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

[アーティクル]
12/18/2024

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

前提条件

Kubernetes kubectl ツール、またはクラスターに接続するための同様のツール。 Azure CLI を使用して kubectl をインストールするには、az aks install-cli コマンドを実行します。
パッケージを処理するための apt-get コマンドラインツール。
クライアント URL (cURL) ツール、または同様のコマンドラインツール。
DNS 解決を確認するための nslookup コマンドライン (dnsutils) ツール。

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

AKS クラスター内から送信されたトラフィックは、ポッドまたはワーカーノードのいずれからのトラフィックであっても、クラスターからの送信トラフィックと見なされます。 AKS クラスターの送信フローに問題がある場合はどうしますか? トラブルシューティングを行う前に、まず送信トラフィックフローのシナリオを確認してください。

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

同じクラスター内のポッドまたはサービスへのトラフィック (内部トラフィック) 。
同じ仮想ネットワーク内のデバイスまたはエンドポイント、または仮想ネットワークピアリングを使用する別の仮想ネットワークへのトラフィック。
VPN 接続または Azure ExpressRoute 接続を介したオンプレミス環境へのトラフィック。
Azure Load Balancer 経由の AKS ネットワーク外のトラフィック (パブリック送信トラフィック)。
Azure Firewall またはプロキシサーバー (パブリック送信トラフィック) 経由の AKS ネットワーク外のトラフィック。

内部トラフィック

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

Azure Load Balancer を介したパブリック送信トラフィック

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

Azure Firewall またはプロキシサーバーを介したパブリック送信トラフィック

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

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

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

トラブルシューティングの際の考慮事項

エグレスデバイスを確認する

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

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

また、フローは宛先によって異なる場合もあります。たとえば、内部トラフィック (つまり、クラスター内) はエグレスデバイスを経由しません。内部トラフィックでは、クラスターネットワークのみが使用されます。パブリック送信トラフィックの場合は、エグレスデバイスが通過しているかどうかを判断し、そのデバイスを確認します。

トラフィックフロー内の各ホップを確認する

エグレスデバイスを特定した後、次の要因を確認します。

要求のソースと宛先。
ソースと宛先の間にホップインします。
要求/応答フロー。
次のレイヤーなど、追加のセキュリティ層によって強化されるホップ。
- ファイアウォール
- ネットワークセキュリティグループ (NSG)
- ネットワークポリシー

問題のあるホップを識別するには、応答コードの前後を確認します。パケットが特定のホップで正しく到着するかどうかを確認するには、パケットキャプチャを続行できます。

HTTP 応答コードを確認する

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

クライアントとサーバーからパケットキャプチャを取得する

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

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

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

ドメインネームシステム (DNS) 解決がエンドポイントに対して正しく機能することを確認します。
IP アドレスを介してエンドポイントに到達できることを確認します。
別のソースからエンドポイントに到達できることを確認します。
そのエンドポイントが動作中であることを確認します。
クラスターが他の外部エンドポイントに到達できるかどうかを確認します。
ネットワークポリシーがトラフィックをブロックしているかどうかを確認します。
NSG がトラフィックをブロックしているかどうかを確認します。
ファイアウォールまたはプロキシがトラフィックをブロックしているかどうかを確認します。
AKS サービスプリンシパル ID またはマネージド ID に、Azure リソースへのネットワーク変更を行うために必要な AKS サービスのアクセス許可があるかどうかを確認します。

Note

基本的なトラブルシューティングを行うときは、サービスメッシュがないことを前提としています。 Istio などのサービスメッシュを使用すると、TCP ベースのトラフィックに対して通常とは異なる結果が生成されます。

ポッドとノードがエンドポイントに到達できるかどうかを確認する

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

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

Note

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

Linux ポッドの DNS 解決を確認する手順の例

問題のあるポッドと同じ名前空間でテストポッドを開始します。
```
kubectl run -it --rm aks-ssh --namespace <namespace> --image=debian:stable --overrides='{"spec": { "nodeSelector": {"kubernetes.io/os": "linux"}}}'
```
テストポッドが稼働した後、そのポッドにアクセスできるようになります。
次の apt-get コマンドを実行して、他のツールパッケージをインストールします。
```
# Update and install tool packages
apt-get update && apt-get install -y dnsutils curl
```

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

$ nslookup microsoft.com # Microsoft.com is used as an example
Server:         <server>
Address:        <server IP address>#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

場合によっては、クラスター DNS ではなくエンドポイント自体に問題があります。このような場合は、次のチェックを検討してください。

目的のポートがリモートホストで開かれているかどうかを確認します。
```
curl -Ivm5 telnet://microsoft.com:443
```
HTTP 応答コードを確認します。
```
curl -Ivm5 https://microsoft.com
```
他のエンドポイントに接続できるかどうかを確認します。
```
curl -Ivm5 https://kubernetes.io
```

問題のあるポッドが存在するノードからエンドポイントに到達可能であることを確認し、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
```

Windows ポッドの DNS 解決を確認する手順の例

Windows ノードプールでテストポッドを実行します。

# For a Windows environment, use the Resolve-DnsName cmdlet.
kubectl run dnsutil-win --image='mcr.microsoft.com/windows/servercore:ltsc2022' --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 解決を伴う 1 つの異常なシナリオでは、DNS クエリはノードから正しい応答を取得しますが、ポッドから失敗します。このシナリオでは、ポッド内から DNS 解決エラーをチェック、ワーカーノードからはチェックしないことを検討してください。クラスター全体のエンドポイントの DNS 解決を検査する場合は、クラスター全体で DNS 解決の状態チェックすることを検討できます。

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

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

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

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

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

次の方法で共有

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

前提条件

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

内部トラフィック

Azure Load Balancer を介したパブリック送信トラフィック

Azure Firewall またはプロキシサーバーを介したパブリック送信トラフィック

トラブルシューティングの際の考慮事項

エグレスデバイスを確認する

トラフィックフロー内の各ホップを確認する

HTTP 応答コードを確認する

クライアントとサーバーからパケットキャプチャを取得する

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

ポッドとノードがエンドポイントに到達できるかどうかを確認する

Linux ポッドの DNS 解決を確認する手順の例

Windows ポッドの DNS 解決を確認する手順の例

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

フィードバック

その他のリソース

次の方法で共有

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

前提条件

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

内部トラフィック

Azure Load Balancer を介したパブリック送信トラフィック

Azure Firewall またはプロキシ サーバーを介したパブリック送信トラフィック

トラブルシューティングの際の考慮事項

エグレス デバイスを確認する

トラフィック フロー内の各ホップを確認する

HTTP 応答コードを確認する

クライアントとサーバーからパケット キャプチャを取得する

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

ポッドとノードがエンドポイントに到達できるかどうかを確認する

Linux ポッドの DNS 解決を確認する手順の例

Windows ポッドの DNS 解決を確認する手順の例

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

フィードバック

その他のリソース

Azure Firewall またはプロキシサーバーを介したパブリック送信トラフィック

エグレスデバイスを確認する

トラフィックフロー内の各ホップを確認する

クライアントとサーバーからパケットキャプチャを取得する