在Kubernetes部署可用的PostgreSQL集群环境

【摘要】本文主要介绍了如安在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能力.

• 如需了解零空信息更多资讯及最新进展,敬请存眷公众号：零空科技&魔法隧道