共计 19861 个字符，预计需要花费 50 分钟才能阅读完成。
点击浏览：《如何在 Kubernetes 上部署有状态的云原生利用（上）》
上面咱们将以最先进的开源数据库 PostgreSQL 为例，介绍如何在 Kubernetes 上部署运维有状态云服务（以下所有的操作都是基于 Kubernetes 1.14 及以上版本来实现的）。
Operator 进去以前，即便有 StatefulSet 控制器，将 PostgreSQL、MySQL 等数据库部署到 Kubernetes 也是非常复杂的。两年前对于在 Kubernetes 上部署数据库还有过一场探讨，过后的广泛倡议是不要在 Kubernetes 部署数据库。
对于这场探讨能够通过该链接查看：
https://www.reddit.com/r/devo…
通过 StatefulSet 在 Kubernetes 上部署高可用的 MySQL 服务请参考以下链接：
https://www.kubernetes.org.cn…
这个办法中 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…
10.https://github.com/operator-f…
11.https://www.kubernetes.org.cn…