GKE 向け Cloud DNS の使用

Autopilot Standard

---

このページでは、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 にトラフィックを送信できます。

注: kube-dns は、バージョン 1.19 以降の Cloud DNS が有効になっている新規および既存の GKE クラスタで引き続き動作します。kube-dns Deployment とオートスケーラーをゼロにスケーリングすることで、kube-dns を無効にできます。

DNS スコープ

Cloud DNS には、GKE クラスタ スコープと Virtual Private Cloud（VPC）スコープの 2 種類の DNS スコープがあります。両方のモードでクラスタを同時に動作させることはできません。

• GKE クラスタ スコープ: DNS レコードをクラスタ内でのみ解決可能です。これは kube-dns と同じ動作です。Service 名を解決できるのは、GKE クラスタで動作しているノードのみです。デフォルトでは、クラスタの DNS 名は *.cluster.local で終わります。これらの DNS 名はクラスタ内でのみ参照され、同じプロジェクト内の他の GKE クラスタの *.cluster.local DNS 名と重複または競合しません。これがデフォルト モードです。
• VPC スコープ: DNS レコードを VPC 全体で解決できます。Compute Engine VM とオンプレミス クライアントは、Cloud Interconnect または Cloud VPN を使用して接続し、GKE Service 名を直接解決できます。クラスタごとに一意のカスタム ドメインを設定する必要があります。これは、すべての Service と Pod の DNS レコードが VPC 内で一意であることを意味します。このモードにより、GKE リソースと非 GKE リソース間の通信上の衝突が削減されます。

Cloud DNS リソース

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

スコープ	前方参照ゾーン	逆引き参照ゾーン
クラスタのスコープ	Compute Engine ゾーン（リージョン内）ごとにクラスタごとに 1 つの限定公開ゾーン	Compute Engine ゾーン（リージョン内）ごとにクラスタごとに 1 つのレスポンス ポリシー ゾーン
VPC スコープ	クラスタごとに 1 つの限定公開ゾーン（グローバル ゾーン）	クラスタごとに 1 つのレスポンス ポリシー ゾーン（グローバル ゾーン）

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

スコープ	前方参照ゾーン	逆引き参照ゾーン
クラスタのスコープ	gke-CLUSTER_NAME-CLUSTER_HASH-dns	gke-CLUSTER_NAME-CLUSTER_HASH-rp
VPC スコープ	gke-CLUSTER_NAME-CLUSTER_HASH-dns	gke-NETWORK_NAME_HASH-rp

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

カスタム DNS 構成	ゾーンのタイプ	ゾーンの命名規則
スタブドメイン	転送（グローバル ゾーン）	gke-CLUSTER_NAME-CLUSTER_HASH-DOMAIN_NAME_HASH
カスタムのアップストリーム ネームサーバー	転送（グローバル ゾーン）	gke-CLUSTER_NAME-CLUSTER_HASH-upstream

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

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

内部 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 料金に応じて課金されます。

要件

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 以降。
• プロジェクトで Cloud DNS API を有効にする必要があります。

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

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

制限事項

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

• VPC スコープは Autopilot クラスタではサポートされていません。クラスタ スコープのみがサポートされています。
• Cloud DNS は、影響レベル 4（IL4）のコンプライアンス体制に準拠していません。GKE 向け Cloud DNS は、IL4 コンプライアンス体制がある Assured Workloads 環境では使用できません。このような規制された環境では kube-dns を使用する必要があります。GKE Autopilot クラスタの場合、kube-dns または Cloud DNS の選択はコンプライアンス体制に基づいて自動的に行われます。
• 限定公開マネージド DNS ゾーンに対する手動変更はサポートされておらず、Cloud DNS コントローラによって上書きされます。これらのゾーンの DNS レコードに対する変更は、コントローラを再起動すると保持されません。
• GKE 向け Cloud DNS をクラスタで一度有効にすると、kube-dns はそのクラスタで動作し続けます。kube-dns Deployment とオートスケーラーをゼロにスケーリングすることで、kube-dns を無効にできます。
• --cluster-dns-scope フラグでスコープを設定した後で、クラスタの DNS スコープを変更することはできません。DNS スコープを変更する必要がある場合は、別の DNS スコープでクラスタを再作成します。
• カスタム スタブドメインとアップストリーム 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 のレコードセットやレコードを作成しません。
• kube-dns から Cloud DNS VPC スコープへの切り替えは、中断が発生する操作です。この操作は、メンテナンスの時間枠中に行うことをおすすめします。

