This site will be decommissioned on December 31st 2024. After that date content will be available at techdocs.broadcom.com.

 

疑難排解工作負載叢集問題

本節包含有助於對工作負載叢集進行疑難排解的提示。

如需疑難排解獨立管理叢集部署的相關資訊，請參閱疑難排解管理叢集問題。有關此版本中已知問題的其他解決辦法，請參閱版本資訊或 VMware 知識庫文章。

一般工作

使用 kubectl 來刪除使用者、內容和叢集

若要刪除某些或所有使用者、內容和叢集，以清理 kubectl 狀態，請執行下列動作：

  1. 開啟 ~/.kube/config 檔案。

  2. 針對您要刪除的 user 物件，執行：

    kubectl config unset users.USER-NAME

    其中，USER-NAME 是每個頂層 user 物件的 name 內容，如 config 檔案中所列。

  3. 針對您要刪除的 context 物件，執行：

    kubectl config unset contexts.CONTEXT-NAME

    其中，CONTEXT-NAME 是每個頂層 context 物件的 name 內容，如 config 檔案中所列，格式通常是 contexts.mycontext-admin@mycontext。

  4. 針對您要刪除的 cluster 物件，執行：

    kubectl config unset clusters.CLUSTER-NAME

    其中，CLUSTER-NAME 是每個頂層 cluster 物件的 name 內容，如 config 檔案中所列。

  5. 如果 config 檔案將您已刪除的叢集列為目前內容，請取消設定該內容：

    kubectl config unset current-context

套件

從預設 YAML 檔案安裝 Grafana 時未建立秘密金鑰

問題

如果嘗試通過產生預設 Grafana 組態檔來安裝 Grafana，安裝將失敗並顯示 error: Secret in version "v1" cannot be handled as a Secret: illegal base64 data at input byte 4 (reason: BadRequest)。

解決方案

手動建立秘密金鑰，並使用不帶秘密金鑰標記的同一 YAML 檔案安裝 Grafana。

  1. 執行部署 Grafana 到工作負載叢集中的步驟為 Grafana 組態建立組態檔。
  2. 從產生的組態檔中移除 grafana.secret.* 項目。

  3. 手動建立秘密金鑰。

    kubectl create secret generic grafana -n tanzu-system-dashboards  --from-literal=admin=admin

  4. 部署套件。

    tanzu package install grafana \
--package grafana.tanzu.vmware.com \
--version AVAILABLE-PACKAGE-VERSION \
--values-file grafana-data-values.yaml \
--namespace TARGET-NAMESPACE
  5. 執行部署 Grafana 到工作負載叢集中的其餘步驟。

執行 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 available list -n NAMESPACE，以查看您要安裝的套件是否已可供安裝。如果目前嘗試新增存放庫失敗，若要還原，請執行 tanzu package repository delete REPOSITORY-NAME -n NAMESPACE。
  • 執行 tanzu package repository list -A，以使用相同的 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 旗標提供的服務帳戶已由另一個已安裝的套件使用。 請讓套件外掛程式為您建立服務帳戶，或選擇其他服務帳戶名稱。

網繭

由於 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 8 清單。

儲存區

如果變更預設 StorageClass 物件，會導致工作負載叢集中的協調失敗

問題

如果修改 TKG 中包含的預設 StorageClass 物件的內容，會導致在使用該儲存區類別的工作負載叢集中，套件協調失敗。

解決方案：

若要自訂儲存區類別，請使用不同的 StorageClass 來建立新的 name 定義 (而不是修改預設物件定義)，然後將叢集重新設定為使用新的儲存區類別。

工作負載叢集

部署叢集時發生逾時，但已建立叢集

問題

執行 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

  1. 在目標叢集上，刪除在 avi-system 命名空間中執行的 AKO StatefulSet 物件：

    kubectl delete sts ako -n avi-system

解決方案 2

  1. 登入叢集，並刪除工作節點機器：

    kubectl delete machine worker1 worker2

  2. 在 vCenter 中，關閉工作節點虛擬機器的電源，並將其刪除。

  3. 編輯控制平面機器，並移除完成項連結：

    finalizers:
 - machine.cluster.x-k8s.io

  4. 刪除控制平面機器：

    kubectl delete machine controlplane1 controlplane2

  5. 在 vCenter 中，關閉控制平面虛擬機器的電源，並將其刪除

由於 MTU 不相符，叢集工作節點處於 NotReady 狀態

問題

在叢集的工作節點上，如果「傳輸單元最大值 (MTU)」設定不同，會導致 TLS 信號交換逾時。

節點 journalctl -u kubelet 中的記錄顯示與 API 伺服器的通訊失敗。執行 kubectl get nodes 時，顯示了工作節點已變為 NotReady 狀態。

您可以執行以下動作，來重新確認該問題：

  1. 在控制平面節點和工作節點機器上，執行 ip link，並比較 eth0 介面的 MTU 值。如果不相符，表示存在此問題。
  2. 請執行「當機診斷 (Crashd)」，並檢閱 kubelet 記錄，判斷連線是否逾時，或者工作節點是否處於 NotReady 狀態。如需執行 Crashd 的詳細資訊，請參閱透過當機診斷來疑難排解工作負載叢集

  3. 確認當您在處於 NotReady 節點狀態的機器上執行以下命令時，這些命令失敗：

    • openssl s_client -connect IP:PORT

    • curl IP:PORT -k /healthz

    其中，IP 和 PORT 是 Kubernetes API 伺服器控制平面端點的 IP 位址和連接埠號碼。依預設，PORT 會設定為 6443。

