疑難排解管理叢集問題
本主題含有一些可協助您對獨立管理叢集部署進行疑難排解的提示。
如需疑難排解工作負載叢集的相關資訊，請參閱疑難排解工作負載叢集問題。有關此版本中已知問題的其他解決辦法，請參閱版本資訊或 VMware 知識庫文章。
必要條件
以下某些程序會使用 kind CLI。若要安裝 kind，請參閱 kind 說明文件中的安裝。
087Bf3b4 (Ghost (#1178) 的 RN更新）
一般工作
透過 SSH 連線到叢集節點
您可以使用 SSH 來連線到獨立管理叢集或工作負載叢集的個別節點。為此，您部署管理叢集時所建立的 SSH 金鑰配對，在您要執行 SSH 命令的機器上必須是可用的。因此，您必須在執行 tanzu 命令的機器上執行 ssh 命令。
您在管理叢集中登錄的 SSH 金鑰，以及您從管理叢集部署的任何工作負載叢集所使用的 SSH 金鑰，必須與以下使用者帳戶相關聯：
- 同時在 Photon OS 和 Ubuntu 上執行的 vSphere 管理叢集和 Tanzu Kubernetes 節點：
capv - AWS Bastion 節點：
ubuntu - 在 Ubuntu 上執行的 AWS 管理叢集和 Tanzu Kubernetes 節點：
ubuntu - 在 Amazon Linux 上執行的 AWS 管理叢集和 Tanzu Kubernetes 節點：
ec2-user - Azure 管理叢集和 Tanzu Kubernetes 節點 (一律是 Ubuntu)：
capi
若要使用 SSH 來連線到節點，請從您作為啟動機器的機器，執行以下其中一個命令：
- vSphere 節點：
ssh capv@node-address - Ubuntu 上的 AWS Bastion 節點以及管理叢集和工作負載節點：
ssh ubuntu@node-address - 在 Amazon Linux 上執行的 AWS 管理叢集和 Tanzu Kubernetes 節點：
ssh ec2-user@node-address - Azure 節點：
ssh capi@node-address
由於 SSH 金鑰存在於您執行 ssh 命令的系統上，因此不需要密碼。
使用 kubectl 來刪除使用者、內容和叢集
若要刪除某些或所有使用者、內容和叢集，以清理 kubectl 狀態，請執行下列動作：
-
開啟
~/.kube-tkg/config檔案。 -
針對您要刪除的
user物件，執行：kubectl config unset users.USERNAME --kubeconfig ~/.kube-tkg/config其中，
USERNAME是每個頂層user物件的name內容，如config檔案中所列。 -
針對您要刪除的
context物件，執行：kubectl config unset contexts.CONTEXT-NAME --kubeconfig ~/.kube-tkg/config其中，
CONTEXT-NAME是每個頂層context物件的name內容，如config檔案中所列，通常其格式為contexts.mycontext-admin@mycontext。 -
針對您要刪除的
cluster物件，執行：kubectl config unset clusters.CLUSTER-NAME --kubeconfig ~/.kube-tkg/config其中，
CLUSTER-NAME是每個頂層cluster物件的name內容，如config檔案中所列。 -
如果
config檔案將您已刪除的叢集列為目前內容，請取消設定該內容：kubectl config unset current-context --kubeconfig ~/.kube-tkg/config -
如果您刪除了
tanzuCLI 所追蹤的管理叢集，請執行tanzu context delete，從tanzuCLI 的狀態刪除這些叢集，如從 Tanzu CLI 組態中刪除管理叢集中所述。
在 Photon OS 節點上停用 nfs-utils
問題
在 Tanzu Kubernetes Grid v1.1.2 及更新版本中，依預設會啟用 nfs-utils。如果您不需要 nfs-utils，則可以將它從叢集節點虛擬機器中移除。
解決方案
若要在您使用 Tanzu Kubernetes Grid v1.1.2 或更新版本部署的叢集上停用 nfs-utils，請使用 SSH 來登入叢集節點虛擬機器，並執行以下命令：
tdnf erase nfs-utils
目標平台
CAPA 資源標記問題導致 AWS 管理叢集部署和升級期間重新調整失敗
問題
由於上游叢集 API 提供者 AWS (CAPA) 中的資源標記問題，離線部署無法存取 ResourceTagging API，從而導致在建立或升級管理叢集期間發生協調失敗。
解決方案
在離線 AWS 環境中，請先在本機環境或管理叢集組態檔中設定 EXP_EXTERNAL_RESOURCE_GC=false，之後再執行 tanzu mc create 或 tanzu mc upgrade。
驗證失敗，AWS 上出現認證錯誤
問題
執行 tanzu management-cluster create 或 tanzu mc create 失敗，並顯示類似如下的錯誤：
Validating the pre-requisites...
Looking for AWS credentials in the default credentials provider chain
Error: : Tkg configuration validation failed: failed to get AWS client: NoCredentialProviders: no valid providers in chain
caused by: EnvAccessKeyNotFound: AWS_ACCESS_KEY_ID or AWS_ACCESS_KEY not found in environment
SharedCredsLoad: failed to load shared credentials file
caused by: FailedRead: unable to open file
caused by: open /root/.aws/credentials: no such file or directory
EC2RoleRequestError: no EC2 instance role found
caused by: EC2MetadataError: failed to make EC2Metadata request
解決方案
Tanzu Kubernetes Grid 會使用預設 AWS 認證提供者鏈結。在 AWS 上建立管理叢集或工作負載叢集之前，您必須先依照設定 AWS 認證中所述，設定 AWS 帳戶認證。
驗證失敗，Azure 上出現法律條款錯誤
問題
在 Azure 上建立獨立管理叢集或工作負載叢集之前，您必須先接受涵蓋了叢集節點所用虛擬機器映像的法律條款。在未接受授權的情況下執行 tanzu mc create 或 tanzu cluster create 會失敗，且會顯示類似如下的錯誤：
User failed validation to purchase resources. Error message: 'You have not accepted the legal terms on this subscription: '*********' for this plan. Before the subscription can be used, you need to accept the legal terms of the image.
解決方案
如果發生此情況，請接受法律條款，然後重試：
- 管理叢集：請參閱接受基礎映像授權
- 工作負載叢集：請參閱部署具有非預設 Kubernetes 版本的叢集中的 Azure 指示。
管理叢集
管理叢集部署失敗後清理
問題
如果嘗試部署獨立管理叢集失敗，則您的雲端基礎結構中和啟動機器上會留下孤立物件。
解決方案
- 在終端機或 Tanzu Kubernetes Grid 安裝程式介面中監控
tanzu mc create命令輸出。如果命令失敗，則會列印一則說明訊息，指出：「部署管理叢集時失敗… 若要清理管理叢集所建立的資源，請執行以下命令：tkg delete mc…。」 - 執行
tanzu mc delete YOUR-CLUSTER-NAME。此命令會移除它在您的基礎結構和本機中建立的物件。
您還可以使用以下所述的替代方法：
-
啟動機器清理：
-
若要移除
kind叢集，請使用kindCLI。例如：kind get clusters kind delete cluster --name tkg-kind-example1234567abcdef -
若要移除 Docker 物件，請使用
dockerCLI。例如，docker rm、docker rmi和docker system prune -a --volumes。注意如果您執行的 Docker 程序與系統上的 Tanzu Kubernetes Grid 無關，請另行移除不需要的 Docker 物件。
-
-
目標平台清理：
- vSphere：找出 Tanzu Kubernetes Grid 所建立的虛擬機器和其他資源，關閉其電源並且刪除。
- AWS：登入 Amazon EC2 儀表板，然後手動或使用自動化解決方案來刪除資源。
- Azure：在資源群組 (Resource Groups) 中，開啟
AZURE_RESOURCE_GROUP。使用核取方塊，以選取和刪除 Tanzu Kubernetes Grid 所建立的資源，這些資源會在其名稱中包含一個時間戳記。
無法刪除 AWS 上的管理叢集
問題
在 AWS 上執行 tanzu mc delete 後，tanzu mc get 和其他 Tanzu CLI 命令不再列出已刪除的管理叢集，但：
- 不會從 AWS 基礎架構中刪除叢集，並且其節點仍顯示在 Amazon EC2 儀表板中
- 管理叢集日誌顯示錯誤
cluster infrastructure is still being provisioned: VpcReconciliationFailed。
解決方案
當 TKG 使用過期或無效的 AWS 帳戶認證時，會出現此行為。要防止或從這種情況中復原，請執行以下操作：
-
禁止：依照設定 AWS 帳戶認證中所述，使用 AWS 認證設定檔或本機靜態環境變數更新 AWS 帳戶認證。
- 無法使用 AWS 執行個體設定檔認證來刪除管理叢集。
-
使用 EC2 儀錶板進行復原：從 EC2 儀錶板手動刪除管理叢集節點
-
使用 CLI 進行復原：
-
在由於管理叢集刪除失敗而保留在啟動載入機器上的
kind叢集中，修正 AWS 認證祕密金鑰：kubectl get secret capa-manager-bootstrap-credentials -n capa-system -ojsonpath="{.data.credentials}"| base64 -d -
編輯祕密金鑰以包括 AWS 認證：
[default] aws_access_key_id = <key id> aws_secret_access_key = <access_key> region = <region> -
再次執行
tanzu mc delete。
-
刪除管理叢集後保留 Kind 叢集
問題
執行 tanzu mc delete 會移除管理叢集，但無法將本機 kind 叢集從啟動機器中刪除。
解決方案
-
列出所有正在執行的
kind叢集，然後移除類似於tkg-kind-unique_ID的叢集：kind delete cluster --name tkg-kind-unique_ID -
列出所有正在執行的叢集，並識別
kind叢集。docker ps -a -
複製
kind叢集的容器識別碼，並將其移除。docker kill container-ID
管理叢集部署失敗後機器停滯
問題
您的獨立管理叢集無法部署，因為機器停滯，正在等待修復。
解決方案
對於您在 dev 計劃下所部署的管理叢集 (此計劃只有一個控制平面節點)，您必須重新部署管理叢集。如果管理叢集有多個控制平面節點，您可以識別並刪除停滯的機器。
-
擷取管理叢集的狀態。例如：
kubectl -n tkg-system get cluster my-mgmt-cluster -o yaml -
從上一個步驟的輸出中尋找停滯機器的名稱。停滯的機器會標記為
WaitingForRemediation。例如，在下列輸出中，停滯機器的名稱為my-mgmt-cluster-zpc7t：status: conditions: - lastTransitionTime: "2021-08-25T15:44:23Z" message: KCP can't remediate if current replicas are less or equal then 1 reason: WaitingForRemediation @ Machine/my-mgmt-cluster-zpc7t severity: Warning status: "False" type: Ready -
增加控制平面節點的機器健全狀況檢查逾時值，使其大於預設值
5m。例如：tanzu cluster machinehealthcheck control-plane set my-cluster --mhc-name my-control-plane-mhc --unhealthy-conditions "Ready:False:10m,Ready:Unknown:10m"如需有關更新
MachineHealthCheck物件的詳細資訊，請參閱〈設定工作負載叢集的機器健全狀況檢查〉中的建立或更新MachineHealthCheck物件。 -
將
kubectl設定為管理叢集的內容。例如：kubectl config use-context mgmt-cluster-admin@mgmt-cluster -
刪除停滯的機器。
kubectl delete machine MACHINE-NAME其中，
MACHINE-NAME是您在先前步驟中找到的機器名稱。 -
等待
KubeadmControlPlane控制器重新部署機器。
還原 ~/.config/tanzu 目錄
問題
啟動機器上的 ~/.config/tanzu 目錄遭到意外刪除或損壞。Tanzu CLI 會建立並使用此目錄，如果沒有此目錄，就無法正常運作。
解決方案
若要還原 ~/.config/tanzu 目錄的內容，請執行以下動作：
-
若要識別現有 Tanzu Kubernetes Grid 管理叢集，請執行：
kubectl --kubeconfig ~/.kube-tkg/config config get-contexts命令輸出會列出 Tanzu CLI 所建立或新增的所有管理叢集的名稱和內容。
-
針對輸出中列出的每一個管理叢集，執行以下命令，將它還原到
~/.config/tanzu目錄和 CLI：tanzu context create --management-cluster --kubeconfig ~/.kube-tkg/config --context MGMT-CLUSTER-CONTEXT --name MGMT-CLUSTER
在 macOS 上執行 tanzu management-cluster create 時，導致 kubectl 版本錯誤
問題
如果您在具有最新穩定版本的 Docker 桌面的 macOS 上執行 tanzu management-cluster create 或 tanzu mc create 命令，該命令會失敗，並顯示類似如下的錯誤訊息：
Error: : kubectl prerequisites validation failed: kubectl client version v1.15.5 is less than minimum supported kubectl client version 1.26.8
會發生這種情況的原因是，Docker 桌面將舊版 kubectl 的符號連結到路徑中。
解決方案
請在路徑中，將較新的 kubectl 支援版本放置在 Docker 版本之前。
復原管理叢集認證
如果您遺失了獨立管理叢集的認證，例如，在無意中刪除了 tanzu 命令執行所在系統上的 .kube-tkg/config 檔案，您可以從管理叢集控制平面節點來復原認證。
- 執行
tanzu mc create，以重建.kube-tkg/config檔案。 - 從 vSphere、AWS 或 Azure 取得管理叢集控制平面節點的公用 IP 位址。
-
使用 SSH 來登入管理叢集控制平面節點。
如需瞭解用於每個目標平台的認證，請參閱上面的透過 SSH 連線到叢集節點。
-
存取管理叢集的
admin.conf檔案。sudo vi /etc/kubernetes/admin.confadmin.conf檔案含有叢集名稱、叢集使用者名稱、叢集內容，以及用戶端憑證資料。 - 將叢集名稱、叢集使用者名稱、叢集內容和用戶端憑證資料，複製到
.kube-tkg/config命令執行所在系統上的tanzu檔案中。
Pinniped
將外部身分識別管理新增到現有部署時，可能需要設定虛設的 VSPHERE_CONTROL_PLANE_ENDPOINT 值
問題
若要將外部身分識別提供者與現有 TKG 部署整合在一起，可能需要在用來建立附加元件密碼的管理叢集組態檔中，設定一個虛設的 VSPHERE_CONTROL_PLANE_ENDPOINT 值，如為管理叢集產生 Pinniped 附加元件密碼中所述
如果停用 Pinniped，則需要在舊版叢集上手動刪除 Secret
問題
當您在管理叢集上停用外部身分識別管理時，未用的 Pinniped Secret 物件仍存在於舊版工作負載叢集上。
之後若是使用者嘗試使用舊有 kubeconfig 來存取叢集，則會顯示登入快顯視窗，並且失敗。
因應措施
手動刪除舊版叢集的 Pinniped Secret，如停用身分識別管理中所述。
部署後 Pinniped 工作失敗
問題
升級至 Tanzu Kubernetes Grid v2.3 傳回類似下列內容的錯誤：
Operation cannot be fulfilled on certificates.cert-manager.io "pinniped-cert": the object has been modified; please apply your changes to the latest version and try again
解決方案
如果 Pinniped 部署後工作會與元件的升級程序發生衝突，則可能會出現此錯誤。請遵循以下步驟來刪除並重新部署該工作。
-
刪除 Pinniped 部署後工作。
kubectl delete jobs.batch -n pinniped-supervisor pinniped-post-deploy-job -
等待大約 5 分鐘，讓
kapp-controller對部署後工作進行重新部署。 -
檢查 Pinniped 應用程式的狀態。
kubectl get app -n tkg-system pinniped NAME DESCRIPTION SINCE-DEPLOY AGE pinniped Reconcile succeeded 5s 49m如果
DESCRIPTION顯示Reconciling，請等待幾分鐘，然後重新檢查。一旦顯示Reconcile succeeded，就可繼續執行下一個步驟。 -
檢查 Pinniped 部署後工作的狀態。
kubectl get jobs -n pinniped-supervisor NAME COMPLETIONS DURATION AGE pinniped-post-deploy-job-ver-1 1/1 9s 62s
升級管理叢集後，工作負載叢集上出現 Pinniped 驗證錯誤
問題
您最近升級了管理叢集。當嘗試對此管理叢集相關聯的工作負載叢集進行驗證時，您收到類似如下的錯誤訊息：
Error: could not complete Pinniped login: could not perform OIDC discovery for "https://IP:PORT": Get "https://IP:PORT/.well-known/openid-configuration": x509: certificate signed by unknown authority
解決方案
會發生這種情況的原因是，工作負載叢集正在使用的 Pinniped 主管 CA 服務包的複本已過期。若要更新主管 CA 服務包，請遵循以下步驟：
-
將
kubectl內容設定為管理叢集。 -
從
pinniped-infoConfigMap 中取得 base64 編碼的 CA 服務包和issuer端點：kubectl get configmap pinniped-info -n kube-public -o jsonpath={.data.issuer_ca_bundle_data} > /tmp/ca-bundle && kubectl get configmap pinniped-info -n kube-public -o jsonpath={.data.issuer} > /tmp/supervisor-endpoint -
從工作負載叢集的 Pinniped 附加元件密碼中取得
values.yaml區段：kubectl get secret WORKLOAD-CLUSTER-NAME-pinniped-addon -n WORKLOAD-CLUSTER-NAMESPACE -o jsonpath="{.data.values\.yaml}" | base64 -d > values.yaml此秘密金鑰位於管理叢集上。
-
在上面所建立的
values.yaml檔案中，更新supervisor_ca_bundle_data索引鍵，使其與pinniped-infoConfigMap 中的 CA 服務包相符。此外，請確定supervisor_svc_endpoint與issuer端點相符。 -
套用您的更新，方法是對所編輯的
values.yaml檔案進行 base64 編碼，並在工作負載叢集秘密金鑰中取代該檔案。此命令會因環境的作業系統而異。例如：Linux：
kubectl patch secret/WORKLOAD-CLUSTER-NAME-pinniped-addon -n WORKLOAD-CLUSTER-NAMESPACE -p "{\"data\":{\"values.yaml\":\"$(base64 -w 0 < values.yaml)\"}}" --type=mergemacOS：
kubectl patch secret/WORKLOAD-CLUSTER-NAME-pinniped-addon -n WORKLOAD-CLUSTER-NAMESPACE -p "{\"data\":{\"values.yaml\":\"$(base64 < values.yaml)\"}}" --type=merge -
在工作負載叢集上，確認 Pinniped 應用程式已成功協調所做的變更：
kubectl get app pinniped -n tkg-system -
對叢集進行驗證。例如：
kubectl get pods -A --kubeconfig my-cluster-credentials
網繭
由於 vCenter 連線問題，網繭在叢集上停滯在擱置狀態
問題
當您在已建立的叢集上執行 kubectl get pods -A 時，某些網繭停留在擱置狀態。
您在受影響的網繭上執行 kubectl describe pod -n pod-namespace pod-name，且看到以下事件：
n node(s) had taint {node.cloudprovider.kubernetes.io/uninitialized: true}, that the pod didn't tolerate
解決方案
確保已備妥連線和防火牆規則，以確保叢集與 vCenter 之間的通訊。如需瞭解防火牆連接埠和通訊協定需求，請參閱 VMware Ports and Protocols 中的 vSphere 清單。
Tanzu CLI
Tanzu CLI 無法連線至管理叢集
問題
執行 tanzu CLI 命令時，傳回了類似如下的錯誤：
Failed to invoke API on cluster : the server has asked for the client to provide credentials, retrying
解決方案
請參閱更新 Tanzu CLI 組態中的管理叢集憑證和無法在 Tanzu Kubernetes Grid 中使用 tkg/tanzu cli 命令來存取叢集。
Windows CMD：CLI 輸出資料行標題中的無關字元
問題
在 Windows 命令提示字元 (CMD) 中，Tanzu CLI 命令輸出 (採資料行格式) 在資料行標題中包含了無關字元。Windows 終端機或 PowerShell 中不會出現此問題。
解決方案
在 Windows 啟動機器上，從 Windows 終端機執行 Tanzu CLI。
當停用 MHC 時，CLI 暫時誤報了最近刪除的節點的狀態
問題
停用機器健全狀況檢查 (MHC) 後，在重建基礎結構期間，Tanzu CLI 命令 (例如 tanzu cluster status) 可能不會報告最新的節點狀態。
解決方案
無。
Tanzu Kubernetes Grid 安裝程式介面
Tanzu Kubernetes Grid UI 在 Windows 上無法正確顯示
問題
當您在 Windows 系統上執行 tanzu management-cluster create --ui 或 tanzu mc create --ui 命令時，UI 會在預設瀏覽器中開啟，但沒有套用圖形和樣式。會發生這種情況的原因是，Windows 登錄設定為 application/x-css。
解決方案
- 在 Windows 搜尋中，輸入
regedit，以開啟「登錄編輯程式」公用程式。 - 展開
HKEY_CLASSES_ROOT，並選取.js。 - 在內容類型 (Content Type) 上按一下滑鼠右鍵，並選取修改 (Modify)。
- 將該值設定為
application/javascript，然後按一下確定 (OK)。 - 再次執行
tanzu mc create --ui命令，以重新啟動 UI。
NSX Advanced Load Balancer
使用 NSX ALB 時，無法建立同名的叢集
問題
如果您使用 NSX Advanced Load Balancer 來處理工作負載 (AVI_ENABLE) 或控制平面 (AVI_CONTROL_PLANE_HA_PROVIDER)，Avi 控制器可能無法區分同名的叢集。
解決方案：
請為每個叢集設定唯一的 CLUSTER_NAME 值：即使是從不同的啟動機器來建立多個管理叢集，也不要使用相同的 CLUSTER_NAME 值。
向 NSX Advanced Load Balancer VIP 發出要求失敗，並顯示「無任何到主機的路由」訊息
問題
如果 LoadBalancer 類型的服務總數很大，且所有的服務引擎都部署在同一 L2 網路中，則向 NSX Advanced Load Balancer VIP 發出的要求可能失敗，並顯示 no route to host 訊息。
會發生這種情況的原因是，服務引擎上的預設 ARP 速率限制為 100。
解決方案
將 ARP 速率限制設定為更大的數字。此參數在 NSX Advanced Load Balancer Essentials 中無法調整，但在 NSX Advanced Load Balancer Enterprise Edition 中可以調整。
建立管理叢集期間，發生可忽略的 AKODeploymentConfig 錯誤
問題
執行 tanzu management-cluster create 以建立具有 NSX ALB 的管理叢集，會輸出錯誤 no matches for kind AKODeploymentConfig in version networking.tkg.tanzu.vmware.com/v1alpha1。
解決方案
可忽略此錯誤。如需更多資訊，請參閱此知識庫文章。
在具有 NSX Advanced Load Balancer 的 medium 和小型 Pod 上，Multus CNI 執行失敗
問題
在 vSphere 上，如果工作負載叢集具有 medium 或小型工作節點，且這些節點將 Multus CNI 套件與 NSX ALB 搭配執行，則可能因 Insufficient CPU 或其他錯誤而失敗。
解決方案
若要將 Multus CNI 與 NSX ALB 搭配使用，在部署工作負載叢集時，請包含 large 或 extra-large 大小的工作節點。
升級
在 Azure 上升級叢集失敗
問題
在 Azure 上，升級管理叢集和工作負載叢集失敗，並顯示 context deadline exceeded 或 unable to upgrade management cluster: error waiting for kubernetes version update for kubeadm control plane 等錯誤。發生這種情況的原因是，作業在 Azure 上的執行時間有時比在其他平台上還久。
解決方案
重新執行 tanzu management-cluster upgrade 或 tanzu cluster upgrade，並在 --timeout 旗標中指定更長的逾時值。預設逾時為 30m0s。
對於最初建立於 TKG v1.3 或更早版本中的獨立管理叢集，升級會失敗
問題
在 TKG v2.3 中，將一般叢集轉換為 TKG 獨立管理叢集的元件會封裝在 Carvel 套件 tkg-pkg 中。最初建立於 TKG v1.3 或更早版本中的獨立管理叢集缺少一個組態密碼，而升級程序在安裝 tkg-pkg 時需要此密碼，從而導致升級失敗。
解決方案
針對建立於 TKG v1.3 或更早版本中的獨立管理叢集，執行升級獨立管理叢集中列出的其他步驟。
