Container Service for Kubernetes:DNS トラブルシューティング

使用方法に関する注意事項

Kubernetes は動的で多層的なネットワークアーキテクチャを使用しているため、Kubernetes における DNS トラブルシューティングは複雑です。CoreDNS エラーと NodeLocal DNSCache エラーに加えて、以下の問題が DNS 解決の失敗につながる可能性があります。

• ネットワークアーキテクチャのワークロード

  Kubernetes の DNS 解決パイプラインには、CoreDNS(kube-dns)、kube-proxy、Container Network Interface (CNI) などの複数のモジュール、コンポーネント、またはプラグインが関係しています。いずれかのモジュールでエラーが発生すると、DNS 解決が失敗する可能性があります。この場合、各モジュールを診断して、DNS 解決の失敗の原因を特定する必要があります。Kubernetes の DNS 解決パイプラインの診断方法の詳細については、「DNS 解決パイプラインの他のモジュールを診断する」をご参照ください。

• 特定のサービス検出メカニズムと名前空間

  • 完全修飾ドメイン名 (FQDN) の依存関係: 名前空間をまたがってサービスにアクセスする場合は、service.namespace.svc.cluster.local などの完全ドメイン名を使用する必要があります。使用するドメイン名に名前空間が含まれていない場合、DNS ルックアップは現在の名前空間内でのみ実行されます。この場合、サービスへのアクセスは失敗しますが、エラーは報告されません。

  • ヘッドレスサービス: ヘッドレスサービスにアクセスすると、ポッドの IP アドレスが返されます。構成が不適切だと、DNS レコードが見つからない場合があります。

• ネットワークポリシーの制限

  • Kubernetes ネットワークポリシーの拒否ルール: ポッドの Kubernetes ネットワークポリシーで、デフォルトの UDP ポート 53 や TCP ポートなどの DNS ポート経由のアクセスが許可されていない場合、ポッドは CoreDNS と通信できません。

  • Virtual Private Cloud (VPC) セキュリティグループによる干渉: ホストファイアウォールルールまたはセキュリティグループルール、特に VPC セキュリティグループルールが原因で、DNS パケットがドロップされる場合があります。

  • トラブルシューティング: kube-system 名前空間の CoreDNS ポッドのネットワーク接続を診断します。

• デバッグツールとログの制限

  • ツールが見つからない: 使用するコンテナイメージに dig または nslookup デバッグツールが含まれていない場合は、クラスタに一時的なデバッグコンテナを起動する必要があります。

  • ログの分散: CoreDNS からログを収集するには、CoreDNS のログプラグインを手動でインストールして、CoreDNS のデバッグモードを有効にする必要があります。CoreDNS のログは、複数のポッドレプリカに分散されています。

  • デバッグ: 一時的なデバッグポッドを使用して DNS 解決をすばやくテストします。

    kubectl run -it --rm debug --image=nicolaka/netshoot -- dig

    次のコマンドを実行することもできます。

    nslookup  <Domain name>

基本用語

• 内部ドメイン名: CoreDNS がサービスを公開するために使用するドメイン名。 内部ドメイン名は .cluster.local で終わります。 内部ドメイン名に対する DNS クエリは、アップストリーム DNS サーバーではなく、CoreDNS の DNS キャッシュに基づいて解決されます。

• 外部ドメイン名: サードパーティ DNS サービスプロバイダー、Alibaba Cloud DNS、または Alibaba Cloud DNS PrivateZone によって提供される権威 DNS サーバーによって解決されるドメイン名。 クラスタ外部ドメイン名は、CoreDNS のアップストリーム DNS サーバーによって解決されます。 CoreDNS は DNS クエリをアップストリーム DNS サーバーに転送するだけです。

• アプリケーションポッド: Kubernetes クラスタ内のシステムコンポーネントのポッド以外のポッド。

• DNS 解決に Coredns を使用するアプリケーションポッド: CoreDNS を使用して DNS クエリを処理するアプリケーションポッド。

• DNS 解決に Nodelocal Dnscache を使用するアプリケーションポッド: DNSConfig が挿入されるアプリケーションポッド。 クラスタに NodeLocal DNSCache をインストールした後、DNSConfig をアプリケーションポッドに挿入することで DNS 設定を構成できます。 このようにして、これらのポッドの DNS クエリは最初に NodeLocal DNSCache に送信されます。 NodeLocal DNSCache がクエリの処理に失敗した場合、クエリは CoreDNS の kube-dns サービスに送信されます。

