次の方法で共有

ポッド内からの DNS 解決エラーのトラブルシューティングを行うが、ワーカー ノードからのトラブルシューティングは行わない

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

[前提条件]

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

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

  • 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

注

デバッグ情報をさらに表示するには、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 ノードでは、 リゾルバー コマンドを使用して DNS サーバーに要求を送信します。 このリゾルバーの構成ファイルは、AKS ノードの /run/systemd/resolve/resolv.conf にあります。

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

    • CoreDNS は 、転送 プラグインを使用してアップストリーム 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 フィードバック コミュニティに製品フィードバックを送信することもできます。