次の方法で共有

ワーカー ノードからではなくポッド内から発生した DNS 解決エラーをトラブルシューティングする

  • [アーティクル]

この記事では、Microsoft Azure Kubernetes Service (AKS) クラスターからの送信接続を確立しようとしたときに、ポッド内から発生するがワーカー ノードからは発生しないドメイン ネーム システム (DNS) 解決エラーのトラブルシューティング方法について説明します。

前提条件

  • Kubernetes kubectl ツール、またはクラスターに接続するための同様のツール。 Azure CLI を使用して kubectl をインストールするには、az aks install-cli コマンドを実行します。

  • パッケージを処理するための apt-get コマンドライン ツール。

  • host DNS 参照用のコマンド ライン ツール。

  • systemctl コマンドライン ツール。

背景

DNS 解決のために、ポッドは kube-system 名前空間の CoreDNS ポッドに要求を送信します。

DNS クエリがサービス名などの内部コンポーネントに対する場合、CoreDNS ポッドはそれ自体で応答します。 ただし、要求が外部ドメインに対する場合、CoreDNS ポッドはアップストリーム DNS サーバーに要求を送信します。

アップストリーム DNS サーバーは、ポッドが実行されているワーカー ノードの resolv.conf ファイルに基づいて取得されます。 resolv.conf ファイル ( /run/systemd/resolve/resolv.conf) は、ワーカー ノードが動作されている仮想ネットワークの DNS 設定に基づいて更新されます。

トラブルシューティングのチェックリスト

ポッド内から DNS の問題をトラブルシューティングするには、次のセクションの手順を使用します。

手順 1: ポッド内から DNS の問題をトラブルシューティングする

次の手順に示すように、kubectl コマンドを使用してポッド内から DNS の問題をトラブルシューティングできます。

  1. CoreDNS ポッドが実行されていることを確認します。

    kubectl get pods -l k8s-app=kube-dns -n kube-system

  2. CoreDNS ポッドが過剰に使用されているかどうかを確認します。

    $ kubectl top pods -n kube-system -l k8s-app=kube-dns
NAME                      CPU(cores)   MEMORY(bytes)
coredns-dc97c5f55-424f7   3m           23Mi
coredns-dc97c5f55-wbh4q   3m           25Mi

  3. CoreDNS ポッドをホストするノードが過剰に使用されていないことを確認します。 また、CoreDNS ポッドをホストしているノードを取得します。

    kubectl get pods -n kube-system -l k8s-app=kube-dns -o jsonpath='{.items[*].spec.nodeName}'

  4. 次のノードの使用状況を確認します。

    kubectl top nodes

  5. CoreDNS ポッドのログを確認します。

    kubectl logs -l k8s-app=kube-dns -n kube-system

Note

デバッグ情報をさらに表示するには、CoreDNS で詳細ログを有効にします。 CoreDNS で詳細ログ記録を有効にするには、「 AKS での CoreDNS カスタマイズのトラブルシューティングを参照してください。

手順 2: コマンドを実行するテスト ポッドを作成する

DNS 解決が失敗した場合は、次の手順に従います。

  1. 問題のあるポッドと同じ名前空間でテスト ポッドを実行します。

  2. クラスターでテスト ポッドを開始します。

    kubectl run -it --rm aks-ssh --namespace <namespace> --image=debian:stable

    テスト ポッドが実行されていると、ポッドにアクセスできます。

  3. 次のコマンドを実行して、必要なパッケージをインストールします。

    apt-get update -y
apt-get install dnsutils -y

  4. resolv.conf ファイルに正しいエントリがあることを確認します。

    cat /etc/resolv.conf
search default.svc.cluster.local svc.cluster.local cluster.local 00idcnmrrm4edot5s2or1onxsc.bx.internal.cloudapp.net
nameserver 10.0.0.10
options ndots:5

  5. host コマンドを使用して、DNS 要求がアップストリーム サーバーにルーティングされているかどうかを確認します。

    $ host -a microsoft.com