CoreDNS と NodeLocal DNSCache のトラブルシューティング手順

1. 例外の原因を特定します。 詳細については、「一般的なエラーメッセージ」をご参照ください。

   • エラーメッセージにドメイン名が しないことが示されている場合は、「トラブルシューティング」セクションの ドメイン名を確認する を参照してください。トラブルシューティング

   • エラーメッセージに DNS サーバーへの接続を確立できないことが示されている場合は、「トラブルシューティング」セクションの エラーの頻度を確認する を参照してください。トラブルシューティング

2. 問題が解決しない場合は、次の手順を実行します。

   • アプリケーションポッドの DNS 構成で CoreDNS が指定されているかどうかを確認します。 詳細については、「アプリケーションポッドの DNS 構成を診断する」をご参照ください。

     • DNS 構成で CoreDNS が指定されていない場合、クライアントがフルロードで実行されているか、conntrack テーブルがいっぱいになっている可能性があります。 詳細については、「クライアントの過負荷が原因で DNS 解決が失敗した場合はどうすればよいですか?」および「conntrack テーブルがいっぱいになっている場合はどうすればよいですか?」をご参照ください。

     • DNS 構成で CoreDNS が指定されている場合は、次の手順を実行します。

       1. CoreDNS ポッドのステータスを確認します。 詳細については、「CoreDNS ポッドのステータスを診断する」および「CoreDNS ポッドが予期したとおりに実行されない場合はどうすればよいですか?」をご参照ください。

       2. CoreDNS ポッドの操作ログを確認します。 詳細については、「CoreDNS の操作ログを診断する」および「クラスタの外部ドメイン名を解決できない場合はどうすればよいですか?」をご参照ください。

       3. 問題が安定して再現できるかどうかを確認します。

          1. エラーが安定して再現できる場合は、「CoreDNS の DNS クエリログを診断する」および「アプリケーションポッドと CoreDNS ポッド間のネットワーク接続を診断する」をご参照ください。

          2. 問題が安定して再現できない場合は、「パケットをキャプチャする」をご参照ください。

   • DNS 構成で NodeLocal DNSCache が指定されている場合は、「NodeLocal DNSCache が機能しない場合はどうすればよいですか?」および「Alibaba Cloud DNS PrivateZone に追加されたドメイン名を解決できない場合はどうすればよいですか?」をご参照ください。

3. 問題が解決しない場合は、チケットの送信 してください。

一般的なエラーメッセージ

DNS 解決パイプラインの他のモジュールを診断する

次の図は、DNS 解決パイプラインを示しています。 CoreDNS エラーと NodeLocal DNSCache エラーに加えて、次のモジュールの問題が DNS 解決の失敗につながる可能性があります。

• DNS リゾルバー: Go などのプログラミング言語や glibc や musl などのライブラリにおける DNS 解決の実装には、まれに DNS 解決の失敗につながる脆弱性が含まれている場合があります。

• /etc/resolv.conf ファイル: コンテナ内の DNS 構成ファイルには、DNS サーバーの IP アドレスと検索ドメインが含まれています。 このファイルの構成が不適切だと、DNS 解決が失敗する可能性があります。

• kube-proxy: kube-proxy は IP Virtual Server (IPVS) モードまたは iptables モードでリクエストをルーティングします。 CoreDNS を更新するときに更新しないと、CoreDNS にアクセスできなくなり、まれに DNS 解決が失敗する可能性があります。

• アップストリーム DNS サーバー: CoreDNS は内部ドメイン名のみを解決します。 CoreDNS が clusterDomain パラメーターと一致しないドメイン名に対する解決リクエストを受信すると、CoreDNS はアップストリーム DNS サーバー (例: VPC プライベート DNS) に DNS クエリを送信します。 アップストリーム DNS サーバーが正しく構成されていない場合、解決は失敗します。

アプリケーションポッドの DNS 構成を診断する

• コマンド

  # 次のコマンドを実行して、foo ポッドの YAML ファイルをクエリします。 次に、YAML ファイルの dnsPolicy フィールドが適切な値に設定されているかどうかを確認します。
  kubectl get pod foo -o yaml
  
  # dnsPolicy フィールドが適切な値に設定されている場合は、ポッドの DNS 構成ファイルを確認します。
  
  # 次のコマンドを実行して、bash を使用して foo ポッドのコンテナにログインします。 bash が しない場合は、sh を使用します。
  kubectl exec -it foo bash
  
  # 次のコマンドを実行して、DNS 構成ファイルをクエリします。 次に、nameserver フィールドの DNS サーバーアドレスを確認します。
  cat /etc/resolv.conf

