[译] 在 Kubernetes 上运行 PostgreSQL：包含基准和最佳实践的实用指南

还记得在 Kubernetes 中运行数据库吗？难以预测的存储性能和复杂的状态管理让稳定性成为一场持久战吗？借助更强大的工具、更智能的运维人员和久经考验的策略，您现在可以自信地在 Kubernetes 上部署 PostgreSQL，尤其是在需要扩展、自动化和平台一致性的时候。Kubernetes 已经不再仅仅承载无状态服务；它正在成为一切的控制平面，包括您的关键数据库。

在本文中，您将了解为什么在 Kubernetes 上运行 PostgreSQL 不仅切实可行，而且对于处理不断增长的基础设施、整合环境或规划长期规模的团队来说，它往往是一个明智的选择。我们将探讨实际的业务优势、技术优势、需要注意的潜在陷阱，以及哪些存储选项性能最佳（并提供基准数据支持）。您还将学习如何通过我们的分步实施指南开始使用 Percona Operator for PostgreSQL。

为什么有远见的组织在 Kubernetes 上运行 PostgreSQL

对于跨多个环境管理 PostgreSQL 的团队，Kubernetes 提供了一个实用的解决方案，可以为您的数据库操作带来一致性和自动化。然而，这并不是为了追随潮流，而是要利用工具来解决真正的基础设施挑战，帮助您更快地行动、保持灵活性并减少手动工作。

无论您在云端、本地还是混合基础架构中运行 PostgreSQL，Kubernetes 都能为您的技术和运营团队提供切实的优势。

构建更具可扩展性、一致性的基础设施

您的 PostgreSQL 部署不再是静态的。您可能正在跨区域部署集群、复制数据以实现故障转移，或在动态环境中与微服务集成。Kubernetes 正是为应对这种复杂性而构建的。通过正确的设置，您可以标准化 PostgreSQL 在不同云平台、团队和开发阶段的部署、管理和扩展方式。

您将获得：

• 可重复的声明性部署：使用 Kubernetes Operators 来定义和管理数据库状态。
• 集成弹性：利用内置健康检查、自动故障转移机制和自我修复功能。
• 简化的 DevOps：将数据库配置和更新原生集成到 CI/CD 管道和 GitOps 工作流中。
• 集中控制：从单一控制平面管理混合或多云数据库环境。
• 将其视为数据库的基础设施即代码，从而消除了扩展或恢复 PostgreSQL 的猜测。

快速满足企业需求

Kubernetes 上的 PostgreSQL 能够满足严格的高可用性 (HA) 和灾难恢复 (DR) 要求，通常比传统的虚拟机设置或手动配置更高效。架构良好的 Kubernetes 部署允许您：

• 启动默认启用 HA 的新集群
• 自动进行故障转移和恢复，无需人工照看
• 不中断服务地推送更新
• 以受控的方式跨环境推出配置更改

当您管理多个实例、区域或租户时，这种灵活性尤其有价值。

优化基础设施利用率和预算

Kubernetes 可帮助团队合理调整资源规模。您可以根据使用情况垂直或水平扩展 PostgreSQL，并动态调整内存、CPU 和存储等资源。这开启了更智能的基础架构选项：

• 降低成本：将实例整合到共享硬件上并微调资源分配以避免过度配置。
• 提高效率：利用 Kubernetes 的智能调度和自动扩展功能来提高资源利用率。
• 简化堆栈：在同一集群上与应用程序一起运行数据库，而不会显著增加操作复杂性。

您无需在超大型虚拟机上花费过多，也无需受困于不灵活的托管服务，而是可以完全掌控。

以正确的方式应对常见挑战

需要明确的是，在 Kubernetes 上运行 PostgreSQL 并非没有挑战。人们对存储可靠性、状态管理、操作符复杂性以及灾难恢复存在一些担忧。然而，这些都是可以解决的问题，而不是障碍。

以下是阻碍团队发展的常见因素：

• 状态持久性：需要强大的持久卷配置、可靠的备份策略和清晰的恢复计划。
• 存储性能变化：性能很大程度上取决于底层存储类别、配置和工作负载类型。
• DIY 复杂性：滚动您自己的 Kubernetes 设置通常缺少成熟的 HA、监控或备份集成等基本组件。
• 潜在锁定：一些商业解决方案可能会在付费墙后引入专有扩展或功能限制。

PostgreSQL 在 Kubernetes 上的性能：基准测试结果

我们经常听到的一个问题是：“ Kubernetes 存储真的能跟上我的 PostgreSQL 工作负载吗？ ”对于数据库工作来说，性能和可靠性不是可选功能，因此我们决定对其进行测试。

Percona 的研究《 在 Kubernetes 上对 PostgreSQL 存储性能进行基准测试》比较了使用 Percona Operator for PostgreSQL 部署时，不同存储解决方案处理 PostgreSQL 工作负载的方式。目标很简单：确定存储选择在实际情况下如何影响 I/O 性能和事务吞吐量。