割り当て

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

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

Kubernetes DNS リソース	対応する Cloud DNS リソース	割り当て
DNS レコードの数	マネージド ゾーンあたりの最大バイト数	2,000,000（マネージド ゾーンの場合は最大 50 MB）
ヘッドレス サービスあたりの Pod 数（IPv4 / IPv6）	リソース レコードセットあたりのレコード数	GKE 1.24～1.25: 1,000（IPv4 / IPv6） GKE 1.26 以降: 3,500 / 2,000（IPv4 / IPv6）
プロジェクト内の GKE クラスタ数	プロジェクトあたりのレスポンス ポリシー数	100
クラスタあたりの PTR レコード数	レスポンス ポリシーごとのルール数	100,000

注: VPC スコープの場合、VPC 全体で使用されるマネージド ゾーンに同じ上限が適用されます。これらの割り当ては、Cloud DNS VPC スコープを使用し、同じ VPC で実行される一連のクラスタに適用されます。

リソースの上限

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

上限	上限への影響
マネージド ゾーンあたりのリソース レコードセット	サービスの数と、有効なホスト名があるヘッドレス サービス エンドポイントの数（クラスタごと）
リソース レコードセットあたりのレコード	ヘッドレス サービスごとのエンドポイントの数。他のサービスタイプには影響しません。
レスポンス ポリシーごとのルール数	クラスタ スコープの場合、サービスの数と、クラスタごとに有効なホスト名があるヘッドレス サービス エンドポイントの数。VPC スコープの場合、サービスの数と、VPC 内のすべてのクラスタのホスト名があるヘッドレス エンドポイントの数。

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

始める前に

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

• Google Kubernetes Engine API を有効にします。
Google Kubernetes Engine API の有効化
• このタスクに Google Cloud CLI を使用する場合は、gcloud CLI をインストールして初期化します。すでに gcloud CLI をインストールしている場合は、gcloud components update を実行して最新のバージョンを取得します。
  注: gcloud CLI がすでにインストールされている場合には、必ず compute/region と compute/zone のプロパティを設定してください。デフォルトのロケーションを設定することで、gcloud CLI のエラー（One of [--zone, --region] must be supplied: Please specify location など）を防止できます。

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

  Cloud DNS API を有効にする

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

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

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

図: クラスタ スコープ 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

--cluster-dns フラグを使用してクラスタを作成します。

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

注: 411.0.0 よりも前のバージョンの Google Cloud CLI では、gcloud container ではなく gcloud beta container を使用します。

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

• CLUSTER_NAME: クラスタの名前。
• COMPUTE_LOCATION: クラスタの Compute Engine のロケーション。

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

コンソール

1. Google Cloud コンソールで Google Kubernetes Engine のページに移動します。

   Google Kubernetes Engine に移動

2. [ 作成] をクリックします。

3. ナビゲーション パネルの [クラスタ] の下の [ネットワーキング] をクリックします。

4. [DNS プロバイダ] セクションで、[Cloud DNS] をクリックします。

5. [クラスタのスコープ] を選択します。

6. 必要に応じてクラスタを構成します。

7. [作成] をクリックします。

既存のクラスタでクラスタ スコープ 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 解決を行います。

gcloud

