大约一年以来，我们的基础架构部门一直在将GitLab.com上运行的所有服务迁移到Kubernetes。在这段时间内，我们不仅遇到了将服务迁移到Kubernetes的问题，而且还遇到了过渡期间管理混合部署的问题。我们将在本文中讨论我们所学到的宝贵经验。
从GitLab.com的一开始，其服务器就在虚拟机上的云中运行。这些虚拟机由Chef管理，并使用我们的官方Linux软件包安装。在需要更新应用程序的情况下，部署策略是使用CI管道以协调的顺序方式简单地更新服务器机群。这种方法虽然缓慢但有点无聊，但可以确保GitLab.com使用与使用我们的Linux软件包进行自我管理的GitLab安装的用户相同的安装和配置方法。
我们使用这种方法，是因为在安装和配置其GitLab副本时，体验社区普通成员所经历的所有悲伤和欢乐非常重要。这种方法在一段时间内效果很好，但是随着GitLab上的项目数量超过1000万，我们意识到它不再能够满足我们的扩展和部署需求。
迈向Kubernetes和云原生GitLab的第一步
2017年，创建了GitLab Charts项目，以准备将GitLab部署在云中，并使用户能够在Kubernetes集群上安装GitLab。然后我们知道将GitLab迁移到Kubernetes将增加SaaS平台的可伸缩性，简化部署并提高计算效率。同时，我们应用程序的许多功能都取决于已安装的NFS分区，这会减慢从虚拟机的过渡。
对云原生和Kubernetes的追求使我们的工程师可以计划逐步过渡，在此期间，我们放弃了一些应用程序对NAS的依赖，同时继续沿途开发新功能。自从我们在2019年夏季开始计划迁移以来，许多限制已被取消，现在将GitLab.com迁移到Kubernetes的过程正在紧锣密鼓地进行中！
Kubernetes中GitLab.com工作的功能
对于GitLab.com，我们使用一个区域GKE集群来处理所有应用程序流量。为了最大程度地减少（已经很棘手的）迁移的复杂性，我们专注于不依赖本地存储或NFS的服务。 GitLab.com使用主要的整体式Rails代码库，我们根据工作负载的特性将流量路由到隔离到我们自己的节点池中的各个端点。
在前端的情况下，这些类型分为对Web，API，Git SSH / HTTPS和注册表的请求。在后端的情况下，我们根据预定义的资源边界根据不同的特征将作业排队，这使我们能够为不同的工作负载设置服务级别目标（SLO）。
所有这些GitLab.com服务都是使用未修改的GitLab Helm图表配置的。配置是在子图中完成的，随着我们逐渐将服务迁移到集群，可以有选择地启用该子图。即使已决定在迁移中不包括我们的某些有状态服务（例如Redis，Postgres，GitLab Pages和Gitaly），Kubernetes仍大大减少了Chef当前管理的VM数量。
Kubernetes透明性和配置管理
所有设置均由GitLab本身控制。为此，使用了三个基于Terraform和Helm的配置项目。我们尝试尽可能使用GitLab本身来运行GitLab，但是对于操作任务，我们需要单独安装GitLab。对于GitLab.com的部署和更新，它必须独立于GitLab.com的可用性。
尽管我们用于Kubernetes集群的管道在单独的GitLab安装上运行，但是代码库在以下地址公开提供了镜像：
- k8s-workloads / gitlab-com -GitLab Helm图表的GitLab.com配置绑定；
- k8s-workloads/gitlab-helmfiles — , GitLab . , PlantUML;
- Gitlab-com-infrastructure — Terraform Kubernetes (legacy) VM-. , , , , , IP-.
进行更改后，将显示可公开获得的简短摘要，并带有指向SRE在更改群集之前进行分析的详细差异的链接。
对于SRE，该链接指向用于生产和访问的GitLab安装中的详细差异，这是有限的。这使员工和社区无需访问运营项目（仅对SRE开放）即可查看建议的配置更改。通过将用于代码的GitLab的公共实例与用于CI管道的私有实例相结合，我们可以维护一个工作流程，同时确保与GitLab.com的独立性以进行配置更新。
我们在迁移过程中发现的内容
在迁移过程中，积累了经验，我们将其应用于Kubernetes中的新迁移和部署。
1. -
GitLab.com上Git存储库公园的每日出口统计数据（每天字节数）
Google将其网络划分为多个区域。依次将它们划分为可用区（AZ）。 Git托管与大量数据相关联，因此对我们来说控制网络出口非常重要。对于内部流量，仅当出口保持在同一可用区内时才是免费的。在撰写本文时，我们将在一个典型的工作日内分发大约100 TB的数据（仅用于Git存储库）。在我们旧的基于VM的拓扑中，服务位于同一虚拟机上，现在在不同的Kubernetes Pod中运行。这意味着，以前对于VM而言本地的某些流量可能会超出可用区域。
区域GKE群集使您可以跨越多个可用区以实现冗余。我们正在考虑将区域GKE集群分为单区域集群，以产生大量流量的服务。这将减少出口成本，同时保持群集冗余。
2.限制，资源请求和扩展
在registry.gitlab.com上处理生产流量的副本数。流量在世界标准时间（UTC）〜15:00达到峰值。
我们的迁移故事始于2019年8月，当时我们将第一个服务GitLab Container Registry移植到了Kubernetes。这种高业务量，关键任务服务非常适合首次迁移，因为它是无外部依赖项的无状态应用程序。我们遇到的第一个问题是由于节点上的内存不足而导致大量的抢占式Pod。因此，我们不得不更改请求和限制。
已经发现，在存储器消耗随时间增加的应用情况下，低的request'ov（对于每个冗余存储器pod'a）值加上“大量的”刚性限制'om导致使用饱和（saturation）单元和高排量。为了解决这个问题，决定增加请求并降低限制。这减轻了节点的压力，并确保了不会对节点施加太大压力的Pod生命周期。现在，我们从大量（几乎相同）的请求和限制值开始迁移，并根据需要进行调整。
3.指标和日志
基础架构将重点放在延迟，错误率和饱和度上，并将已建立的服务水平目标（SLO）与系统的整体可用性联系在一起。
在过去的一年中，基础设施部门的主要发展之一是对SLO的监视和使用方面的改进。 SLO允许我们为单个服务设置目标，在迁移过程中我们会对其进行密切监控。但是，即使有了这种改进的可观察性，也不一定总是可以使用指标和警报立即发现问题。例如，通过关注延迟和错误率，我们无法完全涵盖正在迁移的服务的所有用例。
在将某些工作负载迁移到群集后，几乎立即发现了此问题。当需要检查功能时，请求数量很少，但具有非常特定的配置相关性，就变得尤为严重。迁移结果的主要教训之一是，不仅要监视指标，还要监视日志和“长尾巴” （我们正在谈论它们在图形上的分布-大约Transl。）时，需要考虑到这一点。现在，对于每次迁移，我们都包含详细的日志查询列表，并计划明确的回滚过程，以便在出现问题时可以从一个班次转移到另一个班次。
在旧的VM基础架构和基于Kubernetes的新VM基础架构上并行服务相同的请求是一个独特的挑战。与升降机迁移（将应用程序“按原样”快速迁移到新基础架构；您可以在此处阅读更多详细信息，例如，大约Transl。）不同，在“旧” VM和Kubernetes上并行工作需要使用以下工具监控系统与这两种环境兼容，并且能够将指标合并到一个视图中。重要的是我们在过渡期间使用相同的仪表板和日志查询以实现一致的可观察性。
4.将流量切换到新集群
对于GitLab.com，一些服务器分配给canary阶段。金丝雀公园满足我们的内部项目，也可以由用户启用。但首先，它旨在验证对基础架构和应用程序所做的更改。迁移的第一个服务通过接受有限的内部流量开始，并且我们继续使用此方法来确保在将所有流量转发到群集之前满足SLO。
在迁移的情况下，这意味着首先将对内部项目的请求发送到Kubernetes，然后通过通过HAProxy更改后端的权重，逐渐将其余流量切换到集群。在从VM迁移到Kubernetes的过程中，很明显，拥有一种在旧基础架构和新基础架构之间重定向流量的简便方法非常有益，因此，在迁移后的头几天中，要使旧基础架构准备好进行回滚。
5.保留豆荚的力量及其用途
几乎立即发现了以下问题：Registry Service的pod迅速启动，但是Sidekiq的pod的启动最多花费了两分钟。当我们开始将工作负载迁移到Kubernetes时，Sidekiq的长时间运行的pod成为一个问题。
在这种情况下，教训是，尽管Kubernetes中的水平Pod自动缩放器（HPA）可以很好地处理流量增长，但重要的是要考虑到工作负载的特征并分配备用Pod容量（尤其是在需求分布不均的环境中）。在我们的例子中，作业突然激增，需要快速扩展，这导致我们在没有时间扩展节点池之前导致CPU资源饱和。
总是有尽可能多的机会将集群挤出来，但是，我们最初面临性能问题，现在从慷慨的Pod预算开始，然后缩减规模，密切关注SLO。 Sidekiq服务的启动Pod已大大加快，现在平均大约需要40秒。GitLab.com和我们自助管理安装的用户（使用官方的GitLab Helm图表）都受益于Pod启动时间的减少。
结论
迁移每项服务后，我们享受了在生产中使用Kubernetes的好处：更快，更安全的应用程序部署，扩展和更有效的资源分配。此外，迁移的优势超越了GitLab.com服务。官方Helm图表的每项改进也使用户受益。
希望您喜欢我们的Kubernetes迁移冒险故事。我们将继续将所有新服务迁移到群集。可以从以下出版物中获得更多信息：
译者的PS
另请参阅我们的博客：