本頁面說明如何解決 Google Kubernetes Engine (GKE) 叢集升級問題。
問題:控制層升級後,kube-apiserver 狀態不良
手動升級叢集 GKE 版本時,會發生下列問題。部分使用者部署的許可控制器 Webhook 可能會阻礙系統元件建立寬鬆的 RBAC 角色,導致系統無法正常運作。升級控制層時, Google Cloud會重新建立 Kubernetes API 伺服器 (kube-apiserver) 元件。如果 Webhook 封鎖 API 伺服器元件的 RBAC 角色,API 伺服器就不會啟動,叢集升級也無法完成。
即使 Webhook 運作正常,也可能導致叢集升級失敗,因為新建立的控制層可能無法連線至 Webhook。
gcloud CLI 中的錯誤訊息類似於下列內容:
FAILED: All cluster resources were brought up, but: component "KubeApiserverReady" from endpoint "readyz of kube apiserver is not successful" is unhealthy.
如要找出失敗的 Webhook,請在 GKE 稽核記錄中,檢查具有下列資訊的 RBAC 呼叫:
protoPayload.resourceName="RBAC_RULE"
protoPayload.authenticationInfo.principalEmail="system:apiserver"
RBAC_RULE
是 RBAC 角色的完整名稱,例如 rbac.authorization.k8s.io/v1/clusterroles/system:controller:horizontal-pod-autoscaler
。
記錄檔會顯示失敗的 Webhook 名稱,格式如下:
admission webhook WEBHOOK_NAME denied the request
如要解決這個問題,請嘗試下列方法:
- 調整限制,允許建立及更新具有
system:
前置字元的 ClusterRole。 - 調整 Webhook,使其不再攔截建立及更新系統 RBAC 角色時的要求。
- 停用 Webhook。
為什麼會發生這種情況?
Kubernetes 會自動調解最新次要版本中的預設系統 RBAC 角色和預設政策。新版 Kubernetes 有時會變更系統角色的預設政策。
為執行這項協調作業,GKE 會在叢集中建立或更新 ClusterRole 和 ClusterRoleBinding。如果您的 Webhook 會攔截並拒絕建立或更新要求,原因是預設 RBAC 政策使用的權限範圍,API 伺服器就無法在新次要版本上運作。
問題:升級標準叢集後,工作負載遭到驅逐
如果符合下列所有條件,叢集升級後工作負載可能遭到驅逐:
- 當叢集的控制層執行新的 GKE 版本時,系統工作負載需要更多空間。
- 現有節點的資源不足,無法執行新的系統工作負載和現有工作負載。
- 叢集已停用叢集自動配置器。
如要解決這個問題,請嘗試下列步驟:
問題:節點版本與控制層版本不相容
檢查叢集控制層執行的 Kubernetes 版本,然後檢查叢集節點集區執行的 Kubernetes 版本。如果叢集的任何節點集區版本比控制層舊超過兩個子版本,可能會導致叢集發生問題。
GKE 團隊會定期代您升級叢集控制層。控制層會升級至較新的 Kubernetes 穩定版本。根據預設,叢集的節點會啟用自動升級功能,我們建議您不要停用這項功能。
如果叢集節點停用自動升級功能,且您未手動升級節點集區版本,使其與控制層相容,隨著控制層自動升級,最終會與節點不相容。叢集控制層與節點不相容,可能會導致意料之外的問題。
Kubernetes 版本和版本偏差支援政策指出,控制層可與低於自己兩個次要版本之內的節點相容。舉例來說,Kubernetes 1.19 控制層與 Kubernetes 1.19、1.18 和 1.17 節點相容。如要解決這個問題,請手動將節點集區版本升級至與控制層相容的版本。
如果擔心升級程序會導致受影響節點上執行的工作負載中斷,請完成下列步驟,將工作負載遷移至新的節點集區:
- 建立新的節點集區,並使用相容版本。
- 隔離現有節點集區的節點。
- 選用:更新在現有節點集區上執行的工作負載,為標籤
cloud.google.com/gke-nodepool:NEW_NODE_POOL_NAME
新增 nodeSelector,其中NEW_NODE_POOL_NAME
是新節點集區的名稱。這樣可確保 GKE 將這些工作負載放置在新節點集區的節點上。 - 清空現有節點集區。
- 確認工作負載在新節點集區中順利執行。如果是,即可刪除舊節點集區。如果發現工作負載中斷,請取消隔離現有節點集區中的節點,並清空新節點,然後在現有節點上重新排程工作負載。請排解問題,然後再試一次。
問題:設定節點可分配資源後,Pod 停滯在待處理狀態
設定 Node Allocatable 並執行節點版本升級後,您可能會發現原本執行的 Pod 變更為待處理狀態。
如果 Pod 在升級後處於待處理狀態,建議採取下列做法:
確保 Pod 的 CPU 和記憶體要求不會超過尖峰用量。由於 GKE 會預留 CPU 和記憶體做為額外負擔,因此 Pod 無法要求這些資源。如果 Pod 要求的 CPU 或記憶體超過實際用量,其他 Pod 就無法要求這些資源,叢集也可能無法充分發揮效用。詳情請參閱「如何排定具有資源要求的 Pod 時間」。
建議您調整叢集大小。如需操作說明,請參閱「調整叢集大小」。
如要還原這項變更,請降級叢集。如需操作說明,請參閱手動升級叢集或節點集區。
後續步驟
如果無法在說明文件中找到問題的解決方法,請參閱「取得支援」一文,尋求進一步的協助, 包括下列主題的建議:
- 與 Cloud 客戶服務聯絡,建立支援案件。
- 在 StackOverflow 上提問,並使用
google-kubernetes-engine
標記搜尋類似問題,向社群尋求支援。你也可以加入#kubernetes-engine
Slack 頻道,取得更多社群支援。 - 使用公開問題追蹤工具回報錯誤或提出功能要求。