来源https://www.gabrielebartolini.it/articles/2026/05/cloudnativepg-and-crunchy-pgo-an-honest-opinionated-comparison/CloudNativePG 与 Crunchy PGO一个诚实且带有主观见解的比较作者:Gabriele Bartolini日期:2026年5月18日目录Crunchy 的开创性角色架构分水岭直接 Pod 管理实例管理器关于 Kubernetes API 服务器可用性镜像设计、体积与安全主版本升级备份与恢复可观测性社区健康与治理我诚实的结论本文比较了 CloudNativePG 和 Crunchy PGO这两个在 Kubernetes 上运行 PostgreSQL 时最受欢迎的开源 operator。文章涵盖架构、镜像设计、备份策略、主版本升级、可观测性、许可和社区健康。作为 CloudNativePG 的联合创始人和维护者我事先声明我不声称自己是中立的。我能提供的是基于多年在该项目上的日常工作和对这个领域 Crunchy Data 所构建成就的真正尊重从而形成的知情偏见。多年来我一直抵制直接比较 CloudNativePG 和 Crunchy PGO。从我的位置来看写这种文章感觉不太合适。但在两个项目都成熟了几年之后特别是自从 Crunchy Data 被 Snowflake 收购以来我越来越频繁地被问到这两个 operator 如何比较。我现在认为时机成熟了。上周我写了“食谱 24”来回答如何迁移这个实际问题。这篇帖子尝试做一件更难的事情诚实地评估这两个 operator 为何不同以及这些差异对在 Kubernetes 上为 PostgreSQL 选择长期平台的团队意味着什么。我将承认 Crunchy 的遗产解释我认为使 CloudNativePG 成为更坚实基础的那些架构选择指出存在的数据并标明我个人观点不可避免的主观领域。我不会假装这是一份中立的文档。Crunchy 的开创性角色Crunchy Data 于 2017 年 3 月发布了第一个用于 Kubernetes 的 PostgreSQL operator距离 Kubernetes 本身问世不到两年距离 CoreOS 引入 operator 模式也仅过去不久。这确实具有超前意识。我在 2ndQuadrant后来被 EDB 收购的团队在此期间密切观察了生态系统但选择等待主要是由于 Kubernetes 存储原语尚不成熟。关键转折点出现在 2019 年 4 月Kubernetes 1.14 引入了对本地持久卷的稳定支持。我们的第一个云原生 operatorCloud Native BDR随后不久发布它是为主动-主动工作负载构建的使用了 2ndQuadrant 的双向复制技术现在的 EDB Postgres Distributed。最终成为 CloudNativePG 的第一次提交是在 2020 年 2 月 18 日由 Leonardo Cecchi、Marco Nenciarini 和我本人完成。这里并不是要贬低 Crunchy 的成就。PGO 在大多数人还认为这是个不靠谱的想法时就已经在 Kubernetes 上运行生产级 PostgreSQL 了并且有大量团队在其上构建了基础设施。在进行任何比较之前这一记录值得被承认。架构分水岭这两个 operator 之间最重要的区别不是一个特性。而是一种关于管理 PostgreSQL 高可用性的智能应该放在哪里的哲学。Crunchy PGO 将 HA 委托给 Patroni这是一个基于 Python 的分布式 HA 管理器作为每个 Pod 内的一个进程运行。Patroni 是一个备受尊敬的项目在我看来它是传统 Linux 环境下 PostgreSQL 集群管理的先进技术。Patroni 通过一个分布式配置存储可以是 etcd、Consul、ZooKeeper 或 Kubernetes 本身来协调故障转移而 PGO 的主要角色是配置和供给 Patroni 所需的东西。这个 operator 是在 Patroni 之上构建的而不是取代它。在 Kubernetes 环境中这意味着同时运行两个复杂的分布式系统这是一个完全可以辩护的选择尽管它带来了我们的团队权衡时考量不同的取舍。在 2024 年盐湖城的 KubeCon 上一位 Crunchy 的工程师直接解释了他们的理由当 Patroni 已经存在并且经过实战检验时为什么要从头编写复杂的分布式系统代码这是一个合理的立场我理解它。我们的团队只是得出了不同的结论。我们做了一个根本不同的决定信任 Kubernetes API 正是为了其设计目的管理分布式系统和应用程序并在 operator 中原生编写 HA 逻辑而不是将其委托给一个单独的工具。CloudNativePG 的设计大约晚了三年其核心就是这个前提Kubernetes 是控制平面operator 应该直接利用它。没有 Patroni没有用于 HA 的 etcd 依赖也没有与 Kubernetes 并行的 HA 框架。Kubernetes API 服务器是每个资源状态的唯一真实来源包括主/备拓扑。控制器的文档和技术架构文档描述了这在实践中是什么样子的。直接 Pod 管理CloudNativePG 不使用 StatefulSet。它直接管理 Pod 和 PVC 资源这赋予了 operator StatefulSet 无法提供的细粒度控制。当发生故障转移时CloudNativePG 会提升具有最高日志序列号的副本确保无论其名称或索引如何最新的实例成为新的主实例。绑定 StatefulSet 的序号逻辑无法原生表达这种决策它需要一个额外的协调层而这正是 Patroni 在 PGO 案例中所提供的。直接 Pod 管理还使 CloudNativePG 能够按正确顺序协调整个集群的配置更改包括那些在应用任何更改之前必须在备用节点上设置等于或高于主节点值的参数。使用 StatefulSet这种协调排序需要在该原语之上添加额外的逻辑。实例管理器CloudNativePG 中没有 HA 管理 sidecar。管理逻辑作为一个实例管理器运行这是一个作为 PostgreSQL 容器内 PID 1 运行的 Go 二进制文件。它处理整个 Postgres 生命周期参与自我修复并直接与 Kubernetes API 通信以报告健康状况、复制延迟和位置。这一点特别重要因为实例管理器通过健康探针与 Kubelet 交互这些探针是数据库感知的而不是通用的。启动探针防止 Kubelet 在初始化或恢复期间重启 Pod。就绪探针检查实例是否准备好服务流量包括在配置时检查副本上的复制延迟。主节点上的存活探针执行隔离检查如果 API 服务器和对等实例同时变得不可达探针会故意失败导致 Kubelet 重启 Pod 并将隔离的主节点下线。这降低了脑裂场景的风险尽管在使用同步复制时不会出现这种情况。Patroni 在其 3.0.0 版本中通过其 DCS 故障安全模式引入了类似的能力。CloudNativePG 以 Kubernetes 的方式独立实现了相同的概念它不是通过 REST API 查询对等节点而是让存活探针和 Kubelet 来完成工作。导致我们实现的相关讨论在此处这是一个很好的例子说明了如何根据你的执行环境使用根本不同的原语来解决相同的问题。关于 Kubernetes API 服务器可用性对这种架构的一个常见反对意见是当 Kubernetes API 服务器宕机时会发生什么CloudNativePG 的答案是暂停故障转移操作并优先考虑数据保护。但我认为这个问题值得一个坦率的回答而不仅仅是一个技术性的回答。这里需要精确说明。正如 Kubernetes 文档所指出的当 API 服务器不可用时现有的 Pod 会继续运行因为 Kubelet 在本地管理它们。停止的是调度、协调和 operator 逻辑包括 CloudNativePG 的控制器。没有 API 服务器CloudNativePG 无法对集群做出全局决策例如触发故障转移并且在没有可靠的全集群状态视图的情况下尝试这样做会引入风险而不是消除风险。因此暂停这些决策并优先考虑数据保护与其说是一个限制不如说是一个信任单一权威真实来源的设计的诚实结果。同样值得注意的是Kubernetes 本身旨在通过跨多个可用区部署来解决控制平面可用性风险因此在配置正确的集群中API 服务器完全宕机是一个越来越不可能发生的事件。我们认为对于控制平面本身面临风险的场景更健壮的答案是弹性的多区域架构CloudNativePG 通过其副本集群的分布式拓扑来支持这一点。根据我们的经验这种方法带来的实际后果是更小的操作面没有额外的分布式系统需要与 operator 一起监控、调试或升级并且故障隐藏的地方更少。话虽如此已经非常熟悉 Patroni 的团队可能会发现操作上的转换需要对其心智模型进行一些调整。镜像设计、体积与安全在操作镜像中除了 PostgreSQL 之外不嵌入任何东西的架构选择对镜像大小和安全态势有直接影响。Crunchy 的操作镜像将 Patroni及其 Python 运行时、pgBackRest、pgAudit、pgvector、TimescaleDB、pg_cron、pg_partman 和其他扩展捆绑到一个基于 UBI9 的镜像中因为它们都需要共置以便 Patroni 运行。CloudNativePG 的最小镜像仅包含 PostgreSQL扩展在运行时通过 Kubernetes ImageVolume 功能作为 OCI 镜像卷交付需要 PostgreSQL 18 或更高版本以及 Kubernetes 1.35 或更高版本其中 ImageVolume 默认启用在 1.33 和 1.34 上可以通过特性门控启用这在 CNPG 食谱 23 中有详细介绍。添加或删除扩展是对集群清单的声明性更改它不需要不同的基础镜像并且关键的是不会破坏不可变性。以下数字来自docker scout quickview对当前镜像的检查镜像包数量严重漏洞高危漏洞crunchy-postgres:ubi9-17.9-26106252156postgresql:18-minimal-trixie14004CNPG 的minimal-trixie镜像包含 140 个包而 Crunchy 源镜像为 625 个零个严重漏洞对比两个四个高危漏洞对比 156 个。它的 Debian Trixie Slim 基础镜像本身没有已知漏洞。包数量在操作上很重要更少的包意味着任何未来披露事件的爆炸半径更小需要审计的列表也更短。CNPG 最小镜像还附带完整的软件物料清单来源证明。关于镜像许可的话题Crunchy Data 的容器镜像历史上是根据 Crunchy Data 开发者计划分发的该计划限制超过 50 名员工的组织在生产中使用。operator 本身是开源的它默认使用的镜像并非总是如此。在 Snowflake 收购后这是否发生了变化需要在做出采购决定前直接与 Crunchy 核实。CloudNativePG 生态系统中的每个镜像——operator、操作镜像、扩展镜像——都是完全开源的采用 Apache License 2.0。主版本升级这是 CloudNativePG 投入巨大的一个领域也是差异具体的领域。Crunchy PGO v6 通过专用的PGUpgradeCRD 提供主版本升级。集群必须完全关闭才能进行升级然后pg_upgrade运行完成之后集群才能重新上线。停机时间窗口由关闭和重启周期驱动而非数据集大小因为pg_upgrade默认使用硬链接无论数据量大小都能快速完成。该过程在文档中被明确描述为永久性的没有声明性的回滚路径如果担心回滚问题Crunchy 建议保留旧版本的集群副本。升级期间不支持备用集群必须在之后删除并从头重建。一些升级后任务也需要手动干预运行ANALYZE、升级扩展和清理旧数据目录。正如我在“食谱 24”中所示CloudNativePG 提供了两条路径。离线路径通过内置的bootstrap.initdb.import机制使用pg_dump/pg_restore完全是声明性的在集群引导时执行。在线路径使用原生 PostgreSQL 逻辑复制和声明性的发布与订阅资源将切换窗口减少到几秒钟无论数据集大小如何。第三条路径通过pg_upgrade进行的就地主版本升级已在 CNPG 食谱 17 中引入并支持在有副本时自动回滚。这三条路径今天都可用。备份与恢复我们对 PostgreSQL 备份的参与远远早于 CloudNativePG。Barman 起源于 2ndQuadrant 团队并且是最广泛使用的 PostgreSQL 物理备份和 WAL 归档工具之一。这些经验从一开始就塑造了我们在 CloudNativePG 中处理备份的方式。Crunchy PGO 将 pgBackRest 嵌入到操作镜像中并通过PostgresCluster规范进行配置。pgBackRest 是一个优秀的工具。嵌入模型的结果是备份代码和数据库代码是耦合的pgBackRest 的更新需要一个新的操作镜像。CloudNativePG 支持两种备份方法在文档中有详细比较。第一种是 Kubernetes 本地的卷快照这是唯一由 operator 直接处理的备份方法。卷快照支持冷备份和热备份尽管热备份需要 WAL 归档到位以实现一致性恢复。在 2023 年亚特兰大的 KubeCon 上我们演示了使用这种方法在 2 分钟内恢复一个 4.5 TB 的数据库。第二种是 CNPG-I一个插件接口它完全将备份工具与 operator 解耦。Barman Cloud 插件是参考实现也是目前唯一由社区维护的实现但该接口是开放的没有什么能阻止社区或组织为其他工具如 pgBackRest 或 WAL-G编写插件。可观测性两个 operator 都为 Prometheus 提供 PostgreSQL 指标。CloudNativePG 更进一步支持在 ConfigMap 或 Secret 中定义的声明性自定义指标并由集群资源引用允许团队将应用程序特定的查询作为 Kubernetes 资源与集群本身一起管理。监控文档和社区维护的 Grafana 仪表板涵盖了完整的默认指标集。在日志方面CloudNativePG 管理的每个容器都以 JSON 格式将结构化日志写入stdout如日志文档所述。这是一个刻意的设计选择它不需要在 Pod 内部进行日志文件管理并且可以直接与任何 Kubernetes 级别的日志聚合解决方案集成无论是 EFK 堆栈、Loki、云提供商的本地产品还是诸如 Logging operator 之类的专用 operator。社区健康与治理这一节是我最明显有利益冲突的地方所以我会让数据说话而不是发表评论。我将 Patroni 包含在下面的图表中不是作为 operator 领域的直接竞争对手而是作为更广泛的 PostgreSQL 采用的参考点。Patroni 是传统 Linux 环境中 PostgreSQL 的主要 HA 解决方案并且拥有自己庞大的社区。看到 CloudNativePG 接近并超越其星标数可以感受到云原生 Postgres 运动背后的动力这超越了狭义的 operator 范畴。CloudNativePG 的星标增长完全是自然的没有星标农场活动没有人为的放大。[此处假设有图表标题为Patroni、CloudNativePG 和 Crunchy PGO 的 GitHub 星标历史]下表涵盖了截至 2026 年 5 月的 18 个月内的指标。指标PGO (CrunchyData)CloudNativePGGitHub 星标主仓库4.4k8.6k整个组织约 10k总提交数4,4184,662较新的项目提交率历史平均约 480/年约 745/年提交率过去 3 年约 235/年约 894/年开放的拉取请求约 18约 174贡献者供应商内部200 来自多个组织GA 发布过去 18 个月约 4当前分支约 18一致节奏最长发布间隔过去 18 个月8 个月2025 年 3 月 - 11 月无间隔6-8 周节奏公开治理无CNCFGOVERNANCE.md, MAINTAINERS.mdCNCF 成员资格无沙箱等待孵化中公开路线图无ROADMAP.mdOpenSSF 最佳实践基线无是SECURITY-INSIGHTS.yml无是威胁评估无是ADOPTERS.md无是文档专有门户完全开放PGO 发布历史中 8 个月的间隔2025 年 3 月到 11 月在数据中很突出。这是反映了故意的整合阶段还是更结构性的问题我真的不知道。我能说的是这种节奏、Snowflake 的收购以及缺乏公开治理的组合正是团队在向我询问他们的选择时最常提出的问题。我也会坦诚地说明 CloudNativePG 方面的情况。174 个开放的拉取请求是一个很高的数字它反映了一个真正的挑战项目增长速度快于我们当前审查和合并的能力。部分增长可归因于 AI 生成贡献的增加——这是我们在开源生态系统中观察到的一种模式。我们的 AI 政策是明确的人类贡献者对他们提交的所有内容承担全部责任维护者可能会关闭低质量的 AI 生成的 PR 而不进行详细评审我们重视一个经过仔细考虑的贡献胜过十个肤浅的贡献。除此之外我们正处于一个过渡阶段正在积极减少三个方面的技术债务这些方面目前消耗了我们大部分的认知预算扩展镜像支持工作已接近完成、从核心 Barman Cloud 集成迁移到插件模型也接近完成以及重构端到端测试套件以与 CNPG-I 插件协同工作。一旦这些工作落地审查范围将大大缩小积压问题也应随之解决。CloudNativePG 是一个 CNCF 沙箱项目目前正在排队等待孵化其健康指标在 LFX Insights 仪表板上公开可见。主仓库有 8.6k 个星标在 CloudNativePG GitHub 组织的所有仓库中总数接近 10,000。大部分开发工作仍由 EDB 推动这在 CNCF 成熟度的这个阶段是完全预期的。孵化是项目的下一个里程碑主要要求是展示广泛的生产采用——鉴于 ADOPTERS.md 文件的深度以及我与汇丰银行的 Laurent Parodi 在 KubeCon 上的演讲我并不担心这一点。毕业即第三步是多组织贡献成为正式标准的地方这是我们在达到孵化希望如此之后需要做的工作。治理模型、路线图和安全策略都是公开的。采纳者包括 IBM、Google Cloud、Microsoft Azure、Tesla、GEICO Tech、Novo Nordisk 和 Mirakl8 TB300 集群等列在 ADOPTERS.md 中。安全透明度也是一个刻意的关注点。开源安全基金会一直是这项工作的关键合作伙伴。CloudNativePG 符合 OpenSSF 最佳实践基线在 2026 年于阿姆斯特丹举行的 KubeCon CloudNativeCon Europe 2026 上的 OpenSSF 安全大满贯活动中CloudNativePG 是仅有的三个获得全部五个可用徽章清洁工、编年史家、检查员、机械师和防御者的项目之一。这项工作产生了一个 SECURITY-INSIGHTS.yml 文件和一个项目的 Gemara 威胁评估等成果。这两者都与正在或准备根据欧盟网络弹性法案运营的组织直接相关该法案要求软件制造商在产品生命周期中展示安全尽职调查。作为一个开源社区项目拥有这些工件并非理所当然它反映了投入 CloudNativePG 维护方式的那种长期思考。我诚实的结论Crunchy Data 是开拓者并且构建了实实在在的东西。我对此抱有真诚的敬意。但 2026 年的格局与 2017 年不同Kubernetes 是一个成熟的控制平面operator 模式已广为人知在我看来如今在数据库 Pod 内运行并行分布式系统的权衡比那时更重要。CloudNativePG 从一开始就旨在利用 Kubernetes 实际提供的东西我相信这一决定体现在从架构到镜像体积再到备份模型的方方面面。如果你今天正在评估 PostgreSQL operator并且你的主要关切是长期的架构稳健性、开放的治理以及一个拥有显著发展势头的社区我认为这里提供的数据值得仔细反思。这是我的观点我深知它并非中立。作为一个项目的维护者和创始人它不可能是中立的如果我们最初的想法不同现在就不会有 CloudNativePG 了。最终选择权在你手中。我诚实的建议尽管存在偏见是尝试两者并决定哪个最适合你的团队、你的工作负载和你的组织。这就是做出好的工程决策的方式。请继续关注即将发布的食谱如需最新更新请考虑订阅我的 LinkedIn 和 Twitter 频道。如果你觉得这篇文章信息丰富请随时使用下面提供的链接在你的社交媒体网络中分享。非常感谢你的支持本文在 Claude (Anthropic) 的协助下起草和完善。所有技术内容、更正和编辑方向均由作者本人负责。作者Gabriele BartoliniEDB 副总裁、Kubernetes 首席架构师 | PostgreSQL 贡献者 | DoK 大使 | CloudNativePG 维护者 | 前 2ndQuadrant联合创始人
DeepSeek总结的CloudNativePG 与 Crunchy PGO：一个诚实且带有主观见解的比较
来源https://www.gabrielebartolini.it/articles/2026/05/cloudnativepg-and-crunchy-pgo-an-honest-opinionated-comparison/CloudNativePG 与 Crunchy PGO一个诚实且带有主观见解的比较作者:Gabriele Bartolini日期:2026年5月18日目录Crunchy 的开创性角色架构分水岭直接 Pod 管理实例管理器关于 Kubernetes API 服务器可用性镜像设计、体积与安全主版本升级备份与恢复可观测性社区健康与治理我诚实的结论本文比较了 CloudNativePG 和 Crunchy PGO这两个在 Kubernetes 上运行 PostgreSQL 时最受欢迎的开源 operator。文章涵盖架构、镜像设计、备份策略、主版本升级、可观测性、许可和社区健康。作为 CloudNativePG 的联合创始人和维护者我事先声明我不声称自己是中立的。我能提供的是基于多年在该项目上的日常工作和对这个领域 Crunchy Data 所构建成就的真正尊重从而形成的知情偏见。多年来我一直抵制直接比较 CloudNativePG 和 Crunchy PGO。从我的位置来看写这种文章感觉不太合适。但在两个项目都成熟了几年之后特别是自从 Crunchy Data 被 Snowflake 收购以来我越来越频繁地被问到这两个 operator 如何比较。我现在认为时机成熟了。上周我写了“食谱 24”来回答如何迁移这个实际问题。这篇帖子尝试做一件更难的事情诚实地评估这两个 operator 为何不同以及这些差异对在 Kubernetes 上为 PostgreSQL 选择长期平台的团队意味着什么。我将承认 Crunchy 的遗产解释我认为使 CloudNativePG 成为更坚实基础的那些架构选择指出存在的数据并标明我个人观点不可避免的主观领域。我不会假装这是一份中立的文档。Crunchy 的开创性角色Crunchy Data 于 2017 年 3 月发布了第一个用于 Kubernetes 的 PostgreSQL operator距离 Kubernetes 本身问世不到两年距离 CoreOS 引入 operator 模式也仅过去不久。这确实具有超前意识。我在 2ndQuadrant后来被 EDB 收购的团队在此期间密切观察了生态系统但选择等待主要是由于 Kubernetes 存储原语尚不成熟。关键转折点出现在 2019 年 4 月Kubernetes 1.14 引入了对本地持久卷的稳定支持。我们的第一个云原生 operatorCloud Native BDR随后不久发布它是为主动-主动工作负载构建的使用了 2ndQuadrant 的双向复制技术现在的 EDB Postgres Distributed。最终成为 CloudNativePG 的第一次提交是在 2020 年 2 月 18 日由 Leonardo Cecchi、Marco Nenciarini 和我本人完成。这里并不是要贬低 Crunchy 的成就。PGO 在大多数人还认为这是个不靠谱的想法时就已经在 Kubernetes 上运行生产级 PostgreSQL 了并且有大量团队在其上构建了基础设施。在进行任何比较之前这一记录值得被承认。架构分水岭这两个 operator 之间最重要的区别不是一个特性。而是一种关于管理 PostgreSQL 高可用性的智能应该放在哪里的哲学。Crunchy PGO 将 HA 委托给 Patroni这是一个基于 Python 的分布式 HA 管理器作为每个 Pod 内的一个进程运行。Patroni 是一个备受尊敬的项目在我看来它是传统 Linux 环境下 PostgreSQL 集群管理的先进技术。Patroni 通过一个分布式配置存储可以是 etcd、Consul、ZooKeeper 或 Kubernetes 本身来协调故障转移而 PGO 的主要角色是配置和供给 Patroni 所需的东西。这个 operator 是在 Patroni 之上构建的而不是取代它。在 Kubernetes 环境中这意味着同时运行两个复杂的分布式系统这是一个完全可以辩护的选择尽管它带来了我们的团队权衡时考量不同的取舍。在 2024 年盐湖城的 KubeCon 上一位 Crunchy 的工程师直接解释了他们的理由当 Patroni 已经存在并且经过实战检验时为什么要从头编写复杂的分布式系统代码这是一个合理的立场我理解它。我们的团队只是得出了不同的结论。我们做了一个根本不同的决定信任 Kubernetes API 正是为了其设计目的管理分布式系统和应用程序并在 operator 中原生编写 HA 逻辑而不是将其委托给一个单独的工具。CloudNativePG 的设计大约晚了三年其核心就是这个前提Kubernetes 是控制平面operator 应该直接利用它。没有 Patroni没有用于 HA 的 etcd 依赖也没有与 Kubernetes 并行的 HA 框架。Kubernetes API 服务器是每个资源状态的唯一真实来源包括主/备拓扑。控制器的文档和技术架构文档描述了这在实践中是什么样子的。直接 Pod 管理CloudNativePG 不使用 StatefulSet。它直接管理 Pod 和 PVC 资源这赋予了 operator StatefulSet 无法提供的细粒度控制。当发生故障转移时CloudNativePG 会提升具有最高日志序列号的副本确保无论其名称或索引如何最新的实例成为新的主实例。绑定 StatefulSet 的序号逻辑无法原生表达这种决策它需要一个额外的协调层而这正是 Patroni 在 PGO 案例中所提供的。直接 Pod 管理还使 CloudNativePG 能够按正确顺序协调整个集群的配置更改包括那些在应用任何更改之前必须在备用节点上设置等于或高于主节点值的参数。使用 StatefulSet这种协调排序需要在该原语之上添加额外的逻辑。实例管理器CloudNativePG 中没有 HA 管理 sidecar。管理逻辑作为一个实例管理器运行这是一个作为 PostgreSQL 容器内 PID 1 运行的 Go 二进制文件。它处理整个 Postgres 生命周期参与自我修复并直接与 Kubernetes API 通信以报告健康状况、复制延迟和位置。这一点特别重要因为实例管理器通过健康探针与 Kubelet 交互这些探针是数据库感知的而不是通用的。启动探针防止 Kubelet 在初始化或恢复期间重启 Pod。就绪探针检查实例是否准备好服务流量包括在配置时检查副本上的复制延迟。主节点上的存活探针执行隔离检查如果 API 服务器和对等实例同时变得不可达探针会故意失败导致 Kubelet 重启 Pod 并将隔离的主节点下线。这降低了脑裂场景的风险尽管在使用同步复制时不会出现这种情况。Patroni 在其 3.0.0 版本中通过其 DCS 故障安全模式引入了类似的能力。CloudNativePG 以 Kubernetes 的方式独立实现了相同的概念它不是通过 REST API 查询对等节点而是让存活探针和 Kubelet 来完成工作。导致我们实现的相关讨论在此处这是一个很好的例子说明了如何根据你的执行环境使用根本不同的原语来解决相同的问题。关于 Kubernetes API 服务器可用性对这种架构的一个常见反对意见是当 Kubernetes API 服务器宕机时会发生什么CloudNativePG 的答案是暂停故障转移操作并优先考虑数据保护。但我认为这个问题值得一个坦率的回答而不仅仅是一个技术性的回答。这里需要精确说明。正如 Kubernetes 文档所指出的当 API 服务器不可用时现有的 Pod 会继续运行因为 Kubelet 在本地管理它们。停止的是调度、协调和 operator 逻辑包括 CloudNativePG 的控制器。没有 API 服务器CloudNativePG 无法对集群做出全局决策例如触发故障转移并且在没有可靠的全集群状态视图的情况下尝试这样做会引入风险而不是消除风险。因此暂停这些决策并优先考虑数据保护与其说是一个限制不如说是一个信任单一权威真实来源的设计的诚实结果。同样值得注意的是Kubernetes 本身旨在通过跨多个可用区部署来解决控制平面可用性风险因此在配置正确的集群中API 服务器完全宕机是一个越来越不可能发生的事件。我们认为对于控制平面本身面临风险的场景更健壮的答案是弹性的多区域架构CloudNativePG 通过其副本集群的分布式拓扑来支持这一点。根据我们的经验这种方法带来的实际后果是更小的操作面没有额外的分布式系统需要与 operator 一起监控、调试或升级并且故障隐藏的地方更少。话虽如此已经非常熟悉 Patroni 的团队可能会发现操作上的转换需要对其心智模型进行一些调整。镜像设计、体积与安全在操作镜像中除了 PostgreSQL 之外不嵌入任何东西的架构选择对镜像大小和安全态势有直接影响。Crunchy 的操作镜像将 Patroni及其 Python 运行时、pgBackRest、pgAudit、pgvector、TimescaleDB、pg_cron、pg_partman 和其他扩展捆绑到一个基于 UBI9 的镜像中因为它们都需要共置以便 Patroni 运行。CloudNativePG 的最小镜像仅包含 PostgreSQL扩展在运行时通过 Kubernetes ImageVolume 功能作为 OCI 镜像卷交付需要 PostgreSQL 18 或更高版本以及 Kubernetes 1.35 或更高版本其中 ImageVolume 默认启用在 1.33 和 1.34 上可以通过特性门控启用这在 CNPG 食谱 23 中有详细介绍。添加或删除扩展是对集群清单的声明性更改它不需要不同的基础镜像并且关键的是不会破坏不可变性。以下数字来自docker scout quickview对当前镜像的检查镜像包数量严重漏洞高危漏洞crunchy-postgres:ubi9-17.9-26106252156postgresql:18-minimal-trixie14004CNPG 的minimal-trixie镜像包含 140 个包而 Crunchy 源镜像为 625 个零个严重漏洞对比两个四个高危漏洞对比 156 个。它的 Debian Trixie Slim 基础镜像本身没有已知漏洞。包数量在操作上很重要更少的包意味着任何未来披露事件的爆炸半径更小需要审计的列表也更短。CNPG 最小镜像还附带完整的软件物料清单来源证明。关于镜像许可的话题Crunchy Data 的容器镜像历史上是根据 Crunchy Data 开发者计划分发的该计划限制超过 50 名员工的组织在生产中使用。operator 本身是开源的它默认使用的镜像并非总是如此。在 Snowflake 收购后这是否发生了变化需要在做出采购决定前直接与 Crunchy 核实。CloudNativePG 生态系统中的每个镜像——operator、操作镜像、扩展镜像——都是完全开源的采用 Apache License 2.0。主版本升级这是 CloudNativePG 投入巨大的一个领域也是差异具体的领域。Crunchy PGO v6 通过专用的PGUpgradeCRD 提供主版本升级。集群必须完全关闭才能进行升级然后pg_upgrade运行完成之后集群才能重新上线。停机时间窗口由关闭和重启周期驱动而非数据集大小因为pg_upgrade默认使用硬链接无论数据量大小都能快速完成。该过程在文档中被明确描述为永久性的没有声明性的回滚路径如果担心回滚问题Crunchy 建议保留旧版本的集群副本。升级期间不支持备用集群必须在之后删除并从头重建。一些升级后任务也需要手动干预运行ANALYZE、升级扩展和清理旧数据目录。正如我在“食谱 24”中所示CloudNativePG 提供了两条路径。离线路径通过内置的bootstrap.initdb.import机制使用pg_dump/pg_restore完全是声明性的在集群引导时执行。在线路径使用原生 PostgreSQL 逻辑复制和声明性的发布与订阅资源将切换窗口减少到几秒钟无论数据集大小如何。第三条路径通过pg_upgrade进行的就地主版本升级已在 CNPG 食谱 17 中引入并支持在有副本时自动回滚。这三条路径今天都可用。备份与恢复我们对 PostgreSQL 备份的参与远远早于 CloudNativePG。Barman 起源于 2ndQuadrant 团队并且是最广泛使用的 PostgreSQL 物理备份和 WAL 归档工具之一。这些经验从一开始就塑造了我们在 CloudNativePG 中处理备份的方式。Crunchy PGO 将 pgBackRest 嵌入到操作镜像中并通过PostgresCluster规范进行配置。pgBackRest 是一个优秀的工具。嵌入模型的结果是备份代码和数据库代码是耦合的pgBackRest 的更新需要一个新的操作镜像。CloudNativePG 支持两种备份方法在文档中有详细比较。第一种是 Kubernetes 本地的卷快照这是唯一由 operator 直接处理的备份方法。卷快照支持冷备份和热备份尽管热备份需要 WAL 归档到位以实现一致性恢复。在 2023 年亚特兰大的 KubeCon 上我们演示了使用这种方法在 2 分钟内恢复一个 4.5 TB 的数据库。第二种是 CNPG-I一个插件接口它完全将备份工具与 operator 解耦。Barman Cloud 插件是参考实现也是目前唯一由社区维护的实现但该接口是开放的没有什么能阻止社区或组织为其他工具如 pgBackRest 或 WAL-G编写插件。可观测性两个 operator 都为 Prometheus 提供 PostgreSQL 指标。CloudNativePG 更进一步支持在 ConfigMap 或 Secret 中定义的声明性自定义指标并由集群资源引用允许团队将应用程序特定的查询作为 Kubernetes 资源与集群本身一起管理。监控文档和社区维护的 Grafana 仪表板涵盖了完整的默认指标集。在日志方面CloudNativePG 管理的每个容器都以 JSON 格式将结构化日志写入stdout如日志文档所述。这是一个刻意的设计选择它不需要在 Pod 内部进行日志文件管理并且可以直接与任何 Kubernetes 级别的日志聚合解决方案集成无论是 EFK 堆栈、Loki、云提供商的本地产品还是诸如 Logging operator 之类的专用 operator。社区健康与治理这一节是我最明显有利益冲突的地方所以我会让数据说话而不是发表评论。我将 Patroni 包含在下面的图表中不是作为 operator 领域的直接竞争对手而是作为更广泛的 PostgreSQL 采用的参考点。Patroni 是传统 Linux 环境中 PostgreSQL 的主要 HA 解决方案并且拥有自己庞大的社区。看到 CloudNativePG 接近并超越其星标数可以感受到云原生 Postgres 运动背后的动力这超越了狭义的 operator 范畴。CloudNativePG 的星标增长完全是自然的没有星标农场活动没有人为的放大。[此处假设有图表标题为Patroni、CloudNativePG 和 Crunchy PGO 的 GitHub 星标历史]下表涵盖了截至 2026 年 5 月的 18 个月内的指标。指标PGO (CrunchyData)CloudNativePGGitHub 星标主仓库4.4k8.6k整个组织约 10k总提交数4,4184,662较新的项目提交率历史平均约 480/年约 745/年提交率过去 3 年约 235/年约 894/年开放的拉取请求约 18约 174贡献者供应商内部200 来自多个组织GA 发布过去 18 个月约 4当前分支约 18一致节奏最长发布间隔过去 18 个月8 个月2025 年 3 月 - 11 月无间隔6-8 周节奏公开治理无CNCFGOVERNANCE.md, MAINTAINERS.mdCNCF 成员资格无沙箱等待孵化中公开路线图无ROADMAP.mdOpenSSF 最佳实践基线无是SECURITY-INSIGHTS.yml无是威胁评估无是ADOPTERS.md无是文档专有门户完全开放PGO 发布历史中 8 个月的间隔2025 年 3 月到 11 月在数据中很突出。这是反映了故意的整合阶段还是更结构性的问题我真的不知道。我能说的是这种节奏、Snowflake 的收购以及缺乏公开治理的组合正是团队在向我询问他们的选择时最常提出的问题。我也会坦诚地说明 CloudNativePG 方面的情况。174 个开放的拉取请求是一个很高的数字它反映了一个真正的挑战项目增长速度快于我们当前审查和合并的能力。部分增长可归因于 AI 生成贡献的增加——这是我们在开源生态系统中观察到的一种模式。我们的 AI 政策是明确的人类贡献者对他们提交的所有内容承担全部责任维护者可能会关闭低质量的 AI 生成的 PR 而不进行详细评审我们重视一个经过仔细考虑的贡献胜过十个肤浅的贡献。除此之外我们正处于一个过渡阶段正在积极减少三个方面的技术债务这些方面目前消耗了我们大部分的认知预算扩展镜像支持工作已接近完成、从核心 Barman Cloud 集成迁移到插件模型也接近完成以及重构端到端测试套件以与 CNPG-I 插件协同工作。一旦这些工作落地审查范围将大大缩小积压问题也应随之解决。CloudNativePG 是一个 CNCF 沙箱项目目前正在排队等待孵化其健康指标在 LFX Insights 仪表板上公开可见。主仓库有 8.6k 个星标在 CloudNativePG GitHub 组织的所有仓库中总数接近 10,000。大部分开发工作仍由 EDB 推动这在 CNCF 成熟度的这个阶段是完全预期的。孵化是项目的下一个里程碑主要要求是展示广泛的生产采用——鉴于 ADOPTERS.md 文件的深度以及我与汇丰银行的 Laurent Parodi 在 KubeCon 上的演讲我并不担心这一点。毕业即第三步是多组织贡献成为正式标准的地方这是我们在达到孵化希望如此之后需要做的工作。治理模型、路线图和安全策略都是公开的。采纳者包括 IBM、Google Cloud、Microsoft Azure、Tesla、GEICO Tech、Novo Nordisk 和 Mirakl8 TB300 集群等列在 ADOPTERS.md 中。安全透明度也是一个刻意的关注点。开源安全基金会一直是这项工作的关键合作伙伴。CloudNativePG 符合 OpenSSF 最佳实践基线在 2026 年于阿姆斯特丹举行的 KubeCon CloudNativeCon Europe 2026 上的 OpenSSF 安全大满贯活动中CloudNativePG 是仅有的三个获得全部五个可用徽章清洁工、编年史家、检查员、机械师和防御者的项目之一。这项工作产生了一个 SECURITY-INSIGHTS.yml 文件和一个项目的 Gemara 威胁评估等成果。这两者都与正在或准备根据欧盟网络弹性法案运营的组织直接相关该法案要求软件制造商在产品生命周期中展示安全尽职调查。作为一个开源社区项目拥有这些工件并非理所当然它反映了投入 CloudNativePG 维护方式的那种长期思考。我诚实的结论Crunchy Data 是开拓者并且构建了实实在在的东西。我对此抱有真诚的敬意。但 2026 年的格局与 2017 年不同Kubernetes 是一个成熟的控制平面operator 模式已广为人知在我看来如今在数据库 Pod 内运行并行分布式系统的权衡比那时更重要。CloudNativePG 从一开始就旨在利用 Kubernetes 实际提供的东西我相信这一决定体现在从架构到镜像体积再到备份模型的方方面面。如果你今天正在评估 PostgreSQL operator并且你的主要关切是长期的架构稳健性、开放的治理以及一个拥有显著发展势头的社区我认为这里提供的数据值得仔细反思。这是我的观点我深知它并非中立。作为一个项目的维护者和创始人它不可能是中立的如果我们最初的想法不同现在就不会有 CloudNativePG 了。最终选择权在你手中。我诚实的建议尽管存在偏见是尝试两者并决定哪个最适合你的团队、你的工作负载和你的组织。这就是做出好的工程决策的方式。请继续关注即将发布的食谱如需最新更新请考虑订阅我的 LinkedIn 和 Twitter 频道。如果你觉得这篇文章信息丰富请随时使用下面提供的链接在你的社交媒体网络中分享。非常感谢你的支持本文在 Claude (Anthropic) 的协助下起草和完善。所有技术内容、更正和编辑方向均由作者本人负责。作者Gabriele BartoliniEDB 副总裁、Kubernetes 首席架构师 | PostgreSQL 贡献者 | DoK 大使 | CloudNativePG 维护者 | 前 2ndQuadrant联合创始人
