基于K8s和CloudNativePG的云中立PostgreSQL数据库

作者: Gabriele Bartolini，EDB Kubernetes 首席架构师副总裁

摘要

本文深入探讨了 PostgreSQL 部署中的云中立性概念——我更倾向于使用“中立”而不是“无关性”——这一概念。文章重点介绍了 Kubernetes 作为云中立平台的变革性影响，使组织能够在各种环境中部署和管理 PostgreSQL，包括本地、混合和多云环境。文章探讨了关键的组织性考虑因素，例如供应商锁定、成本可预测性和开发速度，以及从传统的本地 Linux 到基于 Kubernetes 的现代解决方案的各种部署模型。讨论强调了让数据库管理员（DBA）参与到云原生架构的迁移中的重要性，并将 CloudNativePG 作为构建可扩展、灵活和云中立 PostgreSQL 生态系统的强大解决方案。

引言

对数据库的需求持续快速增长。Gartner 报告显示，2023 年全球数据库市场增长了 13.4%，近 80%的数据库是 PostgreSQL 之类的关系型系统。大型云服务提供商（亚马逊、谷歌和微软）提供的强大的数据库即服务（DBaaS）解决方案进一步推动了这一增长。PostgreSQL 已巩固其作为最受欢迎的数据库^[1]的地位，其采用率不断提高，不仅是因为其技术优势，也是因为它能够减少供应商锁定。

虽然公共云服务继续主导市场，但许多依赖 PostgreSQL 的组织越来越多地将 Kubernetes 作为其基础设施战略的核心部分。这种转变的动力，是追求云中立性，使企业能够避免供应商在提供商级别的锁定，并获得更大的灵活性，同时有意识地承担更多运营责任。通过采用 Kubernetes，组织还可以释放提供多云和混合云解决方案的潜力，为全球客户提供更通用的服务。让我们通过 CloudNativePG 堆栈探讨这种转变如何以及为什么重新定义 PostgreSQL 部署的未来。

本地 PostgreSQL

我在 2000 年代初开始在生产环境中使用 PostgreSQL 时，它运行在带有硬件 RAID 控制器和多个本地连接磁盘的裸机 Linux 操作系统上。为了优化成本和资源利用率，我在同一台机器上运行了多个 PostgreSQL 实例，每个实例分配给不同的 TCP 端口。这是当时整合数据库基础设施的常用方法。

随着技术的进步，虚拟化和配置管理工具的兴起显著改善了本地数据库管理。这些创新推动了 PostgreSQL 的全球采用，使本地部署成为需要完全控制和拥有其基础设施的组织的可靠选择。

如今，本地部署通常受到那些对其工作负载有深入了解、必须管理其系统安全、性能、业务连续性和合规性的组织的青睐。行业特定法规、政府强制规定和数据主权要求使这种方法在某些行业中必不可少。

云中的 PostgreSQL：基础设施即服务（IaaS）

2000 年代后期，随着云计算的快速发展，基础设施即服务（IaaS）的兴起带来了显著的转变。到 2010 年代初，PostgreSQL 数据库正从传统的本地数据中心迁移到基于云的解决方案，允许用户按需租用虚拟服务器和存储，并按实际资源使用付费。

借助 Terraform 和 Ansible 等自动化平台，PostgreSQL 数据库的创建、部署和配置变得更加高效，尤其是在 Day 1 运营方面。然而，尽管在速度和灵活性方面具有优势，但 Day 2 运营（例如可用性、维护、扩展和优化）仍然需要数据库管理员（DBA）的大量参与，并且通常仍然局限于数据库领域，与更广泛的基础设施和应用程序脱节。

虽然 IaaS 解决方案减少了创建计算和存储的交付时间，但它们也带来了诸如供应商锁定和不可预测的成本等挑战，尽管承诺了按需付费的节省。混合和多云策略旨在减少对供应商的依赖，但它们的实施通常复杂且资源密集型。

有趣的是，IaaS 还在加速平台即服务（PaaS）和软件即服务（SaaS）的兴起中发挥了关键作用。一个典型的例子是 Heroku，这是一个在 Ruby 开发者中流行的开创性 PaaS，并在 2010 年左右对 PostgreSQL 的日益普及做出了重大贡献。

