Kubernetes 无法像数据库那样以本机方式管理有状态应用程序，尤其是在第 2 天操作时。它需要特定的网络配置、持久性存储和专用计算容量。所有这些都是由库伯内特斯运营商完成的。
在本次演讲中，佩尔科纳产品经理谢尔盖·普罗宁（Sergey Pronin）解释了为什么需要操作员在 Kubernetes上运行MongoDB，以及如何使用Percona的MongoDB运营商进行演示，将MongoDB迁移到库贝内特。
巴特·法瑞尔：谢尔盖，欢迎你，很高兴有你。今天，您将告诉我们如何将MongoDB迁移到Kubernetes。
谢尔盖·普罗宁：我做得很好，谢谢你今天邀请我。
我的名字是谢尔盖。我在佩尔科纳担任产品经理。我主要关注的是 Kubernetes，我们的运营商在云技术以及与之相关的一切方面。今天，我将简要介绍一下将MongoDB迁移到Kubernetes的旅程。而且，首先，这是谈话计划。我们将讨论为什么有人想在库伯内特上运行MongoDB。我将谈谈我们在Percona拥有的操作员和其他一些选项。我们将回顾迁移选项，我将向您展示如何通过复制完成迁移，这将是一个概述。我将快速地向你们展示一些演示，以展示我所谈论的是真实的。右？所以这不是我想象的东西。所以Mongo和Kubernetes就是那个东西，简短的答案是肯定的。在拐角处，我们有很多客户和很多社区用户使用我们的操作员在Kubernetes上运行MongoDB。他们在生产环境中针对各种用例运行它。Kubernetes上的MongoDB每天都在爆炸，我可以看到增长，这是一个有趣的案例，但是，如果我们谈论为什么，当一些大企业或公司来找我们时，我们通常听到的第一件事是他们希望避免供应商锁定，通常谈论Atlas或Ops Manager，主要驱动因素通常是成本。好吧，不是那么明显，但它确实如此。另一项是没有那么多托管服务。我的意思是，如果你看看MongoDB的空间，你可以看到它被记录在亚马逊上，但它不是真正的Mongo，它是Mongo，就像一个数据库，对吧？有数字海洋和其他一些供应商提供MongoDB。而这一切都是因为MongoDB的非友好SSPL许可证，提供托管服务并不容易。当人们开始思考，好吧，我怎么能经营Mongo呢？如果不是阿特拉斯，如果不是托管服务？有哪些选择？我仍然希望拥有自动化，我仍然希望进行第2天的操作，这是非常重要的扩展，进行备份，升级和其他所有内容。我想避免供应商锁定。我不想被困在一朵云中。我想随时从亚马逊迁移到谷歌和我的私有云。这里的答案是操作员，其中有一些。一个是佩尔科纳。我稍后会谈论它。另一个我真正喜欢的是KubeDB。
如果您正在参加 DoK 日活动，并且您应该了解 KubeDB，那么它是一家瑞士操作员，负责在 Kubernetes 上运行数据库。它可以运行后记，MySQL MongoDB，唯一可能阻止你运行KubeDB的是它遵循一个开放的核心模型。因此，某些功能不是免费提供的，例如您无法进行备份，例如，显然有一个针对生产用例的阻碍者。另一个还有一个MongoDB社区运营商，但它也没有备份。我会说它不太适合生产。关于为什么的另一个项目是MongoDB在Kubernetes 上运行良好，我在运行Postgres，MySQL和Kubernetes 之后说这个。而且运行MongoDB并不难。我相信这主要是因为它的设计和易于扩展的能力，它更符合 Kubernetes 原语和 Kubernetes 的想法，即部署 Kubernetes 带来的容器、部件和这个不稳定的环境。嗯，显然运行Postgres和MySQL也是可能的，但我发现在库伯内特上运行MongoDB要容易得多。因此，如果我们简要地谈论Percona运算符，首先，它显然是100%，开源的，就像Percona的一切一样。你已经关闭了开箱即用的工作，所以你可以部署你的MongoDB集群，并横向扩展，缩减，以任何可能的方式，你可以添加更多的计算资源，更多的存储，以及其他一切，这真是太棒了。我们支持通过时间点恢复进行备份和还原。因此，它将把恢复时间缩短到你喜欢的程度。我们通过将博客上传到远程存储来做到这一点。因此，它更符合Kubernetes 的方式。我们不会在本地存储备份，您可以轻松地从一个 Kubernetes 迁移到另一个 Kubernetes。我们与Percona监控和管理集成，这是我们监控和管理数据库的工具，它开箱即用。我喜欢这样做的原因是，您可以部署数据库，并在需要的地方拥有所有指标和警报。
对于自定义，我们有自定义的边车容器，这意味着您可以使用您选择的任何监控工具扩展MongoDB集群，您可以在边车容器中部署基准测试等等。因此，自定义功能开箱即用。我们有自动升级，最后一个是多区域部署。这是我将在本次演讲中强调的功能之一。这是我们最近刚刚推出的新问题，它主要集中在解决两个问题上。首先是灾难恢复。因此，如果您有两个 Kubernetes 集群，并且您希望一个 MongoDB（集群）位于美国，另一个 MongoDB 集群位于欧洲，例如，您可以设置一个复制，即跨两个集群的单个副本集。多区域部署的另一个用例显然是它还提供的迁移功能，因此您可以轻松迁移到 Kubernetes 和 Kubernetes 之外。我要告诉你如何做到这一点。
因此，我们拥有的迁移选项不仅适用于MongoDB，而且几乎适用于任何数据库。但我们将把重点放在MongoDB上。因此，左侧的第一个迁移选项是通过备份和还原。因此，您备份了一些在本地某个地方运行的副本集，然后将其放入某个 S3 存储桶或其他存储中。并且您还使用副本集在 Kubernetes 上部署了运算符，并还原到此副本集。这种方法的唯一缺点是巨大的恢复时间，因为你拥有的数据库越大，如果你有数TB或PB的数据，恢复它将需要一些时间，你将违反所有可能的SLA，你显然不想要。
但这是将数据库从A点迁移到B点的最简单方法，包括MongoDB。MongoDB的另一种方法是将在其他地方运行的远程节点添加到您的本地副本集中。所以右边的图片是你有一个副本集在Linux盒子的某个地方运行，或者我不知道，在阿特拉斯，在亚马逊上，你想把它移动到Kubernetes。你所做的是部署操作员，部署副本集节点，然后只需将这些节点添加到本地副本集，同步数据，然后就可以将应用程序切换到您在 Kubernetes 中拥有的 MongoDB。这就是我今天要强调的，并更详细地谈论。
好吧，我还有一张幻灯片和演示。所以我会很快。所以这将是我们将要设置的右边，在左边，我们有一个本地MongoDB，它再次在任何地方，它可以是一个数据中心，它可以是裸机，它可以是云，没关系。你渴望把它移到Kubernetes。所以第二，如果你有一个部署了操作员的Kubernetes集群。但这里的关键是，操作员将在托管模式下部署这些节点，这意味着它们不会形成 ReplicaSet 本身。而且您只能将这些节点添加到本地运行的ReaconSet中，为了简单起见，我将在演示中展示它。
但这是这些节点正在运行的关键项，不受管理。因此，在 Kubernetes 上没有形成任何副本集。现在，对吧？这是关键。这里的第三件事是，我们需要将每个副本集容器或每个副本集节点公开给外部世界或某个本地Mongo可以访问它的专用网络。原因是，每个节点和副本集都应该相互访问。所以这就像一个完整的节点的混合部署。原因再次是，如果一个节点发生故障，则需要形成一个仲裁，而不是成为主节点，依此类推，因此公开通知也是一个关键。第四步，我们将把这些节点添加到本地副本集。这将启动同步过程。一旦 Kubernetes 集群上的节点同步，您就可以切换应用程序以使用它们，然后慢慢杀死本地 MongoDB 集群。
重要的是要注意，相同的过程以相反的方式工作。因此，如果您想从Kubernetes移动到本地，出于某种原因，您也可以通过操作员进行操作。这里的美妙之处在于，一旦您完成了从本地到 Kubernetes 的迁移，您就会在 Kubernetes 上拥有一个完全托管的集群，操作员将负责全天的操作，因此备份、扩展和一切。所以你终于可以忘记预产程疼痛了。当我说痛苦时，当我为这个演讲做准备时，我只是在数字海洋上旋转一个MongoDB集群，我想，或者在一些Linux盒子里。这花了我很多时间，因为我忘记了在没有操作员和操作员的情况下手动旋转东西是多么困难，事情要容易得多。你只是忘记了用自己的双手或一些脚本配置所有内容是多么困难。
所以演示，让我们开始吧。很好。快速的一个，让我分享我的屏幕。我想是这个。所以在这里，我有一个副本集。它只是一个节点，它是某个运行在某个地方的Linux盒子。所以单节点副本集。在右边，我有一个库伯内特集群。好吧，我将在这里向您展示自定义资源。自定义资源是通过运算符部署数据库的主要清单。因此，该运算符只是一段代码，它将自定义资源作为输入，它证明了 Kubernetes API 并检查特定的自定义资源和 Kubernetes，如果它看到它并在这种情况下执行某些操作，当它看到此自定义资源 YAML 文件应用于 Kubernetes 时。
它说好吧，我需要配置一个非托管的MongoDB集群意味着节点不会形成副本集，没有创建证书，什么都没有，对吧？它说，好吧，我需要预配副本集的三个节点，但它忽略了副本集的名称。它还看到，好吧，我需要通过负载均衡器公开这些节点。我正在做一个负载均衡器，我不建议你做负载均衡器，因为它可能很贵。而且，我通过公共互联网这样做，这显然是不推荐的。还有其他方法可以做到这一点，比如通过一些工具，如潜航者，等等。但为了演示，我将保持简单。我已经运行了这个集群。所以在这里，你可以看到我有一个操作员并部署了三个pod。它们称为副本集 0012。但实际上，它不是副本集，而是现在的独立容器。但是我们稍后会将它们转换为副本集。在这里，我已经有了一项服务。你可以看到我为每个节点都有一个负载均衡器。而且他们有一个公共IP，我还创建了一些域名，只是为了简化部署和配置，这样我就不知道我不需要在任何地方指定IP地址。
因此，现在让我们部署，将这些节点添加到本地副本集中。所以这是本地的，这是我的单节点副本集，我想把它迁移到库伯内特斯。现在，我将把这些节点添加到我在库伯内特斯上拥有的这个副本集中。所以一，二和三。一旦我这样做了，应该发生的事情是应该开始复制到这个节点。正如你所看到的，它们已经被添加到副本集中，并且它们被标记为次要的。所以在这里，我有ID一是我的本地副本集节点，ID是2，然后在Kubernetes上的新节点上进一步ID 2，3，依此类推，它们已经被标记为辅助节点。我没有太多关于我的主数据。因此，迁移将非常快。我认为这一切都已经完全敲定了，但让我们看看。是的，我认为它已经完成了。我会等一会儿。好吧，是的。我看看。好的，是的，迁移已经完成。现在，我将重新配置副本集。我将在库伯内特斯上创建一个节点。侧，作为主。显然，在执行此操作之前，您需要确保应用程序知道这些节点。我不打算在这里关注应用程序部分，我将关注数据库。但要小心，并确保应用程序知道新的主数据库在哪里，依此类推。
是的，我正在设置高优先级，并且我允许这个节点对Kubernetes进行投票。然后重新配置副本集，现在应该发生的是此副本集中的节点，它们将成为主节点。所以现在它仍然是一个本地的IP地址，它仍然是主要的，但是在我执行命令之后，我可以看到我在Kubernetes上的节点现在是主要的，这意味着我准备在那里切换我的应用程序。但在这样做之前，我要做的是促进我的 Kubernetes 集群得到管理。这真的超级容易。我只是要把这个不受管理的东西从真改成假。就是这样。现在，我将把这个 YAML 文件应用到我的 Kubernetes 集群中。操作员现在完全管理此副本集。因此，每当我想进行备份时，每当我想扩展此副本集时，我现在都可以为 Kubernetes 执行此操作。我现在可以忘记这个本地节点，只需将其从副本集中删除，仅此而已。我的数据现在在 Kubernetes 中，我的数据现在在我的集群中，MongoDB 集群现在由操作员管理，这有点棒。这是一个简短的演讲和一个快速演示。我还有一篇博客文章，其中我详细描述了您应该采取哪些措施来使这种迁移变形，以及它的主要好处是什么。
但相信我，在Kubernetes上运行MongoDB比手动运行它要容易得多。这就是我今天的工作。我真的很感谢你的时间。非常感谢您的光临和聆听。如果您有任何疑问，请在DoK Slack上或通过推特通过电子邮件与我联系。谢谢大家。
原文标题：How to Migrate MongoDB to Kubernetes
原文作者：Sylvain Kalache
原文地址：https://dzone.com/articles/how-to-migrate-mongodb-to-kubernetes
