如果無法佈建 TKGS 叢集，請檢閱此常見錯誤清單以進行疑難排解。
檢查叢集 API 記錄
如果無法建立 TKG 叢集，請檢查 CAPW/V 是否正常運作。
CAPW/V 控制器是基礎結構特定的叢集 API 實作。透過 主管 啟用 CAPW/V。CAPW/V 是 TKG 的一個元件，負責管理 TKG 叢集的生命週期。
CAPW/V 負責建立和更新 VirtualNetwork。僅當 VirtualNetwork 準備就緒時，才能繼續建立叢集節點。叢集建立工作流程是否通過了此階段？
CAPW/V 負責建立和更新 VirtualMachineService。是否已成功建立 VirtualMachineService？是否取得了外部 IP？叢集建立工作流程是否通過了此階段？
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 叢集佈建工作流程：
- CAPV 為每個 TKG 叢集網路建立 VirtualNetwork 物件。
- 如果為 主管 設定了 NSX 網路，則 NCP 會監視 VirtualNetwork 物件，並為每個 VirtualNetwork 建立 NSX 第 1 層路由器和 NSX 區段。
- CAPV 檢查 VirtualNetwork 的狀態，並在準備就緒後繼續執行工作流程中的下一步。
虛擬機器服務控制器會監視 CAPV 建立的自訂物件，並使用這些規格建立和設定構成 TKG 叢集的虛擬機器。
NSX Container Plugin (NCP) 是一個控制器，用於監視透過 Kubernetes API 新增到 etcd 的網路資源，並有組織地建立 NSX 相應物件。
每個控制器都在 主管 控制平面上作為 Kubernetes 網繭執行。若要對網路問題進行疑難排解，請檢查 CAPV 控制器記錄、虛擬機器服務記錄和 NCP 記錄。
- 控制平面節點計數無效
-
主管 上的 TKG 叢集支援 1 或 3 個控制平面節點。如果輸入不同的複本數，叢集佈建將失敗。
- 控制平面/worker 虛擬機器的儲存區類別無效
-
執行下列命令：
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-zshippableTKG 叢集規格中的對應名稱：
version: v1.23.8+vmware.2-tkg.1-zshippable
已套用 TKG 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 叢集控制平面未執行
- 檢查發生錯誤時資源是否已準備就緒
-
除了查找記錄外，檢查相關物件的狀態 ControlPlaneLoadBalancer 也有助於瞭解發生錯誤時資源是否已準備就緒。請參閱「網路疑難排解」。
- 它是未啟動的加入節點控制平面還是 Init 節點？
-
節點有時無法正常加入。查看特定虛擬機器的節點記錄。如果 init 節點未成功啟動，則叢集可能缺少 worker 節點和控制平面節點。
- 未在節點物件中設定提供者識別碼
-
如果已建立虛擬機器，請檢查它是否具有 IP，然後查看 cloud-init 記錄 (已正確執行 kubeadm 命令)
檢查 CAPI 控制器記錄以查看是否存在任何問題。您可以在 TKG 叢集上使用
kubectl get nodes進行檢查，然後檢查節點物件上是否存在提供者識別碼。
未建立 TKG worker 節點
kubectl describe cluster CLUSTER-NAME
檢查命名空間中的虛擬機器資源，是否建立了任何其他虛擬機器資源？
如果沒有，請檢查 CAPV 記錄，瞭解不建立其他虛擬機器物件的原因 (啟動程序資料不可用)。
如果 CAPI 無法透過負載平衡器 (具有節點虛擬機器 IP 的 NSX 或具有外部負載平衡器的 VDS) 與 TKG 叢集控制平面進行通訊，請使用命名空間中的密碼取得 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應傳回未經授權的錯誤)。如果 LoadBalancer 類型的服務外部 IP 處於「擱置中」狀態，請檢查 TKG 叢集是否可以透過主管 LB VIP 與主管 Kubernetes API 進行通訊。確保沒有 IP 位址重疊。
- 檢查 TKG 叢集控制平面是否報告任何錯誤 (例如，無法使用提供者識別碼建立節點)。
- TKG 叢集雲端提供者未使用正確的提供者識別碼標記節點，因此 CAPI 無法對客體叢集節點中的提供者識別碼和主管叢集中的機器資源進行比較，也就無法進行驗證。
kubectl get po -n vmware-system-cloud-provider
kubectl logs -n vmware-system-cloud-provider <pod name>
如果 VMOP 未成功協調 VirtualMachineService，請檢查虛擬機器運算子記錄。
如果 NCP 在建立 NSX-T 資源時出現問題，請檢查 NCP 記錄。
kubectl get virtualmachine -n <namespace> <TKC-name>-control-plane-0 -o yaml
ssh vmware-system-user@<vm-ip> -i tkc-cluster-ssh
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 中的 Token 是否具有查詢 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 是否同步。
kubectl describe namespace NAME
發生以下錯誤：「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
