Container Service for Kubernetes:DNS 名前解決エラーのトラブルシューティング

アプリケーション Pod と CoreDNS 間のネットワーク接続性のテスト

次のいずれかの方法を使用して、アプリケーション Pod のネットワーク名前空間に入ります。

• 方法 1 (推奨)：kubectl exec -it <pod-name> -- bash を実行して Pod に入ります。

• 方法 2：ノードにログインし、ps aux | grep <application-process-name> でプロセス ID を見つけてから、nsenter -t <pid> -n bash でネットワーク名前空間に入ります。

• 方法 3 (頻繁に再起動する Pod の場合)：

  1. ノードにログインします。

  2. docker ps -a | grep <application-container-name> を実行してサンドボックスコンテナ ID (名前が k8s_POD_ で始まる) を見つけます。

  3. docker inspect <sandboxed-container-ID> | grep netns を実行して /var/run/docker/netns/xxxx 内のネットワーク名前空間パスを見つけます。

  4. nsenter -n<netns-path> bash</netns-path> を実行して名前空間に入ります。> 注意：-n と <netns-path> の間にスペースを追加しないでください。

Pod のネットワーク名前空間から、接続性をテストします。

# kube-dns サービスへの接続性をテスト
dig <domain> @<kube-dns-svc-ip>

# CoreDNS Pod へのインターネット制御メッセージプロトコル (ICMP) 接続性をテスト
ping <coredns-pod-ip>

# CoreDNS Pod への DNS クエリを直接テスト
dig <domain> @<coredns-pod-ip>

<kube-dns-svc-ip> を kube-system 名前空間の kube-dns サービス IP に、<coredns-pod-ip> を CoreDNS Pod の IP に置き換えます。

CoreDNS のネットワーク接続性のテスト

1. CoreDNS Pod が実行されているノードにログインします。

2. ps aux | grep coredns を実行して CoreDNS プロセス ID を取得します。

3. nsenter -t <pid> -n bash を実行して CoreDNS ネットワーク名前空間に入ります。

4. 接続性をテストします。

   # Kubernetes API サーバーへの接続性をテスト
   telnet <apiserver_clusterip> 6443  # apiserver_clusterip は、default 名前空間の kubernetes サービスの ClusterIP です。
   
   # 上流 DNS サーバーへの接続性をテスト
   dig <domain> @100.100.2.136
   dig <domain> @100.100.2.138

コンテナネットワークの診断

1. ACK コンソールACK コンソールにログインします。

2. [クラスター] ページで、対象クラスターの名前をクリックするか、[操作] 列の [詳細] をクリックします。

3. 左側のナビゲーションウィンドウで、[オペレーション] > [クラスター診断] を選択します。

4. コンテナインテリジェンスサービスページで、[クラスターチェック] > [診断] を選択します。

5. [診断] ページで、[ネットワーク診断] タブをクリックします。

6. [送信元アドレス] をアプリケーション Pod の IP に、[宛先アドレス] を kube-dns サービスの IP に、宛先ポートを 53 に設定します。[パケットトレースを有効にする] と [上記内容を理解し、同意します] を選択し、[診断の作成] をクリックします。

7. 診断リストで、対象レコードの [診断詳細] をクリックします。

結果には、特定されたエラー原因とともに、[診断結果]、[パケットパス]、[すべての可能なパス] が表示されます。詳細については、「クラスター診断機能を使用してクラスターの問題をトラブルシューティングする」をご参照ください。

パケットキャプチャ

エラーが断続的で再現が困難な場合は、パケットキャプチャを使用します。

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

2. 各 ECS インスタンスで DNS トラフィックをキャプチャします。

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

   これにより、ポート 53 のすべてのトラフィックがキャプチャされ、それぞれ 20 MB の最大 200 ファイルにローテーションされます。

3. エラーを再現し、障害発生時間帯のパケットを分析します。正確なタイムスタンプについては、アプリケーションログを確認してください。

