GKE 向け Cloud DNS の使用

コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

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

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

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

VPC スコープ DNS は、Google Cloud CLI バージョン 364.0.0 以降では一般提供(GA)されており、それ以前のバージョンではプレビューです。GKE クラスタのスコープは、Google Cloud CLI バージョン 341.0.0 以降ではプレビューです。

概要

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 のオペレーション スイートと統合し、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 は、Service backend の IP アドレスの DNS リクエストを 169.254.169.254 にある Compute Engine ローカル メタデータ サーバーに送信します。このメタデータ サーバーはノードのローカルで実行され、キャッシュミスを Cloud DNS に送信します。

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

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

DNS スコープ

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

VPC スコープは、Google Cloud CLI バージョン 364.0.0 以降に対して一般提供されています。 クラスタのスコープはプレビュー版です。

  • 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 プロバイダである場合、GKE クラスタ内の Pod からの DNS クエリは、Cloud DNS の料金に応じて課金されます。GKE によって管理されるクラスタ スコープ DNS ゾーンへの DNS クエリは、プレビュー版では課金されませんが、一般提供(GA)では料金が発生します。

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

要件

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

  • 新規クラスタの場合は GKE バージョン 1.18 以降、既存のクラスタの場合は GKE バージョン 1.19 以降。
  • VPC スコープ DNS は、Google Cloud CLIバージョン 364.0.0 以降では一般提供されており、それ以前のバージョンではプレビューです。GKE クラスタのスコープは、Google Cloud CLI バージョン 341.0.0 以降ではプレビューです。

制限事項

GKE 向け Cloud DNS には次の制限があります。

  • GKE クラスタがクラスタ内のサービス名解決機能としてクラスタ スコープ DNS または VPC スコープ DNS で構成されている場合は、フリートに参加しないでください。参加すると、マルチクラスタ サービスの名前解決が正しく行われません。
  • Google Cloud 上の GKE クラスタでのみ使用できます。
  • GKE 向け Cloud DNS をクラスタで一度有効にすると、そのクラスタでは無効にできません。kube-dns はそのクラスタで動作し続けます。kube-dns Deployment とオートスケーラーをゼロにスケーリングすることで、kube-dns を無効にできます。
  • --cluster-dns-scope フラグでスコープを設定した後で、クラスタの DNS スコープを変更することはできません。
  • Cloud DNS はグローバルな依存関係を持つグローバル インフラストラクチャであり、DNS インフラストラクチャ全体がクラスタ内にローカルに存在する kube-dns などの DNS プロバイダとは異なります。
  • カスタム スタブドメインとアップストリーム DNS サーバー構成は、Pod とノードの DNS 構成に適用されます。ホスト ネットワーキングを使用する Pod またはホスト上で直接実行されるプロセスも、スタブドメインとアップストリーム ネームサーバー構成を使用します。
  • kube-dns Configmap で構成されたカスタム スタブドメインとアップストリーム ネームサーバーは、クラスタ スコープ DNS の Cloud DNS に自動的に適用されます。VPC スコープ DNS は kube-dns ConfigMap を無視するので、これらの構成を Cloud DNS で直接適用する必要があります。
  • VPC スコープの場合、Service のセカンダリ IP アドレス範囲は、そのサブネットワーク内の他のクラスタと共有しないでください。
  • VPC スコープの場合、PTR レコードに関連付けられたレスポンス ポリシーは VPC ネットワークに接続されます。クラスタ ネットワークにバインドされた他のレスポンス ポリシーがある場合、Kubernetes Service IP アドレスの PTR レコードの解決は失敗します。
  • Cloud DNS の割り当てと上限が適用され、プロジェクトの kube-dns の制限とは異なる場合があります。
  • Cloud DNS コントローラは、コントローラが再起動すると DNS ゾーンの DNS レコードに手動で行った変更を上書きします。

リソースの上限

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

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

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

