文章目錄

 

一、在Kubernetes上能否部署資料庫？

作為雲原生時代的技術底座，K8s現在已經成為容器編排的事實標準，而且越來越多的工作負載，包括交易事務、音視訊流媒體處理、通訊系統、人工智慧等等都開始使用K8s。因此，K8s又被稱為雲端的“Linux作業系統“。那麼，對於每個企業應用幾乎都離不開的資料庫而言，其是否可以部署到K8S上了嗎？

1、資料庫能不能部署到K8s？

在最開始K8s 1.0時代，k8s是為無狀態應用設計的。無狀態應用可以被重啟和重新排程，或者快速的擴展出多個副本例項。雖然說這個時候也可以在k8s中執行容器化的資料庫例項，但這個階段k8s對資料庫是不友好的。

隨著K8s 1.5版本開始支援StatefulSet，有狀態應用正式成為了k8s的一等公民，通過持久卷（Persistent Volume）可以解決資料庫的資料永續性問題。尤其是到K8s 1.10有了CSI之後，企業也可以使用效能更高、可靠性更好的外接儲存了，當資料庫Pod被排程到其它節點重啟的時候，共享的持久卷可以在新的節點上重新掛載給資料庫Pod。這些解決了資料庫的資料安全性和可用性的基礎設施問題，但k8s本身並不理解每個資料庫的運維的邏輯，因此資料庫的運維部分仍然有很多地方需要人工來處理，比如資料庫狀態的監控、主/從資料庫的切換、資料備份等。

讓資料庫能真正在k8s上變得好用的是Operator（Operator 模型基於 Kubernetes 中的兩個概念結合而成：自定義資源和自定義控制器）的出現。Operator使得資料庫廠商和第三方可以去擴充套件K8s API，將資料庫運維的能力由Operator來實現。這大幅簡化了在k8s中運維和管理資料庫，把K8s變成一個優質的資料庫執行平臺。

2、資料庫部署到容器的好處

• 據庫的安裝、配置和維護更簡單
  資料庫部署到容器，哪怕進行一個複雜的主從關係型資料庫安裝，都可以通過一個YAML檔案輕鬆搞定，後續不管是給資料庫例項增加資源，或者增加例項，都非常簡單。K8s還可以大幅簡化資料庫升級和打補丁的操作。

• 跨多雲的部署相容性更好
  對於需要在多雲環境中進行部署的系統，或者需要經常切換部署環境場景的，託管的資料庫服務基本不可行，而物理部署資料庫又太複雜，在容器中進行資料庫部署就變得非常有優勢。因為目前幾乎所有公有云和私有云的K8s都具有高度的相容性，在容器中進行資料庫部署可以提供高度的可移植性和跨平臺可管理性。

• 應用和資料庫可以統一在一個K8s平臺上運維，不需要分開部署運維。
  對於完成同一業務目的的應用系統而言，應用本身和資料庫可以同時在K8s上進行部署和運維。相對於混合部署的方式而言，同一個平臺可以減少基礎架構的複雜性，以及所需要的人員技能，從而降低成本。

• 快速進行大量的資料庫例項的部署
  對於多租戶的SaaS服務，或者大規模並行測試等這類需要同時提供大量資料庫例項的場景，在容器中部署資料庫不僅僅讓整個過程更加簡單，而且資源的利用率更高，通過名稱空間也可以提供提供網路和執行例項的更好的隔離性。

3、資料庫上容器的現狀

目前主流的開源資料庫都已經有了K8s支援，並提供了相應的Operator來方便資料庫在k8s上的運維，包括MySQL、PostgreSQL、MongoDB等，以及國產的部分資料庫。

傳統的大型商業化資料庫現在也提供了K8s支援，包括微軟的SQL Server，IBM的DB2和Oracle。

二、在 Kubernetes 上部署資料庫

如今，越來越多的應用部署在 Kubernetes 上的容器中，儘管在應用層（application layer）的容器化有了大量增長，但資料層（data layer）在容器化方面得到的關注並不多。

處理資料庫的可持久化、對應用程式其他層的高可用性和資料庫的冗餘等方面，有非常具體的要求。這就使得資料庫在分散式環境中執行起來很有挑戰性。

