トンネル接続の問題

2025-04-17

Microsoft Azure Kubernetes Service (AKS) は、ノードとコントロールプレーンの間のトンネリングされた安全な通信に特定のコンポーネントを使用します。トンネルは、コントロールプレーン側のサーバーとクラスターノード側のクライアントで構成されます。この記事では、AKS のトンネル接続に関連する問題のトラブルシューティングと解決方法について説明します。

注:

以前は、AKS トンネルコンポーネントが tunnel-frontされていました。これで、アップストリームの Kubernetes コンポーネントである Konnectivity サービスに移行されました。この移行の詳細については、 AKS のリリースノートと変更ログを参照してください。

前提条件

Azure CLI

症状

ポート 10250 に関する次の例のようなエラーメッセージが表示されます。

サーバーへの接続エラー: 「https://<aks-node-name>:10250/containerLogs/<namespace>/<pod-name>/<container-name>」: ダイヤル TCP <aks-node-ip>:10250: 入出力タイムアウト

サーバーからのエラー: バックエンドへの接続エラー: tcp <aks-node-ip>:10250: i/o タイムアウトが発生しました。

サーバーからのエラー: "https://<aks-node-name>:10250/containerLogs/<namespace>/<pod-name>/<container-name>": http: サーバーが HTTPS クライアントに HTTP 応答を与えました

Kubernetes API サーバーは、ポート 10250 を使用してノードの kubelet に接続してログを取得します。ポート 10250 がブロックされている場合、kubectl ログとその他の機能は、トンネルコンポーネントがスケジュールされているノードで実行されるポッドに対してのみ機能します。詳細については、「 Kubernetes のポートとプロトコル: ワーカーノード」を参照してください。

トンネルコンポーネントまたはサーバーとクライアントの間の接続を確立できないため、次のような機能は期待どおりに機能しません。

アドミッションコントローラーのウェブフック
ログ取得の機能 ( kubectl logs コマンドを使用)
コンテナーでコマンドを実行する、またはコンテナー内に入る (kubectl exec コマンドを使用)
ポッドの 1 つ以上のローカルポートの転送 ( kubectl port-forward コマンドを使用)

原因 1: ネットワークセキュリティグループ (NSG) がポート 10250 をブロックしている

注:

この原因は、AKS クラスターに存在する可能性があるトンネルコンポーネントに適用されます。

Azure ネットワークセキュリティグループ (NSG) を使用して、Azure 仮想ネットワーク内の Azure リソースとの間のネットワークトラフィックをフィルター処理できます。ネットワークセキュリティグループには、複数の種類の Azure リソース間の送受信ネットワークトラフィックを許可または拒否するセキュリティ規則が含まれています。各ルールには、送信元と宛先、ポート、プロトコルを指定できる。。詳しくは、「ネットワークセキュリティグループによってネットワークトラフィックをフィルター処理する方法」をご覧ください。

NSG が仮想ネットワークレベルでポート 10250 をブロックしている場合、トンネル機能 (ログやコード実行など) は、トンネルポッドがスケジュールされているノードでスケジュールされているポッドに対してのみ機能します。他のポッドは、ノードがトンネルに到達できず、トンネルが他のノードでスケジュールされているため、機能しません。この状態を確認するには、 netcat (nc) または telnet コマンドを使用して接続をテストできます。 az vmss run-command invoke コマンドを実行して接続テストを実行し、成功するか、タイムアウトしたか、または他の問題が発生するかを確認できます。

az vmss run-command invoke --resource-group <infra-or-MC-resource-group> \
    --name <virtual-machine-scale-set-name> \
    --command-id RunShellScript \
    --instance-id <instance-id> \
    --scripts "nc -v -w 2 <ip-of-node-that-schedules-the-tunnel-component> 10250" \
    --output tsv \
    --query 'value[0].message'

解決策 1: ポート 10250 へのアクセスを許可する NSG 規則を追加する

NSG を使用していて、特定の制限がある場合は、仮想ネットワークレベルでポート 10250 のトラフィックを許可するセキュリティ規則を必ず追加してください。次の Azure ポータルイメージは、セキュリティ規則の例を示しています。

Azure portal の [受信セキュリティ規則の追加] ウィンドウのスクリーンショット。新しいセキュリティ規則では、[宛先ポート範囲] ボックスが 10250 に設定されています。

より制限を厳しくする場合は、サブネットレベルでのみポート 10250 へのアクセスを許可できます。

注:

