Kubernetes拒绝CNM转而扶持CNI的技术与非技术原因

[[CNM与CNI因目标完全重叠而只能是你死我活的竞争关系]]的胜负手其实是 Kubernetes的选边站队。CNM发布后很快得到网络提供商追捧（Cisco Contiv、 OpenStack Kuryr、Calico、Weave等纷纷兼容），照理Kubernetes该是Docker 之外最大受益者——CNM本可以方便地替换Docker自带网络。但Kubernetes却 转而支持当时并不成熟的RKT网络提案，与CoreOS合作发展出CNI。原因分技术 和非技术两层。技术上：Docker网络模型对Kubernetes做了很多无效假设—— Docker区分”本地网络”（无跨节点协调能力，对Kubernetes毫无意义）和”全局 网络”（依赖Docker自建的libkv做全局IP管理，这对已经有etcd的Kubernetes 是鸡肋）。非技术上：Kubernetes当时正推进”把Docker从必备依赖变成可选 引擎”的重构，而Docker坚持CNM只能基于Docker设计；Kubernetes Network SIG 负责人Tim Hockin公开撰文列举了一串issue（libnetwork#139/486/514/865、 docker#18864），指出CNM的网络驱动不向外暴露容器名称、只用内部ID代替， 让第三方插件很难把网络连接和自己管理的容器关联起来，反馈给Docker后被 以”Working as Intended”为由直接关闭——这被Kubernetes解读为故意给非Docker 引擎设置障碍。CNM与CNI仅相差不到两个月先后发布，五年后CNI全面获胜， 除Docker外几乎所有主流编排系统（Kubernetes、RKT、Amazon ECS、OpenShift、 Mesos、Cloud Foundry）都转向CNI阵营，包括原本已加入CNM阵营的Contiv、 Calico、Weave也都推出了CNI插件。