GKE 向け Cloud DNS の使用

このページでは、Google Kubernetes Engine（GKE）の Kubernetes DNS プロバイダとして Cloud DNS を使用する方法について説明します。

Cloud DNS を DNS プロバイダとして使用しても、クラスタ外のクライアントが直接 Kubernetes Service を解決してアクセスすることはできません。ロードバランサを使用して Service を外部に公開し、クラスタの外部 IP アドレスを DNS インフラストラクチャに登録する必要があります。

DNS プロバイダとして kube-dns を使用する方法についての詳細は、サービス ディスカバリと DNS をご覧ください。

GKE 向け Cloud DNS の仕組み

Cloud DNS は GKE 向けの DNS プロバイダとして使用できます。クラスタでホストされる DNS プロバイダを必要とせずに、マネージド DNS で Pod と Service の DNS 解決を行うことができます。Pod と Service の DNS レコードは、クラスタ IP アドレス、ヘッドレス、外部名の各 Service 向けに Cloud DNS に自動でプロビジョニングされます。

Cloud DNS は、完全な Kubernetes DNS 仕様をサポートし、GKE クラスタ内の Service の A、AAAA、SRV、PTR の各レコードの解決を行います。PTR レコードは、レスポンス ポリシー ルールを使用して実装されます。

Cloud DNS を GKE 向け DNS プロバイダとして使用すると、クラスタでホストされる DNS と比べて多くのメリットがあります。

• クラスタでホストされる DNS サーバーの管理にかかるオーバーヘッドを解消。Cloud DNS は、スケーラビリティに優れた Google インフラストラクチャでホストされるフルマネージド サービスであるため、DNS インスタンスのスケーリング、モニタリング、管理は必要ありません。
• 各 GKE ノードでの DNS クエリのローカル解決。NodeLocal DNSCache と同様に、Cloud DNS は DNS レスポンスをローカルにキャッシュし、低レイテンシでスケーラビリティの高い DNS の解決を実現します。

アーキテクチャ

Cloud DNS が GKE 向け DNS プロバイダである場合、コントローラは GKE マネージド Pod として動作します。この Pod は、クラスタのコントロール プレーン ノードで実行され、クラスタの DNS レコードを限定公開マネージド DNS ゾーンに同期します。

次の図は、Cloud DNS コントロール プレーンとデータプレーンがクラスタ名を解決する方法を示しています。

この図で、Service backend は実行中の backend Pod を選択します。clouddns-controller は Service backend の DNS レコードを作成します。

Pod frontend は、backend という名前の Service の IP アドレスを解決するために DNS リクエストを 169.254.169.254 にある Compute Engine のローカル メタデータ サーバーに送信します。このメタデータ サーバーはノードのローカルで実行され、キャッシュミスを Cloud DNS に送信します。

Cloud DNS データプレーンは、各 GKE ノードまたは Compute Engine 仮想マシン（VM）インスタンス内で、ローカルに動作します。Kubernetes Service のタイプに応じて、Cloud DNS は Service 名を、その仮想 IP アドレス（クラスタ IP Service の場合）またはエンドポイント IP アドレスのリスト（ヘッドレス Service の場合）に解決します。

Pod frontend が IP アドレスを解決したら、Pod は Service backend と Service の内側のすべての Pod にトラフィックを送信できます。

DNS スコープ

Cloud DNS には次の DNS スコープがあります。複数のモードでクラスタを同時に動作させることはできません。

• GKE クラスタ スコープ: DNS レコードをクラスタ内でのみ解決可能です。これは kube-dns と同じ動作です。Service 名を解決できるのは、GKE クラスタで動作しているノードのみです。デフォルトでは、クラスタの DNS 名は *.cluster.local で終わります。これらの DNS 名はクラスタ内でのみ参照され、同じプロジェクト内の他の GKE クラスタの *.cluster.local DNS 名と重複または競合しません。これがデフォルト モードです。

  • Cloud DNS の追加の VPC スコープ:

    Cloud DNS の追加の VPC スコープは、GKE クラスタ スコープを拡張して、ヘッドレス サービスを VPC 内の他のリソース（Cloud VPN または Cloud Interconnect を使用して接続された Compute Engine VM やオンプレミス クライアントなど）から解決できるようにするオプション機能です。追加の VPC スコープは、クラスタ スコープと並行して有効になる追加モードです。DNS の稼働時間や機能（クラスタ スコープ）に影響を与えることなく、クラスタで有効または無効にできます。

