トンネル接続の問題

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

注:

既定では、 と リージョンに応じて、トンネル コンポーネントは でした tunnel-front。 アップタイム サービス レベル アグリーメント (SLA) 機能に更新する場合、 tunnel-frontOpenVPN を使用するaks-linkトンネル コンポーネントに置き換えられました。 AKS は Konnectivity に移行しています。 これは、 と aks-linkの両方tunnel-frontを置き換える Kubernetes アップストリーム コンポーネントです。 トンネル コンポーネントとしての Konnectivity への移行の詳細については、 AKS のリリース ノートと変更ログを参照してください。

前提条件

• Azure CLI

現象

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

サーバーからのエラー: "https://< aks-node-name>:10250/containerLogs/<namespace>/<pod-name>/<container-name>": ダイヤル tcp <aks-node-ip>:10250: i/o タイムアウト

サーバーからのエラー: バックエンドのダイヤル エラー: 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 をブロックしている

注:

この原因は、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 portalイメージは、セキュリティ規則の例を示しています。

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

注:

• [優先度] フィールドは、それに応じて調整する必要があります。 たとえば、複数のポート (ポート 10250 を含む) を拒否するルールがある場合、イメージに表示されるルールの優先度は低くなります (数値が小さい方が優先順位が高くなります)。 優先度の詳細については、「セキュリティ 規則」を参照してください。

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

原因 2: 複雑化されていないファイアウォール (UFW) ツールがポート 10250 をブロックしている

注:

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

単純なファイアウォール (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: 複雑化されていないファイアウォールを無効にする

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 規則を削除する

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

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 が開かない

注:

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

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

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

解決策 4: ポート 1194 または 9000 を開く

仮想アプライアンスでポート 1194 またはポート 9000 へのアクセスが許可されていることを確認します。 必要な規則と依存関係の詳細については、「 Azure Global required network rules」を参照してください。

原因 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 ポートを表示するには、次の手順に従います。

1. Azure portalで、Kubernetes サービスを検索して選択します。

2. Kubernetes サービスの一覧で、クラスターの名前を選択します。

3. クラスターのメニュー ウィンドウで、[ 設定] 見出しを見つけて、[プロパティ] を選択 します。

4. [ インフラストラクチャ リソース グループ] の下に一覧表示されている名前を選択します。

5. kubernetes ロード バランサーを選択します。

6. ロード バランサーのメニュー ウィンドウで、[ 監視 ] 見出しを見つけて、[ メトリック] を選択します。

7. メトリックの種類として、[ SNAT 接続数] を選択します。

8. [ 分割の適用] を選択します。

9. [ 分割方法] を [接続状態] に設定します。

サービス 診断

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

1. Azure portalで、Kubernetes サービスを検索して選択します。

2. Kubernetes サービスの一覧で、クラスターの名前を選択します。

3. クラスターのメニュー ウィンドウで、[ 問題の診断と解決] を選択します。

4. [ 接続の問題] を選択します。

5. [ SNAT 接続とポートの割り当て] で、[ 詳細の表示] を選択します。

6. 必要に応じて、[ 時間範囲 ] ボタンを使用して時間枠をカスタマイズします。

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

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

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

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

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

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

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

Microsoft では、このトピックに関する追加情報を見つけるのに役立つサード パーティの連絡先情報を提供しています。 将来予告なしに変更されることがあります。 Microsoft は、第三者の連絡先情報の正確性を保証しません。

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

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