パケットキャプチャによるサービスへの影響はごくわずかです。CPU 使用率とディスク I/O がわずかに増加するだけです。

外部ドメイン名が解決できない

CoreDNS クエリログでレスポンスコードを確認します。ログプラグインがまだ有効でない場合は有効にし (「DNS 名前解決の設定」をご参照ください)、失敗したドメインを検索します。NXDOMAIN は、上流にドメインが存在しないことを意味します。これは多くの場合、検索サフィックスが追加されて無効な FQDN (完全修飾ドメイン名) が作成されたことが原因です。SERVFAIL または REFUSED は、上流サーバーに問題があることを意味します。CoreDNS の設定と 100.100.2.136 および 100.100.2.138 への接続性を確認してください。

ヘッドレスサービスのドメイン名が解決できない

1.7.0 より前の CoreDNS では、API サーバーのネットワークジッターにより CoreDNS が終了し、ヘッドレスサービスのレコード更新が停止する可能性があります。1.7.0 以降に更新してください。詳細については、「[コンポーネントの更新] CoreDNS の更新」をご参照ください。

StatefulSet Pod のドメイン名が解決できない

StatefulSet Pod テンプレートでは、serviceName をヘッドレスサービスの名前に設定する必要があります。これがないと、サービスレベルの名前 (例：headless-svc.ns.svc.cluster.local) は機能しますが、Pod ごとの DNS 名 (例：pod.headless-svc.ns.svc.cluster.local) は解決できません。StatefulSet の spec で serviceName を設定してください。

セキュリティグループルールまたはネットワーク ACL によって DNS クエリがブロックされる

セキュリティグループルールまたはネットワークアクセスコントロールリスト (ACL) が UDP ポート 53 をブロックしているため、影響を受けるノードで DNS 障害が発生しています。インバウンドおよびアウトバウンドの UDP ポート 53 トラフィックを許可してください。

コンテナネットワークの接続エラーによる DNS 障害

コンテナネットワークのエラーが UDP ポート 53 をブロックしています。ネットワーク診断機能を使用して、破損したパスと根本原因を特定してください。

CoreDNS Pod の過負荷

クエリ量が CoreDNS レプリカの容量を超えると、レイテンシーが上昇し、障害が発生します。CPU とメモリの使用量が上限に近づいていないか確認してください (kubectl -n kube-system top pod -l k8s-app=kube-dns を実行)。

2 つの修正方法があります。

• NodeLocal DNSCache をデプロイしてクエリをローカルで吸収し、CoreDNS の負荷を軽減します。「NodeLocal DNSCache の設定」をご参照ください。

• CoreDNS レプリカをスケールアウトして、Pod あたりのピーク CPU 使用率がノードの利用可能な CPU を大幅に下回るようにします。

DNS クエリが CoreDNS Pod 間で均等に分散されない

Pod のスケジューリングの不均衡や kube-dns の sessionAffinity 設定が、クエリの不均等な分散を引き起こす可能性があります。症状：CoreDNS Pod 間で CPU 使用率に顕著な差が見られます。

2 つの修正方法があります。

• CoreDNS Pod をスケールアウトし、異なるノードに分散させます。

• kube-dns サービスから sessionAffinity 設定を削除します。「kube-dns サービスの設定」をご参照ください。

CoreDNS Pod が正常に実行されない

YAML または ConfigMap の設定ミスにより、CoreDNS が起動しなかったり、クラッシュしたりすることがあります。症状：Pod が実行中でない、再起動回数が増加する、またはログエラーが発生する。

CoreDNS ログで、これらの一般的なエラーを確認してください。

クライアントの過負荷による DNS 名前解決の失敗

ECS インスタンスが完全にロードされると、UDP パケットが CoreDNS に到達する前にドロップされることがあります。モニタリングデータで、ネットワークインターフェイスコントローラー (NIC) の異常な再送レートと高い CPU 使用率を探してください。

2 つの選択肢があります。

