如何確保有狀態 Kubernetes 的穩定性

Kubernetes 是公有云中應用程式部署的事實標準。然而，隨著企業將更多的工作負載遷移到 K8s，經常遇到應用程式穩定性的的問題。

在業務連續的場景中，在不同區域及雲廠商的不同叢集上恢復具有相同配置的應用程式可能相對容易，但應用程式需要資料才能執行，恢復一個應用程式的狀態是非常複雜的。

試圖為 K8s 的有狀態應用程式構建高可用性環境以履行其服務水平協議(SLA)並維護應用程式和資料可用性的企業面臨著以下挑戰。

複雜性

使用 Kubernetes 的主要問題之一是難以為有狀態應用程式設定儲存，同時保持彈性和應用程式移動性。公有云中的標準解決方案還有待改進，任何超出標準解決方案的東西都需要大量的專業知識來設定和維護。因此，通往有狀態、有彈性的運營之路還很漫長。它需要儲存、網路和遷移方面的知識。許多團隊缺乏做這件事的資金、人力或專業知識。

困難在於，構建儲存基礎設施所需的技能與大多數 DevOps 專業人員受過培訓的技能有很大不同。大多數雲原生團隊缺乏儲存專家的專業知識，他們接受過配置和維護專門的儲存網路和裝置的培訓，以確保所有的儲存都是可用的、有彈性的和有備份——前提是可以訪問公有云中的高階儲存解決方案的話。

供應商選擇受限

由於儲存和基礎設施來自特定的供應商(EBS、Azure Disk 等)，供應商選擇受限和資料重力問題是不可避免的。資料重力(即某個位置的資料量)越大，未來就越難轉移到其他地方。應用程式不斷被拉到資料所在的位置，而過去的資料儲存選擇決定了其未來的位置。

當資料轉移到公有云時，服務提供商不可避免地會影響應用程式的效能。

彈性挑戰

說到彈性，僅僅依靠單一的雲提供商有很大的侷限性。然而，由於為有狀態的應用程式建立跨區域或多雲基礎設施過於複雜，大多陣列織除了依賴單一的雲提供商或區域之外，別無選擇。

即使在不同的可用性區域之間遷移資料，仍然存在區域故障的風險。因此，為了給執行在雲中的有狀態應用程式提供業務連續性，需要能夠立即在第二站點或區域進行恢復，才能不丟失任何資料。

風險

風險是不可避免的。但是，當你的穩定性計劃只是在 AWS 或谷歌雲(統計學上故障最少)上執行你的業務時，就有麻煩了。

臃腫的基礎設施

此外，由於資料沒有其應用就一文不值，為了讓有狀態的 K8s 應用在不同的基礎設施和公有云廠商之間恢復，整個應用環境包括應用狀態必須被複制，並且完全不受應用所執行的底層基礎設施的影響。

隨著時間的推移，這些基礎設施變得越來越臃腫。對於一個拼命嘗試維持穩定的團隊來說，需要額外的變通方法的操作，就變得難以忍受了。

解決公有云彈性之謎

隨著複雜性的增加，對更復雜的彈性、效能和操作技術的需求也在增加，這就需要有一種方法讓複雜的事情變簡單。

為了解決這些問題，出現了一個新的類別。Stateful application mobility platforms. 這些平臺允許使用者配置有狀態的應用程式，而不用擔心它們是如何配置或部署的，允許有狀態的應用繼續不間斷地執行，並能夠在另一個位置恢復，而不會出現資料丟失。使用者可以放心，他們的叢集可以在雲廠商、區域和資料中心之間移動。

這將帶來更大的靈活性、更高的效能和更好的彈性，最終，透過允許有狀態的應用在不同地點之間自由移動來簡化它們的執行位置，使企業能夠利用“雲”的能力，同時避免其侷限性。

透過使用這些平臺，無論應用程式部署在哪裡，資料都是可用的。

這個多雲一鍵部署的可伸縮的儲存解決方案，實現了有狀態的 Kubernetes 的穩定性。