服務和集群肯定會在Kubernetes上出問題，SRE或運維人員通常會在半夜被要求手動修復。雖然Kubernetes確實提供了一種故障切換機制，但它并不是以這樣一種方式自動化的——在集群或服務出現故障時，服務會立即轉移到副本集群配置，在那里它們會恢復功能。

Buoyant的高級軟件開發人員Alejandro Pedraza在一篇博客中寫道，Linkedr的一項新的自動故障切換功能使Linkedr能夠自動將所有流量從故障或無法訪問的服務重定向到該服務的一個或多個副本，包括其他集群上的副本。“正如你所料，任何重定向的流量都能維持Linkedr對應用程序的安全性、可靠性和透明度的所有保證，甚至可以跨越由開放互聯網分隔的集群邊界。”

其他領先的服務網格提供商也為Kubernetes的故障切換缺陷提供了類似的修復，Istio和HashiCorp提供了類似的修復。

松一口氣

對于Linkedr用戶來說，這種故障功能應該會讓在Kubernetes環境中工作的運維團隊松一口氣。這是因為它不需要運維團隊“在半夜不得不去修復Kubernetes集群，而是通過自動重新路由應用流量而不需要任何代碼更改或重新配置。”企業管理協會（EMA）的分析師Torsten Volk表示。

Linkedr的聯合創始人William Morgan也是Buoyant的首席執行官，他表示，有了Linkedr新的自動故障切換功能，集群運維人員可以在服務級別以一種完全自動化且對應用程序透明的方式配置故障切換。這意味著，如果一個組件出現故障，該組件的所有流量將自動路由到一個復制副本，“應用程序不知道這一點”。

“如果該副本位于不同地區的不同集群中，或者甚至位于不同的云中，Linkedr的雙向TLS實施意味著，即使流量現在正在通過開放互聯網，也能保持完全安全。這是Linkedr用戶長期以來一直要求的。”

就Istio而言，Istio“一段時間以來”一直支持Kubernetes的故障切換自動化，Solo的全球現場首席技術官副總裁Christian Posta說，并用Solo.io Gloo Mesh“自動化了所有配置”——“這主要源于Envoy所具有的位置和優先級感知負載均衡。”

HashiCorp也實現了一段時間的故障切換功能的自動化，這在其文檔中有所描述。

Volk說，Kubernetes的故障切換功能自動化的推動支持了策略驅動應用程序放置的最初概念。通過這種方式，“DevOps團隊不再需要根據應用程序需求精確定義特定的應用程序環境，相反，開發人員可以在應用程序代碼中聲明應用程序需求，然后服務網格匹配這些需求。”

簡單概念

主要問題是Kubernetes在發生故障時不提供自動故障切換功能。Volk說，當Kubernetes上的服務和集群出現故障時，“DevOps團隊通常必須更改應用程序代碼，以特定于底層云基礎設施的方式更改流量路由。這意味著，你需要編寫不同的代碼，將工作負載路由到AWS、Azure、Google Cloud或其他特定平臺上的集群或在這些集群之間。”

實際上，故障切換的概念很簡單。Morgan說：“如果一個組件出現故障，將所有發送到該組件的流量發送到其他地方（通常在另一個集群中）的副本。對于希望使用故障切換來提高應用程序恢復能力的DevOps團隊來說，最大的挑戰之一就是Kubernetes本身沒有提供任何自動化解決方案。因此，你可以跨區域部署應用程序組件的副本，但它們之間的故障切換由你決定。更糟糕的是，如果你希望能夠對單個服務進行故障切換，應用程序需要了解如何在發生故障時向不同的副本發送通信量。這會將應用程序問題與平臺問題混為一談，并導致維護問題。”

Mogan說，Linkerd中的新故障切換功能是在現有Kubernetes和Linkerd功能（如健康探測器和SMI流量拆分）的基礎上構建的，并引入了最少的新機器和配置表面積。“正是這一設計原則，使得Linkeder在很大程度上成為運維最簡單的服務網格。這是我們對用戶承諾的一部分：Kubernetes已經足夠復雜了；服務網格不必如此。”

原文鏈接：

https://thenewstack.io/the-rush-to-fix-the-kubernetes-failover-problem/