疑難排解管理叢集問題

本主題含有一些可協助您對獨立管理叢集部署進行疑難排解的提示。以下某些程序會使用 kind CLI。若要安裝 kind，請參閱 kind 說明文件中的安裝。如需疑難排解工作負載叢集的相關資訊，請參閱疑難排解工作負載叢集問題。

一般工作

透過 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 狀態，請執行下列動作：

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

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

    kubectl config unset users.USERNAME --kubeconfig ~/.kube-tkg/config

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

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

    kubectl config unset contexts.CONTEXT-NAME --kubeconfig ~/.kube-tkg/config

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

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

    kubectl config unset clusters.CLUSTER-NAME --kubeconfig ~/.kube-tkg/config

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

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

    kubectl config unset current-context --kubeconfig ~/.kube-tkg/config

  6. 如果您刪除了 tanzu CLI 所追蹤的管理叢集，請執行 tanzu config server delete，從 tanzu CLI 的狀態刪除這些叢集，如從 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

目標平台

驗證失敗，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.

解決方案

如果發生此情況，請接受法律條款，然後重試：

管理叢集

管理叢集部署失敗後清理

問題

如果嘗試部署獨立管理叢集失敗，則您的雲端基礎結構中和啟動機器上會留下孤立物件。

解決方案

  1. 在終端機或 Tanzu Kubernetes Grid 安裝程式介面中監控 tanzu mc create 命令輸出。如果命令失敗，則會列印一則說明訊息，指出：「部署管理叢集時失敗… 若要清理管理叢集所建立的資源，請執行以下命令：tkg delete mc…。」
  2. 執行 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 物件。

  • 目標平台清理：

    • 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 進行復原：

    1. 在由於管理叢集刪除失敗而保留在啟動載入機器上的 kind 叢集中，修正 AWS 認證祕密金鑰：

      kubectl get secret capa-manager-bootstrap-credentials -n capa-system -ojsonpath="{.data.credentials}"| base64 -d

    2. 編輯祕密金鑰以包括 AWS 認證：

      [default]
aws_access_key_id = <key id>
aws_secret_access_key = <access_key>
region = <region>

    3. 再次執行 tanzu mc delete。

刪除管理叢集後保留 Kind 叢集

問題

執行 tanzu mc delete 會移除管理叢集，但無法將本機 kind 叢集從啟動機器中刪除。

解決方案

  1. 列出所有正在執行的 kind 叢集，然後移除類似於 tkg-kind-unique_ID 的叢集：

    kind delete cluster --name tkg-kind-unique_ID

  2. 列出所有正在執行的叢集，並識別 kind 叢集。

    docker ps -a

  3. 複製 kind 叢集的容器識別碼，並將其移除。

    docker kill container-ID

管理叢集部署失敗後機器停滯

問題

您的獨立管理叢集無法部署，因為機器停滯，正在等待修復。

解決方案

對於您在 dev 計劃下所部署的管理叢集 (此計劃只有一個控制平面節點)，您必須重新部署管理叢集。如果管理叢集有多個控制平面節點，您可以識別並刪除停滯的機器。

  1. 擷取管理叢集的狀態。例如：

    kubectl -n tkg-system get cluster my-mgmt-cluster -o yaml

  2. 從上一個步驟的輸出中尋找停滯機器的名稱。停滯的機器會標記為 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

  3. 增加控制平面節點的機器健全狀況檢查逾時值，使其大於預設值 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 物件。

  4. 將 kubectl 設定為管理叢集的內容。例如：

    kubectl config use-context mgmt-cluster-admin@mgmt-cluster

  5. 刪除停滯的機器。

    kubectl delete machine MACHINE-NAME

    其中，MACHINE-NAME 是您在先前步驟中找到的機器名稱。

  6. 等待 KubeadmControlPlane 控制器重新部署機器。

還原 ~/.config/tanzu 目錄

問題

啟動機器上的 ~/.config/tanzu 目錄遭到意外刪除或損壞。Tanzu CLI 會建立並使用此目錄，如果沒有此目錄，就無法正常運作。

解決方案

若要還原 ~/.config/tanzu 目錄的內容，請執行以下動作：

  1. 若要識別現有 Tanzu Kubernetes Grid 管理叢集，請執行：

    kubectl --kubeconfig ~/.kube-tkg/config config get-contexts

    命令輸出會列出 Tanzu CLI 所建立或新增的所有管理叢集的名稱和內容。

  2. 針對輸出中列出的每一個管理叢集，執行以下命令，將它還原到 ~/.config/tanzu 目錄和 CLI：

    tanzu login --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.24.10

