为什么Kubernetes不使用libnetwork

jopen 8年前

Kubernetes 在 1.0 版本之前就已经有了最初的网络插件。与此同时 Docker 也引入了 libnetwork 和 Container Network Model (CNM)。现在 Docker 已经发布并支持了网络插件 libnetwork,然而 Kubernetes 的插件却还停留在 alpha 阶段。 那么一个显而易见的问题是为什么 Kubernetes 还没有采用 libnetwork。毕竟大部分的供应商都肯定会支持 Docker 的插件,Kubernetes 也理所应当采用它。

在开始讨论之前,我们首先需要知道的一点是: Kubernetes 是一个支持多种容器运行环境的系统,Docker 只是其中之一。配置网络对于每个运行环境都是同样重要的。所以当人们问到“ Kubernetes 支持不支持 CNM 时”,他们其实是在问“Kubernetes 会不会在 Docker 运行环境下支持 CNM”。我们当然希望利用同样一个网络插件来支持所有的运行环境,但是这并不是一个绝对的目标。

然而,Kubernetes 并没有在其 Docker 运行环境中采用 CNM/libnetwork。最近一段时间,我们一直在研究探讨能否使用 CoreOS 推出的 App Container (appc) 中的网络模型Container Network Interface (CNI) 去替代它。为什么?这里面有各种技术上和非技术上的原因。

首先,Docker 的网络驱动设计做了一些兼容性不佳的基本假设,这给我们带来了不少困难。

比如 Docker 里面有本地和全局驱动的概念。本地驱动(比如 “bridge”)固定于一台机器而不能做跨机器的远程协调。全局驱动(比如 “overlay”)依赖于 libkv 库去做跨机器间的协调。该库定义了一个 key-value 存储的接口,并且接口非常的底层。为了让 Docker 的全局驱动在 Kubernetes 集群上跑起来,我们还得需要系统管理员去运行 etcd, ZooKeeper, Consul 的实例(具体看 Docker 的 multi-host network 文档); 或者我们得在 Kubernetes 里面提供另一套 libkv 的实现。

不过相比之下,第二种方案(全局驱动)看起来更灵活,更好,所以我们尝试去实现它。但是 libkv 的接口非常底层,它的模式也是为了 Docker 运行环境自身设计的。对于 Kubernetes 来说,我们要么直接暴露出我们的底层 key-value 接口,要么提供一个 key-value 的语义接口(也就是在一个key-value系统上实现结构存储的API)。就性能、伸缩性和安全角度而言,这两个选择对我们来说并不是非常合适。如果我们这样实现的话,整个系统会变明显地变得复杂。这和我们希望利用Docker的网络模型来简化实现所冲突。

对于想要运行 Docker 的全局驱动并能有能力配置 Docker 的用户来说,Docker 的网络应该会运行得很好。对 Kubernetes 来说,我们不希望介入或影响 Docker 的配置步骤;并且不论 Kubernetes 这个项目今后如何发展,这一点应该不会改变。甚至,我们会努力兼容更多的选项给用户。但我们在实践过程中得到的结论是:Docker 的全局驱动是对用户和开发者来说增加了多余的负担,并且我们不会用它作为默认的网络选项——这也意味着使用 Docker 插件的价值很大程度上被排除在外。

与此同时,Docker 的网络模型在设计上还做了很多和 Kubernetes 不兼容的假设。比如说在 Docker 1.8 和 1.9 的版本中,它在实现“服务发现(Service discovery)”时有一个根本性的设计缺陷,结果导致了容器中的 /etc/hosts 文件被随意改写甚至破坏( docker #17190 ) ——而且我们还不能轻易关闭“服务发现”这个功能。在 1.10 的版本中,Docker 还计划增加 捆绑一个新 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 的模型非常不同,没有一个“方法”能把它们很好的兼容起来。其次,我们还是有之前提到的“全局”和“本地”以及 key-value 的问题存在。假设这是个本地驱动,那么我们仍旧要从 Kubernetes 中去得到相应的逻辑网络的信息。

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

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

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

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

原文链接:Why Kubernetes doesn’t use libnetwork

来自: http://www.infoq.com/cn/articles/why-Kubernetes-doesnt-use-libnetwork