共计 4781 个字符，预计需要花费 12 分钟才能阅读完成。
GitHub 迁移到 K8S 的最佳实践是怎样的，相信很多没有经验的人对此束手无策，为此本文总结了问题出现的原因和解决方法，通过这篇文章希望你能解决这个问题。
为什么尝试改变——释放 SRE 工程师
在此之前，主要的 Ruby On Rails 应用（github/github）还类似于 8 年前：“Unicorn processes”由 Ruby 进程管理器调用运行在 Puppet-managed 的“God”。同样的，部署 ChatOps 如同第一次引入时所作：Capistrano 在每个前端服务器上建立 SSH 连接，然后更新代码，重新启动应用，当峰值请求负载超过可用的前端 CPU 容量时，GitHub 站点的 SRE 会释放额外的容量，并将其添加到活动前端服务器池当中。
在近几年中，虽然基本生产方法没有太大的变化，不过 GitHub 本身有了很多改变如：新的功能、更大的社区、更多的员工、以及更多的需求。所以这也就产生了很多新的问题，许多团队想将其负责的功能从某个大的应用中提取出来，形成一个可以独立运行和部署的小型服务。伴随着运行服务数量的增加，SRE 团队开始为数十个其他应用提供类似的配置，从而增加了在服务器维护、配置和其他工作上花费的时间，但这些工作又和改进整个 GitHub 的工作流程没有直接关联。
新服务因为它们的复杂性和 SRE 团队的时间问题，需要几天、几周或者几个月的时间来进行部署，随着时间的推移，一些问题逐渐显现：这种方法并没有为工程师提供他们需要的灵活性，以继续构建世界级的服务。
工程师们需要一个自助平台，可以在上面试验、部署和扩展新的服务，还需要同样的平台来满足 Ruby On Rails 应用的需求，这样工程师或机器人就能以秒、天或更长的时间来分配额外的计算机资源去响应需求的变化。
为了满足这些需求，SRE、平台和开发者体验团队开始了一个联合项目：每天数十次地将 github.com 和 api.github.com 的代码部署到 Kubernetes 集群。
为什么是 Kubernetes？
为了评估“平台即服务”的工具，GitHub 仔细研究了 Kubernetes，它是 Google 的一个项目，用于自动化部署、扩展和管理容器化应用的开源系统，通过以下几点为 Kubernetes 特性做了评估：该项目获得了火热的开源社区支持，首次运行实践（允许部署小型集群和应用在最初的几个小时），大量关于设计的经验。
因此迅速地扩大了实验力度和范围：立了一个小的项目去构建 Kubernetes 集群和部署工具，用来支持即将到来的 Hack Week 从而获得一些实际场景中的经验，GitHub 内部对这个项目反映非常积极。
为什么从 github/github 开始？
在项目最初阶段，GitHub 做了一个深思熟虑的决定：关键性工作负载的：github/github 迁移，许多因素促成了这一决定，比较重要的几点是：
需要自助扩展工具来处理持续的增长
希望确保开发习惯和模式适用于大型应用和较小的服务
可以更好地将应用与开发、Staging、生产、Enterprise、和其他环境隔离
迁移一个关键的、高知名度的工作负载可以激发信心，让更多的 Kubernetes 在 GitHub 上采用。
Rapid iteration and confidence building with a review lab
作为迁移的一部分，进行了一些设计以及原型，并验证了前端服务器使用 Kubernetes 的基础服务如：Pod、部署和服务。通过在容器中运行 gitub/github 现有的测试套件，可以对这种新设计进行一些验证，但仍需观察这个容器是如何成为更大的 Kubernetes 资源一部分的，很快就清楚地认识到，在验证阶段，对 Kubernetes 和打算运行的服务进行探索性测试环境是必备的。
与此同时，项目成员观察到，现有的 github/github 抓取请求的模式已经开始显示出增长十分困难的迹象，部署速度和工程师的数量成正比，使用几个额外的部署环境作为验证拉取请求到 github/github 的部分过程也是如此，在工作高峰时，功能齐全的部署环境数量往往是固定的，这就降低了部署拉取请求的过程，工程师门经常要求在“Branch Lab”中测试更多的子系统，同时允许多名工程师同时进行部署，但每个工程师只能启动一个“Unicorn Process”，所以只在测试 API 和 UI 变更时有用，因为这些需求重叠很多，所以可以将这些项目结合起来，并开始在 github/github 上开发一个新的基于 Kubernet/github 的部署环境，被称之为：Review Lab。
在构建 Review Lab 的过程中，还发布了几个子项目：
在 AWS VPC 上运行的 Kubernetes 集群管理使用了 Terraform Kops
一组 Bash 集成测试使用短暂的 Kubernetes 集群，后来在项目开始时大量使用，增强对 Kuberbetes 的信心。
一个 github Dockerfile/github
对内部 CI 平台的增强，用来支持构建和将容器发布到容器注册中心
YAML 表示 50+Kubernetes 资源，签入 github/github
对内部部署应用的增强，支持将 Kubernetes 的资源从一个存储库部署到 Kubernetes 的命名空间，以及从内部存储库中创建 Kubernetes
该服务结合了 Haproxy 和 Consul-Template，将 Unicorn Pods 路由到现有的服务，发布服务信息。
一种读取 Kubernetes 事件的服务，并将异常事件发送给内部服务跟踪系统
一种名为 kube-me 且与 Rpc 兼容的服务，通过聊天向用户公开一组有限的 kubectl 命令。
最终的结果是一个基于聊天的界面，用于为任何拉取请求创建 GitHub 的独立部署，一旦请求通过了所有需要的 CI 任务，用户即可部署他们的请求：
如同之前的“Branch Lab”一样，实验室在最后一次部署后就被清理掉，由于每个实验室都是在其 Kubernetes 名称空间中创建的，清理工作就像删除名称空间一样简单，部署系统会在需要时自动执行。
Review Lab 是一个成功的项目积累了许多经验和成果，在为工程师提供这种环境之前，还为 Kubernetes 集群设计提供了必要的验证基础和原型环境，以及 Kubernetes 资源的设计和配置，这些资源现在用以描述 github/github 的工作负载，在发布后，它帮助工程师建立了信心，GitHub 非常满意这个环境赋予工程师实验和通过自助的方式去解决问题。
Metal Cloud 上的 Kubernetes
随着 Review Lab 的发布后，注意力就转移到了 github.com 上，为了满足关键服务的性能的可靠性需求（依赖于低延迟访问其他数据服务），需要构建 Kubernetes 的基础设施，去支持在物理数据中心和 POP 中运行的云计算，同样，有 12 个子项目：
关于容器网络，因为一个及时且详尽的帖子，GitHub 选择了 Calico，其提供了需要在 IPIP 模式下快速发送一个集群的功能，与此同时也提供了可以在以后的网络基础设施中进行探索的灵活性。
通过十几次阅读 Kelesyhightower 写的《Kubernetes the hard way》，GitHub 将一些手动操作的服务器组装到了一个临时的 Kubernetes 集群中，此集群通过了相关测试。
还构建了一些小工具，为每个集群生成所需的 CA 和配置，格式可以由 Puppet 和 Secret Systems 使用。
对两个实例配置进行了处理：Kubernetes 节点和 Kubernetes Apiservers，这种方式允许用户提供已经配置的集群名称，以便在规定的时间内引入。
构建了一个小型的 Go 服务，用于消耗容器日志，将 Key/Value 格式的元数据附加到每一行，并将它们发送到主机的本地 Syslog 端点。
加强内部负载均衡服务，用来支持 Kubernetes Node Port。
这些工作并没有白费，都通过了内部验收测试的集群，因此，GitHub 的信心十足，同样的一组 Inputs（由 Review Lab 使用的 Kubernetes 资源），相同的数据集（网络服务 Review Lab 连接到 VPN 上），同样的工具都会产生类似的结果，不到一周，虽然大部分的时间都花费在了内部通信和排序上，但对迁移产生了非常重大的影响：可以将整个工作负载从运行在 AWS 上的 Kubernetes 集群迁移到一个运行在 GitHub 数据中的集群。
Raising the confidence bar
Kubernetes 集群在 Github Metal Cloud 上的成功和可复制性，所以是时候对“Unicorn”进行部署来替代当前前端服务器池了，在 GitHub，工程师及其团队通过创建一个 Flipper 特性去验证新功能是很常见的做法，若可行即选择它，然后加强部署系统再去部署一套新的 Kubernetes 资源，github-produciton 名称空间和现有的生产服务器，提高 GLB 支持员工请求路由到不同的后端：基于 Flipper-infuenced 的 cookie，允许员工在任务控制栏的一个按钮上选择实验 Kubernetes 后端。
来自内部用户的负载可以帮助发现问题、修复 BUG，并开始适应 Kubernetes 的生产，在此期间，通过模拟未来想要执行的应用、编写运行手册和执行 Failure Tests 来增强信心，还将少量的生产流量路由到这个集群，去确认对于负载下性能和可靠性的设定，从每秒 100 个请求开始，然后扩展到 github.com 和 api.github.com 请求的 10%，在几个模拟试验中曾短暂地停止用来重新评估完全迁移的风险。
Cluster Groups
因为一些 Failure Tests 导致了意料之外的结果，特别是模拟单个 Apiserver 节点故障的测试破坏了集群，这种方式对运行工作负载的可用性造成了负面影响，根据调查显示，这些测试没有取得决定性的效果，但帮助识别出相关的破坏可能是一个相互作用的各种客户连接到 Kubernetes Apiserver（像 Calico-Agent Kubelet Kube-Proxy，Kube-Controller-Manager）和内部负载均衡器的行为在一个 Apiserver 节点中的失败，因为检测到 Kuberntes 集群降级可能会破坏服务，所以开始关注了每个站点上运行的关键应用，并自动化地将请求从一个不健康的集群迁移到其他健康的集群。
类似的工作已经放在 GitHub 的流程图中，支持此应用部署到多个独立运营的网站，和其他积极的方式进行取舍。最终选定的设计是：使用部署系统支持多个“分区”增强它通过一个定制的支持提供集群乏味内配置 Kubernetes 资源注释，放弃现有的联合解决方案，允许使用业务逻辑已经出现在 GitHub 的部署系统。
从 10% 到 100%
有了集群组，GitHub 逐渐将前端服务器转换为 Kubernetes 节点，并增加了路由到 Kubernetes 的流量，与其他一些工程师团队一起，在一个多月的时间内完成了前端的转换，同时，在这此期间保持了预计的性能和可接受的错误率。
在迁移过程中，遇到了一直持续至今的问题：在高负载 / 或高利用率的容器中，一些 Kubernetes 节点会出现内核错误并会重启，虽然 GitHub 对这种情况不是很满意，而且进行了最高优先级的排查，但还是很高兴地看到 Kubernetes 能够自动地绕过这些故障，并继续在错误范围内服务流量。
GitHub 进行了一些 Failure Tests，模拟了与 echo c/proc/sysrq 触发相似的内核错误，这是一个很有用的补充。
看完上述内容，你们掌握 GitHub 迁移到 K8S 的最佳实践是怎样的的方法了吗？如果还想学到更多技能或想了解更多相关内容，欢迎关注丸趣 TV 行业资讯频道，感谢各位的阅读！
