次の方法で共有

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

  • [アーティクル]

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

前提条件

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

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

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

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

背景

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

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

アップストリーム DNS サーバーは、ポッドが実行されているワーカー ノードの resolv.conf ファイルに基づいて取得されます。 resolve.conf ファイル (/run/systemd/resolve/resolve.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. ネットワーク ポリシーが、名前空間の CoreDNS ポッドへのユーザー データグラム プロトコル (UDP) ポート 53 のトラフィックを kube-system ブロックしているかどうかを確認します。

  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/resolve.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 サーバーを使用する名前解決」を参照してください。

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

Microsoft では、このトピックに関する追加情報を見つけるのに役立つサード パーティの連絡先情報を提供しています。 将来予告なしに変更されることがあります。 Microsoft は、第三者の連絡先情報の正確性を保証しません。

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

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