如何在Kubernetes中部署一個高可用的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上的用戶分享 1 2 說服我去試一下crunchy容器。但是過了一段時間，我改變了想法。

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

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

下面我將展示一下安裝過程并且演示一下集群環境下的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 ./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能力。

 

 

來自：http://dockone.io/article/2143