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

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

ご使用のエラーメッセージと照合して、障害カテゴリを特定します：

デバッグ用ポッドのセットアップ

診断コマンドを実行する前に、クリーンな観測環境を構築してください。これにより、アプリケーションのバグと DNS のバグとの混同を回避できます。

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

以下のコマンドも実行できます：

nslookup <ドメイン名>

ステップ 1：アプリケーションポッドの DNS 構成を確認

# Pod の YAML を取得し、dnsPolicy フィールドを確認
kubectl get pod <pod-name> -o yaml

# dnsPolicy が適切に設定されている場合、コンテナ内 DNS 構成を確認
kubectl exec -it <pod-name> -- cat /etc/resolv.conf

nameserver が CoreDNS または NodeLocal DNSCache を指しているかを確認します：

• CoreDNS（kube-dns Service IP、例：172.21.0.10）の場合：「ステップ 2」に進みます。

• NodeLocal DNSCache（169.254.20.10）の場合：「NodeLocal DNSCache の問題」をご参照ください。

• いずれでもない（クラスタ DNS が未設定）場合：ポッドが過負荷状態のノード上で実行されているか、conntrack テーブルが満杯になっている可能性があります。「クライアントの過負荷」および「conntrack テーブルが満杯」をご参照ください。

apiVersion: v1
kind: Pod
metadata:
  name: <pod-name>
  namespace: <pod-namespace>
spec:
  containers:
  - image: <container-image>
    name: <container-name>
  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

ステップ 2：CoreDNS ポッドのステータスを確認

kubectl -n kube-system get pod -o wide -l k8s-app=kube-dns

期待される出力（すべてのポッドが Running 状態）：

NAME                      READY   STATUS    RESTARTS   AGE   IP            NODE
coredns-xxxxxxxxx-xxxxx   1/1     Running   0          25h   172.20.6.53   cn-hangzhou.192.168.0.198

リソース使用量を確認します：

kubectl -n kube-system top pod -l k8s-app=kube-dns

期待される出力：

NAME                      CPU(cores)   MEMORY(bytes)
coredns-xxxxxxxxx-xxxxx   3m           18Mi

ポッドが Running 状態でない場合は、原因を特定するために詳細情報を表示します：

kubectl -n kube-system describe pod <coredns-pod-name>

一般的なエラーログおよび修正方法については、「CoreDNS ポッドが予期通りに実行されていない」をご参照ください。

ステップ 3：CoreDNS の運用ログを確認

kubectl -n kube-system logs -f --tail=500 --timestamps <coredns-pod-name>

ログ内で NXDOMAIN、SERVFAIL、または REFUSED 応答を探します。これらの応答が外部ドメイン名に対して表示される場合、上流 DNS サーバがエラーを返しています。「外部ドメイン名が解決できない」をご参照ください。

ステップ 4：問題が再現可能かどうかを確認

• 常に失敗する場合：「DNS クエリログの診断」および「アプリケーションポッドと CoreDNS 間のネットワーク接続性の診断」に進みます。

• 不定期に発生する場合：「パケットキャプチャ」で説明されている手順に従ってパケットを収集します。

DNS クエリログの形式

[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

DNS 応答コード

仕様の詳細については、「RFC 1035」をご参照ください。

ログに外部ドメイン名に対する NXDOMAIN、SERVFAIL、または REFUSED が表示される場合、上流 DNS サーバが根本原因となります。デフォルトでは、CoreDNS は VPC DNS サーバ 100.100.2.136 および 100.100.2.138 を上流リゾルバーとして使用します。「チケットを送信」より ECS チームへチケットを送信し、以下の情報を含めてください：

外部ドメイン名が解決できない場合の対処方法

内部ドメイン名は正常に解決されますが、外部ドメイン名の解決に失敗します。

失敗したドメイン名について、CoreDNS のクエリログに NXDOMAIN、SERVFAIL、または REFUSED が表示されているかを確認します。これらのコードは、上流 DNS サーバ（デフォルトでは 100.100.2.136 および 100.100.2.138）がエラーを返していることを示します。「チケットを送信」より ECS チームへ、ドメイン名、応答コード、タイムスタンプ、および CoreDNS を実行しているノードの ECS インスタンス ID を含めてチケットを送信してください。

ヘッドレス Service ドメイン名が解決できない場合の対処方法

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

これは、通常、Kubernetes API サーバのネットワークジッター時に予期せず終了する可能性のある CoreDNS 1.7.0 より前のバージョンで発生します。これにより、ヘッドレス Service の DNS レコードが古くなってしまいます。CoreDNS を 1.7.0 以降に更新してください。「[コンポーネントの更新] CoreDNS の更新」をご参照ください。

dig の応答に tc フラグが表示される場合、ヘッドレス Service のバックエンド IP アドレスが多すぎて、DNS 応答が UDP パケットサイズ制限を超えています。クライアントを構成して、DNS クエリを TCP 経由で送信できるようにします：

• glibc ベースのリゾルバの場合、use-vc を dnsConfig に追加します：

  dnsConfig:
    options:
    - name: use-vc

  これは options ディレクティブに相当し、/etc/resolv.conf にマップされます。詳細については、「resolv.conf の Linux マニュアルページ」をご参照ください。

• Go アプリケーションの場合、リゾルバを TCP を使用するように構成します：

  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)
  }

