為什么Kubernetes不使用libnetwork

今天就跟大家聊聊有關為什么Kubernetes不使用libnetwork，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結了以下內容，希望大家根據這篇文章可以有所收獲。

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 使用我們的網橋）。

看完上述內容，你們對為什么Kubernetes不使用libnetwork有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注億速云行業資訊頻道，感謝大家的支持。