GKE 向け Cloud DNS の使用

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

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

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

カスタム バージョンの kube-dns またはカスタム DNS プロバイダを使用する方法については、カスタム kube-dns Deployment の設定をご覧ください。

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 の解決を実現します。

• Google Cloud Observability との統合により、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 の稼働時間や機能（クラスタ スコープ）に影響を与えることなく、クラスタで有効または無効にできます。

• VPC スコープ: DNS レコードを VPC 全体で解決できます。Compute Engine VM とオンプレミス クライアントは、Cloud Interconnect または Cloud VPN を使用して接続し、GKE Service 名を直接解決できます。クラスタごとに一意のカスタム ドメインを設定する必要があります。これは、すべての Service と Pod の DNS レコードが VPC 内で一意であることを意味します。このモードにより、GKE リソースと非 GKE リソース間の通信上の衝突が削減されます。

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

Cloud DNS リソース

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

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

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

カスタム スタブドメインまたはカスタム アップストリーム ネームサーバーの作成方法については、スタブドメインのカスタム リゾルバの追加をご覧ください。

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

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

たとえば、クラスタを us-central1-c ゾーンにデプロイする場合、Cloud DNS コントローラが、us-central1-a、us-central1-b、us-central1-c、および us-central1-f にマネージド ゾーンを作成します。

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

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

料金

Cloud DNS が GKE Standard クラスタの DNS プロバイダである場合、GKE クラスタ内の Pod からの DNS クエリは、Cloud DNS の料金に応じて課金されます。

GKE によって管理される VPC スコープ DNS ゾーンに対するクエリは、標準の Cloud DNS 料金に応じて課金されます。

要件

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

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

• Standard の場合、GKE バージョン 1.24.7-gke.800、1.25.3-gke.700 以降。

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

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

• GKE バージョン 1.28.3-gke.1430000 以降

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

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

• Standard の場合、GKE バージョン 1.19 以降。
• Google Cloud CLI バージョン 364.0.0 以降。
• プロジェクトで Cloud DNS API を有効にする必要があります。

制限事項

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

• VPC スコープは Autopilot クラスタではサポートされていません。クラスタ スコープのみがサポートされています。GKE Autopilot クラスタで実行されているヘッドレス サービス名を解決する必要がある場合は、追加の VPC スコープを使用する必要があります。

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

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

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

• GKE 向け Cloud DNS をクラスタで一度有効にすると、kube-dns はそのクラスタで動作し続けます。kube-dns Deployment とオートスケーラーをゼロにスケーリングすることで、kube-dns を無効にできます。

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

• CloudDNS リソースの制限が適用されます。特に、VPC ネットワークにバインドできるレスポンス ポリシー ゾーンは一度に 1 つだけです。VPC スコープと追加の VPC スコープの場合、クラスタの VPC ネットワークにバインドされた命名規則に従わないレスポンス ポリシー ゾーンがすでに存在すると、クラスタの作成は失敗します。

• カスタム スタブドメインとアップストリーム DNS サーバー構成は、Pod とノードの DNS 構成に適用されます。ホスト ネットワーキングを使用する Pod またはホスト上で直接実行されるプロセスも、スタブドメインとアップストリーム ネームサーバー構成を使用します。これは Standard でのみサポートされています。
• kube-dns Configmap で構成されたカスタム スタブドメインとアップストリーム ネームサーバーは、クラスタ スコープ DNS の Cloud DNS に自動的に適用されます。VPC スコープ DNS は kube-dns ConfigMap を無視するので、これらの構成を Cloud DNS で直接適用する必要があります。これは Standard でのみサポートされています。

• kube-dns から VPC スコープへの移行パスがないため、この操作は中断を伴います。kube-dns から VPC スコープ（またはその逆）に切り替えるときに、クラスタを再作成します。
• VPC スコープの場合、Service のセカンダリ IP アドレス範囲はそのサブネットワーク内の他のクラスタと共有しないでください。
• VPC スコープの場合、PTR レコードに関連付けられたレスポンス ポリシーが VPC ネットワークに接続されます。クラスタ ネットワークにバインドされた他のレスポンス ポリシーがある場合、Kubernetes Service IP アドレスの PTR レコードの解決は失敗します。

• 許可された割り当てを超える数の 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 クラスタ スコープになります。

GKE Standard クラスタ

gcloud CLI または Google Cloud コンソールを使用して、Cloud DNS クラスタ スコープを有効にした GKE Standard クラスタを作成できます。

gcloud container clusters create CLUSTER_NAME \
    --cluster-dns=clouddns \
    --cluster-dns-scope=cluster \
    --location=COMPUTE_LOCATION

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

GKE Autopilot クラスタ

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

GKE Standard クラスタ

既存の GKE Standard クラスタを kube-dns から Cloud DNS クラスタ スコープに移行するには、GKE Standard クラスタで gcloud CLI またはGoogle Cloud コンソールを使用します。

既存のクラスタを移行する場合、ノードを再作成するまで、クラスタ内のノードは Cloud DNS を DNS プロバイダとしては使用しません。

クラスタで Cloud DNS を有効にすると、既存のノードプールをアップグレードするか、クラスタに新しいノードプールを追加する場合にのみ、設定が適用されます。ノードプールをアップグレードすると、ノードが再作成されます。