Trying "microsoft.com.default.svc.cluster.local"
Trying "microsoft.com.svc.cluster.local"
Trying "microsoft.com.cluster.local"
Trying "microsoft.com.00idcnmrrm4edot5s2or1onxsc.bx.internal.cloudapp.net"
Trying "microsoft.com"
Trying "microsoft.com"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62884
;; flags: qr rd ra; QUERY: 1, ANSWER: 27, AUTHORITY: 0, ADDITIONAL: 5

;; QUESTION SECTION:
;microsoft.com.                 IN      ANY

;; ANSWER SECTION:
microsoft.com.          30      IN      NS      ns1-39.azure-dns.com.
...
...
ns4-39.azure-dns.info.  30      IN      A       13.107.206.39

Received 2121 bytes from 10.0.0.10#53 in 232 ms

  6. ポッドからアップストリームの DNS サーバーを確認すると、DNS 解決が正しく機能しているかどうかを確認できます。 たとえば、Azure DNS の場合は、次の nslookup コマンドを実行します。

    $ nslookup microsoft.com 168.63.129.16
Server:         168.63.129.16
Address:        168.63.129.16#53
...
...
Address: 20.81.111.85

手順 3: アップストリーム DNS サーバーが明示的に指定されている場合に DNS 要求が機能するかどうかを確認する

アップストリーム DNS サーバーを明示的に指定するときにポッドからの DNS 要求が機能している場合は、次の条件を確認します。

  1. CoreDNS 用のカスタム ConfigMap を確認します。

    kubectl describe cm coredns-custom -n kube-system

    カスタム ConfigMap が存在する場合は、構成が正しいことを確認します。 詳細については、「 Azure Kubernetes Service を使用して CoreDNS をカスタマイズするを参照してください。

  2. kube-system名前空間の CoreDNS ポッドへのユーザー データグラム プロトコル (UDP) ポート 53 のトラフィックが、ネットワーク ポリシーによってブロックされているかどうかを確認します。

  3. CoreDNS ポッドが別のノード プール (システム ノード プール) 上にあるかどうかを確認します。 その場合は、ネットワーク セキュリティ グループ (NSG) が UDP ポート 53 のトラフィックをブロックしているシステム ノード プールに関連付けられているかどうかを確認します。

  4. 仮想ネットワークが最近更新され、新しい DNS サーバーが追加されたかどうかを確認します。

    仮想ネットワークの更新が発生した場合は、次のいずれかのイベントも発生しているかどうかを確認します。

    • ノードが再起動されました。
    • ノード内のネットワーク サービスが再起動されました。

    DNS 設定の更新を有効にするには、ノードと CoreDNS ポッドのネットワーク サービスを再起動する必要があります。 ネットワーク サービスまたはポッドを再起動するには、次のいずれかの方法を使用します。

    • ノードを再起動します。

    • 新しいノードをスケーリングします。 (新しいノードの構成は更新されます)。

    • ノードでネットワーク サービスを再起動し、CoreDNS ポッドを再起動します。 次のステップを実行します。

      1. ノードへの Secure Shell (SSH) 接続を作成します。 詳しくは、「メンテナンスまたはトラブルシューティングのために Azure Kubernetes Service (AKS) クラスター ノードに接続する」をご覧ください。

      2. ノード内から、ネットワーク サービスを再起動します。

        systemctl restart systemd-networkd

      3. 設定が更新されているかどうかを確認します。

        cat /run/systemd/resolve/resolv.conf

      4. ネットワーク サービスが再起動されたら、kubectl を使用して CoreDNS ポッドを再起動します。

        kubectl delete pods -l k8s-app=kube-dns -n kube-system

  5. 仮想ネットワークの DNS の設定で複数の DNS サーバーが指定されているかどうかを調べます。

    AKS 仮想ネットワークで複数の DNS サーバーが指定されている場合、次のいずれかのシーケンスが発生します。

    • AKS ノードは、シリーズの一部としてアップストリーム DNS サーバーに要求を送信します。 このシーケンスでは、仮想ネットワークで構成されている最初の DNS サーバーに要求が送信されます (DNS サーバーに到達して実行されている場合)。 最初の DNS サーバーに到達できない場合、応答していない場合、要求は次の DNS サーバーに送信されます。

      AKS ノードでは、 resolver コマンドを使用して DNS サーバーに要求を送信します。 このリゾルバーの構成ファイルは、AKS ノードの /run/systemd/resolve/resolv.conf にあります。

      複数のサーバーはありますか? この場合、リゾルバー ライブラリは、一覧に記載されている順序でクエリを実行します。 (使用される戦略は、最初にネーム サーバーを試してみる方法です。クエリがタイムアウトした場合は、次のネーム サーバーを試し、ネーム サーバーの一覧が使い果たされるまで続行します。その後、再試行の最大数が行われるまで、クエリはネーム サーバーへの接続を試行し続けます)。

    • CoreDNS は、 forward プラグインを使用してアップストリーム DNS サーバーに要求を送信します。 このプラグインでは、ランダム アルゴリズムを使用してアップストリーム DNS サーバーを選択します。 このシーケンスでは、要求は、仮想ネットワークに記載されている任意の DNS サーバーに送信される可能性があります。 たとえば、次の出力が表示される場合があります。

      $ kubectl describe cm coredns -n kube-system