次の表に、DNS スコープの違いを示します。

Cloud DNS リソース

GKE クラスタの DNS プロバイダとして Cloud DNS を使用すると、Cloud DNS コントローラによりプロジェクトの Cloud DNS にリソースが作成されます。GKE が作成するリソースは、Cloud DNS のスコープによって異なります。

これらの Cloud DNS リソースに使用される命名規則は次のとおりです。

前の表にあるゾーンに加えて、Cloud DNS コントローラは構成に応じて次のゾーンをプロジェクト内に作成します。

マネージド ゾーンと転送ゾーン

内部 DNS トラフィックを処理するため、Cloud DNS コントローラは、クラスタが属するリージョンの Compute Engine ゾーンごとにマネージド DNS ゾーンを作成します。

Cloud DNS コントローラは、DNS stubDomain ごとに 1 つの転送ゾーンを作成します。

Cloud DNS は、. DNS 名を持つ 1 つのマネージド ゾーンを使用して、各 DNS アップストリームを処理します。

要件

プロジェクトで Cloud DNS API を有効にする必要があります。

GKE 向け Cloud DNS には、クラスタ スコープに関する次の要件があります。

• Autopilot の場合、GKE バージョン 1.25.9-gke.400、1.26.4-gke.500 以降。
• Google Cloud CLI バージョン 411.0.0 以降。

GKE 向け Cloud DNS には、追加の VPC スコープに関する次の要件があります。

• Google Cloud CLI バージョン 503.0.0 以降。
• GKE クラスタは、デフォルトの DNS プロバイダとして Cloud DNS クラスタ スコープを使用する必要があります。

制限事項

次の制限が適用されます。

• 追加の VPC スコープの GKE Autopilot クラスタは、クラスタの作成時にのみ有効にできます。既存の GKE Autopilot クラスタで追加の VPC スコープを有効または無効にすることはできません。

• GKE 向け Cloud DNS は、IL4 コンプライアンス レジームの Assured Workload では使用できません。このような規制対象の環境では、kube-dns が強制されます。

• マネージド プライベート DNS ゾーンに対する手動変更はサポートされておらず、Cloud DNS コントローラによって上書きされます。これらのゾーンの DNS レコードに対する変更は、コントローラを再起動すると保持されません。

• --cluster-dns-scope フラグでスコープを設定した後で、クラスタの DNS スコープを変更することはできません。DNS スコープを変更する必要がある場合は、別の DNS スコープでクラスタを再作成します。

• 許可された割り当てを超える数の Pod を使用してヘッドレス Service を作成しようとすると、Cloud DNS は Service のレコードセットやレコードを作成しません。

割り当て

Cloud DNS は、割り当てを使用して、GKE が DNS エントリ用に作成できるリソースの数を制限します。Cloud DNS の割り当てと上限は、プロジェクトの kube-dns の制限とは異なる場合があります。

GKE 向け Cloud DNS を使用する場合、次のデフォルトの割り当てがプロジェクトの各マネージド ゾーンに適用されます。

リソースの上限

次の表に示すように、クラスタごとに作成する Kubernetes リソースは Cloud DNS リソースの上限に影響します。

Kubernetes に対する DNS レコードの作成方法については、Kubernetes の DNS ベースのサービス ディスカバリをご覧ください。

始める前に

作業を始める前に、次のことを確認してください。

• Google Kubernetes Engine API を有効にする。
Google Kubernetes Engine API の有効化
• このタスクに Google Cloud CLI を使用する場合は、gcloud CLI をインストールして初期化する。すでに gcloud CLI をインストールしている場合は、gcloud components update を実行して最新のバージョンを取得する。

