內容來源：2018 年 1 月 10 日，靈雀雲k8s首席專家劉夢馨在“雲原生技術沙龍－北京站”進行《K8s高級網絡實踐》演講分享。IT 大咖說作為獨家視頻合作方，經主辦方和講者審閱授權發佈。
閱讀字數：2418 | 7分鐘閱讀
獲取嘉賓演講視頻及PPT，請複製：http://t.cn/RedbQcS，粘貼至瀏覽器即可。
摘要
CNI 作為 CNCF 的項目提供了構建容器網絡的接口和類庫，可以方便 kubernetes 擴展使用不同的網絡模型，這次會介紹一下 CNI 的工作方式以及如何進行開發。同時會結合靈雀雲的實踐來介紹現有網絡模型在傳統環境存在的一些缺陷以及靈雀雲如何根據 CNI 的接口實現的 pod 靜態 IP 方面的工作。
Kubernetes的網絡模型
Pod IP
Kubernetes的網絡模型主要分為三層。第一層是Pod的多個容器之間的互通，這層實現起來比較簡單，因為所有的容器都共享一個網卡，所以可以直接通信。第二層是同個宿主機中多個Pod的互通，這方面其實也很好解決，可以通過Docker默認服務創建的Docker 0的網橋進行通信，其他的像Calico、Flannel這樣的網絡插件也會創建類似的網橋來方便通信。第三層是跨主機的容器互通，關於這層kubernetes只是定義了規範並沒有真正的實現，包括IP分配、IP通信，IP是否固定這些kubernetes都不會管，僅僅是規定了所有的部分都需要有一個IP才能互通。
Kubernetes網絡模型的缺陷
動態IP or 固定IP
過去Kubernetes網絡模型的動態IP模式是我們在與客戶交流過程中遇到的最大難題，一般很難有客戶能夠接受非固定IP的形式，大多是強烈要求採用固定IP。
從傳統角度來看，運維是管控所有的計算網絡資源的，有精細化的IP管理。因此完全的IP隨機分配對他們來說在理念上就是一個有很大的衝擊，除此之外很多的傳統工作也離不開基於IP的技術，比如基於IP的監控、安全策略。
從實際角度來看，傳統的服務部署也有很多是基於IP的實現，如果IP無法固定會帶來很多問題。最典型的就是Etcd的部署，傳統的模式中這很容易實現，但是在kubernetes中就需要仔細考量下，在理念上會有很大的轉變，要理解些新的概念。
從以上分析來看，其實客戶想要固定IP的需求並非是因為理念上的固執，而是有一定的合理的依據。
反過來看如果kubernetes有了固定IP，又會有哪些影響。細細想想其實整體來看並不會有太大的影響，原先的kubernetes的服務發現機制依然可用，甚至還多了一種方式，傳統的基於IP的監控運維也沒什麼問題。
目前之所以很少看到固定IP的模式，個人認為主要有三方面的原因。首先Docker最初就是基於單機的設計，沒有想過大規模集群的應用，所以不會涉及到對IP的管控。第二可能是理念之爭。到底服務應該是有狀態還是無狀態？現在業界都在追求微服務、無狀態，不關心網絡、存儲只關注計算，但是其實很難做到真正的無狀態，即使自身的服務是無狀態的也還是會調用第三方的服務留下狀態信息。第三是因為實現起來難度很高，固定的IP所帶來的是有狀態，而有狀態的服務往往都很難去做。
固定IP是不是無法實現呢？其實使用CNI就能很好的解決。
CNI簡介
CNI是CNCS的子項目，它為容器提供了一套標準的網絡接口，具體分為兩部分，一部分是CNI標準，包括如何實現CNI以及一些接口和庫，另一部分是官方的實現，會提供一些CNI網絡插件。
CNI and kubernetes
這裡我們看下CNI和kubernetes之間是如何交互的。
通過kubernetes命令行和CNI關聯會有兩個選項，分別是CNI配置地址和CNI二進制文件目錄。一般程序之間的交互，大多是RPC、HTTP之類的通信方式，但是CNI和kubernetes的交互是通過二進制文件的方式。
CNI的配置中比較重要的是type和IPAM，type表示網卡的生成方式，IPAM指定IP分配的方式。創建Pod的時候，CNI會根據這個文件先調用type指定的方式，創建一個網卡，然後調用IPAM指定的方式，獲取IP。銷燬Pod的時候，反過來調用，先釋放IP再刪除網卡。
不同的CNI之間也是通過Config來進行通信。具體的結構中首先interface中會有一個MAC地址，這在一般的網絡插件中是沒有，而這裡提供了設置。配置中的IP是列表的形式，多IP的形式方便了傳統功能的實現。另外每臺Pod的網絡路由和DNS都可以自行設置。
固定IP
針對前面提到的固定IP的實現，只需要用到CNI關於IP控制的插件，目前已有的分別是DHCP和host-local，不過他們都不能很好的滿足我們的需求。DHCP的隨機分配模式在生產環境中很少得到應用，和容器網絡也很難結合起來；host-local會限定每臺機器的固定網絡範圍，增減機器的時候重新分配IP很困難。因此我們最後將IP給提取出來作為第一級的資源，進行單獨的管控。我們專門實現了衣蛾IPAM的插件，它包含網段添加和刪除、網關路由設置、權限控制和配合等功能。
坑和期望
CNI本質上是事件驅動的模型，因此很有可能會遇到丟事件的問題，這裡具體表現為執行失敗、kubernetes掛了、機器掛了等等，從而導致IP洩露、IP衝突。所以如果要做固定IP就一定要加入垃圾處理回收的機制，通過補償機制將不同步的狀態改為同步。
未來我們可能會做一些更靈活的網絡，通過插件在容器的生命週期內改變網絡配置，包括固定MAC、動態路由、dns。另外還想要和現有系統解耦以及支持更多的網絡模式。
以上為今天的全部分享內容，謝謝大家！
閱讀更多 IT大咖說 的文章