Priority フィールドは、それに応じて調整する必要があります。たとえば、複数のポート (ポート 10250 を含む) を拒否するルールがある場合、画像に表示されるルールの優先度は低くする必要があります (数値が小さい方が優先順位が高くなります)。 Priorityの詳細については、「セキュリティ規則」を参照してください。
このソリューションを適用した後に動作の変更が表示されない場合は、トンネルコンポーネントポッドを再作成できます。これらのポッドを削除すると、ポッドが再作成されます。

原因 2: 未コンパイルファイアウォール (UFW) ツールがポート 10250 をブロックしている

注:

この原因は、AKS クラスターに存在するすべてのトンネルコンポーネントに適用されます。

Uncomplicated Firewall (UFW) は、 netfilter ファイアウォールを管理するためのコマンドラインプログラムです。 AKS ノードでは Ubuntu が使用されます。そのため、UFW は既定で AKS ノードにインストールされますが、UFW は無効になっています。

既定では、UFW が有効になっている場合、ポート 10250 を含むすべてのポートへのアクセスがブロックされます。この場合、トラブルシューティングのために Secure Shell (SSH) を使用して AKS クラスターノードに接続できる可能性はほとんどありません。これは、UFW もポート 22 をブロックしている可能性があるためです。トラブルシューティングを行うには、 az vmss run-command invoke コマンドを実行して、UFW が有効になっているかどうかを確認する ufw コマンドを呼び出します。

az vmss run-command invoke --resource-group <infra-or-MC-resource-group> \
    --name <virtual-machine-scale-set-name> \
    --command-id RunShellScript \
    --instance-id <instance-id> \
    --scripts "ufw status" \
    --output tsv \
    --query 'value[0].message'

結果が UFW が有効になっていて、ポート 10250 が明示的に許可されていない場合はどうなりますか? この場合、UFW が有効になっているノードでスケジュールされているポッドでは、トンネル機能 (ログやコード実行など) は機能しません。この問題を解決するには、UFW に次のいずれかの解決策を適用します。

重要

このツールを使用して変更を加える前に、 AKS サポートポリシー (特にノードのメンテナンスとアクセス) を確認して、クラスターがサポートされていないシナリオに入らないようにします。

注:

ソリューションの適用後に動作の変更が表示されない場合は、トンネルコンポーネントポッドを再作成できます。これらのポッドを削除すると、ポッドが再作成されます。

解決策 2a: Uncomplicated Firewall (UFW) を無効にする

UFW を無効にするには、次の az vmss run-command invoke コマンドを実行します。

az vmss run-command invoke --resource-group <infra-or-MC-resource-group> \
    --name <virtual-machine-scale-set-name> \
    --command-id RunShellScript \
    --instance-id <instance-id> \
    --scripts "ufw disable" \
    --output tsv \
    --query 'value[0].message'

解決策 2b: ポート 10250 へのアクセスを許可するように、未コンパイルのファイアウォールを構成する

UFW でポート 10250 へのアクセスを許可するように強制するには、次の az vmss run-command invoke コマンドを実行します。

az vmss run-command invoke --resource-group <infra-or-MC-resource-group> \
    --name <virtual-machine-scale-set-name> \
    --command-id RunShellScript \
    --instance-id <instance-id> \
    --scripts "ufw allow 10250" \
    --output tsv \
    --query 'value[0].message'

原因 3: iptables ツールがポート 10250 をブロックしている

注:

この原因は、AKS クラスターに存在するすべてのトンネルコンポーネントに適用されます。

iptables ツールを使用すると、システム管理者は Linux ファイアウォールの IP パケットフィルター規則を構成できます。ポート 10250 の通信をブロックするように iptables 規則を構成できます。

ノードのルールを表示して、ポート 10250 がブロックされているか、関連付けられているパケットが破棄されているかを確認できます。これを行うには、次の iptables コマンドを実行します。

iptables --list --line-numbers

出力では、データは、チェーンを含む複数のINPUTにグループ化されます。各チェーンには、次の列見出しの下にルールのテーブルが含まれています。

num (ルール番号)
target
prot (プロトコル)
opt
source
destination

INPUT チェーンには、ターゲットがDROPされ、プロトコルがtcpされ、宛先がtcp dpt:10250されるルールが含まれていますか? その場合、 iptables は宛先ポート 10250 へのアクセスをブロックしています。

解決策 3: ポート 10250 でのアクセスをブロックする iptables 規則を削除する

次のいずれかのコマンドを実行して、ポート 10250 へのアクセスを禁止する iptables 規則を削除します。

iptables --delete INPUT --jump DROP --protocol tcp --source <ip-number> --destination-port 10250

iptables --delete INPUT <input-rule-number>

正確または潜在的なシナリオに対処するには、コマンドを実行してiptables --helpiptables のマニュアルを確認することをお勧めします。

