次の方法で共有

AKS クラスターからの送信接続の基本的なトラブルシューティング

  • [アーティクル]

この記事では、Microsoft Azure Kubernetes Service (AKS) クラスターからの送信接続の基本的なトラブルシューティングを行う方法について説明します。

前提条件

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

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

  • クライアント URL (cURL) ツール、または同様のコマンド ライン ツール。

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

  • TCP 接続用 の Netcat (nc) コマンド ライン ツール。

  • ネットワーク ホストへのルーティング パケットのトレースを印刷するための traceroute コマンド ライン ツール。

Azure Kubernetes Serviceの送信トラフィックのシナリオ

どのネットワーク シナリオでも、トラブルシューティングを行うときは、次の要因を考慮する必要があります。

  • 要求のソースと宛先。

  • ソースと宛先の間のホップ。

  • 要求/応答フロー。

  • 次のレイヤーなど、追加のセキュリティ レイヤーによって強化されたホップ。

    • ファイアウォール
    • ネットワーク セキュリティ グループ (NSG)
    • ネットワーク ポリシー

各コンポーネントをチェックしたら、HTTP 応答コードを取得して分析します。 これらのコードは、問題の性質を特定するのに役立ちます。 コードは、アプリケーションが HTTP 要求に応答するシナリオで特に役立ちます。

他のトラブルシューティング手順で決定的な結果が得られない場合は、クライアントとサーバーからパケット キャプチャを実行します。 パケット キャプチャは、クライアントとサーバーの間に HTTP 以外のトラフィックが関係している場合にも役立ちます。 AKS 環境のパケット キャプチャを収集する方法の詳細については、データ収集ガイドの次の記事を参照してください。

HTTP 応答コードを取得し、パケット キャプチャを取得する方法がわかっている場合は、ネットワーク接続の問題のトラブルシューティングを行う方が簡単です。

AKS クラスター内から発信されるトラフィック (ポッドまたはワーカー ノードからのトラフィック) は、クラスターからの送信トラフィックと見なされます。 AKS クラスターの送信フローに問題がある場合はどうすればよいですか? トラブルシューティングを行う前に、まず要求/応答フローの性質を理解してください。

AKS クラスターからの送信トラフィックは、次のカテゴリに分類できます。

  1. 同じクラスター内のポッドまたはサービスへのトラフィック (内部トラフィック)

  2. 同じ仮想ネットワークまたは別の仮想ネットワーク (仮想ネットワーク ピアリングを使用する) 内のデバイスまたはエンドポイントへのトラフィック

  3. VPN 接続または Azure ExpressRoute 接続を介したオンプレミス環境へのトラフィック

  4. AKS ネットワーク外のトラフィック (パブリック送信トラフィック)

このドキュメントでは、送信接続に影響する問題の基本的なトラブルシューティング手順について説明します。

  • クラスター内
  • 仮想ネットワーク内
  • 外部へのアクセス (パブリック トラフィック)

AKS で送信トラフィックのトラブルシューティングを行う場合は、エグレス デバイス (つまり、トラフィックが通過するデバイス) を把握することも重要です。 ここでは、エグレス デバイスは次のいずれかのコンポーネントである可能性があります。

  • Azure Load Balancer
  • Azure Firewallまたはカスタム ファイアウォール
  • ネットワーク アドレス変換 (NAT) ゲートウェイ
  • プロキシ サーバー

また、フローは宛先によって異なる場合もあります。 たとえば、内部トラフィック (つまり、クラスター内) はエグレス デバイスを通過しません。 内部トラフィックでは、クラスター ネットワークのみが使用されます。

内部トラフィック

AKS クラスターからの内部トラフィックの基本的な要求フローは、次の図に示すフローのようになります。

Microsoft Azure Kubernetes Service (AKS) クラスターからの内部トラフィックの基本的な要求フローの図。

Azure Load Balancerを介した外部トラフィック

トラフィックがインターネット上の宛先の場合、既定の方法は、Azure Load Balancer経由でトラフィックを送信することです。

Microsoft Azure Kubernetes Service (AKS) クラスターからのAzure Load Balancerを介した外部インターネット トラフィックの要求フローの図。

Azure Firewallまたはプロキシ サーバー経由の外部トラフィック

場合によっては、エグレス トラフィックをフィルター処理する必要があり、Azure Firewallが必要になる場合があります。

Microsoft Azure Kubernetes Service (AKS) クラスターからのAzure Firewallを介した外部インターネット トラフィックの要求フローの図。

ファイアウォールの代わりに、ユーザーがプロキシ サーバーを追加したい場合があります。 または、ユーザーがエグレス トラフィック用に NAT ゲートウェイを設定したい場合があります。 基本的なフローは、図に示すように変わりません。

トラブルシューティングを続行できるように、クラスターのエグレス フローの性質を理解することが重要です。

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

AKS クラスターからのエグレス トラフィックの基本的なトラブルシューティングについては、次の手順に従います。

  1. エンドポイントのドメイン ネーム システム (DNS) 解決が正しく機能することを確認します。

  2. IP アドレスを介してエンドポイントに到達できることを確認します。

  3. 別のソースからエンドポイントに到達できることを確認します。

  4. エンドポイントが動作していることを確認します。

  5. クラスターが他の外部エンドポイントに到達できるかどうかを確認します。

  6. ネットワーク ポリシーがトラフィックをブロックしているかどうかを確認します。

  7. NSG がトラフィックをブロックしているかどうかを確認します。

  8. ファイアウォールまたはプロキシがトラフィックをブロックしているかどうかを確認します。

  9. AKS サービス プリンシパルまたはマネージド ID に、Azure リソースへのネットワーク変更を行うために必要な AKS サービスアクセス許可 があるかどうかを確認します。

