Google Distributed Cloud 的設計宗旨是限制故障範圍，並優先處理對業務持續性至關重要的功能。本文說明叢集發生故障時，叢集功能會受到哪些影響。這項資訊有助於判斷問題的優先順序，並找出需要排解的區域。
Google Distributed Cloud 的核心功能包括下列類別：
- 執行工作負載：現有工作負載可繼續執行。這是維持業務連續性的最重要考量。即使叢集發生問題，現有工作負載仍可繼續執行，不會中斷。
- 管理工作負載：您可以建立、更新及刪除工作負載。這是流量增加時，擴充工作負載的第二重要考量，即使叢集發生問題也一樣。
- 管理使用者叢集：您可以管理節點、更新、升級及刪除使用者叢集。這項考量的重要性不如應用程式生命週期。如果現有節點有可用容量，無法修改使用者叢集就不會影響使用者工作負載。
- 管理管理員叢集：您可以更新及升級管理員叢集。
- 如果部署作業使用個別的管理員和使用者叢集，這項考量因素的重要性最低，因為管理員叢集不會代管任何使用者工作負載。如果管理員叢集發生問題，其他叢集上的應用程式工作負載仍會繼續運作，不會中斷。
- 如果您使用其他部署模型 (例如混合式或獨立式)，管理員叢集會執行應用程式工作負載。如果管理員叢集發生問題，且控制層停止運作，您也無法管理應用程式工作負載或使用者叢集元件。
以下各節將使用這些核心功能類別，說明特定類型的失敗情境會造成哪些影響。如果中斷是失敗情境的一部分，系統也會盡可能記錄中斷的持續時間 (順序)。
節點故障
Google Distributed Cloud 中的節點可能會停止運作，或無法在網路上連線。視發生故障的機器所屬的節點集區和叢集而定，有幾種不同的故障模式。
控制層節點
下表列出 Google Distributed Cloud 中屬於控制平面的節點行為：
| 執行工作負載 | 管理工作負載 | 管理使用者叢集 | 管理管理員叢集 | |
|---|---|---|---|---|
| 中斷 (時間長度) | 不會中斷 | 可能中斷 (不明) | 可能中斷 (不明) | 可能中斷 (不明) |
| 說明 | — | 如果節點故障影響非高可用性 (HA) 使用者叢集中的單一控制層節點，或是影響高可用性使用者叢集中至少一半的控制層節點，就會發生中斷。使用者叢集的控制層仲裁機制已失效。 | 如果節點故障影響非高可用性管理員叢集中的單一控制層節點，或影響高可用性管理員叢集中至少一半的控制層節點，就會發生中斷。管理員叢集的控制層仲裁已遺失。 | 如果節點故障影響非高可用性管理員叢集中的單一控制層節點，或影響高可用性管理員叢集中至少一半的控制層節點，就會發生中斷。管理員叢集的控制層仲裁已遺失。 |
| 復原 | — | 詳情請參閱「如何從仲裁權喪失中復原」。 | 詳情請參閱「如何從仲裁節點遺失中復原」。 | 詳情請參閱「如何從仲裁節點遺失中復原」。 |
| 預防措施 | — | 以高可用性模式部署使用者叢集，盡量避免中斷。 | 以高可用性模式部署管理員叢集，盡可能減少中斷情況。 | 以高可用性模式部署管理員叢集，盡可能減少中斷情況。 |
負載平衡器節點
下表列出在 Google Distributed Cloud 中，主機負載平衡器的節點行為。這項指引僅適用於採用第 2 層模式的組合式負載平衡器。如要進行手動負載平衡，請參閱外部負載平衡器的故障模式：
| 執行工作負載 | 管理工作負載 | 管理使用者叢集 | 管理管理員叢集 | |
|---|---|---|---|---|
| 中斷 (時間長度) | 可能中斷 (視情況而定) | 可能中斷 (視情況而定) | 可能中斷 (視情況而定) | 可能中斷 (視情況而定) |
| 說明 | 如果外部工作負載依賴資料平面負載平衡器與叢集中的工作負載通訊，且您只有一個負載平衡器節點，就會發生中斷。 | 使用者叢集的控制層虛擬 IP 位址位於其中一個負載平衡器節點上。如果使用者叢集的負載平衡器節點集不是高可用性，就會發生中斷。 | 管理員叢集的控制層虛擬 IP 位址位於其中一個負載平衡器節點。如果管理員叢集的負載平衡器節點集不是高可用性，就會發生中斷。 | 管理員叢集的控制層虛擬 IP 位址位於其中一個負載平衡器節點上。如果管理員叢集的負載平衡器節點集不是高可用性，就會發生中斷。 |
| 復原 | 如果有多個負載平衡器節點，MetalLB 會在幾秒內完成容錯移轉。 如果不是 HA，請考慮部署其他負載平衡器節點。 |
如果是高可用性，系統會自動容錯移轉，時間約為幾秒。 如果不是高可用性，請考慮部署額外的負載平衡器節點 |
如果是高可用性，系統會自動容錯移轉，時間約為幾秒。 如果不是 HA，請考慮部署其他負載平衡器節點。 |
如果是高可用性，系統會自動容錯移轉，時間約為幾秒。 如果不是 HA，請考慮部署其他負載平衡器節點。 |
| 預防措施 | 如要盡量避免中斷，請以高可用性模式部署負載平衡器節點集區。 | 如要盡量避免中斷，請以高可用性模式部署負載平衡器節點集區。 | 如要盡量避免中斷，請以高可用性模式部署負載平衡器節點集區。 | 如要盡量避免中斷，請以高可用性模式部署負載平衡器節點集區。 |
工作站節點
下表列出 Google Distributed Cloud 中工作節點的行為：
| 執行工作負載 | 管理工作負載 | 管理使用者叢集 | 管理管理員叢集 | |
|---|---|---|---|---|
| 中斷 (時間長度) | 可能發生中斷 (秒級) | 不會中斷 | 不會中斷 | 不會中斷 |
| 說明 | 在發生故障的節點上執行的 如果使用者應用程式有備用工作負載容量，且分散在多個節點中，實作重試的用戶端就不會觀察到中斷情形。 系統會在健康狀態良好的節點上自動重新啟動 |
— | — | — |
| 復原 | 如果叢集沒有備用容量，您必須部署更多節點，並將這些節點分散到多個故障區域，然後將失敗的工作負載移至新節點。 | — | — | — |
| 預防措施 | 部署分散在多個故障區域的節點。 將工作負載部署至多個容錯區域，並分散多個副本，盡量減少中斷的可能性。 |
— | — | — |
儲存空間故障
Google Distributed Cloud 中的儲存空間可能會停止運作，或無法透過網路存取。視故障的儲存空間而定，有幾種不同的故障模式。
etcd
如果節點非正常關機或儲存空間發生基礎故障，/var/lib/etcd和 /var/lib/etcd-events 目錄的內容可能會損毀。下表列出因 etcd 失敗而導致核心功能出現的行為：
| 執行工作負載 | 管理工作負載 | 管理使用者叢集 | 管理管理員叢集 | |
|---|---|---|---|---|
| 中斷 (時間長度) | 不會中斷 | 可能中斷 (不明) | 可能中斷 (不明) | 可能中斷 (不明) |
| 說明 | 如果現有工作負載不依賴 Kubernetes 控制層，就能繼續運作，不會中斷。 | 如果單一控制層使用者叢集上的 etcd 失敗，或高可用性使用者叢集上至少一半的控制層節點失敗，就會發生中斷情形。使用者叢集的控制層仲裁機制已失效。 |
如果單一控制層管理員叢集上的 etcd 失敗，或高可用性管理員叢集上至少一半的控制層節點失敗，就會發生中斷。管理員叢集的控制層仲裁已遺失。 |
如果單一控制層管理員叢集上的 etcd 失敗，或高可用性管理員叢集上至少一半的控制層節點失敗，就會發生中斷。管理員叢集的控制層仲裁已遺失。 |
| 復原 | — | 詳情請參閱「如何從仲裁權喪失中復原」。 | 詳情請參閱「如何從仲裁權喪失中復原」。 | 詳情請參閱「如何從仲裁權喪失中復原」。 |
| 預防措施 | — | 為盡量避免中斷，請以高可用性模式部署使用者叢集。 | 如要盡量避免中斷，請以高可用性模式部署管理員叢集。 | 如要盡量避免中斷，請以高可用性模式部署管理員叢集。 |
使用者應用程式 PersistentVolume
下表列出因 PersistentVolume 失敗而導致的核心功能行為：
| 執行工作負載 | 管理工作負載 | 管理使用者叢集 | 管理管理員叢集 | |
|---|---|---|---|---|
| 中斷 (時間長度) | 可能中斷 (不明) | 不會中斷 | 不會中斷 | 不會中斷 |
| 說明 | 使用失敗 PersistentVolume 的工作負載 |
— | — | — |
| 復原 | — | — | — | — |
| 預防措施 | 如要盡量避免中斷，請以高可用性模式部署使用者工作負載。 | — | — | — |
Fluent Bit 磁碟損毀
Fluent Bit 磁碟損毀不會影響任何核心功能，但會影響在 Google Cloud上收集及檢查記錄的能力。
有時可從 stackdriver-log-forwarder 的記錄檔中觀察到 SIGSEGV 事件。這個錯誤可能是因為磁碟上緩衝的記錄檔已損毀。
Fluent Bit 具有篩除及捨棄損毀區塊的機制。這項功能適用於 Google Distributed Cloud 使用的 fluent-bit 版本 (v1.8.3)。
超出 LoadBalancer 個 IP
如果指派集區中的所有 IP 位址目前都已占用，新建立的 LoadBalancer 服務就無法取得 LoadBalancer IP 位址。這個情境會影響服務用戶端與 LoadBalancer 服務通訊的能力。
如要從 IP 位址耗盡的情況中復原，請修改叢集自訂資源，將更多 IP 位址指派給位址集區。
憑證到期
Google Distributed Cloud 會在叢集安裝程序中，產生自行簽署的憑證授權單位 (CA)。CA 的有效期限為 10 年，負責產生憑證，憑證的有效期限為一年。定期輪替憑證，避免叢集停機。您可以升級叢集來輪替憑證，這是建議的方法。如果無法升級叢集，可以視需要輪替 CA。如要進一步瞭解叢集憑證，請參閱 Kubernetes 說明文件中的「PKI certificates and requirements」。
如果叢集憑證已過期，必須手動續約。
| 執行工作負載 | 管理工作負載 | 管理使用者叢集 | 管理管理員叢集 | |
|---|---|---|---|---|
| 中斷 (時間長度) | 不受干擾 | 可能中斷 (不明) | 可能中斷 (不明) | 可能中斷 (不明) |
| 說明 | 如果使用者工作負載未與 Kubernetes 控制層元件通訊，就不會發生中斷情形。 | 如果使用者叢集的憑證授權單位過期，就會發生中斷。 | 如果管理員叢集的憑證授權單位過期，就會發生中斷情形。 | 如果使用者叢集的憑證授權單位過期，就會發生中斷。 |
| 復原 | — | 請按照步驟在使用者叢集上手動更新憑證。 |
請按照步驟在使用者叢集上手動更新憑證。 |
請按照步驟在使用者叢集上手動更新憑證。 |
| 預防措施 | 設定憑證到期監控。您可以在指標清單中找到指標 kubelet_certificate_manager_server_expiration_seconds 的範例。 |
|||
升級失敗
| 執行工作負載 | 管理工作負載 | 管理使用者叢集 | 管理管理員叢集 | |
|---|---|---|---|---|
| 中斷 (時間長度) | 不受干擾 | 不受干擾 | 可能中斷 (不明) | 可能中斷 (不明) |
| 說明 | 如果使用者叢集控制層升級失敗，現有工作負載不會受到影響。 如果特定工作站節點升級失敗，該節點上的工作負載就會清空，並移至其他健康狀態良好的節點 (如果健康狀態良好的節點有額外容量)。 |
如果任何控制層節點無法升級，升級作業就會停止。如果使用者叢集是高可用性叢集，即使升級失敗，叢集仍可正常運作。 | 如果管理員叢集控制層升級失敗，升級完成前會發生中斷。 | 如果管理員叢集控制層升級失敗，升級完成前會發生中斷。 |
| 復原 | — | — | 升級作業可以重試。詳情請參閱如何診斷升級問題並繼續升級。 | 升級作業可以重試。詳情請參閱如何診斷升級問題並繼續升級。 |
| 預防措施 | — | — | 詳情請參閱這篇文章，瞭解如何先建立備份再升級。 | 詳情請參閱這篇文章，瞭解如何在升級前建立備份。 |
後續步驟
如要進一步瞭解已知的產品問題和解決方法，請參閱「Google Distributed Cloud 已知問題」。
如需其他協助，請與 Cloud Customer Care 團隊聯絡。如要進一步瞭解支援資源，包括下列項目，請參閱「取得支援」：