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的介绍）
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