Kubernetes部署高可用PostgreSQL集羣

【編者的話】本文主要介紹瞭如何在Kubernetes環境中用Stolon去部署高可用的PostgreSQL,本文從Stolon的結構組成開始,由淺入深介紹原理,從開始安裝到最後對其進行failover測試,深刻淺出,爲之後部署高可用的PostgreSQL提供了一種的解決方案。mysql

建立一個高可用的PostgreSQL集羣環境老是一件棘手的事情。在雲環境裏部署時更是很是困難。我至少找到了3個項目,它們能夠在Kubernetes裏提供高可用的PostgreSQL解決方案。git

Patronigithub

Patroni是一個模板,它使用Python爲你提供一個本身訂製的,高可用的解決方案,爲最大程度的可用性,它的配置信息存儲在像ZooKeeper, etcd或者Consul中。若是DBAs,DevOps工程師或者SRE正在尋找一個在數據中心中快速部署高可用PostgreSQL方案,或者其餘的用途,我但願Patroni可以幫到他們。sql

Crunchy服務器

Crunchy容器套件提供一個了Docker容器,它能快速部署PostgreSQL,同時也提供管理和監控的工具。而且支持多種用風格的部署PostgreSQL集羣。架構

Stolon負載均衡

Stolon是一個cloud native的PostgreSQL高可用管理工具。它之因此是cloud native的是由於它能夠在爲容器內部的PostgreSQL提供高可用(kubernetes 集成),並且還支持其餘種類的基礎設施(好比:cloud Iaas,舊風格的基礎設施等)工具

漂亮的圖表加上一些在kubernets.io上的用戶分享說服我去試一下crunchy容器。可是過了一段時間,我改變了想法。post

我不想說他設計上的某些缺點或者是其餘的什麼很差。可是它給個人感受就好像是我本身在容器裏手動安裝PostgreSQL同樣,並無雲的感受。測試

因此我嘗試了一下stolon。在一次又一次的安裝和卸載以後,我運行了它的statefulset的例子而且用helm chart建立。

若是你想知道更多關於stolon能夠參考做者這篇介紹

下面我將展現一下安裝過程而且演示一下集羣環境下的failover。咱們假設安裝用的是helm chart。

Stolon 架構圖(摘抄自stolon的介紹)

20170312110257

Stolon 是由3個部分組成的:

  • keeper:他負責管理PostgreSQL的實例匯聚到由sentinel(s)提供的clusterview。
  • sentinel:it負責發現而且監控keeper,而且計算最理想的clusterview。
  • proxy:客戶端的接入點。它強制鏈接到右邊PostgreSQL的master而且強制關閉鏈接到由非選舉產生的master。

Stolon 用etcd或者consul做爲主要的集羣狀態存儲。

Installation

$ git clone https://github.com/lwolf/stolon-chart
$ cd stolon-chart
$ helm install ./stolon

You can also install directly from my repository

helm repo add lwolf-charts http://charts.lwolf.org
helm install lwolf-charts/stolon

安裝的過程將會作以下的動做:

首先,會用statefulset建立3個etcd節點。Stolon-proxy和stolon-sentinel也會被部署。Singe time job將集羣的安裝暫停直到etcd節點狀態變成availabe。
chart還會建立兩個服務

  • stolon-proxy—服務來源於官方的例子。他老是指向當前的因該被寫入的master。
  • stolon-keeper—Stolon本身自己不提供任何讀取操做的負載均衡。可是kubernetes的service卻能夠作到這點。因此對於用戶來講,stolon-keeper的讀操做是在pod的層面作到負載均衡的。

當全部的組件狀態變爲RUNNING時,咱們能夠試着鏈接它們。

咱們能夠用NodePort這種簡單的鏈接方式部署service。用兩個終端分別去鏈接master service和slave service。在post的過程當中,咱們假設stolon-proxy服務(RW)已經暴露了30543端口,stolon-keeper服務(RO)已經暴露了30544端口。

鏈接master而且創建test表

psql --host <IP> --port 30543 postgres -U stolon -W
postgres=# create table test (id int primary key not null,
value text not null);
CREATE TABLE
postgres=# insert into test values (1, 'value1');
INSERT 0 1
postgres=# select * from test;
id | value
---- --------
1 | value1
(1 row)

鏈接slave而且檢查數據。你能夠寫一些信息以便確認請求已經被slave處理了。

psql --host <IP> --port 30544 postgres -U stolon -W
postgres=# select * from test;
id | value
---- --------
1 | value1
(1 row)

在測試經過後,咱們去試試failover功能。

測試failover

這個案例是官方代碼庫中statefullset的一個例子
簡單的說,就是爲模擬了master掛掉,咱們先刪除了master的statefulset又刪除了master的pod。

kubectl delete statefulset stolon-keeper --cascade=false
kubectl delete pod stolon-keeper-0

而後,在sentinel的log中咱們能夠看到新的master被選舉出來了。

no keeper info available db=cb96f42d keeper=keeper0
no keeper info available db=cb96f42d keeper=keeper0
master db is failed db=cb96f42d keeper=keeper0
trying to find a standby to replace failed master
electing db as the new master db=087ce88a keeper=keeper1

如今,在剛纔的那兩個終端中若是咱們重複上一個命令,咱們能夠看到以下輸出。

postgres=# select * from test;
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset:
Succeeded.
postgres=# select * from test;
id | value
---- --------
1 | value1
(1 row)

Kubernetes的service把不可用的pod去掉,把請求轉到可用的pod上。因此新的讀取鏈接被路由到了健康的pod上。

最後,咱們須要從新建立statefulset。最簡單的方法就是更新部署了的helm chart。

helm ls
NAME REVISION UPDATED
STATUS CHART NAMESPACE
factual-crocodile 1 Sat Feb 18 15:42:50 2017
DEPLOYED stolon-0.1.0 default
helm upgrade factual-crocodile .

 

2.用chaoskube模擬隨機的pod掛掉

另外一個測試集羣彈性(resilience)的好方法是用chaoskube。Chaoskube是一個小的服務程序,它能夠週期性的在集羣裏隨機的kill掉一些的pod。它也能夠用helm charts部署。

helm install --set labels="release=factualcrocodile,
component!=factual-crocodine-etcd" --set
interval=5m stable/chaoskube

這條命令會運行chaoskube,它會每5分鐘刪除一個pod。它會選擇label中release=factual-crocodile的pod,可是會忽略etcd的pod。

在作了幾個小時的測試以後,個人集羣環境仍然是一致而且工做的很穩定。

結論

我仍然在個人開發服務器上運行stolon。到目前爲止我仍是滿意的。他真的很想一個本地的運環境。有很好的彈性和自動化的failover能力。

若是你對它感興趣-能夠查看個人官方repository或者和個人chart

原文連接:How to deploy HA PostgreSQL cluster on Kubernetes(翻譯:王曉軒)

MySQL, Vitess: Scaling MySQL with Sugu Sougoumarane

相關文章
相關標籤/搜索