云中的 PostgreSQL：数据库即服务（DBaaS）

自 2013 年以来，基于 IaaS 模型的 PostgreSQL 数据库即服务（DBaaS）越来越受欢迎，尤其是在寻求外包大部分 Day 2 运营的组织中。使用 DBaaS，服务提供商管理底层基础设施、操作系统和 PostgreSQL 服务器，允许客户专注于应用程序开发和业务需求。

如今，DBaaS 已成为云数据库的代名词。主要的云提供商提供 DBaaS 解决方案，例如亚马逊的 Amazon RDS for PostgreSQL、谷歌云的 Google Cloud SQL for PostgreSQL 和 Azure 的 Azure Database for PostgreSQL，以及我公司提供的 EDB Postgres AI Cloud Service 等专业解决方案。这些服务通过提供高可用性、灾难恢复和可观察性以及跨多个云区域的地理冗余来简化数据库管理。

虽然 DBaaS 大大降低了基础设施的复杂性和运营开销，但它限制了对 PostgreSQL 后端的直接控制，限制了对 PostgreSQL 连接、CLI 或基于 Web 的仪表板的访问。这种权衡可以加快开发速度，但它也带来了供应商锁定、不可预测的成本和数据可移植性等问题。最近的欧盟数据法案强调了数据可移植性（即在云提供商之间切换、实施多/混合解决方案以及在不中断服务的情况下迁移数据）的重要性，促使组织在采用 DBaaS 时仔细考虑这些因素。除非 DBaaS 的设计采用了多云方法并专门针对 PostgreSQL 进行了优化（如 EDB 的解决方案），否则将数据从云服务提供商迁移出去可能具有挑战性。

云中立 PostgreSQL

在本地、IaaS 和混合/多云环境中管理 PostgreSQL 会带来巨大的复杂性和运营权衡。每种情况都会带来自身的挑战，使得难以保持一致性和灵活性。

云中立方法通过启用高度可移植的基础设施来提供解决方案，该基础设施有助于在云和本地环境之间进行无缝转换。此模型支持 Day 1 任务（创建、设置）和 Day 2 任务（扩展、监控、备份），而不会牺牲性能或可管理性。通过使用开源技术和标准化 API，组织可以避免供应商锁定，降低运营开销，并保留选择最佳基础设施的灵活性。

我们提出的云中立 PostgreSQL 解决方案基于 CloudNativePG 开源堆栈，该堆栈由 Kubernetes、PostgreSQL 和 CloudNativePG 组成。该堆栈已经使全球各地的组织能够构建高度可移植的基础设施，可在本地（包括裸机）或混合配置中部署。通过利用来自大型云服务提供商（例如 Amazon EKS、Azure AKS 和 Google GKE）的 Kubernetes 即服务（KaaS）解决方案，或 Red Hat OpenShift 等容器平台，甚至标准 Kubernetes 发行版，企业可以拥抱云中立性。

Kubernetes 的云中立性

Kubernetes 是一个开源平台，它提供了一个标准的抽象层，用于管理 Linux 容器中的基础设施和应用程序。其模块化设计、可扩展性、容错能力、自我修复能力以及对基础设施即代码（IaC）原则的遵守，使其成为寻求高度可移植、云中立基础设施的组织的理想选择。

Kubernetes 是最受欢迎的云原生计算基金会（CNCF）项目，可以部署在任何地方——从裸机服务器到虚拟机。组织可以根据自己的专业知识选择自管理 Kubernetes 或托管 KaaS 解决方案。此外，基于 Kubernetes 的企业平台（如 Red Hat OpenShift、Suse Rancher 或 VMware Tanzu）将云中立性扩展到企业环境，方便在本地、私有和公共云基础设施之间无缝迁移。

Kubernetes 解锁了真正的云中立基础设施，允许组织在私有云、公共云或混合云中部署工作负载，而对代码或配置的更改最少。由于 GitOps 和 IaC 的集成，Kubernetes 是云中立 PostgreSQL 的关键推动者，它提供了未来数据库部署所需的灵活性。

