TKGS クラスタをプロビジョニングできない場合は、この一般的なエラーのリストを確認してトラブルシューティングを行います。

クラスタ API ログの確認

TKG クラスタを作成できない場合は、CAPW/V が機能していることを確認します。

CAPW/V コントローラは、クラスタ API のインフラストラクチャ固有の実装です。CAPW/V を有効にするには、スーパーバイザー を使用します。CAPW/V は TKG のコンポーネントであり、TKG クラスタのライフサイクルを管理します。

CAPW/V は、VirtualNetwork の作成と更新を行います。VirtualNetwork の準備ができている場合にのみ、クラスタ ノードの作成を進めることができます。クラスタ作成ワークフローは、このフェーズを通過しましたか。

CAPW/V は、VirtualMachineService の作成と更新を行います。VirtualMachineService は正常に作成されましたか。外部 IP は取得されましたか。クラスタ作成ワークフローは、このフェーズを通過しましたか。

これらの質問に答えるには、次のようにクラスタ API のログを調べます。 
kubectl config use-context tkg-cluster-ns
kubectl get pods -n vmware-system-capw  | grep capv-controller
kubectl logs -n vmware-system-capw -c manager capv-controller-manager-...

クラスタ仕様の検証エラー

YAML 仕様に従って、キー名にスペース文字を使用できます。これはスペースを含むスカラー文字列であり、引用符は必要ありません。

ただし、TKGS の検証では、キー名にスペース文字を使用することはできません。TKGS では、有効なキー名は、英数字、ダッシュ（key-name など）、アンダースコア（KEY_NAME など）、ドット（key.name など）のみで構成する必要があります。

クラスタ仕様でキー名にスペース文字を使用すると、TKGS クラスタはデプロイされません。vmware-system-tkg-controller-manager ログには次のエラー メッセージが記録されます。

Invalid value: \"Key Name\": a valid config key must consist of alphanumeric characters, '-', '_' or '.' (e.g. 'key.name', or 'KEY_NAME', or 'key-name', regex used for validation is '[-._a-zA-Z0-9]+')"

このエラーを修正するには、スペース文字を完全に削除するか、サポートされている文字に置き換えます。

TKG クラスタ YAML の適用時のエラー

TKG クラスタ YAML の適用時にエラーが発生した場合は、次のようにトラブルシューティングします。
クラスタ ネットワークが正しい状態でない
TKG クラスタのプロビジョニング ワークフローを理解します。
  • CAPV は、各 TKG クラスタ ネットワークに対して VirtualNetwork オブジェクトを作成します。
  • スーパーバイザー が NSX ネットワークを使用するように構成されている場合、NCP は VirtualNetwork オブジェクトを監視し、各 VirtualNetwork に対して NSX Tier-1 ルーターと NSX セグメントを作成します。
  • CAPV は VirtualNetwork のステータスをチェックし、準備ができたらワークフローの次の手順に進みます。

仮想マシン サービス コントローラは、CAPV によって作成されたカスタム オブジェクトを監視し、これらの仕様を使用して、TKG クラスタを構築する仮想マシンを作成および構成します。

NSX Container Plugin (NCP) は、Kubernetes API を介して etcd に追加されたネットワーク リソースを監視し、NSX で対応するオブジェクトの作成を調整するコントローラです。

これらの各コントローラは、スーパーバイザー 制御プレーン上で Kubernetes ポッドとして実行されます。ネットワークの問題のトラブルシューティングを実行するには、CAPV コントローラ ログ、仮想マシン サービス ログ、および NCP ログを確認します。

コンテナ ログを確認します。 name-XXXX は、実行したときの一意のポッド名です 
kubectl get pods -A
kubectl logs pod/name-XXXXX -c pod-name -n namesapce
制御プレーン ノード数が無効

スーパーバイザー 上の TKG クラスタでは、1 つまたは 3 つの制御プレーン ノードがサポートされています。別のレプリカ数を入力すると、クラスタのプロビジョニングが失敗します。

制御プレーン/ワーカー仮想マシンのストレージ クラスが無効
次のコマンドを実行します。 
kubectl describe ns <tkg-clsuter-namesapce>

TKG クラスタを作成する名前空間にストレージ クラスが割り当てられていることを確認します。そのストレージ クラスを参照する vSphere 名前空間 には ResourceQuota が必要で、そのストレージ クラスが スーパーバイザー 内にある必要があります。

スーパーバイザー にあるストレージ クラスと名前が一致することを確認します。vSphere 管理者として kubectl get storageclasses スーパーバイザー を実行します。WCP によって スーパーバイザー にストレージ プロファイルが適用されるときに、名前が変換されることがあります（ハイフンがアンダースコアになるなど）。

仮想マシン クラスが無効

