我叫Sergey，来自ITSumma，我想告诉您我们如何处理Kubernetes中的预订。 最近，我在为各个团队实施各种devops解决方案方面进行了大量的咨询工作，尤其是我在使用K8的项目上紧密合作。 在专门讨论复杂体系结构冗余的Uptime第4天会议上，我做了一个关于冗余立方体的演示，这是他的免费重述。 我只会事先警告他，他不是行动的直接指南，而是对该主题思想的概括。
原则上，监视和冗余是增加任何项目的弹性的两个主要工具。 但是在多维数据集中，一切都由自身平衡，您说，一切都由自身缩放，如果发生某些事情，它会自己增长……也就是说，在对该主题进行的第一次表面研究中，互联网回答了我一个问题：“ K8的备份如何工作？” ？ 许多人认为多维数据集是一件神奇的事情，它消除了所有基础架构问题，并使该项目永无失败。 但是...世界不是看起来的那样。
我们以前是如何进行备份过程的？ 我们有相同的放置平台-它们是虚拟机或铁服务器，我们在其中应用了三个基本实践：
- 代码同步和静态
- 配置同步
- 数据库复制
瞧，在任何时候我们转到储备地点，每个人都很高兴，我们起床，我们不同意。
他们为我们提供了什么以增加kubernetes应用程序的持续可用性？ 非正式文档所说的第一件事是放置很多机器，制造很多主机-它们的数量必须满足在集群中实现仲裁的条件，因此在每个主机上都增加了etcd，api，MC，调度程序...而且，看起来一切都很好：当几个工作节点或主节点发生故障时，我们的集群将重新平衡，应用程序将继续工作。 再次看起来像魔术！ 但是通常我们的集群位于同一数据中心内，这可能会引起某些问题。 如果挖掘机到达并挖出电缆，闪电击中，发生了普遍洪水该怎么办？ 一切都覆盖了，我们的集群就没有了。 考虑到问题的这一方面如何处理保留？
首先，您应该在热备份中有另一个群集，即可以随时切换到的群集。 同时，从多维数据集的角度来看，基础结构必须完全相同。 也就是说，如果有任何用于文件系统的非标准插件，用于入口的自定义解决方案，则它们在您的两个（或三个或十个，有足够的资金和管理员的实力）集群上应该完全相同。 有必要明确定义两套应用程序（deployment'ov，statefulset'ov，daemonset'ov，cronjob'ov等）：它们中的哪些可以持续工作在备用上，而最好不要在直接切换之前启动。
那么，我们的备份集群应该与战斗集群完全相同吗？ 不行 以前，作为整体项目和铁基础设施工作的一部分，我们维护了几乎完全相同的环境，但是作为立方体的一部分，我认为不应该这样。 让我们看看为什么。
例如，让我们从kubernetes的基本实体开始-部署-它们必须相同。 应该启动可以随时拦截流量处理并允许我们的项目继续运行的应用程序。 如果我们在谈论配置文件，那么我们需要在这里查看它们是否应该相同。 也就是说，如果我们这些聪明的人不使用任何禁止使用的物质并且不将基地保留在K8中，那么我们必须在战斗基地的configmap中具有访问设置（其备份过程是单独构建的）。 因此，为了确保访问备份数据库实例，我们必须有一个单独的配置文件（configmap）。 我们使用机密的方式完全相同：用于访问数据库的密码，api密钥； 在任何给定时间，战斗秘密或后备力量都可以与我们合作。 总的来说，我们已经有两个kubernetes实体，它们的备份版本应该与战斗版本不同。 下一个值得关注的实体是cronjob。 保留的cronjobs绝对不应与cronjob生产集群的集合相同！ 例如，如果我们在启用所有cronjob的情况下提升备份集群并完全提升它，那么例如，人们会同时收到您的两个字母，而不是一封。 否则，数据与外部源的某种同步将分别发生两次，我们开始受伤，哭泣，尖叫和宣誓。
但是，来自Internet的人们如何为我们提供组织备份集群的机会？ “为什么？”之后的第二个最受欢迎的答案 -使用Kubernetes Federation。
这是什么 假设这是一个大型的元集群。 如果我们想象多维数据集的体系结构-我们有一个主节点，几个节点-那么从联合的角度来看，我们也有一个主节点和几个节点，只有每个节点都是一个单独的群集。 也就是说，我们使用与使用单个多维数据集相同的图元和相同的图元，但是我们不是扭转物理机器，而是扭转整个集群。 在联邦的框架中，我们正在完全同步父母与后代之间的联邦资源。 例如，如果我们通过联盟启动了一些部署，则它将部署在我们的每个子集群中。 如果我们使用一些configmap，秘诀就是将其滚动到联盟中-它会传播到我们的所有子集群中。 同时，联合会允许我们自定义儿童资源。 也就是说，我们采用了一些configmap，通过联邦对其进行了部署，然后，如果我们需要在特定集群上修复某些问题，我们将在单独的集群上进行编辑，并且此更改将不会在任何地方同步。
Kubernetes Federation不久前还不是一个现成的工具，它不支持K8s本身提供的全部资源：在发布该文档的第一个版本时，它只是在谈论仅支持配置映射，副本集的部署，入口。 不支持机密，也不支持批量使用。 设置太有限。 尤其是如果我们希望获得乐趣，例如，通过自定义资源定义将我们自己的资源转移到kubernetes，我们将不会将它们推入联盟。 也就是说，虽然它是……一个与事实非常相似的决定，但它使我们定期地朝自己的脚射击。 另一方面，联合身份验证使您可以灵活地管理我们的副本集。 例如，我们希望启动应用程序的10个副本，默认情况下，联盟将在群集数量之间按比例分配此数量。 所有这些都可以配置！ 也就是说，您可以指定您需要在战斗集群上保留6个应用程序副本，而在备份集群上仅保留4个应用程序副本，以节省资源或用于自己的娱乐。 这也很方便。 但是，有了联合会，我们必须使用一些新的解决方案，随时随地完成一些工作，并迫使自己多考虑一些事情...
是否有可能以某种简单的方式处理预订多维数据集的过程？ 我们有什么工具？
首先，我们总是有某种ci / cd系统，也就是说，我们不手动操作，也不在服务器上编写create / apply。 系统会为我们的容器生成Yaml'ics。
其次，有几个集群，我们有一个或几个（如果我们很聪明的话）注册表，我们也将其保留。 还有一个很棒的kubectl实用程序，可以同时处理多个集群。
因此：我认为，构建备份集群最简单，最正确的解决方案是原始的并行部署。 ci / cd系统中有某种流水线。 首先，我们构建容器，通过kubectl测试应用程序并将其部署到几个独立的集群中。 我们可以在几个群集上建立同时计算。 因此，我们还决定在此阶段交付配置。 您可以预定义战斗集群的配置集，备份集群的配置集，并在系统的ci / cd级别上将pro-environment迁移到pro-cluster，将备份环境迁移到备份集群。 与联盟相比，您无需为每个子群集定义联邦资源并重新定义内容。 我们事先做到了。 我们是个好家伙。
但是……有……我写道，有“万恶之源”，但实际上有两个。 首先是文件系统。 有某种PV，或者我们使用外部存储。 如果我们将文件存储在集群中，则需要遵循铁基础设施时代遗留下来的旧做法：例如，与lsync同步。 好吧，或者您个人更喜欢其他拐杖。 我们将所有东西都投放到其他汽车上并继续生活。
其次，实际上，一个更重要的绊脚石是数据库。 如果我们是聪明人，并且不将数据库保留在多维数据集中，那么根据相同的旧方案备份数据的过程就是主从复制，然后进行切换，我们将追上副本并且生活得很好。 但是，如果我们将数据库保留在群集中，那么原则上会有许多现成的解决方案来组织相同的主从副本，还有许多解决方案可以在多维数据集中提升数据库。
已经阅读了关于数据库备份的十亿份报告，撰写了十亿篇文章，实际上这里不需要任何新内容。 通常，遵循您的梦想，按照自己的意愿生活，发明一些复杂的拐杖，但是一定要考虑一下如何保留所有这些。
现在，从原则上讲，一旦发生火灾，我们将具有切换到备用站点的过程。 首先，我们并行部署无状态应用程序。 它们不影响我们的应用程序，我们的项目的业务逻辑，我们可以不断保留两组正在运行的应用程序，并且它们可以开始接收流量。 在切换到备份站点的过程中，确定是否需要重新定义配置非常重要。 例如，我们有一个kubernetes销售集群，有一个备份kubernetes集群，有一个外部master数据库，还有一个备份master数据库。 对于产品中的这些应用程序如何开始相互交互，我们有四个选择。 我们的基地可以切换，事实证明，我们需要将流量切换到产品集群中的新基地，或者我们可以将集群切换到储备库，但是当我们得到它时，我们将继续使用专业基地，第三个选择，然后搞砸了，我们切换了两个应用程序，重新定义了配置，以便新的应用程序已经可以与新的数据库一起使用。
那么，实际上，从这一切可以得出什么结论？
第一个结论：与储备金一起生活。 但是很贵。 但理想情况下，有多个后备人。 理想情况下，您通常需要生活在几个保护区中。 首先，储备金应至少不位于一个DC中，其次，至少应位于另一个托管人中。 它经常发生-在我的实践中是这样。 不幸的是，当数据中心发生火灾时，我无法命名项目...我是这样的：我们正在转向储备金！ 而位于同一机架中的备份服务器则...
或者想象一下，亚马逊在俄罗斯被禁止了（那是过去）。 所有人：我们的后备在另一个亚马逊地区这一事实的意义？ 它也不可用。 因此，我重复一遍：我们至少将储备保留在另一个DC中，最好与另一个主机保留在一起。
第二个结论：如果您的应用程序与某些外部源（可以是数据库或某些外部api）进行通信，请确保将其定义为具有外部端点的服务，这样您在切换时不必重新修复您的15个应用程序在同一基础上。 将数据库定义为一个单独的服务，将其视为群集中的一个服务：如果您有数据库，则可以在一处更改ip并继续快乐地生活。
最后：我喜欢“多维数据集”以及它的实验。 我也想分享这些实验的结果，以及我的个人经验。 因此，我在
我们的YouTube频道上录制了一系列有关K8的网络研讨会，以了解详细信息。