DBA夜读·第七季第6期｜Operator生态全景——主流PostgreSQL Operator对比

第七季·《PostgreSQL on Kubernetes》 本季将开启云原生数据库的新篇章。我们将从零开始，系统性地学习如何在Kubernetes上部署、管理和运维PostgreSQL，探索云原生时代的数据库新范式。本季旨在帮助DBA和开发者掌握从传统运维到云原生架构的转型升级。

【上期回顾】

上一期我们深入学习了CloudNativePG（CNPG）——当前最受关注的PostgreSQL Operator：

• • 架构设计：不使用StatefulSet和Patroni，直接与K8s API集成
• • 核心CRD：Cluster、Pooler、Backup、ScheduledBackup
• • 备份恢复：Barman Cloud集成、对象存储备份、PITR
• • 高可用机制：内置自动故障转移、同步复制配置
• • 生产配置：资源管理、存储规划、跨可用区部署

CNPG代表了PostgreSQL on K8s的前沿方向，但并非唯一选择。本期我们将放眼整个Operator生态，对比分析五大主流Operator的优劣，帮助你做出最适合的选型决策。

【本集概览】

【第一部分】Operator生态全景

1.1 社区活跃度对比

根据GitHub Star数据（截至2026年3月），PostgreSQL Operator生态的活跃度如下：

关键洞察：

• • CNPG是增长最快的Operator，已进入CNCF沙箱
• • Zalando Operator在生产环境中验证最充分（管理4000+集群）
• • Crunchy PGO是商业化最成熟的选项

1.2 核心功能对比总览

根据Percona官方文档的对比分析：

1.3 Operator选型的核心考量

在选择Operator时，需要从以下几个维度评估：

【第二部分】CloudNativePG (CNPG)——K8s原生设计的先行者

2.1 核心定位

CNPG是由EDB（PostgreSQL生态核心贡献者）创建并维护的Operator，目前已进入CNCF沙箱。其核心设计理念是将PostgreSQL运维知识编码为Kubernetes原生资源。

2.2 架构特点

┌─────────────────────────────────────────────────────────────┐
│                    Kubernetes API Server                     │
└───────────────────────────────┬─────────────────────────────┘
                                │ 直接监听/调谐
┌───────────────────────────────▼─────────────────────────────┐
│                    CNPG Controller Manager                   │
│                      （无需etcd/Patroni）                     │
└───────────────────────────────┬─────────────────────────────┘
                                │ 直接管理
┌───────────────────────────────▼─────────────────────────────┐
│                         PostgreSQL Pods                      │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐          │
│  │ Primary     │  │ Replica     │  │ Replica     │          │
│  │ + Instance  │  │ + Instance  │  │ + Instance  │          │
│  │ Manager     │  │ Manager     │  │ Manager     │          │
│  └─────────────┘  └─────────────┘  └─────────────┘          │
└─────────────────────────────────────────────────────────────┘

关键设计决策：

1. 1. 不使用StatefulSet：直接管理Pod，获得更灵活的控制
2. 2. 不使用Patroni：自研Instance Manager，无需外部依赖
3. 3. 无etcd依赖：利用K8s API作为状态存储

2.3 优势与局限

优势：

局限：

2.4 最佳适用场景

• • ✅ 已有K8s运维能力的平台团队
• • ✅ 追求开源、无厂商锁定的组织
• • ✅ 需要纯K8s原生体验的场景
• • ❌ 需要Web UI的团队
• • ❌ 需要开发者自服务数据库分支的场景

【第三部分】Crunchy Postgres Operator (PGO)——最成熟的企业级选择

3.1 核心定位

Crunchy PGO是最老牌的PostgreSQL Operator，由Crunchy Data开发和维护，在K8s生态中拥有最长的生产验证历史。

3.2 架构特点

PGO基于Patroni实现高可用，深度集成pgBackRest进行备份管理：

