NGINX Ingress Controller を使用したマルチクラスタ DNS の自動化

ユーザーがアプリケーションを見つけられなければ、そのアプリケーションは目的を果たすことができません。 ドメイン ネーム システム (DNS) は、ドメイン名を IP アドレスに変換してアプリや Web サイトを「見つける」インターネット テクノロジーです。 DNS は非常に普及しており、信頼性が高いため、ほとんどの場合、DNS について考えることすらありません。 しかし、DNS に問題が発生すると、すべてが停止します。 DNS が確実に機能することは、最新のアプリケーション、特にサービスが絶えず起動および停止するマイクロサービス アーキテクチャにとって非常に重要です。

前回の投稿では、同じクラスターで実行されているアプリケーション (マーケティングアプリの場合はunit-demo.marketing.net 、エンジニアリングアプリの場合はunit-demo.engineering.net ) に対応する 2 つのサブドメインの DNS レコードを定義し、同じクラスター エントリ ポイント (つまり、クラスターの NGINX Ingress コントローラーの外部 IP アドレス) に解決する方法について説明しました。 NGINX Ingress Controller では、Server Name Indication (SNI) ルーティングが設定されており、ユーザーが要求したドメイン名に基づいて接続を認証し、適切なアプリケーションにルーティングします。

しかし、多くの組織では、そのユースケースを拡張し、クラウド プロバイダーのリージョンにまたがる可能性のある複数の Kubernetes クラスターにアプリケーションをデプロイする必要があります。 外部トラフィックが新しいクラスター リージョンに到達するには、それらのリージョンに解決される DNS ゾーンを作成する必要があります。

以前は、このプロセスでは、サードパーティ プロバイダー (GoDaddy や DNSExit など) を使用して、ドメイン レジストリを手動で作成し、ホスト レコードを適切に更新する必要がありました。 現在、 ExternalDNS Kubernetes プロジェクトは、Kubernetes リソースをパブリック DNS サーバー経由で検出できるようにすることで、プロセスを自動化しています。 つまり、Kubernetes API を使用して DNS プロバイダーのリストを構成することになります。

ExternalDNS とNGINX Ingress Controllerを統合すると、DNS 名が標準の Kubernetes Ingress リソースまたは NGINX VirtualServerカスタム リソースで宣言されたホスト名から派生するように DNS Aレコードを管理できます。 開発者と DevOps チームは、CI/CD パイプラインでこの統合を活用して、NetOps チーム (通常は DNS を所有) を介さずに、さまざまなクラスター間でアプリケーションを自動的に検出できます。

この投稿では、 GitHub リポジトリのサンプル構成ファイルを使用して、ExternalDNS を NGINX Ingress Controller と統合する方法を説明します。

基本アーキテクチャ

NGINX Ingress Controller を使用して ExternalDNS を実装するには、開発者が Ingress コントローラーを構成して Kubernetes アプリを外部に公開するという基本ケースから始めます。 構成されたドメイン名が Kubernetes クラスターのパブリック エントリ ポイントに解決されるまで、クライアントはアプリに接続できません。

NGINX Ingress Controller は、中間の ExternalDNS Kubernetes デプロイメントを介して DNS プロバイダーと対話し、外部 DNS レコードを使用して Kubernetes アプリケーションの自動検出を可能にします。 図では、黒い線は外部ユーザーが Kubernetes クラスター内のアプリケーションにアクセスする際に使用するデータ パスを表しています。 紫色の線は、アプリ所有者が NGINX Ingress Controller 構成の VirtualServer リソースを使用して外部 DNS レコードを管理し、外部 DNS が DNS プロバイダーにアクセスする制御パスを表しています。

ExternalDNS と NGINX Ingress Controller の統合

ExternalDNS と NGINX Ingress Controller を統合するには、次のセクションの手順を実行します。

• 前提条件
• NGINX Ingress ControllerとExternalDNSをデプロイする
• NGINX Ingress コントローラーを構成する

前提条件

1. 少なくとも 1 つの登録済みドメインを作成します。 その名前を <私のドメイン> 以下の手順に従ってください。 (ドメインの登録方法については、 PCMag のこのガイドを含め、多くの記事があります。)