我们测试了什么

基准测试在 AWS EKS (v1.29.4) 上运行，使用 i4i 实例和本地 NVMe 存储。我们评估了多种开源和商业存储方案：

• OpenEBS
• Rook
• Lightbits
• Portworx
• AWS EBS

为了模拟实际的 PostgreSQL 活动，我们使用了两个测试工具：

• FIO ，用于测量原始 I/O 性能（IOPS、带宽、延迟）
• pgbench ，模拟数据库工作负载并捕获TPS（每秒事务数）

为了反映如何在不同的环境中运行 PostgreSQL，我们在两种内存场景下进行了测试：

• 低内存分配，PostgreSQL 严重依赖磁盘 I/O
• 高内存分配，更大的共享缓冲区允许在内存中进行更多操作

关键要点

每种存储解决方案都表现出不同的优势：

• OpenEBS在磁盘密集型（低内存）场景中表现出色，为随机 I/O 工作负载提供最高 TPS。如果您的数据库频繁从磁盘读取/写入小块数据，那么 OpenEBS 将是理想之选。
• Portworx在顺序操作和更大的数据集中表现出了强大的性能，使其适合流式传输或批量处理工作负载。
• AWS EBS全面交付了可靠且可预测的结果。它是一个可靠的通用选项，尤其是在一致性至关重要的环境中。
• Lightbits提供了全面的性能，可以稳定地处理顺序和随机 I/O，尽管并不总是在特定类别中名列前茅。
• Rook在更高的并发级别下表现不佳，性能下降更为明显。它可能更适合规模较小的部署或负载较低的工作负载。

或许最重要的是，我们发现存储后端的选择显著影响了性能，尤其是在 PostgreSQL 内存受限且严重依赖磁盘 I/O 的情况下。吞吐量和延迟差异很大。在内存充足的情况下，性能差异缩小，凸显了基础设施成本和原始速度之间的权衡。

这对你的 PostgreSQL 部署意味着什么

存储可以说是影响 PostgreSQL 在 Kubernetes 上性能的最关键因素。您的选择会直接影响速度、稳定性以及负载下的成本。

这项基准测试证实，只要与正确的架构和存储解决方案搭配使用，PostgreSQL 绝对可以在 Kubernetes 上蓬勃发展。这也进一步证明了使用像 Percona Operator for PostgreSQL 这样经过测试、可用于生产的 Operator 来管理完整堆栈的价值。

如何在 Kubernetes 上运行 PostgreSQL（分步指南）

有了合适的工具，在 Kubernetes 上运行 PostgreSQL 就变得非常简单。Percona Operator for PostgreSQL 能够处理数据库部署、扩展和管理等繁重工作，使整个过程可重复、可靠且可用于生产环境。

本指南将指导您使用Percona Operator for PostgreSQL进行基础部署。虽然简单，但此基础功能可以扩展用于预发布和生产环境。注意： 本示例使用 2.3.1 版本。请查看Percona Operator 文档以使用最新的稳定版本。

为 PostgreSQL 安装 Percona Operator

1. 首先为 Operator 创建一个专用的 Kubernetes 命名空间。这有助于隔离 PostgreSQL 工作负载并保持系统井然有序。在本例中，我们将使用一个名为 postgres-operator 的命名空间：

kubectl create namespace postgres-operator

2. 将 Percona Operator for PostgreSQL 部署到 postgres-operator 命名空间。在本例中，我们使用 2.3.1 版本，并将其应用到服务器端，以确保所有配置都清晰无误：

kubectl apply --server-side -f https://raw.githubusercontent.com/percona/percona-postgresql-operator/v2.3.1/deploy/bundle.yaml -n postgres-operator

此时，Operator pod 应该正在运行。列出命名空间中的 pod，以确认它处于运行状态。

kubectl get pods -n postgres-operator
 
NAME                                                                                           READY       STATUS      RESTARTS     AGE
percona-postgresql-operator-55fff7dd8b-4pz54       1/1        Running          0              5m43s

3.现在是时候通过应用 cr.yaml 自定义资源文件来部署 Percona Distribution for PostgreSQL 了。

kubectl apply -f https://raw.githubusercontent.com/percona/percona-postgresql-operator/v2.3.1/deploy/cr.yaml -n postgres-operator

检查操作员和副本集 Pod 的状态。

kubectl get pg -n postgres-operator

Operator 可能需要一些时间才能完成初始化。报告就绪状态后，创建过程结束：

NAME       ENDPOINT                                   STATUS   POSTGRES   PGBOUNCER   AGE
cluster1   cluster1-pgbouncer.postgres-operator.svc   ready    3          3           143m

