本主題含有一些可協助您對獨立管理叢集部署進行疑難排解的提示。
如需疑難排解工作負載叢集的相關資訊,請參閱疑難排解工作負載叢集問題。有關此版本中已知問題的其他解決辦法,請參閱版本資訊或 VMware 知識庫文章。
以下某些程序會使用 kind
CLI。若要安裝 kind
,請參閱 kind
說明文件中的安裝。
您可以使用 SSH 來連線到獨立管理叢集或工作負載叢集的個別節點。為此,您部署管理叢集時所建立的 SSH 金鑰配對,在您要執行 SSH 命令的機器上必須是可用的。因此,您必須在執行 tanzu
命令的機器上執行 ssh
命令。
您在管理叢集中登錄的 SSH 金鑰,以及您從管理叢集部署的任何工作負載叢集所使用的 SSH 金鑰,必須與以下使用者帳戶相關聯:
capv
ubuntu
ubuntu
ec2-user
capi
若要使用 SSH 來連線到節點,請從您作為啟動機器的機器,執行以下其中一個命令:
ssh capv@node-address
ssh ubuntu@node-address
ssh ec2-user@node-address
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
如果您刪除了 tanzu
CLI 所追蹤的管理叢集,請執行 tanzu config server delete
,從 tanzu
CLI 的狀態刪除這些叢集,如從 Tanzu CLI 組態中刪除管理叢集中所述。
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
問題
執行 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 上建立獨立管理叢集或工作負載叢集之前,您必須先接受涵蓋了叢集節點所用虛擬機器映像的法律條款。在未接受授權的情況下執行 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.
解決方案
如果發生此情況,請接受法律條款,然後重試:
問題
如果嘗試部署獨立管理叢集失敗,則您的雲端基礎結構中和啟動機器上會留下孤立物件。
解決方案
tanzu mc create
命令輸出。如果命令失敗,則會列印一則說明訊息,指出:「部署管理叢集時失敗… 若要清理管理叢集所建立的資源,請執行以下命令:tkg delete mc…。」tanzu mc delete YOUR-CLUSTER-NAME
。此命令會移除它在您的基礎結構和本機中建立的物件。您還可以使用以下所述的替代方法:
啟動機器清理:
若要移除 kind
叢集,請使用 kind
CLI。例如:
kind get clusters
kind delete cluster --name tkg-kind-example1234567abcdef
若要移除 Docker 物件,請使用 docker
CLI。例如,docker rm
、docker rmi
和 docker system prune -a --volumes
。
注意如果您執行的 Docker 程序與系統上的 Tanzu Kubernetes Grid 無關,請另行移除不需要的 Docker 物件。
目標平台清理:
AZURE_RESOURCE_GROUP
。使用核取方塊,以選取和刪除 Tanzu Kubernetes Grid 所建立的資源,這些資源會在其名稱中包含一個時間戳記。問題
在 AWS 上執行 tanzu mc delete
後,tanzu mc get
和其他 Tanzu CLI 命令不再列出已刪除的管理叢集,但:
cluster infrastructure is still being provisioned: VpcReconciliationFailed
。解決方案
當 TKG 使用過期或無效的 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
。
問題
執行 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 login --kubeconfig ~/.kube-tkg/config --context MGMT-CLUSTER-CONTEXT --name MGMT-CLUSTER
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.25.7
會發生這種情況的原因是,Docker 桌面將舊版 kubectl
的符號連結到路徑中。
解決方案
請在路徑中,將較新的 kubectl
支援版本放置在 Docker 版本之前。
如果您遺失了獨立管理叢集的認證,例如,在無意中刪除了 tanzu
命令執行所在系統上的 .kube-tkg/config
檔案,您可以從管理叢集控制平面節點來復原認證。
tanzu mc create
,以重建 .kube-tkg/config
檔案。使用 SSH 來登入管理叢集控制平面節點。
如需瞭解用於每個目標平台的認證,請參閱上面的透過 SSH 連線到叢集節點。
存取管理叢集的 admin.conf
檔案。
sudo vi /etc/kubernetes/admin.conf
admin.conf
檔案含有叢集名稱、叢集使用者名稱、叢集內容,以及用戶端憑證資料。
.kube-tkg/config
命令執行所在系統上的 tanzu
檔案中。VSPHERE_CONTROL_PLANE_ENDPOINT
值問題
若要將外部身分識別提供者與現有 TKG 部署整合在一起,可能需要在用來建立附加元件密碼的管理叢集組態檔中,設定一個虛設的 VSPHERE_CONTROL_PLANE_ENDPOINT
值,如為管理叢集產生 Pinniped 附加元件密碼中所述
Secret
問題
當您在管理叢集上停用外部身分識別管理時,未用的 Pinniped Secret
物件仍存在於舊版工作負載叢集上。
之後若是使用者嘗試使用舊有 kubeconfig
來存取叢集,則會顯示登入快顯視窗,並且失敗。
因應措施
手動刪除舊版叢集的 Pinniped Secret
,如停用身分識別管理中所述。
問題
升級到 Tanzu Kubernetes Grid v2.2 時,傳回了類似如下的錯誤:
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
問題
您最近升級了管理叢集。當嘗試對此管理叢集相關聯的工作負載叢集進行驗證時,您收到類似如下的錯誤訊息:
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-info
ConfigMap 中取得 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-info
ConfigMap 中的 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=merge
macOS:
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
問題
當您在已建立的叢集上執行 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 命令時,傳回了類似如下的錯誤:
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) 中,Tanzu CLI 命令輸出 (採資料行格式) 在資料行標題中包含了無關字元。Windows 終端機或 PowerShell 中不會出現此問題。
解決方案
在 Windows 啟動機器上,從 Windows 終端機執行 Tanzu CLI。
問題
停用機器健全狀況檢查 (MHC) 後,在重建基礎結構期間,Tanzu CLI 命令 (例如 tanzu cluster status
) 可能不會報告最新的節點狀態。
解決方案
無。
問題
當您在 Windows 系統上執行 tanzu management-cluster create --ui
或 tanzu mc create --ui
命令時,UI 會在預設瀏覽器中開啟,但沒有套用圖形和樣式。會發生這種情況的原因是,Windows 登錄設定為 application/x-css
。
解決方案
regedit
,以開啟「登錄編輯程式」公用程式。HKEY_CLASSES_ROOT
,並選取 .js
。application/javascript
,然後按一下確定 (OK)。tanzu mc create --ui
命令,以重新啟動 UI。問題
如果您使用 NSX Advanced Load Balancer 來處理工作負載 (AVI_ENABLE
) 或控制平面 (AVI_CONTROL_PLANE_HA_PROVIDER
),Avi 控制器可能無法區分同名的叢集。
解決方案:
請為每個叢集設定唯一的 CLUSTER_NAME
值:即使是從不同的啟動機器來建立多個管理叢集,也不要使用相同的 CLUSTER_NAME
值。
問題
如果 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???
。
解決方案
可忽略此錯誤。如需更多資訊,請參閱此知識庫文章。
medium
和小型 Pod 上,Multus CNI 執行失敗問題
在 vSphere 上,如果工作負載叢集具有 medium
或小型工作節點,且這些節點將 Multus CNI 套件與 NSX ALB 搭配執行,則可能因 Insufficient CPU
或其他錯誤而失敗。
解決方案
若要將 Multus CNI 與 NSX ALB 搭配使用,在部署工作負載叢集時,請包含 large
或 extra-large
大小的工作節點。
問題
在 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 v2.2 中,將一般叢集轉換為 TKG 獨立管理叢集的元件會封裝在 Carvel 套件 tkg-pkg
中。最初建立於 TKG v1.3 或更早版本中的獨立管理叢集缺少一個組態密碼,而升級程序在安裝 tkg-pkg
時需要此密碼,從而導致升級失敗。
解決方案
針對建立於 TKG v1.3 或更早版本中的獨立管理叢集,執行升級獨立管理叢集中列出的其他步驟。