大约一年以来，基础架构部门一直致力于将在GitLab.com上运行的所有服务迁移到Kubernetes。不仅在将服务转移到Kubernetes方面而且在过渡期间管理混合部署方面，这项工作并非没有挑战。我们将在本文中探讨的过程中吸取了很多教训。
跨可用区流量增加了计费
Google将其网络划分为多个区域，并将各个区域划分为可用区（AZ）。由于Git托管需要大量带宽，因此了解网络出口非常重要。对于内部网络流量，仅当出口保持在单个可用区中时，它才是免费的。
区域GKE群集提供了跨越多个可用区以实现冗余的便利。我们正在考虑将区域GKE群集拆分为单个区域群集，以使用大量带宽的服务来避免网络出口费用，同时在群集级别上保持冗余。
资源限制，请求和扩展
我们的迁移故事始于2019年8月，当时我们将GitLab容器注册表迁移到Kubernetes，这是第一个迁移的服务。尽管这是一项关键且高流量的服务，但它是第一次迁移的不错选择，因为它是一个无状态应用程序，只有很少的外部依赖项。我们遇到的第一个挑战是由于节点上的内存限制而导致大量Pod被驱逐消失。
这要求对请求和限制进行多次更改。我们发现，随着应用程序随着时间的推移增加其内存利用率，低请求（为每个Pod保留内存）和对利用率的慷慨硬性限制是导致节点饱和和驱逐率高的秘诀。
为了对此进行调整，我们最终决定使用更高的请求和更低的限制这样可以减轻节点的压力，并在不对节点施加太大压力的情况下回收豆荚。经历了一次之后，我们开始以接近相同值的大量请求和限制进行迁移，然后根据需要进行调整。
指标和记录
在过去的一年中，基础架构部门的主要变化之一是改进了我们监控和管理SLO的方式。SLO使我们能够为迁移过程中受到密切监视的单个服务设置目标。
将流量转移到新集群
我们迁移的第一个服务从内部限制流量开始，我们将继续使用此方法来确保在将所有流量提交给群集之前满足我们的SLO。对于迁移而言，这意味着将内部项目的请求首先路由到Kubernetes，然后使用HAProxy后端加权将其他流量缓慢移至群集。在从VM迁移到Kubernetes的过程中，我们了解到，对我们而言，以一种简便的方法在新旧基础架构之间移动流量，并使旧基础架构在迁移后的头几天保持可回滚状态非常有益。
预留的Pod容量和利用率
我们较早发现的一个问题是，虽然我们注册服务的pod启动时间很短，但Sidekiq的启动时间却长达两分钟。当我们开始为需要快速处理工作和快速扩展的工作人员将工作负载转移到Kubernetes时，漫长的Sidekiq启动时间带来了挑战。此处的教训是，在Kubernetes中，水平pod自动缩放器（HPA）在适应不断增加的流量方面效果很好，同时评估工作负载特性和设置预留的pod容量（尤其是对于不均衡的需求）也很重要。
在我们的案例中，我们看到作业突然激增，这导致了一个大型扩展事件，在我们可以扩展节点池之前，该事件使CPU饱和。尽管试图尽可能地将其挤出集群，但在遇到一些初始性能问题后，我们现在首先从设置大量的pod开始，然后在以后缩小规模，同时密切关注SLO。