重要

原因 4: エグレスポート 1194 または 9000 が開いていない

注:

この原因は、 tunnel-front ポッドと aks-link ポッドにのみ適用されます。

AKS ファイアウォールなど、エグレストラフィックの制限はありますか。存在する場合は、 tunnel-front ポッドの正しい機能を有効にするためにポート 9000 が必要です。同様に、 aks-link ポッドにはポート 1194 が必要です。

Konnectivity はポート 443 に依存します。既定では、このポートは開いています。そのため、そのポートでの接続の問題について心配する必要はありません。

解決策 4: ポート 9000 を開く

tunnel-frontは Konnectivity サービスに移動されましたが一部の AKS クラスターでは引き続きポート 9000 に依存するtunnel-frontが使用されます。仮想アプライアンスまたは任意のネットワークデバイスまたはソフトウェアがポート 9000 へのアクセスを許可していることを確認します。必要な規則と依存関係の詳細については、「 Azure グローバルに必要なネットワーク規則を参照してください。

原因 5: 送信元ネットワークアドレス変換 (SNAT) ポート不足

注:

この原因は、AKS クラスターに存在するすべてのトンネルコンポーネントに適用されます。ただし、プライベート AKS クラスターには適用されません。ソースネットワークアドレス変換 (SNAT) ポートの枯渇は、パブリック通信でのみ発生する可能性があります。プライベート AKS クラスターの場合、API サーバーは AKS 仮想ネットワークまたはサブネット内にあります。

SNAT ポートの枯渇が発生した場合 (失敗したSNAT ポート)、ノードは API サーバーに接続できません。トンネルコンテナーは API サーバー側にあります。そのため、トンネル接続は確立されません。

SNAT ポートリソースが使い果たされた場合、既存のフローが一部の SNAT ポートを解放するまで、送信フローは失敗します。フローが閉じると、Azure Load Balancer によって SNAT ポートが再利用されます。 4 分間のアイドルタイムアウトを使用して、アイドルフローから SNAT ポートを回収します。

次のセクションで説明するように、AKS ロードバランサーメトリックまたはサービス診断から SNAT ポートを表示できます。詳細については、「送信接続の統計情報を確認する方法」を参照してください。SNATポートを表示する方法に関してです。

AKS ロードバランサーのメトリック

AKS ロードバランサーメトリックを使用して SNAT ポートを表示するには、次の手順に従います。

Azure ポータルでKubernetes サービス検索して選択。
Kubernetes サービスの一覧で、クラスターの名前を選択します。
クラスターのメニューウィンドウで、 Settings 見出しを見つけて、 Properties を選択します。
Infrastructure リソースグループの下に一覧表示されている名前を選択します。
kubernetesロードバランサーを選択します。
ロードバランサーのメニューウィンドウで、 Monitoring 見出しを見つけて、 Metrics を選択します。
メトリックの種類として、 SNAT 接続数を選択します。
[分割の適用] を選択します。
Split by を Connection State に設定します。

サービス診断

サービス診断を使用して SNAT ポートを表示するには、次の手順に従います。

Azure ポータルでKubernetes サービス検索して選択。
Kubernetes サービスの一覧で、クラスターの名前を選択します。
クラスターのメニューウィンドウで Diagnose を選択し、問題を解決します。
接続の問題を選択します。
SNAT 接続とポートの割り当てで、詳細を表示を選択します。
必要に応じて、 Time Range ボタンを使用して時間枠をカスタマイズします。

解決策 5a: アプリケーションで接続プールが使用されていることを確認する

この動作は、アプリケーションが既存の接続を再利用していないために発生する可能性があります。要求ごとに 1 つの送信接続を作成しないことをお勧めします。このような構成は、接続の枯渇を引き起こす可能性があります。アプリケーションコードがベストプラクティスに従い、接続プールを使用しているかどうかを確認します。ほとんどのライブラリでは、接続プールがサポートされています。そのため、要求ごとに新しい送信接続を作成する必要はありません。

解決策 5b: 割り当てられた送信ポートを調整する

アプリケーション内で問題がなければ、割り当てられた送信ポートを調整する必要があります。送信ポートの割り当ての詳細については、「割り当てられた送信ポートを構成するを参照してください。

解決策 5c: クラスターの作成時にマネージドネットワークアドレス変換 (NAT) ゲートウェイを使用する

送信接続にマネージドネットワークアドレス変換 (NAT) ゲートウェイを使用するように新しいクラスターを設定できます。詳細については、「マネージド NAT ゲートウェイを使用して AKS クラスターを作成するを参照してください。