• プロジェクトで Cloud DNS API を有効にします。

  Cloud DNS API を有効にする

クラスタ スコープ DNS を有効にする

クラスタ スコープ DNS では、GKE クラスタで動作しているノードのみがサービス名を解決でき、サービス名はクラスタ間で競合しません。この動作は GKE クラスタの kube-dns と同じです。つまり、ダウンタイムやアプリケーションへの変更なしで kube-dns から Cloud DNS クラスタ スコープにクラスタを移行できます。

次の図は、Cloud DNS により GKE クラスタの限定公開 DNS ゾーンが作成される仕組みを示しています。クラスタの DNS レコードを解決できるのは、クラスタ内のノードで動作しているプロセスと Pod のみです。これは、DNS スコープにはノードのみが含まれているためです。

新しいクラスタでクラスタ スコープ DNS を有効にする

GKE Autopilot クラスタ

バージョン 1.25.9-gke.400、1.26.4-gke.500 以降の新しい Autopilot クラスタは、デフォルトで Cloud DNS クラスタ スコープになります。

既存のクラスタでクラスタ スコープ DNS を有効にする

GKE Autopilot クラスタ

既存の GKE Autopilot クラスタを kube-dns から Cloud DNS クラスタ スコープに移行することはできません。Cloud DNS クラスタ スコープを有効にするには、バージョン 1.25.9-gke.400、1.26.4-gke.500 以降で Autopilot クラスタを再作成します。

Cloud DNS の追加の VPC スコープを有効にする

このセクションでは、Cloud DNS クラスタ スコープのアドオンとして、Cloud DNS の追加の VPC スコープを有効または無効にする手順について説明します。

新しいクラスタで Cloud DNS の追加の VPC スコープを有効にする

新しい GKE クラスタで VPC スコープ DNS を有効にするには、gcloud CLI または Trusted Cloud コンソールを使用します。

Autopilot の場合

gcloud container clusters create-auto CLUSTER_NAME \
    --additive-vpc-scope-dns-domain=UNIQUE_CLUSTER_DOMAIN

次のように置き換えます。

• CLUSTER_NAME: クラスタの名前。
• UNIQUE_CLUSTER_DOMAIN: ドメインの名前。GKE はこの値を確認しないため、この名前は VPC 内で必ず一意になるようにしてください。この値は、設定後は変更できません。「.local」で終わるドメインは使用しないでください。DNS の解決に失敗する可能性があります。

既存のクラスタで Cloud DNS の追加の VPC スコープを有効にする

既存のクラスタで Cloud DNS の追加の VPC スコープを有効にするには、まずクラスタに対して Cloud DNS を有効にしてから、ノードプールをアップグレードします。ノードプールをアップグレードすると、ノードが再作成されます。その後、ノードは kube-dns ではなく Cloud DNS を使用して DNS 解決を行います。

既存のクラスタで Cloud DNS の追加の VPC スコープを有効にするには:

gcloud container clusters update CLUSTER_NAME \
    --additive-vpc-scope-dns-domain=UNIQUE_CLUSTER_DOMAIN \
    --location=COMPUTE_LOCATION

次のように置き換えます。

• CLUSTER_NAME: クラスタの名前。
• UNIQUE_CLUSTER_DOMAIN: ドメインの名前。GKE はこの値を確認しないため、この名前は VPC 内で必ず一意になるようにしてください。この値は、設定後は変更できません。「.local」で終わるドメインは使用しないでください。DNS の解決に失敗する可能性があります。
• COMPUTE_LOCATION: クラスタの Compute Engine のロケーション。

Cloud DNS を確認する

GKE 用 Cloud DNS がクラスタで正しく動作していることを確認します。

1. ノード上の Pod に接続し、cat /etc/resolv.conf コマンドを実行して、ノードが Cloud DNS を使用していることを確認します。

   kubectl exec -it POD_NAME -- cat /etc/resolv.conf | grep nameserver
   

   POD_NAME は、Pod の名前で置き換えます。

   クラスタモードに基づいて、出力は次のようになります。

   GKE Autopilot クラスタ

   nameserver 169.254.20.10
   

   GKE Autopilot では NodeLocal DNSCache がデフォルトで有効になっているため、Pod は NodeLocal DNSCache を使用しています。

   ローカル キャッシュに検索対象名のエントリがない場合にのみ、NodeLocal DNSCache はリクエストを Cloud DNS に転送します。