エンドポイントの DNS 解決が成功したかどうかを確認する

ポッド内から、エンドポイントへの DNS 参照を実行できます。

kubectl exec コマンドを実行してポッドに接続し、DNS Utils パッケージをインストールできない場合はどうすればよいですか? この状況では、 問題のあるポッドと同じ名前空間でテスト ポッドを開始し、テストを実行できます。

注:

DNS 解決またはエグレス トラフィックで必要なネットワーク パッケージをインストールできない場合は、docker イメージを rishasi/ubuntu-netutil:1.0 使用できます。 このイメージでは、必要なパッケージが既にインストールされています。

DNS 解決を確認する手順の例を次に示します。

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

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

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

  2. 次 apt-get のコマンドを実行して、他のツール パッケージをインストールします。

    apt-get update -y
apt-get install dnsutils -y
apt-get install curl -y
apt-get install netcat -y

  3. パッケージがインストールされたら、 nslookup コマンドを実行して、エンドポイントへの DNS 解決をテストします。

    $ nslookup microsoft.com
Server:         10.0.0.10
Address:        10.0.0.10#53
...
...
Name:   microsoft.com
Address: 20.53.203.50

  4. アップストリーム DNS サーバーから直接 DNS 解決を試してください。 この例では、Azure DNS を使用します。

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

  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. Windows ノード プールでテスト ポッドを実行します。

    # For a Windows environment, use the Resolve-DnsName cmdlet.
kubectl run dnsutil-win --image='mcr.microsoft.com/windows/servercore:1809' --overrides='{"spec": { "nodeSelector": {"kubernetes.io/os": "windows"}}}' -- powershell "Start-Sleep -s 3600"

  7. kubectl exec コマンドを実行して、PowerShell を使用してポッドに接続します。

    kubectl exec -it dnsutil-win powershell

  8. PowerShell で Resolve-DnsName コマンドレットを実行して、エンドポイントで DNS 解決が機能しているかどうかをチェックします。

    PS C:\> Resolve-DnsName www.microsoft.com 

Name                           Type   TTL   Section    NameHost
----                           ----   ---   -------    --------
www.microsoft.com              CNAME  20    Answer     www.microsoft.com-c-3.edgekey.net
www.microsoft.com-c-3.edgekey. CNAME  20    Answer     www.microsoft.com-c-3.edgekey.net.globalredir.akadns.net
net
www.microsoft.com-c-3.edgekey. CNAME  20    Answer     e13678.dscb.akamaiedge.net
net.globalredir.akadns.net

Name       : e13678.dscb.akamaiedge.net 
QueryType  : AAAA
TTL        : 20
Section    : Answer
IP6Address : 2600:1408:c400:484::356e   


Name       : e13678.dscb.akamaiedge.net 
QueryType  : AAAA
TTL        : 20
Section    : Answer
IP6Address : 2600:1408:c400:496::356e 


Name       : e13678.dscb.akamaiedge.net
QueryType  : A
TTL        : 12
Section    : Answer
IP4Address : 23.200.197.152

また、エンドポイントがノードから到達可能かどうかをチェックする必要もあります。 次に、ノードの DNS 設定を確認します。 次の手順を実行します。

  1. メンテナンスまたはトラブルシューティングのために、Azure Kubernetes Service (AKS) クラスター ノードに接続します。

  2. エンドポイントへの DNS 解決をテストします。

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

Non-authoritative answer:
Name:   microsoft.com
Address: 20.112.52.29
Name:   microsoft.com
Address: 20.81.111.85
Name:   microsoft.com
Address: 20.84.181.62
Name:   microsoft.com
Address: 20.103.85.33
Name:   microsoft.com
Address: 20.53.203.50

  3. resolv.conf ファイルを調べて、予想されるネーム サーバーが追加されているかどうかを確認します。

    cat /etc/resolv.conf
cat /run/systemd/resolve/resolv.conf

DNS 解決を伴う 1 つの異常なシナリオでは、DNS クエリはノードから正しい応答を取得しますが、ポッドから失敗します。 このシナリオでは、 ポッド内から DNS 解決エラーを確認することを検討しますが、ワーカー ノードからは確認しないでください。

DNS 解決が成功した場合は、ネットワーク テストに進みます。 それ以外の場合は、クラスターの DNS 構成を確認します。

クラスターがネットワーク経由でエンドポイントに到達できるかどうかを確認する

クラスターからネットワーク経由でエンドポイントに到達できるかどうかを判断するには、次の手順に従います。

  1. エンドポイントへのルートを確認して、特定の操作でタイムアウトがあるかどうかを判断します。

    kubectl run -it --rm aks-ssh --namespace <namespace> --image=debian:stable
apt-get install -y traceroute && apt-get install netcat -y
traceroute -T microsoft.com -m 50 -p 443

  2. 目的のポートがリモート ホストで開かれているかどうかを確認します。

    nc -z -v microsoft.com 443

  3. HTTP 応答コードを確認します。

    curl -Iv https://microsoft.com

  4. 他のエンドポイントに接続できるかどうかを確認します。

    curl -Iv https://kubernetes.io

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

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

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

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