• DNS ポリシー設定

  次のサンプルコードは、DNS ポリシー設定で構成されたポッドテンプレートを示しています。

  apiVersion: v1
  kind: Pod
  metadata:
    name: <pod-name>
    namespace: <pod-namespace>
  spec:
    containers:
    - image: <container-image>
      name: <container-name>
  
  # dnsPolicy フィールドのデフォルト値は ClusterFirst です。
    dnsPolicy: ClusterFirst
  # 次のコードは、NodeLocal DNSCache が使用されている場合に適用される DNS ポリシー設定を示しています。
    dnsPolicy: None
    dnsConfig:
      nameservers:
      - 169.254.20.10
      - 172.21.0.10
      options:
      - name: ndots
        value: "3"
      - name: timeout
        value: "1"
      - name: attempts
        value: "2"
      searches:
      - default.svc.cluster.local
      - svc.cluster.local
      - cluster.local
  
    securityContext: {}
    serviceAccount: default
    serviceAccountName: default
    terminationGracePeriodSeconds: 30

  dnsPolicy の値	説明
  Default	クラスタ内からの内部アクセスが必要ない場合は、この値を使用できます。 ポッドは、Elastic Compute Service (ECS) インスタンスの /etc/resolv.conf ファイルで指定された DNS サーバーを使用します。
  ClusterFirst	これがデフォルト値です。 kube-dns サービスの IP アドレスは、ポッドが使用する DNS サーバーのアドレスとして使用されます。 ホストネットワークを使用するポッドの場合、ClusterFirst の値は Default の値と同じ効果があります。
  ClusterFirstWithHostNet	ホストネットワークを使用するポッドの場合、ClusterFirstWithHostNet の値は ClusterFirst の値と同じ効果があります。
  None	この値を使用すると、dnsConfig セクションで自己管理型 DNS サーバーとカスタムパラメーターを構成できます。 NodeLocal DNSCache の dnsConfig の自動挿入を有効にすると、ローカル DNS キャッシュの IP アドレスと kube-dns サービスの IP アドレスが DNS サーバーのアドレスとして指定されます。

CoreDNS ポッドのステータスを診断する

CoreDNS の操作ログを診断する

コマンド

kubectl -n kube-system logs -f --tail=500 --timestamps coredns-xxxxxxxxx-xxxxx

CoreDNS の DNS クエリログを診断する

コマンド

CoreDNS の DNS クエリログは、CoreDNS のログプラグインが有効になっている場合にのみ生成されます。 ログプラグインを有効にする方法の詳細については、「CoreDNS を構成する」をご参照ください。

CoreDNS の操作ログをクエリするために使用するコマンドを実行します。 詳細については、「CoreDNS の操作ログを診断する」をご参照ください。

CoreDNS ポッドのネットワーク接続を診断する

コンソールまたは CLI を使用して、CoreDNS ポッドのネットワーク接続を診断できます。

FAQ

アプリケーションポッドと CoreDNS ポッド間のネットワーク接続を診断する

コンソールまたは CLI を使用して、アプリケーションポッドと CoreDNS ポッド間のネットワーク接続を診断できます。

FAQ

パケットをキャプチャする

問題を特定できない場合は、パケットをキャプチャして診断します。

1. アプリケーションポッドと CoreDNS ポッドが実行されているノードにログインします。

2. 各 ECS インスタンスで次のコマンドを実行して、ポート 53 で受信したすべてのパケットをキャプチャします。

   tcpdump -i any port 53 -C 20 -W 200 -w /tmp/client_dns.pcap

3. エラーが発生した期間中に転送されたパケットを診断します。

   説明

   • パケットキャプチャはサービスに影響を与えず、CPU 使用率とディスク I/O がわずかに増加するだけです。

   • 上記のコマンドは、キャプチャされたパケットをローテーションし、最大 200 個の .pcap ファイルを生成できます。各ファイルのサイズは 20 MB です。

症状

クラスタの内部ドメイン名は解決できますが、外部ドメイン名は解決できません。

原因

外部ドメイン名を解決するときに、アップストリーム DNS サーバーでエラーが発生しました。

解決策

CoreDNS の DNS クエリログを確認します。

一般的な DNS クエリログ

# レスポンスコードが NOERROR の場合、ドメイン名はエラーなしで解決されます。
[INFO] 172.20.2.25:44525 - 36259 "A IN redis-master.default.svc.cluster.local. udp 56 false 512" NOERROR qr,aa,rd 110 0.000116946s

