为什么Kubernetes不使用Libnetwork?-阿里云开发者社区

开发者社区> 开发与运维> 正文

为什么Kubernetes不使用Libnetwork?

简介: 本文讲的是为什么Kubernetes不使用Libnetwork?,【编者的话】Libnetwork是2015年5月1日Docker发布的容器网络管理项目。Libnetwork使用Go语言编写,目标是定义一个容器网络模型(CNM),并为应用程序提供一致的编程接口以及网络抽象。
本文讲的是为什么Kubernetes不使用Libnetwork?【编者的话】Libnetwork是2015年5月1日Docker发布的容器网络管理项目。Libnetwork使用Go语言编写,目标是定义一个容器网络模型(CNM),并为应用程序提供一致的编程接口以及网络抽象。为什么后来发布的Kubernetes在网络管理方面,没有使用Docker中的Libnetwork呢?且听Google工程师怎么说。

Kubernetes 1.0版本之前就已经具有基本的网络插件体系。与此同时,Docker也将libnetworkCNM(容器网络模型)引入系统中使用。与之不同的是,Kubernetes网络插件系统却还停留在Alpha阶段。既然Docker已经发布并支持网络插件libnetwork,那问题来了,为什么Kubernetes没有使用libnetwork呢?毕竟大部分的供应商肯定会支持Docker的网络插件,为什么不选择使用相同的组件呢?

深入讨论之前,首先我们要知道:Kubernetes是一个支持多容器的运行环境,而Docker只是其中一个容器而已。每一个运行环境都会去配置网络环境,所以当人们问“Kubernetes将会支持CNM吗?”时,他们真正的意思是“Kubernetes是否在Docker运行时下支持CNM?”。我们当然希望利用同样一个网络插件来支持所有的运行环境,但是这并不是一个绝对的目标。

Kubernetes确实没有在Docker中采用CNM/libnetwork。事实上,我们一直在研究能不能用CoreOS提出的APP Container(appc)标准中的容器网络接口(Container Network Interface,CNI)替代它。为什么呢?这里有一些技术和非技术上的原因。

首先,在Docker的网络驱动设计中,预先做了一些兼容的基本假设,这给我们带来不少的问题。