Name:         coredns
Namespace:    kube-system
Labels:       addonmanager.kubernetes.io/mode=Reconcile
              k8s-app=kube-dns
              kubernetes.io/cluster-service=true
Annotations:  <none>

Data
====
Corefile:
----
.:53 {
    errors
    ready
    health
    kubernetes cluster.local in-addr.arpa ip6.arpa {
      pods insecure
      fallthrough in-addr.arpa ip6.arpa
    }
    prometheus :9153
    forward . /etc/resolv.conf                            # Here!
    cache 30
    loop
    reload
    loadbalance
    import custom/*.override
}
import custom/*.server


BinaryData
====

Events:  <none>

    CoreDNS の forward プラグインで、policy はアップストリーム サーバーの選択に使用するポリシーを指定します。 次の表はポリシーの定義です。

    ポリシー名 説明
    random ランダムなアップストリーム選択を実装するポリシー。 このポリシーは既定のポリシーです。
    round_robin ラウンド ロビンの順序に基づいてホストを選択するポリシー。
    sequential シーケンシャルな順序に基づいてホストを選択するポリシー。

    AKS 仮想ネットワークに複数の DNS サーバーが含まれている場合、AKS ノードからの要求は最初の DNS サーバーに送信される可能性があります。 ただし、ポッドからの要求は 2 番目の DNS サーバーに送信される場合があります。

原因: DNS 要求の複数の宛先

2 つのカスタム DNS サーバーが指定され、3 つ目の DNS サーバーが Azure DNS (168.63.129.16) として指定されている場合、ノードは、実行中で到達可能な場合に最初のカスタム DNS サーバーに要求を送信します。 このセットアップでは、ノードはカスタム ドメインを解決できます。 ただし、ポッドからの DNS 要求の一部が Azure DNS に送信される場合があります。 これは、CoreDNS がアップストリーム サーバーをランダムに選択できるためです。 このシナリオでは、カスタム ドメインを解決できません。 そのため、DNS 要求は失敗します。

解決策: 仮想ネットワーク設定から Azure DNS を削除する

仮想ネットワーク設定では、Azure DNS とカスタム DNS サーバーを組み合わせないようにすることをお勧めします。 カスタム DNS サーバーを使用する場合は、仮想ネットワーク設定にカスタム DNS サーバーのみを追加します。 次に、カスタム DNS サーバーのフォワーダー設定で Azure DNS を構成します。

詳細については、「独自の DNS サーバーを使用する名前解決」を参照してください。

サードパーティのお問い合わせ窓口に関する免責事項

サードパーティのお問い合わせ窓口に関する情報は、ユーザーの便宜のために提供されているものであり、 この連絡先情報は、予告なしに変更される可能性があります。 マイクロソフトは、掲載されている情報に対して、いかなる責任も負わないものとします。

お問い合わせはこちらから

質問がある場合やヘルプが必要な場合は、サポート要求を作成するか、Azure コミュニティ サポートにお問い合わせください。 Azure フィードバック コミュニティに製品フィードバックを送信することもできます。