圖片

你是否曾聽說過避免在Kubernetes中運行數據庫的建議？有人認為Kubernetes不適合有狀態的應用程序，但這些說法是否屬實？讓我們深入探討并挑戰這些說法。

Kubernetes：有關有狀態工作負載的誤解平臺

在涉及有狀態應用程序時，Kubernetes經常受到不公平的抨擊。這種誤解源自早期階段，當時我們的選擇局限于部署（Deployments）和有狀態集（StatefulSets）。最初認為有狀態集應該是數據庫的首選。然而，這忽略了Kubernetes的真實本質——一種設計用于定制化的可擴展平臺。

網絡和存儲是Kubernetes的典型例子。我們并不依賴內置功能，而是通過CNI和CSI插件增強功能以適應我們特定的需求。這個原則也適用于數據庫，盡管由于缺乏標準的數據庫接口，這條路并不那么直接。

有狀態集的困境

最初，早期采用者使用有狀態集在Kubernetes上運行數據庫。它們提供了一定程度的秩序——可預測的擴展性、穩定的網絡標識符和持久化存儲。然而，僅有有狀態集是不足以在生產環境中管理數據庫的，生產環境需要備份、故障轉移、可觀察性等更多功能。

自定義資源定義

對于Kubernetes中的數據庫來說，真正改變游戲規則的是自定義資源定義（CRDs）和自定義控制器，也稱為運算符（operators）。這些Kubernetes擴展允許創建具有自定義邏輯和生命周期管理的復雜有狀態應用程序。換句話說，它們賦予了Kubernetes智能、高效地處理數據庫的能力。這種方法將Kubernetes的功能擴展到了遠遠超出其核心功能的領域，使其能夠滿足數據庫管理的復雜需求。

使用Cloud Native PG運行PostgreSQL

為了說明問題，讓我們探討一下使用Cloud Native PG項目在Kubernetes上運行PostgreSQL。CloudNativePG的設計允許在多個區域擴展PostgreSQL架構，提供了一個強大的災難恢復框架，RPO（恢復點目標）極小。使用Cloud Native PG，你不僅僅是通過有狀態集來管理Pods；你正在利用一個專用控制器，它封裝了數據庫管理的一系列擴展職責。該項目體現了Kubernetes作為基礎平臺到成為一個完全成熟的運行數據庫的強大平臺的轉變。它支持從高可用設置到備份、擴展和配置管理的所有內容，都是通過CRDs進行聲明性定義。

Cloud Native PG的架構

高可用性和流復制

在核心層，CNPG同時支持異步和同步流復制。它允許配置一個主實例，以及多個熱備份副本以實現同一Kubernetes集群內的高可用性。服務可供應用程序連接到主實例（**-rw**）、熱備份副本（**-ro**）或任何實例進行只讀工作負載（**-r**）。

共享無

CNPG推薦采用共享無體系結構以增強韌性。這意味著PostgreSQL實例位于不同的Kubernetes工作節點上，跨越不同的可用區，不共享存儲。每個節點理想情況下使用本地卷（local volumes）存儲PostgreSQL數據，從而提高集群的容錯性。CNPG自動化地更新服務以適應集群拓撲的變化。例如，在故障轉移期間，它會更新**-rw**服務，將應用程序流量重定向到新晉升的主實例，確保無縫的連續性。

讀寫和只讀工作負載

應用程序可以連接到**-rw**服務以在主實例上執行寫操作。對于只讀工作負載，應用程序使用**-ro**服務連接到熱備份副本，從而分擔主節點的查詢負載。這種設置旨在優化集群中的工作負載分布。

多集群部署和災難恢復

CNPG通過一個名為副本集群（Replica Cluster）的功能，支持跨多個Kubernetes集群的部署。這種設置涉及在一個集群中擁有一個可寫主實例，以及在其他集群中擁有只讀副本集群，促進全球性的災難恢復，并減少RPO（恢復點目標）和RTO（恢復時間目標）。

部署運算符

要開始使用CloudNativePG（CNPG），你需要在你的Kubernetes環境中部署運算符?？梢酝ㄟ^使用**kubectl**應用一個YAML清單文件來完成。按照以下步驟安裝CNPG運算符：

• 安裝所需版本的運算符清單文件。可以使用以下命令

kubectl apply -f https://raw.githubusercontent.com/cloudnative-pg/cloudnative-pg/release-1.20/releases/cnpg-1.20.4.yaml

• 通過檢查部署狀態來驗證安裝：

kubectl get deploy -n cnpg-system cnpg-controller-manager

默認情況下，運算符作為Kubernetes的**Deployment**安裝在**cnpg-system**命名空間中。此部署的名稱取決于安裝方法。

• 使用**kubectl**中的**describe**命令獲取有關運算符部署的更多詳細信息：

kubectl describe deploy -n cnpg-system

部署PostgreSQL集群

一旦CNPG運算符安裝完成，你可以通過應用定義所需的**Cluster**配置文件來部署PostgreSQL集群。下面是一個示例配置文件（**cluster-example.yaml**），它定義了一個使用默認存儲類的簡單的3節點PostgreSQL集群：

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: cluster-example
spec:
  instances: 3
  primaryUpdateStrategy: unsupervised
  storage:
    size: 1Gi

使用以下命令應用配置文件來創建一個3節點的PostgreSQL集群：

kubectl apply -f cluster-example.yaml

你可以使用**get pods**命令檢查集群Pods的狀態：

kubectl get pods

通過按照這些步驟，你可以在Kubernetes環境中快速設置CNPG運算符并部署PostgreSQL集群。為了將你的集群與其他工作負載隔離開來，考慮創建一個單獨的命名空間或使用標簽來識別與特定集群相關的對象。運算符將為了便于管理將**cnpg.io/cluster**標簽應用于相關對象。

Kubernetes和數據庫的未來

Cloud Native PG證明了Kubernetes適合數據庫，特別是在增強了CRDs和自定義控制器的情況下。它已經提交給CNCF進行孵化，有望成為生態系統中的PostgreSQL旗艦項目。

選擇正確的數據庫管理路徑

關鍵的決策在于選擇托管數據庫服務還是自管理方法。在后一種情況下，Kubernetes在如Cloud Native PG這樣的解決方案中表現出色，為其采用提供了一個有力的論據。

結論：擁抱Kubernetes的方式

Kubernetes已經成長為運行數據庫的最佳平臺，前提是我們要接受其可擴展的本質。Cloud Native PG不僅是一個選擇；它是PostgreSQL的首選，提供了豐富的功能集和開源社區支持的保證。如果你傾向于自管理數據庫，考慮Cloud Native PG——它不是替代方案，而是未來發展的最佳方式。