各ノードプールで Cloud DNS を DNS プロバイダとして個別に有効にすると、クラスタ間の通信を中断することなく、アプリケーションを実行しているクラスタを移行することもできます。一部のノードプールで kube-dns が使用され、一部のノードプールで Cloud DNS が使用されているため、ノードのサブセットは常に稼働しています。

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

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

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

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

新しい GKE クラスタで VPC スコープ DNS を有効にするには、gcloud CLI または Google 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 の解決に失敗する可能性があります。

Standard の場合

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

cluster がデフォルト値であるため、--cluster-dns-scope=cluster フラグは省略可能です。

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

• 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 のロケーション。

VPC スコープ DNS を有効にする

VPC スコープ DNS では、クラスタの DNS 名を VPC 内全体で解決できます。VPC 内のすべてのクライアントが、クラスタ DNS レコードを解決できます。

VPC スコープ DNS を使用すると、次のようなユースケースが可能になります。

• 同じ VPC 内の GKE 以外のクライアントのヘッドレス サービス ディスカバリ。
• オンプレミスまたはサードパーティのクラウド クライアントからの GKE Service の解決。詳細については、インバウンド サーバー ポリシーをご覧ください。
• クライアントが、カスタム クラスタの DNS ドメインを使用して通信するクラスタを決定できる Service の解決。

次の図では、2 つの GKE クラスタが同じ VPC 内の VPC スコープ DNS を使用しています。どちらのクラスタにも、デフォルトの .cluster.local ドメインではなく、.cluster1 と .cluster2 というカスタム DNS ドメインがあります。VM は backend.default.svc.cluster1 を解決して、ヘッドレス バックエンド サービスと通信します。Cloud DNS は、ヘッドレス Service を Service の個々の Pod IP に解決し、VM が Pod IP アドレスと直接通信します。

また、Cloud Interconnect または Cloud VPN 経由で VPC に接続するときに、他のネットワークからこのタイプの解決を行うこともできます。DNS サーバー ポリシーを使用すると、VPC に接続されているネットワークのクライアントから Cloud DNS で名前を解決できます。クラスタが VPC スコープ DNS を使用している場合、これには GKE Service が含まれます。

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

この移行は、GKE Autopilot ではなく、GKE Standard でのみサポートされています。

GKE Autopilot クラスタ

GKE Autopilot クラスタを kube-dns から Cloud DNS VPC スコープに移行することはできません。

GKE Standard クラスタ

既存の GKE クラスタは、gcloud CLI または Google Cloud コンソールを使用して kube-dns から Cloud DNS VPC スコープに移行できます。

クラスタで Cloud DNS を有効にすると、既存のノードプールをアップグレードするか、クラスタに新しいノードプールを追加する場合にのみ、設定が適用されます。ノードプールをアップグレードすると、ノードが再作成されます。

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

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 に転送します。

   GKE Standard クラスタ

   nameserver 169.254.169.254
   

   Pod は nameserver として 169.254.169.254 を使用しています。これは、Cloud DNS データプレーンがポート 53 でリクエストをリッスンするメタデータ サーバーの IP アドレスです。ノードは kube-dns Service アドレスを DNS 解決に使用しなくなり、すべての DNS 解決がローカルノードで行われます。

   出力が 10.x.y.10 のような IP アドレスである場合、Pod は kube-dns を使用しています。Pod がまだ kube-dns を使用している理由を理解するには、トラブルシューティングのセクションをご覧ください。

   出力が 169.254.20.10 の場合、クラスタで NodeLocal DNSCache が有効になっていることを意味しており、Pod は NodeLocal DNSCache を使用しています。

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 クラスタの詳細については、要件をご覧ください。

GKE Standard クラスタ

Cloud DNS クラスタのスコープを無効にするには、GKE Standard クラスタで gcloud CLI または Google Cloud コンソールを使用します。

gcloud container clusters update CLUSTER_NAME \
    --cluster-dns=default

Standard クラスタで Cloud DNS を無効にしたら、クラスタに関連付けられているノードプールを更新します。または、新しいノードプールを作成して、そこにワークロードをスケジュールすることもできます。ノードプールを更新しない場合、DNS Namespace は kube-dns ではなく Cloud DNS を指し続けます。

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 向け Cloud DNS は、VPC とクラスタ スコープ両方の共有 VPC をサポートしています。

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

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

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

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

共有 VPC と Cloud DNS VPC スコープを使用するクラスタがすでにある場合は、次の手順でそれらのクラスタを手動で移行する必要があります。

• 共有 VPC が有効になっている既存のクラスタを GKE バージョン 1.22.3-gke.700 以降または 1.21.6-gke.1500 以降にアップグレードします。
• レスポンス ポリシーをサービス プロジェクトからホスト プロジェクトに移行します。この移行は、共有 VPC ネットワークごとに 1 回だけ行う必要があります。

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

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

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

   Cloud DNS の [ゾーン] に移動

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

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

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

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

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

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

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

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

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

カスタム スタブドメインとアップストリーム ネームサーバーをサポートする

GKE 向け Cloud DNS は、kube-dns ConfigMap を使用して構成されたカスタム スタブドメインとアップストリーム ネームサーバーをサポートしています。このサポートは GKE Standard クラスタでのみ利用できます。

Cloud DNS は、stubDomains と upstreamNameservers の値を Cloud 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 を使用しているために発生します。

この問題は、 Google Cloudの 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 のスコープと階層について確認する。
• 限定公開マネージド ゾーンのロギングの有効化と無効化について学習する。