去年年底，俄罗斯PostgreSQL社区
#RuPostgres进行了另一场直播，其联合创始人Nikolai Samokhvalov与Flanta技术总监Dmitry Stolyarov在Kubernetes的背景下讨论了该DBMS。
我们正在发布本次讨论的主体成绩单，并
在该社区的YouTube频道上发布了完整的视频：
数据库和Kubernetes
NS ：我们今天不会谈论VACUUM和CHECKPOINT。 我们想谈谈Kubernetes。 我知道您有多年的经验。 我看了您的视频，甚至还看了其中的一些片段……让我们马上开始：为什么在K8s中使用Postgres或MySQL？DS ：这个问题没有一个单一的答案，而且不可能。 但总的来说，它具有简单性和便利性……潜力。 毕竟，每个人都想要托管服务。
NS ：喜欢RDS ，只能在家吗？DS ：是的，只喜欢RDS。
NS ：“任何地方”都是一个好主意。 在大型公司中，所有内容都位于不同的位置。 那么，如果这是一家大公司，为什么不采用现成的解决方案呢？ 例如，Nutanix有自己的发展，而其他公司（VMware ...）具有相同的“仅在家中使用RDS”。DS ：但是，我们谈论的是仅在某些条件下才能运行的单个实现。 而且，如果我们谈论的是Kubernetes，则基础设施种类繁多（可以在K8中使用）。 这本质上是云API的标准...
NS ：它也是免费的！DS ：这不是那么重要。 对于很大一部分市场来说，免费并不重要。 另一件事很重要……您可能还记得报告“
数据库和Kubernetes ”？
NS ：是的。DS ：我意识到他的模棱两可。 有人以为我是在说：“伙计们，所有数据库都归Kubernetes了！”，而其他人则认为它们都是可怕的自行车。 我想完全说一句：“看看正在发生什么，有什么问题以及如何解决。 现在去Kubernetes基地吗？ 生产？ 好吧，只有在您喜欢...做某些事情的情况下。 但是对于开发人员，我可以说我推荐它。 对于开发人员而言，动态创建/删除环境非常重要。”
NS：“开发人员”是指所有非生产环境吗？ 分期，质量检查...DS ：如果我们谈论的是Perf摊位，那么可能还没有，因为那里的要求是特定的。 如果我们谈论的是在临时情况下需要非常大的数据库的特殊情况，那么可能就不太可能了……如果这是一个长期存在的静态环境，那么将基地设在K8中有什么好处？
NS ：没有。 但是我们在哪里看到静态环境？ 明天的静态环境已经过时了。DS ：分期可以是静态的。 我们有客户...
NS ：是的，我也有。 最大的问题是，如果您的基础容量为10 TB，并且分段-200 GB ...DS ：我的箱子很酷！ 分期进行时，有一个可以进行更改的产品基础。 并提供一个按钮：“开始生产”。 这些变化-增量-已在生产中添加（看来，它们只是通过API进行了同步）。 这是一个非常奇特的选择。
NS ：我看到硅谷的初创公司坐在RDS或什至在Heroku中-这是2-3年前的故事-他们将转储下载到他们的笔记本电脑中。 到目前为止，由于底座仅80 GB，因此在笔记本电脑上有一个位置。 然后他们为每个人购买磁盘，因此他们有3个基础，以便他们可以进行不同的开发。 这也发生。 我还看到他们不害怕将产品复制到阶段中-这在很大程度上取决于公司。 但是他看到他们很害怕，而且他们经常没有足够的时间和双手。 但是，在继续讨论该主题之前，我想听听有关Kubernetes的信息。 我正确理解，到目前为止，没有人吗？DS ：我们的产品基础很小。 我们正在谈论的是数十GB的容量和非关键服务，对于这些服务来说，创建副本太懒了（并且没有这种需求）。 并且只要在Kubernetes下有一个普通存储即可。 该数据库在虚拟机上工作-在存储之上有条件地在VMware中工作。 我们将其放置在
PV中 ，现在我们可以将其从汽车转移到汽车。
NS ：可以在几分钟之内推出具有良好磁盘和良好网络的高达100 GB的这种大小的数据库，对吗？ 每秒1 GB的速度不再是奇特的。DS ：是的，对于线性操作，这不是问题。
NS ：好的，我们应该只考虑产品。 如果我们考虑将Kubernetes用于非产品环境-怎么做？ 我看到在Zalando 他们正在做一个操作员 ，在Crunchy中他们正在锯 ，还有其他一些选择。 还有OnGres-这是我们来自西班牙的好朋友Alvaro：他们基本上不仅是运营商 ，而是整个发行商（ StackGres ），除了Postgres本身之外，他们还决定填充备份，Envoy代理...DS ：特使是为了什么？ Postgres流量平衡到底是什么？
NS ：是的。 也就是说，他们将其视为：如果您使用Linux发行版和内核，那么通常的PostgreSQL是内核，并且他们希望制作一个对云友好且可在Kubernetes上运行的发行版。 它们停靠组件（备份等）并进行调试，以使其正常运行。DS ：太酷了！ 本质上，它是制作托管Postgres的软件。
NS ：Linux发行版有一个永恒的问题：如何制作驱动程序，以便支持所有硬件。 他们的想法是，他们将在Kubernetes工作。 我知道在Zalando运营商中，我们最近看到了AWS上的眼球，但这不是很好。 不应与特定的基础结构有联系-那么意义何在？DS ：我不知道Zalando在什么具体情况下参与进来，但是在Kubernetes中进行存储的方式是不可能以通用方式删除磁盘备份的。 最近，在
CSI规范的最新版本中，该标准提供了快照的可能性，但是在哪里实现呢？ 老实说，它还很原始...我们正在AWS，GCE，Azure，vSphere之上尝试CSI，但是由于您可以看到它尚未准备就绪，所以我们开始使用它了。
NS ：因此，有时您必须配合基础架构。 我认为这仍是早期阶段-增长问题。 问题：您对想在K8s中尝试PgSQL的初学者有什么建议？ 可能是哪个运算符？DS ：问题是对我们来说Postgres是3％。 在Kubernetes中，我们仍然有很多不同软件的清单，我什至不会列出所有清单。 例如，Elasticsearch。 运营商很多：有些正在积极发展，有些则没有。 对于我们自己，我们提出了操作员应具备的要求，因此我们非常重视他。 运算符专门用于Kubernetes，而不是“在亚马逊条件下做某事的运算符...”实际上，我们
为Redis使用了一个运算符（=几乎所有客户）（广泛使用）
（我们将很快发表一篇有关它的文章） 。
NS ：但是对于MySQL也是如此？ 我知道Percona ...因为他们现在涉及MySQL，MongoDB和Postgres，所以他们将必须修复某种通用的方法：对于所有数据库，对于所有云提供商。DS ：我们没有时间查看MySQL的声明。 对我们来说，这不是现在的主要重点。 MySQL独立运行良好。 为什么要成为操作员，如果您只能启动数据库...您可以使用Postrges启动Docker容器，也可以通过简单的方式启动它。
NS ：这也是一个问题。 完全没有操作员？DS ：是的，我们100％的人都在没有操作员的情况下运行PostgreSQL。 到目前为止。 对于Prometheus和Redis，我们积极使用运算符。 我们计划找到Elasticsearch的运算符-它消耗最多，因为我们想100％地在Kubernetes中安装它。 正如我们想确保MongoDB也始终安装在Kubernetes中一样。 某些心愿单出现在这里-感觉在这些情况下可以做一些。 而关于Postgres，我们甚至都没有看。 当然，我们知道存在不同的选择，但实际上我们是独立的。
Kubernetes中的测试数据库
NS ：让我们继续测试的话题。 从DevOps的角度来看，如何推出数据库中的更改。 有微服务，许多数据库，总是在某些地方发生变化。 如何确保CI / CD正常，以便一切都从DBMS位置井井有条。 你的方法是什么？DS ：没有答案。 有几种选择。 首先是我们要推广的基础规模。 您自己曾提到过，公司对于在开发和阶段复制产品有不同的态度。
NS ：就GDPR而言，我认为它们越来越整齐...我可以说在欧洲，它们已经开始罚款。DS ：但是您经常可以编写用于转储产品并对其进行混淆的软件。 原来是prod'ovye数据（快照，转储，二进制副本...），但它们是匿名的。 相反，可能有生成脚本：它可以是装置，也可以只是生成大型数据库的脚本。 问题是什么：创建基础映像需要多长时间？ 在正确的环境上部署多少时间？
我们采用了该方案：如果客户端有一个夹具数据集（数据库的最低版本），那么默认情况下我们将使用它们。 如果我们谈论的是审阅环境，那么在创建分支时，我们已经部署了一个应用程序实例-我们在那里部署了一个小型数据库。 但是，当我们每天（晚上）从生产环境中删除一次转储并在其基础上收集包含这些已加载数据的PostgreSQL和MySQL的Docker容器时，该
选项就很好了。 如果您需要从该映像部署基础数据库50次，则可以非常简单，快速地完成此操作。
NS ：简单的复制？DS ：数据直接存储在Docker映像中。 即 我们有一个现成的映像，尽管100 GB。 由于Docker中的层，我们可以根据需要快速多次部署此映像。 该方法很傻，但是效果很好。
NS ：此外，在测试时，它会在Docker内部更改，对吗？ 在Docker内部进行写时复制-将其丢弃并再次运行，一切都很好。 上课！ 您已经将它与may和main一起使用了吗？DS ：很久了。
NS ：我们做的事情非常相似。 只有我们不使用Docker的写时复制，而是更多。JS ：他不是普通人。 Docker'ny随处可见。
NS ：从理论上讲，是的。 但是我们那里也有模块，您可以制作不同的模块并使用不同的文件系统。 等等 从Postgres，我们以不同的方式看待所有这一切。 现在，我从Docker的角度看，发现一切都对您有效。 但是，如果数据库很大（例如1 TB），那么就太长了：晚上都进行操作，将所有东西都塞在Docker中……如果5 TB塞进了Docker……还是一切正常吗？DS ：有什么区别：它是blob，只是位和字节。
NS ：区别是：您是否通过转储和还原来做到这一点？DS ：完全没有必要。 生成此图像的方法可以不同。
NS ：对于某些客户，我们做到了，因此我们不定期生成基本图像，而是不断更新其图像。 它本质上是一个副本，但不是直接从主数据库接收数据，而是通过存档接收数据。 每天都会在其中滚动WAL的二进制归档文件，并且在那里也删除备份...这些WAL随后会以轻微的延迟（从字面上说是1-2秒）飞到基本映像。 我们可以通过任何方式克隆它-现在默认情况下具有ZFS。DS ：但是使用ZFS，您只能使用一个节点。
NS ：是的。 但是ZFS也具有神奇的发送功能 ：您可以发送快照，甚至（我尚未真正测试过快照，但是...）您也可以在两个PGDATA之间发送增量。 实际上，我们还有另一个我们并未特别考虑用于此类任务的工具。 PostgreSQL具有pg_rewind ，它可以作为“智能” rsync，跳过了许多您不必注意的事情，因为可以肯定的是，那里没有任何变化。 我们可以在两个服务器之间进行快速同步，并以完全相同的方式倒带。因此，我们正在尝试在DBA'noy方面做更多的工作，以制作一种工具，使您可以执行与您说的相同的事情：我们有一个基础，但我们希望同时进行50次测试。DS ：50次表示您需要订购50个Spot实例。
NS ：不，我们在一台机器上做所有事情。DS ：但是，如果这个基础是1 TB，那么您将如何部署50次。 很可能她有条件地需要256 GB的RAM？
NS ：是的，有时需要很多内存-这是正常的。 但是这样的例子来自生活。 该生产机具有96个内核和600 GB。 同时，数据库使用32个核心（有时甚至使用16个核心）和100-120 GB的内存。DS ：那有50份？
NS ：所以只有一个副本，然后写时复制（ZFS'ny）起作用了……我会告诉你更多。例如，我们有一个10 TB的基数。 他们为此制作了一个磁盘，ZFS仍将其百分比大小压缩了30-40。 由于我们不进行负载测试，因此确切的响应时间对我们来说并不重要：让它慢2倍-没关系。我们启用程序员，QA，DBA等。 在1-2个线程中执行测试。 例如，他们可以开始某种迁移。 它一次不需要10个核心-它需要1个Postgres后端，1个核心。 迁移将开始-也许自动真空仍将开始，然后激活第二个核心。 我们分配了16-32个内核，因此10个人可以同时工作，没有问题。由于PGDATA物理上是相同的，因此事实证明我们实际上是在愚弄Postgres。 诀窍是这样的：例如，它同时启动10个Postgres。 通常是什么问题？ 他们将shared_buffers设置为25％。 因此，这是200 GB。 您开始的时间不会超过三个，因为内存将结束。但是在某个时候，我们意识到这不是必需的：我们将shared_buffers设置为2 GB。 PostgreSQL具有有效的缓存大小，实际上只有它会影响计划 。 我们将其设置为0.5 Tb。 而且，即使他们真的不在那也没关系：他像制定计划一样。因此，当我们测试某种迁移时，我们可以收集所有计划-我们将看到它在生产中将如何发生。 秒数将有所不同（较慢），但是实际读取的数据以及计划本身（什么样的JOIN等）的获取与生产时完全相同。 同时，您可以在一台计算机上运行许多此类检查。DS ：您认为有几个问题吗？ 第一个是仅适用于PostgreSQL的解决方案。 这种方法非常私密，不是通用的。 第二个-Kubernetes（这就是云现在要去的地方）涉及许多节点，这些节点是短暂的。 在您的情况下，它是一个有状态的持久节点。 这些事情与我矛盾。
NS ：首先-我同意，这纯粹是Postgres的故事。 我认为，如果我们有几乎所有内存的直接IO和缓冲池，则此方法将不起作用-会有不同的计划。 但我们目前仅与Postgres合作，我们不考虑其他人。关于Kubernetes。 您自己总是说我们有一个持久的基础。 如果实例崩溃，最主要的是保存磁盘。 在这里，我们还在Kubernetes中拥有了整个平台，并且Postgres的组件是独立的（尽管有一天会存在）。 因此，一切都是这样：实例掉了，但我们将其保存为PV并仅连接到另一个（新）实例，好像什么也没发生。DS ：从我的角度来看，我们在Kubernetes中创建了pod。 K8s-弹性的：组件可根据需要单独订购。 任务是简单地创建一个Pod，并说它需要X个资源，然后K8会解决这个问题。 但是Kubernetes的存储支持仍然不稳定：在
1.16版 ，
1.17版 （此版本于
几周前发布）中，这些功能仅是beta版。
六个月或一年将过去-它或多或少会变得稳定，或者至少会这样宣布。 然后快照和调整大小的可能性已经完全解决了您的问题。 因为你有基地。 是的，它可能不会很快，但是速度取决于“幕后”，因为某些实现可以在磁盘子系统级别进行复制和写时复制。
NS ：所有引擎（亚马逊，谷歌...）也必须开始支持该版本-这还需要一些时间。DS ：虽然我们不使用它们。 我们用我们的。
Kubernetes下的本地开发
NS ：当您需要在一台机器上举起所有吊舱并进行少量测试时，是否遇到了这样的愿望清单？ 为了快速获得概念证明，请参见该应用程序可以在Kubernetes中运行，而无需为其分配一堆机器。 有迷你吧，对吗？DS ：在我看来，这种情况-部署在一个节点上-完全是关于本地开发的。 或这种模式的一些表现。 有
Minikube ，有
k3 ，
KIND 。 我们将在Docker中使用Kubernetes。 现在他们开始与他合作进行测试。
NS ：我曾经认为这是将所有Pod包装在一个Docker映像中的尝试。 但事实证明，这与其他事情有关。 无论如何，仅在Docker中就有单独的容器，单独的Pod。DS ：是的。 并完成了一个相当有趣的模仿，但是重点是……我们有一个部署工具
-werf 。 我们想在其中
werf up一个模式-有条件
werf up ：“给我一个本地的Kubernetes。” 然后在此运行有条件的
werf follow 。 然后，开发人员将能够在IDE中进行编辑，然后在系统中启动一个进程，以查看更改并重新组合图像，然后将其重新建模为本地K8。 因此，我们想尝试解决当地发展的问题。
K8现实中的快照和数据库克隆
NS ：如果您返回写时复制。 我注意到云也有快照。 他们的工作方式不同。 例如，在GCP中：您在美国东海岸拥有一个数TB的实例。 您会定期进行快照。 您可以从快照中获取西海岸磁盘的副本-几分钟后一切就绪，它可以非常快速地工作，只需要在内存中填充缓存。 但是这些克隆（快照）-为了“提供”新卷。 当您需要创建许多实例时，这非常有用。但是对于我来说，对于测试而言，似乎是您在Docker中讨论的快照，或者在ZFS，btrfs甚至是LVM中讨论的快照...-它们使您无法在同一台计算机上制作真正的新数据。 在云中，您仍然必须每次都为它们付费，而不必等待几分钟，而要等待几分钟（如果是延迟负载 ，则可能要花几个小时）。相反，您可以在一两秒钟之内获得此数据，进行测试并将其丢弃。 这些快照解决了不同的问题。 在第一种情况下-扩展并获取新副本，在第二种情况下-进行测试。DS ：我不同意。 克隆卷通常是云的任务。 我没有看过它们的实现，但是我知道我们如何在硬件上实现它。 我们有Ceph，在其中您可以告诉任何物理卷（
RBD ）进行
克隆，并在几十毫秒内获得具有相同特性，
IOPS等的第二个卷。 您必须了解内部存在棘手的写时复制。 云为何不这样做？ 我确信他们正在某种程度上尝试这样做。
NS ：但是它们仍然需要几秒钟，数十秒钟来提升实例，将Docker带到那里等等。DS ：为什么必须提出整个实例？ 但是我们有一个32核的实例，一个16……的实例，以某种方式适合它-例如，四个。 当我们订购第五个实例时，该实例将上升，然后将其删除。
NS ：是的，有趣的是，Kubernetes有一个不同的故事。 我们的数据库不在K8s和一个实例中。 但是，克隆一个数TB的数据库只需不到两秒钟。DS ：太酷了。 但是我最初的信息是这不是通用解决方案。 是的，这很酷，但是只有Postgres才适合，并且只能在一个节点上使用。
NS ：它不仅适用于Postgres：正如我所描述的，这些计划仅以这种方式起作用。 但是，如果您不理会这些计划，而我们只需要所有数据进行功能测试，那么它适用于任何DBMS。DS ：很多年前，我们在LVM快照上做到了这一点。 这是经典。 这种方法已经被非常积极地使用。 仅仅有状态节点是一种痛苦。 因为不需要丢弃它们，所以请始终记住它们...
NS ：您在这里看到任何混合的可能性吗？ 假设有状态是某种豆荚，它可用于多个人（许多测试人员）。 我们只有一卷，但是由于有了文件系统，所以克隆是本地的。 如果Pod跌落，磁盘将保留-Pod上升，它将考虑所有克隆的信息，收回所有内容并说：“这是您在这些端口上的克隆，请进一步使用它们。”DS ：从技术上讲，这意味着在Kubernetes中，这是一个pod，我们在其中运行许多Postgres。
NS ：是的。 他有一个限制：假设与此同时，最多有10个人与他一起工作。 如果需要20，请运行第二个类似的容器。 完全现实地克隆它，在收到第二个完整卷之后，它将具有相同的10个“瘦”克隆。 没有看到这样的机会？DS ：我们必须在这里添加安全性问题。 这种组织选项意味着该Pod具有很高的功能，因为它可以在文件系统上执行非标准操作...但是我重复一遍：我相信从中期来看，存储将固定在Kubernetes中，整个卷的故事将固定在云中-一切都会“正常进行”。 它会调整大小，克隆...有一个卷-我们说：“在此基础上创建一个新卷”-经过一分半钟，我们得到了所需的卷。
NS ：我不相信在一秒钟半的时间内可以达到数TB。 在Ceph，您自己做，然后谈论云。 在EC2上转到云，复制许多TB的EBS卷，看看性能如何。 不需要几秒钟。 当他们达到这样的指标时，我非常感兴趣。 我了解您在说什么，但让我不同意。DS ：好的，但是我说的是中期的，不是短期的。 好几年了
Zalando的PostgreSQL专业版运算符
在这次会议的中间，来自Zalando的前开发人员Alexey Klyukin谈到了PostgreSQL运算符的历史，他也加入了她的行列：
总的来说，这个话题也涉及到了：Postgres和Kubernetes。 当我们于2017年在Zalando开始进行这项工作时，每个人都想做这个话题，但没人做。 每个人都已经有了Kubernetes，但是当被问到如何处理数据库时，甚至像Kelsey Hightower这样宣讲K8的人也说过这样的话：
“转到托管服务并使用它们；不要在Kubernetes中启动数据库。 否则，您的K8将决定例如升级，部署所有节点，并且您的数据将飞得很远很远。”
我们决定让运营商与该建议相反，将在Kubernetes中启动Postgres数据库。 而且我们有一个良好的基础-Patroni 。 这是PostgreSQL的自动故障转移，已正确完成，即 使用etcd，consul或ZooKeeper作为集群信息的存储库。 这样的存储库将提供给每个询问例如现在是什么领导者的人的相同信息，尽管事实上我们已经分发了所有信息，所以没有头脑分裂。 另外，我们为他准备了一个Docker映像 。
通常，在从内部铁数据中心迁移到云之后，公司中出现了自动故障转移的需求。 云基于PaaS（平台即服务）专有解决方案。 它是开源的，但是要提高它，您必须努力工作。 它被称为STUPS 。
最初，没有Kubernetes。 更准确地说，当部署自己的解决方案时，K8已经存在，但过于粗糙以至于不适合生产。 我认为是2015年或2016年。 到2017年，Kubernetes变得越来越成熟-需要迁移到那里。
而且我们已经有了一个docker容器。 有使用Docker的PaaS。 为什么不尝试K8s？ 为什么不写自己的声明？ 来自Avito的穆拉特·卡比洛夫（Murat Kabilov）最初是根据自己的倡议发起这个项目-“玩”，然后发起项目“开始”。
但总的来说，我想谈谈AWS。 历史上为什么会有AWS相关代码...
在Kubernetes中运行某些程序时，您需要了解K8s正在进行中。 它在不断发展，改进，并定期甚至中断。 您需要仔细监控Kubernetes的所有变化，需要准备好沉浸其中，并了解其详细工作原理-也许比您想要的更多。 原则上，这是运行数据库的任何平台...
因此，当我们执行该语句时，便有了Postgres，它可以与外部卷配合使用（在本例中为EBS，因为我们在AWS中工作）。 数据库正在增长，有时需要调整大小：例如，EBS的原始大小为100 TB，数据库已经增长到现在的大小，现在我们要使EBS达到200 TB。 怎么了 假设您可以转储/还原到新实例，但这很长，而且会停机。
因此，我想要调整大小以扩展EBS分区，然后告诉文件系统使用新空间。 我们做到了，但是那时Kubernetes没有用于调整大小操作的API。 自从我们致力于AWS以来，我们就为其API编写了代码。
没有人会为其他平台做同样的事情。 声明只能在AWS上运行，而在其他所有功能上都无法运行，这没有什么复杂之处。 总的来说，这是一个开源项目：如果有人想加快使用新API的速度，欢迎我们。 有GitHub ，pull-requests-Zalando团队正在尝试快速响应它们并提升操作员。 据我所知，该项目参与了Google Summer of Code和其他一些类似的计划。 Zalando对此非常活跃。
PS奖金！
如果您对PostgreSQL和Kubernetes主题感兴趣，那么我们还提请您注意上个星期发生的下一个Postgres，
来自Zalando的Alexander Kukushkin与Nikolai进行了交谈。 可从
此处获得视频。
PPS
另请参阅我们的博客：