比如在Docker中有一个“本地”驱动和“全局”驱动的概念。本地驱动是以一台机器为中心(例如“bridge”),不能实现跨机器节点的协作。全局驱动依赖libkv(一个抽象的键值对存数对象)可以实现跨机器节点的协作(例如:overlay)。libkv是一个非常底层(语义层面的)的键值对存储接口。为了能让Docker中类似overlay的全局驱动在Kubernetes集群运行,我们还需要集群系统管理员运行consuletcd或者zookeeper实例(参考multi-host networking,或者我们不得不在Kubernetes中提供我们自己对于libkv的实现。

听起来后者更有吸引力一些,而且我们也正在尝试实现它。但是,libkv的接口太过于底层,而且它的架构模式也是Docker内部的量身定制版,我们要么直接暴露底层的key-value存储,要么提供key-value语义接口(在一个key-value系统上实现结构存储的API)。就起性能、可扩展性和安全性而言,以上两种方案都不是太合适。我们使用Docker网络的目标是简化操作,如果那样做的话,很明显会使整个系统将变得更加复杂。

对于那些想运行 Docker 的全局驱动并有能力配置 Docker 的用户来说,Docker 的网络应该是“可行的”。对 Kubernetes 来说,我们不希望介入或影响 Docker 的配置步骤,并且不论 Kubernetes 这个项目今后如何发展,这一点应该都不会改变。Docker 的全局驱动是对用户和开发者来说增加了多余的负担,并且我们不会用它作为默认的网络选项,这也意味着使用 Docker 插件再没什么价值。

Docker 的网络模型在设计上还做了很多和 Kubernetes 不兼容的假设。在 Docker 1.8 和 1.9 的版本中,它在实现“Discovery”时有一个根本性的设计缺陷,结果导致了容器中的 /etc/hosts 文件被随意改写甚至破坏(docker #17190) ,而且我们还不能轻易关闭“服务发现”这个功能。Docker在 1.10 的版本中,还计划增加捆绑一个新 DNS 服务器 的功能,而我们现在还不清楚这个功能能否被关闭。对 Kubernetes 来说,把命名寻址绑定在容器层面,并不是一个正确的设计—我们已经自己定义了一套 Service 命名、寻址、绑定的概念和规则,并且我们也有了我们自己的 DNS 架构和服务(构建在很成熟的 SkyDNS 上)。所以,捆绑一个 DNS 服务器这样的方案并不能满足我们的需求,而且它还有可能无法被关闭。 

除了“本地/全局”驱动这样的区分,Docker 还定义了“进程内”和“进程外”(“远程”)插件。我们还研究了下是否可以绕过 libnework 本身(这样就能避开之前所述的那些问题)来直接使用”远程“插件。不幸的是,这意味着我们同时也失去了使用 Docker 的那些“进程内”插件的可能,特别是”bridge”和”overlay”这样的全局插件。这又令使用 libnetwork 失去了很大一部分意义。

另一方面来说,CNI 和 Kubernetes 在设计哲学上非常一致。它远比 CNM 简单,不需要守护进程,并且至少是跨平台的(CoreOS 的 rkt 容器支持 CNI)。跨平台意味着同一个网络配置可以在多个运行环境下使用(例如 Docker, rkt 和 Hyper)。这也非常符合 Unix 的设计哲学:做好一件事。

另外,包装 CNI 模块来实现一个自定义的模块是非常简单的-通过一个简单的 shell 脚本就可以完成。相反 CNM 就复杂多了。因此我们认为 CNI 更适合快速开发和迭代。早期的实验尝试证明我们可以利用 CNI 插件来替代几乎所有 kubelet 中硬编码的网络逻辑。

我们也尝试为 Docker 实现了一个 “bridge”CNM 驱动来使用 CNI 的驱动。结果表明这更加复杂了问题。首先 CNM 和 CNI 的模型非常不同,没有一个“methods”能把它们很好的兼容。其次,我们还是有之前提到的“全局”和“本地”以及 key-value 的问题存在。假设这是个本地驱动,那么我们仍旧要从 Kubernetes 中去得到相应的逻辑网络的信息。

不幸的是,Docker驱动很难映射接入到类似Kubernetes这样的管理平台。特别是这些驱动使用了 Docker 内部分配的一个 ID 而不是一个通用的网络名字来指向一个容器所属的网络。这样的设计导致一个被定义在外部系统中(例如 Kubernetes )的网络很难被驱动所理解识别。

我们和其它网络提供商将这些问题和其它一些相关问题都汇报给了 Docker 的开发人员。尽管这些问题给非 Docker 的第三方系统带来了很多困扰,它们通常被以“设计就是如此”的理由关闭了相关问题。(libnetwork #139libnetwork #486libnetwork #514libnetwork #865docker #18864)。通过这些举动,我们观察到 Docker 清楚的表明了他们对于有些建议的态度不够开放,因为这些建议可能会分散其一些主要精力、或者降低其对项目的控制。这一点让我们很担忧,因为 Kubernetes 一直支持 Docker,并且为其增加了如此多的功能,但同时 Kubernetes 也是一个独立于 Docker 之外的项目。

种种原因致使我们选择了 CNI 作为 Kubernetes 的网络模型。这将会带来一些令人遗憾的副作用,虽然绝大部分都是一些小问题,比如 Docker 的 inspect 命令显示不了网络地址。不过也会有一些显著的问题,特别是被 Docker 所启动的容器可能不能和被 Kubernetes 启动的容器沟通,以及网络整合工程师必须提供 CNI 驱动来把网络完全整合到 Kubernetes 中。但重要的是,Kubernetes 会变得更简单、灵活并且不需要进行提前配置(比如配置 Docker 使用我们的网桥)。

随着我们越走越远,我们会毋庸置疑地汲取更多更好的整合、简化的方法。如果您对此有啥想法,我们洗耳恭听——可以通过 slack和 network SIG 邮件列表联系我们。

原文链接:why-Kubernetes-doesnt-use-libnetwork(翻译:ylzhang)

原文发布时间为: 2016-01-21
本文作者:ylzhang 
本文来自云栖社区合作伙伴DockerOne,了解相关信息可以关注DockerOne。
原文标题:为什么Kubernetes不使用Libnetwork?

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
开发与运维
使用钉钉扫一扫加入圈子
+ 订阅

集结各类场景实战经验,助你开发运维畅行无忧

其他文章