嘿哈布尔！
我们代表 Exness 平台团队。 之前我们的同事已经写过一篇文章 。 今天我们想分享一下我们将服务迁移到 Kubernetes 的经验。
首先，我们为您提供一些数字，以便您更好地了解将讨论的内容：
- 我们的开发部门由 100 多人组成，其中包括 10 多个不同的团队，拥有独立的 QA、DevOps 和 Scrum 流程。 开发堆栈 - Python、PHP、C++、Java 和 Golang。
- 测试和生产环境的规模各约为 2000 个容器。 他们在自己的虚拟化和 VMware 下运行 Rancher v1.6。
动机
正如人们所说，没有什么是永恒的，Rancher 很久以前就宣布结束对 1.6 版本的支持。 是的，在三年多的时间里我们已经学会了如何准备并解决出现的问题，但我们越来越多地面临着永远无法纠正的问题。 Rancher 1.6 还有一个僵化的权利发行系统，你要么几乎可以做任何事情，也可以什么都不做。
尽管专有虚拟化提供了对数据存储及其安全性的更大控制，但鉴于公司的不断增长、项目数量及其要求，它带来了难以接受的运营成本。
我们希望遵循 IaC 标准，并在必要时在任何地理位置快速获得容量且不受供应商锁定，也能够快速放弃它。
第一步骤
首先，我们希望依靠现代技术和解决方案，使团队能够拥有更快的开发周期，并最大限度地降低与提供动力的平台交互的运营成本。
当然，我们首先想到的是 Kubernetes，但我们并没有兴奋，而是做了一些研究，看看它是否是正确的选择。 我们只评估开源解决方案，在一场不公平的战斗中，Kubernetes 无条件获胜。
接下来是选择创建集群的工具的问题。 我们比较了最流行的解决方案：kops、kubespray、kubeadm。
首先，kubeadm 在我们看来是一条过于复杂的道路，更像是“自行车”的发明者，而 kops 没有足够的灵活性。
获胜者是：
我们开始尝试自己的虚拟化和 AWS，尝试重新创建与我们之前的资源管理模式大致相似的东西，其中每个人共享相同的“集群”。 现在，我们拥有了第一个由 10 个小型虚拟机组成的集群，其中几个位于 AWS 中。 我们开始尝试将团队迁移到那里，一切似乎都“很好”，故事可以结束了，但是……
第一个问题
Ansible 是 kubespray 的基础，它不是一个允许您遵循 IaC 的工具：在调试/停用节点时，不断出现问题并需要某种干预，并且当使用不同的操作系统时，剧本的行为不同。 。 随着集群中团队和节点数量的增加，我们开始注意到 playbook 的完成时间越来越长，结果我们的记录是 3,5 小时，你们的呢？ 🙂
看起来 kubespray 就是 Ansible，乍一看一切都很清楚，但是：
在旅程开始时，任务是仅在 AWS 和虚拟化中启动功能，但随后，正如经常发生的那样，需求发生了变化。
有鉴于此，很明显，我们将资源组合到一个编排系统中的旧模式并不适合 - 在集群非常遥远且由不同提供商管理的情况下。
此外。 当所有团队在同一个集群中工作时，节点选择器安装不正确的各种服务可能会飞到另一个团队的“外部”主机并利用那里的资源，并且如果设置了污点，则会不断出现一个或另一个服务无法工作的请求，由于人为因素导致分配不正确。 另一个问题是计算成本，特别是考虑到跨节点分发服务的问题。
另一个故事是向员工发放权利：每个团队都希望成为集群的“领导者”并完全管理它，这可能会导致彻底崩溃，因为团队基本上是相互独立的。
怎么办呢？
考虑到上述情况以及团队更加独立的愿望，我们做出了一个简单的结论：一队一集群。
所以我们得到了第二个：
然后是第三个簇：
然后我们开始思考：假设一年后我们的团队将拥有多个集群？ 例如，在不同的地理区域，或者在不同的提供商的控制下？ 其中一些人会希望能够快速部署临时集群来进行一些测试。
完整的 Kubernetes 即将到来！ 事实证明，这是某种 MultiKubernetes。
与此同时，我们都需要以某种方式维护所有这些集群，能够轻松管理对它们的访问，以及创建新集群和退役旧集群，而无需手动干预。
自从我们开始进入 Kubernetes 世界以来已经过去了一段时间，我们决定重新检查可用的解决方案。 事实证明，市场上已经存在——Rancher 2.2。
在我们研究的第一阶段，Rancher Labs 已经发布了第 2 版，虽然可以通过启动一个没有外部依赖且带有几个参数的容器或使用官方 HELM Chart 来非常快速地提升版本 XNUMX，但它看起来很粗糙对我们来说，我们不知道我们是否可以依赖这个决定，无论它会被开发还是很快被放弃。 UI 本身中的 cluster = clicks 范例也不适合我们，而且我们不想与 RKE 联系在一起，因为它是一个关注范围相当狭窄的工具。
Rancher 2.2 版本已经具有更实用的外观，并且与之前的版本一起，具有许多开箱即用的有趣功能，例如与许多外部提供商集成、权限和 kubeconfig 文件的单点分发、启动 kubectl具有您在 UI 中的权限的图像，嵌套命名空间又称为项目。
还有一个围绕 Rancher 2 形成的社区，并创建了一个名为 HashiCorp Terraform 的提供商来管理它，这帮助我们将所有内容整合在一起。
发生了什么
结果，我们最终得到了一个运行 Rancher 的小型集群，所有其他集群以及连接到它的许多集群都可以访问，对其中任何集群的访问都可以像将用户添加到 ldap 目录一样简单地授予，无论它位于哪里以及它使用哪个提供商的资源。
使用 gitlab-ci 和 Terraform 创建了一个系统，允许您在云提供商或我们自己的基础设施中创建任何配置的集群，并将它们连接到 Rancher。 所有这些都是以 IaC 风格完成的，其中每个集群都由存储库描述，并且其状态是版本化的。 同时，大多数模块都是从外部存储库连接的，因此剩下的就是传递变量或描述实例的自定义配置，这有助于减少代码重复的百分比。
当然，我们的旅程还远没有结束，前面仍然有许多有趣的任务，例如使用任何集群的日志和指标的单点工作、服务网格、用于管理多集群中负载的 gitop 等等。 我们希望您觉得我们的经历很有趣！
本文由平台工程师 A. Antipov 和 A. Ganush 撰写。
来源： habr.com