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 クラスターからの送信トラフィックは、次のカテゴリに分類できます。
同じクラスター内のポッドまたはサービスへのトラフィック (内部トラフィック)
同じ仮想ネットワークまたは別の仮想ネットワーク (仮想ネットワーク ピアリングを使用する) 内のデバイスまたはエンドポイントへのトラフィック
VPN 接続または Azure ExpressRoute 接続を介したオンプレミス環境へのトラフィック
AKS ネットワーク外のトラフィック (パブリック送信トラフィック)
このドキュメントでは、送信接続に影響する問題の基本的なトラブルシューティング手順について説明します。
- クラスター内
- 仮想ネットワーク内
- 外部へのアクセス (パブリック トラフィック)
AKS で送信トラフィックのトラブルシューティングを行う場合は、エグレス デバイス (つまり、トラフィックが通過するデバイス) を把握することも重要です。 ここでは、エグレス デバイスは次のいずれかのコンポーネントである可能性があります。
- Azure Load Balancer
- Azure Firewall またはカスタム ファイアウォール
- ネットワーク アドレス変換 (NAT) ゲートウェイ
- プロキシ サーバー
また、フローは宛先によって異なる場合もあります。 たとえば、内部トラフィック (つまり、クラスター内) はエグレス デバイスを通過しません。 内部トラフィックでは、クラスター ネットワークのみが使用されます。
内部トラフィック
AKS クラスターからの内部トラフィックの基本的な要求フローは、次の図に示すフローのようになります。
Azure Load Balancer を介した外部トラフィック
トラフィックがインターネット上の宛先の場合、既定の方法は Azure Load Balancer 経由でトラフィックを送信することです。
Azure Firewall またはプロキシ サーバーを介した外部トラフィック
場合によっては、エグレス トラフィックをフィルター処理する必要があり、Azure Firewall が必要になる場合があります。
ファイアウォールの代わりに、ユーザーがプロキシ サーバーを追加したい場合があります。 または、ユーザーがエグレス トラフィック用に NAT ゲートウェイを設定したい場合があります。 基本的なフローは、図に示すように変わりません。
トラブルシューティングを続行できるように、クラスターのエグレス フローの性質を理解することが重要です。
トラブルシューティング チェックリスト
AKS クラスターからのエグレス トラフィックの基本的なトラブルシューティングについては、次の手順に従います。
IP アドレスを介してエンドポイントに到達できることを確認します。
ファイアウォールまたはプロキシがトラフィックをブロックしているかどうかを確認します。
AKS サービス プリンシパルまたはマネージド ID に、Azure リソースへのネットワーク変更を行うために必要な AKS サービスアクセス許可 があるかどうかを確認します。
エンドポイントの DNS 解決が成功したかどうかを確認する
ポッド内から、エンドポイントへの DNS 参照を実行できます。
kubectl exec コマンドを実行してポッドに接続し、DNS Utils パッケージをインストールできない場合はどうすればよいですか? この状況では、 問題のあるポッドと同じ名前空間でテスト ポッドを開始し、テストを実行できます。
注:
DNS 解決またはエグレス トラフィックで必要なネットワーク パッケージをインストールできない場合は、docker イメージを rishasi/ubuntu-netutil:1.0
使用できます。 このイメージでは、必要なパッケージが既にインストールされています。
DNS 解決を確認する手順の例を次に示します。
問題のあるポッドと同じ名前空間でテスト ポッドを開始します。
kubectl run -it --rm aks-ssh --namespace <namespace> --image=debian:stable
テスト ポッドが実行されると、ポッドにアクセスできます。
次
apt-get
のコマンドを実行して、他のツール パッケージをインストールします。apt-get update -y apt-get install dnsutils -y apt-get install curl -y apt-get install netcat -y
パッケージがインストールされたら、 nslookup コマンドを実行して、エンドポイントへの DNS 解決をテストします。
$ nslookup microsoft.com Server: 10.0.0.10 Address: 10.0.0.10#53 ... ... Name: microsoft.com Address: 20.53.203.50
アップストリーム 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
コマンドを
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
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"
kubectl exec コマンドを実行して、PowerShell を使用してポッドに接続します。
kubectl exec -it dnsutil-win powershell
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 設定を確認します。 次の手順を実行します。
メンテナンスまたはトラブルシューティングのために Azure Kubernetes Service (AKS) クラスター ノードに接続します。
エンドポイントへの 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
resolv.conf ファイルを調べて、予想されるネーム サーバーが追加されているかどうかを確認します。
cat /etc/resolv.conf cat /run/systemd/resolve/resolv.conf
DNS 解決を伴う 1 つの異常なシナリオでは、DNS クエリはノードから正しい応答を取得しますが、ポッドから失敗します。 このシナリオでは、 ポッド内から DNS 解決エラーを確認することを検討しますが、ワーカー ノードからは確認しないでください。 クラスター全体のエンドポイントの DNS 解決を検査する場合は、クラスター 全体で DNS 解決の状態を確認することを検討できます。
DNS 解決が成功した場合は、ネットワーク テストに進みます。 それ以外の場合は、クラスターの DNS 構成を確認します。
クラスターがネットワーク経由でエンドポイントに到達できるかどうかを確認する
クラスターからネットワーク経由でエンドポイントに到達できるかどうかを判断するには、次の手順に従います。
エンドポイントへのルートを確認して、特定の操作でタイムアウトがあるかどうかを判断します。
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
目的のポートがリモート ホストで開かれているかどうかを確認します。
nc -z -v microsoft.com 443
HTTP 応答コードを確認します。
curl -Iv https://microsoft.com
他のエンドポイントに接続できるかどうかを確認します。
curl -Iv https://kubernetes.io
サードパーティのお問い合わせ窓口に関する免責事項
Microsoft では、このトピックに関する追加情報を見つけるのに役立つサード パーティの連絡先情報を提供しています。 将来予告なしに変更されることがあります。 Microsoft は、第三者の連絡先情報の正確性を保証しません。
お問い合わせはこちらから
質問がある場合やヘルプが必要な場合は、サポート要求を作成するか、Azure コミュニティ サポートにお問い合わせください。 Azure フィードバック コミュニティに製品フィードバックを送信することもできます。