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

アーキテクチャ

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

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

Pod が Cloud DNS を使用して Service の IP アドレスをリクエストする
図: クラスタ名の解決

この図で、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 スコープの違いを示します。

機能 GKE クラスタ スコープ Cloud DNS の追加の VPC スコープ VPC スコープ
DNS の公開設定の範囲 GKE クラスタ内のみ VPC ネットワーク全体に及ぶ VPC ネットワーク全体
ヘッドレス サービスの解決策 クラスタ内で解決可能 「cluster.local」を使用してクラスタ内で、クラスタのサフィックスを使用して VPC 全体で解決可能 クラスタのサフィックスを使用して、クラスタ内と VPC 全体で解決可能
固有のドメインの要件 いいえ。デフォルトの「*.cluster.local」を使用します はい、一意のカスタム ドメインを設定する必要があります はい、一意のカスタム ドメインを設定する必要があります
設定の構成 デフォルト。追加の手順はありません クラスタ作成時には省略可
いつでも有効または無効にできます		 クラスタの作成時に構成する必要があります

Cloud DNS リソース

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

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

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

スコープ 前方参照ゾーン 逆引き参照ゾーン
クラスタのスコープ gke-CLUSTER_NAME-CLUSTER_HASH-dns gke-CLUSTER_NAME-CLUSTER_HASH-rp
Cloud DNS の追加の VPC スコープ クラスタ スコープのゾーンの場合は gke-CLUSTER_NAME-CLUSTER_HASH-dns
VPC スコープのゾーンの場合は gke-CLUSTER_NAME-CLUSTER_HASH-dns-vpc		 クラスタ スコープのゾーンの場合は gke-CLUSTER_NAME-CLUSTER_HASH-rp
クラスタ スコープのゾーンの場合は gke-NETWORK_NAME_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 料金に応じて課金されます。

要件

プロジェクトで 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 以降。
  • Google Cloud CLI バージョン 471.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 スコープを使用する必要があります。
  • Cloud DNS は、影響レベル 4（IL4）のコンプライアンス体制に準拠していません。GKE 向け Cloud DNS は、IL4 コンプライアンス体制がある Assured Workloads では使用できません。このような規制された環境では kube-dns を使用する必要があります。GKE Autopilot クラスタの場合、kube-dns または Cloud DNS の選択はコンプライアンス体制に基づいて自動的に行われます。
  • 限定公開マネージド DNS ゾーンに対する手動変更はサポートされておらず、Cloud DNS コントローラによって上書きされます。これらのゾーンの 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 のレコードセットやレコードを作成しません。

割り当て

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

リソースの上限

次の表に示すように、クラスタごとに作成する 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 を実行して最新のバージョンを取得する。

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

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

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

GKE クラスタ内の Service を解決するさまざまなノード上の 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

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

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

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

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

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

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

    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

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

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

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

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

コンソール

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

    Google Kubernetes Engine に移動

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

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

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

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

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

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-scope=cluster \
    --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 \
    --enable-additive-vpc-scope \
    --additive-vpc-scope-dns-domain=UNIQUE_CLUSTER_DOMAIN

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

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

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 クラスタの外部からヘッドレス Service に解決するクライアント
図: VPC スコープ DNS

また、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 解決を行います。

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: アップグレードするノードプールの名前。

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

    レスポンスを確認し、クラスタ内のノードプールごとにこのコマンドを繰り返します。クラスタにノードプールが 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 クラスタ

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. [保存] をクリックします。

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 スコープを使用するクラスタがすでにある場合は、次の手順でそれらのクラスタを手動で移行する必要があります。

レスポンス ポリシーは、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 Standard クラスタでのみ利用できます。

Cloud DNS は、stubDomains と upstreamNameservers の値を Cloud 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 ルックアップが失敗する可能性があります。

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

正しいバージョンを使用していることを確認してください。Cloud DNS の追加の VPC スコープには、GKE バージョン 1.28 以降が必要です。

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

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

    gke-cluster-1-cbdc0678-dns  cluster.local.   Private zone for GKE cluster "cluster-1" with cluster suffix "cluster.local." in project "PROJECT_NAME" with scope "CLUSTER_SCOPE"  private
gke-cluster-1-cbdc-dns-vpc  CLUSTER_DOMAIN.  Private zone for GKE cluster "cluster-1" with cluster suffix "CLUSTER_DOMAIN." in project "PROJECT_NAME" with scope "VPC_SCOPE"     private

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

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

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

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

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

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

    my-service.default.svc.cluster.local.                A     30     10.47.255.11

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

  4. リバース DNS ルックアップの場合、Cloud DNS に ResponsePolicies 内のクラスタのエントリが含まれていることを確認します。

    gcloud dns response-policies list --format="table(responsePolicyName, description)"

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

      gke-NETWORK_HASH-rp        Response Policy for GKE clusters on network "VPC_NAME".
  gke-cluster-1-52c8f518-rp  Response Policy for GKE cluster "cluster-1" with cluster suffix "cluster.local." in project "khamed-gke-dev" with scope "CLUSTER_SCOPE".

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

  5. リバース DNS ルックアップの場合、Cloud DNS に ResponsePolicies 内のクラスタのエントリが含まれていることを確認します。

      gcloud dns response-policies rules list ZONE_NAME --format="table(localData.localDatas[0].name, localData.localDatas[0].rrdatas[0])"

    ZONE_NAME は、限定公開ゾーンの名前に置き換えます。

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

      1.240.27.10.in-addr.arpa.    kubernetes.default.svc.cluster.local.
  52.252.27.10.in-addr.arpa.   default-http-backend.kube-system.svc.cluster.local.
  10.240.27.10.in-addr.arpa.   kube-dns.kube-system.svc.cluster.local.
  146.250.27.10.in-addr.arpa.  metrics-server.kube-system.svc.cluster.local.

次のステップ