本節包含有助於對工作負載叢集進行疑難排解的提示。如需疑難排解獨立管理叢集部署的相關資訊,請參閱疑難排解管理叢集問題。
kubectl
來刪除使用者、內容和叢集若要刪除某些或所有使用者、內容和叢集,以清理 kubectl
狀態,請執行下列動作:
開啟 ~/.kube/config
檔案。
針對您要刪除的 user
物件,執行:
kubectl config unset users.USER-NAME
其中,USER-NAME
是每個頂層 user
物件的 name
內容,如 config
檔案中所列。
針對您要刪除的 context
物件,執行:
kubectl config unset contexts.CONTEXT-NAME
其中,CONTEXT-NAME
是每個頂層 context
物件的 name
內容,如 config
檔案中所列,格式通常是 contexts.mycontext-admin@mycontext
。
針對您要刪除的 cluster
物件,執行:
kubectl config unset clusters.CLUSTER-NAME
其中,CLUSTER-NAME
是每個頂層 cluster
物件的 name
內容,如 config
檔案中所列。
如果 config
檔案將您已刪除的叢集列為目前內容,請取消設定該內容:
kubectl config unset current-context
問題
如果嘗試通過產生預設 Grafana 組態檔來安裝 Grafana,安裝將失敗並顯示 error: Secret in version "v1" cannot be handled as a Secret: illegal base64 data at input byte 4 (reason: BadRequest)
。
解決方案
手動建立秘密金鑰,並使用不帶秘密金鑰標記的同一 YAML 檔案安裝 Grafana。
grafana.secret.*
項目。手動建立秘密金鑰。
kubectl create secret generic grafana -n tanzu-system-dashboards --from-literal=admin=admin
部署套件。
tanzu package install grafana \
--package grafana.tanzu.vmware.com \
--version AVAILABLE-PACKAGE-VERSION \
--values-file grafana-data-values.yaml \
--namespace TARGET-NAMESPACE
tanzu package repository
時出現錯誤問題
tanzu package repository
命令失敗並顯示錯誤。
解決方案
執行 kubectl get pkgr REPOSITORY-NAME -n NAMESPACE -o yaml
,以取得有關錯誤的詳細資料。
其中:
REPOSITORY-NAME
是套件存放庫的名稱。NAMESPACE
是套件存放庫的目標命名空間。tanzu package repository
命令可能失敗,並顯示類似如下的錯誤:
錯誤 | 說明 | 解決方案 |
---|---|---|
NOT_FOUND |
存放庫 URL 路徑無效。 | 確保可從您的叢集連線至套件存放庫的 URL。 |
UNKNOWN 或 UNAUTHORIZED |
嘗試連線至存放庫時,可能會發生此錯誤。 | |
Ownership |
叢集中已安裝具有相同套件存放庫 URL 的存放庫。 | 請執行下列其中一個動作:
|
tanzu package installed
時出現錯誤問題
tanzu package installed
命令失敗並顯示錯誤。
解決方案
執行 kubectl get pkgi INSTALLED-PACKAGE-NAME -n NAMESPACE -o yaml
,以取得有關錯誤的詳細資料。
其中:
INSTALLED-PACKAGE-NAME
是已安裝套件的名稱。NAMESPACE
是已安裝套件的命名空間。tanzu package installed
命令可能失敗,並顯示類似如下的錯誤:
錯誤 | 說明 | 解決方案 |
---|---|---|
Ownership |
叢集中已安裝相同名稱的套件。 | 執行 tanzu package installed list -A ,以檢查您要安裝的套件是否已安裝。若是如此,建議使用已安裝的套件、更新其版本或刪除套件,以便繼續安裝。 |
Evaluating starlark template |
當列出的組態值遺失時,可能會發生此錯誤。 | 執行 tanzu package available get AVAILABLE-PACKAGE-NAME/VERSION -n NAMESPACE –values-schema ,以查看所有可用的組態值,並將所需的組態值提供給 tanzu package install 命令。 |
Failed to find a package with name PACKAGE-NAME in namespace NAMESPACE |
目標命名空間中沒有指定的套件和套件中繼資料。 | 請確定指定的套件列在 tanzu package available list AVAILABLE-PACKAGE-NAME -n NAMESPACE 的輸出中。否則,請將包含套件的套件存放庫新增至目標命名空間。 |
Namespace NAMESPACE not found |
您要在其中安裝套件的命名空間不存在。 | 在 TKG v2.1 中,tanzu package 命令是以 kctrl 為基礎且不再支援 —create-namespace 旗標。在您安裝套件或套件存放庫之前,目標命名空間必須已經存在。 |
Provided service account SERVICE-ACCOUNT-NAME is already used by another package in namespace NAMESPACE |
service-account-name 旗標提供的服務帳戶已由另一個已安裝的套件使用。 |
請讓套件外掛程式為您建立服務帳戶,或選擇其他服務帳戶名稱。 |
問題
當您在已建立的叢集上執行 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 8 清單。
問題
執行 tanzu cluster create
失敗,並顯示類似於如下的逾時錯誤:
I0317 11:11:16.658433 clusterclient.go:341] Waiting for resource my-cluster of type *v1beta1.Cluster to be up and running
E0317 11:26:16.932833 common.go:29]
Error: unable to wait for cluster and get the cluster kubeconfig: error waiting for cluster to be created (this may take a few minutes): cluster control plane is still being initialized
E0317 11:26:16.933251 common.go:33]
解決方案
使用 --timeout
旗標來指定時間,以等待叢集建立完成。預設等待時間為 30 分鐘。
tanzu cluster create --timeout TIME
其中,TIME
是等待叢集建立完成的時間長度 (以分鐘為單位)。例如,60m
。
問題
tanzu cluster delete
無法刪除工作負載叢集。
若要手動刪除叢集,請參閱以下兩個解決方案。
解決方案 1
在目標叢集上,刪除在 avi-system
命名空間中執行的 AKO StatefulSet 物件:
kubectl delete sts ako -n avi-system
解決方案 2
登入叢集,並刪除工作節點機器:
kubectl delete machine worker1 worker2
在 vCenter 中,關閉工作節點虛擬機器的電源,並將其刪除。
編輯控制平面機器,並移除完成項連結:
finalizers:
- machine.cluster.x-k8s.io
刪除控制平面機器:
kubectl delete machine controlplane1 controlplane2
在 vCenter 中,關閉控制平面虛擬機器的電源,並將其刪除
問題
在叢集的工作節點上,如果「傳輸單元最大值 (MTU)」設定不同,會導致 TLS 信號交換逾時。
節點 journalctl -u kubelet
中的記錄顯示與 API 伺服器的通訊失敗。執行 kubectl get nodes
時,顯示了工作節點已變為 NotReady 狀態。
您可以執行以下動作,來重新確認該問題:
ip link
,並比較 eth0
介面的 MTU 值。如果不相符,表示存在此問題。確認當您在處於 NotReady 節點狀態的機器上執行以下命令時,這些命令失敗:
openssl s_client -connect IP:PORT
curl IP:PORT -k /healthz
其中,IP
和 PORT
是 Kubernetes API 伺服器控制平面端點的 IP 位址和連接埠號碼。依預設,PORT
會設定為 6443
。
解決方案
請檢閱部署在叢集上的有權限 Daemonset,並檢閱第三方廠商所提供的任何 Daemonset,其中可能修改了主機作業系統的網路組態。您可能需要諮詢軟體廠商,以瞭解這一點。可能修改主機作業系統的 Daemonset 會有 .spec.template.spec.hostNetwork: true
,或者在任何容器安全性內容的 [功能 (capabilities)] 欄位中具有 privileged: true
或 NET_ADMIN
。
如果您要設定較大的 MTU 設定,請在佈建叢集時,讓控制平面使用較高的 MTU 值。
請確定叢集網路允許進行路徑 MTU 探索或具有 TCP MSS 鉗制,以允許對外部服務 (例如 vCenter 或容器登錄) 進行正確的 MTU 大小調整。
請確定您為叢集中的所有節點所設定的 MTU 設定都相同。
網路防火牆設定必須允許具有所設定 MTU 大小的封包。