s <0x0

本頁面列出 Google Distributed Cloud (僅限軟體) for Bare Metal (舊稱 Google Distributed Cloud Virtual，再舊稱 Anthos clusters on bare metal) 的所有已知問題。

本頁內容適用於管理基礎技術架構生命週期，以及在服務等級目標 (SLO) 未達成或應用程式失敗時，回應快訊和頁面的管理員、架構師和營運人員。如要進一步瞭解內容中提及的常見角色和範例工作，請參閱「常見的 GKE 使用者角色和工作」。 Google Cloud

如果您是 Google 開發人員計畫成員，請儲存這個頁面，以便在發布與這個頁面相關的版本說明時收到通知。詳情請參閱「儲存的頁面」。

如要依產品版本或類別篩選已知問題，請從下列下拉式選單中選取篩選條件。

選取 Google Distributed Cloud 版本：

1.34 1.33 1.32 1.31 1.30 1.29 1.28 1.16 1.15 1.14 1.13 1.12 1.11 1.10

選取問題類別：

設定 安裝 升級與更新 作業 記錄和監控 網路 安全性 重設/刪除 GDC 上的 VM Runtime

或者，搜尋您的問題：

類別	已識別版本	問題和解決方法
網路、升級與更新	1.30 以上版本	升級期間，Istiod Pod 無法達到就緒狀態 Google Distributed Cloud 中隨附的 Ingress 功能會使用 istiod。這項功能不會使用 Istio 定義的自訂資源定義。不過，由於使用的程式碼是開放原始碼，因此 Pod 對於您可能為自身用途安裝的 Istio 相當敏感。 如果叢集中沒有 Istio 自訂資源定義，Istiod 會宣告本身已準備就緒，不會等待自訂資源定義。不過，如果叢集中有v1beta自訂資源定義v1，Istiod 會等待自訂資源定義，然後才宣告就緒。因此，Istiod Pod 可能無法達到就緒狀態，導致叢集升級失敗。 驗證： 如要確認叢集是否受影響，請檢查 gke-system 命名空間中的 Istiod Pod 狀態： kubectl get pods -n gke-system -l app=istiod 如果 Pod 狀態為 Running，但就緒檢查失敗 (例如 0/1 ready)，叢集可能就會受到影響。 解決方法： 如要解決這個問題，請採取下列任一做法： 手動將 Istio v1 自訂資源定義部署至叢集。 如果未使用，請停用隨附的 Ingress 功能。
安裝、升級及更新	1.30.400 以下版本	檢查PreflightCheck自訂資源時發生 lifecycle-controllers-manager 錯誤 如果叢集版本為 1.30.400 或更舊，驗證自訂資源時可能會發生 Pod lifecycle-controllers-manager 異常終止PreflightCheck。這些當機問題會導致叢集佈建和升級作業停滯。 這個問題是由於 PreflightCheck 資源驗證期間的空指標取消參照所造成。 解決方法： 如要允許叢集佈建或升級作業繼續進行，請略過預檢。在叢集設定檔中，將 bypassPreflightCheck 欄位設為 true： spec: bypassPreflightCheck: true 詳情請參閱「套用 Kubernetes 資源時略過預檢」。
作業：重設/刪除	1.33 以下版本	叢集還原後，節點問題偵測工具不會啟動 使用 bmctl restore cluster 還原叢集時，還原作業完成後，節點上的 Node Problem Detector (NPD) systemd 服務不會啟動。 如要確認是否受到影響，請在還原作業後，於叢集節點上執行 systemctl is-active node-problem-detector。如果指令傳回 inactive，表示您受到這個問題影響。 解決方法： 如要還原 NPD，請按照下列步驟操作： 按照「如何啟用及停用節點問題偵測工具」一文中的程序停用 NPD。 按照「如何啟用及停用節點問題偵測工具」一文中的程序啟用 NPD。 明確停用及啟用 NPD 會觸發 NPD 部署工具工作，在所有節點上安裝 NPD 服務。
網路、作業	1.28 和更早版本、1.29.0-1.29.700、1.30.0-1.30.300	控制層負載平衡器 Pod 每 7 天會重新啟動一次 如果叢集使用隨附的第 2 層負載平衡器，您可能會發現每 7 天會發生「連線遭拒」錯誤，或 API 伺服器短暫無法使用 (約 1 分鐘)。 發生這種情況的原因是，控制層節點上的 haproxy 和 keepalived Pod 會因工作存留時間設定而重新啟動。這個問題會影響 1.29.0 至 1.29.700 版、1.30.0 至 1.30.300 版，以及 1.28 版和更早版本的叢集。 驗證： 如要確認叢集是否受到這個特定問題影響，請完成下列步驟，檢查負載平衡器更新作業的設定： 找出更新作業的名稱： kubectl get jobs -n kube-system | grep bm-system-cplb-update 檢查工作的存留時間設定： kubectl get job JOB_NAME -n kube-system -o jsonpath='{.spec.ttlSecondsAfterFinished}' 將 JOB_NAME 替換為上一步傳回的名稱。 如果輸出內容為 604800 (以秒為單位，相當於 7 天)，表示叢集受到這個問題影響。 解決方法： 如要避免每週重新啟動，請完成下列步驟，手動將現有負載平衡器更新作業的 ttlSecondsAfterFinished 欄位修補為較大的值： 編輯負載平衡器更新作業： kubectl edit job JOB_NAME -n kube-system 在編輯器中找出 ttlSecondsAfterFinished 欄位，然後將值變更為 7776000 (約 90 天)。 儲存並結束編輯器，即可套用變更。
作業	1.32.0-1.32.700、1.33.0-1.33.300、1.34.0	cluster-operator Pod 因空值指標取消參照而當機 cluster-operator Pod 可能會因控制器中的恐慌 assignment to entry in nil map 而當機或進入當機迴圈。當控制器嘗試更新自訂資源 (例如 NodePool) 的註解，但該資源沒有任何註解 (空對應) 時，就會發生這種情況。 解決方法： 為避免發生恐慌，請確保自訂資源 (例如 NodePool) 至少有一個註解。您可以使用下列指令新增虛擬註解： kubectl annotate nodepool NODEPOOL_NAME \ -n CLUSTER_NAMESPACE dummy-annotation="added-manually" --overwrite \ --kubeconfig=ADMIN_KUBECONFIG 更改下列內容： NODEPOOL_NAME：NodePool 自訂資源的名稱。 CLUSTER_NAMESPACE：叢集的命名空間。 ADMIN_KUBECONFIG：管理員叢集 kubeconfig 檔案的路徑。
升級與更新	1.34.0	主機名稱不符，導致工作節點升級失敗 由於 kubeadm 中發生回歸 (kubernetes/kubeadm#3244)，工作節點升級作業失敗。如果 Linux 主機名稱與對應 Kubernetes 節點上的 kubernetes.io/hostname 標籤值不符，就會發生迴歸。 如要確認受影響的節點是否發生故障，請使用類似下列指令的 journalctl： [root@vm-lb-0--40b1a328a3448f5-112eaaafe1beedad ~]# journalctl -t kubeadm 回覆內容大致如下： Dec 09 20:09:50 vm-lb-0--40b1a328a3448f5-112eaaafe1beedad kubeadm[3684235]: error: error execution phase kubelet-config: could not remove the CRI socket annotation from Node "vm-lb-0--40b1a328a3448f5-112eaaafe1beedad": nodes "vm-lb-0--40b1a328a3448f5-112eaaafe1beedad" not found 在這個範例中，journalctl 回應中回報的 Linux 主機名稱與節點的 kubernetes.io/hostname 標籤不符，確認升級受到這個問題影響： kubectl get nodes lb-0--40b1a328a3448f5-112eaaafe1beedad.lab.anthos \ -ojsonpath='{.metadata.labels.kubernetes\.io\/hostname}' 回覆： lb-0--40b1a328a3448f5-112eaaafe1beedad.lab.anthos 解決方法： 如要讓受影響的節點完成升級，請嘗試暫時變更主機名稱，使其與對應 Kubernetes 節點上的 kubernetes.io/hostname 標籤值相符，如下所示： [root@vm-lb-0--40b1a328a3448f5-112eaaafe1beedad ~]# hostname lb-0--40b1a328a3448f5-112eaaafe1beedad.lab.anthos
網路	1.34.0	節點封鎖時，正常遷移作業會捨棄現有連線 啟用輸出 NAT 快速容錯移轉後，使用 kubectl cordon <NODE_NAME> 隔離閘道節點會啟動正常遷移，維持現有的輸出連線。不過，在 Google Distributed Cloud 軟體專屬版本 1.34.0 中，正常遷移功能無法正常運作。 如果管理員在 1.34.0 版叢集中使用快速容錯移轉功能，並封鎖有效的輸出閘道節點，封鎖行為會如同節點發生非預期故障，並立即終止該節點上的所有現有具狀態連線。 解決方法： 這個問題沒有解決方法。
網路	1.32.0	ClusterIP 服務通訊失敗 如果流量轉送至不同節點上的後端 Pod，ClusterIP 服務可能會發生連線間歇性中斷或失敗的情況。這項通訊失敗是由於 Cilium v1.15 發生回歸，導致 CILIUM_POST_nat 規則從 iptables 中移除。來源網路位址轉譯 (SNAT) 需要 CILIUM_POST_nat 規則，移除這些規則會導致 kube-proxy 偽裝作業不可靠，進而造成 ClusterIP 服務通訊失敗。 舉例來說，如果您正在升級叢集，但作業停滯不前，您可能會看到類似下列的記錄訊息，指出 ClusterIP 服務嘗試連線至節點集區 np1 中的 API 伺服器時，TLS 交握作業逾時： I0527 15:42:39.261368 372146 upgrade.go:994] Error trying to connect to api server: Get "https://10.200.0.108:443/apis/baremetal.cluster.gke.io/v1/namespaces/cluster-baremetal-test/nodepools/np1": net/http: TLS handshake timeout E0527 15:42:39.264789 372146 exec.go:207] command "/root/bmctl-upgrade upgrade cluster --kubeconfig /root/bmctl-workspace/baremetal-test/baremetal-test-kubeconfig --quiet --cluster baremetal-test --manifest-profile-env staging" times out 這個問題已在 1.32.100 以上版本中修正。 解決方法： 如果無法升級至含有修正程式的版本，建議您手動將 Cilium 映像檔升級至 v1.15.6-anthos1.32.50 以上版本。這項更新重新導入必要的 CILIUM_POST_nat 規則，解決了這個問題。 注意：您也可以手動更新 iptables 規則，新增缺少的 NAT 規則，藉此還原通訊，但我們不建議進行這類變更。這類低階設定變更可能無法在節點重新啟動或叢集更新後保留。 如要升級 Cilium 映像檔，請按照下列步驟操作： 在 kube-system 命名空間中編輯 anetd DaemonSet： kubectl edit ds anetd -n kube-system Replace all occurrences of the Cilium image tag with version v1.15.6-anthos1.32.50 or a later version. Example old image: image: gcr.io/anthos-baremetal-staging/anthos-networking/cilium/cilium:v1.15.6-anthos1.32-gke.41@sha256:1940fccc... 新圖片範例： image: gcr.io/anthos-baremetal-staging/anthos-networking/cilium/cilium:v1.15.6-anthos1.32-gke.50 儲存變更並關閉編輯器。
安裝、升級及更新	1.33	bmctl configure projects returns Identity Pool does not exist error 嘗試使用 bmctl configure projects 指令為新 Google Cloud 專案設定工作負載身分聯合時，指令會失敗並顯示下列錯誤訊息： Error ((retry 1) error adding iam policy bindings: failed to add project binding: failed to set project "<>" iam policy: googleapi: Error 400: Identity Pool does not exist (projectID.svc.id.goog). Please check that you specified a valid resource name as returned in the `name` attribute in the configuration API., badRequest) ensuring iam policy binding: project-Id 這是因為系統不會在新專案中自動佈建名為 projectID.svc.id.goog 的必要預設工作負載身分集區， 解決方法： 請按照下列步驟，為專案設定 Workload Identity 聯盟： 手動建立缺少的預設 workload identity pool： gcloud iam workload-identity-pools create PROJECT_ID.svc.id.goog \ --location=global \ --project=PROJECT_ID 將 PROJECT_ID 替換為專案 ID。 在管理員工作站上，使用新擷取的存取權權杖更新 GCP_ACCESS_TOKEN 環境變數： export GCP_ACCESS_TOKEN=$(gcloud auth application-default print-access-token) 根據預設，存取權杖的生命週期為 3600 秒 (1 小時)。 使用 Workload Identity 叢集驗證時，bmctl 會檢查權杖到期時間。如果權杖在 1800 秒 (30 分鐘) 內過期， bmctl 會回報錯誤並結束。 再次執行 bmctl configure projects。
升級和更新、記錄和監控	1.29、1.30、1.31、1.32	cal-update 變更稽核記錄旗標時，Ansible 應對手冊會失敗 cal-update Ansible 劇本含有邏輯錯誤，導致嘗試變更 disableCloudAuditLogging 旗標時失敗。這會導致稽核記錄無法啟用或正確停用。 如果 disableCloudAuditLogging 從 true 變更為 false，系統就無法啟用稽核記錄，因為指令碼會在將設定變更套用至 kube-apiserver 之前失敗。當 disableCloudAuditLogging 從 false 變更為 true 時，稽核記錄可以停用，但 cal-update 工作會持續失敗，導致劇本無法進行健康狀態檢查。出現的錯誤訊息為： The task includes an option with an undefined variable. The error was: 'dict object' has no attribute 'stdout_lines' 解決方法： 這個問題沒有解決方法，您必須將叢集升級至已修正問題的版本。如要升級，請按照下列步驟操作： 將 disableCloudAuditLogging 設為 true，即可停用稽核記錄。 修補程式發布後，請將叢集升級至下列其中一個次要版本修補程式版本 (或更新版本)，這些版本已修正此問題： 1.30.1200 1.31.800 1.32.400 如要重新啟用 Cloud 稽核記錄，請將 disableCloudAuditLogging 設回 false。
升級與更新	1.32 以上版本	修復作業後，高可用性 (HA) 管理員叢集升級失敗 在 HA 管理員叢集上，執行 gkectl repair admin-master 指令後，執行 gkectl upgrade admin 指令會失敗並停滯。 gkectl repair admin-master 指令會將 machine.onprem.gke.io/managed=false 註解新增至修復的機器。執行 gkectl upgrade admin 指令時，這項註解會導致 cluster-api 控制器停滯在協調狀態。非高可用性叢集的升級作業包含可移除這項註解的樞紐邏輯，但高可用性叢集的升級作業缺少樞紐邏輯。 解決方法： 升級前，請先從管理員叢集的機器資源中手動移除 machine.onprem.gke.io/managed 註解。
升級、設定	1.32.0 - 1.32.200	登錄檔鏡像導致升級預檢失敗 升級至 1.32.0 以上版本時，使用登錄檔鏡像設定的叢集會無法通過 check_gcr_pass 前置檢查。這是因為 PreflightCheck 自訂資源的建構方式有所變更，導致檢查時使用的叢集規格省略了登錄檔鏡像設定。 在內部測試期間，我們發現叢集發生這個問題，且叢集具有 Proxy 和登錄檔鏡像設定。 解決方法： 如要解決這個問題，請採取下列任一做法： 觸發升級時，請使用 --force 旗標。 使用 bmctl get config 取得目前的叢集設定，並使用新產生的設定檔觸發升級。
設定、更新	1.15 至 1.30、1.31.0 至 1.31.800、1.32.0 至 1.32.300	叢集規格變更後，定期健康狀態檢查 CronJob 無法更新 在特定叢集版本中，如果叢集資源設定有變更，週期性健康狀態檢查 CronJob 可能不會更新規格。更新失敗會導致健康狀態檢查過時，並可能導致工作失敗。 Google Distributed Cloud 1.31.900、1.32.400 和 1.33.0 以上版本已修正這個問題。 解決方法： 如果是 1.30 以下版本，可以按照下列步驟操作，暫時解決問題： 停用定期健康狀態檢查。 這會刪除目前的 HealthCheck 資源。 重新啟用定期健康狀態檢查。 這會建立新的 HealthCheck 資源，並考量最新的叢集設定。
網路	1.10、1.11、1.12、1.13、1.14、1.15、1.16、1.28、1.29、1.30、1.31	交錯控制層 VIP 的無故 ARP Keepalived 用於將控制層 VIP 從一部機器移至另一部，以實現高可用性。如果控制層 VIP 由隨附的第 2 層負載平衡器處理，Keepalived 執行個體的容錯移轉可能會導致短暫間隔 (不到一秒)，此時具有不同 MAC 位址的無償 ARP 會交錯。交換網路基礎架構可能會將這種交錯視為異常，並拒絕後續的 ARP 訊息，時間最長可達 30 分鐘。ARP 訊息遭到封鎖，可能會導致控制層 VIP 在這段期間無法使用。 這是因為 1.31 以下版本使用的 Keepalived 設定，導致無償 ARP 交錯。具體來說，所有節點都設定為使用相同的優先順序。Keepalived 1.32 版的設定變更可解決這個問題，方法是為每個 Keepalived 執行個體設定不同的優先順序，並提供叢集設定 controlPlane.loadBalancer.keepalivedVRRPGARPMasterRepeat，以減少無償 ARP 的數量。 解決方法： 如果是 1.31 版以前，您可以直接編輯 Keepalived 設定檔 /usr/local/etc/keepalived/keepalived.conf，減少無故 ARP 交錯。針對執行控制平面負載平衡器的每個節點，編輯設定檔以變更下列設定： priority：為每個節點設定不同的 priority 值 (有效值介於 1 和 254 之間) weight：將 weight 值從 -2 變更為 -253，確保健康狀態檢查失敗時會觸發 Keepalived 容錯移轉。
記錄和監控	1.30、1.31、1.32、1.33	「kubernetes.io/anthos/custom_resurce_watchers」指標有落差 由於內部定義錯誤，kubernetes.io/anthos/custom_resurce_watchers 指標可能會顯示不準確的資料。如果受到這個問題影響，您可能會在記錄中看到類似以下的錯誤： One or more TimeSeries could not be written: timeSeries[42]: Value type for metric kubernetes.io/anthos/custom_resurce_watchers must be INT64, but is DOUBLE. 您可以放心忽略這些錯誤。這項指標不會用於重要系統快訊，且錯誤不會影響專案或叢集的功能。
作業	1.30、1.31、1.32、1.33	擷取快照時，無法剖析叢集設定檔 如果您執行 bmctl check cluster --snapshot 時，管理員工作站上缺少 .manifests 目錄，指令會失敗並顯示類似下列內容的錯誤： Error message: failing while capturing snapshot failed to parse cluster config file failed to get CRD file 發生這項錯誤的原因是 bmctl check cluster --snapshot 指令需要 .manifests 目錄中的自訂資源定義檔案，才能驗證叢集設定。這個目錄通常是在叢集設定期間建立。 如果您不小心刪除目錄，或從其他位置執行 bmctl，指令就無法繼續執行快照作業。 解決方法： 如要解決這個問題，請使用下列任一方法，手動重新產生 .manifests 目錄： 執行 bmctl check cluster 指令： bmctl check cluster --cluster CLUSTER_NAME \ --kubeconfig ADMIN_KUBECONFIG 這項指令會自動在目前的工作目錄中建立 .manifests 目錄，無論指令是否順利完成，都會執行這項操作。 在包含目前叢集設定檔的目錄中，執行 bmctl create cluster 指令： bmctl create cluster --cluster TEST_CLUSTER 雖然這個指令可能會導致錯誤 (例如「無法剖析叢集設定檔」)，但 .manifests 目錄仍會在目前的工作目錄中建立。 之後可以安全地刪除產生的暫時目錄 bmctl-workspace/TEST_CLUSTER 。 執行上述任一解決方法後，請重試 bmctl check cluster --snapshot 指令。
安裝、升級及更新	1.32.0、1.32.100	HAProxy 無法使用時，控制層 VIP 不會移動 如果裝載控制層 VIP 的節點上沒有 HAProxy 執行個體，Keepalived 執行個體的 nopreempt 設定會阻止控制層 VIP 移至具有健康狀態良好的 HAProxy 的節點。這個問題與自動設定 Keepalived 虛擬路由器備援通訊協定 (VRRP) 優先順序的功能有關，該功能與 nopreempt 設定不相容。 解決方法： 如要暫時解決這個問題，請按照下列步驟停用 Keepalived 功能： 將 preview.baremetal.cluster.gke.io/keepalived-different-priorities: "disable" 註解新增至叢集： kubectl annotate --kubeconfig ADMIN_KUBECONFIG \ -n CLUSTER_NAMESPACE \ clusters.baremetal.cluster.gke.io/CLUSTER_NAME \ preview.baremetal.cluster.gke.io/keepalived-different-priorities="disable" 從執行控制層負載平衡器的節點中移除 nopreempt /usr/local/etc/keepalived/keepalived.conf。 視負載平衡器設定而定，這些節點可以是控制層節點，也可以是負載平衡器節點集區中的節點。 移除 nopreempt 後，必須重新啟動 keepalived 靜態 Pod，才能從設定檔擷取變更。如要這麼做，請在每個節點上使用下列指令，重新啟動 keepalived Pod： crictl rmp -f \ $(crictl pods --namespace=kube-system --name='keepalived-*' -q)
安裝、升級及更新	1.30、1.31、1.32.0	未清除 abm-tools-* 個資料夾 如果前置檢查和健康狀態檢查工作失敗，可能會在 /usr/local/bin 下的時間戳記 abm-tools-* 資料夾中留下構件。如果受到影響，您可能會看到許多類似下列的資料夾： /usr/local/bin/abm-tools-preflight-20250410T114317。 如果備份作業屢次失敗，可能會導致磁碟使用量增加。 解決方法 如果遇到這個問題，請手動移除下列資料夾： rm -rf /usr/local/bin/abm-tools-*
網路	1.28.0-1.28.200	使用輸出 NAT 閘道時，負載平衡器流量會遭到捨棄 在啟用輸出 NAT 閘道的叢集上，如果負載平衡器選擇的後端符合過時 EgressNATPolicy 自訂資源指定的流量選取規則，負載平衡器流量就會遭到捨棄。 如果 Pod 符合輸出政策，在建立和刪除 Pod 時就會發生這個問題。刪除 Pod 時，輸出政策未正確清除，導致過時的輸出政策讓 LoadBalancer Pod 嘗試將流量傳送至已不存在的連線。 Google Distributed Cloud 1.28.300 以上版本已修正這個問題。 解決方法 如要清除輸出 NAT 政策資源，請重新啟動每個裝載失敗後端的節點。
升級和更新、重設/刪除	1.28	machine-init failure - new control plane node stuck during replacement 在 Google Distributed Cloud 1.28 中更換 (移除、新增) 控制層節點時，新節點可能無法加入叢集。這是因為負責設定新節點的程序 (bm-system-machine-init) 發生下列錯誤： Failed to add etcd member: etcdserver: unhealthy cluster 如果舊的控制層節點遭到移除，但其在 etcd-events 中的成員資格未正確清除，就會發生這項錯誤，導致過時的成員殘留。過時的成員會導致新節點無法加入 etcd-events 叢集，進而導致 machine-init 程序失敗，且新節點會持續重新建立。 這個問題的後果包括： 新的控制層節點無法順利啟動。 叢集可能會卡在 RECONCILING 狀態。 由於 machine-init 失敗，控制層節點會持續遭到刪除並重新建立。 這個問題在 1.29 以上版本中已修正。 解決方法： 如果無法升級至 1.29 版，可以按照下列操作說明，手動從叢集中清除有問題的 etcd-events 成員： 使用 SSH 存取運作中的控制層節點。 執行下列指令： ETCDCTL_API=3 etcdctl \ --cacert=/etc/kubernetes/pki/etcd/ca.crt \ --cert=/etc/kubernetes/pki/etcd/server.crt \ --key=/etc/kubernetes/pki/etcd/server.key \ --endpoints=localhost:2382 \ member list 如果回應的成員清單包含已移除的節點，請在節點的第一欄中找出成員 ID，然後執行下列指令： ETCDCTL_API=3 etcdctl \ --cacert=/etc/kubernetes/pki/etcd/ca.crt \ --cert=/etc/kubernetes/pki/etcd/server.crt \ --key=/etc/kubernetes/pki/etcd/server.key \ --endpoints=localhost:2382 \ member remove MEMBER_ID 將 MEMBER_ID 替換為已移除節點的成員 ID。 幾分鐘後，新的控制層節點應會自動加入叢集。
升級與更新	1.30.500-gke.126、1.30.600-gke.68、1.31.100-gke.136、1.31.200-gke.58	缺少 super-admin.conf 檔案，導致控制層升級失敗 升級叢集時，第一個控制層節點的升級程序可能會失敗，且 Ansible 工作中會顯示錯誤訊息，指出缺少 super-admin.conf 檔案。 發生這個問題的原因是，升級的第一個控制層節點可能不是叢集建立期間佈建的第一個節點。升級程序會假設要升級的第一個節點是包含 super-admin.conf 檔案的節點。 下列修補程式更新已修正這個問題：1.30.500-gke.127、1.30.600-gke.69 和 1.31.200-gke.59 解決方法： 如要緩解問題，請在失敗的節點上執行下列步驟： 將 /etc/kubernetes/admin.conf 檔案複製到 /etc/kubernetes/super-admin.conf： cp /etc/kubernetes/admin.conf /etc/kubernetes/super-admin.conf 升級程序會自動重試，應該可以順利完成。
升級與更新	1.29.0 - 1.29.1100、1.30.0 - 1.30.400	如果 Pod 容許 NoSchedule taint，節點排空作業就會停滯 升級期間，系統會考慮將具有 NoSchedule 容許度的 Pod 逐出。不過，由於NoSchedule 容許度，Deployment 或 DaemonSet 控制器可能會在維護中的節點上再次排定 Pod，進而延遲升級。 如要確認是否受到這個問題影響，請按照下列步驟操作： 檢查 anthos-cluster-operator pod 記錄，找出阻礙節點排空的 pod。 在下列記錄片段範例中，node-problem-detector-mgmt-ydhc2 Pod 尚未排空： nodepool_controller.go:720] controllers/NodePool "msg"="Pods yet to drain for 10.0.0.3 machine are 1 : [node-problem-detector-mgmt-ydhc2]" "nodepool"={"Namespace":"test-cluster","Name":"test-cluster"} 針對每個阻礙節點排空的 Pod，執行下列指令來檢查容許度： kubectl get po POD_NAME -n kube-system \ -o json | jq '.spec.tolerations' 將 POD_NAME 替換為阻礙節點排空的 Pod 名稱。 畫面應顯示下列其中一組資訊： 使用 NoSchedule 效果和 Exists 運算子容許 容差 (搭配 NoSchedule 效果和 "baremetal.cluster.gke.io/maintenance" 鍵) 容許度 (效果為空白，且具有 "baremetal.cluster.gke.io/maintenance" 鍵) 例如，回覆可能如下所示： { "effect": "NoSchedule", "operator": "Exists" }, 解決方法： 如要解除節點的排空作業，請採取下列任一做法： 將 baremetal.cluster.gke.io/maintenance:NoExecute 容許條件新增至具有 baremetal.cluster.gke.io/maintenance:Schedule 容許條件的 Pod，且不需要正常終止。 從節點排空期間應遭驅逐的 Pod 中，移除已識別的容許度組合。
網路	1.28、1.29 和 1.30	如果要求來自相同節點，對啟用 hostPort 的 Pod 進行的網路呼叫會失敗 如果要求來自 Pod 執行的同一節點，對已啟用 hostPort 的 Pod 進行的網路呼叫會失敗，並捨棄封包。這項設定適用於所有叢集和節點類型。 但如果建立叢集時未啟用 kube-proxy，則不受影響。 如要確認是否受到這個問題影響，請按照下列步驟操作： 取得 anetd Pod 的名稱： anetd Pod 負責控管網路流量。 kubectl get pods -l k8s-app=cilium -n kube-system 檢查 anetd Pod 的狀態： kubectl -n kube-system exec -it ANETD_POD_NAME -- cilium status --all-clusters 將 ANETD_POD_NAME 替換為叢集中其中一個 anetd Pod 的名稱。 如果回應包含 KubeProxyReplacement: Partial ...，表示您受到這個問題影響。 解決方法 如果您有將要求傳送至 Pod 的用途，而這些 Pod 使用與執行所在節點相同的 hostPort，您可以建立不含 kube-proxy 的叢集。或者，您也可以設定 Pod 使用portmap 容器網路介面 (CNI) 外掛程式。
記錄和監控	在 1.29.100 中發現，其他版本也可能發生	網路連線中斷或服務帳戶無效，導致磁碟 I/O 偏高 stackdriver-log-forwarder Pod 可能會失去連線或服務帳戶過期，導致無法將這些記錄傳送至 logging.googleapis.com，進而造成緩衝區中的記錄累積，導致磁碟 I/O 偏高。Cloud 記錄代理程式 (Fluent Bit) 是名為 stackdriver-log-forwarder 的 DaemonSet，使用以檔案系統為基礎的緩衝區，限制為 4 GB。緩衝區填滿時，代理程式會嘗試輪替或清除緩衝區，這可能會導致 I/O 偏高。 檢查事項： 確認服務帳戶 (SA) 金鑰是否已過期。如果是，請旋轉圖片來解決問題。 您可以使用下列指令確認目前使用的服務帳戶，並在 IAM 中驗證該帳戶： kubectl get secret google-cloud-credentials -n CLUSTER_NAMESPACE -o jsonpath='{.data.credentials\.json}' | base64 --decode 解決方法： 警告：移除緩衝區後，系統會永久刪除目前儲存在緩衝區中的所有記錄 (包括 Kubernetes 節點、Pod 和容器記錄)。 如果緩衝區累積是因網路連線中斷，導致無法連線至 Google Cloud 的記錄服務，當緩衝區遭到刪除或緩衝區已滿，且代理程式無法傳送記錄時，這些記錄就會永久遺失。 新增節點選取器，從叢集中移除 stackdriver-log-forwarder daemonset Pod (這會保留 stackdriver-log-forwarder DaemonSet，但會從節點取消排程)： kubectl --kubeconfig KUBECONFIG -n kube-system \ patch daemonset stackdriver-log-forwarder \ -p '{"spec": {"template": {"spec": {"nodeSelector": {"non-existing": "true"}}}}}' 將 KUBECONFIG 替換為使用者叢集 kubeconfig 檔案的路徑。 確認 stackdriver-log-forwarder Pod 已刪除，再繼續下一個步驟。 如果只有一或幾個節點發生這種情況： 使用 SSH 連線至執行 stackdriver-log-forwarder 的節點 (確認 stackdriver-log-forwarder 不再於這些節點上執行)。 在節點上，使用 rm -rf /var/log/fluent-bit-buffers/ 刪除所有緩衝區檔案，然後按照步驟 6 操作。 如果含有這些檔案的節點過多，且您想套用指令碼來清除所有含有這類積壓區塊的節點，請使用下列指令碼： 部署 DaemonSet，清除 fluent-bit 中緩衝區的所有資料： kubectl --kubeconfig KUBECONFIG -n kube-system apply -f - << EOF apiVersion: apps/v1 kind: DaemonSet metadata: name: fluent-bit-cleanup namespace: kube-system spec: selector: matchLabels: app: fluent-bit-cleanup template: metadata: labels: app: fluent-bit-cleanup spec: containers: - name: fluent-bit-cleanup image: debian:10-slim command: ["bash", "-c"] args: - | rm -rf /var/log/fluent-bit-buffers/ echo "Fluent Bit local buffer is cleaned up." sleep 3600 volumeMounts: - name: varlog mountPath: /var/log securityContext: privileged: true tolerations: - key: "CriticalAddonsOnly" operator: "Exists" - key: node-role.kubernetes.io/master effect: NoSchedule - key: node-role.gke.io/observability effect: NoSchedule volumes: - name: varlog hostPath: path: /var/log EOF 確認 DaemonSet 已清除所有節點。下列兩項指令的輸出內容應等於叢集中的節點數： kubectl --kubeconfig KUBECONFIG logs \ -n kube-system -l app=fluent-bit-cleanup | grep "cleaned up" | wc -l kubectl --kubeconfig KUBECONFIG \ -n kube-system get pods -l app=fluent-bit-cleanup --no-headers | wc -l 刪除清理作業 DaemonSet： kubectl --kubeconfig KUBECONFIG -n kube-system delete ds \ fluent-bit-cleanup 重新啟動 stackdriver-log-forwarder Pod： kubectl --kubeconfig KUBECONFIG \ -n kube-system patch daemonset stackdriver-log-forwarder --type json \ -p='[{"op": "remove", "path": "/spec/template/spec/nodeSelector/non-existing"}]'
升級與更新、作業	1.28、1.29、1.30.0 和 1.30.100	由於 containerd 問題導致 Pod 停滯，升級作業遭到封鎖 節點排空時，Pod 可能會卡在終止狀態。如果 Pod 停滯，可能會阻礙節點排空等作業 (例如升級)。如果容器顯示為正在執行，但容器的基礎主程序已成功結束，Pod 可能會停滯。在這種情況下，crictl stop 指令也不會停止容器。 如要確認是否受到這個問題影響，請按照下列步驟操作： 檢查叢集是否有狀態為 Terminating 的 Pod： kubectl get pods --kubeconfig CLUSTER_KUBECONFIG -A \ -o wide | grep Terminating 如果任何 Pod 停止終止，請使用 kubectl describe 檢查事件： kubectl describe pod POD_NAME \ --kubeconfig CLUSTER_KUBECONFIG \ -n NAMESPACE 如果看到以下警告，且原因都是 Unhealthy 和 FailedKillPod，就表示您受到這個問題影響： Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning FailedKillPod 19m (x592 over 46h) kubelet error killing pod: [failed to "KillContainer" for "dnsmasq" with KillContainerError: "rpc error: code = DeadlineExceeded desc = context deadline exceeded", failed to "KillPodSandbox" for "0843f660-461e-458e-8f07-efe052deae23" with KillPodSandboxError: "rpc error: code = DeadlineExceeded desc = context deadline exceeded"] Warning Unhealthy 4m37s (x16870 over 46h) kubelet (combined from similar events): Readiness probe errored: rpc error: code = Unknown desc = failed to exec in container: failed to start exec "c1ea4ffe7e4f1bacaab4f312bcc45c879785f6e22e7dc2d94abc3a019e20e1a9": OCI runtime exec failed: exec failed: cannot exec in a stopped container: unknown 這個問題是由上游 containerd 問題所致，Google Distributed Cloud 1.28.1000、1.29.600、1.30.200、1.31 和後續版本已修正這個問題。 解決方法 如要解除封鎖叢集作業，請按照下列步驟操作： 強制刪除所有卡住的 Pod： kubectl delete pod POD_NAME -n POD_NAMESPACE --force Pod 重新啟動成功後，請再次嘗試叢集作業。
升級與更新、作業	1.28、1.29 和 1.30.0-1.30.100	由於無法移除 cgroups，導致 Pod 停滯，升級作業遭到封鎖 節點排空時，Pod 可能會卡在終止狀態。如果 Pod 停滯，可能會阻礙叢集作業 (例如升級)，導致節點排空。如果 runc init 程序凍結，Pod 就會停滯，導致 containerd 無法刪除與該 Pod 相關聯的 cgroups。 如要確認是否受到這個問題影響，請按照下列步驟操作： 檢查叢集是否有狀態為 Terminating 的 Pod： kubectl get pods --kubeconfig CLUSTER_KUBECONFIG -A \ -o wide | grep Terminating 檢查節點中 kubelet 記錄，這些節點的 pod 終止作業停滯不前： 下列指令會傳回包含 Failed to remove cgroup 文字的記錄項目。 journalctl -u kubelet --no-pager -f | grep "Failed to remove cgroup" 如果回應包含下列警告，表示您受到這個問題影響： May 22 23:08:00 control-1--f1c6edcdeaa9e08-e387c07294a9d3ab.lab.anthos kubelet[3751]: time="2024-05-22T23:08:00Z" level=warning msg="Failed to remove cgroup (will retry)" error="rmdir /sys/fs/cgroup/freezer/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-podea876418628af89ec2a74ea73d4a6023.slice/cri-containerd-d06aacfec2b399fcf05a187883341db1207c04be3698ec058214a6392cfc6148.scope: device or resource busy" ... May 22 23:09:04 control-1 kubelet[3751]: time="2024-05-22T23:09:04Z" level=warning msg="Failed to remove cgroup (will retry)" error="rmdir /sys/fs/cgroup/net_cls,net_prio/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-podea876418628af89ec2a74ea73d4a6023.slice/cri-containerd-d06aacfec2b399fcf05a187883341db1207c04be3698ec058214a6392cfc6148.scope: device or resource busy" ... 解決方法 如要解除凍結 runc init 程序並解除封鎖叢集作業，請按照下列步驟操作： 使用 kubelet 記錄中的 cgroup 路徑，檢查 freezer.state 檔案的內容，確認 cgroup 是否凍結： cat CGROUP_PATH_FROM_KUBELET_LOGS/freezer.state freezer.state 的內容會指出 cgroup 的狀態。 如果使用先前範例記錄項目中的路徑，指令會如下所示： cat /sys/fs/cgroup/freezer/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-podea876418628af89ec2a74ea73d4a6023.slice/cri-containerd-d06aacfec2b399fcf05a187883341db1207c04be3698ec058214a6392cfc6148.scope/freezer.state 取消凍結處於 FREEZING 或 FROZEN 狀態的 cgroups： echo "THAWED" > CGROUP_PATH_FROM_KUBELET_LOGS/freezer.state cgroups THAWED 後，對應的 runc init 程序會自動結束，cgroups 也會自動移除。這樣可避免 kubelet 記錄中出現額外的 Failed to remove cgroup 警告。處於 Terminating 狀態的 Pod 也會在清理後不久自動移除。 清除凍結的 cgroups 並移除卡住的 Pod 後，請重新嘗試叢集作業。
設定、網路	1.28.0 至 1.28.1000、1.29.0 至 1.29.500，以及 1.30.0 至 1.30.200	因租約更新失敗而導致 NodeNotReady 事件 在已識別的 Google Distributed Cloud 版本中，kubelet 可能無法更新節點租約超過 40 秒，導致 NodeNotReady 事件。 問題會間歇性發生，大約每 7 天出現一次。控制層 VIP 容錯移轉可能會在 NodeNotReady 事件發生前後進行。 這個問題已在 1.28.1100、1.29.600、1.30.300 和後續版本中修正。 解決方法： 如要緩解這個問題，請按照下列步驟設定 kubelet： 建立 /etc/default/kubelet，並在其中新增下列環境變數： HTTP2_READ_IDLE_TIMEOUT_SECONDS=10 HTTP2_PING_TIMEOUT_SECONDS=5 重新啟動 kubelet： systemctl restart kubelet 取得 kubelet 的新程序 ID (PID)： pgrep kubelet 確認節點上的 kubelet 重新啟動後，環境變數是否生效： cat /proc/KUBELET_PID/environ | tr '\0' '\n' | grep -e HTTP2_READ_IDLE_TIMEOUT_SECONDS -e HTTP2_PING_TIMEOUT_SECONDS 將 KUBELET_PID 替換為上一個步驟中指令的輸出內容。 cat 指令輸出內容的最後幾行，應該會列出新增的兩個環境變數。
更新	1.30	使用 bmctl 1.30.x 版更新使用者叢集時發生不可變動的欄位錯誤 使用 bmctl create cluster 指令建立使用者叢集，並在標頭中傳遞 cloudOperationsServiceAccountKeyPath 欄位時，系統會將 spec.clusterOperations.serviceAccountSecret 欄位新增至所建立的叢集資源。這個欄位不在叢集設定檔中，且無法變更。bmctl update cluster 指令不會從標頭填入這個欄位，因此嘗試使用 bmctl update cluster 指令和原始叢集設定檔更新叢集時，會失敗並顯示下列錯誤： [2025-01-15 16:38:46+0000] Failed to calculate diff: --- E000090: Unable to calculate diff An error occurred while calculating diff between live configuration and cluster.yaml file Wrapped error: error in dryRunClient.Update for {map[apiVersion:baremetal.cluster.gke.io/v1 kind:Cluster metadata:map[annotations:map[baremetal.cluster.gke.io/enable-kubelet-read-only-port:false baremetal.cluster.gke.io/maintenance-mode-deadline-seconds:180 preview.baremetal.cluster.gke.io/add-on-configuration:enable] creationTimestamp: name:user-test namespace:cluster-user-test resourceVersion:1171702] spec:map[anthosBareMetalVersion:0.0.0-gke.0 bypassPreflightCheck:false clusterNetwork:map[multipleNetworkInterfaces:false pods:map[cidrBlocks:[10.240.0.0/13]] services:map[cidrBlocks:[172.26.0.0/16]]] clusterOperations:map[location:us-west1 projectID:baremetal-test] controlPlane:map[nodePoolSpec:map[nodes:[map[address:10.200.0.15]]]] gkeConnect:map[projectID:baremetal-test] loadBalancer:map[addressPools:[map[addresses:[10.200.0.20/32 10.200.0.21/32 10.200.0.22/32 10.200.0.23/32 10.200.0.24/32 fd00:1::15/128 fd00:1::16/128 fd00:1::17/128 fd00:1::18/128] name:pool1]] mode:bundled ports:map[controlPlaneLBPort:443] vips:map[controlPlaneVIP:10.200.0.19 ingressVIP:10.200.0.20]] nodeAccess:map[loginUser:root] nodeConfig:map[podDensity:map[maxPodsPerNode:250]] profile:default storage:map[lvpNodeMounts:map[path:/mnt/localpv-disk storageClassName:local-disks] lvpShare:map[numPVUnderSharedPath:5 path:/mnt/localpv-share storageClassName:local-shared]] type:user] status:map[]]}: admission webhook "vcluster.kb.io" denied the request: Cluster.baremetal.cluster.gke.io "user-test" is invalid: spec: Forbidden: Fields should be immutable. (A in old) (B in new) {"clusterNetwork":{"multipleNetworkInterfaces":false,"services":{"cidrBlocks":["172.26.0.0/16"]},"pods":{"cidrBlocks":["10.240.0.0/13"]},"bundledIngress":true},"controlPlane":{"nodePoolSpec":{"nodes":[{"address":"10.200.0.15"}],"operatingSystem":"linux"}},"credentials":{"sshKeySecret":{"name":"ssh-key","namespace":"cluster-user-test"},"imagePullSecret":{"name":"private-registry-creds","namespace":"cluster-user-test"}},"loadBalancer":{"mode":"bundled","ports":{"controlPlaneLBPort":443},"vips":{"controlPlaneVIP":"10.200.0.19","ingressVIP":"10.200.0.20"},"addressPools":[{"name":"pool1","addresses":["10.200.0.20/32","10.200.0.21/32","10.200.0.22/32","10.200.0.23/32","10.200.0.24/32","fd00:1::15/128","fd00:1::16/128","fd00:1::17/128","fd00:1::18/128"]}]},"gkeConnect":{"projectID":"baremetal-test","location":"global","connectServiceAccountSecret":{"name":"gke-connect","namespace":"cluster-user-test"},"registerServiceAccountSecret":{"name":"gke-register","namespace":"cluster-user-test"}},"storage":{"lvpShare":{"path":"/mnt/localpv-share","storageClassName":"local-shared","numPVUnderSharedPath":5},"lvpNodeMounts":{"path":"/mnt/localpv-disk","storageClassName":"local-disks"}},"clusterOperations":{"projectID":"baremetal-test","location":"us-west1" A: ,"serviceAccountSecret":{"name":"google-cloud-credentials","namespace":"cluster-user-test"}},"type":"user","nodeAccess":{"loginUser":"root"},"anthosBareMetalVersion":"0.0.0-gke.0","bypassPreflightCheck":false,"nodeConfig":{"podDensity":{"maxPodsPerNode":250},"containerRuntime":"containerd"},"profile":"default"} B: },"type":"user","nodeAccess":{"loginUser":"root"},"anthosBareMetalVersion":"0.0.0-gke.0","bypassPreflightCheck":false,"nodeConfig":{"podDensity":{"maxPodsPerNode":250},"containerRuntime":"containerd"},"profile":"default"} For more information, see https://cloud.google.com/distributed-cloud/docs/reference/gke-error-ref#E000090 只有在您使用 1.30.x 版的 bmctl 進行更新時，才會發生這個問題。 解決方法： 如要解決這個問題，您可以在更新前取得實際 Cluster 資源的叢集設定： 根據已部署的叢集資源，擷取使用者叢集設定檔： bmctl get config --cluster CLUSTER_NAME \ --kubeconfig ADMIN_KUBECONFIG_PATH 系統會將擷取的自訂資源寫入名為 bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME-TIMESTAMP.yaml 的 YAML 檔案。這個新設定檔包含 spec.clusterOperations.serviceAccountSecret，這是更新指令運作的必要條件。檔案名稱中的 TIMESTAMP 表示檔案建立的日期和時間。 以擷取的檔案取代現有叢集設定檔。儲存現有檔案的備份。 編輯新的叢集設定檔，並使用 bmctl update 更新使用者叢集： bmctl update cluster --cluster CLUSTER_NAME \ --kubeconfig ADMIN_KUBECONFIG_PATH
升級和更新、安全性	1.29、1.30 和 1.31	如果目前的憑證檔案不是符號連結，Kubelet 憑證輪替就會失敗 如果 kubelet-client-current.pem 和 kubelet-server-current.pem 是實際檔案，而非符號連結 (symlink)，Kubelet 憑證輪替就會失敗。 使用 bmctl restore 從備份還原叢集後，可能會發生這個問題。 解決方法： 如果受到這個問題影響，請按照下列步驟操作： 備份目前的憑證檔案： mkdir -p ~/kubelet-backup/ cp -r /var/lib/kubelet/pki/ ~/kubelet-backup/ 或者，刪除累積的憑證檔案： ls | grep -E "^kubelet-server-20*" | xargs rm -rf ls | grep -E "^kubelet-client-20*" | xargs rm -rf 重新命名 kubelet-client-current.pem 和 kubelet-server-current.pem 檔案： 使用時間戳記是常見的重新命名方式。 datetime=$(date +%Y-%m-%d-%H-%M-%S) mv kubelet-server-current.pem kubelet-server-${datetime}.pem mv kubelet-client-current.pem kubelet-client-${datetime}.pem 在與上一個指令相同的工作階段中，建立指向有效最新 (已重新命名) 憑證的符號連結： ln -s kubelet-server-${datetime}.pem kubelet-server-current.pem ln -s kubelet-client-${datetime}.pem kubelet-client-current.pem 將符號連結的權限設為 777： chmod 777 kubelet-server-current.pem chmod 777 kubelet-client-current.pem 如果憑證順利輪替，請刪除備份目錄： rm -rf ~/kubelet-backup/
安裝、升級及更新	1.31	建立自訂資源時發生錯誤 在 Google Distributed Cloud 1.31 版中，嘗試建立自訂資源 (例如叢集 (所有類型) 和工作負載) 時，可能會發生錯誤。這個問題是由 Kubernetes 1.31 中導入的重大變更所致，該變更會導致自訂資源定義中的 caBundle 欄位無法從有效狀態轉換為無效狀態。如要進一步瞭解這項異動，請參閱 Kubernetes 1.31 版的異動記錄。 在 Kubernetes 1.31 之前，caBundle 欄位通常會設為 \n 的臨時值，因為在舊版 Kubernetes 中，API 伺服器不允許 CA 組合內容為空。使用 \n 是避免混淆的合理解決方法，因為 cert-manager 通常會在稍後更新 caBundle。 如果 caBundle 已從無效狀態修補為有效狀態，應該就不會有問題。不過，如果自訂資源定義重新協調回 \n (或其他無效值)，您可能會遇到下列錯誤： ...Invalid value: []byte{0x5c, 0x6e}: unable to load root certificates: unable to parse bytes as PEM block] 解決方法 如果您有自訂資源定義，且 caBundle 設為無效值，可以安全地完全移除 caBundle 欄位。這樣應該就能解決問題。
安裝、升級及更新	1.28、1.29 和 1.30	叢集升級時間過長 在叢集升級期間，每個叢集節點都會排空並升級。在 1.28 以上版本中，Google Distributed Cloud 從基於汙染的節點排空，切換為基於逐出的排空。此外，為解決 Pod 間的相互依賴關係，以驅逐為基礎的排空作業會遵循多階段排空順序。在每個排空階段，Pod 都有 20 分鐘的終止寬限期，而先前的汙點排空則只有 20 分鐘的單一逾時。如果每個階段都需要 20 分鐘才能逐一排空所有 Pod，節點排空時間可能會比先前的汙點排空時間長得多。因此，節點排空時間增加可能會大幅延長叢集升級或進入維護模式的時間。 此外，還有一個上游 Kubernetes 問題，會影響以驅逐為基礎的排空作業逾時邏輯。這個問題也可能導致節點排空時間變長。 解決方法： 如要解決這個問題，可以停用以驅逐為準的節點排空。這會還原為以汙染為準的排空作業。我們不建議使用汙點式排空，因為這類排空方式不會遵守 Pod 中斷預算 (PDB)，可能會導致服務中斷。
安裝、升級及更新	1.16、1.28 和 1.29	過時的預檢失敗記錄可能會阻礙叢集作業 叢集協調是大多數叢集作業的標準階段，包括叢集建立和叢集升級。在叢集協調期間，Google Distributed Cloud 叢集控制器會觸發預檢。如果這項預檢檢查失敗，系統就會封鎖後續的叢集協調作業。因此，包含叢集協調的叢集作業也會遭到封鎖。 這項預檢不會定期執行，只會在叢集協調程序中執行。因此，即使您修正了導致初始預檢失敗的問題，並順利執行隨選預檢，叢集協調作業仍會因這個過時的預檢失敗而遭到封鎖。 如果叢集安裝或升級作業停滯，請按照下列步驟檢查是否受到這個問題影響： 檢查 anthos-cluster-operator Pod 記錄檔是否有類似下列的項目： "msg"="Preflight check not ready. Won't reconcile" 檢查叢集控制器觸發的預檢是否處於失敗狀態： kubectl describe preflightcheck PREFLIGHT_CHECK_NAME \ -n CLUSTER_NAMESPACE \ --kubeconfig=ADMIN_KUBECONFIG 更改下列內容： PREFLIGHT_CHECK_NAME：要刪除的預檢名稱。在此情況下，名稱與叢集名稱相同。 CLUSTER_NAMESPACE：預檢失敗的叢集命名空間。 ADMIN_KUBECONFIG：管理員叢集 kubeconfig 檔案的路徑。 如果預檢失敗 (Status.Pass 是 false)，您可能受到這個問題影響。 這個問題已在 1.30 版和所有後續版本中修正。 解決方法 如要解除封鎖叢集作業，請從管理員叢集手動刪除失敗的飛行前檢查： kubectl delete preflightcheck PREFLIGHT_CHECK_NAME \ -n CLUSTER_NAMESPACE \ --kubeconfig=ADMIN_KUBECONFIG 刪除過時的預檢失敗記錄後，叢集控制器就能建立新的預檢。
安裝、升級及更新	1.30.100、1.30.200 和 1.30.300	使用者叢集建立或升級作業可能無法成功 建立使用者叢集時，或將現有使用者叢集升級至 1.30.100、1.30.200 或 1.30.300 版時，可能會失敗。只有在使用 kubectl 或 GKE On-Prem API 用戶端 ( Google Cloud 主控台、gcloud CLI 或 Terraform) 建立及升級使用者叢集時，才會發生這個問題。 在這種情況下，使用者叢集建立作業會停滯在 Provisioning 狀態，使用者叢集升級作業則會停滯在 Reconciling 狀態。 如要檢查叢集是否受影響，請按照下列步驟操作： 取得叢集資源： kubectl get cluster CLUSTER_NAME -n USER_CLUSTER_NAMESPACE \ --kubeconfig ADMIN_KUBECONFIG 更改下列內容： CLUSTER_NAME：卡住的使用者叢集名稱。 USER_CLUSTER_NAMESPACE：使用者叢集命名空間名稱。 ADMIN_KUBECONFIG：管理叢集的 kubeconfig 檔案路徑。 如果 CLUSTER STATE 值為 Provisioning 或 Reconciling，可能會受到這個問題影響。以下範例回應表示升級作業停滯： NAME ABM VERSION DESIRED ABM VERSION CLUSTER STATE some-cluster 1.30.0-gke.1930 1.30.100-gke.96 Reconciling 版本不符也表示叢集升級尚未完成。 找出 anthos-cluster-operator Pod 的完整名稱： kubectl get pods -n kube-system -o=name \ -l baremetal.cluster.gke.io/lifecycle-controller-component=true \ --kubeconfig ADMIN_KUBECONFIG 如下列範例所示，輸出內容是 Pod 清單，其中包含 anthos-cluster-operator Pod： pod/anthos-cluster-operator-1.30.100-gke.96-d96cf6765-lqbsg pod/cap-controller-manager-1.30.100-gke.96-fcb5b5797-xzmb7 串流 anthos-cluster-operator Pod 記錄，查看是否有重複訊息，指出叢集卡在佈建或調解程序： kubectl logs POD_NAME -n kube-system -f --since=15s \ --kubeconfig ADMIN_KUBECONFIG | \ grep "Waiting for configMapForwarder to forward kube-system/metadata-image-digests to the cluster namespace, requeuing" 將 POD_NAME 替換為上一個步驟中 anthos-cluster-operator Pod 的完整名稱。 執行指令時，請注意是否有持續串流的相符記錄行，這表示叢集作業停滯。如果叢集卡在調解程序中，您會看到類似下列範例的輸出內容： ... I1107 17:06:32.528471 1 reconciler.go:1475] "msg"="Waiting for configMapForwarder to forward kube-system/metadata-image-digests to the cluster namespace, requeuing" "Cluster"={"name":"user-t05db3f0761d4061-cluster","namespace":"cluster-user-t05db3f0761d4061-cluster"} "controller"="cluster" "controllerGroup"="baremetal.cluster.gke.io" "controllerKind"="Cluster" "name"="user-t05db3f0761d4061-cluster" "namespace"="cluster-user-t05db3f0761d4061-cluster" "reconcileID"="a09c70a6-059f-4e81-b6b2-aaf19fd5f926" I1107 17:06:37.575174 1 reconciler.go:1475] "msg"="Waiting for configMapForwarder to forward kube-system/metadata-image-digests to the cluster namespace, requeuing" "Cluster"={"name":"user-t05db3f0761d4061-cluster","namespace":"cluster-user-t05db3f0761d4061-cluster"} "controller"="cluster" "controllerGroup"="baremetal.cluster.gke.io" "controllerKind"="Cluster" "name"="user-t05db3f0761d4061-cluster" "namespace"="cluster-user-t05db3f0761d4061-cluster" "reconcileID"="e1906c8a-cee0-43fd-ad78-88d106d4d30a""Name":"user-test-v2"} "err"="1 error occurred:\n\t* failed to construct the job: ConfigMap \"metadata-image-digests\" not found\n\n" ... 按下 Control+C 即可停止串流記錄。 檢查 ConfigMapForwarder 是否停滯： kubectl get configmapforwarder metadata-image-digests-in-cluster \ -n USER_CLUSTER_NAMESPACE \ -o jsonpath='{range .status.conditions[?(@.type=="Ready")]}Reason: {.reason}{"\n"}Message: {.message}{"\n"}{end}' \ --kubeconfig ADMIN_KUBECONFIG 回應包含 ConfigMapForwarder 資源中的原因和訊息。如果 ConfigMapForwarder 停滯，您應該會看到類似以下的輸出內容： Reason: Stalled Message: cannot forward configmap kube-system/metadata-image-digests without "baremetal.cluster.gke.io/mark-source" annotation 確認使用者叢集命名空間中沒有 metadata-image-digests ConfigMap： kubectl get configmaps metadata-image-digests \ -n USER_CLUSTER_NAMESPACE \ --kubeconfig ADMIN_KUBECONFIG 回覆內容應如下所示： Error from server (NotFound): configmaps "metadata-image-digests" not found 解決方法 如要解決問題，可以手動更新 ConfigMap，加入缺少的註解： 在 ConfigMap 中新增缺少的註解： kubectl annotate configmap metadata-image-digests \ -n kube-system "baremetal.cluster.gke.io/mark-source"="true" \ --kubeconfig ADMIN_KUBECONFIG 正確註解後，系統應會在使用者叢集命名空間中自動建立 metadata-image-digests ConfigMap。 確認 ConfigMap 會在使用者叢集命名空間中自動建立： kubectl get configmaps metadata-image-digests \ -n USER_CLUSTER_NAMESPACE \ --kubeconfig ADMIN_KUBECONFIG 如果 ConfigMap 建立成功，指令回應會類似下列內容： NAME DATA AGE metadata-image-digests 0 7s 完成上述修正和驗證後，叢集運算子應會解除封鎖，叢集作業也會照常進行。
作業：重設/刪除	1.30.0 - 1.30.300、1.29.0 - 1.29.700、1.28.0 - 1.28.1100	非根使用者無法執行 bmctl restore 來還原仲裁 以非根使用者身分執行 bmctl restore --control-plane-node 時，從控制平面節點複製檔案到工作站電腦時會發生 chown 問題。 解決方法： 以 sudo 執行 bmctl restore --control-plane-node 指令，適用於非超級使用者。
升級	1.30.0-gke.1930	由於缺少 pause:3.9 映像檔，升級健康檢查工作仍處於有效狀態 升級期間，由於缺少 pause:3.9 映像檔，升級健康狀態檢查作業可能會維持在有效狀態。 這個問題不會影響升級作業是否成功。 解決方法： 使用下列指令手動刪除 upgrade-health-check 工作： kubectl delete job upgrade-health-check-JOB_ID --cascade=true
作業系統	1.28、1.29、1.30	RHEL 9.2 容器中的下載速度緩慢 如果構件大小超過 cgroup memory.max限制，下載速度可能會極慢。這個問題是由 Red Hat Enterprise Linux (RHEL) 9.2 的 Linux 核心錯誤所導致。啟用 cgroup v2 的核心會受到影響。這個問題已在核心版本 5.14.0-284.40.1.el_9.2 以上版本中修正。 解決方法： 針對受影響的 Pod，請增加容器的記憶體限制設定 (spec.containers[].resources.limits.memory)，使限制大於下載構件的大小。
升級	1.28 至 1.29.200	networks.networking.gke.io 自訂資源定義發生衝突，導致叢集升級失敗 升級裸機叢集時，升級作業可能會失敗，並顯示錯誤訊息，指出 networks.networking.gke.io 自訂資源定義發生衝突。具體來說，錯誤會指出 v1alpha1 不存在於 spec.versions 中。 發生這個問題的原因是，在升級程序期間，自訂資源定義的 v1alpha1 版本未遷移至 v1。 解決方法： 使用下列指令修補受影響的叢集： kubectl patch customresourcedefinitions/networkinterfaces.networking.gke.io \ --subresource status --type json \ --patch='[{ "op": "replace", "path": "/status/storedVersions", "value": ["v1"]}]' kubectl patch customresourcedefinitions/networks.networking.gke.io \ --subresource status --type json \ --patch='[{ "op": "replace", "path": "/status/storedVersions", "value": ["v1"]}]'
安裝、升級和更新	1.28.0 至 1.28.600，以及 1.29.0 至 1.29.200	檢查 check_inotify_max_user_instances 和 check_inotify_max_user_watches 設定時，機器預檢失敗 在叢集安裝或升級期間，與 fs.inotify 核心設定相關的機器預檢可能會失敗。如果受到這個問題影響，電腦的預檢記錄會包含類似下列內容的錯誤： Minimum kernel setting required for fs.inotify.max_user_instances is 8192. Current fs.inotify.max_user_instances value is 128. Please run "echo "fs.inotify.max_user_instances=8192" | sudo tee --append /etc/sysctl.conf" to set the correct value. 發生這個問題的原因是，系統從控制層和啟動主機讀取 fs.inotify max_user_instances 和 max_user_watches 值時發生錯誤，而非從預期的節點機器讀取。 解決方法： 如要解決這個問題，請在所有控制層和啟動程序機器上，將 fs.inotify.max_user_instances 和 fs.inotify.max_user_watches 調整為建議值： echo fs.inotify.max_user_watches=524288 | sudo tee --append /etc/sysctl.conf echo fs.inotify.max_user_instances=8192 | sudo tee --append /etc/sysctl.conf sudo sysctl -p 安裝或升級作業完成後，如有需要，可以還原這些值。
升級	1.28.0 - 1.28.500	叢集升級失敗，並顯示 Google Cloud 可連線性檢查錯誤 使用 bmctl 升級叢集時，即使可從管理員工作站連上目標網址，升級作業仍可能因 GCP reachability check failed 錯誤而失敗。這個問題是由 bmctl 1.28.0 至 1.28.500 版本的錯誤所致。 解決方法： 執行 bmctl upgrade 指令前，請設定 GOOGLE_APPLICATION_CREDENTIALS 環境變數，使其指向有效的服務帳戶金鑰檔案： export GOOGLE_APPLICATION_CREDENTIALS=JSON_KEY_PATH bmctl upgrade cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG 以這種方式設定應用程式預設憑證 (ADC)，可確保 bmctl 擁有存取 Google API 端點的必要憑證。
設定、安裝、升級與更新、網路、安全性	1.15、1.16、1.28、1.29	需要 ipam-controller-manager 時，叢集安裝和升級作業會失敗 如果需要 ipam-controller-manager，且叢集在 Red Hat Enterprise Linux (RHEL) 8.9 以上版本 (視上游 RHEL 變更而定) 上執行，且 SELinux 處於強制模式，叢集安裝和升級就會失敗。如果 container-selinux 版本高於 2.225.0，就會發生這種情況。 在下列任何情況下，叢集都需要 ipam-controller-manager： 叢集已設定為 IPv4/IPv6 雙重堆疊網路 叢集已設定為 clusterNetwork.flatIPv4 設為 true 叢集已設定 preview.baremetal.cluster.gke.io/multi-networking: enable 註解 安裝 ipam-controller-manager 時，叢集安裝和升級作業會失敗。 解決方法 在每個控制層節點上，將 /etc/kubernetes 目錄的預設內容設為 etc_t： semanage fcontext /etc/kubernetes --add -t etc_t semanage fcontext /etc/kubernetes/controller-manager.conf --add -t etc_t restorecon -R /etc/kubernetes 這些指令會還原 /etc/kubernetes 目錄的 container-selinux 變更。 將叢集升級至含有修正程式的版本後，請在每個控制層節點上還原先前的檔案內容變更： semanage fcontext /etc/kubernetes --delete -t etc_t semanage fcontext /etc/kubernetes/controller-manager.conf --delete -t etc_t restorecon -R /etc/kubernetes
升級	1.28.0 - 1.28.500	叢集升級失敗，並顯示 Google Cloud 可連線性檢查錯誤 使用 bmctl 升級叢集時，即使可從管理員工作站連上目標網址，升級作業仍可能因 GCP reachability check failed 錯誤而失敗。這個問題是由 bmctl 1.28.0 至 1.28.500 版本的錯誤所致。 解決方法： 執行 bmctl upgrade 指令前，請設定 GOOGLE_APPLICATION_CREDENTIALS 環境變數，使其指向有效的服務帳戶金鑰檔案： export GOOGLE_APPLICATION_CREDENTIALS=JSON_KEY_PATH bmctl upgrade cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG 以這種方式設定應用程式預設憑證 (ADC)，可確保 bmctl 擁有存取 Google API 端點的必要憑證。
安裝	1.29	叢集二進位授權問題 (使用獨立的負載平衡器節點集區) 如果您在建立叢集時啟用二進位授權政策，安裝含有獨立負載平衡器節點集區的叢集可能會失敗。 發生這個問題的原因是，Binary Authorization Webhook 會封鎖 GKE Identity Service Pod 和其他重要 Pod 的建立作業。 如要判斷是否受到這個問題影響，請完成下列步驟： 找出失敗的 Pod： kubectl get pods \ -n anthos-identity-service \ --kubeconfig CLUSTER_KUBECONFIG 描述失敗的 Pod。 在輸出內容中尋找下列訊息： admission webhook "binaryauthorization.googleapis.com" denied the request: failed to post request to endpoint: Post "https://binaryauthorization.googleapis.com/internal/projects/PROJECT_NUMBER/policy/locations/LOCATION/clusters/CLUSTER_NAME:admissionReview": oauth2/google: status code 400: {"error":"invalid_target","error_description":"The target service indicated by the \"audience\" parameters is invalid. This might either be because the pool or provider is disabled or deleted or because it doesn't exist."} 如果看到上述訊息，表示叢集有這個問題。 解決方法： 如要解決這個問題，請完成下列步驟： 取消叢集建立作業。 從叢集設定檔中移除 spec.binaryAuthorization 區塊。 建立停用二進位授權的叢集。 安裝完成後，請為現有叢集啟用二進位授權政策。
設定、安裝	1.10、1.11、1.12、1.13、1.14、1.15、1.16、1.28、1.29、1.30	啟用 SELinux 的掛接點導致問題 如果啟用 SELinux，並將檔案系統掛接至 Kubernetes 相關目錄，可能會發生叢集建立失敗、檔案無法讀取或權限問題等狀況。 如要判斷是否受到這個問題影響，請執行下列指令： ls -Z /var/lib/containerd 。 如果看到 system_u:object_r:unlabeled_t:s0，但預期會看到其他標籤 (例如 system_u:object_r:container_var_lib_t:s0)，表示你受到影響。 解決方法： 如果您最近將檔案系統掛接到目錄，請確保這些目錄的 SELinux 設定為最新狀態。 此外，在執行 bmctl create cluster 前，您也應在每部電腦上執行下列指令： restorecon -R -v /var restorecon -R -v /etc 這項一次性修正會在重新啟動後保留，但每次新增具有相同掛接點的節點時，都必須進行這項修正。詳情請參閱 Red Hat 說明文件中的「掛接檔案系統」。
重設/刪除	1.29.0	嘗試刪除命名空間時，重設使用者叢集失敗 執行 bmctl reset cluster -c ${USER_CLUSTER} 時，如果所有相關工作都已完成，這項指令會無法刪除使用者叢集命名空間。使用者叢集命名空間停滯在 Terminating 狀態。最終，叢集重設作業會逾時並傳回錯誤。 解決方法： 如要移除命名空間並完成使用者叢集重設，請按照下列步驟操作： 從管理員叢集刪除 metrics-server Pod： kubectl delete pods -l k8s-app=metrics-server \ -n gke-managed-metrics-server --kubeconfig ADMIN_KUBECONFIG_PATH 在這種情況下，metrics-server Pod 會阻止移除叢集命名空間。 在管理員叢集中，強制移除使用者叢集命名空間中的終結器： kubectl get ns ${USER_CLUSTER_NAMESPACE} -ojson | \ jq '.spec.finalizers = []' | \ kubectl replace --raw "/api/v1/namespaces/${USER_CLUSTER_NAMESPACE}/finalize" -f - 移除終結器後，系統會移除叢集命名空間，叢集重設作業即完成。
設定、安裝、安全性	1.16.0 至 1.16.7 和 1.28.0 至 1.28.400	二進位授權部署項目缺少 nodeSelector 如果您已為 Google Distributed Cloud 啟用二進位授權，且使用的版本為 1.16.0 至 1.16.7 或 1.28.0 至 1.28.400，可能會遇到排定功能 Pod 時的問題。在這些版本中，Binary Authorization Deployment 缺少 nodeSelector，因此這項功能的 Pod 可以排定在工作站節點上，而不是控制層節點。這個行為不會導致任何項目失敗，但並非預期行為。 解決方法： 請針對所有受影響的叢集完成下列步驟： 開啟二進位授權部署檔案： kubectl edit -n binauthz-system deployment binauthz-module-deployment 在 spec.template.spec 區塊中新增下列 nodeSelector： nodeSelector: node-role.kubernetes.io/control-plane: "" 儲存變更。 儲存變更後，系統只會將 Pod 重新部署至控制層節點。每次升級後都必須套用這項修正。
升級與更新	1.28.0、1.28.100、1.28.200、1.28.300	將叢集升級至 1.28.0-1.28.300 時發生錯誤 如果叢集是在 1.11.0 版之前建立，升級至 1.28.0-1.28.300 版時，生命週期控制器部署工具 Pod 可能會在升級期間進入錯誤狀態。發生這種情況時，生命週期控制器部署工具 Pod 的記錄會顯示類似以下的錯誤訊息： "inventorymachines.baremetal.cluster.gke.io\" is invalid: status.storedVersions[0]: Invalid value: \"v1alpha1\": must appear in spec.versions 解決方法： 這個問題已在 1.28.400 版中修正。請升級至 1.28.400 以上版本，解決這個問題。 如果無法升級，請執行下列指令來解決問題： kubectl patch customresourcedefinitions/nodepoolclaims.baremetal.cluster.gke.io \ --subresource status --type json \ --patch='[{ "op": "replace", "path": "/status/storedVersions", "value": ["v1"]}]' kubectl patch customresourcedefinitions/machineclasses.baremetal.cluster.gke.io \ --subresource status --type json \ --patch='[{ "op": "replace", "path": "/status/storedVersions", "value": ["v1"]}]' kubectl patch customresourcedefinitions/inventorymachines.baremetal.cluster.gke.io \ --subresource status --type json \ --patch='[{ "op": "replace", "path": "/status/storedVersions", "value": ["v1"]}]'
記錄和監控	1.13.7、1.14、1.15、1.16、1.28	記錄檔探索工具中顯示的專案 ID 不正確 有時，叢集或容器記錄檔會在記錄檔探索工具中，標記不同的專案 ID。resource.labels.project_id 如果叢集設定為使用可觀測性 PROJECT_ONE，且該設定位於叢集設定的 clusterOperations.projectID 欄位中，就可能發生這種情況。不過，設定中的 cloudOperationsServiceAccountKeyPath 具有專案 PROJECT_TWO 的服務帳戶金鑰。 在這種情況下，所有記錄都會傳送至 PROJECT_ONE，但 resource.labels.project_id 會標示為 PROJECT_TWO。 解決方法： 請使用下列其中一種方式解決問題： 使用相同目標專案中的服務帳戶。 將服務帳戶金鑰 JSON 檔案中的 project_id 變更為目前的專案。 在 Logs Explorer 中，直接從記錄篩選器變更 project_id。
網路	1.29、1.30	使用 BGP 進行套裝組合負載平衡的叢集效能下降 如果 1.29.0 版叢集使用搭配 BGP 的組合式負載平衡，當 LoadBalancer 類型的 Service 總數接近 2,000 時，負載平衡效能可能會降低。效能降低時，新建立的服務可能需要很長時間才能連線，或無法連線至用戶端。現有服務會繼續運作，但無法有效處理失敗模式，例如負載平衡器節點遺失。如果ang-controller-manager部署作業因記憶體不足而終止，就會發生這類服務問題。 如果叢集受到這個問題影響，叢集中的服務將無法連線且不正常，且「部署」ang-controller-manager處於 CrashLoopBackOff 狀態。列出 ang-controller-manager Deployment 時的回應類似如下： ang-controller-manager-79cdd97b88-9b2rd 0/1 CrashLoopBackOff 639 (59s ago) 2d10h 10.250.210.152 vm-bgplb-centos4-n1-02 <none> <none> ang-controller-manager-79cdd97b88-r6tcl 0/1 CrashLoopBackOff 620 (4m6s ago) 2d10h 10.250.202.2 vm-bgplb-centos4-n1-11 <none> <none> 解決方法 如要解決這個問題，可以將 ang-controller-manager Deployment 的記憶體資源限制增加 100MiB，並移除 CPU 限制： kubectl edit deployment ang-controller-manager -n kube-system --kubeconfig ADMIN_KUBECONFIG 成功變更並關閉編輯器後，您應該會看到下列輸出內容： deployment.apps/ang-controller-manager edited 如要確認變更是否已套用，請檢查叢集中 ang-controller-manager 的資訊清單： kubectl get deployment ang-controller-manager \ -n kube-system \ -o custom-columns=NAME:.metadata.name,CPU_LIMITS:.spec.template.spec.containers[*].resources.limits.cpu,MEMORY_LIMITS:.spec.template.spec.containers[*].resources.limits.memory \ --kubeconfig ADMIN_KUBECONFIG 回覆內容大致如下： NAME CPU_LIMITS MEMORY_LIMITS ang-controller-manager <none> 400Mi
安裝、升級、備份及還原	1.28.0、1.28.100	Artifact Registry 端點 gcr.io 連線問題可能會封鎖叢集作業 管理員叢集的多個叢集作業會建立啟動叢集。建立啟動叢集前，bmctl 會從管理員工作站執行 Google Cloud 可連線性檢查。 如果 Artifact Registry 端點 gcr.io 的連線發生問題，這項檢查可能會失敗，並顯示類似下列的錯誤訊息： system checks failed for bootstrap machine: GCP reachability check failed: failed to reach url https://gcr.io: Get "https://cloud.google.com/artifact-registry/": net/http: request canceled (Client.Timeout exceeded while awaiting headers) 解決方法 如要解決這個問題，請使用 --ignore-validation-errors 旗標重試作業。
網路	1.15、1.16	GKE Dataplane V2 與部分儲存空間驅動程式不相容 裸機叢集使用 GKE Dataplane V2，但這與部分儲存空間供應商不相容。您可能會遇到 NFS 磁碟區或 Pod 卡住的問題。如果工作負載使用 ReadWriteMany 磁碟區，且磁碟區是由容易發生這個問題的儲存空間驅動程式支援，就特別容易發生這種情況： Robin.io Portworx (sharedv4 服務量) csi-nfs 請注意，這份清單僅列出部分示例。 解決方法 下列 Ubuntu 版本已修正這個問題： 20.04 LTS：使用 5.4.0 核心映像檔，且版本晚於 linux-image-5.4.0-166-generic 22.04 LTS：使用 5.15.0 核心映像檔 (晚於 linux-image-5.15.0-88-generic)，或使用 6.5 HWE 核心。 如果不是使用這些版本，請與 Google 支援團隊聯絡。
記錄和監控	1.15、1.16、1.28	kube-state-metrics 大型叢集中的 OOM 您可能會發現 kube-state-metrics 或 gke-metrics-agent Pod 與 kube-state-metrics 位於同一節點，但記憶體不足 (OOM)。 如果叢集有超過 50 個節點，或有許多 Kubernetes 物件，就可能發生這種情況。 解決方法 如要解決這個問題，請更新 stackdriver 自訂資源定義，使用 ksmNodePodMetricsOnly 功能閘道。這項功能閘可確保只公開少數重要指標。 如要使用這項解決方法，請完成下列步驟： 檢查自訂資源定義，瞭解可用的功能閘道：stackdriver kubectl -n kube-system get crd stackdrivers.addons.gke.io -o yaml | grep ksmNodePodMetricsOnly 更新 stackdriver 自訂資源定義，啟用 ksmNodePodMetricsOnly： kind:stackdriver spec: featureGates: ksmNodePodMetricsOnly: true
安裝	1.28.0-1.28.200	RHEL 9.2 缺少 iptables，因此預檢失敗 在 Red Hat Enterprise Linux (RHEL) 9.2 作業系統上安裝叢集時，可能會因為缺少 iptables 套件而失敗。失敗發生在預檢期間，並觸發類似下列內容的錯誤訊息： 'check_package_availability_pass': "The following packages are not available: ['iptables']" Google Distributed Cloud 1.28 版的 RHEL 9.2 為預先發布版。 解決方法 如要略過前置檢查錯誤，請在叢集資源中將 spec.bypassPreflightCheck 設為 true。
作業	1.10、1.11、1.12、1.13、1.14、1.15、1.16	大規模環境中，MetalLB 容錯移轉速度緩慢 如果 MetalLB 處理的服務數量過多 (超過 10,000 個)，容錯移轉可能需要超過一小時。這是因為 MetalLB 使用的佇列有速率限制，因此在大量擴充時，可能需要一段時間才能到達需要容錯移轉的服務。 解決方法 將叢集升級至 1.28 以上版本。如果無法升級，手動編輯服務 (例如新增註解) 會導致服務更快容錯移轉。
作業	1.16.0-1.16.6、1.28.0-1.28.200	如果已啟用 Proxy，就必須在管理員工作站上設定環境變數 如果管理工作站上未定義環境變數 HTTPS_PROXY 和 NO_PROXY，bmctl check cluster 可能會因 Proxy 故障而失敗。bmctl 指令會回報無法呼叫某些 Google 服務的錯誤訊息，例如： [2024-01-29 23:49:03+0000] error validating cluster config: 2 errors occurred: * GKERegister check failed: 2 errors occurred: * Get "https://gkehub.googleapis.com/v1beta1/projects/baremetal-runqi/locations/global/memberships/ci-ec1a14a903eb1fc": oauth2: cannot fetch token: Post "https://oauth2.googleapis.com/token": dial tcp 108.177.98.95:443: i/o timeout * Post "https://cloudresourcemanager.googleapis.com/v1/projects/baremetal-runqi:testIamPermissions?alt=json&prettyPrint=false": oauth2: cannot fetch token: Post "https://oauth2.googleapis.com/token": dial tcp 74.125.199.95:443: i/o timeout 解決方法 在管理員工作站上，手動設定 HTTPS_PROXY 和 NO_PROXY。
升級與更新	1.28.0-gke.435	如果 audit.log 的擁有權不正確，升級至 1.28.0-gke.435 版可能會失敗 在某些情況下，控制層節點上的 /var/log/apiserver/audit.log 檔案會將群組和使用者擁有權都設為 root。從 1.16.x 版升級至 1.28.0-gke.435 版時，這項檔案擁有權設定會導致控制層節點升級失敗。 這項問題僅適用於 1.11 版之前建立的叢集，且這些叢集已停用 Cloud 稽核記錄。對於 1.9 以上版本的叢集，Cloud 稽核記錄預設為啟用。 解決方法 如果無法將叢集升級至 1.28.100-gke.146 版，請按照下列步驟操作，將叢集升級至 1.28.0-gke.435 版： 如果已啟用 Cloud 稽核記錄，請移除 /var/log/apiserver/audit.log 檔案。 如果 Cloud 稽核記錄已停用，請將 /var/log/apiserver/audit.log 的擁有權變更為與父項目錄 /var/log/apiserver 相同。
網路、升級與更新	1.28.0-gke.435	MetalLB 不會將 IP 位址指派給 VIP 服務 Google Distributed Cloud 使用 MetalLB 進行套裝組合負載平衡。在 Google Distributed Cloud 1.28.0-gke.435 版中，隨附的 MetalLB 已升級至 0.13 版，並導入 IPAddressPools 的 CRD 支援。不過，由於 ConfigMaps 允許 IPAddressPool 的任何名稱，因此必須將集區名稱轉換為符合 Kubernetes 規範的名稱，方法是在 IPAddressPool 名稱結尾附加雜湊。舉例來說，當您將叢集升級至 1.28.0-gke.435 版時，名稱為 default 的 IPAddressPool 會轉換為 default-qpvpd 等名稱。 由於 MetalLB 需要特定名稱的 IPPool 才能進行選取，因此名稱轉換會導致 MetalLB 無法選取集區並指派 IP 位址。因此，使用 metallb.universe.tf/address-pool 做為註解來選取 IP 位址的位址集區的服務，將不再從 MetalLB 控制器接收 IP 位址。 Google Distributed Cloud 1.28.100-gke.146 版已修正這個問題。 解決方法 如果無法將叢集升級至 1.28.100-gke.146 版，請按照下列步驟操作，做為暫時解決方法： 取得 IPAddressPool 的轉換名稱： kubectl get IPAddressPools -n kube-system 更新受影響的 Service，將 metallb.universe.tf/address-pool 註解設為轉換後的名稱 (含雜湊)。 舉例來說，如果 IPAddressPool 名稱從 default 轉換為 default-qpvpd 等名稱，請將服務中的 metallb.universe.tf/address-pool: default 註解變更為 metallb.universe.tf/address-pool: default-qpvpd。 名稱轉換中使用的雜湊是決定性雜湊，因此這項解決方法會持續有效。
升級與更新	1.14、1.15、1.16、1.28、1.29	升級至 1.14.x 版後出現孤立 Pod 將叢集升級至 1.14.x 版時，系統不會刪除舊版的部分資源。具體來說，您可能會看到一組類似下列的孤立 Pod： capi-webhook-system/capi-controller-manager-xxx capi-webhook-system/capi-kubeadm-bootstrap-controller-manager-xxx 這些孤立物件不會直接影響叢集運作，但建議您移除這些物件，以符合最佳做法。 執行下列指令，移除孤立物件： kubectl delete ns capi-webhook-system kubectl delete validatingwebhookconfigurations capi-validating-webhook-configuration kubectl delete mutatingwebhookconfigurations capi-mutating-webhook-configuration 這個問題在 Google Distributed Cloud 1.15.0 以上版本中已修正。
安裝	1.14	叢集建立作業停滯在 machine-init 工作 如果您嘗試安裝 Google Distributed Cloud 1.14.x 版，可能會因 machine-init 工作而發生失敗情形，類似於下列範例輸出內容： "kubeadm join" task failed due to: error execution phase control-plane-join/etcd: error creating local etcd static pod manifest file: etcdserver: re-configuration failed due to not enough started members "kubeadm reset" task failed due to: panic: runtime error: invalid memory address or nil pointer dereference 解決方法： 移除導致 machine-init 工作失敗的過時 etcd 成員。在運作中的控制平面節點上完成下列步驟： 列出現有的 etcd 成員： etcdctl --key=/etc/kubernetes/pki/etcd/peer.key \ --cacert=/etc/kubernetes/pki/etcd/ca.crt \ --cert=/etc/kubernetes/pki/etcd/peer.crt \ member list 尋找狀態為 unstarted 的成員，如下列範例輸出內容所示： 5feb7ac839625038, started, vm-72fed95a, https://203.0.113.11:2380, https://203.0.113.11:2379, false 99f09f145a74cb15, started, vm-8a5bc966, https://203.0.113.12:2380, https://203.0.113.12:2379, false bd1949bcb70e2cb5, unstarted, , https://203.0.113.10:2380, , false 移除失敗的 etcd 成員： etcdctl --key=/etc/kubernetes/pki/etcd/peer.key \ --cacert=/etc/kubernetes/pki/etcd/ca.crt \ --cert=/etc/kubernetes/pki/etcd/peer.crt \ member remove MEMBER_ID 將 MEMBER_ID 替換為失敗的 etcd 成員 ID。在先前的範例輸出內容中，這個 ID 是 bd1949bcb70e2cb5。 下列範例輸出內容顯示成員已移除： Member bd1949bcb70e2cb5 removed from cluster 9d70e2a69debf2f
網路	1.28.0	缺少 Node Cilium-operator 和 list watch 權限 在 Cilium 1.13 中，cilium-operator ClusterRole 權限不正確。缺少節點 list 和 watch 權限。cilium-operator 無法啟動垃圾收集器，導致下列問題： Cilium 資源洩漏。 過時的 ID 不會從 BFP 政策對應檔中移除。 政策對應表可能會達到 16K 的限制。 無法新增項目。 NetworkPolicy 強制執行不正確。 身分可能達到 64K 限制。 無法建立新的 Pod。 如果運算子缺少節點權限，系統會回報下列範例記錄訊息： 2024-01-02T20:41:37.742276761Z level=error msg=k8sError error="github.com/cilium/cilium/operator/watchers/node.go:83: Failed to watch *v1.Node: failed to list *v1.Node: nodes is forbidden: User \"system:serviceaccount:kube-system:cilium-operator\" cannot list resource \"nodes\" in API group \"\" at the cluster scope" subsys=k8s 如果 Cilium 代理程式無法將項目插入政策對應，就會回報錯誤訊息，如下例所示： level=error msg="Failed to add PolicyMap key" bpfMapKey="{6572100 0 0 0}" containerID= datapathPolicyRevision=0 desiredPolicyRevision=7 endpointID=1313 error="Unable to update element for Cilium_policy_01313 map with file descriptor 190: the map is full, please consider resizing it. argument list too long" identity=128 ipv4= ipv6= k8sPodName=/ port=0 subsys=endpoint 解決方法： 移除 Cilium 身分，然後將缺少的 ClusterRole 權限新增至運算子： 移除現有的 CiliumIdentity 物件： kubectl delete ciliumid –-all 編輯 cilium-operator ClusterRole 物件： kubectl edit clusterrole cilium-operator 新增 nodes 的章節，其中包含缺少的權限，如下列範例所示： - apiGroups: - "" resources: - nodes verbs: - get - list - watch 儲存並關閉編輯器。運算子會動態偵測權限變更。您不需要手動重新啟動運算子。
升級與更新	1.15.0-1.15.7、1.16.0-1.16.3	預檢時發生暫時性問題 升級前檢查期間執行的 kubeadm 健康狀態檢查工作可能會失敗，並顯示下列錯誤訊息： [ERROR CreateJob]: could not delete Job \"upgrade-health-check\" in the namespace \"kube-system\": jobs.batch \"upgrade-health-check\" not found 您可以放心忽略這項錯誤。如果遇到這個錯誤而無法升級，請重新執行升級指令。 如果您使用 bmctl preflightcheck 指令執行預檢時看到這項錯誤，表示這項失敗不會阻礙任何作業。您可以再次執行預檢檢查，取得準確的預檢資訊。 解決方法： 重新執行升級指令，或在 bmctl preflightcheck 期間遇到問題時，重新執行 preflightcheck 指令。
作業	1.14、1.15.0-1.15.7、1.16.0-1.16.3、1.28.0	節點更換或移除時，週期性網路健康狀態檢查會失敗 如果叢集在節點更換或移除後，會定期執行網路健康狀態檢查，就會受到這個問題影響。如果叢集會定期進行健康狀態檢查，在節點更換或移除後，定期網路健康狀態檢查會失敗，因為網路清單 ConfigMap 建立後就不會更新。 解決方法： 建議的解決方法是刪除清單 ConfigMap 和定期網路健康狀態檢查。叢集運算子會自動使用最新資訊重新建立這些資源。 如為 1.14.x 叢集，請執行下列指令： kubectl delete configmap \ $(kubectl get cronjob CLUSTER_NAME-network -o=jsonpath='{.spec.jobTemplate.spec.template.spec.volumes[?(@name=="inventory-config-volume")].configMap.name}' \ -n CLUSTER_NAMESPACE) \ -n CLUSTER_NAMESPACE \ --kubeconfig ADMIN_KUBECONFIG kubectl delete healthchecks.baremetal.cluster.gke.io \ CLUSTER_NAME-network -n CLUSTER_NAMESPACE \ --kubeconfig ADMIN_KUBECONFIG 如為 1.15.0 以上版本的叢集，請執行下列指令： kubectl delete configmap \ $(kubectl get cronjob bm-system-network -o=jsonpath='{.spec.jobTemplate.spec.template.spec.volumes[?(@.name=="inventory-config-volume")]configMap.name}' \ -n CLUSTER_NAMESPACE) \ -n CLUSTER_NAMESPACE \ --kubeconfig ADMIN_KUBECONFIG kubectl delete healthchecks.baremetal.cluster.gke.io \ bm-system-network -n CLUSTER_NAMESPACE \ --kubeconfig ADMIN_KUBECONFIG
網路	1.14、1.15、1.16.0-1.16.2	如果裝置名稱含有半形句號，GDC 網路閘道就無法套用設定 如果網路裝置的名稱包含半形句號 (.)，例如 bond0.2，當 Network Gateway for GDC 執行 sysctl 進行變更時，會將半形句號視為目錄中的路徑。當 GDC 的網路閘道檢查是否已啟用重複位址偵測 (DAD) 時，檢查可能會失敗，因此不會進行協調。 叢集版本之間的行為有所不同： 1.14 和 1.15：只有在使用 IPv6 浮動 IP 位址時，才會發生這個錯誤。如果您未使用 IPv6 浮動 IP 位址，裝置名稱含有半形句號時，就不會遇到這個問題。 1.16.0 - 1.16.2：如果裝置名稱含有半形句號，就會發生這個錯誤。 解決方法： 將叢集升級至 1.16.3 以上版本。 在升級叢集前，請先移除裝置名稱中的半形句號 (.)，做為暫時的解決方法。
升級與更新、網路、安全性	1.16.0	停用 seccomp 時，升級至 1.16.0 版會失敗 如果叢集已停用 seccomp (spec.clusterSecurity.enableSeccomp 設為 false)，則升級至 1.16.0 版會失敗。 Google Distributed Cloud 1.16 版使用 Kubernetes 1.27 版。 在 Kubernetes 1.27.0 以上版本中，設定 seccomp 設定檔的功能已正式發布，不再使用功能閘道。 如果叢集設定中停用了 seccomp，這項 Kubernetes 變更會導致升級至 1.16.0 版失敗。這個問題在 1.16.1 以上版本的叢集中已修正。如果 cluster.spec.clusterSecurity.enableSeccomp 欄位設為 false，您可以升級至 1.16.1 以上版本。 如果叢集未設定 spec.clusterSecurity.enableSeccomp 或設為 true，則不受影響。
安裝、操作	1.11、1.12、1.13、1.14、1.15.0-1.15.5、1.16.0-1.16.1	重新啟動後，如果已掛接 /var/lib/containerd，containerd 中繼資料可能會損毀 如果您選擇掛接 /var/lib/containerd，重新啟動後，containerd 中繼資料可能會損毀。中繼資料損毀可能會導致 Pod 失敗，包括系統關鍵 Pod。 如要確認這個問題是否會影響您，請查看是否為 /var/lib/containerd/ 定義選用掛接點，且掛接選項中是否包含 nofail。/etc/fstab 解決方法： 移除 /etc/fstab 中的 nofail 掛接選項，或將叢集升級至 1.15.6 以上版本。
作業	1.13、1.14、1.15、1.16、1.28	清除叢集中過時的 Pod 您可能會看到 Deployment (ReplicaSet) 管理的 Pod 處於 Failed 狀態，且狀態為 TaintToleration。這些 Pod 不會使用叢集資源，但應刪除。 您可以使用下列 kubectl 指令，列出可清除的 Pod： kubectl get pods –A | grep TaintToleration 以下輸出範例顯示狀態為 TaintToleration 的 Pod： kube-system stackdriver-metadata-agent-[...] 0/1 TaintToleration 0 解決方法： 針對出現上述徵兆的每個 Pod，檢查該 Pod 所屬的 ReplicaSet。如果 ReplicaSet 滿足條件，即可刪除 Pod： 取得管理 Pod 的 ReplicaSet，並找出 ownerRef.Kind 值： kubectl get pod POD_NAME -n NAMESPACE -o yaml 取得 ReplicaSet，並確認 status.replicas 與 spec.replicas 相同： kubectl get replicaset REPLICA_NAME -n NAMESPACE -o yaml 如果名稱相符，請刪除 Pod： kubectl delete pod POD_NAME -n NAMESPACE.
升級	1.16.0	升級至 1.16.0 版時，etcd 事件可能會停滯 將現有叢集升級至 1.16.0 版時，與 etcd 事件相關的 Pod 故障可能會導致作業停滯。具體來說，升級節點工作會在 TASK [etcd_events_install : Run etcdevents] 步驟失敗。 如果受到這個問題影響，您會看到類似下列的 Pod 失敗訊息： kube-apiserver Pod 無法啟動，並顯示下列錯誤： connection error: desc = "transport: Error while dialing dial tcp 127.0.0.1:2382: connect: connection refused" etcd-events Pod 無法啟動，並顯示下列錯誤： Error: error syncing endpoints with etcd: context deadline exceeded 解決方法： 如果無法將叢集升級至含有修正程式的版本，請使用下列暫時解決方法來解決錯誤： 使用 SSH 存取發生錯誤的控制層節點。 編輯 etcd-events 資訊清單檔案 /etc/kubernetes/manifests/etcd-events.yaml， 並移除 initial-cluster-state=existing 標記。 套用資訊清單。 升級作業應該會繼續。
網路	1.15.0-1.15.2	無法辨識 CoreDNS orderPolicy OrderPolicy 不會被視為參數，也不會使用。Google Distributed Cloud 一律會使用 Random。 發生這個問題的原因是 CoreDNS 範本未更新，導致系統忽略 orderPolicy。 解決方法： 更新 CoreDNS 範本並套用修正程式。這項修正會持續生效，直到升級為止。 編輯現有範本： kubectl edit cm -n kube-system coredns-template 將範本內容替換成以下內容： coredns-template: |- .:53 { errors health { lameduck 5s } ready kubernetes cluster.local in-addr.arpa ip6.arpa { pods insecure fallthrough in-addr.arpa ip6.arpa } {{- if .PrivateGoogleAccess }} import zones/private.Corefile {{- end }} {{- if .RestrictedGoogleAccess }} import zones/restricted.Corefile {{- end }} prometheus :9153 forward . {{ .UpstreamNameservers }} { max_concurrent 1000 {{- if ne .OrderPolicy "" }} policy {{ .OrderPolicy }} {{- end }} } cache 30 {{- if .DefaultDomainQueryLogging }} log {{- end }} loop reload loadbalance }{{ range $i, $stubdomain := .StubDomains }} {{ $stubdomain.Domain }}:53 { errors {{- if $stubdomain.QueryLogging }} log {{- end }} cache 30 forward . {{ $stubdomain.Nameservers }} { max_concurrent 1000 {{- if ne $.OrderPolicy "" }} policy {{ $.OrderPolicy }} {{- end }} } } {{- end }}
網路、作業	1.10、1.11、1.12、1.13、1.14	由於缺少優先順序類別，GDC 元件的網路閘道遭到逐出或處於待處理狀態 kube-system 中的網路閘道 Pod 可能會顯示 Pending 或 Evicted 狀態，如下列簡化範例輸出內容所示： $ kubectl -n kube-system get pods | grep ang-node ang-node-bjkkc 2/2 Running 0 5d2h ang-node-mw8cq 0/2 Evicted 0 6m5s ang-node-zsmq7 0/2 Pending 0 7h 這些錯誤表示發生 Pod 逐出事件，或因節點資源不足而無法排定 Pod。由於 GDC Pod 的網路閘道沒有 PriorityClass，因此與其他工作負載的預設優先順序相同。如果節點資源受限，網路閘道 Pod 可能會遭到撤銷。這項行為對 ang-node DaemonSet 來說特別糟糕，因為這些 Pod 必須排程在特定節點上，且無法遷移。 解決方法： 升級至 1.15 以上版本。 如要短期解決問題，可以手動將 PriorityClass 指派給 GDC 元件的網路閘道。在協調程序期間 (例如叢集升級期間)，Google Distributed Cloud 控制器會覆寫這些手動變更。 將 system-cluster-critical PriorityClass 指派給 ang-controller-manager 和 autoscaler 叢集控制器 Deployment。 將 system-node-critical PriorityClass 指派給 ang-daemon 節點 DaemonSet。
安裝、升級及更新	1.15.0、1.15.1、1.15.2	叢集名稱長度導致叢集建立和升級失敗 如果叢集名稱超過 48 個字元 (版本 1.15.0) 或 45 個字元 (版本 1.15.1 或 1.15.2)，則建立版本 1.15.0、1.15.1 或 1.15.2 的叢集，或是將叢集升級至版本 1.15.0、1.15.1 或 1.15.2 時，就會失敗。在叢集建立和升級作業期間，Google Distributed Cloud 會建立健康狀態檢查資源，名稱包含叢集名稱和版本： 如果是 1.15.0 版叢集，健康狀態檢查資源名稱為 CLUSTER_NAME-add-ons-CLUSTER_VER。 如果是 1.15.1 或 1.15.2 版叢集，健康狀態檢查資源名稱為 CLUSTER_NAME-kubernetes-CLUSTER_VER。 如果叢集名稱過長，健康狀態檢查資源名稱會超過Kubernetes 標籤名稱的 63 個字元長度限制，導致無法建立健康狀態檢查資源。如果健康狀態檢查未通過，叢集作業就會失敗。 如要確認是否受到這個問題影響，請使用 kubectl describe 檢查失敗的資源： kubectl describe healthchecks.baremetal.cluster.gke.io \ HEALTHCHECK_CR_NAME -n CLUSTER_NAMESPACE \ --kubeconfig ADMIN_KUBECONFIG 如果這個問題影響到您，回應會包含類似以下的警告： ReconcileError ... Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning ReconcileError 77s (x15 over 2m39s) healthcheck-controller Reconcile error, retrying: 1 error occurred: * failed to create job for health check db-uat-mfd7-fic-hybrid-cloud-uk-wdc-cluster-02-kubernetes-1.15.1: Job.batch "bm-system-db-uat-mfd7-fic-hybrid-cloud-u24d5f180362cffa4a743" is invalid: [metadata.labels: Invalid value: "db-uat-mfd7-fic-hybrid-cloud-uk-wdc-cluster-02-kubernetes-1.15.1": must be no more than 63 characters, spec.template.labels: Invalid value: "db-uat-mfd7-fic-hybrid-cloud-uk-wdc-cluster-02-kubernetes-1.15.1": must be no more than 63 characters] 解決方法 如要解除叢集升級或建立作業的封鎖狀態，可以略過健康檢查。使用下列指令修補健康狀態檢查自訂資源，並傳遞狀態：(status: {pass: true}) kubectl patch healthchecks.baremetal.cluster.gke.io \ HEALTHCHECK_CR_NAME -n CLUSTER_NAMESPACE \ --kubeconfig ADMIN_KUBECONFIG --type=merge \ --subresource status --patch 'status: {pass: true}'
升級與更新	1.14、1.15	搭載預先發布版功能的 1.14.0 和 1.14.1 版叢集無法升級至 1.15.x 版 如果 1.14.0 和 1.14.1 版叢集已啟用預先發布功能，就無法順利升級至 1.15.x 版。這適用於預先發布功能，例如建立叢集時不使用 kube-proxy，只要在叢集設定檔中啟用下列註解即可： preview.baremetal.cluster.gke.io/kube-proxy-free: "enable" 如果受到這個問題影響，叢集升級時會出現類似下列內容的錯誤： [2023-06-20 23:37:47+0000] error judging if the cluster is managing itself: error to parse the target cluster: error parsing cluster config: 1 error occurred: Cluster.baremetal.cluster.gke.io "$cluster-name" is invalid: Annotations[preview.baremetal.cluster.gke.io/$preview-feature-name]: Forbidden: preview.baremetal.cluster.gke.io/$preview-feature-name feature isn't supported in 1.15.1 Anthos Bare Metal version 這個問題在 1.14.2 以上版本的叢集中已修正。 解決方法： 如果無法在升級至 1.15.x 版前，將叢集升級至 1.14.2 以上版本，可以使用啟動程序叢集直接升級至 1.15.x 版： bmctl upgrade cluster --use-bootstrap=true
作業	1.15	1.15 版叢集不接受重複的浮動 IP 位址 如果現有 NetworkGatewayGroup 自訂資源已使用 IP 位址，您就無法在包含這些 IP 位址的 spec.floatingIPs 中，透過 GDC 網路閘道建立新的 NetworkGatewayGroup 自訂資源。在裸機叢集 1.15.0 以上版本中，這項規則會由 Webhook 強制執行。如果先前有重複的浮動 IP 位址，不會導致錯誤。Webhook 只會禁止建立含有重複 IP 位址的新 NetworkGatewayGroups 自訂資源。 Webhook 錯誤訊息會指出衝突的 IP 位址，以及已使用該位址的現有自訂資源： IP address exists in other gateway with name default 在進階網路功能 (例如輸出 NAT 閘道) 的初始文件中，並未提醒您避免重複的 IP 位址。一開始，協調器只會辨識名為 NetworkGatewayGroup 的資源。defaultGDC 的網路閘道現在可辨識系統命名空間中的所有 NetworkGatewayGroup 自訂資源。現有的自訂資源會照常運作。NetworkGatewayGroup 解決方法： 只有在建立新的自訂資源時才會發生錯誤。NetworkGatewayGroup 如要解決這項錯誤，請按照下列步驟操作： 使用下列指令列出自訂資源：NetworkGatewayGroups kubectl get NetworkGatewayGroups --kubeconfig ADMIN_KUBECONFIG \ -n kube-system -o yaml 開啟現有的NetworkGatewayGroup自訂資源，並移除所有衝突的浮動 IP 位址 (spec.floatingIPs)： kubectl edit NetworkGatewayGroups --kubeconfig ADMIN_KUBECONFIG \ -n kube-system RESOURCE_NAME 如要套用變更，請關閉並儲存編輯過的自訂資源。
GDC 上的 VM Runtime	1.13.7	使用私人登錄檔的 1.13.7 叢集可能無法啟動 VM 在新的或升級版 1.13.7 叢集上啟用 GDC 的 VM 執行階段時，如果該叢集使用私人登錄檔，連線至節點網路或使用 GPU 的 VM 可能無法正常啟動。這是因為 vm-system 命名空間中的部分系統 Pod 發生映像檔提取錯誤。舉例來說，如果 VM 使用節點網路，部分 Pod 可能會回報下列映像檔提取錯誤： macvtap-4x9zp 0/1 Init:ImagePullBackOff 0 70m 這個問題已在 1.14.0 以上版本的叢集中修正。 解決方法 如果無法立即升級叢集，可以手動提取映像檔。下列指令會為 VM 提取 macvtap CNI 外掛程式映像檔，並推送至私人登錄檔： docker pull \ gcr.io/anthos-baremetal-release/kubevirt/macvtap-cni:v0.5.1-gke.:21 docker tag \ gcr.io/anthos-baremetal-release/kubevirt/macvtap-cni:v0.5.1-gke.:21 \ REG_HOST/anthos-baremetal-release/kubevirt/macvtap-cni:v0.5.1-gke.:21 docker push \ REG_HOST/anthos-baremetal-release/kubevirt/macvtap-cni:v0.5.1-gke.:21 將 REG_HOST 替換為您在本機鏡像的主機網域名稱。
安裝	1.11、1.12	在 kind 叢集中建立叢集時，gke-metric-agent Pod 無法啟動 在 kind 叢集中建立叢集時，gke-metrics-agent Pod 會因映像檔提取錯誤而無法啟動，如下所示： error="failed to pull and unpack image \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": failed to resolve reference \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": pulling from host gcr.io failed with status code [manifests 1.8.3-anthos.2]: 403 Forbidden" 此外，在啟動叢集的 containerd 記錄中，您會看到下列項目： Sep 13 23:54:20 bmctl-control-plane containerd[198]: time="2022-09-13T23:54:20.378172743Z" level=info msg="PullImage \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\" " Sep 13 23:54:21 bmctl-control-plane containerd[198]: time="2022-09-13T23:54:21.057247258Z" level=error msg="PullImage \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\" failed" error="failed to pull and unpack image \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": failed to resolve reference \"gcr.io/gke-on-prem-staging/gke-metrics-agent:1.8.3-anthos.2\": pulling from host gcr.io failed with status code [manifests 1.8.3-anthos.2]: 403 Forbidden" 您會在 Pod 中看到下列「無法提取」錯誤： gcr.io/gke-on-prem-staging/gke-metrics-agent 解決方法 雖然發生錯誤，但叢集建立程序不會遭到封鎖，因為在 Kind 叢集中，gke-metrics-agent Pod 的用途是提高叢集建立成功率，以及用於內部追蹤和監控。因此，您可以忽略這項錯誤。 解決方法 雖然發生錯誤，但叢集建立程序不會遭到封鎖，因為在 Kind 叢集中，gke-metrics-agent Pod 的用途是提高叢集建立成功率，以及用於內部追蹤和監控。因此，您可以忽略這項錯誤。
作業、網路	1.12、1.13、1.14、1.15、1.16、1.28	在 CentOS 或 RHEL 上存取 IPv6 服務端點時，LoadBalancer 節點會當機 存取雙堆疊服務 (同時具有 IPv4 和 IPv6 端點的服務) 並使用 IPv6 端點時，提供服務的 LoadBalancer 節點可能會當機。如果客戶使用 CentOS 或 RHEL 雙堆疊服務，且核心版本早於 kernel-4.18.0-372.46.1.el8_6，就會受到這個問題影響。 如果認為這個問題會影響您，請使用 uname -a 指令檢查 LoadBalancer 節點上的核心版本。 解決方法： 將 LoadBalancer 節點更新至核心版本 kernel-4.18.0-372.46.1.el8_6 以上。在 CentOS 和 RHEL 8.6 以上版本中，這個核心版本預設可用。
網路	1.11、1.12、1.13、1.14.0	節點重新啟動後，連線問題間歇發生 重新啟動節點後，NodePort 或 LoadBalancer 服務可能會發生間歇性連線問題。舉例來說，您可能會遇到間歇性的 TLS 握手或連線重設錯誤。這項問題已在 1.14.1 以上版本的叢集中修正。 如要檢查這個問題是否會影響您，請查看後端 Pod 執行所在節點上受影響服務的 iptables 轉送規則： sudo iptables -L FORWARD 如果 iptables 中的 KUBE-FORWARD 規則出現在 CILIUM_FORWARD 規則之前，您可能受到這個問題影響。以下輸出範例顯示有問題的節點： Chain FORWARD (policy ACCEPT) target prot opt source destination KUBE-FORWARD all -- anywhere anywhere /* kubernetes forwarding rules */ KUBE-SERVICES all -- anywhere anywhere ctstate NEW /* kubernetes service portals */ KUBE-EXTERNAL-SERVICES all -- anywhere anywhere ctstate NEW /* kubernetes externally-visible service portals */ CILIUM_FORWARD all -- anywhere anywhere /* cilium-feeder: CILIUM_FORWARD */ 解決方法： 在設定錯誤的節點上重新啟動 anetd Pod。重新啟動 anetd Pod 後，iptables 中的轉送規則應會正確設定。 以下輸出範例顯示 CILIUM_FORWARD 規則現在已正確設定在 KUBE-FORWARD 規則之前： Chain FORWARD (policy ACCEPT) target prot opt source destination CILIUM_FORWARD all -- anywhere anywhere /* cilium-feeder: CILIUM_FORWARD */ KUBE-FORWARD all -- anywhere anywhere /* kubernetes forwarding rules */ KUBE-SERVICES all -- anywhere anywhere ctstate NEW /* kubernetes service portals */ KUBE-EXTERNAL-SERVICES all -- anywhere anywhere ctstate NEW /* kubernetes externally-visible service portals */
升級與更新	1.9、1.10	預覽功能不會保留原始權限和擁有者資訊 使用 bmctl 1.9.x 預覽 1.9.x 叢集時，系統不會保留原始權限和擁有者資訊。如要確認您是否受到這項功能影響，請使用下列指令解壓縮備份檔案： tar -xzvf BACKUP_FILE 解決方法 確認 metadata.json 是否存在，以及 bmctlVersion 是否為 1.9.x。如果沒有 metadata.json，請升級至 1.10.x 叢集，並使用 bmctl 1.10.x 備份/還原。
升級及建立	1.14.2	clientconfig-operator 處於待處理狀態，且有 CreateContainerConfigError 如果您已升級至或建立 1.14.2 版叢集，並使用 OIDC/LDAP 設定，可能會發現 clientconfig-operator Pod 停滯在待處理狀態。在這個問題中，有兩個 clientconfig-operator Pod，其中一個處於執行狀態，另一個則處於待處理狀態。 這項問題只會影響 1.14.2 版叢集。1.14.0 和 1.14.1 等較舊的叢集版本不受影響。這個問題已在 1.14.3 版和後續所有版本中修正，包括 1.15.0 以上版本。 解決方法： 如要解決這個問題，可以修補 clientconfig-operator 部署作業，加入額外的安全性環境，並確保部署作業已準備就緒。 使用下列指令修補目標叢集中的 clientconfig-operator： kubectl patch deployment clientconfig-operator -n kube-system \ -p '{"spec":{"template":{"spec":{"containers": [{"name":"oidcproxy","securityContext":{"runAsGroup":2038,"runAsUser":2038}}]}}}}' \ --kubeconfig CLUSTER_KUBECONFIG 更改下列內容： CLUSTER_KUBECONFIG：目標叢集的 kubeconfig 檔案路徑。
作業	1.11、1.12、1.13、1.14、1.15	未採用套裝組合負載平衡的叢集無法輪替憑證授權單位 如果叢集沒有隨附的負載平衡功能 (spec.loadBalancer.mode 設為 manual)，bmctl update credentials certificate-authorities rotate 指令可能會沒有回應，並因下列錯誤而失敗：x509: certificate signed by unknown authority。 如果受到這個問題影響，bmctl 指令可能會在停止回應前輸出下列訊息： Signing CA completed in 3/0 control-plane nodes 在本例中，指令最終會失敗。如果叢集有三個控制層，則輪替憑證授權單位記錄可能包含下列項目： [2023-06-14 22:33:17+0000] waiting for all nodes to trust CA bundle OK [2023-06-14 22:41:27+0000] waiting for first round of pod restart to complete OK Signing CA completed in 0/0 control-plane nodes Signing CA completed in 1/0 control-plane nodes Signing CA completed in 2/0 control-plane nodes Signing CA completed in 3/0 control-plane nodes ... Unable to connect to the server: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "kubernetes") 解決方法 如需其他協助，請與 Google 支援團隊聯絡。
安裝、網路	1.11、1.12、1.13、1.14.0-1.14.1	ipam-controller-manager 雙堆疊叢集中的當機迴圈 部署雙重堆疊叢集 (同時具有 IPv4 和 IPv6 位址的叢集) 時，ipam-controller-manager Pod 可能會進入 CrashLoopBackOff 狀態。這項行為會導致節點在 Ready 和 NotReady 狀態之間循環，並可能導致叢集安裝失敗。如果 API 伺服器負載過高，就可能發生這個問題。 如要確認這個問題是否會影響您，請檢查 Pod 是否因 ipam-controller-manager 錯誤而失敗：CrashLoopBackOff kubectl -n kube-system get pods | grep ipam-controller-manager 以下輸出範例顯示處於 CrashLoopBackOff 狀態的 Pod： ipam-controller-manager-h7xb8 0/1 CrashLoopBackOff 3 (19s ago) 2m ipam-controller-manager-vzrrf 0/1 CrashLoopBackOff 3 (19s ago) 2m1s ipam-controller-manager-z8bdw 0/1 CrashLoopBackOff 3 (31s ago) 2m2s 取得處於 NotReady 狀態的節點詳細資料： kubectl describe node <node-name> | grep PodCIDRs 在有這個問題的叢集中，節點不會獲派 PodCIDR，如下列範例輸出內容所示： PodCIDRs: 在運作正常的叢集中，所有節點都應已指派雙堆疊 PodCIDR，如下列範例輸出內容所示： PodCIDRs: 192.168.6.0/24,222:333:444:555:5:4:7:0/120 解決方法： 重新啟動 ipam-controller-manager Pod： kubectl -n kube-system rollout restart ds ipam-controller-manager
作業	1.6、1.7、1.8、1.9、1.10、1.11、1.12、1.13 和 1.14	etcd 監控資源不足 如果叢集執行的 etcd 版本為 3.4.13 以下，可能會發生監控資源閒置和無法運作的情況，進而導致下列問題： Pod 排程中斷 節點無法註冊 kubelet 不會觀察 Pod 變更 這些問題可能會導致叢集無法運作。 這個問題已在 Google Distributed Cloud 1.12.9、1.13.6、1.14.3 和後續版本中修正。這些較新的版本使用 etcd 3.4.21 版。所有先前的 Google Distributed Cloud 版本都會受到這個問題影響。 解決方法 如果無法立即升級，可以減少叢集中的節點數量，降低叢集故障的風險。移除節點，直到 etcd_network_client_grpc_sent_bytes_total 指標低於 300 MBps 為止。 如要在 Metrics Explorer 中查看這項指標，請按照下列步驟操作： 前往 Google Cloud 控制台的 Metrics Explorer： 前往 Metrics Explorer 選取「設定」分頁標籤。 展開「選取指標」，在篩選列中輸入 Kubernetes Container，然後使用子選單選取指標： 在「Active resources」(有效資源) 選單中，選取「Kubernetes Container」(Kubernetes 容器)。 在「使用中的指標類別」選單中，選取「Anthos」。 在「使用中的指標」選單中，選取 etcd_network_client_grpc_sent_bytes_total。 按一下「套用」。
網路	1.11.6、1.12.3	SR-IOV 運算子的 vfio-pci 模式「失敗」狀態 SriovNetworkNodeState 物件的 syncStatus 可以回報已設定節點的「失敗」值。如要查看節點狀態，並判斷問題是否會影響您，請執行下列指令： kubectl -n gke-operators get \ sriovnetworknodestates.sriovnetwork.k8s.cni.cncf.io NODE_NAME \ -o jsonpath='{.status.syncStatus}' 將 NODE_NAME 替換為要檢查的節點名稱。 解決方法： 如果 SriovNetworkNodeState 物件狀態為「失敗」，請將叢集升級至 1.11.7 以上版本或 1.12.4 以上版本。
升級與更新	1.10、1.11、1.12、1.13、1.14.0、1.14.1	升級後，部分工作節點未處於「就緒」狀態 升級完成後，部分工作節點的「Ready」條件可能會設為 false。在節點資源上，您會在「Ready」條件旁看到類似下列範例的錯誤： container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:Network plugin returns error: cni plugin not initialized 登入停滯的機器時，機器上的 CNI 設定會是空白： sudo ls /etc/cni/net.d/ 解決方法 刪除節點的 anetd Pod，即可重新啟動。
升級和更新、安全性	1.10	cert-manager 多次輪替憑證會導致不一致 多次手動或自動輪替憑證後，系統不會以 cert-manager 核發的新憑證更新 Webhook Pod，例如 anthos-cluster-operator。叢集自訂資源的任何更新都會失敗，並導致類似下列的錯誤： Internal error occurred: failed calling webhook "vcluster.kb.io": failed to call webhook: Post "https://webhook-service.kube-system.svc:443/validate-baremetal-cluster-gke-io-v1-cluster?timeout=10s": x509: certificate signed by unknown authority (possibly because of "x509: invalid signature: parent certificate cannot sign this kind of certificate" while trying to verify candidate authority certificate "webhook-service.kube-system.svc") 這個問題可能發生於下列情況： 如果叢集已超過 180 天，且您已手動輪替 cert-manager 簽發的憑證兩次，但從未重新啟動 anthos-cluster-operator。 如果您在超過 90 天的叢集上進行手動cert-manager核發憑證輪替，且從未重新啟動 anthos-cluster-operator。 解決方法 終止 anthos-cluster-operator 即可重新啟動 Pod。
升級與更新	1.14.0	使用者叢集升級期間建立的生命週期控制器部署 Pod 已過時 在 1.14.0 版管理員叢集中，升級使用者叢集時，可能會建立一或多個過時的生命週期控制器部署程式 Pod。這個問題適用於最初建立時版本低於 1.12 的使用者叢集。無意間建立的 Pod 不會阻礙升級作業，但可能處於非預期狀態。建議您移除過時的 Pod。 這個問題已在 1.14.1 版中修正。 解決方法： 如要移除過時的生命週期控制器部署者 Pod，請執行下列步驟： 列出預檢資源： kubectl get preflightchecks --kubeconfig ADMIN_KUBECONFIG -A 輸出如下所示： NAMESPACE NAME PASS AGE cluster-ci-87a021b9dcbb31c ci-87a021b9dcbb31c true 20d cluster-ci-87a021b9dcbb31c ci-87a021b9dcbb31cd6jv6 false 20d 其中 ci-87a021b9dcbb31c 是叢集名稱。 刪除 PASS 欄中的值為 true 或 false 的資源。 舉例來說，如要刪除上述範例輸出內容中的資源，請使用下列指令： kubectl delete preflightchecks ci-87a021b9dcbb31c \ -n cluster-ci-87a021b9dcbb31c \ --kubeconfig ADMIN_KUBECONFIG kubectl delete preflightchecks ci-87a021b9dcbb31cd6jv6 \ -n cluster-ci-87a021b9dcbb31c \ --kubeconfig ADMIN_KUBECONFIG
網路	1.9、1.10、1.11、1.12、1.13、1.14、1.15、1.16、1.28	BGPSession 狀態不斷變更，因為有大量傳入路徑 當外部對等互連通告大量路徑 (約 100 個以上) 時，Google Distributed Cloud 進階網路無法正確管理 BGP 工作階段。如果傳入大量路徑，節點本機 BGP 控制器需要很長時間才能調解 BGP 工作階段，且無法更新狀態。如果沒有狀態更新或健康狀態檢查，系統會因為工作階段過時而將其刪除。 您可能會發現 BGP 工作階段出現下列不當行為，並指出問題： 持續刪除和重新建立 bgpsession。 bgpsession.status.state 永遠不會變成 Established 無法宣傳或重複宣傳並撤銷的路線。 如果連線至 LoadBalancer 服務時發生問題，可能表示 BGP 負載平衡有問題。 如果 Pod 的連線發生問題，可能表示 BGP FlatIP 有問題。 如要判斷 BGP 問題是否是由於遠端對等互連廣告的路由過多所致，請使用下列指令查看相關狀態和輸出內容： 在受影響的叢集上使用 kubectl get bgpsessions。 輸出內容會顯示 bgpsessions，狀態為「Not Established」(未建立)，且最後回報時間會持續計數，直到大約 10 到 12 秒後重設為零。 kubectl get bgpsessions 的輸出內容顯示受影響的工作階段會重複重新建立： kubectl get bgpsessions \ -o jsonpath="{.items[*]['metadata.name', 'metadata.creationTimestamp']}" 記錄檔訊息會指出系統正在刪除過時的 BGP 工作階段： kubectl logs ang-controller-manager-POD_NUMBER 將 POD_NUMBER 替換為叢集中的領導者 Pod。 解決方法： 使用匯出政策，減少或排除從遠端對等互連到叢集通告的路徑數量。 在叢集版本 1.14.2 以上，您也可以使用 AddOnConfiguration 停用處理接收路徑的功能。將 --disable-received-routes 引數新增至 ang-daemon 守護程式集的 bgpd 容器。
網路	1.14、1.15、1.16、1.28	conntrack 表格插入失敗導致應用程式逾時 如果叢集在 Ubuntu OS 上執行，且使用 5.15 以上版本的核心，就可能發生 netfilter 連線追蹤 (conntrack) 表格插入失敗的問題。即使 conntrack 資料表有空間容納新項目，仍可能發生插入失敗的情況。失敗原因為核心 5.15 以上版本有變更，會根據鏈結長度限制表格插入作業。 如要確認是否受到這個問題影響，請使用下列指令檢查核心內連線追蹤系統統計資料： sudo conntrack -S 回應的形式如下所示： cpu=0 found=0 invalid=4 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0 cpu=1 found=0 invalid=0 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0 cpu=2 found=0 invalid=16 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0 cpu=3 found=0 invalid=13 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0 cpu=4 found=0 invalid=9 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0 clash_resolve=0 chaintoolong=0 cpu=5 found=0 invalid=1 insert=0 insert_failed=0 drop=0 early_drop=0 error=519 search_restart=0 clash_resolve=126 chaintoolong=0 ... 如果回應中的 chaintoolong 值為非零數字，表示您受到這個問題影響。 解決方法 短期解決方法是增加 netfiler 雜湊表 (nf_conntrack_buckets) 和 netfilter 連線追蹤表 (nf_conntrack_max) 的大小。在每個叢集節點上使用下列指令，增加資料表的大小： sysctl -w net.netfilter.nf_conntrack_buckets=TABLE_SIZE sysctl -w net.netfilter.nf_conntrack_max=TABLE_SIZE 將 TABLE_SIZE 替換為新的位元組大小。預設的表格大小值為 262144。建議您將值設為節點上核心數的 65,536 倍。舉例來說，如果節點有八個核心，請將表格大小設為 524288。
升級與更新	1.11.3、1.11.4、1.11.5、1.11.6、1.11.7、1.11.8、1.12.4、1.12.5、1.12.6、1.12.7、1.12.8、1.13.4、1.13.5	無法使用 bmctl 還原部分版本的叢集備份 建議您先備份叢集再升級，這樣一來，如果升級失敗，就能還原至先前的版本。bmctl restore cluster 指令發生問題，導致無法還原具有特定版本的叢集備份。這個問題只會發生在升級時，也就是還原舊版備份時。 如果叢集受到影響，bmctl restore cluster 記錄會包含下列錯誤： Error: failed to extract image paths from profile: anthos version VERSION not supported 解決方法： 在修正這個問題前，建議您按照「備份及還原叢集」一文中的指示，手動備份及還原叢集 (如有必要)。
網路	1.10、1.11、1.12、1.13、1.14.0-1.14.2	如果介面上沒有 IP 位址，NetworkGatewayGroup 就會當機 NetworkGatewayGroup 無法為節點建立精靈，因為這些節點沒有 IPv4 和 IPv6 介面。這會導致 BGP LB 和 EgressNAT 等功能失敗。如果您檢查 kube-system 命名空間中失敗的 ang-node Pod 記錄，系統會顯示類似下列範例的錯誤，表示缺少 IPv6 位址： ANGd.Setup Failed to create ANG daemon {"nodeName": "bm-node-1", "error": "creating NDP client failed: ndp: address \"linklocal\" not found on interface \"ens192\""} 在先前的範例中，ens192 介面上沒有 IPv6 位址。如果節點缺少 IPv4 位址，系統也會顯示類似的 ARP 錯誤。 NetworkGatewayGroup 會嘗試建立 ARP 連線和 NDP 連線至連結本機 IP 位址。如果 IP 位址不存在 (ARP 的 IPv4，NDP 的 IPv6)，連線就會失敗，精靈也不會繼續。 這個問題已在 1.14.3 版中修正。 解決方法： 使用 SSH 連線至節點，並在包含節點 IP 的連結中新增 IPv4 或 IPv6 位址。在先前的記錄檔項目中，這個介面為 ens192： ip address add dev INTERFACE scope link ADDRESS 更改下列內容： INTERFACE：節點的介面，例如 ens192。 ADDRESS：要套用至介面的 IP 位址和子網路遮罩。
重設/刪除	1.10、1.11、1.12、1.13.0-1.13.2	移除控制層節點時發生 anthos-cluster-operator 迴圈 當您嘗試從 Cluster.Spec 移除 IP 位址來移除控制層節點時，anthos-cluster-operator 會進入當機迴圈狀態，導致任何其他作業都無法執行。 解決方法： 這個問題已在 1.13.3 和 1.14.0 以上版本中修正。其他版本都會受到影響。升級至已修正問題的版本 如要解決這個問題，請執行下列指令： kubectl label baremetalmachine IP_ADDRESS \ -n CLUSTER_NAMESPACE baremetal.cluster.gke.io/upgrade-apply- 更改下列內容： IP_ADDRESS：處於當機迴圈狀態的節點 IP 位址。 CLUSTER_NAMESPACE：叢集命名空間。
安裝	1.13.1、1.13.2 和 1.13.3	kubeadm join 會因權杖不符而導致大型叢集發生故障 安裝節點數量眾多的叢集時，可能會看到類似下列範例的 kubeadmin join 錯誤訊息： TASK [kubeadm : kubeadm join --config /dev/stdin --ignore-preflight-errors=all] *** fatal: [10.200.0.138]: FAILED! => {"changed": true, "cmd": "kubeadm join --config /dev/stdin --ignore-preflight-errors=all", "delta": "0:05:00.140669", "end": "2022-11-01 21:53:15.195648", "msg": "non-zero return code", "rc": 1, "start": "2022-11-01 21:48:15.054979", "stderr": "W1101 21:48:15.082440 99570 initconfiguration.go:119] Usage of CRI endpoints without URL scheme is deprecated and can cause kubelet errors in the future. Automatically prepending scheme \"unix\" to the \"criSocket\" with value \"/run/containerd/containerd.sock\". Please update your configuration!\nerror execution phase preflight: couldn't validate the identity of the API Server: could not find a JWS signature in the cluster-info ConfigMap for token ID \"yjcik0\"\n To see the stack trace of this error execute with --v=5 or higher", "stderr_lines": ["W1101 21:48:15.082440 99570 initconfiguration.go:119] Usage of CRI endpoints without URL scheme is deprecated and can cause kubelet errors in the future. Automatically prepending scheme \"unix\" to the \"criSocket\" with value \"/run/containerd/containerd.sock\". Please update your configuration!", "error execution phase preflight: couldn't validate the identity of the API Server: could not find a JWS signature in the cluster-info ConfigMap for token ID \"yjcik0\"", "To see the stack trace of this error execute with --v=5 or higher"], "stdout": "[preflight] Running pre-flight checks", "stdout_lines": ["[preflight] Running pre-flight checks"]} 解決方法： Google Distributed Cloud 1.13.4 以上版本已解決這個問題。 如需使用受影響的版本，請先建立節點少於 20 個的叢集，然後在安裝完成後調整叢集大小，新增其他節點。
記錄和監控	1.10、1.11、1.12、1.13.0	邊緣叢集中的 metrics-server CPU 限制偏低 在 Google Distributed Cloud Edge 叢集中，如果 metrics-server 的 CPU 限制過低，可能會導致 metrics-server 經常重新啟動。由於 metrics-server 狀況不佳，水平 Pod 自動調度資源 (HPA) 無法運作。 如果 metrics-server CPU 上限低於 40m，叢集可能會受到影響。如要查看 metrics-server CPU 限制，請查看下列其中一個檔案： 叢集版本 1.x-1.12： kubectl get deployment metrics-server -n kube-system \ -o yaml > metrics-server.yaml 叢集版本 1.13 以上： kubectl get deployment metrics-server -n gke-managed-metrics-server \ -o yaml > metrics-server.yaml 解決方法： 叢集版本 1.13.1 以上已解決這個問題。如要修正這個問題，請升級叢集。 在升級叢集前，短期解決方法是手動增加 metrics-server 的 CPU 限制，如下所示： 縮減 metrics-server-operator： kubectl scale deploy metrics-server-operator --replicas=0 更新設定並提高 CPU 限制： 叢集版本 1.x-1.12： kubectl -n kube-system edit deployment metrics-server 叢集版本 1.13： kubectl -n gke-managed-metrics-server edit deployment metrics-server 移除 --config-dir=/etc/config 行，並提高 CPU 限制，如以下範例所示： [...] - command: - /pod_nanny # - --config-dir=/etc/config # <--- Remove this line - --container=metrics-server - --cpu=50m # <--- Increase CPU, such as to 50m - --extra-cpu=0.5m - --memory=35Mi - --extra-memory=4Mi - --threshold=5 - --deployment=metrics-server - --poll-period=30000 - --estimator=exponential - --scale-down-delay=24h - --minClusterSize=5 - --use-metrics=true [...] 儲存並關閉 metrics-server，即可套用變更。
網路	1.14、1.15、1.16	無法直接透過 NodePort 連線至 hostNetwork Pod 如果後端 Pod 與目標 NodePort 位於相同節點，則無法使用 NodePort 服務連線至已啟用 hostNetwork 的 Pod。如果搭配使用 hostNetwork-ed Pod，LoadBalancer 服務就會受到影響。如果有多個後端，可能會發生偶發性連線失敗。 這個問題是由 eBPF 程式中的錯誤所致。 解決方法： 使用 Nodeport 服務時，請勿以任何後端 Pod 執行的節點為目標。使用 LoadBalancer Service 時，請確保 hostNetwork Pod 不會在 LoadBalancer 節點上執行。
升級與更新	1.12.3、1.13.0	1.13.0 管理員叢集無法管理 1.12.3 使用者叢集 執行 1.13.0 版的管理員叢集無法管理執行 1.12.3 版的使用者叢集。對 1.12.3 版使用者叢集執行的作業會失敗。 解決方法： 將管理員叢集升級至 1.13.1 版，或將使用者叢集升級至與管理員叢集相同的版本。
升級與更新	1.12	如果管理員叢集含有工作站節點集區，就無法升級至 1.13.x 1.13.0 以上版本的管理員叢集不得包含工作站節點集區。 如果管理員叢集含有工作站節點集區，則無法升級至 1.13.0 以上版本。如果管理員叢集升級作業停滯，您可以檢查 bmctl-workspace 資料夾內的 upgrade-cluster.log 檔案，確認工作站節點集區是否為原因： Operation failed, retrying with backoff. Cause: error creating "baremetal.cluster.gke.io/v1, Kind=NodePool" cluster-test-cluster-2023-06-06-140654/np1: admission webhook "vnodepool.kb.io" denied the request: Adding worker nodepool to Admin cluster is disallowed. 解決方法： 升級前，請將所有工作站節點集區移至使用者叢集。如需新增及移除節點集區的操作說明，請參閱管理叢集中的節點集區。
升級與更新	1.10、1.11、1.12、1.13、1.14、1.15、1.16、1.28	使用 kubectl apply 更新資源時發生錯誤 如果您使用 kubectl apply 更新現有資源 (例如 ClientConfig 或 Stackdriver 自訂資源)，控制器可能會傳回錯誤，或還原您的輸入內容和預計變更。 舉例來說，您可能會先取得資源，然後套用更新版本，嘗試編輯 Stackdriver 自訂資源，如下所示： 取得現有的 YAML 定義： kubectl get stackdriver -n kube-system stackdriver \ -o yaml > stackdriver.yaml 在 YAML 檔案中啟用功能或更新設定。 重新套用更新後的 YAML 檔案： kubectl apply -f stackdriver.yaml kubectl apply 的最後一個步驟可能會遇到問題。 解決方法： 請勿使用 kubectl apply 變更現有資源。請改用 kubectl edit 或 kubectl patch，如以下範例所示： 編輯 Stackdriver 自訂資源： kubectl edit stackdriver -n kube-system stackdriver 在 YAML 檔案中啟用功能或更新設定。 儲存並結束編輯器 使用 kubectl patch 的替代做法： 取得現有的 YAML 定義： kubectl get stackdriver -n kube-system stackdriver \ -o yaml > stackdriver.yaml 在 YAML 檔案中啟用功能或更新設定。 重新套用更新後的 YAML 檔案： kubectl patch stackdriver stackdriver --type merge \ -n kube-system --patch-file stackdriver.yaml
記錄和監控	1.12、1.13、1.14、1.15、1.16	後續記錄區塊損毀，導致 stackdriver-log-forwarder 重複當機 如果 stackdriver-log-forwarder 嘗試處理損毀的待處理項目區塊，就會進入無限迴圈。以下範例錯誤會顯示在容器記錄中： [2022/09/16 02:05:01] [error] [storage] format check failed: tail.1/1-1659339894.252926599.flb [2022/09/16 02:05:01] [error] [engine] could not segregate backlog chunks 發生這類當機迴圈時，您無法在 Cloud Logging 中查看記錄。 解決方法： 如要解決這些錯誤，請完成下列步驟： 找出損毀的待處理事項區塊。請查看下列錯誤訊息範例： [2022/09/16 02:05:01] [error] [storage] format check failed: tail.1/1-1659339894.252926599.flb [2022/09/16 02:05:01] [error] [engine] could not segregate backlog chunks 在本範例中，儲存在 var/log/fluent-bit-buffers/tail.1/ 中的 tail.1/1-1659339894.252926599.flb 檔案有問題。請務必移除所有格式檢查失敗的 *.flb 檔案。 結束 stackdriver-log-forwarder 的執行中 Pod： kubectl --kubeconfig KUBECONFIG -n kube-system \ patch daemonset stackdriver-log-forwarder \ -p '{"spec": {"template": {"spec": {"nodeSelector": {"non-existing": "true"}}}}}' 將 KUBECONFIG 替換為使用者叢集 kubeconfig 檔案的路徑。 確認 stackdriver-log-forwarder Pod 已刪除，再繼續下一個步驟。 使用 SSH 連線至執行 stackdriver-log-forwarder 的節點。 在節點上，刪除 var/log/fluent-bit-buffers/tail.1/ 中所有已損毀的 *.flb 檔案。 如果損毀的檔案過多，且您想套用指令碼來清除所有待處理的區塊，請使用下列指令碼： 部署 DaemonSet，清除緩衝區中的所有髒資料： fluent-bit kubectl --kubeconfig KUBECONFIG -n kube-system apply -f - << EOF apiVersion: apps/v1 kind: DaemonSet metadata: name: fluent-bit-cleanup namespace: kube-system spec: selector: matchLabels: app: fluent-bit-cleanup template: metadata: labels: app: fluent-bit-cleanup spec: containers: - name: fluent-bit-cleanup image: debian:10-slim command: ["bash", "-c"] args: - | rm -rf /var/log/fluent-bit-buffers/ echo "Fluent Bit local buffer is cleaned up." sleep 3600 volumeMounts: - name: varlog mountPath: /var/log securityContext: privileged: true tolerations: - key: "CriticalAddonsOnly" operator: "Exists" - key: node-role.kubernetes.io/master effect: NoSchedule - key: node-role.gke.io/observability effect: NoSchedule volumes: - name: varlog hostPath: path: /var/log EOF 確認 DaemonSet 已清除所有節點。下列兩項指令的輸出內容應等於叢集中的節點數： kubectl --kubeconfig KUBECONFIG logs \ -n kube-system -l app=fluent-bit-cleanup | grep "cleaned up" | wc -l kubectl --kubeconfig KUBECONFIG \ -n kube-system get pods -l app=fluent-bit-cleanup --no-headers | wc -l 刪除清理作業 DaemonSet： kubectl --kubeconfig KUBECONFIG -n kube-system delete ds \ fluent-bit-cleanup 重新啟動 stackdriver-log-forwarder Pod： kubectl --kubeconfig KUBECONFIG \ -n kube-system patch daemonset stackdriver-log-forwarder --type json \ -p='[{"op": "remove", "path": "/spec/template/spec/nodeSelector/non-existing"}]'
網路，GDC 上的 VM 執行階段	1.14.0	在叢集上重新啟動 Dataplane V2 (anetd) 可能會導致現有 VM 無法附加至非 Pod 網路 在多 NIC 叢集上，重新啟動 Dataplane V2 (anetd) 可能會導致虛擬機器無法附加至網路。在 anetd Pod 記錄中，可能會看到類似下列的錯誤： could not find an allocator to allocate the IP of the multi-nic endpoint 解決方法： 如要快速解決問題，可以重新啟動 VM。為避免問題再次發生，請將叢集升級至 1.14.1 以上版本。
作業	1.13、1.14.0、1.14.1	gke-metrics-agent 的 Edge 設定檔叢集沒有記憶體限制 視叢集的工作負載而定，gke-metrics-agent 可能會使用超過 4608 MiB 的記憶體。這個問題只會影響裸機適用的 Google Distributed Cloud Edge 設定檔叢集。預設設定檔叢集不受影響。 解決方法： 將叢集升級至 1.14.2 以上版本。
安裝	1.12、1.13	競爭狀況可能導致叢集建立失敗 使用 kubectl 建立叢集時，由於競爭條件，預檢可能永遠不會完成。因此在某些情況下，叢集建立作業可能會失敗。 前置檢查調解程式會建立 SecretForwarder，將預設 ssh-key 密鑰複製到目標命名空間。通常預檢會利用擁有者參照，並在 SecretForwarder 完成後進行比對。不過，在極少數情況下，SecretForwarder 的擁有者參照可能會失去預檢的參照，導致預檢卡住。因此叢集建立作業會失敗。如要繼續進行控制器主導的飛行前檢查，請刪除 cluster-operator Pod 或飛行前檢查資源。刪除前置檢查資源時，系統會建立另一個資源，並繼續進行協調。或者，您可以將現有叢集 (以舊版建立) 升級至修正版本。
網路	1.9、1.10、1.11、1.12、1.13、1.14、1.15	使用 whereabouts 外掛程式搭配多 NIC 功能時，系統不會釋出預留 IP 位址 在多重 NIC 功能中，如果您使用 CNI whereabouts 外掛程式，並使用 CNI DEL 作業刪除 Pod 的網路介面，部分保留的 IP 位址可能無法正確釋出。CNI DEL 作業中斷時，就會發生這種情況。 如要驗證 Pod 未使用的 IP 位址預留項目，請執行下列指令： kubectl get ippools -A --kubeconfig KUBECONFIG_PATH 解決方法： 手動刪除未使用的 IP 位址 (ippools)。
安裝	1.10、1.11.0、1.11.1、1.11.2	節點問題偵測工具在 1.10.4 使用者叢集中失敗 如果 1.11.0、1.11.1 或 1.11.2 版管理員叢集管理 1.10.x 版使用者叢集，節點問題偵測器可能會在 1.10.x 版使用者叢集中失敗。如果節點問題偵測器失敗，記錄檔會更新為下列錯誤訊息： Error - NPD not supported for anthos baremetal version 1.10.4: anthos version 1.10.4 not supported. 解決方法 將管理員叢集升級至 1.11.3，即可解決問題。
作業	1.14	1.14 島嶼模式 IPv4 叢集節點的 Pod CIDR 遮罩大小為 24 在 1.14 版中，系統不會將 maxPodsPerNode 設定納入島嶼模式叢集考量，因此節點會指派 24 個 Pod CIDR 遮罩大小 (256 個 IP 位址)。這可能會導致叢集比預期更早用盡 Pod IP 位址。舉例來說，如果叢集的 Pod CIDR 遮罩大小為 22，則每個節點都會獲派 Pod CIDR 遮罩 24，且叢集最多只能支援 4 個節點。如果 maxPodsPerNode 設為 129 以上，且每個節點的 Pod CIDR 沒有足夠的額外負荷，叢集也可能在 Pod 變動率高的期間發生網路不穩定的情況。 這個問題只會影響使用 maxPodsPerNode 範圍外 (65 到 128) 的島嶼模式 IPv4 叢集。 如果叢集受到影響，當您將新節點新增至叢集，但沒有可用的 podCIDR 時，anetd Pod 會回報下列錯誤： error="required IPv4 PodCIDR not available" 解決方法 請按照下列步驟解決問題： 升級至 1.14.1 以上版本。 移除工作節點，然後重新加入。 移除控制層節點，然後重新新增節點，最好一次移除一個節點，以免叢集停機。
升級與更新	1.14.0、1.14.1	叢集升級復原失敗 1.14.0 或 1.14.1 版叢集可能無法復原升級。 如果您將叢集從 1.14.0 升級至 1.14.1，然後嘗試使用 bmctl restore cluster 指令回溯至 1.14.0，系統可能會傳回類似下列範例的錯誤： I0119 22:11:49.705596 107905 client.go:48] Operation failed, retrying with backoff. Cause: error updating "baremetal.cluster.gke.io/v1, Kind=HealthCheck" cluster-user-ci-f3a04dc1b0d2ac8/user-ci-f3a04dc1b0d2ac8-network: admission webhook "vhealthcheck.kb.io" denied the request: HealthCheck.baremetal.cluster.gke.io "user-ci-f3a04dc1b0d2ac8-network" is invalid: Spec: Invalid value: v1.HealthCheckSpec{ClusterName:(*string)(0xc0003096e0), AnthosBareMetalVersion:(*string)(0xc000309690), Type:(*v1.CheckType)(0xc000309710), NodePoolNames:[]string(nil), NodeAddresses:[]string(nil), ConfigYAML:(*string)(nil), CheckImageVersion:(*string)(nil), IntervalInSeconds:(*int64)(0xc0015c29f8)}: Field is immutable 解決方法： 刪除叢集命名空間下的所有 healthchecks.baremetal.cluster.gke.io 資源，然後重新執行 bmctl restore cluster 指令： 列出所有healthchecks.baremetal.cluster.gke.io資源： kubectl get healthchecks.baremetal.cluster.gke.io \ --namespace=CLUSTER_NAMESPACE \ --kubeconfig=ADMIN_KUBECONFIG 更改下列內容： CLUSTER_NAMESPACE：叢集的命名空間。 ADMIN_KUBECONFIG：管理員叢集 kubeconfig 檔案的路徑。 刪除上一個步驟列出的所有 healthchecks.baremetal.cluster.gke.io 資源： kubectl delete healthchecks.baremetal.cluster.gke.io \ HEALTHCHECK_RESOURCE_NAME \ --namespace=CLUSTER_NAMESPACE \ --kubeconfig=ADMIN_KUBECONFIG 將 HEALTHCHECK_RESOURCE_NAME 替換為健康狀態檢查資源的名稱。 重新執行 bmctl restore cluster 指令。
網路	1.12.0	服務外部 IP 位址在扁平模式中無法運作 在 flatIPv4 設為 true 的叢集中，LoadBalancer 類型的服務無法透過外部 IP 位址存取。 這個問題已在 1.12.1 版中修正。 解決方法： 在 cilium-config ConfigMap 中，將 enable-415 設為 "true"，然後重新啟動 anetd Pod。
升級與更新	1.13.0、1.14	從 1.13.0 到 1.14.x 的直接升級作業永遠不會完成 當您嘗試使用 bmctl 1.14.0 和 --use-bootstrap=false 標記，從 1.13.0 就地升級至 1.14.x 時，升級作業永遠不會完成。 preflight-check 運算符發生錯誤，導致叢集永遠不會排定必要檢查作業，因此預檢永遠不會完成。 解決方法： 請先升級至 1.13.1，再升級至 1.14.x。從 1.13.0 就地升級至 1.13.1 應該可行。或者，您也可以從 1.13.0 升級至 1.14.x，不必使用 --use-bootstrap=false 旗標。
升級和更新、安全性	1.13 和 1.14	升級至 1.14.0 的叢集會失去主節點汙點 控制層節點需要其中一個特定汙點，才能防止工作負載 Pod 排定在這些節點上。將 1.13 版叢集升級至 1.14.0 版時，控制層節點會失去下列必要汙點： node-role.kubernetes.io/master:NoSchedule node-role.kubernetes.io/master:PreferNoSchedule 注意：獨立型叢集等自行管理的叢集，預設會使用 PreferNoSchedule 汙點。 這個問題不會導致升級失敗，但本來不該在控制層節點上執行的 Pod 可能會開始執行。這些工作負載 Pod 可能會讓控制層節點不堪負荷，導致叢集不穩定。 判斷是否受到影響 找出控制層節點，使用下列指令： kubectl get node -l 'node-role.kubernetes.io/control-plane' \ -o name --kubeconfig KUBECONFIG_PATH 如要查看節點上的汙染清單，請使用下列指令： kubectl describe node NODE_NAME \ --kubeconfig KUBECONFIG_PATH 如果未列出任一必要汙點，則表示您受到影響。 解決方法 請針對受影響的 1.14.0 版叢集，對每個控制層節點執行下列步驟，以還原正常功能。這些步驟適用於 node-role.kubernetes.io/master:NoSchedule 汙染和相關 Pod。如果您打算讓控制層節點使用 PreferNoSchedule Taint，請視情況調整步驟。 查看解決方法步驟 套用缺少的汙染： kubectl taint nodes NODE_NAME \ node-role.kubernetes.io/master:NoSchedule \ -–kubeconfig KUBECONFIG_PATH 找出沒有 node-role.kubernetes.io/master:NoSchedule 容許度的 Pod： kubectl get pods -A --field-selector spec.nodeName="NODE_NAME" \ -o=custom-columns='Name:metadata.name,Toleration:spec.tolerations[*].key' \ --kubeconfig KUBECONFIG_PATH | \ grep -v "node-role.kubernetes.io/master" | uniq 刪除沒有 node-role.kubernetes.io/master:NoSchedule 容許度的 Pod： toleration: kubectl delete pod POD_NAME –-kubeconfig KUBECONFIG_PATH
GDC 上的作業和 VM 執行階段	1.11、1.12、1.13、1.14、1.15、1.16、1.28、1.29、1.30、1.31	VM 建立作業間歇性失敗，並顯示上傳錯誤 使用 kubectl virt create vm 指令建立新的虛擬機器 (VM) 時，偶爾會因映像檔上傳失敗而無法建立。這個問題適用於 Linux 和 Windows VM。錯誤示例如下： PVC default/heritage-linux-vm-boot-dv not found DataVolume default/heritage-linux-vm-boot-dv created Waiting for PVC heritage-linux-vm-boot-dv upload pod to be ready... Pod now ready Uploading data to https://10.200.0.51 2.38 MiB / 570.75 MiB [>----------------------------------------------------------------------------------] 0.42% 0s fail to upload image: unexpected return value 500, ... 解決方法 重試 kubectl virt create vm 指令來建立 VM。
升級和更新、記錄和監控	1.11	升級至 1.12 時，系統不會保留 1.11 叢集中的受管理集合元件 代管收集元件是 Managed Service for Prometheus 的一部分。 如果您在 1.11 版叢集的 gmp-system 命名空間中手動部署代管集合元件，升級至 1.12 版時，相關聯的資源不會保留。 從 1.12.0 版叢集開始，gmp-system 命名空間中的 Managed Service for Prometheus 元件和相關自訂資源定義，會由 stackdriver-operator 透過 enableGMPForApplications 欄位管理。enableGMPForApplications 欄位預設為 true，因此如果您在升級至 1.12 版之前，於命名空間中手動部署 Managed Service for Prometheus 元件，stackdriver-operator 會刪除這些資源。 解決方法 如要保留手動管理的集合資源，請按照下列步驟操作： 備份所有現有的 PodMonitoring 自訂資源。 將叢集升級至 1.12 版，並 啟用 Managed Service for Prometheus。 在升級後的叢集上重新部署 PodMonitoring 自訂資源。
升級與更新	1.13	部分使用 Docker 容器執行階段的 1.12 版叢集無法升級至 1.13 版 如果使用 Docker 容器執行階段的 1.12 版叢集缺少下列註解，就無法升級至 1.13 版： baremetal.cluster.gke.io/allow-docker-container-runtime: "true" 如果受到這個問題影響，bmctl 會在 bmctl-workspace 資料夾內的 upgrade-cluster.log 檔案中寫入下列錯誤： Operation failed, retrying with backoff. Cause: error creating "baremetal.cluster.gke.io/v1, Kind=Cluster": admission webhook "vcluster.kb.io" denied the request: Spec.NodeConfig.ContainerRuntime: Forbidden: Starting with Anthos Bare Metal version 1.13 Docker container runtime will not be supported. Before 1.13 please set the containerRuntime to containerd in your cluster resources. Although highly discouraged, you can create a cluster with Docker node pools until 1.13 by passing the flag "--allow-docker-container-runtime" to bmctl create cluster or add the annotation "baremetal.cluster.gke.io/allow-docker- container-runtime: true" to the cluster configuration file. 從 1.11 版升級的 1.12 版 Docker 叢集最有可能發生這種情況，因為升級時不需要註解，即可維護 Docker 容器執行階段。在這種情況下，叢集升級至 1.13 時不會有註解。請注意，從 1.13 版開始，containerd 是唯一允許的容器執行階段。 解決方法： 如果受到這個問題影響，請使用缺少的註解更新叢集資源。您可以在升級執行期間新增註解，也可以在取消升級後重試升級前新增註解。
安裝	1.11	bmctl 在叢集建立完成前退出 Google Distributed Cloud 1.11.0 版可能無法建立叢集 (這個問題已在 Google Distributed Cloud 1.11.1 版中修正)。在某些情況下，bmctl create cluster 指令會提早結束，並將類似下列內容的錯誤寫入記錄檔： Error creating cluster: error waiting for applied resources: provider cluster-api watching namespace USER_CLUSTER_NAME not found in the target cluster 解決方法 失敗的作業會產生構件，但叢集無法運作。如果受到這個問題影響，請按照下列步驟清除構件並建立叢集： 查看解決方法步驟 如要刪除叢集構件並重設節點機器，請執行下列指令： bmctl reset -c USER_CLUSTER_NAME 如要啟動叢集建立作業，請執行下列指令： bmctl create cluster -c USER_CLUSTER_NAME \ --keep-bootstrap-cluster 如果這個指令失敗，--keep-bootstrap-cluster 旗標就很重要。 如果叢集建立指令成功執行，您可以略過其餘步驟。否則請繼續操作。 執行下列指令，取得啟動程序叢集的版本： kubectl get cluster USER_CLUSTER_NAME \ -n USER_CLUSTER_NAMESPACE \ --kubeconfig bmctl-workspace/.kindkubeconfig \ -o=jsonpath='{.status.anthosBareMetalVersion} 輸出內容應為 1.11.0。如果輸出內容不是 1.11.0，請稍候一兩分鐘後再試一次。 如要手動將資源從啟動程序叢集移至目標叢集，請執行下列指令： bmctl move --from-kubeconfig bmctl-workspace/.kindkubeconfig \ --to-kubeconfig \ bmctl-workspace/USER_CLUSTER_NAME/USER_CLUSTER_NAME-kubeconfig \ -n USER_CLUSTER_NAMESPACE 如要刪除啟動程序叢集，請執行下列指令： bmctl reset bootstrap
安裝作業：GDC 上的 VM Runtime	1.11、1.12	安裝報告 VM 執行階段協調錯誤 叢集建立作業可能會回報類似下列的錯誤： I0423 01:17:20.895640 3935589 logs.go:82] "msg"="Cluster reconciling:" "message"="Internal error occurred: failed calling webhook \"vvmruntime.kb.io\": failed to call webhook: Post \"https://vmruntime-webhook-service.kube-system.svc:443/validate-vm-cluster-gke-io-v1vmruntime?timeout=10s\": dial tcp 10.95.5.151:443: connect: connection refused" "name"="xxx" "reason"="ReconciliationError" 解決方法 這個錯誤無害，您可以放心忽略。
安裝	1.10、1.11、1.12	使用多重 NIC、containerd 和 HTTPS Proxy 時，叢集建立作業會失敗 如果符合下列條件組合，叢集建立作業就會失敗： 叢集已設定為使用 containerd 做為容器執行階段 (叢集設定檔中的 nodeConfig.containerRuntime 設為 containerd，這是 Google Distributed Cloud 1.13 以上版本的預設值)。 叢集已設定為提供多個網路介面 (多 NIC) 給 Pod (在叢集設定檔中設為 clusterNetwork.multipleNetworkInterfaces true)。 叢集已設定為使用 Proxy (叢集設定檔中指定了 spec.proxy.url)。即使叢集建立失敗，當您嘗試建立叢集時，這項設定也會傳播。您可能會在HTTPS_PROXY環境變數或 containerd 設定 (/etc/systemd/system/containerd.service.d/09-proxy.conf) 中看到這項 Proxy 設定。 解決方法 在所有節點機器上，將服務 CIDR (clusterNetwork.services.cidrBlocks) 附加至 NO_PROXY 環境變數。
安裝	1.10、1.11、1.12	系統的 umask 設定受限，導致失敗 Google Distributed Cloud 1.10.0 版導入了無根控制層功能，可將所有控制層元件以非根使用者身分執行。以非根使用者身分執行所有元件，可能會導致系統安裝或升級失敗，因為系統的 0077 設定較為嚴格。umask 解決方法 重設控制層節點，並在所有控制層機器上將 umask 設定變更為 0022。更新機器後，請重試安裝。 或者，您也可以變更控制層機器上 /etc/kubernetes 的目錄和檔案權限，然後繼續安裝或升級。 將 /etc/kubernetes 和所有子目錄設為可供全域讀取：chmod o+rx。 將目錄 (遞迴) 下 root 使用者擁有的所有檔案設為可供全世界讀取 (chmod o+r)。由於私密金鑰檔案 (.key) 已使用正確的擁有權和權限建立，因此請將這些檔案排除在變更範圍之外。/etc/kubernetes 讓 /usr/local/etc/haproxy/haproxy.cfg 世界可讀取。 設為可供全世界讀取。/usr/local/etc/bgpadvertiser/bgpadvertiser-cfg.yaml
安裝	1.10、1.11、1.12、1.13	控制組第 2 版不相容 Google Distributed Cloud 1.13 版和更早版本不支援 控制群組 v2 (cgroup v2)。不過，1.14 版支援 cgroup v2，這項功能目前為預先發布版 。如果存在 /sys/fs/cgroup/cgroup.controllers，表示系統使用 cgroup v2。 解決方法 如果系統使用 cgroup v2，請將叢集升級至 1.14 版。
安裝	1.10、1.11、1.12、1.13、1.14、1.15、1.16、1.28、1.29	預檢和服務帳戶憑證 如果是由管理員或混合式叢集觸發的安裝作業 (換句話說，不是使用 bmctl 建立的叢集，例如使用者叢集)，前置檢查不會驗證 Google Cloud 服務帳戶 Google Cloud 憑證或相關聯的權限。
安裝	1.10、1.11、1.12、1.13、1.14、1.15、1.16、1.28、1.29、1.30	在 vSphere 上安裝 在 vSphere VM 上安裝裸機叢集時，您必須將 tx-udp_tnl-segmentation 和 tx-udp_tnl-csum-segmentation 旗標設為關閉。這些旗標與 vSphere 驅動程式 VMXNET3 完成的硬體區隔卸載作業有關，且無法與裸機叢集的 GENEVE 管道搭配運作。 解決方法 在每個節點上執行下列指令，檢查這些旗標的目前值： ethtool -k NET_INTFC | grep segm 將 NET_INTFC 替換為與節點 IP 位址相關聯的網路介面。 回應應包含類似下列的項目： ... tx-udp_tnl-segmentation: on tx-udp_tnl-csum-segmentation: on ... 在 RHEL 8.4 中，ethtool 有時會顯示這些標記已關閉，但實際並非如此。如要明確將這些旗標設為關閉，請使用下列指令將旗標切換為開啟，然後再切換為關閉： ethtool -K ens192 tx-udp_tnl-segmentation on ethtool -K ens192 \ tx-udp_tnl-csum-segmentation on ethtool -K ens192 tx-udp_tnl-segmentation off ethtool -K ens192 \ tx-udp_tnl-csum-segmentation off 這項標記變更不會在重新啟動後保留。設定開機指令碼，在系統啟動時明確設定這些旗標。
升級與更新	1.10	bmctl 無法建立、更新或重設較低版本的使用者叢集 無論管理員叢集版本為何，bmctl CLI 都無法建立、更新或重設子版本較低的使用者叢集。舉例來說，即使管理員叢集也採用 1.N.X 版本，您也無法使用 bmctl 搭配 1.N.X 版本，重設 1.N-1.Y 版本的使用者叢集。 如果受到這個問題影響，使用 bmctl 時應該會看到類似下列內容的記錄： [2022-06-02 05:36:03-0500] error judging if the cluster is managing itself: error to parse the target cluster: error parsing cluster config: 1 error occurred: * cluster version 1.8.1 isn't supported in bmctl version 1.9.5, only cluster version 1.9.5 is supported 解決方法： 使用 kubectl 在管理員叢集中建立、編輯或刪除使用者叢集自訂資源。 升級使用者叢集的功能不受影響。
升級與更新	1.12	升級至 1.12.1 版的叢集可能會停滯 將叢集升級至 1.12.1 版時，有時會因 API 伺服器無法使用而停滯。所有叢集類型和所有支援的作業系統都會受到影響。發生這個問題時，bmctl upgrade cluster 指令可能會在多個時間點失敗，包括在預檢檢查的第二階段。 解決方法 您可以查看升級記錄，判斷是否受到這個問題影響。升級記錄檔預設位於 /baremetal/bmctl-workspace/CLUSTER_NAME/log/upgrade-cluster-TIMESTAMP。 「upgrade-cluster.log」可能包含下列錯誤： Failed to upgrade cluster: preflight checks failed: preflight check failed 電腦記錄可能包含下列錯誤 (重複失敗表示您受到這個問題影響)： FAILED - RETRYING: Query CNI health endpoint (30 retries left). FAILED - RETRYING: Query CNI health endpoint (29 retries left). FAILED - RETRYING: Query CNI health endpoint (28 retries left). ... 重新嘗試將叢集升級至 1.12.1 版前，請務必在每個控制層節點上執行 HAProxy 和 Keepalived。在每個節點上使用 crictl 指令列介面，檢查 haproxy 和 keepalived 容器是否正在執行： docker/crictl ps | grep haproxy docker/crictl ps | grep keepalived 如果節點上未執行 HAProxy 或 Keepalived，請在節點上重新啟動 kubelet： systemctl restart kubelet
升級和更新：GDC 上的 VM 執行階段	1.11、1.12	啟用 GDC 上的 VM Runtime 時，無法將叢集升級至 1.12.0 以上版本 在 1.12.0 版叢集中，與 GDC 上的 VM Runtime 相關的所有資源都會遷移至 vm-system 命名空間，以便更妥善地支援 GDC 上的 VM Runtime 正式版。如果叢集版本為 1.11.x 以下，且已啟用 GDC 上的 VM Runtime，則必須先停用 GDC 上的 VM Runtime，才能升級至 1.12.0 以上版本。如果遇到這個問題，升級作業會回報下列錯誤： Failed to upgrade cluster: cluster isn't upgradable with vmruntime enabled from version 1.11.x to version 1.12.0: please disable VMruntime before upgrade to 1.12.0 and higher version 解決方法 如要在 GDC 上停用 VM Runtime，請按照下列步驟操作： 編輯 VMRuntime 自訂資源： kubectl edit vmruntime 在規格中將 enabled 設為 false： apiVersion: vm.cluster.gke.io/v1 kind: VMRuntime metadata: name: vmruntime spec: enabled: false ... 在編輯器中儲存自訂資源。 叢集升級完成後，請在 GDC 上重新啟用 VM Runtime。 詳情請參閱「在 GDC 上啟用或停用 VM Runtime」。
升級與更新	1.10、1.11、1.12	升級作業停滯在 error during manifests operations 在某些情況下，叢集升級作業無法完成，且 bmctl CLI 會沒有回應。這個問題可能是因為資源更新有誤所致。如要判斷是否受到這個問題影響並加以修正，請檢查 anthos-cluster-operator 記錄檔，並尋找類似下列項目的錯誤： controllers/Cluster "msg"="error during manifests operations" "error"="1 error occurred: ... {RESOURCE_NAME} is invalid: metadata.resourceVersion: Invalid value: 0x0: must be specified for an update 這些項目是資源更新錯誤的徵兆，其中 {RESOURCE_NAME} 是有問題的資源名稱。 解決方法 如果在記錄中發現這些錯誤，請完成下列步驟： 使用 kubectl edit 從記錄訊息中包含的資源移除 kubectl.kubernetes.io/last-applied-configuration 註解。 儲存變更並套用至資源。 再次嘗試升級叢集。
升級與更新	1.10、1.11、1.12	如果叢集的功能使用 GDC 的網路閘道，則無法升級 如果叢集使用輸出 NAT 閘道或使用 BGP 進行套裝組合負載平衡，則無法從 1.10.x 升級至 1.11.x。這兩項功能都使用 GDC 的網路閘道。叢集升級作業停滯在 Waiting for upgrade to complete... 指令列訊息，且 anthos-cluster-operator 記錄的錯誤類似於下列訊息： apply run failed ... MatchExpressions:[]v1.LabelSelectorRequirement(nil)}: field is immutable... 解決方法 注意：下列解決方法會刪除資訊清單，並導致與 BGP 搭配使用的組合式負載平衡器短暫停機 30 到 60 秒。BGP 工作階段會遭到捨棄並重新建立，且 LoadBalancer 服務在這段期間無法使用。當 anthos-cluster-operator 重新安裝資訊清單時，函式就會還原。 如要解除升級封鎖，請對要升級的叢集執行下列指令： kubectl -n kube-system delete deployment \ ang-controller-manager-autoscaler kubectl -n kube-system delete deployment \ ang-controller-manager kubectl -n kube-system delete ds ang-node
升級與更新	1.10、1.11、1.12、1.13、1.14、1.15	bmctl update 不會移除維護作業封鎖 bmctl update 指令無法從叢集資源設定中移除或修改 maintenanceBlocks 區段。 解決方法 如需更多資訊，包括如何將節點從維護模式中移除的操作說明，請參閱「讓節點進入維護模式」。
作業	1.10、1.11、1.12	如果您未使用維護模式程序，節點會取消封鎖 如果您執行 1.12.0 以下版本的叢集 (anthosBareMetalVersion: 1.12.0)，並在節點上手動使用 kubectl cordon，Google Distributed Cloud for bare metal 可能會在您準備就緒前取消節點的 cordon，以協調預期狀態。 解決方法 如果是 1.12.0 以下版本的叢集，請使用維護模式，安全地封鎖及排空節點。 在 1.12.1 版 (anthosBareMetalVersion: 1.12.1) 以上版本中，使用 kubectl cordon 時，Google Distributed Cloud Bare Metal 不會意外取消節點的封鎖狀態。
作業	1.11	使用登錄檔鏡像的第 11 版管理員叢集無法管理第 10 版叢集 如果管理員叢集使用 1.11 版，且使用登錄檔鏡像，就無法管理子版本較低的使用者叢集。這項問題會影響使用者叢集的重設、更新和升級作業。 如要判斷您是否受到這個問題影響，請檢查叢集作業 (例如建立、升級或重設) 的記錄。這些記錄檔預設位於 bmctl-workspace/CLUSTER_NAME/ 資料夾。如果受到這個問題影響，記錄檔會包含下列錯誤訊息： flag provided but not defined: -registry-mirror-host-to-endpoints
作業	1.10、1.11	kubeconfig Secret 已覆寫 在使用者叢集上執行 bmctl check cluster 指令時，系統會以管理員叢集 kubeconfig 覆寫使用者叢集 kubeconfig Secret。覆寫檔案會導致受影響的使用者叢集無法執行標準叢集作業，例如更新和升級。這個問題適用於 1.11.1 以下的叢集版本。 如要判斷使用者叢集是否受到這個問題影響，請執行下列指令： kubectl --kubeconfig ADMIN_KUBECONFIG \ get secret -n USER_CLUSTER_NAMESPACE \ USER_CLUSTER_NAME -kubeconfig \ -o json | jq -r '.data.value' | base64 -d 更改下列內容： ADMIN_KUBECONFIG：管理員叢集 kubeconfig 檔案的路徑。 USER_CLUSTER_NAMESPACE：叢集的命名空間。根據預設，叢集命名空間名稱是叢集名稱，並以 cluster- 為前置字串。舉例來說，如果將叢集命名為 test，預設命名空間就是 cluster-test。 USER_CLUSTER_NAME：要檢查的使用者叢集名稱。 如果輸出內容中的叢集名稱 (請參閱以下範例輸出內容中的 contexts.context.cluster) 是管理員叢集名稱，表示指定的使用者叢集受到影響。 apiVersion: v1 clusters: - cluster: certificate-authority-data:LS0tLS1CRU...UtLS0tLQo= server: https://10.200.0.6:443 name: ci-aed78cdeca81874 contexts: - context: cluster: ci-aed78cdeca81 user: ci-aed78cdeca81-admin name: ci-aed78cdeca81-admin@ci-aed78cdeca81 current-context: ci-aed78cdeca81-admin@ci-aed78cdeca81 kind: Config preferences: {} users: - name: ci-aed78cdeca81-admin user: client-certificate-data: LS0tLS1CRU...UtLS0tLQo= client-key-data: LS0tLS1CRU...0tLS0tCg== 解決方法 請按照下列步驟，為受影響的使用者叢集還原功能 (USER_CLUSTER_NAME)： 找出使用者叢集 kubeconfig 檔案。建立叢集時，裸機專用的 Google Distributed Cloud 會在管理員工作站產生 kubeconfig 檔案。根據預設，該檔案位於 bmctl-workspace/USER_CLUSTER_NAME 目錄中。 確認 kubeconfig 是正確的使用者叢集 kubeconfig： kubectl get nodes \ --kubeconfig PATH_TO_GENERATED_FILE 將 PATH_TO_GENERATED_FILE 替換為使用者叢集 kubeconfig 檔案的路徑，回應會傳回使用者叢集節點的詳細資料。確認叢集的機器名稱正確無誤。 執行下列指令，刪除管理員叢集中的損毀 kubeconfig 檔案： kubectl delete secret \ -n USER_CLUSTER_NAMESPACE \ USER_CLUSTER_NAME-kubeconfig 執行下列指令，將正確的 kubeconfig 密鑰儲存回管理員叢集： kubectl create secret generic \ -n USER_CLUSTER_NAMESPACE \ USER_CLUSTER_NAME-kubeconfig \ --from-file=value=PATH_TO_GENERATED_FILE
作業	1.10、1.11、1.12、1.13、1.14、1.15、1.16、1.28、1.29、1.30	以非超級使用者身分登入並建立快照 如果使用 containerd 做為容器執行階段，以非超級使用者身分執行快照時，/usr/local/bin 必須位於使用者的 PATH 中。否則會失敗並顯示 crictl: command not found 錯誤。 如果未以超級使用者身分登入，請使用 sudo 執行快照指令。sudo PATH 可能與根設定檔不同，且可能不包含 /usr/local/bin。 解決方法 更新 /etc/sudoers 中的 secure_path，加入 /usr/local/bin。或者，在另一個 /bin 目錄中為 crictl 建立符號連結。
記錄和監控	1.10	stackdriver-log-forwarder 有 [parser:cri] invalid time format 則警告記錄 如果容器執行階段介面 (CRI) 剖析器使用不正確的規則運算式剖析時間，stackdriver-log-forwarder Pod 的記錄會包含類似下列的錯誤和警告： [2022/03/04 17:47:54] [error] [parser] time string length is too long [2022/03/04 20:16:43] [ warn] [parser:cri] invalid time format %Y-%m-%dT%H:%M:%S.%L%z for '2022-03-04T20:16:43.680484387Z' 解決方法： 查看解決方法步驟 將叢集升級至 1.11.0 以上版本。 如果無法立即升級叢集，請按照下列步驟更新 CRI 剖析 regex： 如要避免後續變更還原，請縮減 stackdriver-operator： kubectl --kubeconfig KUBECONFIG \ -n kube-system scale deploy \ stackdriver-operator --replicas=0 編輯 stackdriver-log-forwarder-config ConfigMap 中的 Regex 項目： kubectl --kubeconfig KUBECONFIG \ -n kube-system edit configmap \ stackdriver-log-forwarder-config 編輯後的資源應如下所示： [PARSER] # https://rubular.com/r/Vn30bO78GlkvyB Name cri Format regex # The timestamp is described in https://www.rfc-editor.org/rfc/rfc3339#section-5.6 Regex ^(?<time>[0-9]{4}-[0-9]{2}-[0-9]{2}[Tt ][0-9] {2}:[0-9]{2}:[0-9]{2}(?:\.[0-9]+)?(?:[Zz]|[+-][0-9] {2}:[0-9]{2})) (?<stream>stdout|stderr) (?<logtag>[^ ]*) (?<log>.*)$ Time_Key time Time_Format %Y-%m-%dT%H:%M:%S.%L%z Time_Keep off 重新啟動記錄轉送器 Pod： kubectl --kubeconfig KUBECONFIG \ -n kube-system rollout restart daemonset \ stackdriver-log-forwarder
記錄和監控	1.10、1.11、1.12、1.13、1.14、1.15	非預期的監控費用 對於叢集版本 1.10 至 1.15，部分客戶發現「帳單」頁面上的 Metrics volume 費用異常高。只有在符合下列所有情況時，這個問題才會影響您： 已啟用應用程式監控功能 (enableStackdriverForApplications=true) Managed Service for Prometheus 未啟用 (enableGMPForApplications) 應用程式 Pod 具有 prometheus.io/scrap=true 註解 如要確認是否受到這個問題影響，請列出您定義的使用者指標。如果看到不必要的指標費用，表示您遇到這個問題。 解決方法 如果受到這個問題影響，建議您將叢集升級至 1.12 版，並改用新的應用程式監控解決方案 managed-service-for-prometheus，解決這個問題： 使用個別的旗標來控管應用程式記錄檔和應用程式指標的收集作業 隨附的 Google Cloud Managed Service for Prometheus 如果無法升級至 1.12 版，請按照下列步驟操作： 找出有不必要帳單的來源 Pod 和服務： kubectl --kubeconfig KUBECONFIG \ get pods -A -o yaml | grep 'prometheus.io/scrape: "true"' kubectl --kubeconfig KUBECONFIG get \ services -A -o yaml | grep 'prometheus.io/scrape: "true"' 從 Pod 或服務中移除 prometheus.io/scrap=true 註解。
記錄和監控	1.11、1.12、1.13、1.14、1.15、1.16、1.28	對「metrics-server-config」進行的編輯作業不會保留 在極端情況下，高 Pod 密度可能會產生過多的記錄和監控負荷，導致 Metrics Server 停止並重新啟動。您可以編輯 metrics-server-config ConfigMap，分配更多資源來維持 Metrics Server 運作。不過，由於需要進行協調，在叢集更新或升級作業期間，對 metrics-server-config 所做的編輯可能會還原為預設值。指標伺服器不會立即受到影響，但下次重新啟動時，會採用還原的 ConfigMap，再次受到過多負擔的影響。 解決方法 如果是 1.11.x，您可以編寫 ConfigMap 編輯指令碼，並與叢集更新或升級作業一併執行。如要使用 1.12 以上版本，請與支援團隊聯絡。
記錄和監控	1.11、1.12	已淘汰的指標會影響 Cloud Monitoring 資訊主頁 多項 Google Distributed Cloud 軟體專屬指標已淘汰，自 Google Distributed Cloud 1.11 版起，系統將不再收集這些指標的資料。如果您在任何快訊政策中使用這些指標，系統就不會有任何資料來觸發快訊條件。 下表列出已淘汰的個別指標，以及取代這些指標的指標。 已淘汰的指標 更換指標 kube_daemonset_updated_number_scheduled kube_daemonset_status_updated_number_scheduled kube_node_status_allocatable_cpu_cores kube_node_status_allocatable_memory_bytes kube_node_status_allocatable_pods kube_node_status_allocatable kube_node_status_capacity_cpu_cores kube_node_status_capacity_memory_bytes kube_node_status_capacity_pods kube_node_status_capacity 在低於 1.11 的叢集版本中，建議的 Anthos on baremetal node cpu usage exceeds 80 percent (critical) 警報政策定義檔會使用已淘汰的指標。1.11.0 以上版本會更新 node-cpu-usage-high.json JSON 定義檔。 解決方法 請按照下列步驟遷移至替代指標： 在 Google Cloud 控制台中選取「Monitoring」，或按一下下列按鈕： 前往 Monitoring 在導覽窗格中，選取「資訊主頁」，然後刪除「Anthos 叢集節點狀態」資訊主頁。 按一下「範例程式庫」分頁標籤，然後重新安裝「Anthos 叢集節點狀態」資訊主頁。 請按照「建立快訊政策」一文中的操作說明，使用更新後的 node-cpu-usage-high.json 政策定義檔案建立政策。
記錄和監控	1.10、1.11	「stackdriver-log-forwarder」有 CrashloopBackOff 項錯誤 在某些情況下，fluent-bit 記錄代理程式可能會卡住，無法處理損毀的區塊。如果記錄代理程式無法略過損毀的區塊，您可能會發現 stackdriver-log-forwarder 持續當機，並出現 CrashloopBackOff 錯誤。如果遇到這個問題，記錄檔中會有類似下列的項目 [2022/03/09 02:18:44] [engine] caught signal (SIGSEGV) #0 0x5590aa24bdd5 in validate_insert_id() at plugins/out_stackdriver/stackdriver.c:1232 #1 0x5590aa24c502 in stackdriver_format() at plugins/out_stackdriver/stackdriver.c:1523 #2 0x5590aa24e509 in cb_stackdriver_flush() at plugins/out_stackdriver/stackdriver.c:2105 #3 0x5590aa19c0de in output_pre_cb_flush() at include/fluent-bit/flb_output.h:490 #4 0x5590aa6889a6 in co_init() at lib/monkey/deps/flb_libco/amd64.c:117 #5 0xffffffffffffffff in ???() at ???:0 解決方法： 清除 Stackdriver Log Forwarder 的緩衝區區塊。 注意：在下列指令中，請將 KUBECONFIG 替換為管理員叢集 kubeconfig 檔案的路徑。 終止所有 stackdriver-log-forwarder Pod： kubectl --kubeconfig KUBECONFIG -n kube-system patch daemonset \ stackdriver-log-forwarder -p \ '{"spec": {"template": {"spec": {"nodeSelector": {"non-existing": "true"}}}}}' 確認 stackdriver-log-forwarder Pod 已刪除，再繼續下一個步驟。 部署下列 DaemonSet，清除 fluent-bit 緩衝區中的任何損毀資料： kubectl --kubeconfig KUBECONFIG -n kube-system apply -f - << EOF apiVersion: apps/v1 kind: DaemonSet metadata: name: fluent-bit-cleanup namespace: kube-system spec: selector: matchLabels: app: fluent-bit-cleanup template: metadata: labels: app: fluent-bit-cleanup spec: containers: - name: fluent-bit-cleanup image: debian:10-slim command: ["bash", "-c"] args: - | rm -rf /var/log/fluent-bit-buffers/ echo "Fluent Bit local buffer is cleaned up." sleep 3600 volumeMounts: - name: varlog mountPath: /var/log securityContext: privileged: true tolerations: - key: "CriticalAddonsOnly" operator: "Exists" - key: node-role.kubernetes.io/master effect: NoSchedule - key: node-role.gke.io/observability effect: NoSchedule volumes: - name: varlog hostPath: path: /var/log EOF 使用下列指令，確認 DaemonSet 已清除所有節點： kubectl --kubeconfig KUBECONFIG logs \ -n kube-system -l \ app=fluent-bit-cleanup | grep "cleaned up" | wc -l kubectl --kubeconfig KUBECONFIG -n \ kube-system get pods -l \ app=fluent-bit-cleanup --no-headers | wc -l 這兩項指令的輸出內容應等於叢集中的節點數量。 刪除清理作業 DaemonSet： kubectl --kubeconfig KUBECONFIG -n \ kube-system delete ds fluent-bit-cleanup 重新啟動記錄轉送器 Pod： kubectl --kubeconfig KUBECONFIG \ -n kube-system patch daemonset \ stackdriver-log-forwarder --type json \ -p='[{"op": "remove", "path": "/spec/template/spec/nodeSelector/non-existing"}]'
記錄和監控	1.10、1.11、1.12、1.13、1.14、1.15、1.16、1.28	gke-metrics-agent 記錄檔中出現不明指標錯誤 gke-metrics-agent 是在每個節點上收集指標，並將指標轉送至 Cloud Monitoring 的 DaemonSet。這可能會產生類似下列內容的記錄： Unknown metric: kubernetes.io/anthos/go_gc_duration_seconds_summary_percentile 其他指標類型也可能發生類似錯誤，包括 (但不限於)： apiserver_admission_step_admission_duration_seconds_summary go_gc_duration_seconds scheduler_scheduling_duration_seconds gkeconnect_http_request_duration_seconds_summary alertmanager_nflog_snapshot_duration_seconds_summary 您可以放心忽略這些錯誤記錄，因為這些記錄所指的指標不受支援，且對監控用途而言並不重要。
記錄和監控	1.10、1.11	指標匯出作業間歇性中斷 叢集可能會中斷正常、持續匯出指標，或部分節點缺少指標。如果這個問題影響叢集，您可能會發現下列指標的資料出現缺口 (至少)： kubernetes.io/anthos/container_memory_working_set_bytes kubernetes.io/anthos/container_cpu_usage_seconds_total kubernetes.io/anthos/container_network_receive_bytes_total 解決方法 將叢集升級至 1.11.1 以上版本。 如果無法升級，請按照下列步驟操作，暫時解決問題： 開啟 stackdriver 資源進行編輯： kubectl -n kube-system edit stackdriver stackdriver 如要將 gke-metrics-agent 的 CPU 要求從 10m 增加到 50m，請在 stackdriver 資訊清單中新增下列 resourceAttrOverride 區段： spec: resourceAttrOverride: gke-metrics-agent/gke-metrics-agent: limits: cpu: 100m memory: 4608Mi requests: cpu: 50m memory: 200Mi 編輯後的資源應如下所示： spec: anthosDistribution: baremetal clusterLocation: us-west1-a clusterName: my-cluster enableStackdriverForApplications: true gcpServiceAccountSecretName: ... optimizedMetrics: true portable: true projectID: my-project-191923 proxyConfigSecretName: ... resourceAttrOverride: gke-metrics-agent/gke-metrics-agent: limits: cpu: 100m memory: 4608Mi requests: cpu: 50m memory: 200Mi 儲存變更並關閉文字編輯器。 如要確認變更是否生效，請執行下列指令： kubectl -n kube-system get daemonset \ gke-metrics-agent -o yaml | grep "cpu: 50m" 如果編輯內容已生效，這項指令會找出 cpu: 50m。
網路	1.10	多個預設閘道會中斷與外部端點的連線 節點中有多個預設閘道可能會導致 Pod 無法連線至外部端點，例如 google.com。 如要判斷是否受到這個問題影響，請在節點上執行下列指令： ip route show 如果回覆中出現多個 default，表示你受到影響。
網路	1.12	使用者叢集上的網路自訂資源編輯作業會遭到覆寫 1.12.x 版叢集不會禁止您在使用者叢集中手動編輯網路自訂資源。叢集升級期間，Google Distributed Cloud 會比對使用者叢集和管理員叢集中的自訂資源。這項對帳作業會覆寫直接在使用者叢集網路自訂資源中進行的任何編輯作業。網路自訂資源只能在管理員叢集中修改，但 1.12.x 版叢集不會強制執行這項規定。 進階網路功能，例如使用 BGP 進行套裝組合負載平衡、輸出 NAT 閘道、SR-IOV 網路、使用 BGP 的扁平模式，以及Pod 的多重 NIC，使用下列自訂資源： BGPLoadBalancer BGPPeer NetworkGatewayGroup NetworkAttachmentDefinition ClusterCIDRConfig FlatIPMode 您可以在管理員叢集中編輯這些自訂資源，而協調步驟會將變更套用至使用者叢集。 解決方法 如果您已在使用者叢集上修改任何上述自訂資源，請先在管理員叢集上修改對應的自訂資源，再進行升級。這個步驟可確保設定變更不會遺失。叢集版本 1.13.0 以上會禁止您直接修改使用者叢集上的網路自訂資源。
網路	1.10、1.11、1.12、1.13、1.14、1.15、1.16、1.28	Pod 連線失敗和反向路徑篩選 Google Distributed Cloud 會在節點上設定反向路徑篩選，以停用來源驗證 (net.ipv4.conf.all.rp_filter=0)。如果 rp_filter 設定變更為 1 或 2，Pod 會因節點外通訊逾時而失敗。 反向路徑篩選功能是在 IPv4 設定資料夾 (net/ipv4/conf/all) 中，透過 rp_filter 檔案設定。這個值也可能遭到 sysctl 覆寫，後者會在網路安全性設定檔 (例如 /etc/sysctl.d/60-gce-network-security.conf) 中儲存反向路徑篩選設定。 解決方法 如要還原 Pod 連線，請採取下列任一解決方法： 手動將 net.ipv4.conf.all.rp_filter 的值設回 0，然後執行 sudo sysctl -p 來套用變更。 或 重新啟動 anetd Pod，將 net.ipv4.conf.all.rp_filter 設回 0。如要重新啟動 anetd Pod，請使用下列指令找出並刪除 anetd Pod，系統會啟動新的 anetd Pod 來取代： kubectl get pods -n kube-system kubectl delete pods -n kube-system ANETD_XYZ 將 ANETD_XYZ 替換為 anetdPod 的名稱。 執行任一解決方法後，請在每個節點上執行 sysctl net.ipv4.conf.all.rp_filter，確認 net.ipv4.conf.all.rp_filter 值已設為 0。
網路	1.10、1.11、1.12、1.13、1.14、1.15、1.16、1.28、1.29、1.30、1.31、1.32、1.33、1.34	啟動 (kind) 叢集 IP 位址和叢集節點 IP 位址 重疊 192.168.122.0/24 和 10.96.0.0/27 是啟動 (kind) 叢集使用的預設 Pod 和服務 CIDR。如果預檢與叢集節點機器的 IP 位址重疊，就會失敗。 解決方法 為避免發生衝突，您可以將 --bootstrap-cluster-pod-cidr 和 --bootstrap-cluster-service-cidr 旗標傳遞至 bmctl，指定不同的值。
作業系統	1.10、1.11、1.12、1.13、1.14、1.15、1.16、1.28	在 CentOS 上建立或升級叢集失敗 2020 年 12 月，CentOS 社群和 Red Hat 宣布終止 CentOS 支援。CentOS 8 已於 2022 年 1 月 31 日終止服務 (EOL)。由於終止支援，yum存放區已停止為 CentOS 運作，導致叢集建立和叢集升級作業失敗。這項異動適用於所有支援的 CentOS 版本，且會影響所有版本的叢集。 解決方法 查看解決方法步驟 如要解決這個問題，請執行下列指令，讓 CentOS 使用封存的動態消息： sed -i 's/mirrorlist/#mirrorlist/g' /etc/yum.repos.d/CentOS-Linux-* sed -i 's|#baseurl=http://mirror.centos.org|baseurl=http://vault.centos.org|g' \ /etc/yum.repos.d/CentOS-Linux-* 從長遠來看，建議遷移至其他支援的作業系統。
安全性	1.10、1.11、1.12、1.13、1.14、1.15、1.16、1.28	使用 containerd 和 SELinux 時，容器無法寫入 Dockerfile 中定義的 VOLUME 如果您使用 containerd 做為容器執行階段，且作業系統已啟用 SELinux，則應用程式 Dockerfile 中定義的 VOLUME 可能無法寫入。舉例來說，使用下列 Dockerfile 建構的容器無法寫入 /tmp 資料夾。 FROM ubuntu:20.04 RUN chmod -R 777 /tmp VOLUME /tmp 如要確認是否受到這個問題影響，請在裝載問題容器的節點上執行下列指令： ausearch -m avc 如果受到這個問題影響，您會看到類似下列內容的 denied 錯誤： time->Mon Apr 4 21:01:32 2022 type=PROCTITLE msg=audit(1649106092.768:10979): proctitle="bash" type=SYSCALL msg=audit(1649106092.768:10979): arch=c000003e syscall=257 success=no exit=-13 a0=ffffff9c a1=55eeba72b320 a2=241 a3=1b6 items=0 ppid=75712 pid=76042 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=4294967295 comm="bash" exe="/usr/bin/bash" subj=system_u:system_r:container_t:s0:c701,c935 key=(null) type=AVC msg=audit(1649106092.768:10979): avc: denied { write } for pid=76042 comm="bash" name="aca03d7bb8de23c725a86cb9f50945664cb338dfe6ac19ed0036c" dev="sda2" ino=369501097 scontext=system_u:system_r: container_t:s0:c701,c935 tcontext=system_u:object_r: container_ro_file_t:s0 tclass=dir permissive=0 解決方法 如要解決這個問題，請進行下列任一變更： 關閉 SELinux。 請勿在 Dockerfile 中使用 VOLUME 功能。
升級與更新	1.10、1.11、1.12	叢集升級後，節點問題偵測器預設不會啟用 升級叢集時，系統預設不會啟用節點問題偵測器。這個問題適用於從 1.10 版升級至 1.12.1 版，並已在 1.12.2 版中修正。 解決方法： 如要啟用節點問題偵測器，請執行下列步驟： 確認節點上是否正在執行 node-problem-detector systemd 服務。 使用 SSH 指令連線至節點。 檢查節點上是否正在執行 node-problem-detector systemd 服務： systemctl is-active node-problem-detector 如果指令結果顯示 inactive，表示節點上未執行 node-problem-detector。 如要啟用節點問題偵測器，請使用 kubectl edit 指令並編輯 node-problem-detector-config ConfigMap。詳情請參閱「節點問題偵測器」。
作業	1.9、1.10	使用非根登入時，叢集備份作業會失敗 如果 nodeAccess.loginUser 設為非根使用者名稱，bmctl backup cluster 指令就會失敗。] 解決方法： 這個問題會影響 1.9.x、1.10.0 和 1.10.1 版，並在 1.10.2 以上版本中修正。
網路	1.10、1.11、1.12	負載平衡器服務無法搭配控制層主機網路上的容器使用 anetd 存在錯誤，如果後端 Pod 同時在控制層節點上執行，且使用容器規格中的 hostNetwork: true 欄位，則系統會捨棄 LoadBalancer 服務的封包。 1.13 以上版本不會出現這個錯誤。 解決方法： 如果您使用由 hostNetwork Pod 支援的 LoadBalancer 服務，可以嘗試下列解決方法： 在工作站節點 (而非控制層節點) 上執行。 在 Service 規格中使用 externalTrafficPolicy: local，並 確保工作負載在負載平衡器節點上執行。
升級與更新	1.12、1.13	孤立的 anthos-version-$version$ Pod 無法提取映像檔 將叢集從 1.12.x 升級至 1.13.x 時，可能會發現 anthos-version-$version$ Pod 失敗，並出現 ImagePullBackOff 錯誤。這是因為 anthos-cluster-operator 升級時發生競爭條件，但這不應影響任何一般叢集功能。 1.13 以上版本已修正這個錯誤。 解決方法： 刪除 dynamic-version-installer 的工作： kubectl delete job anthos-version-$version$ -n kube-system
升級與更新	1.13	從 1.11 升級的 1.12 叢集無法升級至 1.13.0 從 1.11 版升級的 1.12 版叢集無法升級至 1.13.0 版。如果叢集是在 1.12 版建立，就不會發生這項升級問題。 如要判斷是否受到影響，請檢查管理員叢集升級工作的記錄，其中包含 upgrade-first-no* 字串。如果看到下列錯誤訊息，表示你受到影響。 TASK [kubeadm_upgrade_apply : Run kubeadm upgrade apply] ******* ... [upgrade/config] FATAL: featureGates: Invalid value: map[string]bool{\"IPv6DualStack\":false}: IPv6DualStack isn't a valid feature name. ... 解決方法： 如要解決這個問題，請按照下列步驟操作： 在管理員工作站上執行下列指令： echo '[{ "op": "remove", "path": \ "/spec/clusterConfiguration/featureGates" }]' \ > remove-feature-gates.patch export KUBECONFIG=$ADMIN_KUBECONFIG kubectl get kubeadmconfig -A --no-headers | xargs -L1 bash -c \ 'kubectl patch kubeadmconfig $1 -n $0 --type json \ --patch-file remove-feature-gates.patch' 重新嘗試升級叢集。
記錄和監控	1.16.2、1.16.3	「stackdriver-operator」的 CPU 使用率偏高 stackdriver-operator發生問題，導致 CPU 時間消耗量高於正常值。在閒置狀態下，正常 CPU 用量應低於 50 毫 CPU (50m)。stackdriver-operator原因是 stackdriver-operator 套用的憑證資源與 cert-manager 的預期不符。這種不符會導致更新這些資源時，cert-manager 和 stackdriver-operator 之間發生競爭狀況。 如果叢集的 CPU 可用性有限，這個問題可能會導致叢集效能下降。 解決方法： 在升級至修正此錯誤的版本前，請使用下列解決方法： 如要暫時將 stackdriver-operator 縮減為 0 個副本，請套用 AddonConfiguration 自訂資源： kubectl scale deploy stackdriver-operator --replicas=0 升級至修正此問題的版本後，請再次向上擴充 stackdriver-operator： kubectl scale deploy stackdriver-operator --replicas=1
記錄和監控	1.16.0、1.16.1	無法根據註解擷取指標 在 Google Distributed Cloud 1.16 次要版本中，stackdriver 自訂資源規格中的 enableStackdriverForApplications 欄位已淘汰。這個欄位已由 stackdriver 自訂資源中的 enableCloudLoggingForApplications 和 enableGMPForApplications 兩個欄位取代。 建議您使用 Google Cloud Managed Service for Prometheus 監控工作負載。使用 enableGMPForApplications 欄位啟用這項功能。 如果您依賴由工作負載上的 prometheus.io/scrape 註解觸發的指標收集作業，可以使用 annotationBasedApplicationMetrics 特徵閘旗標保留舊版行為。不過，annotationBasedApplicationMetrics 有問題，導致無法正常運作，因此無法將應用程式的指標收集到 Cloud Monitoring。 解決方法： 如要解決這個問題，請將叢集升級至 1.16.2 以上版本。 透過 annotationBasedApplicationMetrics 功能閘啟用以註解為準的工作負載指標收集功能後，系統會收集具有 prometheus.io/scrape 註解的物件指標。許多開放原始碼軟體系統可能會使用這項註解。如果您繼續使用這種指標收集方法，請注意這項依附元件，以免 Cloud Monitoring 的指標費用超出預期。
記錄和監控	1.15、1.16、1.28.0-1.28.900、1.29.0-1.29.400、1.30.0、1.30.100	由於權限遭拒，Cloud 稽核記錄失敗 Cloud 稽核記錄需要特殊權限設定，叢集運算子會透過 GKE Hub 自動執行這項設定。 不過，如果一個管理員叢集管理多個具有不同專案 ID 的叢集，叢集運算子中的錯誤會導致系統重複將同一個服務帳戶附加至允許清單，並因大小限制而導致允許清單要求失敗。這會導致部分或所有叢集的稽核記錄無法注入 Google Cloud。 症狀是受影響叢集中的 Permission Denied Pod 發生一連串錯誤。audit-proxy 另一個徵兆是錯誤狀態，以及透過 GKE Hub 檢查 Cloud 稽核記錄許可清單時，出現一長串重複的服務帳戶： curl -H "Authorization: Bearer $(gcloud auth print-access-token)" \ https://gkehub.googleapis.com/v1alpha/projects/PROJECT_ID/locations/global/features/cloudauditlogging { "name": "projects/PROJECT_ID/locations/global/features/cloudauditlogging", "spec": { "cloudauditlogging": { "allowlistedServiceAccounts": [ "SERVICE-ACCOUNT-EMAIL", ... ... multiple lines of the same service account ] } }, "state": { "state": { "code": "ERROR" } } } 如要解決這個問題，請將叢集升級至至少 1.28.1000、1.29.500 或 1.30.200，這些版本已修正這個問題；或者，您也可以套用下列解決方法： 查看解決方法步驟 刪除並重新建立 GKE Hub 雲端稽核記錄功能，強制再次觸發自動許可清單。 刪除 cloudauditlogging 中樞功能： curl -X DELETE -H "Authorization: Bearer $(gcloud auth print-access-token)" \ https://gkehub.googleapis.com/v1alpha/projects/PROJECT_ID/locations/global/features/cloudauditlogging 重新建立 cloudauditlogging 中樞功能，方法如下： curl -X POST -H "Authorization: Bearer $(gcloud auth print-access-token)" \ -H "Content-Type: application/json" \ https://gkehub.googleapis.com/v1alpha/projects/PROJECT_ID/locations/global/features?feature_id=cloudauditlogging -d \ '{"spec":{"cloudauditlogging":{"allowlistedServiceAccounts":["SERVICE_ACCOUNT_EMAIL"]}}}' 在上述指令中： 將 PROJECT_ID 替換為叢集的 叢集作業專案。 將 SERVICE_ACCOUNT_EMAIL 替換為叢集 記錄和監控服務帳戶的電子郵件地址。
設定	1.29 和更早版本、1.30.400 和更早版本，以及 1.31.0 中的所有修補程式版本	如果只變更 hosts 欄位，節點上的登錄檔鏡像設定不會更新 在叢集規格中更新登錄檔鏡像端點的 containerRuntime.registryMirrors.hosts 欄位時，變更不會自動套用至叢集節點。這是因為和解邏輯不會偵測到僅對 hosts 欄位所做的變更，因此不會觸發負責更新節點上 containerd 設定的機器更新作業。 驗證： 如要驗證這個問題，請只修改登錄檔映像檔的 hosts 欄位，然後檢查工作站節點上的 containerd 設定檔 (路徑可能是 /etc/containerd/config.toml 或其他路徑，例如 /etc/containerd/config.d/01-containerd.conf，視版本和設定而定)。檔案不會顯示鏡像端點的更新 hosts 清單。 解決方法： 選擇下列其中一個選項： 升級至修正問題的版本：將叢集升級至 1.30.500-gke.126 以上版本、1.31.100-gke.136 以上版本或 1.32.0 版。 透過 NodePool 變更觸發更新：對受影響節點的 NodePool 規格進行微小變更。例如新增臨時標籤或註解。這會觸發機器更新程序，並擷取登錄檔鏡像變更。之後可以移除微不足道的變更。

後續步驟

如需其他協助，請與 Cloud Customer Care 團隊聯絡。如要進一步瞭解支援資源，包括下列項目，請參閱「取得支援」：

• 提出支援案件的規定。
• 工具：協助您排解問題，例如環境設定、記錄和指標。
• 支援的元件。