2. サンプル アプリケーションをクラスタにデプロイします。

   kubectl run dns-test --image us-docker.pkg.dev/google-samples/containers/gke/hello-app:2.0
   

3. サンプル アプリケーションを Service で公開します。

   kubectl expose pod dns-test --name dns-test-svc --port 8080
   

4. Service が正常にデプロイされたことを確認します。

   kubectl get svc dns-test-svc
   

   出力は次のようになります。

   NAME           TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
   dns-test-svc   ClusterIP   10.47.255.11    <none>        8080/TCP   6m10s
   

   CLUSTER-IP の値は、クラスタの仮想 IP アドレスです。この例の仮想 IP アドレスは 10.47.255.11 です。

5. Service 名がクラスタの限定公開 DNS ゾーンにレコードとして作成されていることを確認します。

   gcloud dns record-sets list \
       --zone=PRIVATE_DNS_ZONE \
       --name=dns-test-svc.default.svc.cluster.local.
   

   PRIVATE_DNS_ZONE は、マネージド DNS ゾーンの名前に置き換えます。

   出力は次のようになります。

   NAME: dns-test-svc.default.svc.cluster.local.
   TYPE: A
   TTL: 30
   DATA: 10.47.255.11
   

GKE 向け Cloud DNS を無効にする

GKE Autopilot クラスタ

Cloud DNS を使用してデフォルトで作成された GKE Autopilot クラスタの Cloud DNS を無効にすることはできません。デフォルトで Cloud DNS を使用する GKE Autopilot クラスタの詳細については、要件をご覧ください。

Cloud DNS の追加の VPC スコープを無効にする

クラスタに対して Cloud DNS の追加の VPC スコープを無効にすると、VPC ネットワークに接続されている限定公開ゾーンの DNS レコードのみが削除されます。GKE クラスタの限定公開 DNS ゾーン内のレコードは、ヘッドレス サービスがクラスタから削除されるまで、GKE 向け Cloud DNS によって管理されます。

Cloud DNS の追加の VPC スコープを無効にするには、次のコマンドを実行します。

gcloud container clusters update CLUSTER_NAME \
    --disable-additive-vpc-scope

CLUSTER_NAME は、クラスタの名前に置き換えます。

これにより、Cloud DNS クラスタ スコープが有効なクラスタが維持され、クラスタ内から DNS 解決を行うことができます。

クリーンアップ

このページの演習を完了したら、アカウントで不要な請求が発生しないように、以下の手順でリソースを削除します。

1. 次のコマンドでサービスを削除します。

   kubectl delete service dns-test-svc
   

2. Pod を削除します。

   kubectl delete Pod dns-test
   

3. クラスタを削除することもできます。

共有 VPC で Cloud DNS を使用する

GKE コントローラは、GKE クラスタと同じプロジェクトにマネージド プライベート ゾーンを作成します。

マネージド ゾーンと GKE クラスタは同じプロジェクト内にあるため、GKE クラスタの GKE サービス アカウントには、プロジェクト外の DNS の Identity and Access Management（IAM）は必要ありません。

サービス プロジェクトごとに複数のクラスタ

GKE バージョン 1.22.3-gke.700、1.21.6-gke.1500 以降では、同じホスト プロジェクト内の VPC を参照する複数のサービス プロジェクトでクラスタを作成できます。

レスポンス ポリシーは、 Trusted Cloud コンソールで移行できます。

サービス プロジェクトで次の操作を行います。

1. [Cloud DNS] ページに移動します。

   Cloud DNS の [ゾーン] に移動

2. [レスポンス ポリシーのゾーン] タブをクリックします。

3. VPC ネットワークのレスポンス ポリシーをクリックします。レスポンス ポリシーは、「ネットワーク NETWORK_NAME 上の GKE クラスタのレスポンス ポリシー」のような説明によって識別できます。