apiVersion: postgres-operator.crunchydata.com/v1beta1
kind: PostgresCluster
metadata:
  name: hippo
spec:
  postgresVersion: 16
  instances:
    - name: pgha
      replicas: 3
      dataVolumeClaimSpec:
        storageClassName: fast-ssd
        resources:
          requests:
            storage: 50Gi
  backups:
    pgbackrest:
      repos:
        - name: repo1
          s3:
            bucket: my-backups
            region: us-east-1
          schedules:
            full: "0 1 * * 0"           # 每周日全量
            differential: "0 1 * * 1-6"  # 每周一到周六差异
  proxy:
    pgBouncer:
      replicas: 2

3.3 优势与局限

优势：

局限：

3.4 最佳适用场景

• • ✅ 企业级生产环境，需要商业支持
• • ✅ 已有Patroni使用经验的团队
• • ✅ 重视备份功能的场景（pgBackRest最成熟）
• • ❌ 追求轻量级、无外部依赖的团队
• • ❌ 需要Web UI的团队

【第四部分】Zalando Postgres Operator——大规模验证的Patroni方案

4.1 核心定位

Zalando Postgres Operator是社区最广泛使用的Operator之一，由欧洲最大电商平台Zalando开发，管理着4000+ PostgreSQL集群。

4.2 架构特点

Zalando Operator的核心是Spilo——一个集成了Patroni、PgBouncer和WAL-G的PostgreSQL Docker镜像：

┌─────────────────────────────────────────────────────────────┐
│                      Spilo Container                         │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐          │
│  │ PostgreSQL  │  │  Patroni    │  │  PgBouncer  │          │
│  │  (数据库)   │  │  (HA管理)   │  │  (连接池)   │          │
│  └─────────────┘  └─────────────┘  └─────────────┘          │
│  ┌─────────────┐                                           │
│  │   WAL-G     │  ← 备份工具                                │
│  └─────────────┘                                           │
└─────────────────────────────────────────────────────────────┘

部署方式：

# Helm部署（推荐）
helm repo add postgres-operator-charts \
  https://opensource.zalando.com/postgres-operator/charts/postgres-operator
helm install postgres-operator postgres-operator-charts/postgres-operator

# Kustomize部署（生产推荐）
kubectl apply -k github.com/zalando/postgres-operator/manifests

4.3 优势与局限

优势：

局限：

4.4 最佳适用场景

• • ✅ 已使用Patroni的团队
• • ✅ 大规模PostgreSQL部署（数百集群以上）
• • ✅ 运行在AWS环境
• • ❌ 追求K8s原生体验的团队
• • ❌ 需要厂商商业支持的场景

【第五部分】StackGres——全栈集成的Web UI方案

5.1 核心定位

StackGres是OnGres公司开发的全栈PostgreSQL平台，最大的特色是提供了Web UI，大大降低了运维门槛。

5.2 架构特点

StackGres的独特之处在于使用Envoy作为数据库代理：

┌─────────────────────────────────────────────────────────────┐
│                      StackGres Admin UI                      │
│                    （Web图形化管理界面）                       │
└───────────────────────────────┬─────────────────────────────┘
                                │
┌───────────────────────────────▼─────────────────────────────┐
│                         Envoy Mesh                           │
│         （服务网格代理，负责负载均衡和可观测性）               │
└───────────────────────────────┬─────────────────────────────┘
                                │
┌───────────────────────────────▼─────────────────────────────┐
│                    PostgreSQL + Patroni                      │
│                    （底层HA由Patroni实现）                    │
└─────────────────────────────────────────────────────────────┘

部署命令：

# 一键安装
kubectl apply -f 'https://sgres.io/install'

# 或使用Helm
helm install --namespace stackgres stackgres-operator \
  https://stackgres.io/downloads/stackgres-k8s/stackgres/latest/helm/stackgres-operator.tgz

5.3 优势与局限

优势：

局限：

5.4 最佳适用场景

