点击阅读:《如何在Kubernetes上部署有状态的云原生应用(上)》html
下面咱们将以最早进的开源数据库PostgreSQL为例,介绍如何在 Kubernetes 上部署运维有状态云服务(如下全部的操做都是基于Kubernetes 1.14及以上版原本完成的)。node
Operator出来之前,即便有StatefulSet控制器,将PostgreSQL、MySQL等数据库部署到Kubernetes也是很是复杂的。两年前关于在Kubernetes上部署数据库还有过一场讨论,当时的广泛建议是不要在Kubernetes部署数据库。git
关于这场讨论能够经过该连接查看:github
https://www.reddit.com/r/devo...sql
经过StatefulSet在Kubernetes上部署高可用的MySQL服务请参考如下连接:数据库
https://www.kubernetes.org.cn...centos
这个方法中yaml文件至关复杂,用户能够参与控制的地方很少。安全
开源的PostgreSQL Operator有CrunchyData/postgres-operator、zalando-incubator/postgres-operator,咱们以CrunchyData/postgres-operator为例来说解如何经过Operator这个新生事物在Kubernetes上管理PostgreSQL数据库,选择它的缘由是功能至关完备而且集成了PostgreSQL周边生态相关的应用。服务器
该Operator实现了在Kubernetes上自动化部署PostgreSQL集群,简化了PostgreSQL服务的部署,并经过Kubernetes平台保持PostgreSQL集群的运行状态,其中包含的基本功能有:网络
PostgreSQL集群配置:轻松建立、扩展和删除PostgreSQL集群,同时彻底自定义Pod和PostgreSQL配置。
高可用性:基于分布式共识的高可用解决方案,支持安全的自动故障转移。使用Pod Anti-Affinity来加强弹性,失败的主数据库会自动恢复,从而缩短恢复时间。
灾难恢复:利用开源pgBackRest程序实现备份和还原功能,并包括对全备,增量和差别备份以及有效增量还原的支持。能够设置要保留的备份时间,比较适合较大型的数据库,也经过共享S3存储及多Kubernetes部署实现了跨机房多区域异地灾备。
TLS:经过为PostgreSQL服务器启用TLS来保护应用程序和数据服务器之间的通讯安全,包括强制全部链接使用TLS。
监控方式:使用开源pgMonitor库跟踪PostgreSQL集群的运行情况。
PostgreSQL用户管理:使用功能强大的命令给PostgreSQL集群快速添加和删除用户。管理密码过时策略或使用首选的PostgreSQL身份验证方案。
升级管理:安全地将PostgreSQL更新应用到您的PostgreSQL集群中,而对可用性的影响最小。
高级复制支持:用户能够在异步复制和同步复制之间进行选择,以处理对丢失事务敏感的工做负载。
克隆:使用简单的pgo clone命令从现有集群中建立新集群。
链接池:使用pgBouncer进行链接池。
节点亲和力:将PostgreSQL集群部署到您喜欢的Kubernetes节点。
备份策略定制:选择备份的类型(全量,增量,差别备份)以及但愿其在每一个PostgreSQL集群上发生周期及时间点。
备份到S3:将您的备份存储在任何支持S3协议的对象存储系统中。PostgreSQL Operator能够从这些备份中还原和建立新的集群。
_多命名空间支持:_您能够经过几种不一样的部署模型来控制PostgreSQL Operator如何利用Kubernetes命名空间:
- 将PostgreSQL Operator和全部PostgreSQL集群部署到同一名称空间;
- 将PostgreSQL Operator部署到一个名称空间,并将全部PostgreSQL集群部署到另外一名称空间;
- 将PostgreSQL Operator部署到一个名称空间,并跨多个命名空间管理PostgreSQL集群;
- 使用pgo create namespace和pgo delete namespace命令动态添加和删除由PostgreSQL Operator管理的名称空间。
彻底可定制:
- 为主存储,WAL存储,副本存储和备份存储选择不一样的存储类别;
- 为每一个PostgreSQL集群部署选择容器资源类;区别应用于主群集和副本群集的资源;
- 使用您私有的镜像存储库,包括支持imagePullSecrets存储库和私有存储库;
- 自定义PostgreSQL配置等。
PostgreSQL Operator包含各类组件,这些组件已部署到您的Kubernetes集群中,以下图所示:
PostgreSQL Operator在指定的namespace中以Deployment对象运行,而且最多由四个容器的Pod组成,其中包括:
- Operator:这是PostgreSQL Operator的核心。它包含一系列Kubernetes 控制器,这些控制器将监视事件关注在一系列本地Kubernetes资源(如Job,Pods)以及PostgreSQL Operator自定义的CRD上,如:Pgcluster,Pgtask等。
- ApiServer: 提供了一套Restful API接口,方便用户经过pgo命令行或直接经过HTTP请求与其交互,ApiServer还利用一系列RBAC规则来控制用户对资源的访问权限。
- Scheduler:运行cron并容许用户设置周期性任务(如备份)以Kubernetes Job的方式运行。
- Event:可选组件,一个提供nsq消息队列接口并输出有关Operator内发生的生命周期事件的信息的容器(例如,建立集群,进行备份,建立克隆失败等),能够由pgo watch命令接受消息。
下列流程是理解 Operator工做原理的关键:
使用Kubernetes的CustomResourceDefinition(CRD)定义若干和 PostgreSQL部署运维相关的资源对象。
- pgclusters.crunchydata.com:存储管理PostgreSQL集群所需的信息。其中包括集群名称,要使用的存储和资源类,要运行的PostgreSQL版本,有关如何维护高可用性集群的信息等。
- pgreplicas.crunchydata.com:存储管理PostgreSQL集群中的副本所需的信息。这包括诸如副本数,要使用的存储和资源类,特殊的类似性规则等。
- pgtasks.crunchydata.com:通用CRD,它接受针对集群运行(例如,建立集群,进行备份,执行克隆)所需的一种任务,并经过其工做流跟踪该任务的状态。
- pgpolicies.crunchydata.com:存储对能够对PostgreSQL集群执行的SQL文件的引用。过去它用于管理PostgreSQL集群上的RLS策略。
在Kubernetes中部署一个Operator实例,该Operator会持续监听针对这些资源对象的CRUD操做,并观察对象状态。
当用户执行了某项操做,例如建立一个PostgreSQL集群时,一个新的 pgcluster 资源对象会被建立。当Operator监听到了pgcluster的建立事件后,会根据用户配置建立符合需求的集群。这里建立了一个基于流复制协议的高可用PostgreSQL集群,使用了Deployment、Service、ConfigMap、PVC等原生 Kubernetes资源对象。
当Operator观察到PostgreSQL Cluster的当前状态与指望状态存在差异时,会执行相应的编排操做,保证状态的一致性。
经过helm部署PostgreSQL Operator。
1[root@RDS pgo]# helm search repo 2NAME CHART VERSION APP VERSION DESCRIPTION 3jd_tpaas_repo/customconfig 1 4.3.2 Deploys a custom configuration for postgreSQL 4jd_tpaas_repo/pgodeployer 1 4.3.2 Deploys a job for the installation of the postg...
<左右滑动以查看完整代码>
安装Operator。
5 [root@RDS pgo]# helm --namespace pgo install pg-operator jd_tpaas_repo/pgo-deployer
<左右滑动以查看完整代码>
部署完成之后查看Operator的状态 。
6 [root@RDS ~]# kubectl -n pgo get all 7 NAME READY STATUS RESTARTS AGE 8 pod/crunchy-grafana-77b4b84b57-cgrnn 1/1 Running 0 4m12s 9 pod/crunchy-prometheus-57788f56fb-lcqsp 1/1 Running 0 4m15s 10 pod/postgres-operator-7f6d4646cc-zf2dg 4/4 Running 0 4m50s 11 12 NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE 13 service/crunchy-grafana ClusterIP 192.168.58.207 3000/TCP 5m34s 14 service/crunchy-prometheus ClusterIP 192.168.62.99 9090/TCP 5m37s 15 service/postgres-operator ClusterIP 192.168.60.155 8080/TCP,4171/TCP,4150/TCP 5m23s 16 17 NAME READY UP-TO-DATE AVAILABLE AGE 18 deployment.apps/crunchy-grafana 1/1 1 1 5m34s 19 deployment.apps/crunchy-prometheus 1/1 1 1 5m37s 20 deployment.apps/postgres-operator 1/1 1 1 5m22s 21 22 NAME DESIRED CURRENT READY AGE 23 replicaset.apps/crunchy-grafana-77b4b84b57 1 1 1 4m12s 24 replicaset.apps/crunchy-prometheus-57788f56fb 1 1 1 4m15s 25 replicaset.apps/postgres-operator-7f6d4646cc 1 1 1 4m50s
<左右滑动以查看完整代码>
咱们看到有一个PostgreSQL-Operator Deployment里面包含了4个容器:ApiServer、Operator、Scheduler、 Event,除了Operator,还部署了crunchy-prometheus和crunchy-grafana两个Deployment能够帮助用户进行集中式监控管理。
PostgreSQL Operator的主要目的是围绕PostgreSQL集群的结构建立和更新信息,并传递有关PostgreSQL集群的整体状态和运行情况的信息。目标也是为用户尽量简化此过程。
例如,假设咱们要建立一个具备单个副本的高可用PostgreSQL集群,它支持在本地存储和S3中进行备份,并具备内置监控指标收集和集中的日志收集。咱们能够利用以下命令来完成:
pgo create cluster hacluster --replica-count=1 --metrics --pgbackrest-storage-type="local,s3"
<左右滑动以查看完整代码>
经过pgo命令行建立集群示例:
首先为集群建立一个namespace 。
1[root@RDS pgo]# pgo create namespace pgouser2 2created namespace pgouser2
<左右滑动以查看完整代码>
建立集群,带一个副本并开启监控。
3 [root@RDS pgo]# pgo -n pgouser2 create cluster test-pgcluter-002 --replica-count 1 --metrics 4 created cluster: test-pgcluter-002 5 workflow id: cb75373a-518f-49e1-8b6a-55e274d2fc58 6 database name: test-pgcluter-002 7 users: 8 username: testuser password: 7iFe|iS4aF(}:3*6FibWo?jZ
<左右滑动以查看完整代码>
查看集群信息。
9 [root@RDS pgo]# pgo -n pgouser2 show cluster test-pgcluter-002 10 cluster : test-pgcluter-002 (crunchy-postgres-ha:centos7-12.3-4.3.2-0) 11 pod : test-pgcluter-002-b7d8b4bd4-qk5cp (Running) on k8s-node-vm7sjf-yn5hsstwuf (2/2) (primary) 12 pvc : test-pgcluter-002 13 pod : test-pgcluter-002-jcfm-6bfff77fcf-vxpn6 (Running) on k8s-node-vmr4ej-yn5hsstwuf (2/2) (replica) 14 pvc : test-pgcluter-002-jcfm 15 resources : Memory: 128Mi 16 storage : Primary=20Gi Replica=20Gi 17 deployment : test-pgcluter-002 18 deployment : test-pgcluter-002-backrest-shared-repo 19 deployment : test-pgcluter-002-jcfm 20 service : test-pgcluter-002 - ClusterIP (192.168.120.61) 21 service : test-pgcluter-002-replica - ClusterIP (192.168.123.182) 22 pgreplica : test-pgcluter-002-jcfm 23 ...
<左右滑动以查看完整代码>
查看集群的服务状态。
24 [root@RDS pgo]# pgo -n pgouser2 test test-pgcluter-002 25 cluster : test-pgcluter-002 26 Services 27 primary (192.168.120.61:5432): UP 28 replica (192.168.123.182:5432): UP 29 Instances 30 primary (test-pgcluter-002-b7d8b4bd4-qk5cp): UP 31 replica (test-pgcluter-002-jcfm-6bfff77fcf-vxpn6): UP
<左右滑动以查看完整代码>
不难看到集群中包含两个Deployment,对应的两个Pod各绑定一个PVC,暴露出两个Service:
Service-Primary:test-pgcluter-002 - ClusterIP (192.168.120.61) 负责用户的读写请求;
Service-Replica: test-pgcluter-002-replica - ClusterIP (192.168.123.182)负责用户的只读请求。
集群建立成功之后,Pod和Service的状态都是Up,处于正常运行状态。
PostgreSQL的一大优势是它的可靠性:它很是稳定,一般能够“正常工做”。可是,在部署PostgreSQL的环境中可能会发生某些事情,从而影响其正常运行时间,包括:
- 数据库存储磁盘发生故障或发生其余一些硬件故障;
- 数据库所在的网络没法访问;
- 主机操做系统变得不稳定并崩溃;
- 密钥数据库文件已损坏;
- 数据中心丢失。
可能还会因为正常操做而致使停机事件,例如执行小版本升级,操做系统的安全修补,硬件升级或其余维护。
为此,在Crunchy PostgreSQL Operator 建立的集群中每个PostgreSQL容器里面都包含Patroni工具,由Patroni经过raft 分布式共识的特性来处理PostgreSQL的高可用。
Patroni是一个用Python编写的开源工具套件,用于管理PostgreSQL集群的高可用性。Patroni没有构建本身的一致性协议,而是巧妙地利用了分布式配置存储(DCS)提供的一致性模型。它支持的DCS解决方案包括:Zookeeper,etcd,Consul和Kubernetes。Crunchy PostgreSQL Operator中采用的是Kubernetes的ConfigMap做为其DCS。
Patroni确保PostgreSQL HA集群的端到端设置,包括流复制。它支持各类方式建立备用节点,而且能够像模板同样工做,能够根据须要进行自定义。这个功能丰富的工具经过RestFul API和称为patronictl的命令行程序暴露其功能。它经过使用其运行情况检查API处理负载均衡来支持与HAProxy集成。在Operator中是经过处理Kubernetes的Service来实现,Patroni还借助回调来支持事件通知,这些回调是由某些操做触发的脚本。经过提供暂停/恢复功能,它使用户可以执行任何维护操做。
最初,须要安装PostgreSQL和Patroni二进制文件。完成此操做后,您还须要设置HA DCS配置。须要在yaml配置文件中指定全部用于引导集群的必要配置,而且Patroni将使用该文件进行初始化。在第一个节点上,Patroni初始化数据库,从DCS获取领导者锁,并确保该节点做为主节点运行。
下一步是添加备用节点,Patroni为此提供了多个选项。默认状况下,Patroni使用pg_basebackup建立备用节点,而且还支持WAL-E、pgBackRest、Barman等自定义方法来建立备用节点。Patroni使添加备用节点变得很是简单,而且能够处理全部引导任务和流复制的设置。集群设置完成后,Patroni将主动监视集群并确保其处于正常状态。主节点每ttl秒更新一次领导者锁(默认值:30秒)。当主节点没法更新领导者锁时,Patroni会触发选举,而且得到领导者锁的节点将被选举为新的主节点。
在分布式系统中,共识在肯定一致性方面起着重要做用,而Patroni使用DCS来达成共识。只有持有领导者锁的节点才能成为主节点,而且领导者锁是经过DCS得到的。若是主节点未持有领导者锁,那么Patroni将当即将其降级以做为备用节点运行。这样,在任什么时候间点,系统中都只能运行一个主服务器。
咱们经过下面一系列的图片来演示Patroni在集群的Failover发生后从新选主的过程:
图 A 显示了一个集群暂时的稳定状态,Pod A是当前的主节点,每隔一段时间就要刷新一次本身的心跳信息,保持本身领导者的地位,其对应的PostgreSQL在集群中是Primary的角色。Pod B 和 Pod C一直在watch leader,集群中有两个Service,master service其后挂载的endpoint指向带有label=master标签的Pod,replica service其后挂载的endpoint指向带有label=replica标签的Pod;
图B 示意某一时刻,Pod A发生了故障,没有及时更新心跳,超过ttl=30s后,Kubernetes会通知 Pod B、Pod C主节点Pod A心跳缺失超时信息。
图C示意Pod B和Pod C都会发起检查集群中其余节点的状态,均会发现主节点Pod A Failed,从而从新发起选举主节点流程,Pod B和Pod C谁的wal_position更大谁将是下一轮主节点,若是同样大就会发生竞争,先抢到领导者锁的节点将成为下一轮的主节点。如图D所示意,Pod B成功抢到了领导者锁。
图E示意_抢到领导者锁的Pod B对应的PostgreSQL会被提高为Master,Pod C中的PostgreSQL会向Pod B的PostgreSQL同步数据。_Pod B会周期刷新本身的心跳,巩固本身领导者的地位,Pod C会一直Watch Leader。到此,集群又进入下一轮稳定状态。
图F示意由于Operator要保证集群的replica的个数,会拉起一个新的Pod D,做为replica加入到集群中,从Pod B的PostgreSQL同步数据,而且带有replica的label,其endpoint会挂载到replica service下面。
实际操做示意:
删除Primary的Pod 。
1 [root@RDS pgo]# kubectl -n pgouser2 delete pod test-pgcluter-002-b7d8b4bd4-qk5cp 2 pod "test-pgcluter-002-b7d8b4bd4-qk5cp” deleted 3 稍等片刻......
<左右滑动以查看完整代码>
查看集群的状态
4 [root@RDS pgo]# pgo -n pgouser2 show cluster test-pgcluter-002 5 cluster : test-pgcluter-002 (crunchy-postgres-ha:centos7-12.3-4.3.2-0) 6 pod : test-pgcluter-002-b7d8b4bd4-97qqp (Running) on k8s-node-vm7sjf-yn5hsstwuf (2/2) (replica) 7 pvc : test-pgcluter-002 8 pod : test-pgcluter-002-jcfm-6bfff77fcf-vxpn6 (Running) on k8s-node-vmr4ej-yn5hsstwuf (2/2) (primary) 9 pvc : test-pgcluter-002-jcfm 10 resources : Memory: 128Mi 11 storage : Primary=20Gi Replica=20Gi 12 deployment : test-pgcluter-002 13 deployment : test-pgcluter-002-backrest-shared-repo 14 deployment : test-pgcluter-002-jcfm 15 service : test-pgcluter-002 - ClusterIP (192.168.120.61) 16 service : test-pgcluter-002-replica - ClusterIP (192.168.123.182) 17 pgreplica : test-pgcluter-002-jcfm 18 ... 19 20 [root@RDS pgo]# pgo -n pgouser2 test test-pgcluter-002 21 cluster : test-pgcluter-002 22 Services 23 primary (192.168.120.61:5432): UP 24 replica (192.168.123.182:5432): UP 25 Instances 26 replica (test-pgcluter-002-b7d8b4bd4-97qqp): UP 27 primary (test-pgcluter-002-jcfm-6bfff77fcf-vxpn6): UP
<左右滑动以查看完整代码>
能够看到原来的Replica Pod:test-pgcluter-002-jcfm-6bfff77fcf-vxpn6 变成了Primary,Operator又新建了一个Pod:test-pgcluter-002-b7d8b4bd4-97qqp 做为replica 运行,其挂载的仍是原来Primary的PVC:test-pgcluter-002,Services相对于集群建立的时候没有发生变化,仍是primary (192.168.120.61:5432) 和 replica (192.168.123.182:5432),链接的用户除了有秒级别的闪断基本没有感知。
经过pgo scale来进行水平扩容,如下命令对集群test-pgcluter-002水平扩容增长一个replica节点。
1 [root@RDS pgo]# pgo -n pgouser2 scale test-pgcluter-002 --replica-count=1 2 WARNING: Are you sure? (yes/no): yes 3 created Pgreplica test-pgcluter-002-tbrl
<左右滑动以查看完整代码>
查看扩容之后的集群状态:
4 [root@RDS pgo]# pgo -n pgouser2 show cluster test-pgcluter-002 5 cluster : test-pgcluter-002 (crunchy-postgres-ha:centos7-12.3-4.3.2-0) 6 pod : test-pgcluter-002-b7d8b4bd4-97qqp (Running) on k8s-node-vm7sjf-yn5hsstwuf (2/2) (replica) 7 pvc : test-pgcluter-002 8 pod : test-pgcluter-002-jcfm-6bfff77fcf-vxpn6 (Running) on k8s-node-vmr4ej-yn5hsstwuf (2/2) (primary) 9 pvc : test-pgcluter-002-jcfm 10 pod : test-pgcluter-002-tbrl-7d69bc5fb9-8xmx2 (Running) on k8s-node-vmwnpv-yn5hsstwuf (2/2) (replica) 11 pvc : test-pgcluter-002-tbrl 12 resources : Memory: 128Mi 13 storage : Primary=20Gi Replica=20Gi 14 deployment : test-pgcluter-002 15 deployment : test-pgcluter-002-backrest-shared-repo 16 deployment : test-pgcluter-002-jcfm 17 deployment : test-pgcluter-002-tbrl 18 service : test-pgcluter-002 - ClusterIP (192.168.120.61) 19 service : test-pgcluter-002-replica - ClusterIP (192.168.123.182)
<左右滑动以查看完整代码>
经过增长一个名为test-pgcluter-002-tbr的Deployment,增长了一个replica。新建的pod为test-pgcluter-002-tbrl-7d69bc5fb9-8xmx2,绑定的pvc:test-pgcluter-002-tbrl,暴露的服务仍是原来的两个Service:primary (192.168.120.61:5432)、replica (192.168.123.182:5432) 。Service replica 后面对应着两个replica节点的Pod暴露的endpoint,对用户数据面没有影响。
如下命令查看能够缩容的replica节点:
1 [root@RDS pgo]# pgo -n pgouser2 scaledown test-pgcluter-002 --query 2 Cluster: test-pgcluter-002 3 REPLICA STATUS NODE REPLICATION LAG PENDING RESTART 4 test-pgcluter-002 running k8s-node-vm7sjf-yn5hsstwuf 0 MB false 5 test-pgcluter-002-tbrl running k8s-node-vmwnpv-yn5hsstwuf 0 MB false
<左右滑动以查看完整代码>
经过pgo scaledown命令进行缩容:
6 [root@RDS pgo]# pgo -n pgouser2 scaledown test-pgcluter-002 --target test-pgcluter-002 7 WARNING: Are you sure? (yes/no): yes 8 deleted replica test-pgcluter-002
<左右滑动以查看完整代码>
查看集群的详情:
9 [root@RDS pgo]# pgo -n pgouser2 show cluster test-pgcluter-002 10 cluster : test-pgcluter-002 (crunchy-postgres-ha:centos7-12.3-4.3.2-0) 11 pod : test-pgcluter-002-jcfm-6bfff77fcf-vxpn6 (Running) on k8s-node-vmr4ej-yn5hsstwuf (2/2) (primary) 12 pvc : test-pgcluter-002-jcfm 13 pod : test-pgcluter-002-tbrl-7d69bc5fb9-8xmx2 (Running) on k8s-node-vmwnpv-yn5hsstwuf (2/2) (replica) 14 pvc : test-pgcluter-002-tbrl 15 resources : Memory: 128Mi 16 storage : Primary=20Gi Replica=20Gi 17 deployment : test-pgcluter-002-backrest-shared-repo 18 deployment : test-pgcluter-002-jcfm 19 deployment : test-pgcluter-002-tbrl 20 service : test-pgcluter-002 - ClusterIP (192.168.120.61) 21 service : test-pgcluter-002-replica - ClusterIP (192.168.123.182) 22 …
<左右滑动以查看完整代码>
咱们不难发现,Pod:test-pgcluter-002 和其关联的 PVC:test-pgcluter-002 已经被回收,两个Service仍是保持在原来的状态primary (192.168.120.61:5432)、replica (192.168.123.182:5432),对用户数据面没有影响。
经过pgo update cluster命令来修改集群的cpu和memory资源。
1 [root@RDS pgo]# pgo -n pgouser2 update cluster test-pgcluter-002 --memory 256Mi --cpu 1 2 Updating CPU resources can cause downtime. 3 Updating memory resources can cause downtime. 4 WARNING: Are you sure? (yes/no): yes 5 updated pgcluster test-pgcluter-002 6 7 [root@RDS pgo]# pgo -n pgouser2 show cluster test-pgcluter-002 8 9 cluster : test-pgcluter-002 (crunchy-postgres-ha:centos7-12.3-4.3.2-0) 10 pod : test-pgcluter-002-jcfm-54ff784874-jfwgk (Running) on k8s-node-vmr4ej-yn5hsstwuf (2/2) (replica) 11 pvc : test-pgcluter-002-jcfm 12 pod : test-pgcluter-002-tbrl-8695b6d956-j9pdv (Running) on k8s-node-vmwnpv-yn5hsstwuf (2/2) (primary) 13 pvc : test-pgcluter-002-tbrl 14 resources : CPU: 1 Memory: 256Mi
<左右滑动以查看完整代码>
用户在用pgo create cluster建立集群的时候能够经过参数--cpu ,--memory和--pvc-size来指定集群所用的cpu,内存和存储的大小,集群建立完成之后,还能够经过pgo update cluster命令来修改 cpu和memory资源配置,pvc大小的变动须要csi支持,如京东的chubaofs等。
出于安全的考虑,周期性的备份对于生产级别的数据库服务来讲是很是重要的,Crunchy PostgreSQL Operator提供了全量备份,差别备份,增量备份,周期性的备份和周期性的WAL文件归档。
备份策略定制:选择备份的类型(全量,增量,差别备份)以及但愿其在每一个PostgreSQL集群上执行的频率及时间点。
备份到S3:将您的备份存储在任何支持S3协议的对象存储系统中,Operator能够从这些备份还原和建立新集群。
示例:
建立用s3备份的cluster
1 pgo create cluster test-pgcluter-004 -n pgouser2 --pgbackrest-storage-type s3 --pgbackrest-s3-region cn-north-1 --pgbackrest-s3-endpoint s3.cn-north-1.jdcloud-oss.com --pgbackrest-s3-key 7FD8AC9D8XX --pgbackrest-s3-key-secret BE059515AXYX --pgbackrest-s3-bucket caas-test --replica-count 1 --metrics 2 created cluster: test-pgcluter-004 3 workflow id: 7c1ae19b-937d-441f-80ff-ff50ac8943b0 4 database name: test-pgcluter-004 5 users: 6 username: testuser password: (Ev{k)VoEWStc8mWryL3r10
<左右滑动以查看完整代码>
建立备份
7 [root@RDS pgo]# pgo -n pgouser2 backup test-pgcluter-004 --pgbackrest-storage-type s3 8 created Pgtask backrest-backup-test-pgcluter-004
<左右滑动以查看完整代码>
查看备份
9 [root@RDS pgo]# pgo -n pgouser2 show backup test-pgcluter-004 10 cluster: test-pgcluter-004 11 storage type: s3 12 stanza: db 13 status: ok 14 cipher: none 15 db (current) 16 wal archive min/max (12-1) 17 full backup: 20200710-022111F 18 timestamp start/stop: 2020-07-10 10:21:11 +0800 CST / 2020-07-10 10:22:11 +0800 CST 19 wal start/stop: 000000010000000000000002 / 000000010000000000000003 20 database size: 31.1MiB, backup size: 31.1MiB 21 repository size: 3.7MiB, repository backup size: 3.7MiB 22 backup reference list:
<左右滑动以查看完整代码>
周期备份设置
23 pgo create schedule --schedule="* * * * *" --schedule-type=pgbackrest --pgbackrest-backup-type=full test-pgcluter-004
<左右滑动以查看完整代码>
使用简单的pgo clone命令从现有集群中建立新集群。
经过命令pgo clone从源集群test-pgcluter-007克隆建立新的集群test-pgcluter-008,并打开监控。
1 [root@RDS pgo]# pgo -n pgouser2 clone test-pgcluter-007 test-pgcluter-008 --pgbackrest-storage-source s3 --enable-metrics 2 Created clone task for: test-pgcluter-008 3 workflow id is 232b0c7b-fb13-451e-a65f-194ee3fe2413 4
<左右滑动以查看完整代码>
克隆过程当中的任务顺序
5 [root@RDS pgo]# pgo -n pgouser2 show workflow 232b0c7b-fb13-451e-a65f-194ee3fe2413 6 parameter value 7 --------- ----- 8 clone 1.1: create pvc2020-07-10T06:33:59Z 9 clone 1.2: sync pgbackrest repo2020-07-10T06:33:59Z 10 clone 2: restoring backup2020-07-10T06:34:23Z 11 clone 3: cluster creating2020-07-10T06:35:16Z 12 pg-cluster test-pgcluter-008 13 task submitted 2020-07-10T06:33:59Z 14 workflowid 232b0c7b-fb13-451e-a65f-194ee3fe2413 15
<左右滑动以查看完整代码>
克隆完成之后查看新的集群test-pgcluter-008信息
16 [root@RDS pgo]# pgo -n pgouser2 show cluster test-pgcluter-008 17 cluster : test-pgcluter-008 (crunchy-postgres-ha:centos7-12.3-4.3.2-0) 18 pod : pgo-backrest-repo-sync-test-pgcluter-008-beje-b99pp (Succeeded) on k8s-node-vmj91e-yn5hsstwuf (0/1) (unknown) 19 pvc : test-pgcluter-008-pgbr-repo 20 pod : test-pgcluter-008-59cbf78584-cld7j (Running) on k8s-node-vm7sjf-yn5hsstwuf (2/2) (primary) 21 pvc : test-pgcluter-008 22 resources : Memory: 128Mi 23 ...
<左右滑动以查看完整代码>
不难从 show workflow的输出中看到克隆大致流程:_先为新集群建立一个pvc,而后经过pgbackrest将老集群的备份信息同步到新PVC中,再恢复增量WAL文件,最后用刚才的PVC建立集群。_
一个完备的系统少不了监控和告警,由Crunchy PostgreSQL Operator建立的PostgreSQL集群能够选择经过Prometheus Exporters提供性能指标。指标收集器(metric exporter)包含在数据库集群的每一个Pod里面,为数据库容器提供实时监控指标收集。为了存储和查看这些数据,还有须要使用Grafana和Prometheus两个组件,用户能够经过最新版本的helm chart部署Operator项目自带的Grafana和Prometheus组件。
Prometheus收集到的监控指标显示以下:
示例图片是集群中WAL文件积压空间的相关监控信息,图片中阶梯降低的线展现了集群里面wal文件由12GB左右的积压数据,降到0GB的过程,期间PostgreSQL的archive commoand经过pgbackrest在周期性的作WAL文件归档操做,示例中WAL文件积压消化的有点慢,能够调整pgbackrest的并行度加速。更美观更多维度的监控信息能够经过Grafana展现,以下一小节所示。
Grafana监控指标信息显示:
容器生成的日志对于系统相当重要,由于它们提供了有关系统运行情况的详细记录。PostgreSQL日志很是详细,而且有些信息只能从日志中获取(但不只限于):
- 用户的链接和断开。
- 检查点统计。
- PostgreSQL服务器错误。
跨多个主机聚合容器日志可以让管理员很方便的审核、调试问题并防止违规行为。
本文首先探讨了一下在Kubernetes上部署有状态的服务的几种可行方案,而后以开源社区的Crunchy PostgreSQL Operator为例部署了一个基本功能相对完备的PostgreSQL云服务。咱们能够看到Operator屏蔽了复杂应用的编排细节,大大下降了它们在Kubernetes中的使用门槛,并且能作到对应用很是复杂而又精细的管理和控制,可以帮助开发人员实现全部主流云厂商相同云产品的同等功能。同时,借助于强大的Kubernetes,系统更健壮、扩展更灵活方便,若是您有其它复杂应用须要部署,也建议采用Operator方式来部署。
1.CrunchyData/postgres-operator:https://github.com/CrunchyDat...
2.zalando/postgres-operator:
https://github.com/zalando/po...
3.Patroni组件:
https://github.com/zalando/pa...
4.K8s应用管理之道 - 有状态服务:
https://developer.aliyun.com/...
5.Managing High Availability in PostgreSQL — Part 3 Patroni:
https://scalegrid.io/blog/man...
6.https://thenewstack.io/differ...
7.Databases on Kubernetes:
https://www.reddit.com/r/devo...
8.https://www.slideshare.net/jk...
9.https://www.slideshare.net/Al...