使用 CloudNativePG 实现 PostgreSQL 的云中立性

Kubernetes 促进了基础设施和容器化工作负载的云中立性，但在这种环境中管理 PostgreSQL 数据库会带来独特的挑战。虽然 Kubernetes 将 PostgreSQL 视为另一个应用程序，但由于数据库固有的复杂性，依赖于标准资源（如Deployments和StatefulSets）是不够的。虽然我们经常努力避免将数据库视为“宠物”并采用“牲畜”模型，但重要的是要记住 PostgreSQL 的吉祥物是大象——象征着力量，需要仔细管理（而不是“牲畜”，也许“兽群”是更合适的比喻）。

这就是 PostgreSQL Operator 发挥作用的地方。Operator 模式通过自定义资源、控制器和声明式配置扩展了 Kubernetes 的功能，允许以云原生方式编排 PostgreSQL 等复杂应用程序。

精心设计的 PostgreSQL Operator 提供了必要的自定义资源和控制器，使 Kubernetes 能够高效地管理数据库。这确保了 PostgreSQL 满足核心云原生需求，例如高可用性、自我修复、可扩展性和安全性，同时还利用其强大的业务连续性功能。这些功能包括本地复制机制（如热备用、同步复制、级联复制），以及对热备份、连续备份和时间点恢复（PITR）的支持。这些功能共同构成了在云原生世界中实现数据完整性、弹性和运营卓越的坚实基础。

有几种 PostgreSQL Operator 可用，但我将重点介绍 CloudNativePG，原因如下：

• 我是该项目的创始人之一和维护者。
• 它是开源的，采用 Apache License 2.0 许可。
• 它是唯一一个由厂商中立社区管理的 PostgreSQL Operator。虽然 EDB 是最初的创建者和主要贡献组织，但在 2022 年 5 月将知识产权捐赠给了 CloudNativePG 社区，但该社区现在公开管理该项目。
• 它是提交给 CNCF Sandbox^[2]的唯一 PostgreSQL Operator。
• 它是 GitHub 上最受欢迎的 PostgreSQL Operator，拥有超过 4.5k 颗星、5800 万次下载量、最快的采用率和最高水平的社区参与度。
• 文档非常全面。
• CloudNativePG 是 Kubernetes 原生，充分利用并扩展了 Kubernetes API。它是完全声明式的，默认情况下是安全的，并且与用于可观察性的云原生标准工具无缝集成。
• CloudNativePG 与 Kubernetes 存储项目合作，以应对大型数据库工作负载的独特需求，尤其是在备份/恢复的卷快照和性能和数据持久性的本地存储方面。

通过定义 CloudNativePG Cluster资源，用户可以确保其 PostgreSQL 数据库（具有主节点和任意数量的只读副本）在业务连续性场景中运行，恢复时间目标（RTO）和恢复点目标（RPO）最小，并且在一年内可以实际实现 99.99%的正常运行时间。相同的资源可以在任何云环境或多个 Kubernetes 集群中（用于混合和多云场景）进行部署，而无需更改，并自动处理大部分 Day 2 操作。用户可以完全控制其数据，而不会出现供应商锁定，从而确保根据欧盟数据法案的要求实现完全的数据可移植性（PostgreSQL 的本地流复制——逻辑或物理——支持这种灵活性）。

这就是基于 Kubernetes 和 PostgreSQL 构建的 CloudNativePG 堆栈如何实现真正的云中立性。

此外，Kubernetes 的调度功能允许用户为 PostgreSQL 工作负载分配特定的机器。通过将标签和污点应用于节点，并在 CloudNativePG Cluster资源上定义亲和规则和容忍度，PostgreSQL 可以在物理层与其他应用程序完全隔离，同时在逻辑层无缝集成。这种方法反映了微服务数据库架构，其中应用程序及其后端共存于同一个 Kubernetes 命名空间中。

使用 CloudNativePG 实现 PostgreSQL DBaaS 的云中立性