• • ✅ 需要Web UI降低运维门槛的团队
• • ✅ 已使用Envoy服务网格的环境
• • ✅ 需要分布式存储的场景
• • ❌ 资源受限的环境
• • ❌ 对AGPL许可证敏感的企业

【第六部分】Percona Operator——Percona生态的集成方案

6.1 核心定位

Percona Operator基于Crunchy PGO 4.7构建，集成了Percona监控和管理（PMM）方案。

6.2 架构特点

Percona Operator的核心增强是PMM集成：

┌─────────────────────────────────────────────────────────────┐
│                   Percona Operator                           │
│                     （基于PGO 4.7）                          │
└───────────────────────────────┬─────────────────────────────┘
                                │
            ┌───────────────────┼───────────────────┐
            ▼                   ▼                   ▼
    ┌─────────────┐     ┌─────────────┐     ┌─────────────┐
    │  PostgreSQL │     │  pgBackRest │     │   PgBouncer │
    │  + Patroni  │     │  （备份）    │     │  （连接池）  │
    └─────────────┘     └─────────────┘     └─────────────┘
            │                   │                   │
            └───────────────────┼───────────────────┘
                                ▼
                    ┌─────────────────────┐
                    │  Percona Monitoring │
                    │  and Management     │
                    │  （PMM Web UI）      │
                    └─────────────────────┘

6.3 优势与局限

优势：

局限：

6.4 最佳适用场景

• • ✅ 已使用Percona生态（如Percona XtraDB Cluster）
• • ✅ 需要PMM监控能力
• • ✅ 对存储类型有特殊要求
• • ❌ 追求最大社区支持的团队

【第七部分】选型决策矩阵

7.1 功能对比总结

7.2 场景推荐

7.3 Operator间迁移

由于选型决策可能随时间变化，了解迁移路径也很重要：

迁移触发场景：

• • 许可证变化（如StackGres的AGPL）
• • 维护活跃度下降
• • 功能需求无法满足
• • 商业支持需求变化

迁移方式：

7.4 选型决策流程图

开始选型
    │
    ▼
是否需要Web UI？
    ├── 是 → StackGres  Percona（PMM）
    │
    ▼
是否需要商业支持？
    ├── 是 → PGO（Crunchy）/ CNPG（EDB）
    │
    ▼
是否已有Patroni经验？
    ├── 是 → Zalando  PGO
    │
    ▼
是否追求K8s原生、无依赖？
    ├── 是 → CNPG（首选）
    │
    ▼
是否Percona生态用户？
    ├── 是 → Percona Operator
    │
    ▼
是否追求最大社区支持？
    └── CNPG

【第八部分】本章总结

8.1 核心知识点速查

8.2 选型建议总结

8.3 实战练习

练习1：部署对比

# 任务：
# 1. 分别部署CNPG和Zalando Operator到两个namespace
# 2. 各创建一个3实例集群
# 3. 对比两者的CRD结构差异
# 4. 对比故障转移速度

练习2：备份功能对比

# 任务：
# 1. 为CNPG集群配置S3备份
# 2. 为PGO集群配置pgBackRest备份
# 3. 对比两者的备份格式和恢复流程

练习3：选型分析

# 任务：
# 选择一个真实业务场景（如：10人团队、无K8s经验、需要Web UI）
# 分析每个Operator的优缺点
# 给出推荐方案并说明理由

8.4 下期预告

第7期：监控与可观测性——Prometheus + Grafana

我们将深入PostgreSQL on K8s的监控体系：

• • Prometheus集成：各Operator的监控方案对比
• • 关键指标采集：连接数、TPS、复制延迟、WAL归档
• • Grafana仪表盘：CNPG官方Dashboard使用
• • 日志采集：Loki + Promtail方案
• • 告警配置：AlertManager规则设置

监控是生产环境的眼睛，下期见！

本文为学习笔记，内容基于CloudNativePG、Crunchy PGO、Zalando Operator官方文档及社区对比分析提炼总结。