クラスタ YAML で指定された値が、kubectl get virtualmachineclass によって返された仮想マシン クラスのいずれかと一致することを確認します。TKG クラスタではバインドされたクラスのみを使用できます。仮想マシン クラスは、vSphere 名前空間 に追加されるとバインドされます。

コマンド kubectl get virtualmachineclasses は スーパーバイザー 上のすべての仮想マシン クラスを返しますが、バインドされているクラスのみを使用できます。

TKR 分散が見つからない
次のようなエラーが表示される場合があります。 
“Error from server (unable to find Kubernetes distributions): 
admission webhook “version.mutating.tanzukubernetescluster.run.tanzu.vmware.com” 
denied the request: unable to find Kubernetes distributions”

これは、コンテンツ ライブラリの問題である場合があります。使用可能になっているものを一覧表示するには、kubectl get virtualmachineimages -A コマンドを使用します。結果として、コンテンツ ライブラリで使用可能になっているもの、同期されたもの、またはアップロードされたものが表示されます。

スーパーバイザー 上の TKG には、新しい TKR API と互換性がある新しい TKR 名があります。コンテンツ ライブラリ内の各 TKR に正しい名前を付ける必要があります。

コンテンツ ライブラリでの名前：photon-3-amd64-vmi-k8s-v1.23.8---vmware.2-tkg.1-zshippable

TKG クラスタ仕様での対応する名前：version: v1.23.8+vmware.2-tkg.1-zshippable

TKG YAML は適用されるが、仮想マシンが作成されない

TKG 2.0 クラスタ YAML が有効で適用されていても、ノード仮想マシンが作成されない場合は、次のようにトラブルシューティングを実行します。
CAPI/CAPV リソースの確認

TKG によって CAPI/CAPV レベルのリソースが作成されたかどうかを確認します。

  • CAPV によって VirtualMachine リソースが作成されたかどうかを確認します。
  • 仮想マシン オペレータ ログを確認して、仮想マシンが作成されなかった理由を調べます。たとえば、ESX ホストでのリソース不足のために OVF のデプロイが失敗した可能性があります。
  • CAPV と仮想マシン オペレータのログを確認します。
  • NCP ログを確認します。NCP は制御プレーンの VirtualNetwork、VirtualNetworkInterface、および LoadBalancer を認識します。これらのリソースに関連するエラーがあると、問題になる可能性があります。
仮想マシン サービスのエラー
仮想マシン サービスのエラー
  • 名前空間で kubectl get virtualmachineservices を実行します
  • 仮想マシン サービスは作成されましたか。
  • 名前空間で kubectl describe virtualmachineservices を実行します
  • 仮想マシン サービスでエラーが報告されていますか。
仮想ネットワークのエラー

名前空間で kubectl get virtualnetwork を実行します。

このクラスタのために仮想ネットワークが作成されますか。

名前空間で kubectl describe virtual network を実行します。

仮想マシンのために仮想ネットワーク インターフェイスが作成されますか。

TKG クラスタ制御プレーンが実行されていない

TKG 制御プレーンが実行されていない場合は、エラーが発生したときにリソースの準備ができていたかどうかを確認します。起動していないのは Join Node 制御プレーンですか。それとも Init Node ですか。また、プロバイダ ID がノード オブジェクトに設定されていないかどうかも確認します。
エラーが発生したときにリソースの準備ができていたかどうかを確認する

ログを調べる他に、関連オブジェクトのステータス (ControlPlaneLoadBalancer) を確認すると、エラーが発生したときにリソースの準備ができていたかどうかを理解するのに役立ちます。ネットワークのトラブルシューティングを参照してください。

起動していないのは Join Node 制御プレーンですか。それとも Init Node ですか。

ノード参加が正しく動作しない場合があります。特定の仮想マシンのノード ログを調べてください。初期ノードが正常に起動しない場合、クラスタにワーカー ノードと制御プレーン ノードがない可能性があります。

プロバイダ ID がノード オブジェクトに設定されていない

仮想マシンが作成された場合は、IP を持っているかどうかを確認し、cloud-init ログを調べます（kubeadm コマンドが適切に実行されているか）。

CAPI コントローラのログを確認して、問題が発生しているかどうかを確認します。それは、TKG クラスタで kubectl get nodes を使用して確認できます。その後、ノード オブジェクトにプロバイダ ID があるかどうかを確認します。

TKG ワーカー ノードが作成されない

TKG クラスタと制御プレーン仮想マシンが作成されても、ワーカーが作成されないか、他の仮想マシン オブジェクトが作成されない場合は、次の手順を試します。 
kubectl describe cluster CLUSTER-NAME

名前空間内の仮想マシン リソースを確認します。他に作成されたリソースはありますか。

ない場合は、CAPV ログを調べて、他の仮想マシン オブジェクトが作成されない理由を確認します。ブートストラップ データは使用できません。

