Kubernetes 十岁了：PostgreSQL 处于什么位置？

目录

前言

kubernetes 上数据库工作负载的兴起

入门：kubernetes 和云原生

入门：kubernetes 与 vm

操作员模式：数据库的必备元素

kubernetes 中 postgres 数据库的当前状态

postgresql 社区

企业基础设施团队

开发团队

结论

进一步阅读

 

封面图片：两头大象在米内里耶国家公园里友好地闲聊，由 rohitvarma 根据creative commons attribution-share alike 4.0 international许可证进行授权。相关链接：

https://commons.wikimedia.org/wiki/file:engaged_in_a_friendly_banter.jpg

 

前言

随着 kubernetes 迎来十周年，其对基础设施管理的影响力不断增强。本文探讨了 postgresql 在 kubernetes 中日益普及的现象，这得益于其可扩展性和 ai 应用。它重点介绍了将 postgresql 与 kubernetes 集成的过程、 cloudnativepg 运算符。kubernetes 与传统 vm 部署之间的比较，突显了数据库工作负载的优势。本文呼吁提高对 postgresql 与 kubernetes 结合的认识和专业知识，旨在加强整个 it 领域对这一完全开源堆栈的采用。

 

kubernetes迎来十周年纪念[1]，但其发展势头丝毫没有放缓的迹象。全球范围内，越来越多的组织将其基础设施迁移到 kubernetes，原因是它能够提供标准化界面，使用基础设施即代码 (iac) 来管理整个数据中心和云区域。这种标准化、可移植的基础设施层支持私有云、公有云、混合云和多云场景，帮助组织降低被云服务提供商锁定的风险。那么，随着 kubernetes 进入第二个十年，postgresql 在 kubernetes 中的采用情况如何？

 

[1]https://events.linuxfoundation.org/kuber10es-birthday-bash/

kubernetes 上数据库工作负载的兴起

数据库工作负载最近已成为 kubernetes 的一个关键用例，而人工智能应用的激增加速了这一趋势。postgresql 的可扩展性，加上 pgvector 等强大的扩展，大大促进了这种强大的开源数据库的采用。“ postgresql 适用于一切”（timescale）[2]和“只需使用 postgres ”（edb）[3]等短语在社交媒体上广为流传，反映了日益增长的热情，并促使 postgresql 被公认为 2023 年年度数据库[4]。我还想重申 postgresql 的 simon riggs 在 2023 年 12 月 pgconf europe 上富有远见的主题演讲[5]中所说的话：大多数（如果不是全部）数据库用例都可以通过 postgres（加上扩展）来满足。

 

本文介绍了我对这一重要时刻的看法，回顾了我自 2019 年在 2ndquadrant 启动 kubernetes 上的 postgresql 以来的五年历程，最终让我参与了 cloudnativepg[6]、 cncf和 kubernetes 上的数据[7]社区。

 

我将简要介绍 kubernetes 和 cloud native 原则，重点介绍它们与传统基于 vm 的部署的区别，尤其是在无状态应用程序环境中。然后，我将深入探讨与 postgres 数据库等有状态工作负载相关的独特考虑因素和挑战。

 

[2] https://www.timescale.com/blog/postgres-for-everything/

[3] https://techcrunch.com/sponsor/enterprise-db/edbs-next-move-from-a-postgres-database-company-to-a-postgres-data-ai-platform-company/

[4] https://db-engines.com/en/blog_post/106

[5] https://www.youtube.com/watch?v=8w-j36ixyv4&ab_channel=postgresqleurope

[6] https://cloudnative-pg.io/ 

[7] https://dok.community/

入门：kubernetes 和云原生

kubernetes 提供了一个用于管理基础设施的标准接口，但并不止于此。该接口允许组织根据其资源需求（例如计算能力和存储）控制容器化应用程序的调度和运行。因此，部署的物理位置变得无关紧要，这导致了文献中常见的（且有些苛刻的）类比，即将容器视为“牛”而不是“宠物”。

 

kubernetes 集群由一个控制平面和多个工作节点组成，应用程序在这些节点上运行。这些节点通常分布在不同的数据中心（也称为可用区），从而形成一个扩展集群，用于管理整个云区域中的基础设施和应用程序。

