資料庫如何在 Kubernetes 上運行？如果可以，哪些類型的資料庫和數據最適合使用 K8s？讓我們一起來看看。 Kubernetes 是用於自動部署、擴展和管理容器化應用程式的一個開源的容器編排解決方案。儘管 Kubernetes 最初是為無狀態應用程式設計的，但隨著有狀態工作負載的日益流行，K ...

資料庫如何在 Kubernetes 上運行？如果可以，哪些類型的資料庫和數據最適合使用 K8s？讓我們一起來看看。

Kubernetes 是用於自動部署、擴展和管理容器化應用程式的一個開源的容器編排解決方案。儘管 Kubernetes 最初是為無狀態應用程式設計的，但隨著有狀態工作負載的日益流行，Kubernetes 也可以於管理有狀態應用程式。

通常情況下，容器是無狀態的，如果容器崩潰或需要重啟，容器中的數據肯定會丟失。作為一個容器編排器，Kubernetes 會保持定期重啟併在節點間移動容器。無論 Kubernetes 對運行應用程式的容器做了什麼，這對於需要保存數據的有狀態工作負載來說都是一個重要的問題。

眾所周知，資料庫伺服器是一個有狀態的應用程式。

那資料庫如何在 Kubernetes 上運行？Kubernetes 是否有機制來管理此類應用程式？如果是這樣，什麼類型的資料庫和數據最適合使用它？

在這篇文章中，我們將找到答案。

運行資料庫的不同方式

以企業中運行資料庫伺服器的不同方式為例分為：

本地自有資料庫：目前許多公司仍然選擇使用虛擬機在本地或雲上托管資料庫伺服器。企業負責設置資料庫伺服器、設置其安全性、安裝補丁、升級、配置存儲、提供高可用性、擴展、備份以及執行其他的資料庫管理員操作。這是手動程度最高的方式，但這種方式可以完全控制資料庫和數據。
雲上托管資料庫：大多數現代企業會選擇 Amazon RDS、Azure 資料庫、谷歌雲資料庫或 Instaclustr 等在雲上部署和擴展資料庫伺服器更容易的解決方案。供應商負責存儲、計算、網路帶寬、安裝、升級和高可用性等。作為消費者的企業只需將資料庫托管在供應商提供的一個實例上，該實例運行你選擇的資料庫引擎（如 SQL 或 NoSQL）。
Kubernetes 托管資料庫：該方式是以上兩種方式的混合體。你可以在本地或雲端運行 Kubernetes 或者使用托管服務。通過這種方法，你可以利用 Kubernetes 的許多優勢，如自動調度、自修複或水平伸縮。但資料庫的使用（如性能調優、備份和恢復）仍需要你註意，並且可能會由於一些容器化特點而略有不同。

持久性存儲和 K8s 的其他特性

儘管開發 Kubernetes 的目的是管理不需要數據持久性的容器化應用程式，但它現在也提供了管理有狀態應用程式的解決方案。持久捲（ Persistent volumes 簡稱 PV）[1] 提供了一個 API，允許 Kubernetes 管理員管理捲[2]，它與更多存儲種類[3] 一起提供了一種安全而抽象的方式來存儲和管理數據。

然而，雲是不可預測的，Kubernetes 經常需要重啟和重新構建 pods。因此，持久捲很難在節點間移動數據，並同時確保它們連接到正確的容器。更複雜的是，一些資料庫需要運行在多節點集群配置中。

Kubernetes 1.5 版本[4] 中引入了一些設計來幫助解決這些問題。StatefulSets[5] 確保 pods 基於相同的容器規範，即使它們被移動到另一個節點也保持唯一的 ID。通過唯一 ID 將 pods 與持久捲耦合起來，即使在重新調度它們時，也可以維護工作負載的狀態。DaemonSets[6] 雖然稍微複雜一些，但也是在集群的每個節點上運行工作副本的一種方式。

分散式有狀態工作負載通常需要一系列預定義資源無法處理的複雜操作。例如，分散式資料庫可能需要在資料庫節點（在 Kubernetes 中，是一個 pod）出現故障時執行一組特定的操作。這類操作的例子可以是選舉領導者、平衡數據等等。

