5 CNCF（Cloud Native Computing Foundation）

的基金会

基金会希望，以 Kubernetes 项目为基础，建立一个由开源基础设施领域厂商主导的、按照独立基金会方式运营的平台级社区，来对抗以Docker公司为核心的容器商业生态。

CNCF社区就需要至少确保两件事情

5.1 在容器编排,Kubernetes具备强大优势

在容器编排领域，Kubernetes项目需要面对来自Docker公司和Mesos社区两个方向的压力。

• Swarm擅长是跟Docker生态的无缝集成
• Mesos擅长大规模集群的调度与管理

这两个方向，也是大多数人做容器集群管理项目时最容易想到的两个出发点

也正因为如此，Kubernetes项目如果继续在这两个方向上做文章恐怕就不太明智了。

Kubernetes选择的应对方式是

Borg

Kubernetes项目早期的GitHub Issue和Feature大多来自于Borg和Omega系统的内部特性

落到Kubernetes项目上，就是Pod、Sidecar等功能和设计模式。

Kubernetes项目的基础特性是Google公司在容器化基础设施领域多年来实践经验的沉淀与升华

是Kubernetes项目能够从一开始就避免同Swarm和Mesos社区同质化的重要手段!

5.2 CNCF社区必须以Kubernetes项目为核心，覆盖足够多场景

如何把这些先进的思想通过技术手段在开源社区落地，并培育出一个认同这些理念的生态？

RedHat就发挥了重要作用。

当时Kubernetes团队规模很小，能够投入的工程能力也十分紧张，而这恰恰是RedHat的长处

更难得的是，RedHat是世界上为数不多的、能真正理解开源社区运作和项目研发真谛的合作伙伴。

所以，RedHat与Google联盟的成立，不仅保证了RedHat在Kubernetes项目上的影响力，也正式开启了容器编排领域“三国鼎立”的局面。

Mesos社区与容器技术的关系，更像是“借势”，而不是这个领域真正的参与者和领导者

这个事实，加上它所属的Apache社区固有的封闭性，导致了Mesos社区虽然技术最为成熟，却在容器编排领域鲜有创新

这也是为何Google很快就把注意力转向了激进的Docker公司

Docker公司对Mesos社区也是类似的看法,所以从一开始，Docker公司就把应对Kubernetes项目的竞争摆在了首要位置：一方面，不断强调“Docker Native”的“重要性”，另一方面，与Kubernetes项目在多个场合进行了直接的碰撞。

发展态势，很快超过Docker公司的预期。

Kubernetes项目并没有跟Swarm项目展开同质化的竞争，所以“Docker Native”的说辞并没有太大的杀伤力

相反地，Kubernetes项目让人耳目一新的设计理念和号召力，很快就构建出了一个与众不同的容器编排与管理的生态。

就这样，Kubernetes项目在GitHub上的各项指标开始一骑绝尘，将Swarm项目远远地甩在了身后。

有了这个基础，CNCF社区就可以放心地解决第二个问题了。

在已经囊括了容器监控事实标准的