Get best of the week

K8S多集群之旅

哈Ha！

我们代表Exness平台团队。早些时候，我们的同事已经写了一篇有关k8的生产就绪图像的文章。今天，我们想分享Kubernetes中服务迁移的经验。



首先，我们为您提供一些数字以更好地理解所讨论的内容：

  • 100+ , 10 QA, DevOps Scrum. — Python, PHP, C++, Java Golang. 
  • — 2000 . Rancher v1.6 VMware. 


正如他们所说，一切都不会永远持续下去，Rancher已经足够长的时间宣布终止对1.6版的支持。是的，三年多来，我们已经学会了如何烹饪和解决出现的问题，但是越来越多的我们面临着永远无法解决的问题。Rancher 1.6还拥有一个僵化的发行权系统，您几乎可以做任何事或什么都不做。

自己的虚拟化虽然可以更好地控制数据存储和安全性，但是却带来了运营成本，这对于公司的持续增长，项目数量和需求难以承受。

我们希望遵循IaC标准，并在必要时在任何地理位置且无供应商锁定的情况下迅速获得电源，并能够迅速放弃它们。

第一步


首先，我们希望依靠现代技术和解决方案，使团队能够拥有更快的开发周期并最小化与提供电源的平台进行交互的运营成本。 
 
当然，我们首先想到的是Kubernetes，但我们并没有感到兴奋，而是对正确选择的主题进行了一些研究。我们只评估了开源解决方案，而Kubernetes在不公平的战斗中无条件被击败。  

接下来是选择用于创建集群的工具的问题。我们比较了最受欢迎的解决方案：kops，kubespray和kubeadm。

首先，kubeadm在我们看来似乎太复杂了，相反，他是“自行车”的发明者，而kops缺乏灵活性。

赢家出来了：



我们开始在自己的虚拟化和AWS上进行试验，试图重新创建与我们以前的资源管理模式的相似之处，其中每个人都使用相同的“集群”。现在，我们有了第一个包含10个小型虚拟机的集群，其中有两个在AWS中。我们开始尝试将团队迁移到那里，一切似乎都“不错”，故事可以结束，但是...

第一个问题


Ansible是建立在kubespray之上的工具，并不是遵循IaC的工具：当我进入/停用节点时，经常出错，需要任何干预，而当使用不同的操作系统时，剧本的表现以不同的方式。随着集群中命令和节点数量的增加，我们开始注意到剧本花费的时间越来越长，最后，我们的记录是3.5个小时，您的记录呢？ :)

似乎kubespray只是Ansible，乍看之下一切都清楚，但是：



在旅程的开始，就有一项任务是仅在AWS和虚拟化中运行容量，但是随后，需求经常发生变化。
 


鉴于此，很明显，我们原来的将资源组合到一个业务流程系统中的模式是不合适的-在集群距离很远且由不同提供商管理的情况下。 

更进一步。当所有团队都在同一个集群中工作时，错误地安装了NodeSelector的各种服务可能会飞到另一个团队的“外来”主机并在那里使用资源，并且在设置污点的情况下，经常有人说该服务或该服务不起作用，由于人为因素导致分布正确。另一个问题是成本的计算，特别是考虑到节点分发服务方面的问题。

一个单独的故事是员工的权利问题：每个团队都想成为集群的“负责人”并对其进行全面管理，这可能导致彻底崩溃，因为团队之间基本上是彼此独立的。

怎样成为


鉴于以上所述以及团队希望拥有更多独立性的愿望，我们得出了一个简单的结论：一个团队-一个集群。 

因此，我们得到了第二



个集群：



然后是第三个集群：  然后我们开始思考：假设，我们的团队一年内将拥有多个集群？例如，在不同的地理区域，还是在不同的提供者的控制之下？他们中的一些人希望能够为任何测试快速部署临时集群。 



将会有完整的Kubernetes！事实证明，这是一种MultiKubernetes。 

同时，我们所有人都需要以某种方式支持所有这些集群，能够轻松地控制对它们的访问，以及无需手动干预即可创建新集群并停用旧集群。

自从我们进入Kubernetes世界以来，已经过去了一段时间，我们决定重新检查可用的解决方案。事实证明，它已经存在于市场上-Rancher 2.2。



在我们研究的第一阶段，Rancher Labs已经发布了版本2的第一个版本，但是尽管可以通过运行不带两个参数的外部依赖项的容器或使用官方的HELM Chart来快速提高版本，但对我们来说似乎很粗糙，我们不知道是否依靠这个决定，无论是将其发展还是迅速放弃。 UI中的cluster = clicks范式本身也不适合我们，我们也不想加入RKE，因为这是一个狭narrow的工具。 

Rancher 2.2版本已经具有更高效的外观，并且与以前的版本一起具有许多有趣的功能，例如与许多外部提供程序集成，权限和kubeconfig文件的单点分发，在UI中启动具有您的权限的kubectl映像，嵌套命名空间（也称为项目）。 

已经在Rancher 2周围形成了一个社区，并创建了HashiCorp Terraform提供程序来对其进行管理，这有助于我们将所有内容组合在一起。

发生了什么


结果，我们得到了一个启动Rancher的小型集群，所有其他集群都可以访问Rancher，以及与之相关联的许多集群，可以像向ldap目录中添加用户一样简单地发出对任意一个集群的访问权限位置以及提供者使用的资源。

使用gitlab-ci和Terraform，创建了一个系统，该系统使您可以在云提供商或我们自己的基础架构中创建任何配置的集群，并将它们连接到Rancher。所有这些都是以IaC样式完成的，其中每个集群都由存储库描述，并且其状态是版本化的。在这种情况下，大多数模块都是从外部存储库连接的，因此它仅用于传输变量或为实例描述其自定义配置，这有助于减少代码可重复性的百分比。



当然，我们的旅程还远远没有结束，还有许多有趣的任务在前，例如任何集群的日志和指标的单点工作，服务网格，用于管理多集群负载的gitop等。希望您对我们的经验感兴趣！ 

该文章由平台工程师A.Antipov，A.Ganush撰写。 

More articles:


All Articles