2. マニフェストまたはHelm チャートを使用して NGINX Ingress Controller をデプロイします。 デプロイメント仕様に、次のコマンドライン引数と同等のものを追加します。

   • -enable-external-dns – ExternalDNS との統合を有効にします。
   • -external-service=nginx-ingress – NGINX Ingress Controller に、DNS プロバイダーによって管理されるAレコードに記録するためのパブリック エントリ ポイントをアドバタイズするように指示します。 パブリック エントリ ポイントのホスト名は、外部サービスnginx-ingressに解決されます。
3. Kubernetes クラスターをオンプレミスにデプロイする場合は、外部ロードバランサーをプロビジョニングします。 無料の電子書籍「Get Me to the Cluster」では、BGP を使用して NGINX を外部ロード バランサーとして導入する手順を説明しています。 あるいは、 F5 BIG‑IPまたはMetalLB を使用することもできます。

4. 必要に応じて、 ExternalDNS でサポートされているプロバイダーに DNS ゾーンを作成します。 このコマンドは、サンプル デプロイメントで使用されるプロバイダ、Google Cloud DNS 用です。

   $ gcloud dns マネージドゾーンは「外部dns-<私のドメイン>" --dns-name "外部DNS。<私のドメイン>." --description "ExternalDNS によって自動的に管理されるゾーン"
   

NGINX Ingress ControllerとExternalDNSをデプロイする

1. サンプル デプロイメント用のGitHub リポジトリをクローンし、NGINX Ingress Controller をデプロイします。

   $ git clone https://github.com/nginxinc/NGINX-Demos.git && cd NGINX-Demos/external-dns-nginx-ingress/ $ kubectl apply -f nginx-ingress.yaml && kubectl apply -f loadbalancer.yaml
   

2. ExternalDNS デプロイメント仕様 (サンプル デプロイメントのexternal-dns-gcloud.yamlの 59 ～ 62 行目) で次の引数を更新します。

   • --ドメインフィルター – 作成されたドメイン名 ステップ4 前のセクション（サンプル展開では、 外部 DNS。<私のドメイン>）。 このドメインのみが使用されるように、既存の値をすべて削除します。
   • --provider – DNS プロバイダー (サンプルのデプロイメントでは、Google DNS の場合はgoogle )。
   • --google-project – サンプル デプロイメントに使用しているGoogle プロジェクトの名前 (複数の Google プロジェクトがある場合にのみ必須)。
   • --txt-owner-id – 選択した ID (サンプル デプロイメントに固有)。

   注記： ExternalDNS デプロイメント仕様に含める必要がある引数は、選択する DNS プロバイダーによって異なる場合があります。 さまざまな DNS プロバイダーを使用して ExternalDNS をクラスターにデプロイするためのチュートリアルの一覧については、 ExternalDNS のドキュメントを参照してください。

3. クラスターに ExternalDNS をデプロイし、デプロイが正常に実行されることを確認します (読みやすくするために出力は 2 行に分かれています)。

   $ kubectl apply -f external-dns-gcloud.yaml $ kubectl get pods -o wide NAME READY STATUS ... external-dns-4hrytf7f98f-ffuffjbf7 1/1 実行中 ... ... 年齢をリスタート... 0 1分
   

NGINX Ingress コントローラーを構成する

次に、外部接続を Kubernetes アプリケーションにルーティングする Ingress ロード バランシング ルールを使用して VirtualServer リソースを構成します。

1. app-virtual-server.yamlで、ホストフィールドを設定します (行 6)。

    6 ホスト: ingress.external-dns。<私のドメイン>
   

   この値と、 external-dns-gcloud.yamlの 59 行目のdomain-filterの値 (前のセクションの手順 2で設定) とのマッピングにより、DNS レコードの自動更新が可能になります。