始める前に

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

  • Google Kubernetes Engine API を有効にします。
  • Google Kubernetes Engine API を有効にする
  • このタスクに Google Cloud CLI を使用する場合は、gcloud CLI をインストールして初期化します。

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

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

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

GKE クラスタ内の Service を解決するさまざまなノード上の Pod
図: クラスタ スコープ DNS

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

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

gcloud beta container clusters create CLUSTER_NAME \
    --cluster-dns=clouddns \
    --cluster-dns-scope=cluster \
    --cluster-version=VERSION \
    --region=COMPUTE_REGION

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

  • CLUSTER_NAME: クラスタの名前。
  • VERSION: GKE バージョン。1.18 以降である必要があります。また、--release-channel フラグを使用してリリース チャンネルを選択することもできます。リリース チャンネルには、デフォルトのバージョン 1.18 以降が必要です。
  • COMPUTE_REGION: 新しいクラスタの Compute Engine のリージョン。ゾーンクラスタの場合は、--zone=COMPUTE_ZONE を使用します。

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

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

既存の GKE クラスタを kube-dns から Cloud DNS クラスタ スコープに移行できます。

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

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

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

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

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

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

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

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

    Enabling CloudDNS is a one-way operation. Once enabled, this
    configuration cannot be disabled. All the node pools in the cluster
    need to be re-created by the user to start using CloudDNS for DNS
    lookups. It is highly recommended to complete this step shortly after
    enabling CloudDNS.
    Do you want to continue (Y/n)?
    

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

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

    gcloud beta container clusters upgrade CLUSTER_NAME \
        --node-pool=POOL_NAME \
        --cluster-version=VERSION
    

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

    • CLUSTER_NAME: クラスタの名前。
    • POOL_NAME: アップグレードするノードプールの名前。
    • VERSION: GKE バージョン。1.18 以降である必要があります。また、--release-channel フラグを使用してリリース チャンネルを選択することもできます。リリース チャンネルには、デフォルトのバージョン 1.18 以降が必要です。

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

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

  3. ノード上の Pod に接続し、cat /etc/resolv.conf コマンドを実行して、ノードが 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 のような IP アドレスである場合、Pod は kube-dns を使用しています。出力が 169.254.20.10 の場合、Pod は NodeLocalDNS を使用しています。169.254.169.254 は、Cloud DNS データプレーンがポート 53 でリクエストをリッスンするメタデータ サーバーの IP アドレスです。ノードは kube-dns Service アドレスを DNS 解決に使用しなくなり、すべての 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 サーバー ポリシーを使用すると、接続されたネットワークのクライアントから Cloud DNS で名前を解決できます。クラスタが VPC スコープ DNS を使用している場合、これには GKE Service が含まれます。

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

gcloud CLI を使用して、新しいクラスタで VPC スコープ DNS を有効にできます。使用するコマンドは、Google Cloud CLI のバージョンによって異なります。

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

gcloud container clusters create CLUSTER_NAME \
    --cluster-dns=clouddns \
    --cluster-dns-scope=vpc \
    --cluster-version=VERSION \
    --cluster-dns-domain=CUSTOM_DOMAIN \
    --region=COMPUTE_REGION

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

  • CLUSTER_NAME: クラスタの名前。
  • VERSION: GKE バージョン。1.18 以降である必要があります。また、--release-channel フラグを使用してリリース チャンネルを選択することもできます。リリース チャンネルには、デフォルトのバージョン 1.18 以降が必要です。
  • COMPUTE_REGION: 新しいクラスタの Compute Engine のリージョン。ゾーンクラスタの場合は、--zone=COMPUTE_ZONE を使用します。
  • CUSTOM_DOMAIN: ドメインの名前。GKE はこの値を確認しないため、この名前は VPC 内で必ず一意になるようにしてください。この値は、設定後は変更できません。「.local」で終わるドメインは使用しないでください。そうしないと、DNS の解決に失敗する可能性があります。

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