kubernetes 提供许多标准资源来帮助管理无状态应用程序的生命周期。以下是三个值得注意的例子：

1. pod 资源：这是 kubernetes 中最小的工作单元。它通常运行单个容器并配置一组特定的资源。

2. 部署资源： 这允许您指定要同时运行的应用程序副本数。kubernetes 通过自我修复、高可用性和滚动更新确保始终维持所需的副本数（pod）。

3. 服务资源： 通过直接与 deployment 和 pod 资源协作，服务可确保您的应用程序在 kubernetes 内部和外部具有稳定的网络身份。

 

kubernetes也是围绕云原生计算基金会 (cncf) [8]（linux 基金会的一部分） 构建的蓬勃发展的开源和开放治理项目生态系统的一部分 。通过将您的基础架构和应用程序与现有项目[9]集成，您可以在多个领域受益，例如：

1. 可观察性：prometheus、opentelemetry、fluentd

2. ci / cd：argo，flux

3. 安全性：cert-manager、istio、falco、open policy agent

 

cncf 还推动了标准计划，例如 开放容器计划 (oci)[[10] 以及我们最重要的 容器存储接口 (csi)[11]，它在 kubernetes 和存储通信之间提供了一个标准层。

 

数据库领域在过去几年取得了显著进步，最近更是受到人工智能浪潮的推动。然而，仍存在大量错误信息和知识空白需要解决。

我将在本文的剩余部分讨论这个问题。

 

[8] https://www.cncf.io/

[9] https://landscape.cncf.io/ 

[10] https://opencontainers.org/

[11] https://github.com/container-storage-interface/spec/blob/master/spec.md

入门：kubernetes 与 vm

kubernetes 与虚拟机之间最明显的区别在于，虚拟机运行操作系统，而 kubernetes 运行容器化应用程序并对其进行编排。虚拟机不控制在其内部运行的应用程序，需要外部工具来部署它们，对第2天的操作几乎没有了解。

 

让我通过一个例子来说明这一点。kubernetes 中的部署资源旨在响应导致期望状态与观察到的状态不同的预期和意外事件。这可能包括对托管容器共享的操作系统的底层 kubernetes 节点的计划安全更新：在排空操作期间，此更新要求将所有正在运行的工作负载顺利移动到另一个 kubernetes 节点。它还可能包括意外事件，例如托管其中一些工作负载的工作节点发生故障，触发自我修复过程，通过将应用程序副本移动到另一个可用节点来恢复高可用性。同样，自动扩展功能可以检测到应用程序的较低资源需求并自动缩减。

这些模式可以更好、更有效地利用可用资源并优化成本，这通常是迁移到 kubernetes 的主要原因之一。容器共享安装在工作节点上的底层操作系统，进一步优化了成本，使其占用空间比每个部署整个操作系统的虚拟机小得多。

让我用一个例子来说明。kubernetes中的deployment资源旨在响应导致期望状态与观察状态不同的预期和意外事件。这可能包括对托管容器共享的操作系统的底层kubernetes节点的计划安全更新：

1. 在drain操作期间，此更新要求将所有运行的工作负载顺利移动到另一个kubernetes节点。

2. 它还可能包括一个意外事件，例如承载其中一些工作负载的工作节点发生故障，触发一个自我修复过程，通过将应用程序副本移动到另一个可用节点来恢复高可用性的应用程序副本数量。

3. 类似地，自动伸缩功能可以检测到应用程序的资源需求较低，并自动进行伸缩。

 

kubernetes 不仅仅是一个部署工具，它还可以处理第二天的操作。虽然虚拟机需要额外的软件来实现类似的功能，但 kubernetes 扩展到了基础设施层，承担了应用程序业务连续性的责任。这种转变减少了不必要的官僚作风，有利于自动化，并简化了单个区域内的业务连续性计划。

 

vm 通常被视为可变系统，托管多个应用程序。它们直接或间接地使用命令式命令进行升级，例如dnf update。相反，容器是不可变的，应该运行单个应用程序。它们的升级方式是使用滚动更新方式将其替换为容器映像的较新版本。虽然这种方法需要改变应用程序的部署和分发方式，但它从安全角度和通过基础设施即代码进行变更管理带来了许多好处。整个 kubernetes 集群的状态本质上定义了组织在任何给定时间的基础设施。

 

尽管虚拟机可以移植到每个云提供商，但以可移植的方式配置它们需要额外的软件和复杂性。相比之下，所有主要提供商都提供 kubernetes 服务，使我们的基础设施和应用程序组合的整个定义完全可移植到任何云环境，包括私有云、混合云和多云场景。

操作员模式：数据库的必备元素

对于数据库，虚拟机和 kubernetes 的标准资源是不够的。但是，kubernetes 的优势之一是操作员模式，这是一种旨在管理复杂应用程序（如 postgresql 数据库）的开发模式。

我强烈建议不要在 kubernetes 中运行生产数据库，除非使用了解 postgresql 的主/备用架构及其配置的操作员，可以执行自动故障转移、切换、防护、休眠、备份和时间点恢复，默认情况下提高安全性，并促进与 prometheus、grafana、fluentbit 等可观察性工具的集成。

 

在 computerweekly.com 的这篇文章中[12]，google 的 kubernetes 存储开发人员、kubecon na 2023 的演讲者 michelle au 讨论了操作员在管理数据库[13]等有状态工作负载方面的关键作用。她提供了一个令人信服的见解：

kubernetes 已经走过了漫长的道路，从‘我不可能在 kubernetes 上运行数据库’到‘我正在运行 pb 级数据库并实现自动滚动升级’。

 

作为维护者和联合创始人，我推荐 cloudnativepg，这是一个拥有近 20 年使用 edb 以及之前的 2ndquadrant 管理关键任务生产数据库经验的运营商。

 

[12] https://www.computerweekly.com/feature/kubernetes-at-10-building-stateful-app-storage-and-data-protection

[13] https://www.youtube.com/watch?v=wgqq4mwzw6e&ab_channel=cncf[cloudnativecomputingfoundation]

kubernetes 中 postgres 数据库的当前状态

免责声明：这是我个人的观点，自2019年开始在kubernetes中运行postgresql数据库的激动人心的旅程以来，我所面临的经验和挑战形成了这一观点。我的技术背景主要是作为postgres dba和数据仓库架构师，尽管我已经接触devops和精益实践很多年了。最初，作为dba的我对kubernetes持怀疑态度，而我的精益思维促使我对整个项目采用快速失败的方法。此外，我的观点围绕着cloudnativepg和它不断增长的社区中发生的对话。

 

我们对 cloudnativepg 采取的整体方法显示出非常有希望的结果。与大多数其他运营商不同，cloudnativepg 是为 kubernetes 用户从头设计的。我们的座右铭是： “将 postgres 带入 kubernetes。”

 

cloudnativepg 不仅仅是一个操作员；它是一个扩展 kubernetes 控制器的数据库管理平台。它教会 kubernetes 直接理解和管理 postgresql 集群[14]，而不是依赖外部工具（例如我在早期阶段贡献的 repmgr 或 patroni）来执行关键操作，例如主选举、异步/同步复制、自动故障转移、切换、跨主/备用架构的配置管理、备份、恢复、监控、日志记录和证书管理。

cloudnativepg 还利用了 kubernetes api，通过存储类直接管理持久卷声明，而无需依赖状态集。它支持卷快照备份和恢复，集群状态存储在 kubernetes 本身中。此外，我们的默认安全方法提供了显著的优势，确保在 kubernetes 环境中对 postgresql 数据库进行可靠且安全的管理。

 

我们中的一些人积极参与 kubernetes 社区上的数据[15]、 cncf 的 tag 存储小组和kubernetes 存储项目[16]。我们参与这些社区对于塑造和推进 postgresql 与 kubernetes 的集成起到了重要作用。当我们于 2019 年首次参加圣地亚哥的 kubecon 时，这种程度的参与和影响力似乎是不可想象的，当时我们谨慎而悄无声息地进入了这个领域。从那时起，我们取得了重大进展，为这些充满活力的社区做出贡献并从中学习，帮助推动 kubernetes 中数据管理的发展。

 

edb 于 2022 年 5 月开源的 cloudnativepg 是根据 apache 2.0 许可证分发的。最重要的是，它与供应商无关，由开源社区（而非公司）拥有，并且是 公开管理的[17]。它将始终以非常宽松的许可证开源，使整个堆栈（kubernetes、postgresql 和 cloudnativepg）成为组织的安全长期选择。

 

cloudnativepg 也正在成为kubecon 和 kubernetes 社区日等会议[17]上最受欢迎的数据库运营商之一 ，自开源以来，在过去的两年中，我们曾多次发表演讲（不仅仅是我）。总之，我们正在利用我们的经验，并为其他人提供工具，以便他们轻松测试和扩展，从而挑战数据库无法在 kubernetes 中运行的误解。作为一名开源爱好者，为如此充满活力、有机和生机勃勃的项目做出贡献令人无比振奋。新社区成员在 slack 频道中讨论的问题和解决方案的质量和深度清楚地表明了这一未知领域的增长和不断提高的卓越标准。

 

看到新一代云原生 it 专业人士使用 postgresql 作为 kubernetes 中的第一个数据库，也是一件令人欣慰的事情，这要归功于 cloudnativepg。这一趋势表明，许多初创公司将以 postgresql 为基础建立数据平台，并完全接受“postgresql 适用于一切”/“只需使用 postgres”的浪潮。利用 postgresql 的可扩展性——包括 pgvector 扩展[18]，使 postgres 成为向量数据库。

 

这些只是 cloudnativepg 所采用的独特方法的几个例子，这些方法使其在 kubernetes 社区中越来越受欢迎，并被越来越多地采用。然而，其他社区和企业部门仍有许多工作要做。

 

[14] https://cloudnative-pg.io/documentation/current/controller/

[15] https://dok.community/

[16] https://github.com/cncf/tag-storage

[17] https://github.com/cloudnative-pg/governance/blob/main/governance.md

[18] https://github.com/pgvector/pgvector

postgresql 社区

到目前为止，我们的努力促进了 postgres 在 kubernetes 中的采用， 主要针对 kubernetes 采用者和受众群体。然而，我们现在看到，在这一交叉领域对更多 postgresql 专业知识的需求日益增长。

 

这为所有 postgresql dba 提供了一个重要的机会。

为了利用这一点，我们必须开发程序和材料来帮助 dba 快速掌握 kubernetes，并强调传统虚拟机部署和裸机部署之间的相似之处和不同之处。我打算今年参加更多 postgresql 会议（从 2024 年 6 月 28 日的瑞士 pgday[19]开始），并听取与会者的反馈。

 

[19] https://www.pgday.ch/2024/#schedule

企业基础设施团队

我经常注意到，大型企业中负责基础设施和 kubernetes 部署的团队通常不知道数据库可以在 kubernetes 中运行。他们倾向于将数据库保留在 kubernetes 之外，选择将其作为云中的服务运行（尤其是在组织中没有 dba 团队的情况下）或在虚拟机/裸机部署上运行。这主要是因为缺乏针对该主题的解决方案架构师量身定制的技术材料。

 

这里戴上 edb 帽子：我们需要通过与支持 kubernetes 发行版（例如，openshift 的 red hat）的企业合作，来提高对可能的架构和存储解决方案的认识。

 

cio 可能会发现这一点特别有吸引力，尤其是在欧洲，开源授权和新的 欧盟数据法案[20] 鼓励组织将数据保留在自己的基础设施上并完全控制。postgresql、kubernetes 和 cloudnativepg 开源堆栈在此背景下提供了宝贵的资产。

 

[20] https://eur-lex.europa.eu/eli/reg/2023/2854/oj

开发团队

开发人员编写应用程序以在容器中运行，但通常没有意识到他们可以利用 kubernetes 和 postgresql 微服务数据库。可能受到上述基础设施团队意见的影响，开发人员仍然将数据库视为应用程序的外部事物，而不是应用程序的基本和可控部分。

 

将 postgresql 整合到他们的 ci/cd 管道中可以带来惊人的速度和可靠性。我们需要利用上一篇文章中强调的微服务数据库的概念来[21]建立意识并提供这意味着什么的示例。

通过解决这些问题，我们可以进一步增强 postgresql 在 kubernetes 中的采用和有效使用，确保它成为各个领域的标准实践。

 

[21] https://www.gabrielebartolini.it/articles/2024/02/maximizing-microservice-databases-with-kubernetes-postgres-and-cloudnativepg/

结论

总结一下，根据我的经验，组织迁移到 kubernetes 的主要原因有：

1. 标准化和可移植性： kubernetes 提供了一致且可移植的基础设施层，降低了供应商锁定风险。

2. 资源优化：kubernetes 通过容器编排和自动扩展实现资源的有效利用，并带来成本优化的优势。

3. 第二天运营/更多功能：kubernetes 在强大的操作员支持下，可以自动更新和自我修复，这些功能在传统的基于 vm 的设置中通常不存在或委托。

4. 安全和变更管理：容器的不变性和滚动更新提供了显著的安全和操作优势。

5. 提高速度：开发团队可以通过精简的 ci/cd 管道自主快速地为其微服务应用程序提供新功能。这种方法使团队能够更有效地迭代和部署更新，从而提高整体开发速度和敏捷性。

 

postgresql 与 kubernetes 环境的集成在上述所有方面都具有显著优势。本文旨在激发全球组织内部的讨论，并鼓励人们考虑这一强大的选项。

 

kubernetes 迎来十周年之际，恰逢 cloud native postgresql 计划启动第五周年，该计划于 2019 年 8 月在我任职 2ndquadrant 期间启动。回顾这段收获颇丰的旅程，我热切期待未来五年的创新和发展。在结束之前，我分享了 cloudnativepg 社区成员 、新西兰 datacom 高级平台工程师 wei-yen tan[22]的感言：我们选择在客户的生产环境中实施 cnpg，以管理跨多个位置的大量日常交易。此组件对我们的运营至关重要。操作员的稳定性和自动化使我们的 postgresql 工程师能够专注于更高价值的任务。最初，由于数据完整性问题，我对在容器中使用 postgresql 持怀疑态度，但在概念验证测试期间，逻辑和完整性保护的数据管理让我感到惊喜。恢复非常简单，尤其是使用 minio 等本地对象存储解决方案。

 

[22] https://www.linkedin.com/in/weiyentan/?originalsubdomain=nz

进一步阅读

为了更全面地理解和进一步了解这个主题，我整理了一份我过去写过的相关文章清单。这些资源可以更深入地了解 kubernetes 上的 postgresql 以及更广泛的云原生运动的细微差别：

1. kubernetes 中的本地持久卷和 postgresql 的使用（2020 年 6 月）

https://www.2ndquadrant.com/en/blog/local-persistent-volumes-and-postgresql-usage-in-kubernetes/

 

2. edb 为何选择不可变应用程序容器（2021 年 2 月）

https://www.enterprisedb.com/blog/why-edb-chose-immutable-application-containers

 

3. 介绍 cloudnativepg：适用于 postgres 的全新开源 kubernetes 运算符（2022 年 5 月）

https://www.enterprisedb.com/blog/introducing-cloudnativepg-new-open-source-kubernetes-operator-postgres

 

4. cloudnativepg 文档中的“自定义 pod 控制器”页面（2022 年 5 月）

https://cloudnative-pg.io/documentation/current/controller/

 

5. “kubernetes 中 postgresql 的推荐架构”（2023 年 9 月）

https://www.cncf.io/blog/2023/09/29/recommended-architectures-for-postgresql-in-kubernetes/

 

6. 使用 kubernetes、postgres 和 cloudnativepg 最大化微服务数据库（2024 年 2 月）

https://www.gabrielebartolini.it/articles/2024/02/maximizing-microservice-databases-with-kubernetes-postgres-and-cloudnativepg/

 

7. cloudnativepg 秘诀 5 - 如何在 kubernetes 中从任何地方迁移 postgresql 数据库，且停机时间约为 0（2024 年 3 月）

https://www.gabrielebartolini.it/articles/2024/03/cloudnativepg-recipe-5-how-to-migrate-your-postgresql-database-in-kubernetes-with-~0-downtime-from-anywhere/

 

通过利用这些见解并不断创新，我们可以确保 postgresql 在 kubernetes 生态系统中蓬勃发展，为未来的发展和更广泛的采用铺平道路。

 

请留意未来的更新！请务必关注我的 linkedin[23]和 x[24]频道以了解最新动态。如果您发现本文有用，为什么不使用以下链接将其分享到您的社交媒体网络？您的支持意义重大！

[23] https://www.linkedin.com/in/gbartolini/

[24] https://twitter.com/_gbartolini_