一般的なレスポンスコード

症状

CoreDNS がヘッドレスサービスのドメイン名を解決できません。

原因

1.7.0 より前の CoreDNS バージョンを使用している場合、クラスタの Kubernetes API サーバーでネットワークジッターが発生すると、CoreDNS が予期せず終了する可能性があります。 その結果、CoreDNS がダウンしているときにヘッドレスサービスのドメイン名が更新されません。

解決策

CoreDNS を 1.7.0 以降に更新します。 詳細については、「[コンポーネントの更新] CoreDNS を更新する」をご参照ください。

問題の説明

dig コマンドを使用すると、レスポンスに tc フラグが表示されます。これは、レスポンスが大きすぎることを示しています。

原因

ヘッドレスドメイン名に対応する IP アドレスの数が多すぎると、クライアントが UDP 経由で送信した DNS クエリが UDP DNS パケットのサイズ制限を超える可能性があります。 これにより、解決が失敗します。

解決策

解決の失敗を回避するには、クライアントアプリケーションが TCP 経由で DNS クエリを送信するように構成します。 CoreDNS は TCP と UDP の両方をサポートしています。 ビジネスシナリオに応じてプロトコルを変更できます。

• glibc 関連のリゾルバーを使用します。

  クライアントアプリケーションが glibc 関連のリゾルバーを使用している場合は、use-vc 構成を dnsConfig に追加できます。 これにより、クライアントアプリケーションは TCP 経由で DNS クエリを送信します。 これらの設定は、/etc/resolv.conf ファイルの対応する options 構成にマッピングされます。 options の詳細については、「Linux man ページ」をご参照ください。

  dnsConfig:
    options:
    - name: use-vc

• Golang によって実装されたビジネスコードロジック

  Golang を使用して開発する場合は、次のコードを参照して TCP 経由で DNS クエリを送信できます。

  package main
  
  import (
  	"fmt"
  	"net"
  	"context"
  )
  
  func main() {
  	resolver := &net.Resolver{
  		PreferGo: true,
  		Dial: func(ctx context.Context, network, address string) (net.Conn, error) {
  			return net.Dial("tcp", address)
  		},
  	}
  
  	addrs, err := resolver.LookupHost(context.TODO(), "example.com")
  	if err != nil {
  		fmt.Println("Error:", err)
  		return
  	}
  	fmt.Println("Addresses:", addrs)
  }

症状

Kubernetes 1.20 以降と CoreDNS 1.8.4 以降を使用している場合、etcd、Nacos、Kafka などのオープンソースコンポーネントの以前のバージョンは予期したとおりに動作しません。

原因

CoreDNS 1.8.4 以降では、EndpointSlice API を使用して、クラスタ内のサービスの IP アドレスを同期することが優先されます。 一部のオープンソースコンポーネントは、初期化フェーズで Endpoint API によって提供される service.alpha.kubernetes.io/tolerate-unready-endpoints アノテーションを使用して、準備ができていないサービスを公開します。 このアノテーションは EndpointSlice API では非推奨となり、publishNotReadyAddresses に置き換えられました。 したがって、CoreDNS を更新した後は、準備ができていないサービスをリリースできません。 その結果、オープンソースコンポーネントはサービス検出を実行できません。

解決策

オープンソースコンポーネントの YAML ファイルまたは Helm Chart ファイルに service.alpha.kubernetes.io/tolerate-unready-endpoints アノテーションが含まれているかどうかを確認します。 オープンソースコンポーネントにアノテーションが含まれている場合、オープンソースコンポーネントが予期したとおりに動作しない可能性があります。 この場合は、オープンソースコンポーネントをアップグレードするか、オープンソースコンポーネントコミュニティに相談する必要があります。

症状

StatefulSet ポッドのドメイン名を解決できません。

原因

StatefulSet がヘッドレスサービスを使用して公開されている場合、ポッド YAML テンプレートの ServiceName パラメーターをヘッドレスサービスの名前に設定する必要があります。 そうしないと、pod.headless-svc.ns.svc.cluster.local などの StatefulSet ポッドのドメイン名にアクセスできません。 ただし、headless-svc.ns.svc.cluster.local などのヘッドレスサービスのドメイン名にはアクセスできます。

解決策

ポッド YAML テンプレートの ServiceName パラメーターを、StatefulSet ポッドの公開に使用されるヘッドレスサービスの名前に設定します。

症状

