将 GitHub 的 Web 和 API 迁移到运行在裸机上的 Kubernetes

过去一年中， GitHub 将其运行 Ruby on Rails 应用程序的内部基础设施迁移到了 Kubernetes 上，Ruby on Rails 是 github.com 和 api.github.com 的载体。迁移过程始于在 Unicorn 进程上运行 Web 和 API 应用程序，上述 Uncorn 进程部署于由 Puppet 管理的裸机（ metal cloud ）服务器之上。最后，整个迁移过程在容器处理完所有 Web 和 API 请求时结束，这些容器由部署在 metal cloud 上的 Kubernetes 集群运行。

根据 GitHub Engineering 博文，部署和运行 GitHub 的基本方法在过去八年中没有显著变化。然而，GitHub 本身却发生了巨大变化，包括新的功能、更大的软件社区、更多的 GitHub 开发人员及员工以及每秒钟更多的请求。随着 GitHub 组织的发展，现有的运营方式开始出现新问题。许多团队希望将功能提取到可以独立运行和部署的较小服务中。随着服务数量的增加，网站可靠性工程师（SRE）团队发现他们越来越频繁地进行维护，这意味着他们没有时间来增强底层平台。GitHub 工程师需要一个可以用来实验、部署和扩展新服务的自助服务平台。

Kubernetes 的这几个品质使其从最初被评估过的几个平台中脱颖而出，包括：支持该项目的活跃的开源社区 ; 第一次运行（第一个吃螃蟹）的体验，因此我们可以在初始实验的最初几个小时内部署小型集群和应用程序 ; 以及“可用于激发其设计的大量经验”，其中值得一提的当属 acmqueue 杂志上的" Borg, Omega 和 Kubernetes "这篇文章。

在本项目的最初阶段，GitHub 团队作出了慎重的决定，只关注于关键 Web 流量负载的迁移。做出这一决定源于许多因素，例如：

• 围绕 GitHub 对 Kubernetes 的深入了解会对迁移过程大有裨益。
• 团队希望确保我们制定的习惯和模式适合大型应用程序以及较小型的服务。
• 成功迁移一个关键且知名度高的工作负载能进一步推进 Kubernetes 在 GitHub 的使用。

鉴于被迁移的工作量非常关键，在处理任何生产流量之前必须需要极高的运营信心。因此，我们构建了一系列 Kubernetes “审查实验室”集群作为原型。最终我们得到了一个基于聊天的接口，它被用于为所有pull 请求创建GitHub 的独立部署。审查实验室会在最后一次部署后的一天内被清理，由于每个实验室创建于自己的Kubernetes 命名空间中，清理与删除命名空间一样简单，而且部署系统会在必要时自动执行清理。

为满足旗舰GitHub Web 服务（该服务依赖于对其他数据服务低延迟的访问）的性能和可靠性要求，我们在GitHub 的物理数据中心和POPs 中运行的metal cloud 之上实施了Kubernetes 基础设施。这项工作还涉及许多子项目，包括：通过 Project Calico 网络提供商使用容器网络、借鉴Kelsey Hightower 的 Kubernetes the Hard Way 教程、将 Kubernetes 节点和 Kubernetes apiserver 的配置变得 Puppet 化、 以及增强 GitHub 的内部负载均衡服务（ GLB ）以支持 Kubernetes NodePort 服务等。

在增强 GitHub 部署系统后，我们将一套新的 Kubernetes 资源部署到与现有生产服务器平行的一个 github-production 命名空间上，并增强了 Github 负载均衡服务，可基于受Flipper 影响的功能切换的 cookie ，将员工的网络请求路由到另外的后端服务器。然后，员工就能在任务控制栏中用按钮选择用于实验的Kubernetes 后端服务器。来自内部用户的负载帮助我们发现问题、修复错误，并习惯在生产中采用Kubernetes。

几次初始故障测试产生了出乎意料的结果。特别是，模拟单个apiserver 节点的故障测试中断了集群并且对运行工作负载的可用性产生了负面影响。考虑到Kubernetes 集群降级可能会中断服务，现在我们将Web 应用程序在每个物理站点上的多个集群上运行，并且把将请求从不正常集群转移到其他正常集群的过程完全自动化。

前端转型在一个多月内就完成了，而且性能和错误率被控制在目标之内。在迁移过程中，我们遇到了一个始终存在的问题：在高负载和/ 或高容器流失率的时候，部分Kubernetes 节点会出现内核错误并重启。SRE 团队对此情况不太满意，并且一直高度重视这个问题，但让他们很高兴的是，Kubernetes 能够自动绕过这些故障，并继续提供流量，将错误控制在目标范围内。

GitHub 工程团队“受到了我们将应用程序迁移到 Kubernetes 的启发”。虽然我们将首次迁移的范围有意限定为无状态工作负载，但对于在 Kubernetes 上试验运行有状态服务，例如使用 StatefulSets，我们仍然感到非常期待。

有关 GitHub 采用 Kubernetes 的更多信息您可在 GitHub Engineering 博文中找到。

英文原文： Migrating GitHub’s Web and API to Kubernetes Running on Bare Metal

感谢罗远航对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。