Operator 现已安装并部署完毕。接下来，您可以连接到 PostgreSQL 集群并像平常一样开始使用数据库。

连接到 PostgreSQL 集群

kubectl get secrets -n postgres-operator

我们目标的 Secrets 对象名为 cluster1-pguser-cluster1。我们将从您的 Secret 中检索 pgBouncer URI，对其进行解码，并将其作为 PGBOUNCER_URI 环境变量传递。

以下示例显示如何从默认 Secret 对象 cluster1-pguser-cluster1 传递 pgBouncer URI：

PGBOUNCER_URI=$(kubectl get secret ​​cluster1-pguser-cluster1 --namespace postgres-operator -o jsonpath='{.data.pgbouncer-uri}' | base64 --decode)

现在让我们创建一个 Pod，它运行一个包含 Percona Distribution for PostgreSQL 的容器并连接到数据库。以下命令执行此操作，将 Pod 命名为 pg-client 并连接到 cluster1 数据库：

kubectl run -i --rm --tty pg-client --image=perconalab/percona-distribution-postgresql:16 --restart=Never -- psql $PGBOUNCER_URI

创建 Pod 并建立数据库连接可能需要一些时间。准备就绪后，您将看到类似如下的输出：

If you don't see a command prompt, try pressing enter.
psql (16.2 - Percona Distribution, server 16.1 - Percona Distribution)
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, compression: off)
Type "help" for help.
 
cluster1=>

您现在已连接到 PostgreSQL 集群并准备开始创建表和插入数据！

Percona 在 Kubernetes 上使用 PostgreSQL 的方法
在 Kubernetes 上运行 PostgreSQL 是一回事。而 Percona 的与众不同之处在于，它能够良好地运行，并具备安全性、可扩展性、可观察性和专家支持。

我们不只是将一些工具打包在一起。我们的开源方法为您提供了一套可立即投入生产的 PostgreSQL 技术栈，它包含企业解决方案所需的所有功能，且没有隐藏的许可成本、功能限制或供应商锁定。

企业功能，无附加条件

使用 Percona Operator for PostgreSQL，您可以立即获得所需的一切：

• 通过 Patroni 和 HAProxy 实现高可用性，使用由 PostgreSQL 专家构建和测试的架构
• 通过 pgBackRest进行完整的备份和灾难恢复，具有完整和增量备份选项
• 使用 PgBouncer 实现高效的连接池，在高负载下保持性能
• 使用 pgAudit、set_user、角色管理和透明数据加密支持实现高级安全性（TD​​E 目前处于候选发布状态，预计将于 2025 年第三季度全面上市。）
• 使用 PMM 和 pg_stat_monitor 进行全面监控，这些工具专为 PostgreSQL 构建，可提供深入、可操作的见解

没有专有包装器或企业级层级。我们构建的一切都完全开源。

使用 Percona Everest 进行统一管理

对于在 Kubernetes 上管理多种数据库类型（PostgreSQL、MySQL、MongoDB）的组织，Percona Everest 提供了一个统一的自助服务平台。它简化了跨不同数据库集群的配置、扩展、备份和监控，为专有 DBaaS 平台提供了开源替代方案。

按照您的条件提供专业知识

有时您想独自管理一切。有时您需要合作伙伴。Percona 为您提供多种选择，而不会将您限制在一条路径上。

我们提供：

• 24/7/365 支持：PostgreSQL 专家提供具有保证的 SLA 的关键任务支持。
• 托管服务：让 Percona 处理您的数据库的日常操作、监控和维护。
• 咨询和健康检查：有关架构、性能调整、迁移和扩展的战略指导。
• 培训和入职：让您的团队掌握在 Kubernetes 上有效运行 PostgreSQL 所需的技能。
  由于我们支持 MySQL、MongoDB和PostgreSQL，因此即使您的基础设施不断增长，我们也能帮助您保持与数据库无关的特性。

使用 Percona for PostgreSQL 在 Kubernetes 上做更多事情

PostgreSQL 和 Kubernetes 的组合非常强大，但前提是拥有合适的架构、存储和运维支持。如果操作得当，这种方法可以为您提供一致、可扩展的 PostgreSQL 运行方式，无需依赖专有工具或牺牲性能。

这正是我们所提供的。

借助 Percona for PostgreSQL，您可以获得在生产环境中运行 PostgreSQL 所需的一切，从高可用性和安全性到备份、监控和企业级扩展。我们的 Operator for PostgreSQL 包含在解决方案中，为您提供一个完全开源、经过全面测试并由 PostgreSQL 专家支持的部署框架。

无锁定，无妥协。只需一种经过验证的方法，即可在您需要的任何地方安全可靠地运行 PostgreSQL。

原文地址：https://www.percona.com/blog/run-postgresql-on-kubernetes-a-practical-guide-with-benchmarks-best-practices/
原文作者：David Quilty