Azure Kubernetes Service (AKS) での CoreDNS に関する問題のトラブルシューティング

この記事では、Azure Kubernetes Service (AKS) のさまざまな CoreDNS の問題に関するトラブルシューティングガイダンスを提供します。

DNS 解決の問題をデバッグする

エンドポイントや解決策を調べるなど、CoreDNS の一般的なトラブルシューティング手順については、「DNS 解決のデバッグ」を参照してください。

CoreDNS ポッドのトラフィックの不均衡のトラブルシューティング

AKS クラスターで複数の CoreDNS ポッドが実行されている場合でも、1 つまたは 2 つの CoreDNS ポッドが CPU 使用率が大幅に高く、他のポッドよりも多くの DNS クエリを処理していることがわかります。これは Kubernetes の既知の問題であり、CoreDNS ポッドの 1 つが過負荷になり、クラッシュする可能性があります。

この不均一な DNS クエリの分散は、主に Kubernetes のユーザーデータグラムプロトコル (UDP) 負荷分散の制限によって発生します。プラットフォームでは、UDP トラフィックを分散するために 5 タプルハッシュ (ソース IP、送信元ポート、宛先 IP、宛先ポート、プロトコル) が使用されるため、アプリケーションが DNS クエリに同じソースポートを再利用する場合、そのクライアントからのすべてのクエリは同じ CoreDNS ポッドにルーティングされます。この分散方法により、1 つのポッドが不均衡な量のトラフィックを処理する可能性があります。さらに、一部のアプリケーションでは接続プールを使用し、DNS 接続を再利用します。この動作により、単一の CoreDNS ポッドに DNS クエリがさらに集中し、不均衡とオーバーロードのリスクと潜在的なクラッシュが増加する可能性があります。

次のセクションは、この問題のトラブルシューティングと軽減に役立ちます。

DNS クエリログを有効にする

DNS クエリログを有効にして、CoreDNS ポッドから必要な DNS クエリログをキャプチャします。

coredns-custom ConfigMap に次の構成を追加します。

apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns-custom
  namespace: kube-system
data:
  log.override: | # You can select any name here, but it must end with the .override file extension
        log

kubectl apply configmap コマンドを使用して ConfigMap の変更を適用します。
```
kubectl apply -f corednsms.yaml
```
kubectl rollout restart コマンドを使用して、ローリング再起動を実行して ConfigMap を再読み込みし、Kubernetes Scheduler がダウンタイムなしで CoreDNS を再起動できるようにします。
```
kubectl --namespace kube-system rollout restart deployment coredns
```
kubectl logs コマンドを使用して CoreDNS デバッグログを表示します。
```
kubectl logs --namespace kube-system -l k8s-app=kube-dns
```

CoreDNS ポッドのトラフィック分散を確認する

kubectl get pods コマンドを使用して、クラスター内のすべての CoreDNS ポッドの名前を取得します。
```
kubectl get pods --namespace kube-system -l k8s-app=kube-dns
```
各 CoreDNS ポッドのログを確認し、 kubectl logs コマンドを使用して DNS クエリパターンを分析します。すべての CoreDNS ポッドに対してこのコマンドを繰り返し、 <coredns-pod-x> を実際のポッド名に置き換えます。
```
kubectl logs --namespace kube-system <coredns-pod-x>
```
出力で、1 つの CoreDNS ポッドのログにのみ表示される繰り返しのクライアント IP アドレスとポートを探します。これは、特定のクライアントからの DNS クエリが均等に分散されていないことを示します。

ログ出力の例:
```
[INFO] 10.244.0.247:5556 - 42621 "A IN myservice.default.svc.cluster.local. udp 28" NOERROR qr,aa,rd 106 0.000141s
```
このログエントリの例では、次の操作を行います。
- 10.244.0.247 は、DNS クエリを作成するクライアント IP アドレスです。
- 5556 はクライアントソースポートです。
- 42621 はクエリ ID です。
1 つのポッドのログにのみ同じクライアント IP とポートが繰り返し表示される場合は、トラフィックの不均衡が確認されます。

CoreDNS ポッドのトラフィックの不均衡を軽減する

不均衡に気付いた場合、アプリケーションは UDP ソースポートを再利用したり、接続をプールしたりする可能性があります。根本原因に基づいて、次の軽減策を実行できます。