2. app-virtual-server.yamlを適用し、VirtualServer が正しく構成されていることを確認します。

   $ kubectl apply -f アプリシークレット.yaml && kubectl apply -f アプリ仮想サーバー.yaml
   $ kubectl getと 
   名前 状態 ホスト IP 
   cafe 有効な ingress.external-dns。<私のドメイン>  34.168.バツ。はい
   

3. DNS タイプAレコードが DNS ゾーンに追加されたことを確認します。 特に、 DATAフィールドの IP アドレスは、前の手順のkubectl get vsコマンドの出力のIPフィールド (NGINX Ingress Controller を公開するLoadBalancerタイプのサービスの外部 IP アドレス、またはオンプレミス展開の同等のもの) と一致する必要があります。

   $ gcloud dns レコードセット リスト --zone external-dns-<私のドメイン> -name ingress.external-dns。<私のドメイン> --タイプA名前 タイプ TTL データ
   ingress.external-dns.<私のドメイン>。  A 300 34.168. X . Y
   

4. VirtualServer ホスト名がローカル マシン上で解決できることを検証するには、DNS ゾーンに割り当てられたネーム サーバー (この場合はmy-ns-domains ) を取得します。

   $ gcloud dns レコードセット リスト --zone external-dns。<私のドメイン> --name 外部 DNS。<私のドメイン>. --タイプNS名前 タイプ TTL データ
   外部 DNS。<私のドメイン>。   NS 21600 マイ ns ドメイン
   
   $ dig +short @my-ns-domains ingress.external-dns。<私のドメイン>
   34.168.バツ。はい
   

5. 前の手順で取得した DNS レコードを、登録したドメインの専用ネーム サーバーとして使用します。 これにより、登録したドメインが、前提条件の手順 4で作成された DNS ゾーンの親ゾーンとして設定されます。

6. グローバル インターネットに公開された VirtualServer ホスト名にアクセスできることを確認します。

   $ curl -i --insecure https://ingress.external-dns を実行します。<私のドメイン>/お茶HTTP/1.1 200 OK
   サーバー: nginx/1.23.0
   日付: 日、 DD MM YYYY hh : mm : ss TZコンテンツタイプ: text/plain コンテンツ長: 160 接続: キープアライブ 有効期限: 日、 DD MM YYYY hh : mm : ss TZキャッシュ制御: キャッシュなし
   

複数の Kubernetes クラスターのスケールアウト

外部 DNS レコードの作成を自動化し、それらを図内の新しいクラスター エントリ ポイント ( Kubernetes Cluster 1とKubernetes Cluster 2 ) に解決することで、アーキテクチャを迅速に拡張し、複数のクラスターを自動的に検出できます。 NGINX Ingress Controller と ExternalDNS のデプロイとNGINX Ingress Controller の構成の手順を繰り返します。

また、CI/CD パイプラインでInfrastructure-as-Codeツールを使用して、ExternalDNS と NGINX Ingress Controller で新しいクラスターを生成し、外部トラフィックに公開することもできます。 さらに、検出を有効にする方法に応じて、複数の DNS ゾーン、または複数の DNS プロバイダーを管理することもできます。

結論

生産性と侵害を軽減するセキュリティ対策のバランスを取るのは難しい場合があります。 DevOps チームに制限を課すと、多くの場合、DevOps チームと NetOps/SecOps チームの間に摩擦が生じます。 理想的なバランスは組織ごとに異なりますが、NGINX は優先順位と要件に従ったバランスを確立する柔軟性を提供します。

これまで、アプリ所有者は、アプリケーションを外部システムに接続するために NetOps チームに依存していました。 NGINX との ExternalDNS 統合を使用することで、開発者と DevOps チームは検出可能なアプリケーションを独自にデプロイできるようになり、イノベーションの市場投入までの時間を短縮できます。

Kubernetes で NGINX を使い始めるための包括的なガイドについては、無料の電子書籍「F5 NGINX を使用した Kubernetes トラフィックの管理」をダウンロードしてください。 実用ガイド。

また、NGINX App Protect WAF および DoS を搭載した NGINX Ingress Controller の30 日間無料トライアルをリクエストして、今すぐ開始することもできます。または、弊社にお問い合わせいただき、ユースケースについてご相談ください。