ユーザがアプリケーションを見つけられないことには、アプリケーションはその目的を果たすことができません。ドメインネームシステム(DNS)は、ドメイン名をIPアドレスに変換することで、アプリケーションやWebサイトを「発見」するインターネットテクノロジです。DNSは非常にユビキタスで信頼性が高いため、ほとんどの場合、それについて意識することはありません。しかし、DNSに問題が発生すると、すべてが停止してしまいます。DNSが機能していることを確認することは、最新のアプリケーション、特にサービスが絶えずスピンアップ・ダウンしているマイクロサービスアーキテクチャにおいては非常に重要です。
前回の記事では、同じクラスタで実行されているアプリケーションに対応する2つのサブドメイン(Marketingアプリケーションの場合はunit-demo.marketing.net、 Engineeringアプリケーションの場合は unit-demo.engineering.net)のDNSレコードを定義して、同じクラスタエントリーポイント、つまりクラスタのNGINX Ingress Controllerの外部IPアドレスに解決することについて説明しました。Server Name Indication (SNI) ルーティングはNGINX Ingress Controllerで構成され、ユーザが要求したドメイン名に基づいて適切なアプリケーションへの接続を認証し、ルーティングします。
しかし、多くの組織ではそのユースケースを拡張し、複数のKubernetesクラスタにアプリケーションを導入する必要性に迫られおり、それらのクラスタはクラウドプロバイダのリージョン全体に分散している可能性があります。外部トラフィックが新しいクラスタリージョンに到達するには、それらのリージョンに解決されるDNSゾーンを作成する必要があります。
これまで、このプロセスでは、サードパーティのプロバイダ(GoDaddyやDNSExitなど)を利用して手動でドメインレジストリを作成し、ホストレコードを適切に更新する必要がありました。が、現在では ExternalDNS Kubernetesプロジェクトは、パブリックDNSサーバーを介してKubernetesリソース検出可能にすることで、プロセスを自動化しています。つまり、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を実装するには、開発者がKubernetesアプリケーションを外部公開するようにIngressコントローラを構成する基本ケースから始めます。構成されたドメイン名が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を統合します。
Prerequisites(前提条件)
- 少なくとも1つの登録済みドメインを作成します。次の手順では、その名前を
<my‑domain>
に置き換えます (ドメインの登録方法については、このPCMagのガイドをはじめ、多くの記事で公開されています)。 -
NGINX Ingress ControllerをマニフェストまたはHelmチャートを使って導入します。次に示すものと同等のコマンドライン引数を導入仕様に追加します。
-enable-external-dns
– ExternalDNSとの統合を有効にする。-external-service=nginx-ingress
– DNSプロバイダが管理するA
レコードに記録するために、NGINX Ingress Controllerにパブリックエントリポイントをアドバタイズするように指示します。パブリックエントリポイントのホスト名は、外部サービスnginx-ingress
に解決されます。
- Kubernetesクラスタをオンプレミスで導入する場合は、外部ロードバランサをプロビジョニングします。BGPを使用してNGINXの導入手順については、無料のeBookの『Get Me to the Cluster』を参照してください。または、F5 BIG‑IPかMetalLBを使用します。
-
必要に応じて、DNSゾーンをExternalDNSによってサポートされているプロバイダに作成します。このコマンドは、サンプルの導入で使用されるプロバイダ、Google Cloud DNS用です。
$ gcloud dns managed-zones create "external-dns-<my-domain>" --dns-name "external-dns.<my-domain>." --description "Zone automatically managed by ExternalDNS"
NGINX Ingress ControllerとExternalDNSのデプロイ
-
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
-
次のExternalDNSの導入仕様の引数(サンプルの導入では、 external-dns-gcloud.yamlの59〜62行目)を更新します。
--domain-filter
– 前のセクションの手順 4で作成したドメイン名(サンプルの導入では、external-dns.<my-domain>
)。このドメインのみが使用されるように、既存の値をすべて削除します。--provider
– DNSプロバイダ(サンプルの導入では、Google DNSの場合はgoogle
)。--google-project
– サンプルの導入で使用しているGoogleプロジェクトの名前(複数のGoogleプロジェクトがある場合のみ必須)。--txt-owner-id
– 選択したID(サンプルの導入固有)。
注:ExternalDNSの導入仕様に含める必要がある引数は、選択したDNSプロバイダによって異なる場合があります。さまざまなDNSプロバイダを使用してクラスタにExternalDNSを導入する方法を示すチュートリアル一覧については、ExternalDNSのドキュメントを参照してください。
-
クラスタにExternalDNSを導入し、導入が正常に実行されることを確認します(出力は読みやすくするために2行に分かれています)。
$ kubectl apply -f external-dns-gcloud.yaml $ kubectl get pods -o wide NAME READY STATUS ... external-dns-4hrytf7f98f-ffuffjbf7 1/1 Running ... ... RESTARTS AGE ... 0 1m
NGINX Ingress Controllerの構成
次に、外部接続をKubernetesアプリケーションにルーティングするIngressロードバランシングルールを使用して、VirtualServerリソースを構成します。
-
app-virtual-server.yamlには、
host
(ホスト)フィールド(6行目)を設定します。6 host: ingress.external-dns.<my-domain>
この値とexternal-dns-gcloud.yamlの59行目の
domain-filter
の値(前のセクションの手順2で設定)とのマッピングにより、DNSレコードの自動更新が可能になります。 -
app-virtual-server.yamlを適用し、VirtualServerが正しく構成されていることを確認します。
$ kubectl apply -f app-secret.yaml && kubectl apply -f app-virtual-server.yaml $ kubectl get vs NAME STATE HOST IP cafe Valid ingress.external-dns.<my-domain> 34.168.X.Y
-
DNSタイプ
A
レコードがDNSゾーンに追加されていることを確認します。特に、DATA
(データ)フィールドのIP
アドレスは、前の手順のkubectl
get
vs
コマンドから出力されるIPフィールドと一致する必要があります(NGINX Ingress Controllerを公開するタイプ のLoadBalancer
サービスにおける外部IPアドレス、またはオンプレミスの導入において同等のIPアドレス)。$ gcloud dns record-sets list --zone external-dns-<my-domain> -name ingress.external-dns.<my-domain> --type A NAME TYPE TTL DATA ingress.external-dns.<my-domain>. A 300 34.168.X.Y
-
ローカルマシンでVirtualServerのホスト名を解決できることを確認するには、DNSゾーンに割り当てられたネームサーバーを取得します(この場合は、
my-ns-domains
)。$ gcloud dns record-sets list --zone external-dns.<my-domain> --name external-dns.<my-domain>. --type NS NAME TYPE TTL DATA external-dns.<my-domain>. NS 21600 my-ns-domains $ dig +short @my-ns-domains ingress.external-dns.<my-domain> 34.168.X.Y
- 前の手順で取得したDNSレコードを、登録済みドメインの専用ネームサーバーとして使用します。 これにより、登録されたドメインが、「前提条件」の手順4で作成されたDNSゾーンの親ゾーンとして設定されます。
-
グローバルインターネットに公開されたVirtualServerホスト名にアクセスできることを確認します。
$ curl -i --insecure https://ingress.external-dns.<my-domain>/tea HTTP/1.1 200 OK Server: nginx/1.23.0 Date: Day, DD MM YYYY hh:mm:ss TZ Content-Type: text/plain Content-Length: 160 Connection: keep-alive Expires: Day, DD MM YYYY hh:mm:ss TZ Cache-Control: no-cache
複数のKubernetesクラスタのスケールアウト
外部DNSレコードの作成を自動化し、ダイアグラム内の新しいクラスタのエントリポイント(Kubernetesクラスタ1とKubernetesクラスタ2)を解決に導くことで、アーキテクチャをすばやくスケーリングし、複数のクラスタを自動的に検出できます。「NGINX Ingress ControllerとExternalDNSのデプロイ」「NGINX Ingress Controllerの設定」の手順を繰り返します。
CI/CDパイプラインでInfrastructure-as-Codeツールを使って、ExternalDNSおよびNGINX Ingress Controllerで新しいクラスタを生成し、外部トラフィックに公開することもできます。さらに、検出を有効にする方法に応じて、複数のDNSゾーンまたは複数のDNSプロバイダを管理できます。
結論
高い生産性と侵害を軽減するセキュリティ対策とを両立させることは、難しい場合があります。DevOpsチームに制限を課すと、NetOps/SecOpsチームとの間に摩擦が生じることがよくあります。理想的なバランスは組織によって異なりますが、NGINXはお客様の優先順位や要件に沿ったバランスを確立する柔軟性を提供します。
これまで、アプリケーションの所有者はNetOpsチームに依存してアプリケーションを外部システムに接続していました。NGINXとExternalDNSを統合することで、開発者とDevOpsチームは検出可能なアプリケーションを独自に導入できるようになり、イノベーションを市場に投入するまでの時間を短縮できます。
KubernetesでNGINXを使い始めるための総合的な完全ガイドについては、当社の無料eBook『Managing Kubernetes Traffic with F5 NGINX: A Practical Guide(F5 NGINXによるKubernetesトラフィックの管理:実践的なガイド)』をダウンロードしてください。
また、今すぐ、NGINX App Protect WAFとDoSを備えたNGINX Ingress Controllerの30日間無料トライアルをお申し込みいただくか、具体的なユースケースについてお問合わせください。