大牌供应商蜂拥 CNCF，Kubernetes 势不可遏｜航海日志 Vol.29

汇总一周容器圈热点资讯，让开发者了解最 in 的容器技术，让企业熟知最实时的国内外容器行业动态。

1.大牌供应商蜂拥 CNCF，Kubernetes 势不可遏

2.Docker 官方镜像现在是多平台的

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

大牌供应商蜂拥 CNCF，Kubernetes 势不可遏

就如同一辆列车驶离站台的逐步加速一样，云原生计算基金会（Cloud Native Computing Foundation，CNCF）正在迅速积聚动力，吸引了一些科技领域最大的供应商。在过去的一个半月里, AWS、Oracle、Microsoft、VMware 都相继加入了其中。

随着 Kubernetes 已经发展成为一个重要的行业工具，这些公司都认为加入 CNCF 和支持其使命是非常必要的。这在一定程度上是由客户需求驱动的, 其中的部分原因是希望在 Kubernetes 和其他相关的云原生技术的开发上掌握发言权。

对于那些不熟悉这个组织的人来说，CNCF 是 Linux 基金会的一部分，它包含了最初在 Google 开发的开源项目 Kubernetes。Kubernetes 充当容器化应用程序的编排层。而容器提供了一种分隔不同软件的方法, 而不是像过去那样作为一个大型的单个应用程序。

CNCF 的执行董事 Dan Kohn 表示, 现在企业都期望以云原生的方式来运行这些容器化的应用程序。当我们看到公司向公共云 （如 AWS、Azure 和 GCP）迈进或者在私有云中运行应用程序时，他们在这两方面都运行着相同的技术, 而 Kubernetes 能给他们一个工具, 以一致的方式管理这些应用程序, 不管他们在哪里。

这达到了一个令人难以置信的速度，作为企业在容器中启动他们的云原生应用程序的编排或操作层。就这样，这些大佬级别的公司看到这一切的势头，决定加入 CNCF 。

采用容器编排工具 Kubernetes 并加入 CNCF ，对于所有大牌供应商来说都是有其业务目的的。Kohn 表示: “并不是表明所有这些公司都决定联手，也不是表明他们在争夺同一个客户，而是他们意识到，试图在容器编排中进行竞争并不具有很大的价值。

Kohn 解释说, 这是因为 Kubernetes 已经在容器编排领域成为事实意义上的标准，这些公司已经决定在提供全方位的服务上进行竞争, 从而提高容器管理方面的经验。这就表明，在这个行业中如果走在前列的大牌供应商都解决了相应的问题，那么对于其他企业来说，重复制造车轮是没有意义的。

Docker 官方镜像现在是多平台的

在过去的一周, Docker 在官方镜像上推出了一个重大的更新，使其实现多平台。现在，当你使用 Docker 运行 hello world，Docker CE 和 EE 将拉取和运行正确的 hello world 的镜像, 无论是为 x86-64 Linux, Windows，ARM，IBM Z 大型机或任何其他 Docker 运行的系统上。随着 Docker 快速添加对其他操作系统（如 Windows）和 CPU 体系结构（如 IBM Z）的支持, 这将是一个重要的 UX 改进。

将 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 应用程序在每个物理站点上的多个集群上运行，并且把将请求从不正常集群转移到其他正常集群的过程完全自动化。

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

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

这一期的『航海日志』就到这里，下期再浪～

参考链接

• https://techcrunch.com/2017/09/20/kubernetes-gains-momentum-as-big-name-vendors-join-cloud-native-computing-foundation/
• https://blog.docker.com/2017/09/docker-official-images-now-multi-platform/
• http://www.infoq.com/cn/news/2017/09/kubernetes-at-github

未经允许不得转载：DaoCloud道客博客 » 大牌供应商蜂拥 CNCF，Kubernetes 势不可遏｜航海日志 Vol.29