資料庫如何在 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 托管的理想資料是可以輕松快速重新生成的資料，歸根結底，這將取決于業務需要的容錯能力，

原文：https://www.containiq.com/post/should-you-run-a-database-on-kubernetes

參考鏈接

1.持久卷：https://www.containiq.com/post/kubernetes-persistent-volumes

2.卷：https://kubernetes.io/docs/concepts/storage/volumes/

3.存盤種類：https://kubernetes.io/docs/concepts/storage/storage-classes/

4.Kubernetes 1.5：https://kubernetes.io/blog/2016/12/kubernetes-1-5-supporting-production-workloads/

5.StatefulSets：https://www.containiq.com/post/kubernetes-statefulsets

6.DaemonSets：https://www.containiq.com/post/using-kubernetes-daemonsets-effectively

7.自定義資源：https://www.containiq.com/post/kubernetes-crds-custom-resource-definitions

8.控制器：https://www.containiq.com/post/kubernetes-controllers

9.Operator 模式：https://kubernetes.io/docs/concepts/extend-kubernetes/operator/

10.kubebuilder：https://github.com/kubernetes-sigs/kubebuilder

11.Operator Framework：https://operatorframework.io/

12.Postgres Operator：https://github.com/zalando/postgres-operator

13.MySQL Operator：https://github.com/mysql/mysql-operator

14.Elastic Cloud on Kubernetes：https://github.com/elastic/cloud-on-k8s

15.K8ssandra：https://k8ssandra.io/

標籤：其他

上一篇：翻譯 | Kubernetes Operator 對資料庫的重要性

下一篇：翻譯 | Kubernetes Operator 對資料庫的重要性