kubectl またはその他のサード パーティ製ツールが API サーバーに接続するときの TCP タイムアウト

この記事では、microsoft Azure Kubernetes Service (AKS) の API サーバーへの接続に kubectl またはその他のサード パーティ製ツールを使用する場合に発生する TCP タイムアウトのトラブルシューティング方法について説明します。 AKS では、サービス レベルの目標 (SLA) とサービス レベル アグリーメント (SLA) を確保するために、コア数に基づいて垂直方向と水平方向にスケーリングされる高可用性 (HA) コントロール プレーンを使用します。

現象

接続タイムアウトが繰り返されます。

原因 1: ノード間プレーン通信を担当するポッドが実行されていない

いくつかの API コマンドだけが一貫してタイムアウトしている場合、次のポッドが実行中の状態ではない可能性があります。

• konnectivity-agent
• tunnelfront
• aks-link

これらのポッドは、ノードとコントロール プレーン間の通信を担当します。

解決策: ノード ホストの使用率またはストレスを軽減する

このポッドをホストするノードが過度に利用されていないか、ストレスが発生していないことを確認します。 ノードを独自の システム ノード プールに移動することを検討してください。

原因 2: 一部の必要なポート、FQDN、および IP アドレスでアクセスがブロックされる

必要なポート、完全修飾ドメイン名 (FQDN)、および IP アドレスがすべて開かれていない場合、いくつかのコマンド呼び出しが失敗する可能性があります。 API サーバーと kubelet (ポッドを介した konnectivity-agent ) 間の AKS でのセキュリティで保護されたトンネリングされた通信では、これらの項目の一部が正常に動作する必要があります。

解決策: 必要なポート、FQDN、および IP アドレスを開く

開く必要があるポート、FQDN、および IP アドレスの詳細については、「Azure Kubernetes Service (AKS)のクラスター ノードのエグレス トラフィックを制御する」を参照してください。

原因 3: Application-Layer プロトコル ネゴシエーション TLS 拡張機能がブロックされている

コントロール プレーンとノード間の接続を確立するには、ポッドには、konnectivity-agentApplication-Layer プロトコル ネゴシエーション (ALPN) のトランスポート層セキュリティ (TLS) 拡張機能が必要です。 以前にこの拡張機能をブロックしている可能性があります。

解決策: ALPN 拡張機能を有効にする

ポッドで ALPN 拡張機能を konnectivity-agent 有効にして、TCP タイムアウトを防ぎます。

原因 4: API サーバーの IP 承認範囲が現在の IP アドレスをカバーしていない

API サーバーで承認された IP アドレス範囲を使用する場合、IP が承認された範囲に含まれていない場合、API 呼び出しはブロックされます。

解決策: IP アドレスをカバーするように、承認された IP アドレス範囲を変更する

IP アドレスがカバーされるように、承認された IP アドレス範囲を変更します。 詳細については、「 クラスターの API サーバーの承認された IP 範囲を更新する」を参照してください。

原因 5: クライアントまたはアプリケーションが API サーバーへの呼び出しをリークする

GET 呼び出しが頻繁に発生すると、API サーバーが蓄積され、オーバーロードされる可能性があります。

解決策: GET 呼び出しの代わりにウォッチを使用しますが、アプリケーションがそれらの呼び出しをリークしないようにする

API サーバーへの GET 呼び出しを頻繁に行う代わりに、ウォッチを使用してください。 また、サード パーティ製アプリケーションがwatch接続や GET 呼び出しをリークしないようにする必要もあります。 たとえば、Istio マイクロサービス アーキテクチャでは、シークレットが内部的に読み取されるたびに、ミキサー アプリケーションのバグによって新しい API サーバー watch接続が作成されます。 この動作は一定の間隔で発生するため、watch接続はすぐに蓄積されます。 これらの接続により、スケーリング パターンに関係なく、最終的に API サーバーが過負荷になります。

原因 6: Helm デプロイのリリースが多すぎます

Helm (Kubernetes パッケージ マネージャー) のデプロイで使用するリリースが多すぎると、ノードのメモリ消費が多すぎます。 また、大量の ConfigMap (構成データ) オブジェクトが発生し、API サーバーで不要な使用量が急増する可能性があります。

解決策: 各リリースのリビジョンの最大数を制限する

各リリースのリビジョンの最大数は既定では無限であるため、コマンドを実行して、この最大数を適切な値に設定する必要があります。 Helm 2 の場合、コマンドは helm init です。 Helm 3 の場合、コマンドは Helm アップグレードです。 コマンドの実行時に --history-max <value> パラメーターを設定します。

原因 7: ノード間の内部トラフィックがブロックされている

AKS クラスター内のノード間に内部トラフィックのブロックが発生する可能性があります。

解決策: "ダイヤル tcp <Node_IP>:10250: i/o タイムアウト" エラーのトラブルシューティング

「ダイヤル tcp Node_IP>:10250: i/o タイムアウト」などの TCP <タイムアウトのトラブルシューティングに関するページを参照してください。

サードパーティの情報に関する免責事項

この資料に記載されているサードパーティ製品は、マイクロソフトと関連のない他社の製品です。 明示的か黙示的かにかかわらず、これらの製品のパフォーマンスや信頼性についてマイクロソフトはいかなる責任も負わないものとします。

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

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