4. [使用中] タブをクリックします。

5. ホスト プロジェクトの名前の横にある delete をクリックして、ネットワーク バインディングを削除します。

6. [レスポンス ポリシー ルール] タブをクリックします。

7. テーブル内のすべてのエントリを選択します。

8. [レスポンス ポリシー ルールを削除] をクリックします。

9. delete [レスポンス ポリシーを削除] をクリックします。

レスポンス ポリシーを削除すると、DNS コントローラによって、ホスト プロジェクトにレスポンス ポリシーが自動的に作成されます。他のサービス プロジェクトのクラスタが、このレスポンス ポリシーを共有します。

仕様拡張

さまざまなクライアントやシステムとのサービス ディスカバリと互換性を改善するため、一般的な Kubernetes DNS 仕様に加えて追加の仕様が用意されています。

名前付きポート

このセクションでは、Cloud DNS によって Kubernetes クラスタ用に作成される DNS レコードに名前付きポートがどのように影響するかについて説明します。Kubernetes は、必要な DNS レコードの最小セットを定義します。一方、Cloud DNS は、独自のオペレーションとさまざまな Kubernetes 機能をサポートするために追加のレコードを作成する場合があります。次の表に、想定されるレコードセットの最小数を示します。ここで、「E」はエンドポイントの数、「P」はポートの数を表します。Cloud DNS によって追加のレコードが作成される場合があります。

Cloud DNS によって作成される追加の DNS レコード

Cloud DNS は、レコードセットの最小数を超える DNS レコードを作成する場合があります。これらのレコードは、次のようなさまざまな目的に使用されます。 SRV レコード: Cloud DNS は、サービス ディスカバリのために SRV レコードを作成します。これらのレコードには、サービスのポートとプロトコルに関する情報が含まれています。AAAA レコード（デュアル スタックの場合）: デュアル スタック構成（IPv4 と IPv6）では、Cloud DNS は各エンドポイントに A レコード（IPv4 用）と AAAA レコード（IPv6 用）の両方を作成します。内部レコード: Cloud DNS は、独自の管理と最適化のために内部レコードを作成します。通常、これらのレコードはユーザーに直接関連するものではありません。LoadBalancer Service: LoadBalancer タイプの Service に対して、Cloud DNS は外部ロードバランサの IP アドレスに関連付けられたレコードを作成します。Headless Service: Headless Service には独自の DNS 構成があります。各 Pod は独自の DNS レコードを取得するため、クライアントは Pod に直接接続できます。このため、ヘッドレス Service レコードの計算でポート番号は乗算されません。

例: backend Namespace にある my-http-server という Service について考えてみましょう。この Service は、3 つの Pod を含む Deployment に対して 80 と 8080 の 2 つのポートを公開します。したがって、E = 3、P = 2 です。

これらの最小レコードに加えて、Cloud DNS は SRV レコードを作成します。デュアル スタックの場合は AAAA レコードも作成します。my-http-server が LoadBalancer タイプの Service の場合、ロードバランサ IP 用に追加レコードが作成されます。注: Cloud DNS は、必要に応じて補足の DNS レコードを追加します。作成される具体的なレコードは、Service のタイプや構成などの要因によって異なります。

既知の問題

Terraform は dns_config の変更により Autopilot クラスタの再作成を計画している

terraform-provider-google または terraform-provider-google-beta を使用すると、Terraform が Autopilot クラスタの再作成を試みるという問題が発生することがあります。このエラーは、バージョン 1.25.9-gke.400、1.26.4-gke.500、1.27.1-gke.400 以降を実行している新しく作成された Autopilot クラスタが、kube-dns の代わりに DNS プロバイダとして Cloud DNS を使用しているために発生します。

この問題は、 Trusted Cloud by S3NSの Terraform プロバイダのバージョン 4.80.0 で解決されています。

terraform-provider-google または terraform-provider-google-beta のバージョンを更新できない場合は、lifecycle.ignore_changes をリソースに追加して、google_container_cluster が dns_config への変更を無視するようにできます。

  lifecycle {
    ignore_changes = [
      dns_config,
    ]
  }