然而，資料層得到更多關注，是因為很多開發者想要像處理應用層技術棧一樣處理資料層基礎架構。運維人員希望使用同樣的工具來運維資料庫和應用程式，而且資料層和應用層能達到相同的收益，跨不同環境的快速啟動和可重複自動完成。

1、 Google Cloud 平臺上執行資料庫的選項

在探討 Kubernetes 上執行資料庫的注意事項之前，先了解下 Google Cloud 平臺（GCP）上執行資料庫都有哪些選項，以及這些資料庫的最佳用法。

• 完全託管的資料庫
  包括 Cloud Spanner、Cloud Bigtable 和 Cloud SQL 等。這些都是低運維成本的選擇，因為 Google Cloud 會承擔很多日常維護的工作，如備份、補丁和擴充套件等。開發者或運維人員無需人為干預，只要建立一個數據庫，構建自己的 APP，然後交給 Google Cloud 進行擴充套件。但這也意味著你可能無法使用到自己想要的資料庫版本、擴充套件或某種型別的資料庫。

• 在虛擬機器上自行操作的資料庫
  也可稱為“全運維選項”，構建資料庫、擴充套件資料庫、管理可靠性、配置備份等通通需要自行設定。這雖然工程量巨大，但所有的功能和資料庫型別的選擇都在自己的掌握之中。

• 在 Kubernetes 上執行的資料庫
  在 Kubernetes 上執行資料庫更接近於全運維選項，但是可以從 Kubernetes 提供的自動化功能中，享受一些好處，以支援資料庫應用程式的執行。話雖如此，但需要記住的是，Pods 也就是資料庫應用容器是瞬時性的，所以資料庫應用重啟或故障切換的可能性較大。此外，由於容器化後增加了抽象功能，一些資料庫管理任務，如備份、縮放、調優等，都是不一樣的。

2、在 Kubernetes 上執行資料庫的技巧

如果選擇走 Kubernetes 路線，你需要思考執行哪些資料庫，由於 Pods 至關重要，因此發生故障轉移事件的可能性，比傳統部署或完全託管的資料庫要高。如果這個資料庫內建支援分片（sharding）、故障選舉（failover election）和複製等設計，那麼在 Kubernetes 上執行會更簡單。一些開源專案提供自定義資源和控制器，來幫助管理容器化的資料庫。

接下來，考慮資料庫在應用和業務的上下游中起到的作用。儲存更多臨時的和快取層的資料庫更適合 Kubernetes。這種型別的資料層通常在應用中更有彈性，整體體驗更好。

最後，確保你瞭解資料庫中可用的複製模式。非同步傳輸模式可能會出現資料丟失，因為資料庫事務（transaction）可能會被提交到主要資料庫，而不會提交到次要資料庫。因此，一定要明確是否會產生資料丟失，以及在自己的應用程式中，有多少資料丟失是可以接受的。

在評估了以上這些方面後，你最終會得到一個類似於下圖這樣的決策樹：

3、如何在 Kubernetes 上部署資料庫？

現在，深入瞭解一下如何使用 StatefulSets 在 Kubernetes 上部署資料庫。藉助 StatefulSet，你的資料可以儲存在 Persistent Volume 上，將資料庫應用程式與持久化儲存解耦，因此當重新建立一個 Pod（如資料庫應用程式）時，所有的資料依然存在。此外，當在 StatefulSet 中重新建立一個 Pod 時，它將保持相同的名稱，所以你會有一個一致的端點來連線。持久資料和一致的命名是 StatefulSets 最大的兩個特點（參考 Kubernetes 文件）。

如果你要執行一個不完全適合 Kubernetes 承載的資料庫型別，可以考慮使用 Kubernetes Operators 或包含其他改進特性的資料庫專案，使得資料庫適合容器化環境執行。Operator 會幫助你啟動這些資料庫，並執行資料庫維護任務，如備份和複製。

Operator 藉助自定義資源和控制器，通過 Kubernetes API 來暴露特定操作。還有一些其圍繞著各自的資料庫構建了許多工具，從而可以在 Kubernetes 內部進行操作。可能包括的補充功能有分片、主從選舉以及故障轉移功能，這些功能都是在 Kubernetes 中成功部署 MySQL 或 PostgreSQL 等資料庫所需的。

