トンネル接続の問題
Microsoft Azure Kubernetes Service (AKS) は、ノードとコントロール プレーンの間のトンネリングされた安全な通信に特定のコンポーネントを使用します。 トンネルは、コントロール プレーン側のサーバーとクラスター ノード側のクライアントで構成されます。 この記事では、AKS のトンネル接続に関連する問題のトラブルシューティングと解決方法について説明します。
Note
以前は、AKS トンネル コンポーネントが tunnel-frontされていました。 これで、アップストリームの Kubernetes コンポーネントである Konnectivity サービスに移行されました。 この移行の詳細については、 AKS のリリース ノートと変更ログを参照してください。
前提条件
現象
ポート 10250 に関する次の例のようなエラー メッセージが表示されます。
サーバーからのエラー: "https://<aks-node-name>:10250/containerLogs/<namespace>/<pod-name>/<container-name>": tcp <aks-node-ip>:10250: i/o timeout
サーバーからのエラー: バックエンドのダイヤル エラー: tcp <aks-node-ip>:10250: i/o タイムアウトをダイヤルする
Kubernetes API サーバーは、ポート 10250 を使用してノードの kubelet に接続してログを取得します。 ポート 10250 がブロックされている場合、kubectl ログとその他の機能は、トンネル コンポーネントがスケジュールされているノードで実行されるポッドに対してのみ機能します。 詳細については、「 Kubernetes のポートとプロトコル: ワーカー ノード」を参照してください。
トンネル コンポーネントまたはサーバーとクライアントの間の接続を確立できないため、次のような機能は期待どおりに機能しません。
アドミッション コントローラー Webhook
ログ取得の機能 ( kubectl logs コマンドを使用)
コンテナーでのコマンドの実行またはコンテナー内の取得 ( kubectl exec コマンドを使用)
ポッドの 1 つ以上のローカル ポートの転送 ( kubectl port-forward コマンドを使用)
原因 1: ネットワーク セキュリティ グループ (NSG) がポート 10250 をブロックしている
Note
この原因は、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 に設定されています。](media/tunnel-connectivity-issues/add-inbound-security-rule.png)
より制限を厳しくする場合は、サブネット レベルでのみポート 10250 へのアクセスを許可できます。
Note
Priority フィールドは、それに応じて調整する必要があります。 たとえば、複数のポート (ポート 10250 を含む) を拒否するルールがある場合、画像に表示されるルールの優先度は低くする必要があります (数値が小さい方が優先順位が高くなります)。 Priorityの詳細については、「セキュリティ規則」を参照してください。
このソリューションを適用した後に動作の変更が表示されない場合は、トンネル コンポーネント ポッドを再作成できます。 これらのポッドを削除すると、ポッドが再作成されます。
原因 2: 未コンパイルファイアウォール (UFW) ツールがポート 10250 をブロックしている
Note
この原因は、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 サポート ポリシー (特に ノードのメンテナンスとアクセス) を確認して、クラスターがサポートされていないシナリオに入らないようにします。
Note
ソリューションの適用後に動作の変更が表示されない場合は、トンネル コンポーネント ポッドを再作成できます。 これらのポッドを削除すると、ポッドが再作成されます。
解決策 2a: 未コンパイルのファイアウォールを無効にする
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 をブロックしている
Note
この原因は、AKS クラスターに存在するすべてのトンネル コンポーネントに適用されます。
iptables ツールを使用すると、システム管理者は Linux ファイアウォールの IP パケット フィルター規則を構成できます。 ポート 10250 の通信をブロックするように iptables 規則を構成できます。
ノードのルールを表示して、ポート 10250 がブロックされているか、関連付けられているパケットが破棄されているかを確認できます。 これを行うには、次の iptables コマンドを実行します。
iptables --list --line-numbers
出力では、データは、INPUT チェーンを含む複数のチェーンにグループ化されます。 各チェーンには、次の列見出しの下にルールのテーブルが含まれています。
num(ルール番号)targetprot(プロトコル)optsourcedestination
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 --help コマンドを実行してiptables のマニュアルを確認することをお勧めします。
重要
このツールを使用して変更を加える前に、 AKS サポート ポリシー (特に ノードのメンテナンスとアクセス) を確認して、クラスターがサポートされていないシナリオに入らないようにします。
原因 4: エグレス ポート 1194 または 9000 が開いていない
Note
この原因は、 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) ポート不足
Note
この原因は、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 クラスターを作成するを参照してください。
サードパーティのお問い合わせ窓口に関する免責事項
サードパーティのお問い合わせ窓口に関する情報は、ユーザーの便宜のために提供されているものであり、 この連絡先情報は、予告なしに変更される可能性があります。 マイクロソフトは、掲載されている情報に対して、いかなる責任も負わないものとします。
お問い合わせはこちらから
質問がある場合やヘルプが必要な場合は、サポート要求を作成するか、Azure コミュニティ サポートにお問い合わせください。 Azure フィードバック コミュニティに製品フィードバックを送信することもできます。