NodeLocal DNSCache が有効な状態で kube-dns から Cloud DNS に移行した後に DNS 解決が失敗する

このセクションでは、クラスタ スコープで NodeLocal DNSCache を使用する Cloud DNS の GKE クラスタに存在する既知の問題について説明します。

クラスタで NodeLocal DNSCache を有効にして kube-DNS から Cloud DNS に移行すると、クラスタで断続的に名前解決エラーが発生することがあります。

クラスタで NodeLocal DNSCache が有効になっている状態で kube-dns を使用する場合、NodeLocal DNSCache は両方のアドレス（NodeLocal DNSCache アドレスと kube-dns アドレス）でリッスンするように構成されます。

NodeLocal DNSCache のステータスを確認するには、次のコマンドを実行します。

kubectl get cm -n kube-system node-local-dns -o json | jq .data.Corefile -r | grep bind

出力は次のようになります。

    bind 169.254.20.10 x.x.x.10
    bind 169.254.20.10 x.x.x.10

クラスタを Cloud DNS に更新した後、NodeLocal DNSCache 構成が変更されたので、NodeLocal DNSCache を確認します。

kubectl get cm -n kube-system node-local-dns -o json | jq .data.Corefile -r | grep bind

出力は次のようになります。

    bind 169.254.20.10
    bind 169.254.20.10

次のワークフローは、移行とノードの再作成中の resolv.conf ファイルのエントリを示しています。

移行前

• Pod の resolv.conf が kube-dns-IP（x.x.x.10 など）に構成されています。
• Node-local-cache Pod は両方のアドレスでリッスンし（169.254.20.10 x.x.x.10 をバインド）、Pod からの DNS リクエストが重複しています。
• NodeLocal DNSCache はキャッシュとして機能し、kube-dns Pod にほとんど負荷がかかりません。

移行後

• コントロール プレーンが Cloud DNS を使用するように更新された後も、Pod の resolv.conf は kube-dns-IP（x.x.x.10 など）に構成されたままです。GKE で 169.254.20.10 を使用するにはノードの再作成が必要であるため、この構成は保持されます。Cloud DNS の設定には 169.254.20.10 が必要です。
• Node-local-cache Pod は、NodeLocal DNSCache アドレスでのみリッスンします（169.254.20.10 にバインド）。リクエストが Node-local-cache Pod に送信されません。
• Pod からのすべてのリクエストは、kube-dns Pod に直接送信されます。この設定では、Pod で大量のトラフィックが発生します。

ノードの再作成後またはノードプールのアップグレード後

• Pod の resolv.conf は、NodeLocal DNSCache IP アドレス（169.254.20.10）に構成されています。
• Node-local-cache Pod は、NodeLocal DNSCache アドレス（169.254.20.10 にバインド）でのみリッスンし、この IP アドレスの Pod から DNS リクエストを受信します。

ノードプールの再作成前にノードプールが resolv.conf の kube-dns IP を使用すると、DNS クエリ トラフィックの増加に伴い kube-dns Pod のトラフィックが増加し、DNS リクエストが断続的に失敗します。エラーを最小限に抑えるため、この移行はダウンタイム中に行う必要があります。

トラブルシューティング

Cloud DNS のトラブルシューティングについては、次のページをご覧ください。

• GKE の Cloud DNS に関するアドバイスについては、GKE での Cloud DNS のトラブルシューティングをご覧ください。
• Cloud DNS に関する具体的なアドバイスについては、Cloud DNS のトラブルシューティングをご覧ください。
• Kubernetes DNS の問題の診断に関する一般的な情報については、DNS 解決のデバッグをご覧ください。

次のステップ

• GKE がマネージド DNS を提供する方法の概要を確認する。
• Kubernetes クラスタで DNS が使用される仕組みの一般的な概要について、Service と Pod の DNS を確認する。
• Cloud DNS のスコープと階層について確認する。
• 限定公開マネージド ゾーンのロギングの有効化と無効化について学習する。