讓節點進入維護模式

維護模式可讓您維修及保養節點，盡可能減少對工作負載的干擾。將節點新增至叢集設定的 maintenanceBlocks 區段時，Google Distributed Cloud 會妥善清空工作負載，並防止新的 Pod 排定在這些節點上。如需將整個叢集離線，也可以安全地關閉並重新啟動叢集。

升級叢集時，Google Distributed Cloud 會自動使用維護模式，在升級前清空節點。如要進一步瞭解升級程序，請參閱「叢集升級的生命週期和階段」。

運作方式

Google Distributed Cloud 可讓您將節點設為維護模式。這種做法可讓其他叢集元件正確得知節點處於維護模式。將節點設為維護模式後，就無法在該節點上排定其他 Pod，現有的 Pod 也會停止。

除了使用維護模式，您也可以在特定節點上手動使用 Kubernetes 指令，例如 kubectl cordon 和 kubectl drain。

使用維護模式程序時，Google Distributed Cloud 會執行下列操作：

1.29

• Google Distributed Cloud 會將 baremetal.cluster.gke.io/maintenance:NoSchedule taint 新增至指定節點，防止在節點上排定新的 Pod。

• Google Distributed Cloud 會使用 Eviction API 剔除各個 Pod。這種節點排空方法會遵循 PodDisruptionBudget (PDB)。您可以設定 PDB，使用 minAvailable 和 maxUnavailable 欄位指定一組 Pod 可容忍的中斷程度，藉此保護工作負載。以這種方式排空節點，可更有效地防範工作負載中斷。1.29 版正式推出以逐出為基礎的節點排除功能。

• 系統會強制執行 20 分鐘的逾時設定，確保節點不會因等待 Pod 停止而停滯。如果 Pod 設為容許所有污點，或具有終止器，則可能不會停止。Google Distributed Cloud 會嘗試停止所有 Pod，但如果超過逾時時間，節點就會進入維護模式。這項逾時設定可防止執行中的 Pod 阻礙升級。

1.28 以下版本

• Google Distributed Cloud 會將 baremetal.cluster.gke.io/maintenance:NoSchedule taint 新增至指定節點，防止在節點上排定新的 Pod。

• Google Distributed Cloud 會新增 baremetal.cluster.gke.io/maintenance:NoExecute 污點。Google Distributed Cloud kube-scheduler 會根據 NoExecute 污點停止 Pod 並排空節點。這種節點排空方法不遵循 PDB。

• 系統會強制執行 20 分鐘的逾時設定，確保節點不會因等待 Pod 停止而停滯。如果 Pod 設為容許所有污點，或具有終止器，則可能不會停止。Google Distributed Cloud 會嘗試停止所有 Pod，但如果超過逾時時間，節點就會進入維護模式。這項逾時設定可防止執行中的 Pod 阻礙升級。

依據驅逐作業進行排空

從以 taint 為基礎的排除作業切換至以逐出為基礎的節點排除作業，並不會造成程序變更。這項切換只會影響對帳邏輯。

這項功能在所有支援的版本中，並非處於相同的推出階段：

• 1.29：正式發布
• 1.28：不適用
• 1.16：不適用

排除順序

在 1.29 版之前，Google Distributed Cloud kube-scheduler 執行的污點式節點排空作業不會採用特定演算法，從節點排空 Pod。使用以逐出為基礎的節點排空功能時，Pod 會依優先順序逐出。淘汰優先順序與特定 Pod 條件相關聯，如下表所示：

排除順序	Pod 條件 (必須全部符合) 和
1	符合下列條件的 Pod 會遭到淘汰： 沒有 spec.prorityClassName 的 Pod 不符合任何已知容器儲存介面 (CSI) 名稱的 Pod 不屬於 DaemonSet 的 Pod
2	符合下列條件的 Pod 會遭到淘汰： 屬於 DaemonSet 的 Pod Pod 沒有 PriorityClass 不符合任何已知容器儲存介面 (CSI) 名稱的 Pod
3	符合下列條件的 Pod 會遭到淘汰： Pod 含有 Spec.ProrityClassName 不符合任何已知容器儲存介面 (CSI) 名稱的 Pod 相符 Pod 的淘汰順序取決於 PriorityClass.value，由低到高。
4	等待 CSI 在所有 Pod 都遭到剔除後，清除 PV/PVC 掛接。使用 Node.Status.VolumesInUse 表示所有磁碟區都已清除。
5	符合下列條件的 Pod 會遭到淘汰： 符合已知容器儲存空間介面 (CSI) 名稱的 Pod kubelet 不提供就地升級相容性，因此仍須清空這些 Pod。