CAPI がロード バランサを介して TKG クラスタ制御プレーン（ノード仮想マシンの IP アドレスを使用する NSX または外部ロード バランサを使用する Distributed Switch）と通信できない場合は、名前空間のシークレットを使用して TKG クラスタ kubeconfig を取得します。

名前空間のシークレットを使用して、TKG クラスタ kubeconfig を取得します。 
kubectl get secret -n <namespace> <tkg-cluster-name>-kubeconfig -o jsonpath='{.data.value}' | base64 -d 
> tkg-cluster-kubeconfig; kubectl --kubeconfig tkg-cluster-kubeconfig get pods -A

これが「接続が拒否されました」で失敗する場合は、制御プレーンが適切に初期化されなかった可能性があります。I/O タイムアウトが発生する場合は、kubeconfig で IP アドレスへの接続を確認します。

組み込みのロード バランサを使用する NSX：

  • 制御プレーン LB が起動し、アクセス可能であることを確認します。
  • LB に IP がない場合は、NCP ログと NSX-T ユーザー インターフェイスを調べて、関連するコンポーネントが正しい状態であるかどうかを確認します。（NSX-T LB、VirtualServer、ServerPool は、すべて健全な状態である必要があります）。
  • LB に IP アドレスがあっても、アクセスできない場合（curl -k https://<LB- VIP>:6443/healthz は不正なエラーを返します）。

    サービス外部 IP の LoadBalancer タイプが「保留中」状態の場合は、TKG クラスタがスーパーバイザー LB VIP を介してスーパーバイザー Kubernetes API と通信できることを確認します。IP アドレスの重複がないことを確認します。

TKG 制御プレーン ノードが健全な状態であるかどうかを確認します
  • TKG クラスタ制御プレーンがエラー（プロバイダ ID でノードを作成できないなど）を報告しているかどうかを確認します。
  • TKG クラスタ クラウド プロバイダがノードを正しいプロバイダ ID でマークしなかったため、CAPI はゲスト クラスタ ノードのプロバイダ ID とスーパーバイザー クラスタのマシン リソースを比較して検証することができません。
制御プレーン仮想マシンに SSH 接続するか、TKG クラスタ kubeconfig を使用して、TKG クラウド プロバイダ ポッドが実行中であることと、エラーがログに記録されているかどうかを確認します。 Kubernetes 管理者およびシステム ユーザーとしての TKG サービス クラスタへの接続を参照してください。 
kubectl get po -n vmware-system-cloud-provider
kubectl logs -n vmware-system-cloud-provider <pod name>

VMOP によって VirtualMachineService が正常に調整されなかった場合は、仮想マシン オペレータ ログを確認します。

NCP で NSX-T リソースを作成するときに問題が発生した場合は、NCP ログを確認します。

制御プレーンが適切に初期化されなかった場合は、仮想マシンの IP アドレスを特定します。ステータスには仮想マシンの IP が含まれている必要があります。 
kubectl get virtualmachine -n <namespace> <TKC-name>-control-plane-0 -o yaml
ssh vmware-system-user@<vm-ip> -i tkc-cluster-ssh
kubeadm によってログにエラーが記録されているかどうかを確認します。 
cat /var/log/cloud-init-output.log | less

プロビジョニングされた TKG クラスタが「作成中」フェーズで停止する

次のコマンドを実行して、クラスタのステータスを確認します。

kubectl get tkc -n <namespace>
kubectl get cluster -n <namespace> 
kubectl get machines -n <namespace>
KubeadmConfig がありましたが、CAPI がそれを見つけることができませんでした。vmware-system-capv のトークンに kubeadmconfig をクエリする適切な権限があるかどうかを確認しました。 
$kubectl --token=__TOKEN__ auth can-i get kubeadmconfig 
yes
コントローラ ランタイム キャッシュが更新されていない可能性があります。CAPI ウォッチ キャッシュが古く、新しいオブジェクトを取得していない可能性があります。必要に応じて、問題を解決するために capi-controller-manager を再起動します。 
kubectl rollout restart deployment capi-controller-manager -n vmware-system-capv

vSphere 名前空間 が「終了中」フェーズで停止する

バージョンの互換性の観点から、TKR、スーパーバイザー、および vCenter Server が同期していることを確認します。

名前空間は、名前空間の下のすべてのリソースが順番に削除された場合にのみ削除できます。 
kubectl describe namespace NAME

次のエラーが見つかりました：「サーバからのエラー（Kubernetes ディストリビューションが見つかりません）：アドミッション Webhook「version.mutating.tanzukubernetescluster.run.tanzu.vmware.com」が要求を拒否しました：Kubernetes ディストリビューションが見つかりません」

vCenter Server の仮想マシン イメージを確認します。 
kubectl get virtualmachineimages -A