既存の GKE クラスタを kube-dns から Cloud DNS VPC スコープに移行できます。

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

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

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

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

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

    gcloud container clusters update CLUSTER_NAME \
        --cluster-dns=clouddns \
        --cluster-dns-scope=vpc \
        --cluster-dns-domain=CUSTOM_DOMAIN \
        --region=COMPUTE_REGION
    

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

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

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

    Enabling CloudDNS is a one-way operation. Once enabled, this
    configuration cannot be disabled. All the node pools in the cluster
    need to be re-created by the user to start using CloudDNS for DNS
    lookups. It is highly recommended to complete this step shortly after
    enabling CloudDNS.
    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-version=VERSION
    

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

    • CLUSTER_NAME: クラスタの名前。
    • POOL_NAME: アップグレードするノードプールの名前。
    • VERSION: GKE バージョン。1.18 以降である必要があります。また、--release-channel フラグを使用してリリース チャンネルを選択することもできます。リリース チャンネルには、デフォルトのバージョン 1.18 以降が必要です。

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

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

  3. ノード上の Pod に接続し、cat /etc/resolv.conf コマンドを実行して、ノードが 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 のような IP アドレスである場合、Pod は kube-dns を使用しています。出力が 169.254.20.10 の場合、Pod は NodeLocal DNSCache を使用しています。 169.254.169.254 は、Cloud DNS データプレーンがポート 53 でリクエストをリッスンするメタデータ サーバーの IP アドレスです。ノードは kube-dns Service アドレスを DNS 解決に使用しなくなり、すべての DNS 解決がローカルノードで行われます。

Cloud DNS を確認する

GKE 向け Cloud DNS がクラスタで正しく動作していることを確認するには、次の手順を行います。

  1. 次のコマンドを使用して、サンプル アプリケーションをクラスタにデプロイします。

    kubectl run dns-test --image us-docker.pkg.dev/google-samples/containers/gke/hello-app:2.0
    
  2. 次のコマンドを使用して、サンプル アプリケーションをサービスとともに公開します。

    kubectl expose pod dns-test --name dns-test-svc --port 8080
    
  3. 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 です。

サービス名を解決する

kubectl exec を使用して Pod に接続し、nslookup コマンドを使用してサービス名を解決して、Cloud DNS がクラスタ内の DNS レコードを処理していることを確認します。

クラスタのスコープ

kubectl exec -it dns-test -- nslookup dns-test-svc

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

Server:   169.254.169.254
Address:  169.254.169.254#53

Non-authoritative answer:
Name: dns-test-svc.default.svc.cluster.local
Address: 10.47.255.11

このレスポンスは、Cloud DNS がサービス名 dns-test-svc をクラスタの仮想 IP(10.47.255.11)に解決したことを示しています。

VPC スコープ

kubectl exec -it dns-test -- nslookup dns-test-svc

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

Server:   169.254.169.254
Address:  169.254.169.254#53

Non-authoritative answer:
Name: dns-test-svc.default.svc.cluster1
Address: 10.47.255.11

このレスポンスは、Cloud DNS がサービス名 dns-test-svc をクラスタの仮想 IP(10.47.255.11)に解決したことを示しています。

クリーンアップ

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

  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 クラスタ スコープでのみ使用できます。

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

トラブルシューティング

Kubernetes DNS の問題の診断に関する一般的な情報については、DNS 解決のデバッグをご覧ください。また、Cloud DNS の問題の診断について詳しくは、トラブルシューティングをご覧ください。

Cloud DNS ロギングを有効にすることもできます。

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

正しいバージョンを使用していることを確認してください。GKE 向け Cloud DNS の使用に必要なバージョンは、新しいクラスタの作成には GKE バージョン 1.18 以降、既存のクラスタには GKE バージョン 1.19 以降です。

既存のクラスタで 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 のような IP アドレスである場合、Pod は kube-dns を使用しています。出力が 169.254.20.10 の場合、Pod は NodeLocalDNS を使用しています。

  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 ルックアップが失敗する可能性があります。

次のステップ