由於以逐出為基礎的節點清空作業會遵循 PDB，因此在某些情況下，PDB 設定可能會阻擋節點清空作業。如需節點集區排空作業的疑難排解資訊，請參閱「查看節點長時間處於排空狀態的原因」。

依據淘汰作業進行排除的期限

將節點設為維護模式時，系統會強制執行預設的 20 分鐘 (1200 秒) 逾時設定，以便清空節點。逾時後，所有不容許維護模式的 Pod 都會遭到淘汰，節點也會進入維護模式。從 1.16 版開始，您可以將 baremetal.cluster.gke.io/maintenance-mode-deadline-seconds 註解新增至叢集資源，藉此調整逾時時間長度。舉例來說，如要將逾時時間變更為 10 分鐘，請在叢集資源中新增 baremetal.cluster.gke.io/maintenance-mode-deadline-seconds: "600" 註解。

以逐出為基礎的清空作業有時可能會超過 maintenance-mode-deadline-seconds 指定的期限。如果 Pod 在超過期限後仍卡在終止狀態，請勿使用 kubectl 搭配 --grace-period=0 --force 旗標強制刪除，因為這可能會導致有狀態應用程式發生資料損毀或腦裂問題。請改為重新啟動有狀態 Pod 卡住的節點。

如需其他協助，請與 Cloud Customer Care 團隊聯絡。您也可以參閱「取得支援」，進一步瞭解支援資源，包括：

• 建立客服案件的需求條件。
• 工具：協助您疑難排解，例如您的環境設定、記錄和指標。
• 支援的元件。

停用以淘汰為基礎的節點排除功能

如果是子版本 1.29 以上的叢集，或升級至子版本 1.29 以上的叢集，預設會啟用以逐出為基礎的節點清空功能。如果以撤離為基礎的節點清空作業導致叢集升級或叢集維護發生問題，您可以將 baremetal.cluster.gke.io/maintenance-mode-ignore-pdb: "" 註解新增至叢集資源，還原為以污點為基礎的節點清空作業。

如要還原預設的逐出式節點排空行為，請完全移除註解。將註解設為 false 不會重新啟用預設行為。

將節點切換至維護模式

在叢集設定檔的 maintenanceBlocks 下方，為所選節點指定 IP 範圍，選擇要進入維護模式的節點。您選擇的節點必須處於就緒狀態，且在叢集中正常運作。

如要將節點設為維護模式，請按照下列步驟操作：

1. 編輯叢集設定檔，選取要進入維護模式的節點。

   您可以使用偏好的編輯器編輯設定檔，也可以直接執行下列指令，編輯叢集自訂資源：

   kubectl -n CLUSTER_NAMESPACE edit cluster CLUSTER_NAME

   更改下列內容：

   • CLUSTER_NAMESPACE：叢集的命名空間。
   • CLUSTER_NAME：叢集名稱。

2. 在叢集設定檔中新增 maintenanceBlocks 區段，為要進入維護模式的節點指定單一 IP 位址或位址範圍。

   以下範例說明如何指定 IP 位址範圍來選取多個節點：

   metadata:
     name: my-cluster
     namespace: cluster-my-cluster
   spec:
     maintenanceBlocks:
       cidrBlocks:
       - 172.16.128.1-172.16.128.64
   

3. 儲存並套用更新後的叢集設定。

   Google Distributed Cloud 會開始將節點設為維護模式。

4. 執行下列指令，取得叢集中的節點狀態：

   kubectl get nodes --kubeconfig=KUBECONFIG

   輸出結果會與下列內容相似：

   NAME                STATUS   ROLES           AGE     VERSION
   user-baremetal-01   Ready    control-plane   2d22h   v1.27.4-gke.1600
   user-baremetal-04   Ready    worker          2d22h   v1.27.4-gke.1600
   user-baremetal-05   Ready    worker          2d22h   v1.27.4-gke.1600
   user-baremetal-06   Ready    worker          2d22h   v1.27.4-gke.1600
   

   請注意，節點仍可排程，但 taint 會防止任何 Pod (沒有適當的容許設定) 排程到節點上。