CoreDNS の DNS 解決の失敗が、一部またはすべてのノードで発生し続けます。

原因

ECS インスタンスのネットワーク通信を制御するセキュリティグループルールまたはネットワークアクセス制御リスト (ACL) が UDP ポート 53 をブロックしています。

解決策

セキュリティグループルールまたはネットワーク ACL を変更して、UDP ポート 53 を開きます。

症状

CoreDNS の DNS 解決の失敗が、一部またはすべてのノードで発生し続けます。

原因

コンテナネットワーク接続エラーまたはその他の原因により、UDP ポート 53 がブロックされています。

解決策

ネットワーク診断 機能を使用して、アプリケーションポッドと CoreDNS ポッド間のネットワーク接続を診断できます。 問題が解決しない場合は、チケットの送信 してください。

症状

• CoreDNS の DNS 解決のレイテンシが高い、または CoreDNS の DNS 解決の失敗が一部またはすべてのノードで発生し続ける、または断続的に発生します。

• CoreDNS ポッドのステータスを確認し、CPU とメモリの使用量が上限に達しようとしているかどうかを確認します。

原因

CoreDNS に構成されている複製ポッドの数が、DNS クエリを処理するには不十分です。

解決策

• NodeLocal DNSCache を使用して DNS 解決の効率を向上させ、CoreDNS の負荷を軽減します。 詳細については、「NodeLocal DNSCache を構成する」をご参照ください。

• 各ポッドのピーク CPU 使用率がノードのアイドル CPU リソースの量よりも少なくなるように、CoreDNS ポッドをスケールアウトします。

症状

• CoreDNS の DNS 解決のレイテンシが高い、または CoreDNS の DNS 解決の失敗が一部のノードで発生し続ける、または断続的に発生します。

• CoreDNS ポッドのステータスは、ポッド間で CPU 使用率が異なることを示しています。

• CoreDNS に構成されている複製ポッドの数が 2 未満であるか、複数の CoreDNS ポッドが同じノードにデプロイされています。

原因

ポッドのスケジューリングの不均衡または kube-dns サービスの SessionAffinity 設定が不適切なため、DNS クエリが CoreDNS ポッド間で均等に分散されていません。

解決策

• CoreDNS ポッドをスケールアウトし、ポッドを異なるノードにスケジュールします。

• kube-dns サービスの構成から SessionAffinity パラメーターを削除できます。 詳細については、「ACK を構成して CoreDNS を自動的に更新する」をご参照ください。

症状

• CoreDNS の DNS 解決のレイテンシが高い、または CoreDNS の DNS 解決の失敗が一部のノードで発生し続ける、または断続的に発生します。

• CoreDNS ポッドが Running 状態ではない、またはポッドの再起動回数が継続的に増加しています。

• CoreDNS ログデータは、エラーが発生したことを示しています。

原因

YAML ファイルまたは CoreDNS ConfigMap の設定が不適切なため、CoreDNS ポッドが予期したとおりに実行されていません。

解決策

CoreDNS ポッドのステータスと操作ログを確認します。

一般的なエラーログと解決策

症状

DNS 解決エラーが断続的に、またはピーク時に発生します。 ECS インスタンスに関する監視情報は、ネットワークインターフェースコントローラー (NIC) の異常な再送率と異常な CPU 使用率を示しています。

原因

CoreDNS に DNS クエリを送信するポッドをホストする ECS インスタンスがフルロードになっているため、UDP パケット損失が発生しています。

解決策

• チケットの送信 して問題のトラブルシューティングを行うことをお勧めします。

• NodeLocal DNSCache を使用して DNS 解決の効率を向上させ、CoreDNS の負荷を軽減します。 詳細については、「NodeLocal DNSCache を構成する」をご参照ください。

症状

• ピーク時に一部またはすべてのノードで CoreDNS がドメイン名を解決できないことがよくありますが、ピーク時以外は予期したとおりにドメイン名を解決できます。

• インスタンスで dmesg -H コマンドを実行し、解決が失敗した期間中に生成されたログを確認します。 ログにはキーワード conntrack full が含まれています。

原因

Linux カーネルの conntrack テーブルがいっぱいです。 その結果、UDP または TCP 経由で送信されたリクエストを処理できません。

解決策

Linux カーネルの conntrack テーブルのエントリの最大数を増やします。 詳細については、「Linux カーネルの conntrack テーブルで追跡される接続の最大数を増やすにはどうすればよいですか?」をご参照ください。

症状

