TKGS クラスタ ネットワーク エラーのトラブルシューティングについては、このセクションのヒントを参照してください。
ノード ネットワークの確認
各 TKG クラスタには、次のネットワーク リソースが必要です。
| ネットワーク オブジェクト | ネットワーク リソース | 説明 | トラブルシューティング | コマンド |
|---|---|---|---|---|
| VirtualNetwork | Tier-1 ルーターと、リンクされたセグメント | クラスタのノード ネットワーク | SNAT IP が割り当てられていることを確認します | kubectl get virtualnetwork -n NS-NAME |
| VirtualNetworkInterface | セグメントの論理ポート | クラスタ ノードのノード ネットワーク インターフェイス | 各 VirtualMachine に IP アドレスがあることを確認します | kubectl get virtualmachines -n NS-NAME NODE-NAME |
制御プレーンのロード バランサの確認
TKG クラスタ制御プレーンのロード バランサは、Kubernetes API サーバへのアクセスを提供します。このロード バランサは、クラスタの作成時にシステムによって自動的にプロビジョニングされます。次のリソースが必要です。
制御プレーン ロード バランサのステータスを調べると、エラーが発生したときにリソースの準備ができていたかどうかを理解するのに役立ちます。通常、このロード バランサを検索するには、スーパーバイザー クラスタに対して
kubectl get services -A | grep control-plane-service というコマンドを使用します。
| ネットワーク オブジェクト | ネットワーク リソース | 説明 | トラブルシューティング | コマンド |
|---|---|---|---|---|
| VirtualMachineService | 該当なし | VirtualMachineService が作成され、k8s サービスに変換されます。 | ステータスが更新され、ロード バランサの仮想 IP (VIP) が含まれていることを確認します。 | kubectl get virtualmachineservices -n NS-NAME SERVICE-NAME |
| サービス | VirtualServer インスタンスおよび関連付けられているサーバ プール（メンバー プール）があるロード バランサ サーバ | TKG クラスタ API サーバにアクセスするために、ロード バランサ タイプの Kubernetes サービスが作成されます。 | 外部 IP アドレスが割り当てられていることを確認します。LB サービスの外部 IP を介して TKG クラスタ API にアクセスできることを確認します。 |
スーパーバイザー名前空間：
kubectl get services -A | grep control-plane-service
クラスタ名前空間：
kubectl get services -n NS-NAME
どちらかの名前空間
curl -k https://EXTERNAL-IP:PORT/healthz |
| エンドポイント | エンドポイント メンバー（TKG クラスタ制御プレーン ノード）は、メンバー プールに含まれている必要があります。 | すべての TKG クラスタ制御プレーン ノードを含むように、エンドポイントが作成されます。 | kubectl get endpoints -n NS-NAME SERVICE-NAME |
ワーカー ノード上のロード バランサ サービスの確認
LoadBalancer タイプの Kubernetes サービスが作成されるときに、TKG クラスタ ワーカー ノードのロード バランサ インスタンスがユーザーによって作成されます。
最初の手順は、クラウド プロバイダが TKG クラスタ上で実行されていることを確認することです。
kubectl get pods -n vmware-system-cloud-provider
関連する Kubernetes オブジェクトが作成され、正しい状態になっていることを確認します。
| ネットワーク オブジェクト | ネットワーク リソース | 説明 | コマンド |
|---|---|---|---|
| スーパーバイザー上の VirtualMachineService | 該当なし | VirtualMachineService がスーパーバイザーで作成され、スーパーバイザーで Kubernetes サービスに変換されます | kubectl get virtualmachineservice -n NS-NAME SVC-NAME |
| スーパーバイザー上のロード バランサ サービス | TKG クラスタ ロード バランサ内の VirtualServer、および関連付けられているメンバー プール。 | ロード バランサ サービスは、この LB タイプのサービスにアクセスするために、スーパーバイザー上に作成されます | kubectl get services -n NS-NAME SVC-NAME |
| スーパーバイザー上のエンドポイント | エンドポイント メンバー（TKG クラスタ ワーカー ノード）は、NSX のメンバー プールに含まれている必要があります。 | すべての TKG クラスタ ワーカー ノードを含むように、エンドポイントが作成されます | # kubectl get endpoints -n NS-NAME SVC-NAME |
| TKG クラスタのロード バランサ サービス | 該当なし | ユーザーによってデプロイされた TKG クラスタのロード バランサ サービスは、ステータスがロード バランサの IP で更新される必要があります | kubectl get services |
スーパーバイザー NSX ネットワーク スタックの確認
Kubernetes API サーバ、NCP ポッド、および任意のコントローラ ポッドで実行されるマネージャ コンテナは、インフラストラクチャ ネットワークの問題を確認するための主要な開始点になります。
次のエラー メッセージは、ESXi ホストの NIC が接続されている物理プロトコル グループなどのネットワーク ファブリックの任意のポイントで、ルーティングまたは MTU の問題が発生していることを示します。
{"log":"I0126 19:40:15.347154 1 log.go:172] http: TLS handshake error from
100.64.128.1:4102: EOF\n","stream":"stderr","time":"2021-01-26T19:40:15.347256146Z"}
トラブルシューティングを行うには、ESXi ホストに SSH 接続し、次のコマンドを実行します。
esxcli network ip interface ipv4 get
このコマンドは、ホストのすべての vmkernel インターフェイスを一覧表示します。TEP インターフェイスを 1 つ使用している場合、インターフェイスは常に vmk10 になります。2 番目または 3 番目の TEP インターフェイスを使用している場合、インターフェイスは vmk11 と vmk12 などになります。作成される TEP インターフェイスの数は、アップリンク プロファイルで TEP に割り当てたアップリンクの数によって異なります。アップリンク間の TEP に「ロード共有」を選択した場合は、アップリンクごとに TEP インターフェイスが 1 つ作成されます。
TEP 間で行われる主要な ping コマンドの構文は、次のとおりです。
vmkping ++netstack=vxlan -s 1572 -d -I vmk10 10.218.60.66
ここで、
-sはパケット サイズです-dは断片化しないという意味です-Iは、リンクの送信元が vmk10 であることを意味しますIP addressは、ping を送信している別の ESXi ホストまたは NSX Edge 上の TEP インターフェイスです