5. 執行下列指令，取得處於維護模式的節點數量：

   kubectl get nodepools --kubeconfig ADMIN_KUBECONFIG 
   

   回應內容應類似下方範例：

   NAME   READY   RECONCILING   STALLED   UNDERMAINTENANCE   UNKNOWN
   np1    3       0             0         1                  0
   

   這個範例中的 UNDERMAINTENANCE 欄顯示一個節點處於維護模式。

   節點進入維護模式時，Google Distributed Cloud 也會為節點新增下列污點：

   • baremetal.cluster.gke.io/maintenance:NoExecute
   • baremetal.cluster.gke.io/maintenance:NoSchedule

將節點從維護模式中移除

如要將節點從維護模式中移除，請按照下列步驟操作：

1. 編輯叢集設定檔，清除要從維護模式中移除的節點。

   您可以使用偏好的編輯器編輯設定檔，也可以直接執行下列指令，編輯叢集自訂資源：

   kubectl -n CLUSTER_NAMESPACE edit cluster CLUSTER_NAME

   更改下列內容：

   • CLUSTER_NAMESPACE：叢集的命名空間。
   • CLUSTER_NAME：叢集名稱。

2. 您可以編輯 IP 位址，將特定節點從維護模式中移除，或移除 maintenanceBlocks 區段，將所有節點從維護模式中移除。

3. 儲存並套用更新後的叢集設定。

4. 使用 kubectl 指令查看節點狀態。

關閉並重新啟動叢集

如果必須關閉整個叢集，請按照下列各節的操作說明關閉叢集，並安全地重新啟動。

關閉叢集

如要關閉管理使用者叢集的叢集，必須先關閉所有受管理的使用者叢集。下列操作說明適用於所有 Google Distributed Cloud 叢集類型。

1. 檢查所有叢集節點的狀態：

   kubectl get nodes --kubeconfig CLUSTER_KUBECONFIG
   

   將 CLUSTER_KUBECONFIG 替換為叢集的 kubeconfig 檔案路徑。

   輸出結果會與下列內容相似：

   NAME        STATUS   ROLES           AGE    VERSION
   control-0   Ready    control-plane   202d   v1.27.4-gke.1600
   control-1   Ready    control-plane   202d   v1.27.4-gke.1600
   control-2   Ready    control-plane   202d   v1.27.4-gke.1600
   worker-0    Ready    worker          202d   v1.27.4-gke.1600
   worker-1    Ready    worker          202d   v1.27.4-gke.1600
   worker-2    Ready    worker          202d   v1.27.4-gke.1600
   worker-3    Ready    worker          202d   v1.27.4-gke.1600
   worker-4    Ready    worker          154d   v1.27.4-gke.1600
   worker-5    Ready    worker          154d   v1.27.4-gke.1600
   worker-6    Ready    worker          154d   v1.27.4-gke.1600
   worker-7    Ready    worker          154d   v1.27.4-gke.1600
   worker-8    Ready    worker          154d   v1.27.4-gke.1600
   worker-9    Ready    worker          154d   v1.27.4-gke.1600
   

   如果節點的 STATUS 不是 Ready，強烈建議您排解節點問題，並在所有節點都為 Ready 時再繼續操作。

2. 如果您要關閉使用者叢集，請檢查管理員叢集節點的狀態：

   kubectl get nodes --kubeconfig ADMIN_KUBECONFIG
   

   將 ADMIN_KUBECONFIG 替換為管理叢集的 kubeconfig 檔案路徑。

   後續步驟會依附於管理員叢集。如果節點的 STATUS 不是 Ready，強烈建議您排解節點問題，並在所有節點都處於 Ready 狀態時再繼續操作。

3. 檢查要關閉的叢集健康狀態：

   bmctl check cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
   

   更改下列內容：

   • CLUSTER_NAME：要檢查的叢集名稱。

   • ADMIN_KUBECONFIG：管理叢集的 kubeconfig 檔案路徑。

   請先修正所有回報的問題，再繼續操作。

