解疑：为何红帽OpenShift选用Kubernetes？
红帽公司的企业Kubernetes发行版，既可以用作商业软件解决方案（OpenShift容器平台，可以运行在OpenStack、VMware、AWS、GCP、Azure 以及任何支持RHEL 7的平台上），也可以用作公共云服务（OpenShift Dedicated和OpenShift Online）。
三年前的一个重要决定
OpenShift在2011年首次推出，一直依赖Linux容器来部署和运行用户应用。在OpenShift v1和v2中，如同许多依赖容器的PaaS解决方案一样，使用红帽自己的与特定平台相关的容器运行时和容器编排引擎。
在2013年年中，红帽做出了一项决定，支持docker开源项目，并帮助推动容器运行时和包装格式的行业标准。我们在红帽企业版Linux 7（以及Fedora和CentOS）中提供了完整的docker支持，这成为OpenShift 3的基础。
但是，红帽一直很清楚，OpenShift不仅仅需要一个容器运行时。真正的应用不是运行在单个容器中，而且实际的生产应用不是部署在单个主机上。能够在多个主机之间协调多个容器是OpenShift的一个关键要求。
在2013年下半年和2014年初，红帽调研了一些方案，包括docker社区中新出现的一些编排方面的工作，并对Mesos进行了彻底评估，我们甚至还尝试构建我们自己的OpenShift特定编排解决方案。我们甚至听到来自Twitterati的呼吁，建议红帽应该支持其他项目，而不是OpenShift。
最终，经过调研，我们选中了Kubernetes。现在回头来看，这有三个主要原因……
了不起的技术
关于Kubernetes，我们首先注意到并仍然非常喜欢的，是其针对容器编排和管理的强大基元（primitive）。这包括：
-
Kubernetes pod，它能够让开发人员将一个或多个容器部署为单个原子单元。
-
能够访问某个固定地址和集成IP中的一组pod的服务，以及基于DNS的服务发现功能，可以将这些服务链接在一起。
-
复制控制器能够确保所需数量的pod始终保持运行，而且有众多标签来识别pod和其他Kubernetes对象。
-
强大的网络模型，用于管理跨多个主机的容器。
-
能够协调存储器，从而让您在容器中运行无状态和有状态的服务。
-
简化的编排模型，能够快速让多个应用投入运行，而无需复杂的双层调度器
-
一套具有下述能力的架构：认识到开发人员和操作人员的需求是不同的，并将这两种需求统筹考虑，从而无需对这两项重要的功能做出妥协。
我们还喜欢的一点是，Kubernetes是采用Go语言编写的，而且是专为容器编排而设计的。我们在docker社区中或者在我们自己的开发工作中都没有看到类似的东西。
虽然Mesos在大数据方面已经拥有良好的记录，但它更多地关注集群管理，并依靠诸如Marathon或Aurora这样的插件来编排容器化的应用服务。这些插件的能力赶不上我们在Kubernetes中看到的能力，而且Mesos本身是一个更复杂的C++代码库，我们认为它更难以扩展和维护。
即使在今天，我们仍然看到，诸如Docker Swarm和Mesos这样的解决方案还在复制Kubernetes最先推出的许多容器编排基元。但是，Kubernetes社区并没有停滞不前；随着每个版本的发布，Kubernetes的创新一直在以惊人的速度继续前进。
了不起的合作伙伴
回顾我过去的电子邮件，我发现我们第一次与Google讨论容器的话题是在2014年3月初。
那次会议的参加者包括Craig McLuckie、Joe Beda、Brendan Burns、Martin Buhr、Ville Aikas以及Google公司Kubernetes项目的其他先驱。当然，当时我们不知道Kubernetes的存在。我们的目的只是讨论两家公司在Docker社区所做的工作，并探索可以一致行动的领域。
Google和红帽两家公司都是Linux和容器技术的长期贡献者。正是Google于2006年在Linux 控制小组(Cgroups)中的工作形成了Linux容器的基础，并使得像Docker这样的项目得以存在。红帽也对Linux的容器技术做出了广泛的贡献，而且与Google一起迅速成为docker项目的顶级贡献者。
在那次会议上，我们了解到，Google不仅支持Docker，还将其引入Google云平台，而且他们还在容器编排方面开展了一个新项目。这个项目，当时代号为“Seven of Nine”，后来展示给红帽工程部负责人以及其他人，他们都对其一见钟情！许多编排功能来自Google自己多年来运行诸如Borg等传统系统，以及大规模编排容器方面的经验。
从这一点上说，它是一个老生常谈的东西，但是在Google，任何东西都运行在容器中，而且当你每个星期都部署数十亿个容器时，你很快就会知道什么东西能奏效，什么东西不起作用。
“Seven of Nine”项目最终变成了Kubernetes，并在那年七月推出，一年后在2015年7月达到了 1.0 状态。我经常听说，评价一家公司时，你应该关注其员工，而不是关注其产品。在这方面，Google 云计算小组当仁不让，他们在容器以及大规模管理容器方面的知识和经验都是首屈一指的。
真正了不起的社区
人们在评估开源软件时常犯的错误是花费太多时间考察技术，而没有用足够的时间来评估它周围的社区。这是我担任红帽公司产品经理时学到的第一课。任何开源技术的当前状态只是时间长河中的一瞬间。而它周围的社区的状态才是决定其创新速度的东西，而且也决定着该技术将会如何随着时间的推移而发展。
在短短一年多的时间里，Kubernetes社区贡献者数量已经壮大到任何其他容器编排项目的4倍，并已成为Github上增长最快的开源项目之一。现在，在云原生计算基金会(CNCF) 的治理下，我们看到众多公司和个人贡献者正在开展卓越协作和创新。
从我们最早与Google讨论开始，我们就看到他们致力于建立一个完全开放的、基于精英管理的社区。他们邀请红帽加入该社区，并请求我们就如何塑造它提出建议。
当2014年7月Kubernetes最终作为开源项目发布时，红帽也加入了发布活动；目前红帽是仅次于Google的第二位贡献者。在Google的支持下，红帽一直致力于帮助Kubernetes扩大企业用户使用案例，而且正是通过OpenShift来实现这一目标。
Kubernetes社区的活力体现在项目的快速增长，以及每一个版本发布时所引入的大量新功能。现在我们看到，Kubernetes不断扩展，运行规模达到新层次，从而能够支持新的工作负载、推动新的集群联合、满足企业在安全性和可管理性方面的要求，同时提高了易用性。
喜欢就说出来，我本人以及整个红帽团队都非常高兴红帽为OpenShift选择了Kubernetes。