1. 既存のクラスタを更新します。

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

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

   • CLUSTER_NAME: クラスタの名前。
   • COMPUTE_LOCATION: クラスタの Compute Engine のロケーション。

   レスポンスは次の例のようになります。

   All the node-pools in the cluster need to be re-created by the user to start using Cloud DNS for DNS lookups. It is highly recommended to complete this step
   shortly after enabling Cloud DNS.
   Do you want to continue (Y/n)?
   

   確認後、Cloud DNS コントローラは GKE コントロール プレーンで動作するようになりますが、ノードプールをアップグレードするか、クラスタに新しいノードプールを追加するまで、Pod は DNS 解決に Cloud DNS を使用しません。

2. Cloud DNS を使用するようにクラスタ内のノードプールをアップグレードします。

   gcloud container clusters upgrade CLUSTER_NAME \
       --node-pool=POOL_NAME \
       --location=COMPUTE_LOCATION
   

   注: 411.0.0 よりも前のバージョンの Google Cloud CLI では、gcloud container ではなく gcloud beta container を使用します。

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

   • CLUSTER_NAME: クラスタの名前。
   • POOL_NAME: アップグレードするノードプールの名前。

   ノードプールとコントロール プレーンが同じバージョンを実行している場合は、コントロール プレーンの手動アップグレードに従ってコントロール プレーンをアップグレードしてから、ノードプールをアップグレードしてください。

   注: 現在実行中のノードプールと同じバージョンにアップグレードしても、Pod に影響はありません。このようなノードプールでは、これらのノードで実行されている Pod は引き続き kube-dns を使用します。kube-dns のデプロイとオートスケーラーをゼロにスケールダウンすると、こうした Pod で DNS 障害が発生します。Pod で Cloud DNS を使用するには、ノードプールを新しいバージョンにアップグレードする必要があります。他の方法としては、同じバージョンで新しいノードプールを作成することもできます。

   レスポンスを確認し、クラスタ内のノードプールごとにこのコマンドを繰り返します。クラスタにノードプールが 1 つしかない場合は、--node-pool フラグを省略します。

コンソール

1. Google Cloud コンソールで Google Kubernetes Engine のページに移動します。

   Google Kubernetes Engine に移動

2. 変更するクラスタの名前をクリックします。

3. [ネットワーキング] の [DNS プロバイダ] フィールドで、 [DNS プロバイダを編集] をクリックします。

4. [Cloud DNS] をクリックします。

5. [クラスタのスコープ] をクリックします。

6. [変更を保存] をクリックします。

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 と直接通信します。

注: GKE クラスタ外部からアクセスできる IP アドレスに解決されるのは、ヘッドレス Service のみです。ClusterIP Service は、クラスタ内でローカルにのみ存在する仮想 IP アドレスを使用します。

図: VPC スコープ DNS

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

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

GKE Autopilot クラスタ

VPC スコープ DNS を使用して GKE Autopilot クラスタを作成することはできません。この機能は GKE Autopilot ではサポートされていません。

GKE Standard クラスタ

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

警告: cluster-dns-domain 以外の cluster.local を指定すると、Kubernetes Service に対するすべての *.cluster.local クエリが失敗します。*.cluster.local を使用する名前に対して DNS ルックアップを実行しないでください。

gcloud

次のコマンドを使用して、VPC スコープの Cloud DNS が有効な新しいクラスタを作成します。

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

注: 364.0.0 よりも前のバージョンの Google Cloud CLI では、gcloud container ではなく gcloud beta container を使用します。

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

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

コンソール

1. Google Cloud コンソールで Google Kubernetes Engine のページに移動します。

   Google Kubernetes Engine に移動

2. [ 作成] をクリックします。

3. ナビゲーション パネルの [クラスタ] の下の [ネットワーキング] をクリックします。

4. [DNS プロバイダ] セクションで、[Cloud DNS] をクリックします。

5. [VPC スコープ] を選択します。

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

7. 必要に応じてクラスタを構成します。

