SDN是Software-defined networking的縮寫。在許多介紹Kubernetes的文件，特別是安裝文件中， 當介紹到Kubernetes所需的容器網路時常常會提到這個縮寫，告知使用者需要使用某種SDN技術用以解決“每個Pod有獨立IP， Pod之間可以不經過NAT直接互訪”這一Kubernetes叢集最基本的技術要求。

大多數非網路工程師背景的技術人員對SDN這個概念會比較陌生，當讀到這個段落時，往往會選擇把它當作Kubernetes的底層依賴， 照著文件所推薦的流程安裝一款SDN工具，比如Flannel，Calico，Weave等。由於不瞭解這些工具的原理，同時缺乏實際的使用經驗， 當出現文件以外的異常情況時，整個安裝流程就卡住了。SDN儼然成為了Kubernetes大規模普及的攔路虎。

那些按照文件順利搭建起來的叢集當中，還有不少使用了並不適合該叢集所處環境的SDN技術，造成了額外的運維負擔以及潛在的安全風險。 讓我們不得不思考一個問題，怎樣才是正確的在Kubernetes叢集中使用SDN技術的方法？

今天我們來詳細聊聊這個話題。

結論先行

在大多數的Kubernetes叢集中，都不需要使用SDN技術，Kubernetes的容器網路要求可以使用更加簡單易懂的技術來實現， 只有當企業有特定的安全或者配置要求時，才需要使用SDN技術。SDN應當作為一個附加選項，用以解決特定的技術問題。

理解Kubernetes的容器網路

下圖是一張Kubernetes容器網路的示意圖

可以看到在圖中，每臺伺服器上的容器有自己獨立的IP段，各個伺服器之間的容器可以根據目標容器的IP地址進行訪問。

為了實現這一目標，重點解決以下這兩點：

• 各臺伺服器上的容器IP段不能重疊，所以需要有某種IP段分配機制，為各臺伺服器分配獨立的IP段
• 從某個Pod發出的流量到達其所在伺服器時，伺服器網路層應當具備根據目標IP地址將流量轉發到該IP所屬IP段所對應的目標伺服器的能力。

總結起來，實現Kubernetes的容器網路重點需要關注兩方面，分配和路由。

Flannel的工作方式

這裡我們以比較常見的Flannel為例子，看看SDN系統是如何解決分配和路由的問題的。

下圖是Flannel的架構示意圖

可以看到Flannel依賴etcd實現了統一的配置管理機制。當一臺伺服器上的Flannel啟動時，它會連線所配置的etcd叢集， 從中取到當前的網路配置以及其他已有伺服器已經分配的IP段，並從未分配的IP段中選取其中之一作為自己的IP段。 當它將自己的分配記錄寫入etcd之後，其他的伺服器會收到這條新記錄，並更新本地的IP段對映表。

Flannel的IP段分配發生在各臺伺服器上，由flannel程序將結果寫入到etcd中。路由也由Flannel完成，網路流量先進入Flannel控制的Tunnel中， 由Flannel根據當前的IP段對映錶轉發到對應的伺服器上。

需要指出的是Flannel有多種backend，另外新增的kube-subnet-mgr引數會導致Flannel的工作方式有所不同，在這裡就不詳細展開了。 有興趣的朋友可以去查閱Flannel的文件以及原始碼瞭解更多的細節。

更見簡化的網路配置方法

Flannel的工作方式有2點是需要注意的。一是所有伺服器上執行的Flannel均需要etcd的讀寫許可權，不利於許可權的隔離和安全防護。 二是許多教程中所使用的預設backend型別為vxlan，雖然它使用了核心中的vxlan模組，造成的效能損失並不大， 但是在常見的二層網路的環境中，其實並不需要使用Tunnel技術，直接利用路由就可以實現流量的轉發， 這時使用hostgw模式就可以達成目標。

大部分的Kubernetes叢集伺服器數量並不會超過100臺，不論是在物理機房當中或是利用IaaS提供的VPC技術，我們會把這些伺服器均放在同一個網段， 這時我們可以去掉Flannel這一層，直接使用Kubernetes內建的kubenet功能，配合上我們為Kubernetes定製的hostroutes工具， 即可實現容器網路的要求。

kubenet

kubenet是kubelet內建的網路外掛中的一個，它非常的簡單，會根據當前伺服器對應的Node資源上的PodCIDR欄位所設的IP段，配置一個本地的網路介面cbr0， 在新的Pod啟動時，從IP段中分配一個空閒的IP，用它建立容器的網路介面，再將控制權交還給kubelet，完成後續的Pod建立流程。

由於kubenet會自己管理容器網路介面，所以使用kubenet時，不需要修改任何的Docker配置，僅需要在啟動kubelet時，傳入–network-plugin=kubenet 引數即可。

allocate-node-cidrs

allocate-node-cidrs是controller-manager的一個引數，當它和cluster-cidr引數共同使用的時候，controller-manager會為所有的Node資源分配容器IP段， 並將結果寫入到PodCIDR欄位。

hostroutes

hostroutes是我們為kubenet開發的一個配套小工具，它也非常的簡單，它會watch所有的Node資源的變化，用所有Node資源的PodCIDR欄位來配置伺服器本地路由表。 這時所有Pod發出的流量將通過Linux自帶的路由功能進行轉發，效能優異。Linux的路由功能也是大部分技術人員已經掌握的技能，理解維護起來沒有任何負擔。

在這一簡化的模式下，controller-manager負責分配容器IP段，kubenet負責本地網路介面的控制，hostroutes負責路由。 我們最大程度使用了Kubernetes已有的功能，並且用hostroutes來解決kubenet只管網路介面不管路由的問題。整個方案中， 需要寫入許可權的僅有部署在master節點的controller-manager，執行在Node節點上的kubenet和hostroutes均只需要讀取許可權即可，增強了安全性。 另外此方案將Kubernetes作為唯一的配置來源，去除了對etcd的依賴，簡化了配置，降低了運維負擔和安全風險。

不同的技術方案雖說實現細節不同，但是隻要圍繞著分配和路由這兩個關鍵點進行比較，我們就可以更加明確的在不同方案之間進行選擇。

容器網路技術方案選型推薦

任何的技術方案都離不開場景，在這裡我們根據不同的場景給大家推薦幾種技術方案：

• 單伺服器：不需要網路元件，使用Docker自帶的網路即可
• 小規模叢集：使用kubenet + hostroutes，簡單、易配合管理
• 雲環境中的小規模叢集：使用kubenet + master元件上執行的網路控制器，充分利用IaaS所提供的VPC環境中的路由功能，簡化網路配置
• 伺服器不在一個網段的叢集：使用Flannel提供的vxlan或者其他類似的Tunnel技術
• 安全要求高的叢集：使用Calico或者Open vSwitch等支援Policy的SDN技術

總結

在本篇文章中，我們探討了Kubernetes的容器網路的工具方式，並以Flannel為案例分析了已有的SDN解決方案，並提出了適合小規模叢集的kubenet +hostroutes的解決方案。希望可以幫助讀者理清在Kubernetes叢集搭建過程中容器網路這一部分的思路，不再因為容器網路影響了Kubernetes的整體使用。

在實際工作中，各個企業對叢集的要求都有自己的特點，技術人員需要根據企業的需要，充分比較現有的各種方案的優劣，選擇最適合的方案。 直接照抄教程的搭建方式會為將來的執行埋下隱患，應當儘可能的避免。