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社区就可以放心地解决第二个问题了。
在已经囊括了容器监控事实标准的