8. [作成] をクリックします。

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

GKE Autopilot クラスタ

GKE Autopilot クラスタを kube-dns から Cloud DNS VPC スコープに移行することはできません。この機能は GKE Autopilot ではサポートされていません。

GKE Standard クラスタ

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

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

警告: kube-dns から VPC スコープへの移行は、中断が発生する操作です。移行後、クラスタ内のノードは、ノードが再作成されるまで、Cloud DNS を DNS プロバイダとして使用しません。kube-dns では、DNS クエリを以前のドメイン（デフォルトでは cluster.local）に解決できず、DNS エラーになります。ノードプール単位で VPC スコープへの移行は行えないため、メンテナンスの時間枠内にこの移行を行うことをおすすめします。

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

gcloud

1. 既存のクラスタを更新します。

   gcloud container clusters update CLUSTER_NAME \
       --cluster-dns=clouddns \
       --cluster-dns-scope=vpc \
       --cluster-dns-domain=CUSTOM_DOMAIN \
       --location=COMPUTE_LOCATION
   

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

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

   レスポンスは次の例のようになります。

   All the node-pools in the cluster need to be re-created by the user to start using Cloud DNS for DNS lookups. It is highly recommended to complete this step
   shortly after enabling Cloud DNS.
   Do you want to continue (Y/n)?
   

   確認後、Cloud DNS コントローラは GKE コントロール プレーンで動作するようになります。ノードプールをアップグレードするか、クラスタに新しいノードプールを追加するまで、Pod は DNS 解決に Cloud DNS を使用しません。

2. Cloud DNS を使用するようにクラスタ内のノードプールをアップグレードします。

   gcloud container clusters upgrade CLUSTER_NAME \
       --node-pool=POOL_NAME
   

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

   • CLUSTER_NAME: クラスタの名前。
   • POOL_NAME: アップグレードするノードプールの名前。

   ノードプールとコントロール プレーンが同じバージョンを実行している場合は、コントロール プレーンの手動アップグレードに従ってコントロール プレーンをアップグレードしてから、ノードプールをアップグレードしてください。

   注: 現在実行中のノードプールと同じバージョンにアップグレードしても、Pod に影響はありません。このようなノードプールでは、これらのノードで実行されている Pod は引き続き kube-dns を使用します。kube-dns のデプロイとオートスケーラーをゼロにスケーリングすると、こうした Pod で DNS 障害が発生します。Pod で Cloud DNS を使用するには、ノードプールを新しいバージョンにアップグレードする必要があります。他の方法としては、同じバージョンで新しいノードプールを作成することもできます。

   レスポンスを確認し、クラスタ内のノードプールごとにこのコマンドを繰り返します。クラスタにノードプールが 1 つしかない場合は、--node-pool フラグを省略します。

コンソール

1. Google Cloud コンソールで Google Kubernetes Engine のページに移動します。

   Google Kubernetes Engine に移動

2. 変更するクラスタの名前をクリックします。

3. [ネットワーキング] の [DNS プロバイダ] フィールドで、 [DNS プロバイダを編集] をクリックします。

4. [Cloud DNS] をクリックします。

5. [VPC スコープ] をクリックします。

6. [変更を保存] をクリックします。

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 クラスタ

警告: GKE Standard クラスタで Cloud DNS VPC スコープを無効にすることはできません。デフォルトの DNS プロバイダとして kube-dns を使用してクラスタを再作成する必要があります。

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

gcloud

kube-dns を使用するようにクラスタを更新します。

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

コンソール

1. Google Cloud コンソールで Google Kubernetes Engine のページに移動します。

   Google Kubernetes Engine に移動

2. 変更するクラスタの名前をクリックします。

3. [ネットワーキング] の [DNS プロバイダ] フィールドで、 [DNS プロバイダを編集] をクリックします。

4. [Kube-dns] をクリックします。

5. [変更を保存] をクリックします。