原生 Kubernetes 功能無法真正處理這些情況，但其自定義資源（Custom resources）[7] 可以提供幫助。 Custom resources 允許 Kubernetes API 使用領域特定的邏輯進行擴展，定義新的資源類型和控制器[8]。Operator 模式[9] 通過幫助開發自定義解決方案，利用自定義資源來管理應用程式及其組件。

OSS 框架，如 kubebuilder[10]，或 Operator Framework[11]，提供了構建塊來創建 Operator，如 Postgres Operator[12]、MySQL Operator for Kubernetes[13], Elastic Cloud on Kubernetes (ECK)[14]，或 K8ssandra[15]。

分散式資料庫的特性

大多數資料庫引擎都提供了一種或多種方式來分發數據並使其具有高可用性。當選擇要在 Kubernetes 上運行資料庫時，你需要考慮以下特性：

複製：資料庫是否支持複製？如果支持，它支持什麼類型的複製（如：雙向複製、事務複製和快照）？這將有助於提高可靠性、容錯性和可訪問性。
分片：資料庫是否能夠對數據進行分區，併在不同的實例（即 pod）中保存不同的片段？這可以幫助優化冗餘和分散負載。
故障轉移：資料庫是否能夠從主節點、讀寫節點切換到其他只讀節點並將只讀節點提升為主節點？這也將有助於提高可靠性、容錯性和可訪問性。
可伸縮性：資料庫是否具備可伸縮性（向內擴展和向外擴展）？Kubernetes 為水平擴展鋪平了道路，但是資料庫需要根據需要添加或刪除實例。這可以幫助處理增加的負載或在負載下降時降低成本。
具有這些特性的資料庫（例如：MySQL、PostgreSQL、ClickHouse、Elasticsearch、MongoDB 或 Cassandra 等）可以更輕鬆地應對異構雲環境的不確定性。

數據可用性的考慮

由於 pod 和計算節點在本質上通常是臨時的，因此，Kubernetes 更適合於某些類型的數據。重要的是要瞭解數據的重要性，以及它必須在多大程度上可用。

為了實現高可用性，一些資料庫引擎使用所謂的最終一致性模型。最終一致性是一種技術，它確保如果給定的數據塊沒有新的更新，所有對它的訪問都將返回最後更新的值。它假設，在任何時間點，不同節點的數據可能存在一些不一致（取決於從哪裡讀取它），因為它正在不斷更新，但是一旦更新完成，所有節點都將擁有它的相同副本，並且所有客戶端請求都將獲得相同的數據。當你在 Kubernetes 中運行資料庫系統時，需要從業務角度來看這是否可接受。

一些資料庫引擎可以處理故障轉移（例如，當運行數據的主副本的 pod 重新調度或崩潰時），但備用節點恢復並承擔主要節點角色可能需要一些時間。你需要考慮在這種情況下，可以承受多少數據不可用，以及是否可以接受使用舊數據。

如你所見，這完全取決於業務需求。處理瞬態數據（如緩存層）、只讀數據（如查找表）或可輕鬆重建的數據（如 API 輸出）的工作負載時，很顯然更適合在 Kubernetes 上。

總結

作為一種容器編排技術，Kubernetes 簡化了許多常見的操作問題，例如調度、自動擴展或故障轉移。雖然它非常適用於無狀態工作負載，但有狀態工作負載（如資料庫）還有其他需要解決的問題。我們已經看到：

持久捲和存儲類提供了一種安全而抽象的方式來管理數據；
通過允許將 pod 與持久數據綁定，可以在這些概念的基礎上構建 StatefulSet 和 DaemonSet；
自定義資源和 Operator 可以幫助為需要數據持久性的應用程式提供自定義邏輯。
但是，重要的是要考慮對要在 Kubernetes 上運行的資料庫引擎的可用支持，以及要存儲的數據類型和數據的可用性要求。在 Kubernetes 中運行服務需要應對一定程度的波動性。

因此，Kubernetes 上更適合部署可以處理複製、分片和故障轉移的資料庫。同樣，Kubernetes 托管的理想數據是可以輕鬆快速重新生成的數據。歸根結底，這將取決於業務需要的容錯能力。