會發生這種情況的原因是，Docker 桌面將舊版 kubectl 的符號連結到路徑中。

解決方案

請在路徑中，將較新的 kubectl 支援版本放置在 Docker 版本之前。

復原管理叢集認證

如果您遺失了獨立管理叢集的認證，例如，在無意中刪除了 tanzu 命令執行所在系統上的 .kube-tkg/config 檔案，您可以從管理叢集控制平面節點來復原認證。

  1. 執行 tanzu mc create，以重建 .kube-tkg/config 檔案。
  2. 從 vSphere、AWS 或 Azure 取得管理叢集控制平面節點的公用 IP 位址。

  3. 使用 SSH 來登入管理叢集控制平面節點。

    如需瞭解用於每個目標平台的認證，請參閱上面的透過 SSH 連線到叢集節點。

  4. 存取管理叢集的 admin.conf 檔案。

    sudo vi /etc/kubernetes/admin.conf

    admin.conf 檔案含有叢集名稱、叢集使用者名稱、叢集內容，以及用戶端憑證資料。

  5. 將叢集名稱、叢集使用者名稱、叢集內容和用戶端憑證資料，複製到 .kube-tkg/config 命令執行所在系統上的 tanzu 檔案中。

Pinniped

部署後 Pinniped 工作失敗

問題

升級到 Tanzu Kubernetes Grid v2.1.1 時，傳回了類似如下的錯誤：

 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 部署後工作會與元件的升級程序發生衝突，則可能會出現此錯誤。請遵循以下步驟來刪除並重新部署該工作。

  1. 刪除 Pinniped 部署後工作。

    kubectl delete jobs.batch -n pinniped-supervisor pinniped-post-deploy-job

  2. 等待大約 5 分鐘，讓 kapp-controller 對部署後工作進行重新部署。

  3. 檢查 Pinniped 應用程式的狀態。

    kubectl get app -n tkg-system pinniped
NAME       DESCRIPTION           SINCE-DEPLOY   AGE
pinniped   Reconcile succeeded   5s             49m

    如果 DESCRIPTION 顯示 Reconciling，請等待幾分鐘，然後重新檢查。一旦顯示 Reconcile succeeded，就可繼續執行下一個步驟。

  4. 檢查 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 服務包，請遵循以下步驟：

  1. 將 kubectl 內容設定為管理叢集。

  2. 從 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

  3. 從工作負載叢集的 Pinniped 附加元件密碼中取得 values.yaml 區段：

    kubectl get secret WORKLOAD-CLUSTER-NAME-pinniped-addon -n WORKLOAD-CLUSTER-NAMESPACE -o jsonpath="{.data.values\.yaml}" | base64 -d > values.yaml

    此秘密金鑰位於管理叢集上。

  4. 在上面所建立的 values.yaml 檔案中，更新 supervisor_ca_bundle_data 索引鍵，使其與 pinniped-info ConfigMap 中的 CA 服務包相符。此外，請確定 supervisor_svc_endpoint 與 issuer 端點相符。

  5. 套用您的更新，方法是對所編輯的 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

  6. 在工作負載叢集上，確認 Pinniped 應用程式已成功協調所做的變更：

    kubectl get app pinniped -n tkg-system

  7. 對叢集進行驗證。例如：

    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

解決方案

這是一個會影響 TKG v1.2 及更新版本的已知問題。有關因應措施，請參閱更新 Tanzu CLI 組態中的管理叢集憑證和無法在 Tanzu Kubernetes Grid 中使用 tkg/tanzu cli 命令來存取叢集。

Tanzu Kubernetes Grid 安裝程式介面

Tanzu Kubernetes Grid UI 在 Windows 上無法正確顯示

問題

當您在 Windows 系統上執行 tanzu management-cluster create --ui 或 tanzu mc create --ui 命令時，UI 會在預設瀏覽器中開啟，但沒有套用圖形和樣式。會發生這種情況的原因是，Windows 登錄設定為 application/x-css。

解決方案

  1. 在 Windows 搜尋中，輸入 regedit，以開啟「登錄編輯程式」公用程式。
  2. 展開 HKEY_CLASSES_ROOT，並選取 .js。
  3. 在內容類型 (Content Type) 上按一下滑鼠右鍵，並選取修改 (Modify)。
  4. 將該值設定為 application/javascript，然後按一下確定 (OK)。
  5. 再次執行 tanzu mc create --ui 命令，以重新啟動 UI。

NSX Advanced Load Balancer

向 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 中可以調整。

check-circle-line exclamation-circle-line close-line
Scroll to top icon