Google Distributed Cloud 的設計宗旨是限制故障範圍，並優先處理對業務持續性至關重要的功能。本文說明叢集發生故障時，叢集功能會受到哪些影響。這項資訊有助於判斷問題的優先順序，並找出需要排解的區域。
Google Distributed Cloud 的核心功能包括下列類別：
- 執行工作負載：現有工作負載可繼續執行。這是維持業務連續性的最重要考量。即使叢集發生問題，現有工作負載仍可繼續執行，不會中斷。
- 管理工作負載：您可以建立、更新及刪除工作負載。這是流量增加時，擴充工作負載的第二重要考量，即使叢集發生問題也一樣。
- 管理使用者叢集：您可以管理節點、更新、升級及刪除使用者叢集。這項考量的重要性不如應用程式生命週期。如果現有節點有可用容量，無法修改使用者叢集就不會影響使用者工作負載。
- 管理管理員叢集：您可以更新及升級管理員叢集。這是最不重要的考量因素，因為管理員叢集不會代管任何使用者工作負載。如果管理員叢集發生問題，應用程式工作負載仍會持續執行，不會中斷。
以下各節會使用這些核心功能類別，說明特定類型的失敗情境造成的影響。
故障模式
下列類型的故障可能會影響 Google Distributed Cloud 叢集的效能。
ESXi 主機故障
在這個失敗情境中，執行 Kubernetes 節點的虛擬機器 (VM) 執行個體所屬的 ESXi 主機可能會停止運作或發生網路分割。
| 執行工作負載 | 管理工作負載 | 管理使用者叢集 | 管理管理員叢集 | |
|---|---|---|---|---|
| 中斷 | 可能發生中斷和自動復原 | 可能發生中斷和自動復原 | 中斷和自動復原 | 中斷和自動復原 |
| 說明 | 在故障主機上執行的 Pod 會中斷，並自動重新排程至其他健康狀態良好的 VM。 如果使用者應用程式有備用工作負載容量，且分散在多個節點中，實作重試的用戶端就不會觀察到中斷情形。 |
如果主機故障影響非高可用性使用者叢集中的控制層 VM，或高可用性使用者叢集中的多個控制層 VM，就會發生中斷。 | 如果主機故障影響管理員叢集中的控制層 VM 或工作人員 VM，就會發生中斷情形。 | 如果主機故障影響管理員叢集中的控制層 VM，就會發生中斷。 |
| 復原 | vSphere HA 會自動在健康狀態良好的主機上重新啟動 VM。 | vSphere HA 會自動在健康狀態良好的主機上重新啟動 VM。 | vSphere HA 會自動在健康狀態良好的主機上重新啟動 VM。 | vSphere HA 會自動在健康狀態良好的主機上重新啟動 VM。 |
| 預防措施 | 以高可用性方式部署工作負載，盡量減少服務中斷的可能性。 | 使用高可用性使用者叢集，盡量減少中斷的可能性。 | — | — |
VM 故障
在這種故障情況下，VM 可能會意外遭到刪除、開機磁碟可能損毀，或 VM 可能因作業系統問題而遭入侵。
| 執行工作負載 | 管理工作負載 | 管理使用者叢集 | 管理管理員叢集 | |
|---|---|---|---|---|
| 中斷 | 可能發生中斷和自動復原 | 可能發生中斷和自動復原 | 中斷和自動/手動復原 | 中斷和手動復原 |
| 說明 | 在發生故障的 Worker VM 上執行的 Pod 會中斷，Kubernetes 會自動將這些 Pod 重新排程至其他正常的 VM。 如果使用者應用程式有備用工作負載容量，且分散在多個節點中，實作重試的用戶端就不會觀察到中斷情形。 |
如果非高可用性使用者叢集中的控制層 VM 發生故障，或高可用性使用者叢集中有多個控制層 VM 發生故障，就會發生中斷。 | 如果管理員叢集中的控制層 VM 或工作人員 VM 發生故障，就會發生中斷。 | 如果管理員叢集中的控制層 VM 發生故障，就會發生中斷情形。 |
| 復原 | 如果使用者叢集已啟用節點自動修復功能，系統會自動復原失敗的 VM。 | 如果管理員叢集已啟用節點自動修復功能，系統會自動復原失敗的 VM。 | 如果管理叢集已啟用節點自動修復功能，系統會自動復原管理叢集中失敗的工作站 VM。 如要復原管理員叢集的控制層 VM，請參閱「修復管理員叢集的控制層 VM」。 |
如要復原管理員叢集的控制層 VM，請參閱「修復管理員叢集的控制層 VM」。 |
| 預防措施 | 以高可用性方式部署工作負載，盡量減少服務中斷的可能性。 | 使用高可用性使用者叢集，盡量減少中斷的可能性。 | — | — |
儲存空間故障
在這種失敗情境中，VMDK 檔案中的內容可能會因 VM 異常關機而損毀，或是資料存放區故障可能會導致 etcd 資料和永久性磁碟區 (PV) 遺失。
etcd 失敗
| 執行工作負載 | 管理工作負載 | 管理使用者叢集 | 管理管理員叢集 | |
|---|---|---|---|---|
| 中斷 | 不會中斷 | 可能發生中斷和手動復原 | 中斷和手動復原 | 中斷和手動復原 |
| 說明 | — | 如果非高可用性使用者叢集中的 etcd 儲存空間發生故障，或是高可用性使用者叢集中有多個 etcd 副本發生故障，就會發生中斷。 | 如果非高可用性使用者叢集中的 etcd 儲存空間發生故障，或是高可用性使用者叢集中有多個 etcd 副本發生故障，就會發生中斷。 如果管理員叢集中的 etcd 副本發生故障，就會發生中斷。 |
如果管理員叢集中的 etcd 副本發生故障，就會發生中斷。 |
| 預防措施 | — | Google Distributed Cloud 提供手動程序，可從故障中復原。 | Google Distributed Cloud 提供手動程序，可從故障中復原。 | Google Distributed Cloud 提供手動程序，可從故障中復原。 |
使用者應用程式 PV 失敗
| 執行工作負載 | 管理工作負載 | 管理使用者叢集 | 管理管理員叢集 | |
|---|---|---|---|---|
| 中斷 | 可能中斷 | 不會中斷 | 不會中斷 | 不會中斷 |
| 說明 | 使用失敗 PV 的工作負載會受到影響。 以高可用性方式部署工作負載，盡量減少服務中斷的可能性。 |
— | — | — |
負載平衡器故障
在這個失敗情境中，負載平衡器故障可能會影響公開 LoadBalancer 類型服務的使用者工作負載。
| 執行工作負載 | 管理工作負載 | 管理使用者叢集 | 管理管理員叢集 | |
|---|---|---|---|---|
| 中斷和手動復原 | ||||
| 說明 |
備用負載平衡器復原管理員控制層 VIP 連線前，服務會中斷幾秒鐘。 使用 Seesaw 時，服務中斷時間最多可能為 2 秒， 使用 F5 時則最多可能為 300 秒。 隨著負載平衡器節點數量增加，MetalLB 的容錯移轉中斷時間也會變長。如果節點少於 5 個，中斷時間會在 10 秒內。 |
|||
| 復原 | Seesaw HA 會自動偵測故障，並故障轉移至備份執行個體。 Google Distributed Cloud 提供手動程序，可從 Seesaw 故障中復原。 |
|||
復原損毀的叢集
下列各節說明如何復原損毀的叢集。
從 ESXi 主機故障中復原
Google Distributed Cloud 採用 vSphere HA，在 ESXi 主機發生故障時提供復原功能。vSphere HA 會持續監控 ESXi 主機，並視需要自動在其他主機上重新啟動 VM。Google Distributed Cloud 使用者不會察覺到這項變更。
從 VM 故障中復原
VM 故障可能包括下列情況：
VM 遭到意外刪除。
VM 開機磁碟損毀，例如開機磁碟因垃圾內容日誌記錄而變成唯讀。
VM 啟動失敗，原因可能是磁碟效能不佳或網路設定問題，例如無法為 VM 分配 IP 位址，導致 VM 無法啟動。
Docker 疊加檔案系統損毀。
升級失敗導致管理員控制層 VM 遺失。
作業系統問題。
Google Distributed Cloud 提供管理員附加元件節點、使用者控制層和使用者節點的自動復原機制。這項節點自動修復功能可針對每個管理員叢集和使用者叢集啟用。
管理控制層 VM 的特殊之處在於，它並非由 Kubernetes 叢集管理，且可用性不會影響業務持續性。如要從管理員控制層 VM 故障中復原，請與 Cloud Customer Care 團隊聯絡。
從儲存空間故障中復原
部分儲存空間故障問題可透過 vSphere HA 和 vSAN 解決，不會影響 Google Distributed Cloud。不過，某些儲存空間故障可能會從 vSphere 層級浮現，導致各種 Google Distributed Cloud 元件上的資料損毀或遺失。
叢集和使用者工作負載的有狀態資訊會儲存在下列位置：
- etcd：每個叢集 (管理員叢集和使用者叢集) 都有 etcd 資料庫，用於儲存叢集的狀態 (Kubernetes 物件)。
- PersistentVolumes：系統元件和使用者工作負載都會使用。
從 etcd 資料損毀或遺失中復原
etcd 是 Kubernetes 用來儲存所有叢集狀態的資料庫，包括使用者應用程式資訊清單。如果使用者叢集的 etcd 資料庫損毀或遺失，應用程式生命週期作業就會停止運作。如果管理員叢集的 etcd 資料庫損毀或遺失，使用者叢集生命週期作業就會停止運作。
etcd 未提供可靠的內建機制來偵測資料損毀。如果懷疑 etcd 資料已毀損或遺失，請查看 etcd Pod 的記錄。
如果 etcd Pod 處於待處理/錯誤/當機迴圈狀態，不一定表示 etcd 資料已損毀或遺失。這可能是因為主機 etcd Pod 的 VM 發生錯誤。只有在資料毀損或遺失時，才應執行下列 etcd 復原作業。
如要從 etcd 資料毀損或遺失的情況中復原 (還原至最近的叢集狀態)，必須在叢集中的任何生命週期作業 (例如建立、更新或升級) 後備份 etcd 資料。如要備份 etcd 資料，請參閱「備份管理員叢集」和「備份使用者叢集」。
還原 etcd 資料會將叢集恢復至先前的狀態。如果在部署應用程式前進行備份，然後使用該備份還原叢集，最近部署的應用程式就不會在還原的叢集中執行。舉例來說，如果您使用在建立使用者叢集前建立的 etcd 管理員叢集快照，還原後的管理員叢集就會移除使用者叢集控制層。因此，建議您在每次執行重要叢集作業後備份叢集。
在下列情況中，可能會發生 etcd 資料毀損或遺失失敗：
三節點 etcd 叢集 (高可用性使用者叢集) 的單一節點因資料損毀或遺失而永久損壞。在本例中，只有一個節點損壞，且 etcd 仲裁仍存在。如果是在高可用性叢集中，其中一個 etcd 副本的資料毀損或遺失，就可能發生這種情況。只要在乾淨狀態下以新副本取代失敗的 etcd 副本，即可修正問題，且不會遺失任何資料。詳情請參閱「取代失敗的 etcd 備用資源」。
三節點 etcd 叢集 (高可用性使用者叢集) 的兩個節點因資料損毀或遺失而永久損壞。仲裁已遺失，因此即使以新副本取代失敗的 etcd 副本，也無法解決問題。叢集狀態必須從備份資料還原。詳情請參閱「從備份還原使用者叢集 (高可用性)」。
單一節點的 etcd 叢集 (管理員叢集或非高可用性使用者叢集) 因資料損毀或遺失而永久損壞。仲裁已遺失，因此您必須從備份建立新的叢集。詳情請參閱「從備份還原使用者叢集 (非高可用性)」。
從使用者應用程式 PV 毀損或遺失中復原
您可以使用特定合作夥伴儲存空間解決方案，備份及還原使用者應用程式 PersistentVolume。如要查看已通過 Google Distributed Cloud 資格認證的儲存空間合作夥伴清單，請參閱「GDC Ready 儲存空間合作夥伴」。
從負載平衡器故障中復原
如要從套裝組合 Seesaw 負載平衡器故障中復原，可以重新建立負載平衡器。如要重新建立負載平衡器，請將 Seesaw 升級至與 1.16 版文件升級管理員叢集的負載平衡器中顯示的版本相同。
如果管理員叢集的負載平衡器故障，可能無法連線至控制層。在可存取控制層的管理員控制層 VM 上執行升級。
如果是整合式負載平衡器 (F5)，請與 F5 支援團隊聯絡。
如果是套裝組合 MetalLB 負載平衡器，則會使用叢集節點做為負載平衡器。如果負載平衡器發生問題，系統不會觸發自動節點修復功能。你可以按照手動程序修復節點。
後續步驟
如需其他協助，請與 Cloud Customer Care 團隊聯絡。
如要進一步瞭解支援資源，包括下列項目，請參閱「取得支援」：