【摘要】本文主要介紹了如安在Kubernetes環境中用Stolon去部署高可用的PostgreSQL,本文從Stolon的結構組成開始,由淺入深介紹原理,從開始安裝到最后對其進行failover測試,深入淺出,為以后部署高可用的PostgreSQL提供了一種的解決方案.

創建一個高可用的PostgreSQL集群環境總是一件棘手的事情.在云環境里部署時更是非常困難.我至少找到了3個項目,它們可以在Kubernetes里提供高可用的PostgreSQL辦理方案.

• Patroni

Patroni是一個模板,它使用Python為你提供一個自己訂制的,高可用的辦理方案,為最大程度的可用性,它的配置信息存儲在像ZooKeeper, etcd或者Consul中.如果DBAs,DevOps工程師或者SRE正在尋找一個在數據中心中快速部署高可用PostgreSQL方案,或者其他的用途,我希望Patroni能夠幫到他們.

• Crunchy

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

• Stolon

Stolon是一個cloud native的PostgreSQL高可用管理工具.它之所以是cloud native的是因為它可以在為容器內部的PostgreSQL提供高可用(kubernetes 集成),而且還支持其他種類的基礎設施(好比：cloud Iaas,舊風格的基礎設施等)

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

我不想說他設計上的某些缺點或者是其他的什么不好.但是它給我的感覺就好像是我本身在容器里手動安裝PostgreSQL一樣,并沒有云的感覺.

所以我嘗試了一下stolon.在一次又一次的安裝和卸載之后,我運行了它的statefulset的例子而且用helm chart創建.

如果你想知道更多關于stolon可以參考作者這篇介紹

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

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

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 ./stolonYou can also install directly from my repositoryhelm repo add lwolf-charts http://charts.lwolf.orghelm 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 -Wpostgres=# create table test (id int primary key not null,value text not null);CREATE TABLEpostgres=# insert into test values (1, 'value1');INSERT 0 1postgres=# select * from test;id | value---- --------1 | value1(1 row)

連接slave并且檢查數據.你可以寫一些信息以便確認哀求已經被slave處理了.

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

在測試通過后,我們去嘗嘗failover功能.

測試failover

這個案例是官方代碼庫中statefullset的一個例子.

簡單的說,便是為模擬了master掛掉,我們先刪除了master的statefulset又刪除了master的pod.

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

然后,在sentinel的log中我們可以看到新的master被選舉出來了.

no keeper info available db=cb96f42d keeper=keeper0no keeper info available db=cb96f42d keeper=keeper0master db is failed db=cb96f42d keeper=keeper0trying to find a standby to replace failed masterelecting db as the new master db=087ce88a keeper=keeper1

現在,在剛才的那兩個終端中如果我們重復上一個命令,我們可以看到如下輸出.

postgres=# select * from test;server closed the connection unexpectedlyThis probably means the server terminated abnormallybefore 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 lsNAME REVISION UPDATEDSTATUS CHART NAMESPACEfactual-crocodile 1 Sat Feb 18 15:42:50 2017DEPLOYED stolon-0.1.0 defaulthelm upgrade factual-crocodile .

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

另一個測試集群彈性(resilience)的好辦法是用chaoskube.Chaoskube是一個小的服務程序,它可以周期性的在集群里隨機的kill掉一些的pod.它也可以用helm charts部署.

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

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

在做了幾個小時的測試之后,我的集群環境仍然是一致而且工作的很穩定.

結論

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

• 如需了解零空信息更多資訊及最新進展,敬請存眷公眾號：零空科技&魔法隧道