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

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

現象

接続タイムアウトが繰り返し発生します。

原因 1: ノードとコントロール プレーンの通信を担当するポッドが実行されていない

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

• konnectivity-agent
• tunnelfront
• aks-link

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

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

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

konnectivity-agent ポッドがホストされているノードとノードの使用状況を確認するには、次のコマンドを実行します。

# Check which node the konnectivity-agent pod is hosted on
$ kubectl get pod -n kube-system -o wide
    
# Check the usage of the node hosting the pod
$ kubectl top node

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

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

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

開く必要があるポート、FQDN、IP アドレスの詳細については、「 Azure Kubernetes Service (AKS) クラスターの送信ネットワークと FQDN 規則を参照してください。

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

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

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

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

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

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

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

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

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

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

解決策: GET 呼び出しの代わりにウォッチを使用しますが、アプリケーションがそれらの呼び出しを漏らさないことを確認します

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

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

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

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

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

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

AKS クラスター内のノード間で内部トラフィックがブロックされている可能性があります。

解決策: "dial tcp <Node_IP>:10250: i/o timeout" エラーのトラブルシューティング

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

原因 8: クラスターがプライベートである

クラスターはプライベート クラスターですが、API サーバーにアクセスしようとしているクライアントは、AKS によって使用されるサブネットに接続できないパブリックまたは異なるネットワーク内にあります。

解決策: AKS サブネットにアクセスできるクライアントを使用する

クラスターはプライベートであり、そのコントロール プレーンは AKS サブネット内にあるので、AKS サブネットに接続できるネットワーク内に存在しない限り、API サーバーに接続することはできません。 これは予期される動作です。

この場合は、AKS サブネットと通信できるネットワーク内のクライアントから API サーバーにアクセスしてみてください。 さらに、ネットワーク 間のネットワーク セキュリティ グループ (NSG) またはその他のアプライアンスがパケットをブロックしていないことを確認します。

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

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

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

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