最初发布于 DevToolHub，随着 CloudNativePG 的发展，我会在那里持续更新本指南。
在 Kubernetes 中运行 PostgreSQL 曾经是个糟糕的主意。有状态副本集配置复杂，持久卷不可靠，而故障转移往往意味着数据丢失。大多数团队最终都选择了托管云数据库，并认为问题已解决。
这种考量如今已经改变。CloudNativePG（云原生 PostgreSQL）——这款列入云原生计算基金会清单的 PostgreSQL 运算符——开箱即用地支持高可用性、自动故障转移、时间点恢复、连接池和流复制。到 2026 年，它已成为在 Kubernetes 上运行生产级 PostgreSQL 的标准方式，“在 K8s 上自托管”与“托管云数据库”之间的差距已显著缩小。
本指南将详细介绍完整的 CloudNativePG 设置流程——从安装运算符到部署具备生产就绪能力的集群。
完整指南涵盖的内容
- 为何选择 CloudNativePG 而非普通的有状态副本集 —— 运算符究竟做了哪些原始有状态副本集无法实现的事情
-
安装运算符 —— 使用 kubectl 和
kubectl-cnpg插件 - 部署包含 3 个实例的高可用集群 —— 1 个主节点 + 2 个备用节点，并包含 PostgreSQL 调优参数
- 连接您的应用程序 —— 读写服务与只读服务的区别，以及用于调试的端口转发
- 备份并将预写式日志归档至 S3 —— 计划备份、保留策略，以及验证归档是否正常工作
- PgBouncer 连接池 —— 池化器资源，事务模式与会话模式的区别
- 基于角色的访问控制和网络策略 —— 在 Kubernetes 层限制谁可以访问数据库
- 测试故障转移 —— 如何模拟主节点故障以及预期结果
- 时间点恢复 —— 从预写式日志归档中恢复到确切的时间戳
- 常见错误与最佳实践 —— 存储容量规划、池化模式、pg_hba.conf 默认配置、同步复制
大多数指南忽略的关键一点
必须在向数据库写入数据之前配置好预写式日志归档——您无法事后启用时间点恢复功能。请在进行首次应用程序写入之前配置好备份。
那么，您应该使用哪种设置？
K8s 上的 CloudNativePG —— 适合拥有 Kubernetes 专业知识、希望获得完全运维控制权、具备时间点恢复能力并能自定义 PostgreSQL 配置，同时不愿支付托管数据库高昂费用的团队。
托管 PostgreSQL（RDS、Cloud SQL、DigitalOcean 托管数据库）—— 在运维简便性方面仍然胜出。无需维护运算符，自动故障转移由服务商处理。
CloudNativePG 显著缩小了两者之间的差距——但正确的选择取决于您的团队对数据库运维工作的接受程度。
我在 DevToolHub 上保留了完整的分步指南，包括所有 YAML 清单文件和 kubectl 命令：Kubernetes 上的 PostgreSQL — 使用 CloudNativePG 的完整设置指南
我在 devtoolhub.com 撰写实用的 DevOps 和 Kubernetes 指南。对您的设置有疑问？欢迎留言评论。
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
