カスタム ネットワーク セキュリティ グループによってトラフィックがブロックされる
Azure Kubernetes Service (AKS) クラスターでホストされているアプリケーションにアクセスすると、"タイムアウト" というエラー メッセージが表示されます。 このエラーは、アプリケーションが実行されていて、残りの構成が正しいと思われる場合でも発生する可能性があります。
前提条件
Kubernetes kubectl ツールまたは同様のツールを使用してクラスターに接続します。 Azure CLI を使用して kubectl をインストールするには、az aks install-cli コマンドを実行します。
クライアント URL (cURL) ツール、または同様のコマンド ライン ツール。
パッケージを処理するための apt-get コマンド ライン ツール。
現象
次の kubectl get コマンドと cURL コマンドを実行すると、次のコンソール出力のような "タイムアウト" エラーが発生します。
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
my-deployment-66648877fc-v78jm 1/1 Running 0 5m53s
$ kubectl get service
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
my-loadbalancer-service LoadBalancer 10.0.107.79 10.81.x.x 80:31048/TCP 4m14s
$ curl -Iv http://10.81.124.39 # Use an IP address that fits the "EXTERNAL-IP" pattern.
* Trying 10.81.x.x:80...
* connect to 10.81.x.x port 80 failed: Timed out
* Failed to connect to 10.81.x.x port 80 after 21033 ms: Timed out
* Closing connection 0
curl: (28) Failed to connect to 10.81.x.x port 80 after 21033 ms: Timed out
原因
毎回同じ "タイムアウト" エラーが発生する場合は、通常、ネットワーク コンポーネントがトラフィックをブロックしていることを示唆しています。
この問題をトラブルシューティングするには、まずポッドへのアクセスを確認してから、 インサイドアウト アプローチでクライアントに移動します。
ポッドをチェックするには、次kubectl getのコマンドと kubectl describe コマンドを実行します。
$ kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE
my-deployment-66648877fc-v78jm 1/1 Running 0 53s 172.25.0.93 aks-agentpool-42617579-vmss000000
$ kubectl describe pod my-deployment-66648877fc-v78jm # Specify the pod name from the previous command.
...
...
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 117s default-scheduler Successfully assigned default/my-deployment-66648877fc-v78jm to aks-agentpool-42617579-vmss000000
Normal Pulling 116s kubelet Pulling image "httpd"
Normal Pulled 116s kubelet Successfully pulled image "httpd" in 183.532816ms
Normal Created 116s kubelet Created container webserver
Normal Started 116s kubelet Started container webserver
この出力に基づいて、ポッドは再起動せずに正しく実行されているようです。
テスト ポッドを開き、アプリケーション ポッドへのアクセスをチェックします。 次kubectl getの 、kubectl run、、apt-getおよび cURL コマンドを実行します。
$ kubectl get pods -o wide # Get the pod IP address.
NAME READY STATUS RESTARTS AGE IP NODE
my-deployment-66648877fc-v78jm 1/1 Running 0 7m45s 172.25.0.93 aks-agentpool-42617579-vmss000000
$ kubectl run -it --rm aks-ssh --image=debian:stable # Launch the test pod.
If you don't see a command prompt, try pressing enter.
$ root@aks-ssh:
$ # Install packages inside the test pod.
$ root@aks-ssh: apt-get update -y && apt-get install dnsutils -y && apt-get install curl -y
Get:1 http://deb.debian.org/debian bullseye InRelease [116 kB]
Get:2 http://deb.debian.org/debian bullseye-updates InRelease [39.4 kB]
...
...
Running hooks in /etc/ca-certificates/update.d...
done.
$ # Try to check access to the pod using the pod IP address from the "kubectl get" output.
$ curl -Iv http://172.25.0.93
* Trying 172.25.0.93:80...
* Connected to 172.25.0.93 (172.25.0.93) port 80 (#0)
...
...
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
...
...
* Connection #0 to host 172.25.0.93 left intact
ポッドに直接アクセスできます。 そのため、アプリケーションが実行されています。
定義されたサービスは型です LoadBalancer 。 つまり、エンド クライアントからポッドへの要求フローは次のようになります。
クライアント >> ロード バランサー >> AKS ノード >> アプリケーション ポッド
この要求フローでは、次のコンポーネントを介してトラフィックをブロックできます。
- クラスター内のネットワーク ポリシー
- AKS サブネットと AKS ノードのネットワーク セキュリティ グループ (NSG)
ネットワーク ポリシーをチェックするには、次kubectl getのコマンドを実行します。
$ kubectl get networkpolicy --all-namespaces
NAMESPACE NAME POD-SELECTOR AGE
kube-system konnectivity-agent app=konnectivity-agent 3h8m
AKS の既定のポリシーのみが存在します。 そのため、ネットワーク ポリシーはトラフィックをブロックしていないようです。
AKS を使用して NSG とそれに関連付けられているルールをチェックするには、次の手順に従います。
Azure portalで、[仮想マシン スケール セット] を検索して選択します。
スケール セット インスタンスの一覧で、使用しているインスタンスを選択します。
スケール セット インスタンスのメニュー ウィンドウで、 を選択します
Networking。
スケール セット インスタンス の [ネットワーク ] ページが表示されます。 [ 受信ポート規則 ] タブには、スケール セット インスタンスに対して動作する 2 つの NSG に基づく 2 つのルール セットが表示されます。
最初のセットは、サブネット レベルの NSG ルールで構成されます。 これらのルールは、次のメモ見出しの下に表示されます。
ネットワーク セキュリティ グループ <my-aks-nsg> (サブネットに接続: <my-aks-subnet>)
この配置は、AKS クラスターのカスタム仮想ネットワークとカスタム サブネットが使用される場合に一般的です。 サブネット レベルの規則のセットは、次の表のようになります。
優先度 名前 ポート プロトコル ソース Destination (転送先) アクション 65000 AllowVnetInBound 任意 任意 VirtualNetwork VirtualNetwork 許可 65001 AllowAzureLoadBalancerInBound 任意 任意 AzureLoadBalancer 任意 許可 65500 DenyAllInBound 任意 任意 任意 任意 拒否 2 番目のセットは、ネットワーク アダプター レベルの NSG 規則で構成されます。 これらのルールは、次のメモ見出しの下に表示されます。
ネットワーク セキュリティ グループ aks-agentpool-agentpool-number-nsg<> (ネットワーク インターフェイスに接続: aks-agentpool-vm-scale-set-number-vmss<>)
この NSG は AKS クラスターによって適用され、AKS によって管理されます。 対応する規則のセットは、次の表のようになります。
優先度 名前 ポート プロトコル ソース Destination (転送先) アクション 500 <guid-TCP-80-Internet> 80 TCP インターネット 10.81.x。X 許可 65000 AllowVnetInBound 任意 任意 VirtualNetwork VirtualNetwork 許可 65001 AllowAzureLoadBalancerInBound 任意 任意 AzureLoadBalancer 任意 許可 65500 DenyAllInBound 任意 任意 任意 任意 拒否
ネットワーク アダプター レベルでは、IP アドレス 10.81 の TCP の NSG 受信規則があります。x。ポート 80 の x (表で強調表示されています)。 ただし、サブネット レベルの NSG のルールには、同等のルールがありません。
AKS がカスタム NSG にルールを適用しなかったのはなぜですか? AKS は NSG をそのサブネットに適用せず、そのサブネットに関連付けられている NSG は変更されないためです。 AKS は、ネットワーク アダプター レベルでのみ NSG を変更します。 詳細については、「 AKS で NSG を構成できますか?」を参照してください。
ソリューション
アプリケーションで特定のポートへのアクセスが有効になっている場合は、カスタム NSG でそのポートをルールとして許可していることを確認する Inbound 必要があります。 サブネット レベルでカスタム NSG に適切なルールが追加されると、アプリケーションにアクセスできます。
$ curl -Iv http://10.81.x.x
* Trying 10.81.x.x:80...
* Connected to 10.81.x.x (10.81.x.x) port 80 (#0)
...
...
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
...
...
* Connection #0 to host 10.81.x.x left intact
お問い合わせはこちらから
質問がある場合やヘルプが必要な場合は、サポート要求を作成するか、Azure コミュニティ サポートにお問い合わせください。 Azure フィードバック コミュニティに製品フィードバックを送信することもできます。
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示