• 外部ドメイン名が断続的に解決に失敗するか、断続的に間違った IP アドレスに解決されます。 ただし、内部ドメイン名は正常に解決されます。

• クラスタが高頻度でコンテナを作成すると、内部ドメイン名が間違った IP アドレスに解決されます。

原因

CoreDNS の不具合により、autopath プラグインが予期したとおりに動作していません。

解決策

症状

• CoreDNS の DNS 解決が断続的に失敗します。

• キャプチャされたパケットまたは CoreDNS への DNS クエリのログは、A レコードと AAAA レコードのクエリが同じポートで同時に開始されたことを示しています。

原因

• A レコードと AAAA レコードの同時 DNS クエリにより、Linux カーネルの conntrack テーブルでエラーが発生し、UDP パケット損失が発生します。

• 2.33 より前の libc バージョンは、ARM マシンで A レコードと AAAA レコードのクエリを同時に開始します。 その結果、クエリがタイムアウトし、再起動されます。 詳細については、「GLIBC#26600」をご参照ください。

解決策

• NodeLocal DNSCache を使用して DNS 解決の効率を向上させ、CoreDNS の負荷を軽減します。 詳細については、「NodeLocal DNSCache を構成する」をご参照ください。

• CentOS や Ubuntu イメージなど、libc を使用するイメージの場合は、libc のバージョンを 2.33 以降に更新して、A レコードと AAAA レコードのクエリが同時に開始される問題を防ぎます。

• options timeout:2 attempts:3 rotate single-request-reopen などのパラメーターを設定することで、CentOS および Ubuntu イメージを最適化できます。

• 使用しているイメージが Alpine Linux に基づいている場合は、イメージを別のオペレーティングシステムに基づくイメージに置き換えることをお勧めします。 詳細については、「Alpine」をご参照ください。

• PHP で記述されたアプリケーションが短命接続を使用して DNS クエリを送信すると、さまざまな解決エラーが発生する可能性があります。 PHP cURL を使用する場合は、CURL_IPRESOLVE_V4 を追加して、ドメイン名を IPv4 アドレスのみに解決できるように指定する必要があります。 詳細については、「cURL_setopt」をご参照ください。

症状

クラスタへのノードの追加または削除、ノードのシャットダウン、または CoreDNS のスケールイン時に、DNS 解決が断続的に失敗します。 ほとんどの場合、この状況は約 5 分間続きます。

原因

クラスタの kube-proxy のロードバランシングモードが IPVS に設定されています。 カーネルバージョンが 4.19.91-25.1.al7.x86_64 より前の CentOS または Alibaba Cloud Linux 2 を実行しているノードから IPVS UDP バックエンドポッドを削除すると、UDP パケットの送信時に送信元ポートの競合が発生します。 その結果、UDP パケットがドロップされます。

解決策

• NodeLocal DNSCache を使用して、IPVS モードでのパケット損失を減らします。 詳細については、「NodeLocal DNSCache を構成する」をご参照ください。

• IPVS モードでの UDP セッションのタイムアウト期間を短縮します。 詳細については、「IPVS モードでの UDP タイムアウト期間を変更する」をご参照ください。

症状

すべての DNS クエリが NodeLocal DNSCache ではなく CoreDNS に送信されます。

原因

• DNSConfig がアプリケーションポッドに挿入されていません。 kube-dns サービスの IP アドレスが、アプリケーションポッドの DNS サーバーのアドレスとして構成されています。

• アプリケーションポッドが Alpine Linux に基づくイメージを使用してデプロイされています。 その結果、DNS クエリは、ローカル DNS キャッシュと CoreDNS ポッドを含むすべてのネームサーバーに同時に送信されます。

解決策

• DNSConfig の自動挿入を構成します。 詳細については、「NodeLocal DNSCache を構成する」をご参照ください。

• 使用しているイメージが Alpine Linux に基づいている場合は、イメージを別のオペレーティングシステムに基づくイメージに置き換えることをお勧めします。 詳細については、「Alpine」をご参照ください。

症状

NodeLocal DNSCache を使用しているときに、Alibaba Cloud DNS PrivateZone に追加されたドメイン名を解決できない、vpc-proxy を含む Alibaba Cloud サービス API のエンドポイントを解決できない、またはドメイン名が間違った IP アドレスに解決されます。

原因

Alibaba Cloud DNS PrivateZone は TCP をサポートしていません。 UDP を使用する必要があります。

解決策

prefer_udp 構成を CoreDNS に追加します。 詳細については、「CoreDNS を構成する」をご参照ください。