UDP ソースポートの再利用が原因: UDP ソースポートの再利用は、クライアントアプリケーションが同じ UDP ソースポートから複数の DNS クエリを送信するときに発生します。これが問題である場合は、アプリケーションまたは DNS クライアントを更新して、各 DNS クエリのソースポートをランダム化します。これにより、ポッド間で要求をより均等に分散できます。
接続プールの原因: 接続プールは、アプリケーションが要求ごとに新しい接続を作成するのではなく、既存のネットワーク接続を再利用するために使用するメカニズムです。これにより効率が向上しますが、アプリケーションからのすべての DNS クエリが同じ接続経由で送信され、同じ CoreDNS ポッドにルーティングされる可能性があります。これを軽減するには、接続の Time to Live (TTL) を減らすか、接続の作成をランダム化して、クエリが 1 つの CoreDNS ポッドに集中しないようにすることで、アプリケーションの DNS 接続処理を調整します。

これらの変更は、よりバランスの取れた DNS クエリ分散を実現し、個々のポッドをオーバーロードするリスクを軽減するのに役立ちます。

internal.cloudapp.net と reddog.microsoft.com の無効な検索ドメイン補完をトラブルシューティングする

Azure DNS では、Azure DNS を使用して仮想ネットワーク (VNet) 内の <VNET_ID>.<REGION>.internal.cloudapp.net の既定の検索ドメインを構成し、カスタム DNS サーバーを使用して VNet で機能しないスタブ reddog.microsoft.com を構成します。詳細については、リソースの名前解決に関するドキュメントを参照してください。

Kubernetes は、ポッドの DNS 設定を構成する際、クラスターサービスのホスト名解決を適切にサポートするために ndots: 5 を使用します。これら 2 つの構成の組み合わせは、システムによってドメイン検索リストが処理される際、決して成功しない無効な検索ドメイン補完クエリがアップストリームネームサーバーに送信される結果を引き起こします。それらの無効なクエリは、名前解決に遅延が発生する原因になり、アップストリーム DNS サーバーに余分な負荷をかける可能性もあります。

v20241025 AKS リリースの時点で、AKS は、これらの無効な検索ドメイン完了クエリがアップストリーム DNS に転送されないようにするために、次の場合にNXDOMAINで応答するように CoreDNS を構成します。

reddog.microsoft.com のルートドメインまたはサブドメインに対する任意のクエリ。
internal.cloudapp.net のサブドメインで、ドメイン名に 7 個以上のラベルが含まれるクエリ。
- この構成により、ホスト名による仮想マシン (VM) の解決は引き続き成功します。たとえば、CoreDNS は aks12345.myvnetid.myregion.internal.cloudapp.net (6 つの ラベル) を Azure DNS に送信しますが、 mcr.microsoft.com.myvnetid.myregion.internal.cloudapp.net (8 つの ラベル) は拒否します。

このブロックは、クラスターの CoreFile の既定のサーバーブロックに実装されます。必要に応じて、転送プラグインを有効にして適切なドメインのカスタムサーバーブロックを作成することで、この拒否構成を無効にすることができます。

corednsms.yamlという名前のファイルを作成し、次の構成例に貼り付けます。 IP アドレスとホスト名は、必ず独自の値で更新してください。

apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns-custom # This is the name of the ConfigMap you can overwrite with your changes
  namespace: kube-system
data:
    override-block.server:
       internal.cloudapp.net:53 {
           errors
           cache 30
           forward . /etc/resolv.conf
       }
       reddog.microsoft.com:53 {
           errors
           cache 30
           forward . /etc/resolv.conf
       }

kubectl apply configmap コマンドを使用して ConfigMap を作成します。
```
kubectl apply -f corednsms.yaml
```
kubectl rollout restart コマンドを使用して、ローリング再起動を実行して ConfigMap を再読み込みし、Kubernetes Scheduler がダウンタイムなしで CoreDNS を再起動できるようにします。
```
kubectl --namespace kube-system rollout restart deployment coredns
```

CoreDNS の自動スケールに関する問題のトラブルシューティング

CoreDNS 自動スケールの問題をトラブルシューティングするには、 Azure Kubernetes Service (AKS) での CoreDNS の自動スケーリングに関するページを参照してください。

フィードバック

このページはお役に立ちましたか?

Last updated on 2025-10-22