在 Kubernetes 上运行 Postgres 是可能的，但它是否符合您的需求？
Kubernetes 曾经是一个只能托管无状态工作负载的平台，虽然这已经发生了很大变化，高达90% 的人认为 Kubernetes 已经为有状态工作负载做好了准备，但“像 PostgreSQL 这样的数据库不能在 Kubernetes 上运行”仍然可以听到。然而，EDB的 Cloud Native 副总裁Gabriele Bartolini和2ndQuadrant的系统工程师Francesco Canovai 却不这么认为。
但他们不希望我们认为他们的话是理所当然的。如果一家公司正在考虑在 Kubernetes 上运行 Postgres，他们应该问的第一个问题是“为什么”。一旦确定了目标，对设置进行基准测试是确保根据需要执行设置的好方法。
Grabiele 和 Francesco 与我们分享了提出可靠方法的方法和工具，以确保在 Kubernetes 上托管 Postgres 是可行的方法。
巴特法瑞尔 00:02
欢迎大家！这是我们本周与来自意大利的人进行的第二次见面会。另一位意大利人加入了我们的行列，他以两种不同的方式体现了我们作为一个社区所追求的精神：（1）他将谈论在 Kubernetes 上使用数据库和有状态工作负载；（2）他是体现我们具有弹性的社区精神，不仅在数据弹性意义上，而且作为一个人，因为必须即兴发挥。Gabriele 应该由 Francesco 加入，他有望加入我们。弗朗切斯科遇到了意外情况，但我们希望他稍后会和我们在一起。Gabriele 对 Data on Kubernetes 并不陌生，他从事数据库和数据问题已经有一段时间了，目前在 EDB 工作。
巴特法瑞尔 01:36
PostgreSQL是一个非常吸引人的话题。为什么它如此吸引人，加布里埃尔？
加布里埃尔·巴托里尼 02:05
这是永远不会消失的事情之一。它是动态变化的。有了新技术，Postgres 一直在适应，这要归功于可扩展性。
巴特法瑞尔 02:29
经受住实战考验是件好事。Postgres 已经存在了很长一段时间。随着时间的推移，它有不同的技术变化，但就像一个社区一样有趣，我们举办的涉及 Postgres 的聚会通常会吸引很多注意力，你的也不例外。我们在 LinkedIn 上得到了很好的反馈，并得到了 EDB 其他人的大力支持。非常感谢大家。话虽如此，Gabriele，您可以直接进入您的演示文稿。
加布里埃尔·巴托里尼 03:40
为什么以及如何在 Kubernetes 上运行数据库？为什么我应该使用 Postgres 作为我的数据库技术？为什么我应该在生产之前对我的数据库进行基准测试？
如果您使用 Kubernetes，我敢肯定您一直在问自己前面的一个或多个问题，并且您至少对以云原生方式使用 Postgres 感到好奇。欢迎来到第 58 届 Data on Kubernetes 社区网络研讨会。今晚，如果我的同事 Francesco 准时回来，我将与他讨论为什么在 Kubernetes 中对 Postgres 进行基准测试很重要，并引入一套新的开源指南来帮助您完成该过程。让我快速介绍一下自己。
我的名字是 Gabriele Bartolini，正如 Bart 之前提到的，我住在意大利的一个叫普拉托的城市，它是托斯卡纳仅次于佛罗伦萨的第二大城市。早在 2007 年，这座城市就在欧洲举办了首届 Postgres 社区会议。我使用 Postgres 已经将近 20 年了，在过去的 15 年里我一直是社区成员。作为组织欧洲会议的协会 PostgreSQL Europe 的四位创始成员之一，我感到非常自豪。从一开始我就一直在使用 2ndQuadrant。我担任过多个职位，包括意大利和澳大利亚分公司的首席执行官、全球支持负责人以及云原生计划的负责人。自从收购 2ndQuadrant 以来，我一直是 EDB 的一员，在那里我也领导了云原生计划。我’ m 也是 Barman 的创始成员和贡献者之一——一种流行的开源工具，用于 Postgres 空间中的备份和恢复。我也是精益、敏捷和 DevOps 学科和文化的忠实粉丝。
Francesco 应该今天和我说话。但是他在最后一刻遇到了不幸的个人紧急情况，所以希望他能按时参加他的演讲。否则，我会尽力描述他在 EDB 与他的团队所做的实际工作。Francesco 于 2013 年开始在我的团队工作，是 Postgres 多个领域的专家，尤其是业务连续性、监控、基础设施和自动化。多年来，他为 2ndQuadrant 自动化测试态势的发展做出了贡献，从 CI/CD 管道的设置到测试编写，从单元测试到验收测试、冒烟测试等。他一直对容器技术感兴趣，并成为一位非常熟练的 Kubernetes 工程师。在业余时间，Francesco 是一名空手道教练。
继续我们的议程，我将讨论我在演示开始时提出的为什么问题，然后我将尝试介绍我们的倡议发生的背景。我将尝试解释为什么在对数据库进行基准测试之前对 Postgres 中的数据库工作负载的存储进行基准测试很重要，然后介绍我们名为 cnp-bench 的开源项目并在结束前分享一些结果。
让我们从为什么开始，在我看来，这总是好的。我在本次演讲开始时提出的第一个问题是为什么以及如何在 Kubernetes 上运行数据库？这里有一个重要的考虑因素，我认为我不应该详细介绍使用 Kubernetes 的好处。有了这些观众，我想我们都知道 Kubernetes 是什么。我将尝试描述我的观点，这可能与您的不同。
Kubernetes 的优势之一是 Kubernetes 发展和滋养的文化和生态系统。说到底，Kubernetes 只是一个工具。它甚至可能在未来被另一种工具所取代，但在我看来，重要的是 Kubernetes 的云原生方面。对于云原生，我基本上意味着三件事。第一个是 DevOps。基于 DevOps 的文化使团队和组织能够作为一个团队不断变化。从而创新并加速交付成果，以更安全、更高效和更有吸引力的方式为企业创造价值。二是基于容器的微服务架构。第三种是管理和编排这些容器的方法，例如使用 Kubernetes。
在微服务架构中，微服务应该拥有它所管理的数据并独占。这些可以是站点文件、队列、键值存储，或者在 Postgres 的情况下，一个包含结构化和非结构化数据的关系数据库。只有微服务可以访问数据库，包括模式管理和迁移。这将是理想的情况。我们还应该预见康威定律的必然后果通过利用微服务和组织我们的产品和系统。考虑每个团队认知负荷的界限。对于认知负荷，我喜欢使用 Dan North 的定义：“适合我们头脑的软件”。除此之外，我们人类无法高效运作。因此，设计松散耦合的基于微服务的系统，其 API 定义了明确的边界。
以上所有概念都引起了我的共鸣。这就是为什么我相信数据库在逻辑上可以很好地适应基于 Kubernetes 的云原生环境的原因，其中一切都是工作负载——包括数据库。通过拥有数据库，可以轻松地在为容器、分发和持续软件交付设计的 CI/CD 管道中测试应用程序。如果您想了解更多关于这个故事的信息，请扫描二维码阅读我最近写的一篇博客文章。
这里我们有一个在 Kubernetes 集群中具有自己的 Postgres 后端的微服务应用程序示例，该应用程序与另一个应用程序通信，该应用程序在另一个通过 Rest API 定义的 Kubernetes 集群中具有另一个 Postgres 后端。在这种情况下，他们使用 Postgres 拥有自己的数据库和数据存储。既然我们谈到了为什么数据库可以适应 Kubernetes，作为 Postgres 的长期社区成员和贡献者，我想讨论一下为什么我们应该在 Kubernetes 中使用 Postgres。
让我为不熟悉 Postgres 的人花几张幻灯片。在过去四年中，Postgres 连续第三年被 DB-Engine 评为最佳数据库。Postgres 是人类历史上最成功的开源项目之一。我将尝试在一张幻灯片中回顾 Postgres 的数十年发展历程，并根据我的经验和意见，我将尝试选择 Postgres 最显着的功能。如果我错过了你最喜欢的人，请原谅我。
对我来说，描述 Postgres 的一种快速方式是，它在数据库领域相当于 Linux 在操作系统领域所代表的内容。Postgres 当前最新的主要版本是版本 13，它提供了开箱即用的本地流复制，包括物理和逻辑。详细信息在下一张幻灯片中；持续热备份和指向时间恢复，用于水平表分区的声明式分区——一种提高单个实例的垂直可扩展性的技术，支持多模式混合数据库的 JSON 支持，同时包含结构化和关系。要使用 SQL 查询和存储在同一数据库中的结构化关系和非结构化数据。然后，可使用 PostGIS 等地理数据库扩展、垂直可扩展性并行查询等扩展的可访问性。在架构方面，Postgres 原生支持具有可选和多个副本的主/备用架构。复制背后的技术非常强大。这是进化论Crash Recovery和Point-In-Time Recovery技术，大约 15 年前通过 WAL shipping 和 Warm Standby 在 PostgreSQL 8.2 中首次引入。然后，它后来在 PostgreSQL 9.0 中通过 WAL 流和带热备的只读副本进行了改进。
进一步的改进包括同步复制，它支持 RPO 零集群和备份。零数据丢失集群和级联复制意味着从备用服务器进行复制。PostgreSQL 原生支持的最后一种复制是逻辑复制。由于字符串复制已经存在了十多年，该技术非常稳定、健壮，并保证了非常高的业务连续性结果，通过恢复点目标和报告恢复时间目标来衡量。
说了这些，我们现在可以探索如何在 Kubernetes 中安装 Postgres。有两种方法。第一种是基本方法，使用 Kubernetes 的自我修复功能，让一个 pod 运行一个没有 Postgres 级别副本的 Postgres 容器。通过存储实现复制和高可用性。但是，我们对第二种情况感兴趣。从现在开始，我将专门讨论第二种情况，即使用运算符来管理PostgreSQL。通过这样做，我们可以依赖 PostgreSQL 本机复制。我们正在将复制从存储级别提升到操作数和操作员级别。当我指的是操作数时，我指的是 Postgres。在这种情况下，应用程序和工作负载可能代表 Kubernetes 中的反模式，至少在 Data on Kubernetes 社区之外。说，我希望这个社区在这种情况下就应用程序级复制达成一致。Native Postgres 认证为我们带来了事务级别的同步提交、同步备用服务器级联复制和时间点恢复。确保数据库级别的业务连续性所需的一切，并有可能从目录中的第一个可用连续备份随时恢复。这里有一个重要说明，我知道我们在这里可能不客观，但我们在 EDB 的团队在过去 15 年中一直在 Postgres 中编写这些功能，并继续完善它们。多年来，通过在世界上一些最大的数据库上支持我们的客户，一切都得到了验证，这些数据库依赖于像 Postgres 这样的开源数据库管理系统。因此，我们在这里的信息是强烈的。我们希望将 Kubernetes 和 Postgres 带到任何地方。Kubernetes 是我们需要去的地方，也是我们需要做更多事情的原因——这是我们的使命。
这是可用于 Postgres 的运算符的非详尽列表。一些开源软件，如 Crunchy、Zalando、Stackgres、KudeDB 和 Kubegres。我知道以下会谈之一将是关于 Postgres 的[Álvaro 。]
加布里埃尔·巴托里尼 19:17
EDB 还有一个闭源运算符。这是我唯一会提到这些的地方；它被称为云原生 PostgreSQL。有了一个 30 天的隐式试用许可证，您可以将其与开源 PostgreSQL 一起使用，我记得 EDB 是代码和开发人员的主要贡献者，我们在 Postgres 系统本身上投入了大量资金。
我们在 EDB 的目标是利用世界上最好的数据数据库——Postgres 来利用云原生世界的所有好处。需要注意的是，要在 Kubernetes 上使用 Postgres，您需要一个具备 Kubernetes 和 Postgres 技能的多学科团队。因此，我之前提到了 DevOps 的重要性。这不是巧合。我们需要掌握整个系统并熟悉它——弱点、强点和限制。做这个的最好方式是什么？答案是基准测试。
Francesco 和我来自托斯卡纳的一个城市，离比萨不远。比萨是伽利略·伽利莱出生的地方。因此，科学方法烙印在我们身上。这是我们的一部分。不幸的是，整个团队需要不断地声明期望，运行实验，测量结果，并将它们与最初的期望进行比较。随着时间的推移，这些方法多次拯救了我们。无论我们的组织规模大小，无论我们是小时候还是大，等等，以及客户。它还使我们能够赢得有时超出我们能力范围的其他挑战。另一个重要的建议是尝试将我们的注意力从技术手段上移开；工具，或者我们为实现实际目标而一直这样做的方式，这可能会迫使我们走不同的道路来实现我们的目标，并总是问我们为什么要做某些事情。
我最喜欢的那些过去和现在在某种程度上反复出现的问题引发了一个问题：就恢复点目标或恢复时间目标而言，您的目标是什么？Postgres 没有 RAC。还有其他方法可以达到目标。另一个是，比如说，我想要无限的水平可扩展性；就每秒事务而言，横向可扩展性的实际需求在哪里？我想澄清一下。我不是说这些，因为 Postgres 天生不支持查询和数据分发。假设我们的基准测试结果显示每秒观察到的事务数不满足我们对单个主系统的实际要求。在这种情况下，我们应该考虑不同的选项，包括水平可扩展性——跨不同服务器和节点的数据分布。
最后，让你的决定由数字和测量而不是意见驱动，因为每个人都知道应该这样做。请记住，每个上下文都与您的想法不同，并根据数字做出决定。在这些情况下，数字可以拯救你。如果您打算在任何环境中使用 Postgres，请始终对 Postgres 进行基准测试；在生产之前，最好在受控环境中。基准测试对于容量规划和优化成本很重要。这也是产生技术信誉的基本机会，我们可能会在 Postgres 数据库投入生产后发现它很有用。例如，我们可能会遇到性能变化并打开支持事件。
我负责 2ndQuadrant 的 24/7 支持。然后，我们的一位客户遇到了性能问题。我们可能会遇到两种可能的情况。第一种情况是令人愉快的，我们根据在生产之前所做的存储和数据库基准测试了性能、可预测性和明确的预期。另一方面，令人不快的是，没有进行基准测试。当系统投入生产时，运行基准测试为时已晚。
存储性能可能会有所不同。不要相信供应商声明的值，而是验证它们。衡量数据库性能，因为它严重依赖于存储，这通常是我们的瓶颈。我要分享一个不久前的故事。一位客户向我们抱怨 Kubernetes 上的 Postgres 很低。事实证明，顺序读取的底层持久卷吞吐量为每秒 3 MB。Postgres 或任何东西都无法运行它。
加布里埃尔·巴托里尼 25:25
我想分享我们团队的一切是如何开始的。那时，我是 2ndQuadrant 的全球支持主管。我们的团队基于 DevOps、精益和敏捷原则、价值观等培养了一种非常积极的团队文化。我们对新技术进行探索和试验具有扎实的心态，并始终如一地学习、取消学习、采用和放弃工具，这些工具专注于个人在哪里分配领导力和赋予人们权力。2019 年 8 月，CEO 要求我为公司制定一个计划，让 Postgres 进入 Kubernetes 市场。几年来，我们对这个领域正在发生的事情充满兴趣，并与我们在 Zalando 的朋友定期交谈。我们渴望在 Kubernetes 上工作。已经在我们所有的 CI/CD 管道中采用了容器技术，
我记得有几个重大挑战。首先，我们站在 Kubernetes 专家的角度，问自己以下问题：(1) Postgres 在 Kubernetes 中缺少什么？(2) Kubernetes 缺少什么？这两个问题都要求我们快速精通 Kubernetes。我们非常清楚，尽管我们在 Postgres 系统中拥有权威，但我们在 Kubernetes 中却是无名小卒。我们以认证 Kubernetes 管理员 (CKA) 认证为目标，并且是第一家成为 Kubernetes 认证服务提供商 (KCSP) 的 Postgres 公司。我们将 Kubernetes 上的整个 Postgres 视为一个紧急问题。因此，我们采用了快速失败的探索模式。尽管我们希望这成为可能，但我们的心态是快速了解我们是否必须在最短的时间内放弃该项目。我们知道 Postgres 的高可用性是其他玩家已经解决的问题。但是，我们想针对以前没有人尝试过的东西：使用专用的物理工作节点来运行 Postgres 实例，看看 Postgres 是否以及如何在裸机 Kubernetes 上运行。如果这导致不可能，我们就会退出。
我的同事 (Marco) 和我在 2019 年使用 KubeCon North America 来验证我们的假设。我们决定简要参与 CNCF 的六个存储组。我建议我们的团队使用最近在 Kubernetes 1.14 中引入的本地持久卷执行一些基准测试，但我们在裸机上运行它。Francesco 是该项目的负责人。我们在 Hetzner 云中拥有自己的[裸机 Kubernetes 集群。]我们进行了存储测试，可以说，结果非常令人鼓舞。这就是我们正在寻找的答案，我们决定继续。我们的存储结果发表在[博客文章中]，在 Kubernetes 的数据存储社区中非常流行。我们使用商用硬件、专用的本地 SSD 存储、使用硬件 RAID 控制器的简单设置，并直接在 Linux 上执行存储基准测试，然后在 Kubernetes 中使用 fio。我们使用开放的 EBS 本地持久卷，顺序读取和写入的结果与裸机几乎相同。然后我们继续对 Postgres 进行基准测试，结果遵循相同的存储模式——与裸机具有可比的行为。与此同时，从 EDB 获得 2ndQuadrant 的过程已经开始，我们不得不暂停我们的活动。我本应成为本次 Data on Kubernetes 社区网络研讨会的第一名或第二名，所以我很高兴终于来到这里。
然后我们在 10 月份完成收购后恢复了工作，我们就到了这里。现在让我们看看数据库期望从底层存储中获得哪些功能。我们都希望它是可用的和可扩展的，以便它表现良好并保证一致性和持久性。传统上，Postgres 管理员将存储可用性与他们的托管操作系统相关联。可扩展性是通过表空间、LVM 或存储在线调整大小来实现的。因此，对于 Postgres，我们主要关注性能——支持请求、一致性和持久性的主要来源之一。
幸运的是，在存储访问模式方面，与 MDM 和裸机相同的概念在 Kubernetes 中仍然有效。我们只需要将我们所知道的与 Kubernetes 如何管理存储（即存储类、PVC 等）集成起来。主要有两种访问存储的方法：
(1) 直接或间接通过网络，例如 NFS 卷
网络存储无疑是 Kubernetes 中最常用的模式，并且在 Kubernetes 集群外部或内部都有许多可用的解决方案。此外，复制通常在文件系统级别。Kubernetes 中的网络存储呈现出与我们在其他所有环境中遇到的相同的吞吐量和延迟问题。
(2) 运行 Pod 的 Kubernetes 节点的本地存储
这包括 DAS 或直接附加人们喜欢的数据库。这在历史上是 Kubernetes 中的一种反模式。我们看到这种情况正在发生变化，我们希望数据库的无共享架构在 Kubernetes 空间中变得更加普遍。
无共享架构带来了性能可预测性，尽管它是有代价的。代价是更难的可扩展性。但是，Postgres 另有规定要这样做。高可用性委托给 Postgres，我们将持久性控制到数据库事务级别。
现在让我们看看存储可能成为 Postgres 等数据库管理系统瓶颈的一些关键领域。作为免责声明，这张幻灯片提供了 Postgres 如何与存储交互的简化视图。让我们从事务日志开始，在 Postgres 中称为预写日志 (WAL)。Postgres 最重要的资产是业务连续性能力，因为它们构成了崩溃恢复、时间点恢复和复制的基础。简而言之，WAL 是按顺序写入的逻辑文件，通常由单独的文件组成。每个最多有 16 MB。它们包含数据库发生更改的历史记录。我们需要确保在更改缓冲区中的实际页面之前写入信息。因此，我们要求更改与磁盘同步，以便在崩溃或突然断电后会擦除磁盘和数据库之间的任何中间缓存的内容。当我们向表中添加记录或修改其内容时，更改首先存储在 WAL 中，然后存储在共享缓冲区中，以便更快地访问和检索数据。当页面（通常为 8 kB）在内存中被修改时，这些缓冲区会变脏，并且内容与实际内容不同。它们被清除，这意味着内存中的版本在三个事件之后与磁盘上的版本匹配。第一个是检查站。它们通常基于超时和自上次检查点以来的更改次数甚至手动发出。通常，缓冲区刷新的写入分布在两个检查点之间，以避免写入操作出现峰值。第二个是背景作家。第三种模式是通过实际的后端进程。后端进程是需要写入数据但发现缓冲区已满的查询。如果页面溢出成为常态，那么数据库就会在厌氧模式下运行——它没有正确配置或调整大小。因此，我们需要在这里采取行动。
对于缓冲区清理，我们需要查看随机写入性能。此外，操作系统缓存可能在这里发挥重要作用，但这是另一个不同的主题。每当一个页面被查询的进程需要并且它不在缓冲区中时，Postgres 需要从磁盘中获取该页面。这不仅对表有效，对索引也有效。在这种情况下，随机读取很重要。但是，随机读取并不总是像顺序读取一样快。Postgres 计划器足够聪明，可以根据统计数据实现，如果您要获取关系的大部分，按顺序读取整个表会更快。这是数据仓库工作负载中的常见模式，在这种情况下，顺序读取性能变得至关重要。
根据我们的经验，在为数据库使用准备系统时，我们应该对存储进行基准测试并确定顺序和随机读写的吞吐量。我们需要考虑的另一个方面，尤其是在云环境中，是每秒输入和输出操作的数量，在某些情况下可能会受到限制。但是，它们最终会影响吞吐量，这是我们应该牢记的。现在，我们进入下一个问题：如何测量存储量？我们的解决方案是使用最常用的工具之一——fio。过去，我们也使用过开源工具 bonnie++。它是高度可配置的，并且在 Kubernetes 上也受支持。它支持多种 IO 工作负载，但我们稍后会看到。
我们的团队通常会说，“慢速存储通常会产生慢速数据库”，除非他们的访问模式主要在内存中。既然我们已经了解了如何对存储进行基准测试，那么现在让我们谈谈 Postgres 中最常见的工作负载。其中之一是内存中。这意味着数据库完全适合数据库缓冲区。它主要绑定到 CPU 和内存。最典型的使用模式是在线事务处理 (OLTP)，这意味着我们有许多混合了插入、更新和读取的小型并发事务。第三个是用于 BI 数据仓库。它使用历史数据库进行报告。它是在线分析处理。更少的查询更复杂，需要阅读大部分时间序列。
我们的计划主要关注数据库大小大于可用 RAM 的所有 OLTP 工作负载。因此，数据库不适合内存，迫使我们依赖这些公司，我们可以看到这种存储如何影响数据库。此外，我们要衡量的是我们每秒的交易量。
我们选择了pgbench，它是 Postgres 中的默认基准测试工具。它与 Postgres 一起分发。它提供并模拟了一个类似TPC-B的工作负载——一种在线事务处理工作负载。它是高度可配置的。在我们最初的实验中，我们使用标准查询，但我们也可以注入我们自己的和自定义的查询来模拟不同的工作负载。将来，我们希望添加应用程序级别的测试，以便我们可以使用池，例如副本部署或前面带有干草的 Web 应用程序，它们会生成随机 Web 访问。
弗朗切斯科·卡诺瓦伊 40:25
为了在 Cloud Native Postgres 上测试和获得基准测试，我们开发了一个名为cnp-bench的工具。它是 Helm 图表的集合，这意味着它将非常容易运行和自定义，并且结果将很容易重现。我们想要一些可以在 Kubernetes 旅程开始时使用的东西；具有 Postgres 经验并开始从事 Kubernetes 工作的人可以轻松使用 Helm 图表并对其进行自定义。
我们决定使用 Gabriele 之前谈到的工具 fio 和 pgbench 来监控我们可以从某个设置中获得的 IOPS 和每秒事务数。代码可在 GitHub 上找到。在企业版活动下，您将能够获得代码。
我们有两张图表，一张是用于对存储进行基准测试的 fio 基准测试。此图表创建 PVC，您可以对其进行自定义并选择从中获取 PVC 的存储类。您可以选择 PVC 的大小，然后 fio 波段图表将创建一个包含 fio 作业的配置映射，这不是 Kubernetes 作业，而是 fio 应该如何运行工作负载。然后，它会部署一个 pod，其中包含一个运行基准测试的文件，并在您完成后在 Web 服务器上提供结果。YAML 中的值很简单。第一部分是指 PVC，然后是关于我们要运行的 fio 作业的信息。运行后，您将获得结果、带宽和 IOPS。
例如，这是在我的笔记本电脑上运行的集群上执行的。我的笔记本电脑能够以每秒约 135 MB 的速度运行。然后类似地，我们有一个 pgbench 的 Helm 图表，它启动了一个 Cloud Native PostgreSQL 集群。再一次，您可以在图表中对其进行自定义，因为不同的 Postgres 设置可以提供不同的性能。然后，您定义要运行的 pgbench 作业。这也是一项 Kubernetes 工作。您可以根据需要定义数据库的大小以及 pgbench 将执行的连接数。最后，您可以获取 pgbench pod 的日志，看看发生了什么。
回到 YAML 中的值，前半部分专用于 Postgres 配置，而后半部分用于 pgbench。我们还使用节点选择器来避免 pgbench 作业在相同的节点和 Postgres pod 上运行，因此它们不会相互影响。您可以在运行图表的系统上获得日志和每秒的事务量。有了这个，我们决定在云上运行一些测试。我们已经开始在Azure上进行测试。我们想看看 Azure 上的网络存储是如何执行的。我们已经测试了一些虚拟机和磁盘的组合。
当您使用公共云时，会遇到各种复杂情况，因为您必须决定 VM 的大小。它的大小不仅可以定义您拥有的 CPU 数量或您拥有多少 GB 的 RAM；不同的 VM 系列可以有不同的限制。例如，您可以拥有限制底层存储上 IOPS 的 VM，然后拥有存储本身。同样，您可以拥有具有不同限制的不同存储空间。但是，某些磁盘允许您在短时间内超过限制，称为条形图。它通常可用于 AKS 上的较小磁盘。
我们使用了Standard_E8d_v4. 连同这些结果，它有 8 个 CPU、64 GB 的 RAM 和 4 Gbps 的定义带宽量。我们已经用不同的存储对其进行了测试。它们都是来自 Azure 的高级磁盘。Azure 中磁盘的速度与大小有关；磁盘越大，它应该能够运行得越快。较小的 P10 只有 100 GB。它可以为您提供更大的 500 IOPS。您最多可以获得 20,000 个。根据网站上的记录数据，我们选择运行一小时的测试。对于 fio，我们选择使用 8 kb 的块大小，因为它是 Postgres 使用的。在全球范围内，最快的磁盘更好。选择 8 kb 块，IOPS 主要限制了我们的操作。我们永远无法达到磁盘所拥有的带宽量。我们进入 IOPS 级别，但这里有一些奇怪之处。例如，P10 看起来具有非常高的读取速度。P30 正在超越其极限，而 P80 从未达到极限。你必须熟悉。这些都有解释。它们被记录在案。比如我之前说的，有的在爆裂处使用小盘。虽然平均而言，我们已经超过了 500 IOPS 作为上限。前半小时，我们以 3500 的条形速度运行，然后我们有声明的 500 IOPS。如果你看这个，你不能决定你的数据库，因为平均在 2000 左右，它将以 2000 运行并且通常以 500 IOPS 运行。如果您的数据库很小，那可能会很好，但对于较大的数据库则不然。虽然平均而言，我们已经超过了 500 IOPS 作为上限。前半小时，我们以 3500 的条形速度运行，然后我们有声明的 500 IOPS。如果你看这个，你不能决定你的数据库，因为平均在 2000 左右，它将以 2000 运行并且通常以 500 IOPS 运行。如果您的数据库很小，那可能会很好，但对于较大的数据库则不然。虽然平均而言，我们已经超过了 500 IOPS 作为上限。前半小时，我们以 3500 的条形速度运行，然后我们有声明的 500 IOPS。如果你看这个，你不能决定你的数据库，因为平均在 2000 左右，它将以 2000 运行并且通常以 500 IOPS 运行。如果您的数据库很小，那可能会很好，但对于较大的数据库则不然。
接下来，我们问，为什么我们有这种方式更高的读取？磁盘具有读取缓存。如果您尝试在没有读取缓存的情况下运行相同的测试，结果会更加一致。对于 P10，无缓存，您从 483 MB/s 降至 16。磁盘的缓存大于磁盘本身和我们正在写入的文件。一遍又一遍地运行相同的测试，数据会进入缓存，你会得到这些结果。
读取缓存对数据库有好处，所以不要禁用它。但是，很高兴看到对这种结果有解释。例如，文档中没有关于这台机器上缓存的信息，但系统机器说它有 200 GB 的缓存。这很容易解释这种行为。此外，与这些土狼的上限相同的系统机器约为 12,000。这也可以解释为什么我们无法从 P80 磁盘达到我们应该拥有的声明的 20,000 IOPS。这意味着当你去尝试磁盘上发生的事情时，你可以根据学校环境得到不同的结果。您需要知道您正在运行什么，特别是如果您知道您对数据库的要求是什么。在数据库大小上，我们测试了 pgbench。我们在不同的磁盘上定义了不同的数据库大小，因为它们比另一个大。小型磁盘上的小型数据库或大型磁盘上的大型数据库，但速度更快，因为每秒事务量的大部分速度可以满足超过 1000 个事务，这对于中型数据库来说是件好事。Postgres 的配置大多是默认的。我们更改了一些参数，以便从具有 64 GB RAM 的机器上获得更好的结果。我们提高了共享缓冲区，并且提高了 max_wal_size。不要检查点太多。最后的结果是好的。Postgres 的配置大多是默认的。我们更改了一些参数，以便从具有 64 GB RAM 的机器上获得更好的结果。我们提高了共享缓冲区，并且提高了 max_wal_size。不要检查点太多。最后的结果是好的。Postgres 的配置大多是默认的。我们更改了一些参数，以便从具有 64 GB RAM 的机器上获得更好的结果。我们提高了共享缓冲区，并且提高了 max_wal_size。不要检查点太多。最后的结果是好的。
本地存储呢？这个想法是它应该更快；它直接在机器上。我们已经测试了 L8s 作为机器。它是带有 NVME 磁盘的机器系列。他们的结果在行速度方面要好得多。每秒交易量增加了十倍，速度提高了一倍。这又回到了最初的想法，即数据库的本地存储是一个有趣的点。我们会让加布里埃拉得出结论。
加布里埃尔·巴托里尼 56:35
本次演讲有三个主要内容。首先，提供一种在 Kubernetes 中对 Postgres 数据库进行基准测试的方法。其次，开源工具集，以及为什么 Kubernetes 用于数据库和 Postgres 是一个有效的选择。接下来是为什么基准测试很重要，最后，您现在可以访问 cnp-bench 的链接。在接下来的几周和几个月内，您将收到我们的更多消息。我们也在招聘。如果您想与我们合作，请访问 URL。我们需要团队中的人。
巴特法瑞尔 57:53
Gabriele，我们今晚至少可以回答一个问题，然后我们可以在 Slack 中讨论其他问题。
加布里埃尔·巴托里尼 58:27
对于问题：在运行高可用 Postgres 时我们应该考虑哪些因素？在我看来，无共享架构是基础。这意味着将 Postgres 实例分布在不同的 Kubernetes 节点上，可能将专用节点分配给单个实例，并将专用存储用于可能位于该节点本地的节点，正如我之前在性能可预测性中解释的那样。但是，仅靠高可用性是不够的。您需要灾难恢复能力来实现业务连续性，而 Postgres 支持连续备份和时间点恢复，这对于企业级数据库上下文至关重要。实例可以分布在同一个 Kubernetes 集群中的不同区域。我们还作为 EDB 致力于 Postgres 的跨集群复制，预计将在今年晚些时候完成。
还有一个问题是关于使用操作符相对于以老式方式安装数据库的优势。这取决于运营商。容器方法仅提供自愈能力。然后复制可用性全部专用于委派的文件系统级别。然后，操作员提供更高级别的体验，包括同步复制。有自动故障转移、计划切换、滚动更新、读取操作的扩展和 TLS 的透明管理。Postgres 是一个复杂的应用程序。我认为在管理复杂的应用程序和工作负载时，我们需要操作员。
巴特法瑞尔 1:01:05
作为传统的一部分，我们社区中有一位出色的艺术家，他总是出现在我们的聚会中，为我们今天的演讲提供了视觉呈现。再一次，当 Gabriele 开始时，从“为什么？”开始。是我们社区的重要组成部分；我们为什么要这样做？您可能会遇到来自客户的一些阻力，这可能会带来其他困难或问题。但是，当你从一开始就明白“为什么”时，你可以多一点耐心来对待许多其他的事情。话虽如此，感谢你们今天与我们共度时光。
原文标题：Benchmarking PostgreSQL Workloads on Kubernetes
原文作者：西尔万卡拉奇
原文地址：https://dzone.com/articles/benchmarking-postgresql-workloads-on-kubernetes