• 詳細な調査のためにチケットを送信チケットを送信チケットを送信チケットを送信チケットを送信チケットを送信チケットを送信チケットを送信チケットを送信チケットを送信してください。

• NodeLocal DNSCache をデプロイして、ノード間の DNS トラフィックを削減します。「NodeLocal DNSCache の設定」をご参照ください。

conntrack テーブルが満杯になる

conntrack テーブルが満杯になると、新しい UDP および TCP 接続がドロップします。これは通常、ピーク時の DNS 障害を引き起こし、オフピーク時に回復します。確認するには、影響を受けるノードで dmesg -H を実行し、障害発生時間帯に conntrack full が表示されるかを探します。

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

autopath プラグインが正常に動作しない

既知の autopath プラグインの欠陥により、外部ドメインの解決が時折失敗したり、間違った IP に解決されたりすることがあります。内部ドメインは正しく解決されます。この問題は、コンテナの作成頻度が高いクラスターで悪化します。

autopath プラグインを無効にします。

1. kubectl -n kube-system edit configmap coredns を使用して CoreDNS ConfigMap を編集します。

2. autopath @kubernetes の行を削除し、保存して終了します。

3. CoreDNS ログで reload を確認して、設定がロードされたことを確認します。

A レコードと AAAA レコードの同時クエリによる DNS 名前解決の失敗

一部の Linux ディストリビューションでは、同じポートで A クエリと AAAA クエリを同時に送信するため、conntrack の競合が発生し、UDP パケットがドロップされます。

症状：断続的な名前解決の失敗。パケットキャプチャでは、同じ送信元ポートからの A クエリと AAAA クエリが同時に表示されます。

修正方法は、ベースイメージによって異なります。

• CentOS または Ubuntu：DNS リゾルバーの設定に options timeout:2 attempts:3 rotate single-request-reopen を追加します。

• Alpine Linux：Alpine ベースのイメージを別の OS ベースのイメージに置き換えます。「Alpine の注意点」をご参照ください。

• PHP と cURL：CURL_IPRESOLVE_V4 を追加して、IPv4 のみの解決を強制します。「cURL 関数」をご参照ください。

• すべての環境：競合状態を緩和する NodeLocal DNSCache をデプロイします。「NodeLocal DNSCache の設定」をご参照ください。

IPVS エラーによる DNS 名前解決の失敗

CentOS または Alibaba Cloud Linux 2 (カーネルが 4.19.91-25.1.al7.x86_64 より前) の IPVS モードでは、UDP バックエンド Pod を削除すると、送信元ポートの競合が発生し、パケットがドロップします。DNS 障害は、ノードまたは CoreDNS のスケーリングイベント中に約 5 分間続きます。

2 つの修正方法があります。

• NodeLocal DNSCache をデプロイして、DNS クエリの IPVS パスをバイパスします。「NodeLocal DNSCache の設定」をご参照ください。

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

NodeLocal DNSCache が機能しない

次のいずれかの条件が適用される場合、DNS クエリは NodeLocal DNSCache をバイパスします。

• dnsConfig がアプリケーション Pod に挿入されなかったため、それらはまだ kube-dns サービスの IP を指しています。

• Pod は Alpine Linux ベースのイメージを使用しており、CoreDNS を直接含むすべてのネームサーバーに同時にクエリを送信します。

最初のケースでは、自動 dnsConfig 挿入を有効にします。「NodeLocal DNSCache の設定」をご参照ください。Alpine イメージの場合は、別の OS 上に構築されたイメージを使用してください。「Alpine の注意点」をご参照ください。

Alibaba Cloud DNS PrivateZone の名前が解決できない

Alibaba Cloud DNS PrivateZone は TCP ではなく UDP を必要とします。NodeLocal DNSCache を使用すると、PrivateZone ドメイン、vpc-proxy API エンドポイント、またはその他のドメイン名が解決に失敗したり、間違った IP に解決されたりする可能性があります。

CoreDNS 設定に prefer_udp を追加して、上流クエリに UDP を強制します。「CoreDNS の設定」をご参照ください。