BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

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

| 作者 Daniel Bryant 关注 281 他的粉丝 ,译者 张斌 关注 0 他的粉丝 发布于 2017年9月25日. 估计阅读时间: 6 分钟 | QCon北京2018全面起航:开启与Netflix、微软、ThoughtWorks等公司的技术创新之路!

亲爱的读者:我们最近添加了一些个人消息定制功能,您只需选择感兴趣的技术主题,即可获取重要资讯的邮件和网页通知

过去一年中,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)关注我们。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT