关于javascript:云原生在京东丨如何在Kubernetes上部署有状态的云原生应用下

点击浏览：《如何在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    ...  1920    [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...