此外，CloudNativePG 堆栈是隔离应用程序和后端数据库的逻辑层，同时提供云中立数据库即服务（DBaaS）解决方案的绝佳选择。依赖于标准资源（例如负载均衡器服务）可以安全地在 Kubernetes 外部暴露 PostgreSQL。此设置有效地为组织内的内部客户和外部客户提供服务，正如 IBM 的 Cloud Pak、EDB 的 Postgres AI Cloud Service 和 Tembo 所证明的那样。

裸机 PostgreSQL 的回归

关于 Kubernetes 最常见的误解之一是它只能在虚拟机上运行。实际上，Kubernetes 在裸机基础设施上的运行效率同样高（甚至更高），而无需使用虚拟机管理程序。下图简化地显示了裸机和虚拟机 Kubernetes 节点中的关键层。

通过直接在主机上运行，容器可以充分利用底层硬件，消除虚拟化的开销，甚至将效率和性能提高一倍，这对于数据库等有状态工作负载尤其重要，这些工作负载可以部署在专用裸机 Kubernetes 节点上，并受益于本地连接的存储。此设置为数据库专业人员提供了一个独特的机会，可以为 PostgreSQL 集群实现高性能、强大的无共享架构，所有这些都通过声明式配置进行无缝管理。（毕竟，CloudNativePG 的存在源于我的团队在 2019 年末进行的第一个快速失败实验，当时我们启动了我们的 Postgres 计划。目标是衡量 Kubernetes 在裸机上的性能——正如你可能猜到的那样，结果不言而喻。）

借助 CloudNativePG 堆栈，PostgreSQL DBA 现在可以在 Kubernetes 的裸机上运行 PostgreSQL，并在使用对称架构的私有或公共 Kubernetes 集群之间进行复制。这为混合云环境提供了一种高度可移植和标准化的方法——一种真正的云中立 PostgreSQL 解决方案，可以帮助逆转或减缓数据库向公共云的迁移，从而实现向混合或完全本地部署的转变。

PostgreSQL DBA 的机会

正如我之前写过的，PostgreSQL DBA 在面对 Kubernetes 时处于职业生涯的关键十字路口：他们应该采用、避免还是拒绝它？

在过去五年中，我将我的云原生计划致力于简化在 Kubernetes 上运行 PostgreSQL 的工作，我现在正转向下一阶段——帮助 PostgreSQL 专家顺利过渡到 Kubernetes 生态系统。虽然在 Kubernetes 中启动 PostgreSQL 集群现在已经变得非常简单，但还有一个广阔且大部分未开发的领域，只有经验丰富的 PostgreSQL 专家才能充分探索和掌握。这种转变无疑需要 DBA 付出努力和适应，他们必须掌握足够的 Kubernetes 知识（T 型人才），才能从第 0 天（规划）开始与 Kubernetes 专家有效地合作处理 PostgreSQL 数据库。然而，正如成功完成此旅程的 PostgreSQL DBA 所证实的，回报是显而易见的。在许多方面，这种转变与 DBA 在过去二十年中从裸机迁移到虚拟机的转变类似。

根据我的经验，PostgreSQL DBA 非常重视开源软件，并且精通运行 Linux 命令。Kubernetes 与 Linux 和 PostgreSQL 一起，是历史上最引人入胜和最具变革性的开源项目和社区之一。虽然 Kubernetes 庞大而复杂，但它也是模块化的，这意味着 DBA 不需要掌握它的每一个方面。相反，他们可以专注于管理 CloudNativePG PostgreSQL 集群的要点：了解 Pod 和容器、网络（服务资源）、存储（存储类、持久卷声明和持久卷），并具有足够的熟悉程度，以便在 IaC、GitOps、TLS 证书、监控（使用 Prometheus 进行指标和警报）和日志记录（因为日志不存储在磁盘上）等领域与基础设施管理员有效协作。投入一两个月的时间学习这套技能可以开启十年的新机遇。

云数据库背后的决策过程

在基础设施层面实现真正的云中立性，需要你的组织通过内部团队或外部合作伙伴来发展或获取 Kubernetes 专业知识。这种专业知识因平台选择而异——无论使用上游 Kubernetes（需要最多的技能）、Kubernetes 即服务（KaaS）还是 Red Hat OpenShift 和 SUSE Rancher 等企业级容器平台。

