k8s中使用PGO部署高可用PostgreSQL

1、介绍

PGO是来自 Crunchy Data的 Postgres Operator，它为您提供了一个声明式 Postgres解决方案，可以自动管理您的PostgreSQL集群。

专为您的 GitOps 工作流程而设计，使用 PGO 在 Kubernetes 上使用 Postgres很容易。片刻之内，您就可以拥有一个完整的生产级 Postgres 集群，该集群具有高可用性、灾难恢复和监控，以及所有安全 TLS 通信。更棒的是，PGO 让您可以轻松自定义 Postgres 集群，使其适应您的工作负载！

借助诸如克隆 Postgres 集群、使用滚动更新以以最少的停机时间推出破坏性更改等便利性，PGO 已准备好在发布管道的每个阶段支持您的 Postgres 数据。PGO 专为弹性和正常运行时间而构建，可将您所需的 Postgres 保持在所需状态，因此您无需担心。

PGO 是凭借在 Kubernetes 上自动化 Postgres 管理方面的多年生产经验而开发的，提供无缝的云原生 Postgres 解决方案，让您的数据始终可用。

PostgreSQL 集群配置：轻松创建、扩展和删除 PostgreSQL 集群，同时完全自定义您的 Pod 和 PostgreSQL 配置！
高可用性：由基于分布式共识的高可用性解决方案支持的安全、自动故障转移。使用Pod Anti-Affinity来帮助恢复；您可以配置它的攻击性！失败的初选会自动愈合，从而加快恢复时间。您甚至可以创建定期计划的备份并设置备份保留策略
灾难恢复：备份和恢复利用开源pgBackRest实用程序，包括对完整、增量和差异备份以及高效增量恢复的支持。设置您希望备份保留多长时间。适用于非常大的数据库！
监控：使用开源pgMonitor库跟踪 PostgreSQL 集群的运行状况。
克隆：通过有效的数据克隆从现有集群或备份创建新集群。
TLS：所有连接都通过TLS。如果您不想使用提供的默认值，也可以使用自己的 TLS 基础架构。
连接池：使用pgBouncer的高级连接池支持。
Affinity and Tolerations：将您的 PostgreSQL 集群部署到您喜欢的Kubernetes 节点。设置您的pod 反亲和性、节点亲和性、Pod 容忍度和更多规则来自定义您的部署拓扑！
完全可定制性：Crunchy PostgreSQL for Kubernetes 让您可以轻松启动和运行您自己的 PostgreSQL 即服务并完全定制您的部署，包括：
为您的 Postgres 集群选择资源：容器资源和存储大小。随时调整大小，将干扰降至最低。
使用您自己的容器镜像存储库，包括支持imagePullSecrets和私有存储库
自定义您的 PostgreSQL 配置

2、部署

安装 Operator Lifecycle Manager (OLM)，这是一个帮助管理集群上运行的 Operator 的工具。

curl -sL https://github.com/operator-framework/operator-lifecycle-manager/releases/download/v0.21.2/install.sh | bash -s v0.21.2

安装Postgres Operator，此 Operator 将安装在“ operators ”命名空间中，并可从集群中的所有命名空间使用。

kubectl create -f https://operatorhub.io/install/postgresql.yaml

查看Operator

kubectl get csv -n operators
NAME                      DISPLAY                           VERSION   REPLACES                  PHASE
postgresoperator.v5.1.2   Crunchy Postgres for Kubernetes   5.1.2     postgresoperator.v5.1.1   Succeeded

要使用Operator，还需要自定义资源定义 (CRD) 以开始使用它。

apiVersion: postgres-operator.crunchydata.com/v1beta1
kind: PostgresCluster
metadata:
  name: pgsql
spec:
  image: registry.developers.crunchydata.com/crunchydata/crunchy-postgres:ubi8-14.4-0
  postgresVersion: 14
  instances:
    - name: instance1
      replicas: 2
      resources:
        limits:
          cpu: 2.0
          memory: 4Gi
      dataVolumeClaimSpec:
        accessModes:
        - "ReadWriteOnce"
        resources:
          requests:
            storage: 10Gi
  backups:
    pgbackrest:
      image: registry.developers.crunchydata.com/crunchydata/crunchy-pgbackrest:ubi8-2.38-2
      manual:
        repoName: repo1
        options:
         - --type=full
      global:
        repo1-retention-full: "3"
        repo1-retention-full-type: time
      repos:
      - name: repo1
        schedules:
          full: "0 1 * * 0"
          differential: "0 1 * * 1-6"
        volume:
          volumeClaimSpec:
            accessModes:
            - "ReadWriteOnce"
            resources:
              requests:
                storage: 10Gi

部署自定义CRD

kubectl apply -f pgsql-operator.yml

查看结果

kubectl get pod 