クリーンアップ

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

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 Console を使用して移行できます。

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

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

   Cloud DNS の [ゾーン] に移動

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

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

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

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

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

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

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

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

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

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

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

Cloud DNS は、stubDomains と upstreamNameservers の値を Cloud DNS 転送ゾーンに変換します。

注: カスタム DNS 構成はクラスタ内のノードと Pod の両方に適用されます。この動作は、カスタム DNS 構成が Pod にのみ適用される kube-dns とは異なります。

既知の問題

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,
    ]
  }

トラブルシューティング

DNS ロギングを有効にする方法については、限定公開マネージド ゾーンのロギングを有効または無効にするをご覧ください。

DNS の問題のトラブルシューティングの詳細については、GKE での DNS のトラブルシューティングをご覧ください。

既存のクラスタを更新できない、または Cloud DNS が有効なクラスタを作成できない

正しいバージョンを使用していることを確認してください。GKE 向け Cloud DNS では、VPC スコープを使用するクラスタの場合は GKE バージョン 1.19 以降、クラスタ スコープを使用するクラスタの場合は GKE バージョン 1.24.7-gke.800、1.25.3-gke.700 以降が必要です。

既存のクラスタで Cloud DNS が有効になっていても、Pod が kube-dns を使用している

クラスタで Cloud DNS を有効にした後、ノードプールがアップグレードまたは再作成されていることを確認します。この手順が完了するまで、Pod は引き続き kube-dns を使用します。

Pod が DNS ルックアップを解決できない

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

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

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

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

   nameserver 169.254.169.254
   

   出力が 10.x.y.10 または 34.118.224.10 のような IP アドレスの場合（バージョン 1.27 以降の GKE Autopilot クラスタのみ）、Pod は kube-dns を使用しています。出力が 169.254.20.10 の場合、Pod は NodeLocal DNSCache を使用しています。

2. マネージド ゾーンが存在し、必要な DNS エントリが含まれていることを確認します。

   gcloud dns managed-zones list --format list
   

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

    - creationTime: 2021-02-12T19:24:37.045Z
      description: Private zone for GKE cluster "cluster1" with cluster suffix "cluster.local" in project "project-243723"
      dnsName: cluster.local.
      id: 5887499284756055830
      kind: dns#managedZone
      name: gke-cluster1-aa94c1f9-dns
      nameServers: ['ns-gcp-private.googledomains.com.']
      privateVisibilityConfig: {'kind': 'dns#managedZonePrivateVisibilityConfig'}
      visibility: private
   

   レスポンスの name の値は、Google Cloud が gke-cluster1-aa94c1f9-dns という名前の限定公開ゾーンを作成したことを示しています。

3. Cloud DNS にクラスタのエントリが含まれていることを確認します。

   gcloud dns record-sets list --zone ZONE_NAME | grep SERVICE_NAME
   

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

   • ZONE_NAME: 限定公開ゾーンの名前。
   • SERVICE_NAME: サービスの名前。

   出力は、Cloud DNS にドメイン dns-test.default.svc.cluster.local. の A レコードとクラスタの IP アドレス（10.47.255.11）が含まれていることを示しています。

   dns-test.default.svc.cluster.local.                A     30     10.47.255.11
   

4. Cloud DNS ロギングを有効にしてクエリを追跡します。すべてのログエントリには、DNS レイテンシなど、クエリに関する情報が含まれています。

クラスタで Cloud DNS を有効にした後、ノードでの DNS ルックアップが失敗する

カスタム スタブドメインまたはアップストリーム ネームサーバーを持つ GKE クラスタでクラスタ スコープ Cloud DNS を有効にすると、Cloud DNS は Pod とノードの DNS リクエストを区別できないため、カスタム構成がクラスタ内のノードと Pod の両方に適用されます。カスタム アップストリーム サーバーがクエリを解決できない場合、ノードの DNS ルックアップが失敗する可能性があります。

次のステップ

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