這個頁面說明如何調查 Google Distributed Cloud (僅限軟體) for VMware 的叢集建立和升級問題。
安裝問題
以下各節內容或許有助於排解 Google Distributed Cloud 安裝問題。
使用啟動叢集偵錯問題
安裝期間，Google Distributed Cloud 會建立臨時的啟動程序叢集。安裝完成後，Google Distributed Cloud 會刪除啟動叢集，只留下管理員叢集和使用者叢集。一般來說，您應該沒有與啟動叢集互動的理由。不過，如果在安裝過程中遇到問題，可以使用啟動程序叢集記錄來協助偵錯。
如果將 --cleanup-external-cluster=false 傳遞至 gkectl create cluster，啟動叢集就不會遭到刪除，您可以使用啟動叢集偵錯安裝問題。
檢查啟動叢集的記錄檔
找出在
kube-system命名空間中執行的 Pod 名稱：kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl get pods -n kube-system查看 Pod 的記錄：
kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl -n kube-system get logs POD_NAME將
POD_NAME替換為要查看的 Pod 名稱。如要直接從啟動程序叢集取得記錄，請在建立、更新及升級叢集時執行下列指令：
docker exec -it gkectl-control-plane bash這個指令會在啟動叢集中執行的
gkectl-control-plane容器內開啟終端機。如要檢查
kubelet和containerd記錄，請使用下列指令，並在輸出內容中尋找錯誤或警告：systemctl status -l kubelet journalctl --utc -u kubelet systemctl status -l containerd journalctl --utc -u containerd
檢查啟動叢集的快照
如果您嘗試建立或升級管理員叢集，但作業失敗，Google Distributed Cloud 會擷取啟動叢集的外部快照。這個啟動叢集快照與在管理員叢集上執行 gkectl diagnose snapshot
指令所擷取的快照類似，但程序會自動觸發。啟動叢集快照包含管理員叢集建立和升級程序的重要偵錯資訊。如有需要，您可以將這份快照提供給 Cloud Customer Care。
外部快照包含 onprem-admin-cluster-controller 中的 Pod 記錄，可供您查看，以偵錯叢集建立或升級問題。記錄會儲存在個別檔案中，例如：
kubectl_logs_onprem-admin-cluster-controller-6767f6597-nws8g_ \
--container_onprem-admin-cluster-controller_ \
--kubeconfig_.home.ubuntu..kube.kind-config-gkectl_\
--namespace_kube-system
管理員控制層啟動後，VM 未啟動
如果管理員控制層啟動後，VM 無法啟動，您可以檢查管理員叢集中的 Cluster API 控制器 Pod 記錄，調查問題：
找出 Cluster API 控制器 Pod 的名稱：
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system \ get pods | grep clusterapi-controllers從「
vsphere-controller-manager」查看記錄。首先指定 Pod，但不要指定容器：kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system \ logs POD_NAME輸出內容會顯示您必須指定容器，並提供 Pod 中的容器名稱。例如：
... a container name must be specified ..., choose one of: [clusterapi-controller-manager vsphere-controller-manager rbac-proxy]
選擇容器並查看記錄：
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system \ logs POD_NAME --container CONTAINER_NAME
已分配足夠的 IP 位址，但機器無法向叢集註冊
如果 IP 位址衝突，就可能發生這個問題。舉例來說，您為機器指定的 IP 位址正用於負載平衡器。
如要解決這個問題，請更新叢集 IP 區塊檔案，確保機器位址不會與叢集設定檔或 Seesaw IP 區塊檔案中指定的位址衝突。
Kind 叢集不會遭到刪除
建立管理員叢集時，系統會一併建立 kind 叢集 (也稱為啟動叢集)。管理員叢集作業完成後，kind 叢集就會自動刪除。
如果看到 Failed to delete the kind cluster 錯誤訊息，請在管理工作站上執行下列步驟，手動刪除 kind 叢集：
取得
kind容器 ID：docker inspect --format="{{.Id}}" gkectl-control-plane取得
containerd-shim程序 ID：sudo ps awx | grep containerd-shim | grep CONTAINER_ID | awk '{print $1}'終止程序：
sudo kill -9 PROCESS_ID
叢集升級問題
下列各節提供相關提示，協助您解決叢集升級期間可能遇到的問題。
在升級後復原節點集區
升級使用者叢集後，如果發現叢集節點有問題，可以將選取的節點集區還原至先前的版本。
系統支援還原所選 Ubuntu 和 COS 節點集區，但不支援 Windows 節點集區。
節點集區版本可以與使用者叢集控制層版本相同，或比使用者叢集控制層版本舊一個子版本。舉例來說，如果控制層是 1.14 版，節點集區可以是 1.14 或 1.13 版。
查看可用的節點集區版本
假設您最近升級使用者叢集工作站節點和控制層，從 1.13.1-gke.35 版升級至 1.14.0 版，但發現升級後的工作站節點有問題。因此您決定將一或多個節點集區復原為先前執行的版本：1.13.1-gke.35。開始回溯前，請先確認先前的版本是否可供回溯。
如要查看可用版本，請執行下列指令：
gkectl version --cluster-name USER_CLUSTER_NAME \
--kubeconfig ADMIN_CLUSTER_KUBECONFIG
輸出內容會顯示每個節點集區的目前版本和先前版本。例如：
user cluster version: 1.14.0-gke.x
node pools:
- pool-1:
- version: 1.14.0-gke.x
- previous version: 1.13.1-gke.35
- pool-2:
- version: 1.14.0-gke.x
- previous version: 1.13.1-gke.35
available node pool versions:
- 1.13.1-gke.35
- 1.14.0-gke.x
復原節點集區版本
您可以一次回溯一個節點集區的版本，也可以在單一步驟中回溯多個節點集區的版本。
如要復原節點集區版本，請完成下列步驟：
在使用者叢集設定檔中，於一或多個節點集區中，將
gkeOnPremVersion的值設為先前的版本。以下範例說明如何回溯至 1.13.1-gke.35 版：nodePools: - name: pool-1 cpus: 4 memoryMB: 8192 replicas: 3 gkeOnPremVersion: 1.13.1-gke.35 ...更新叢集，復原節點集區：
gkectl update cluster --config USER_CLUSTER_CONFIG \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG確認回溯作業是否成功：
gkectl version --cluster-name USER_CLUSTER_NAME \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG以下輸出內容顯示
pool-1已回溯至 1.13.1-gke.35 版。user cluster version: 1.14.0-gke.x node pools: - pool-1: - version: 1.13.1-gke.35 - previous version: 1.14.0-gke.x - pool-2: - version: 1.14.0-gke.x - previous version: 1.13.1-gke.35 available node pool versions: - 1.13.1-gke.35 - 1.14.0-gke.x
升級至新的修補程式版本
您可以將所有節點集區和控制層升級至新的修補程式版本。如果您已還原至舊版，但想升級至包含修正程式的版本，這項功能或許能派上用場。
如要升級至新版本，請完成下列步驟：
在使用者叢集設定檔中進行下列變更：
將
gkeOnPremVersion的值設為新的修正程式版本。本範例使用 1.14.1-gke.x。針對每個節點集區，移除
gkeOnPremVersion欄位，或將其設為空字串。如果未指定節點集區的版本，節點集區的版本預設會是叢集指定的版本。這些變更類似於下列範例：
gkeOnPremVersion: 1.14.1-gke.x nodePools: - name: pool-1 cpus: 4 memoryMB: 8192 replicas: 3 gkeOnPremVersion: "" - name: pool-2 cpus: 8 memoryMB: 8192 replicas: 2 gkeOnPremVersion: ""
按照「升級 Google Distributed Cloud」一文的說明，執行
gkectl prepare和gkectl upgrade cluster和gkectl upgrade cluster。驗證新叢集版本，並查看可供回溯的版本：
gkectl version --cluster-name USER_CLUSTER_NAME \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG輸出結果會與下列內容相似：
user cluster version: 1.14.1-gke.y node pools: - pool-1: - version: 1.14.1-gke.y - previous version: 1.13.1-gke.35 - pool-2: - version: 1.14.1-gke.y - previous version: 1.13.1-gke.35 available node pool versions: - 1.13.1-gke.35 - 1.14.0-gke.x - 1.14.1-gke.y ```
叢集升級失敗時，系統會自動執行健康狀態檢查
如果您嘗試升級管理員或使用者叢集，但作業失敗，Google Distributed Cloud 會自動在叢集上執行 gkectl diagnose cluster
指令。
如要略過自動診斷，請將 --skip-diagnose-cluster 旗標傳遞至 gkectl upgrade。
升級程序停滯
在升級期間，Google Distributed Cloud 會在幕後使用 Kubernetes drain指令。如果 Deployment 只有一個副本，且已為該副本建立 Pod 中斷預算 (PDB)，則drain程序可能會遭到封鎖minAvailable: 1。
從 Google Distributed Cloud 1.13 版開始，您可以透過 Kubernetes Pod 事件檢查失敗情形。
找出機器的名稱：
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get machines --all-namespaces使用
kubectl describe machine指令檢查錯誤：kubectl --kubeconfig USER_CLUSTER_KUBECONFIG describe machine MACHINE_NAME輸出結果會與下列內容相似：
Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning PodEvictionTooLong 3m49s machine-controller Waiting too long(12m10.284294321s) for pod(default/test-deployment-669b85c4cc-z8pz7) eviction.選用：如要更詳細地分析機器物件狀態，請執行
gkectl diagnose cluster。輸出結果會與下列內容相似：
... Checking machineset...SUCCESS Checking machine objects...FAILURE Reason: 1 machine objects error(s). Unhealthy Resources: Pod test-deployment-669b85c4cc-7zjpq: Pod cannot be evicted successfully. There is 1 related PDB. ... Checking all poddisruptionbudgets...FAILURE Reason: 1 pod disruption budget error(s). Unhealthy Resources: PodDisruptionBudget test-pdb: default/test-pdb might be configured incorrectly, the total replicas(3) should be larger than spec.MinAvailable(3). ... Some validation results were FAILURE or UNKNOWN. Check report above.
如要解決這個問題，請儲存 PDB，然後從叢集中移除，再嘗試升級。升級完成後，即可重新新增 PDB。
移除不支援的變更，解除升級限制
將叢集升級至 1.16 版或更早版本時，系統會在升級期間忽略大多數欄位的變更，也就是說，這些變更在升級期間和升級後都不會生效。
將使用者叢集升級至 1.28 以上版本時，我們會驗證設定檔中的所有變更，並針對不支援的變更傳回錯誤，而不是直接忽略。這項功能僅適用於使用者叢集。 升級管理員叢集時，系統會忽略大多數欄位的變更，且升級後不會生效。
舉例來說，如果您嘗試在將使用者叢集升級至 1.28 時停用節點自動修復功能，升級作業會失敗，並顯示下列錯誤訊息：
failed to generate desired create config: failed to generate desired OnPremUserCluster from seed config: failed to apply validating webhook to OnPremUserCluster: the following changes on immutable fields are forbidden during upgrade: (diff: -before, +after):
v1alpha1.OnPremUserClusterSpec{
... // 20 identical fields
CloudAuditLogging: &{ProjectID: "syllogi-partner-testing", ClusterLocation: "us-central1", ServiceAccountKey: &{KubernetesSecret: &{Name: "user-cluster-creds", KeyName: "cloud-audit-logging-service-account-key"}}},
- AutoRepair: &v1alpha1.AutoRepairConfig{Enabled: true},
+ AutoRepair: &v1alpha1.AutoRepairConfig{},
CARotation: &{Generated: &{CAVersion: 1}},
KSASigningKeyRotation: &{Generated: &{KSASigningKeyVersion: 1}},
... // 8 identical fields
}
如要略過這項錯誤，可以嘗試下列解決方法：
- 請還原嘗試進行的變更，然後重新執行升級。舉例來說，在先前的案例中，您會還原對
AutoRepair設定所做的變更，然後重新執行gkectl upgrade。 - 或者，您也可以執行
gkectl get-config，產生與叢集目前狀態相符的設定檔，更新設定檔中叢集和節點集區的gkeOnPremVersion欄位，然後重新執行gkectl upgrade。
問題：gkectl prepare後找不到 OS 映像檔
執行 gkectl prepare 指令後，嘗試使用 gkectl upgrade cluster 升級使用者叢集時，可能會遇到類似下列的錯誤：
[FAILURE] User OS images exist: OS images [gke-on-prem-ubuntu-VERSION] don't exist, please run `gkectl prepare` to upload OS images.
如果管理員叢集和使用者叢集設定為使用不同的 vSphere 資料夾，就可能發生這項錯誤。根據預設，gkectl prepare 指令會將 OS 映像檔上傳至管理員叢集的資料夾。如要將圖片上傳至使用者叢集的資料夾，請使用 --user-cluster-config 標記，如下列指令所示：
gkectl prepare --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
--bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-VERSION-full.tgz \
--user-cluster-config USER_CLUSTER_CONFIG
使用內部 kubeconfig 檔案偵錯 F5 BIG-IP 問題
安裝完成後，Google Distributed Cloud 會在管理工作站的主目錄中，產生名為 internal-cluster-kubeconfig-debug 的 kubeconfig 檔案。這個 kubeconfig 檔案與管理員叢集的 kubeconfig 檔案相同，但會直接指向 Kubernetes API 伺服器執行的管理員叢集控制平面節點。您可以使用 internal-cluster-kubeconfig-debug 檔案偵錯 F5 BIG-IP 問題。
偵錯 vSphere 問題
您可以使用 govc 檢查 vSphere 的問題。舉例來說，您可以確認 vCenter 使用者帳戶的權限和存取權，以及收集 vSphere 記錄。
重新建立遺失的使用者叢集 kubeconfig 檔案
在下列情況下，您可能需要重新建立使用者叢集 kubeconfig 檔案：
- 如果您嘗試建立使用者叢集，但建立作業失敗，且您想要取得使用者叢集
kubeconfig檔案。 - 使用者叢集
kubeconfig檔案遺失 (例如遭到刪除)。
如要為使用者叢集產生新的 kubeconfig 檔案，請執行下列步驟：
定義環境變數：
首先，請使用適當的值設定下列環境變數：
USER_CONTROLPLANEVIP=USER_CONTROLPLANEVIP USER_CLUSTER_NAME=USER_CLUSTER_NAME ADMIN_CLUSTER_KUBECONFIG=PATH_TO_ADMIN_KUBECONFIG KUBECONFIG_SECRET_NAME=$(kubectl --kubeconfig $ADMIN_CLUSTER_KUBECONFIG get secrets -n $USER_CLUSTER_NAME | grep ^admin | cut -d' ' -f1 | head -n 1)更改下列內容：
ADMIN_CLUSTER_KUBECONFIG：管理員叢集的kubeconfig檔案路徑。USER_CONTROLPLANEVIP：使用者叢集的controlPlaneVIP。這項資訊可從使用者叢集資訊清單檔案中擷取。
產生 Kubeconfig 檔案：
執行下列指令來建立新的 kubeconfig 檔案：
kubectl --kubeconfig $ADMIN_CLUSTER_KUBECONFIG get secrets $KUBECONFIG_SECRET_NAME \ -n $USER_CLUSTER_NAME -o jsonpath='{.data.admin\.conf}' | base64 -d | \ sed -r "s/ kube-apiserver.*local\./${USER_CONTROLPLANEVIP}/" \ > USER_CLUSTER_KUBECONFIG取代：
USER_CLUSTER_KUBECONFIG：使用者叢集的新kubeconfig檔案名稱。
後續步驟
如需其他協助，請與 Cloud Customer Care 團隊聯絡。
如要進一步瞭解支援資源，包括下列項目，請參閱「取得支援」：