CoreDNS を更新後にヘッドレス Service ドメイン名が解決できない場合の対処方法

Kubernetes 1.20 以降および CoreDNS 1.8.4 以降にアップグレードした後、etcd、Nacos、Kafka などのオープンソースコンポーネントがサービス検出に失敗します。

CoreDNS 1.8.4 では EndpointSlice API に切り替わりました。一部のオープンソースコンポーネントは、初期化時に準備ができていないサービスを公開するために、古い Endpoint API の service.alpha.kubernetes.io/tolerate-unready-endpoints アノテーションに依存しています。このアノテーションは EndpointSlice ではサポートされておらず、publishNotReadyAddresses に置き換えられました。

影響を受けるコンポーネントの YAML または Helm チャートで service.alpha.kubernetes.io/tolerate-unready-endpoints が使用されているかを確認してください。使用されている場合は、コンポーネントをアップグレードするか、コンポーネントのコミュニティに相談してください。

StatefulSet ポッドのドメイン名が解決できない場合の対処方法

StatefulSet ポッドのドメイン名（例：pod.headless-svc.ns.svc.cluster.local）が解決できないが、ヘッドレス Service 自体のドメイン名は正常に解決される。

StatefulSet ポッドの YAML テンプレートで serviceName が誤った値に設定されているか、空欄のままになっています。serviceName を、StatefulSet を公開するヘッドレス Service の正確な名前に設定してください。

セキュリティグループルールが DNS クエリをブロックしている場合の対処方法

DNS 解決が一部またはすべてのノードで継続的に失敗する。

ECS インスタンスのセキュリティグループルールまたはネットワークアクセスコントロールリスト（ACL）が UDP ポート 53 をブロックしています。UDP ポート 53 を許可するようにセキュリティグループルールまたはネットワーク ACL を変更してください。

コンテナネットワーク接続エラーが発生した場合の対処方法

DNS 解決が一部またはすべてのノードで継続的に失敗する。

コンテナネットワーク接続エラーまたはその他の問題が UDP ポート 53 をブロックしています。「ネットワーク診断」機能を使用して、アプリケーションポッドと CoreDNS ポッド間のネットワーク接続性を診断してください。問題が継続する場合は、「チケットを送信」してください。

CoreDNS ポッドが過負荷状態の場合の対処方法

DNS 解決の遅延が大きい、または継続的または不定期に失敗が発生する。CoreDNS ポッドの CPU 使用率またはメモリ使用率が上限に近い。

DNS クエリのボリュームを処理するのに十分な CoreDNS レプリカ数が少ないためです。以下のいずれか、または両方の対策を実施してください：

• CoreDNS の負荷を軽減するために NodeLocal DNSCache を有効化します。「NodeLocal DNSCache の構成」をご参照ください。

• CoreDNS ポッドをスケールアウトし、各ポッドのピーク CPU 使用率がノードの利用可能な CPU 余剰分を下回るようにします。

DNS クエリ負荷が不均衡な場合の対処方法

DNS 解決の遅延が大きい、または一部（すべてではない）のノードで不定期に失敗が発生する。CoreDNS ポッドの CPU 使用率がポッド間で大きく異なる。2 つ未満の CoreDNS レプリカが実行中である、または複数のポッドが同じノードにスケジュールされている。

ポッドのスケジューリングの不均衡または kube-dns Service の SessionAffinity 設定により、DNS クエリが不均等に分散されています。これを修正するには：

