乐趣区

关于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    ...  
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…

退出移动版