在线观看亚洲,国产三级在线观看视频不卡,香蕉一区二区

Kubernetes中PostgreSQL的推薦方法圖片

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

Kubernetes：有關有狀態(tài)工作負載的誤解平臺

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

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

有狀態(tài)集的困境

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

自定義資源定義

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

使用Cloud Native PG運行PostgreSQL

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

Cloud Native PG的架構

高可用性和流復制

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

共享無

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

讀寫和只讀工作負載

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

Kubernetes中PostgreSQL的推薦方法

多集群部署和災難恢復

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

部署運算符

要開始使用CloudNativePG（CNPG），你需要在你的Kubernetes環(huán)境中部署運算符。可以通過使用**kubectl**應用一個YAML清單文件來完成。按照以下步驟安裝CNPG運算符：

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

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

通過檢查部署狀態(tài)來驗證安裝：

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節(jié)點PostgreSQL集群：

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

使用以下命令應用配置文件來創(chuàng)建一個3節(jié)點的PostgreSQL集群：

kubectl apply -f cluster-example.yaml

你可以使用**get pods**命令檢查集群Pods的狀態(tài)：

kubectl get pods

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

Kubernetes和數(shù)據(jù)庫的未來

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

選擇正確的數(shù)據(jù)庫管理路徑

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

結論：擁抱Kubernetes的方式

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