下图根据我的经验以及对过去五年客户旅程和对话的分析，概述了采用 CloudNativePG 堆栈的决策过程。虽然简化了，但它准确地反映了行业的更广泛趋势，即使某些细节在特定情况下可能有所不同。

对于旨在将云中立性扩展到 PostgreSQL 并充分利用 CloudNativePG 堆栈的组织而言，让 PostgreSQL DBA 从一开始就参与进来至关重要。如果你的团队缺乏 Kubernetes 知识，或者你的 DBA 不愿接受这种转变，那么坚持使用更熟悉的选项（例如在裸机、虚拟机或基础设施即服务（IaaS）上运行 PostgreSQL）可能更为谨慎。为了简单起见，图中没有明确表示，但在这些情况下，DBA 也可以依赖数据库即服务（DBaaS）解决方案，尤其是在其他利益相关者（如开发人员）推动决策时。

对于没有专门的 DBA 或 Kubernetes 专业知识的组织而言，DBaaS 仍然是一个流行且务实的选项。

然而，在战略性地采用了 Kubernetes 但没有专门的 DBA 的组织中，一种新的趋势正在出现。这些公司正在使用 CloudNativePG 堆栈为其内部客户（主要是来自其他部门的开发人员和工程师）提供数据库即服务。这种方法在传统的基础设施管理和完全托管的云 DBaaS 之间提供了一种平衡的解决方案。虽然我无法透露具体的公司名称，但在制造业、银行、金融、支付、汽车和 IT 服务等大型企业中，这种用例越来越普遍。这种趋势在欧洲尤为明显，因为那里通常更喜欢本地基础设施。CloudNativePG 堆栈能够在逻辑上和物理上对工作负载进行声明式隔离，从而能够在裸机 Kubernetes 节点上整合 PostgreSQL，从而为基础设施管理员和 DBA 创造双赢的局面。

最后，需要强调的是，CloudNativePG 的最初创建者和创始人 EDB，在帮助全球企业将其 Postgres 数据库迁移到 Kubernetes 方面处于有利地位。EDB 处于 Kubernetes 上 PostgreSQL 技术的领先地位，是 CNCF 的白银成员，也是唯一一个积极参与 PostgreSQL 开发的 Kubernetes 认证服务提供商。EDB 提供 CloudNativePG 的长期支持版本，称为 EDB Postgres for Kubernetes (PG4K)，它还提供对 EDB Postgres Advanced Server (EPAS)，简化了 Oracle 迁移，以及用于主动-主动工作负载的 EDB Postgres Distributed for Kubernetes (PGD4K)。

总结

总而言之，Kubernetes 作为云中立平台的兴起正在彻底改变 PostgreSQL 在各种环境中的部署和管理方式。虽然蓝图和最佳实践可以提供宝贵的指导，但正确的部署选择最终取决于你组织的特定需求及其团队的专业知识。

下表总结了主要的组织性考虑因素——例如供应商锁定、成本可预测性和开发速度——以及当今可用的主要 PostgreSQL 部署模型，从传统的本地 Linux 设置到基于 Kubernetes 的现代解决方案。

在解决这些组织性因素后，我们可以深入研究基础设施和操作系统层，以探讨本文讨论的部署选项之间的关键技术差异：

至此，所有主要的组织和架构考虑因素都已得到解决，你关于采用哪种云模型的决定可能已经很明确了。但是，同样重要的是要评估与 Postgres 数据库本身及其管理的数据相关的方面。下表总结了这些因素，它们可能会对你的最终部署选择产生重大影响：

借助 CloudNativePG，组织可以采用一种强大、高性能且标准化的方式来运行跨裸机、混合或多云环境的 PostgreSQL 集群，所有这些都由声明式配置驱动。这使 DBA 能够实现云中立的、无共享架构，从而避免供应商锁定，同时保留对数据和性能的完全控制。随着企业越来越多地远离依赖云的模型，CloudNativePG 为在各种复杂环境中管理 PostgreSQL 提供了一种可扩展的、面向未来的解决方案，包括回归本地部署。