• CoreDNS ポッドをスケールアウトし、別々のノードにスケジュールします。

• kube-dns Service の SessionAffinity 設定を削除します。「ACK による CoreDNS の自動更新の構成」をご参照ください。

CoreDNS ポッドが予期通りに実行されていない場合の対処方法

DNS 解決の遅延が大きい、一部のノードで失敗が発生する、CoreDNS ポッドが Running 状態でない、再起動回数が増加し続ける、または CoreDNS のログにエラーが表示される。

誤った YAML 構成または誤った CoreDNS ConfigMap がポッドの実行を妨げています。ポッドのステータスおよびログを確認してください。

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

クライアントの過負荷により DNS が失敗する場合の対処方法

DNS エラーが不定期またはピーク時に発生する。ECS インスタンスの監視で異常な NIC 再送率または高い CPU 使用率が確認される。

DNS クエリを送信するポッドをホストする ECS インスタンスが完全に過負荷状態であり、UDP パケット損失が発生しています。「チケットを送信」してください。並行して、NodeLocal DNSCache を有効化してノード単位の DNS 負荷を軽減します。「NodeLocal DNSCache の構成」をご参照ください。

conntrack テーブルが満杯の場合の対処方法

DNS 解決がピーク時に一部またはすべてのノードで頻繁に失敗するが、非ピーク時には正常に動作する。インスタンスで dmesg -H を実行すると、障害発生期間中に conntrack full がログに表示される。

Linux カーネルの conntrack テーブルが満杯のため、UDP および TCP パケットを処理できません。conntrack テーブルの最大エントリ数を増加させます。「Linux カーネルの conntrack テーブルにおけるトラッキング接続数の最大値を増やすには？」をご参照ください。

autopath プラグインが期待通りに動作しない場合の対処方法

外部ドメイン名が偶発的に解決できない、または誤った IP アドレスに解決される。一方、内部ドメイン名は正常に解決される。クラスタがコンテナを高速で作成する場合、内部ドメイン名が誤った IP アドレスに解決されることがある。

CoreDNS の autopath プラグインには既知の欠陥があります。無効化してください：

1. CoreDNS ConfigMap を編集します：

   kubectl -n kube-system edit configmap coredns

2. autopath @kubernetes 行を削除し、ファイルを保存して終了します。

3. CoreDNS が新しい構成を読み込んだことを、ログに reload キーワードが表示されているかで確認します。

同時 A および AAAA レコードクエリにより DNS が失敗する場合の対処方法

CoreDNS の DNS 解決が不定期に失敗する。パケットキャプチャまたは DNS クエリログで、同一送信元ポートを介して同時に送信された A レコードおよび AAAA レコードのクエリが確認される。

同時 A および AAAA レコードクエリにより conntrack テーブルのエラーが発生し、UDP パケット損失につながります。ARM マシンでは、libc のバージョン 2.33 より前のものでこの問題が発生します（GLIBC#26600 を参照）。

ご使用の環境に応じて、以下のいずれか、または複数の修正を適用してください：

• NodeLocal DNSCache：パケット損失の影響を軽減します。「NodeLocal DNSCache の構成」をご参照ください。

• libc を使用する CentOS または Ubuntu：libc を 2.33 以降に更新するか、リゾルバオプションを追加します：options timeout:2 attempts:3 rotate single-request-reopen。

• PHP cURL: ドメイン名の解決を IPv4 アドレスのみに指定するには、CURL_IPRESOLVE_V4 を追加します。詳細については、curl_setopt を参照してください。

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

IPVS エラーにより DNS が失敗する場合の対処方法

ノードがクラスタに追加または削除されたとき、ノードがシャットダウンしたとき、または CoreDNS がスケールインされたときに、DNS 解決が不定期に失敗する。障害は通常約 5 分間続く。

kube-proxy が IPVS モードで実行されています。カーネルバージョンが 4.19.91-25.1.al7.x86_64 より前の CentOS または Alibaba Cloud Linux 2 ノードで UDP バックエンドポッドが削除されると、送信元ポートの競合により UDP パケットが破棄されます。

これを修正するには：

• IPVS をバイパスするために NodeLocal DNSCache を有効化します。「NodeLocal DNSCache の構成」をご参照ください。

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

NodeLocal DNSCache の問題