解決方案

  1. 請檢閱部署在叢集上的有權限 Daemonset，並檢閱第三方廠商所提供的任何 Daemonset，其中可能修改了主機作業系統的網路組態。您可能需要諮詢軟體廠商，以瞭解這一點。可能修改主機作業系統的 Daemonset 會有 .spec.template.spec.hostNetwork: true，或者在任何容器安全性內容的 [功能 (capabilities)] 欄位中具有 privileged: true 或 NET_ADMIN。

  2. 如果您要設定較大的 MTU 設定，請在佈建叢集時，讓控制平面使用較高的 MTU 值。

  3. 請確定叢集網路允許進行路徑 MTU 探索或具有 TCP MSS 鉗制，以允許對外部服務 (例如 vCenter 或容器登錄) 進行正確的 MTU 大小調整。

  4. 請確定您為叢集中的所有節點所設定的 MTU 設定都相同。

  5. 網路防火牆設定必須允許具有所設定 MTU 大小的封包。

使用 NSX ALB 時，無法建立同名的叢集

問題

如果您使用 NSX Advanced Load Balancer 來處理工作負載 (AVI_ENABLE) 或控制平面 (AVI_CONTROL_PLANE_HA_PROVIDER)，Avi 控制器可能無法區分同名的叢集。

解決方案：

請為每個叢集設定唯一的 CLUSTER_NAME 值：請勿建立多個具有相同 CLUSTER_NAME 且位於同一管理叢集命名空間 (如其 NAMESPACE 值所設定) 的工作負載叢集。

AVS 上的 vSphere CSI 磁碟區刪除可能會失敗

問題

在 Azure vSphere 解決方案 (AVS) 上，刪除 vSphere CSI 持續性磁碟區 (PV) 可能會失敗。刪除 PV 時，需要 cns.searchable 權限。未使用此權限來建立 AVS 的預設管理員帳戶 (<[email protected]>)。如需詳細資訊，請參閱 vSphere 角色和權限。

解決方案

若要刪除 AVS 上的 vSphere CSI PV，請連絡 Azure 支援。

如果叢集使用的網路資源未使用 Tanzu Kubernetes Grid 進行部署，則刪除 AWS 上的叢集會失敗

問題

如果叢集使用 AWS 雲端控制器管理程式所建立的網路資源 (獨立於 Tanzu Kubernetes Grid 部署程序之外)，則 tanzu cluster delete 和 tanzu management-cluster delete 命令可能會當機。此類資源可能包括負載平衡器和其他網路服務，如 Kubernetes AWS 雲端提供者說明文件中的服務控制器中所列。

如需詳細資訊，請參閱下列叢集 API 問題：在卸除時清空服務類型為 Loadbalancer 的工作負載叢集。

解決方案

使用 kubectl delete，從叢集中刪除類型為 LoadBalancer 的服務。或者，如果這樣做仍失敗，請使用 AWS 主控台，手動刪除雲端控制器管理程式為此服務所建立的任何 LoadBalancer 和 SecurityGroup 物件。

注意

請勿刪除由 Tanzu 管理的負載平衡器或安全群組 (有 key: sigs.k8s.io/cluster-api-proider-aws/cluster/CLUSTER-NAME、value: owned 標記)。

當儲存磁碟區使用具有私人端點的帳戶時，叢集刪除會失敗

問題

如果未受管理的資源群組中有一個 Azure 工作負載叢集，當 Azure CSI 驅動程式建立一個持續性磁碟區 (PV)，且該持續性磁碟區使用具有私人端點的儲存區帳戶時，它會建立一個 privateEndpoint 和 vNet 資源，但在刪除 PV 時，並不會刪除這些資源。因此，刪除叢集將失敗，並顯示類似如下的錯誤：subnets failed to delete. err: failed to delete resource ... Subnet management-cluster-node-subnet is in use。

解決方案：

在刪除 Azure 叢集之前，請先手動刪除儲存區帳戶私人端點的網路介面：

  1. 從瀏覽器登入 Azure Resource Explorer。
  2. 按一下左側的訂閱 (subscriptions)，然後展開您的訂閱。
  3. 在您的訂閱下，展開左側 resourceGroups，然後展開您的 TKG 部署的資源群組。
  4. 在資源群組下，展開提供者 (providers) > Microsoft.Network > networkinterfaces。
  5. 在 networkinterfaces 下，選取無法刪除的 NIC 資源。
  6. 按一下頂層的讀取/寫入 (Read/Write) 按鈕，然後按一下其正下方的動作 (張貼、刪除) (Actions (POST, DELETE)) 索引標籤。
  7. 按一下刪除 (Delete)。
  8. 刪除 NIC 後，請刪除 Azure 叢集。
check-circle-line exclamation-circle-line close-line
Scroll to top icon