NAME                       READY   STATUS      RESTARTS   AGE
pgsql-instance1-6tdw-0     4/4     Running     0          26m
pgsql-instance1-ndwp-0     4/4     Running     0          7h8m
pgsql-repo-host-0          2/2     Running     0          7h37m

自定义CRD文件参数说明：

replicas: 2

HA Postgres：将副本添加到 Postgres 集群

PGO 提供了几种添加副本以创建 HA 集群的方法：

增加spec.instances.replicas价值
在中添加一个附加条目spec.instances

manual:
  repoName: repo1
  options:
    - --type=full

一次性备份

这不会触发一次性备份 - 您必须通过将 postgres-operator.crunchydata.com/pgbackrest-backup注释添加到自定义资源来做到这一点。设置此注释的最佳方法是使用时间戳，以便您知道何时初始化备份。
我们可以运行以下命令来触发一次性备份：

kubectl annotate -n postgres-operator postgrescluster hippo \
  postgres-operator.crunchydata.com/pgbackrest-backup="$(date)"

global:
  repo1-retention-full: "14"  
  repo1-retention-full-type: time

管理备份保留

您可以设置两种不同类型的备份保留：

count：这取决于您要保留的备份数量。这是默认设置。
time：这是基于您希望保留备份的总天数。

schedules:
  full: "0 1 * * 0"
  differential: "0 1 * * 1-6"

管理计划备份

PGO 使用的备份管理工具pgBackRest提供了不同的备份类型，以从空间管理和 RTO 优化的角度提供帮助。这些备份类型包括：

full：整个 Postgres 集群的备份。这是所有备份类型中最大的。
differential：自上次备份以来的所有数据的full备份。
incremental：自上次、或备份以来的所有数据full的differential备份incremental。

3、测试 HA 集群

查看 PGO 创建的服务：

kubectl  get svc   --selector=postgres-operator.crunchydata.com/cluster=pgsql

NAME              TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)    AGE
pgsql-ha          ClusterIP   10.96.0.184   <none>        5432/TCP   5h23m
pgsql-ha-config   ClusterIP   None          <none>        <none>     7h9m
pgsql-pods        ClusterIP   None          <none>        <none>     7h9m
pgsql-primary     ClusterIP   None          <none>        5432/TCP   5h24m
pgsql-replicas    ClusterIP   10.96.3.171   <none>        5432/TCP   5h24m

测试1：删除pgsql-primary的svc

kubectl delete svc pgsql-primary

service "pgsql-primary" deleted

kubectl  get svc   --selector=postgres-operator.crunchydata.com/cluster=pgsql

NAME              TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)    AGE
pgsql-ha          ClusterIP   10.96.0.184   <none>        5432/TCP   5h26m
pgsql-ha-config   ClusterIP   None          <none>        <none>     7h12m
pgsql-pods        ClusterIP   None          <none>        <none>     7h12m
pgsql-primary     ClusterIP   None          <none>        5432/TCP   4s
pgsql-replicas    ClusterIP   10.96.3.171   <none>        5432/TCP   5h27m

PGO 检测到主服务被删除并重新创建了它！根据您的应用程序连接到 Postgres 的方式，它可能甚至没有注意到发生了此事件！

测试2：删除主 StatefulSet
获取主Pod

kubectl get pods   --selector=postgres-operator.crunchydata.com/role=master   -o jsonpath='{.items[*].metadata.labels.postgres-operator\.crunchydata\.com/instance}'

pgsql-instance1-6tdw

删除主Pod

kubectl delete sts -n postgres-operator pgsql-instance1-6tdw

下面来获取所有实例

kubectl get sts   --selector=postgres-operator.crunchydata.com/cluster=pgsql,postgres-operator.crunchydata.com/instance

NAME                   READY   AGE
pgsql-instance1-6tdw   1/1     7h21m
pgsql-instance1-ndwp   1/1     7h21m

PGO 重新创建了被删除的 StatefulSet！在这个“灾难性”事件之后，PGO 继续修复 Postgres 实例，以便它可以重新加入集群。我们稍后会在文档中更深入地介绍高可用性过程。

再次查看主 Pod

kubectl  get pods   --selector=postgres-operator.crunchydata.com/role=master   -o jsonpath='{.items[*].metadata.labels.postgres-operator\.crunchydata\.com/instance}'

pgsql-instance1-ndwp

此时从Pod已经切换为主Pod，测试故障转移成功，说明高可用没有问题！

Q/A：
如果 PGO 在停机事件期间停机怎么办？

故障转移仍然会发生：Postgres HA 系统独立于 PGO 工作，并且可以维持自己的正常运行时间。PGO 仍需要协助一些修复方面的问题，但您的应用程序仍将保持与 Postgres 集群的读/写连接！

目录CONTENT

k8s中使用PGO部署高可用PostgreSQL

1、介绍

2、部署

3、测试 HA 集群

评论区