排解升級問題


本頁面說明如何解決 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 節點相容。如要解決這個問題,請手動將節點集區版本升級至與控制層相容的版本。

如果擔心升級程序會導致受影響節點上執行的工作負載中斷,請完成下列步驟,將工作負載遷移至新的節點集區:

  1. 建立新的節點集區,並使用相容版本。
  2. 隔離現有節點集區的節點。
  3. 選用:更新在現有節點集區上執行的工作負載,為標籤 cloud.google.com/gke-nodepool:NEW_NODE_POOL_NAME 新增 nodeSelector,其中 NEW_NODE_POOL_NAME 是新節點集區的名稱。這樣可確保 GKE 將這些工作負載放置在新節點集區的節點上。
  4. 清空現有節點集區。
  5. 確認工作負載在新節點集區中順利執行。如果是,即可刪除舊節點集區。如果發現工作負載中斷,請取消隔離現有節點集區中的節點,並清空新節點,然後在現有節點上重新排程工作負載。請排解問題,然後再試一次。

問題:設定節點可分配資源後,Pod 停滯在待處理狀態

設定 Node Allocatable 並執行節點版本升級後,您可能會發現原本執行的 Pod 變更為待處理狀態。

如果 Pod 在升級後處於待處理狀態,建議採取下列做法:

後續步驟