4. 針對要關閉的叢集，請確認所有 etcd Pod 都在執行中：

   kubectl get pods --kubeconfig CLUSTER_KUBECONFIG -A \
       -l component=etcd
   

   將 CLUSTER_KUBECONFIG 替換為叢集的 kubeconfig 檔案路徑。

   輸出結果會與下列內容相似：

   NAMESPACE     NAME                   READY   STATUS    RESTARTS   AGE
   kube-system   etcd-control-0-admin   1/1     Running   0          2d22h
   kube-system   etcd-control-1-admin   1/1     Running   0          2d22h
   kube-system   etcd-control-2-admin   1/1     Running   0          2d22h
   

   如果 Pod 的 STATUS 不是 Running，強烈建議您排解 Pod 問題，並在所有 Pod 都處於 Running 狀態時再繼續操作。

5. 按照「備份叢集」一文所述執行備份。

   請務必在關閉叢集前備份 etcd，這樣一來，如果重新啟動叢集時發生任何問題，就能還原叢集。Etcd 損毀、節點硬體故障、網路連線問題，以及其他可能的情況，都可能導致叢集無法正常重新啟動。

6. 如要關閉含有 worker 節點的叢集，請將 worker 節點設為維護模式。

   這個步驟可盡量減少寫入 etcd 的次數，降低叢集重新啟動時，需要協調大量 etcd 寫入作業的可能性。

7. 將控制層節點切換至維護模式。

   這個步驟可防止節點關閉時，有狀態工作負載的寫入作業損毀。

8. 請按照下列順序關閉叢集節點：

   1. worker 節點
   2. 控制層負載平衡器節點

   3. 控制層節點，從 etcd 追蹤者開始，到 etcd 領導者結束

      如果您有高可用性 (HA) 叢集，可以使用 SSH 連線至各個控制層節點，並執行下列 etcdctl 指令，找出 etcd 領導者：

      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 \
          --write-out=table endpoint status
      

      回應包含 IS LEADER 欄，如果節點是 etcd 領導者，則會傳回 true。

   注意： etcd 追蹤者停止運作後，API 伺服器也會停止運作。這是因為如果 etcd 叢集失去仲裁，API 伺服器就無法處理要求，而關機時就會發生這種情況。所有控制層節點恢復連線後，etcd 就會重新取得多數決。

此時，叢集已完全關閉。完成任何必要的維護作業後，您可以按照下一節的說明重新啟動叢集。

重新啟動叢集

請按照下列步驟，重新啟動已完全關閉的叢集。

1. 按照與關機順序相反的順序開啟節點機器。

2. 將控制層節點從維護模式中移除。

   如需操作說明，請參閱「將節點從維護模式中移除」。

   注意： 您不必一次將一部機器移出維護模式，但建議您先從單一節點開始，確認其健康狀態良好，然後再慢慢增加節點數量。

3. 將 worker 節點從維護模式中移除。

4. 執行叢集健康狀態檢查，確保叢集正常運作：

   bmctl check cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
   

5. 如果發生 etcd 崩潰迴圈等問題，導致叢集無法正常重新啟動，請嘗試從最新的已知良好備份還原叢集。如需操作說明，請參閱「還原叢集」。

計費和維護模式

Google Distributed Cloud 的計費依據，是叢集中可執行工作負載的節點 vCPU 數量。將節點設為維護模式時，系統會將 NoExecute 和 NoSchedule 污點新增至節點，但不會停用計費功能。將節點設為維護模式後，請隔離節點 (kubectl cordon NODE_NAME)，將其標示為無法指派。節點標示為無法指派後，節點和相關聯的 vCPU 就不會計入帳單。

重要事項：關閉節點電源不會變更其計費狀態。如要將節點排除在計費範圍之外，請採取下列任一做法：

• 從節點集區移除個別節點
• 從叢集移除節點集區
• 將節點設為維護模式，並隔離節點，使其無法排程

如定價頁面所述，您可以使用 kubectl 查看每個使用者叢集的 vCPU 容量 (用於計費)。這個指令不會考量節點是否可排程，只會提供每個節點的 vCPU 數量。

如要找出使用者叢集每個節點的 vCPU 數量，請按照下列步驟操作：

kubectl get nodes \
    --kubeconfig USER_KUBECONFIG \
    -o=jsonpath="{range .items[*]}{.metadata.name}{\"\t\"} \
    {.status.capacity.cpu}{\"\n\"}{end}"

將 USER_KUBECONFIG 替換為使用者叢集的 kubeconfig 檔案路徑。