原因 6: クラスターの拡張に関する Konnectivity Agents のパフォーマンスの問題

クラスターの増加に伴い、ネットワークトラフィックの増加、要求の増加、またはリソースの制約により、Konnectivity Agents のパフォーマンスが低下する可能性があります。

注:

この原因は、 Konnectivity-agent ポッドにのみ適用されます。

解決策 6: Konnectivity エージェントのクラスタープロポーショナルオートスケーラー

大規模なクラスターでスケーラビリティの課題を管理するために、Konnectivity Agents のクラスター比例オートスケーラーを実装します。このアプローチは、業界標準とベストプラクティスに沿っています。これにより、最適なリソース使用量とパフォーマンスの向上が保証されます。

この変更が行われた理由 以前は、Konnectivity エージェントのレプリカ数が固定され、クラスターの成長に伴ってボトルネックが発生する可能性がありました。クラスター比例オートスケーラーを実装することで、レプリカ数をノードスケーリングルールに基づいて動的に調整し、最適なパフォーマンスとリソース使用量を提供できるようにします。

クラスター比例オートスケーラーのしくみ クラスター比例オートスケーラーの作業では、ラダー構成を使用して、クラスターサイズに基づいて Konnectivity エージェントレプリカの数を決定します。ラダー構成は、kube-system 名前空間の konnectivity-agent-autoscaler configmap で定義されます。ラダー構成の例を次に示します。

nodesToReplicas": [
    [1, 2],
    [100, 3],
    [250, 4],
    [500, 5],
    [1000, 6],
    [5000, 10]
]

この構成により、レプリカの数がクラスター内のノード数に合わせて適切にスケーリングされ、最適なリソース割り当てとネットワークの信頼性が向上します。

クラスタープロポーショナルオートスケーラーを使用する方法 kube-system 名前空間の konnectivity-agent-autoscaler configmap を更新することで、既定値をオーバーライドできます。 configmap を更新するサンプルコマンドを次に示します。

kubectl edit configmap <pod-name> -n kube-system

このコマンドを実行すると、エディターで configmap が開き、必要な変更を行うことができます。

確認する必要がある内容

クラスター比例オートスケーラーの誤った設定により、Konnectivityエージェントのメモリ割り当てが不十分になる可能性があるため、ノードのメモリ不足（OOM）による強制終了を監視する必要があります。この構成の誤りは、次の主な理由で発生します。

メモリ使用量が多い: クラスターが大きくなると、Konnectivity エージェントのメモリ使用量が大幅に増加する可能性があります。この増加は、特にピーク時、または多数の接続を処理する場合に発生する可能性があります。クラスター比例オートスケーラー構成でレプリカが適切にスケーリングされない場合、エージェントのメモリ不足が発生する可能性があります。

リソース制限の修正: Konnectivity エージェントのリソース要求と制限が低すぎると、ワークロードを処理するのに十分なメモリが不足し、OOM が強制終了する可能性があります。クラスタープロポーショナルオートスケーラーの設定が正しく構成されていないと、負荷を分散するのに十分なレプリカが提供されないため、この問題が悪化する可能性があります。

クラスターのサイズとワークロードの変動性: Konnectivity エージェントで必要な CPU とメモリは、クラスターのサイズとワークロードによって大きく異なる場合があります。クラスタープロポーショナルオートスケーラーのラダー構成が適切なサイズに調整されておらず、クラスターの使用パターンに応じて適応的にサイズ変更されていない場合、メモリが過剰に割り当てられ、OOM（Out Of Memory）による強制終了が発生する可能性があります。

OOM キルを特定してトラブルシューティングするには、次の手順に従います。

ノードで OOM Kills を確認する: 次のコマンドを使用して、ノードで OOM Kills を確認します。

kubectl get events --all-namespaces | grep -i 'oomkill'

ノードリソースの使用状況を調べる: ノードのリソース使用量を確認して、メモリが不足していないことを確認します。

kubectl top nodes

ポッドのリソース要求と制限を確認する: Konnectivity エージェントポッドに、OOMキルを防ぐために適切なリソース要求と制限が適切に設定されているか確認してください。

kubectl get pod <pod-name> -n kube-system -o yaml | grep -A5 "resources:"

リソース要求と制限の調整: 必要に応じて、デプロイを編集して Konnectivity エージェントポッドのリソース要求と制限を調整します。

kubectl edit deployment konnectivity-agent -n kube-system

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

マイクロソフトは、このトピックについて追加情報を見つけるための助けとして、サードパーティの連絡先情報を提供しています。この連絡先情報は予告なしに変更されることがあります。マイクロソフトは、第三者の連絡先情報の正確性について保証しません。

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

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