三、雲原生資料庫執行之Kubernetes的設計原則

長期以來，我們一直在談論將工作負載遷移到雲中，但是對許多IT組織的應用程式組合的觀察表明，仍有許多工作要做。在許多情況下，儘管雲中的資料庫已經用了多年，但在雲中持久儲存和移動資料的挑戰仍然是阻礙雲採用的主要限制因素。

有一個有趣的問題：必須將在Kubernetes上執行的資料庫視為雲原生資料庫嗎? 雖然Kubernetes最初是為無狀態工作負載設計的，但Kubernetes的最新改進(例如StatefulSets和持久卷)也使執行有狀態工作負載成為可能。

但是，勉強接受在Kubernetes上執行資料庫並不是我們的目標。為了使資料庫成為最“雲原生”的資料庫，我們需要包含Kubernetes必須提供的所有內容。雲原生資料庫必須是可以在Kubernetes上有效執行的資料庫。

下面是Kubernetes設計原則：

• 原則1：將計算、網路和儲存作為商業API
  雲端計算成功的關鍵之一是計算，網路和儲存的商業化，這是我們可以通過簡單的API進行配置的資源。考慮以下AWS服務樣本：
  ·計算：我們通過EC2和自動伸縮組(ASG)分配虛擬機器
  ·網路：我們使用ElasticLoadBalancer(ELB)，Route53和VPC對等管理流量
  ·儲存：我們使用諸如簡單儲存服務(S3)進行長期物件儲存或彈性塊儲存(EBS)卷之類的選項來持久化資料。
  Kubernetes提供了自己的API來為世界範圍內的容器化應用程式提供類似的服務：
  ·計算：容器，部署和副本集管理計算硬體上容器的排程和生命週期
  ·網路：服務和入口公開了容器的網路介面
  ·儲存：永續性卷和有狀態集可實現容器與儲存的靈活關聯
  Kubernetes資源促進了Kubernetes發行版和服務提供商之間應用程式的可移植性。這對資料庫意味著什麼? 它們只是利用計算，網路和儲存資源來提供資料永續性和檢索服務的應用程式：
  ·計算：資料庫需要足夠的處理能力來處理傳入的資料和查詢。每個資料庫節點均作為Pod部署並分組在StatefulSets中，從而使Kubernetes能夠管理橫向擴充套件和橫向擴充套件。
  ·網路：資料庫需要公開用於資料和控制的介面。我們可以使用KubernetesServices和IngressControllers公開這些介面。
  ·儲存：資料庫使用指定儲存類的持久捲來儲存和檢索資料。

從資料庫的計算，網路和儲存需求的角度考慮，消除了在Kubernetes上部署所涉及的許多複雜性。

• 原則2：將控制平面和資料平面分開
  Kubernetes促進了控制平面和資料平面的分離。Kubernetes API伺服器是用於請求計算資源的關鍵資料平面介面，而控制平面則管理將這些請求對映到基礎IaaS平臺的細節。

• 原則3：簡化可觀察性
  可觀察系統的三大支柱是日誌記錄，指標和跟蹤。通過將每個容器的日誌暴露給第三方日誌聚合解決方案，Kubernetes提供了一個很好的起點。度量和跟蹤需要花費更多的精力來實現，但是有多種解決方案可用。

• 原則4：確保預設配置安全
  Kubernetes網路預設是安全的：必須顯式公開端口才能從外部訪問Pod。這為資料庫部署樹立了有用的先例，迫使我們仔細考慮如何公開每個控制平面和資料平面介面，以及應該通過KubernetesService公開哪些介面。

• 原則5：首選宣告式配置
  在Kubernetes宣告性方法中，您可以指定所需的資源狀態，並且控制器可以操縱底層基礎結構以實現該狀態。Cass-operator允許您指定叢集中所需的節點數，並管理放置新節點以按比例放大以及選擇要刪除的節點以按比例縮小的詳細資訊。

以上是參考並整理的Kubernetes（K8S）與資料庫的“故事”，歡迎閱讀！覺得不錯的話來個三連支援下博主吧~