排解升級問題

本頁面說明如何解決 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 在升級後處於待處理狀態，建議採取下列做法：

後續步驟