【編者的話】本文比較了Kubernetes和Docker的網路模型，並對Kubernetes的網路模擬做了重點闡述，對Kubernetes的網路外掛作了比較。
容器編排技術是當今最火的IT技術之一。不可否認，Docker技術促進了資料中心的發展，併為微服務架構在開發和運維中的實踐奠定了基礎。
工作在Sun公司的John Gage 曾說：“ 網路就是計算機。” 為了能充分發揮計算機的功能，必須讓計算機之間互相連線。因此，除非你的服務是簡單的並且不需要擴容，容器編排技術是一個不錯的容器管理技術。在容器編排技術領域，有兩個主要的公司Docker和Google， 每個公司都有用略微不同的方式實現容器編排的產品。
開箱即用的Dcoker容器被繫結到一個獨立的機器上。雖然可以在已建立的埠部署服務，但是當將應用程式擴充套件時，這很快將會是一項枯燥的任務。當將每臺機器作為獨立單元處理時，靈活的自動擴充套件服務將困難的多。
對於任何的編排業務，必須為叢集選擇合適的網路模型，因為這是系統的可配置部分並且通常是不可變的。讀完這篇文章，希望你能對容器的網路模型做出選擇。
Kubernetes模型
Google的Kubernetes是一個公認的，經過實戰考驗的，比較成熟的容器編排技術。它是一個在叢集環境中用於管理應用程式的開源容器編排工具。最近釋出的1.6版本，增強了在叢集環境中多使用者多重負載的可部署性。通過使用minikube簡化了測試環境的搭建，minikube是在host上啟動了一個all in one的虛擬機器來執行Kubernets叢集。但是，這樣的叢集受限於一個節點，除了用作測試工具，沒有辦法去嘗試多節點業務流程。所以，需要用適當的網路模型建立多節點叢集。為了能更好的理解Kubernetes的網路模型，先看下叢集中可能遇到的場景。
Kubernetes 網路有四種元件網路場景：
容器間通訊
這發生於Pod 內，可以認為是本地host的流量。然而，這種場景，並沒有任何網路特性，本文不做闡述。
Pod 間通訊
Pod是可以被Kubernetes建立和管理的最小可部署的計算單元。在Kubernetes叢集中每個pod被分配一個IP地址，Pod中的container共享網路名稱空間。這構成了一個pod間可以相互通訊的網路場景。
Pod和Service間通訊
在Pod和Service間通訊場景中，service被分配一個客戶端可以訪問的IP地址。然後，它們被透明的代理到被Service管理的一組Pod。發給Service的IP的請求會被執行在每個host上的kube-proxy 處理，來選擇去往正確的pod的路由。
外部和內部服務間通訊
允許外部流量進入叢集，主要是通過對映外部的負載均衡器顯示的發現叢集中的服務。該對映允許Kube-intermediary使用叢集的pod網路對適當的pod進行外部請求。當流量到達一個節點後，通過kube-proxy路由到正確的後端服務。
Docker模型
Docker Swarm，是Kubernetes的主要競爭對手，自從Docker 1.12版本（2016.6）後，已經成為Docker Engine的組成單元。在這之前，Docker Swarm 作為一個獨立的產品，是一個輕量級的容器編排工具。
讓我們將所熟知的Kubernetes與Docker允許的容器網路方案進行比較。為了保證在不影響主機網路介面前提下，容器可以相互通訊，Docker 用了一個叫Docker0 的虛擬網橋。Docker0 被分配子網，每個container通過內部的網路介面（通常是eht0）和 Docker0 通訊。這意味著容器只在一個Docker節點聯網。
如果多個節點通訊，則需要一種不同的方法。一個可以使用部署Docker Swarm 用於overlay的網路（通過key,vlaue的儲存模式進行管理，如：etcd或Consul）或者用執行在Docker Engine的網路外掛。
Kubernetes和 Docker的網路方案標準
有許多標準可以成為容器網路的解決方案。Docker和Kubernetes在容器網路標準化方面的工作也有所增加。Docker建立了容器網路模型（CNM），而在同一時間CoreOS也開發了容器網路介面（CNI）。
容器網路模型（CNM）
CNM由Docker引入，CNM有IP 地址管理（IPAM）和網路外掛功能。IPAM外掛可以建立IP地址池並分配，刪除和釋放容器IP。網路外掛API用於建立/刪除網路，並從網路中新增/刪除容器。Docker的libnetwork為CNM的實現提供了基礎。內建的Docker驅動程式可以在第三方外掛幫助下被替換。
因為CNM是在考慮Docker執行時設計的，Kubernetes決定使用容器網路介面（CNI）作為其網路外掛而不是開發自己的網路標準。
容器網路介面（CNI）
CNI 分配IP地址給容器網路介面，而不是像CNM中的etcd或Consul的分散式鍵值儲存。這使CNI 提供了一個簡單的網路介面集可以從網路中增加或刪除容器。最新的CNI支援定義IPAM外掛，它可以在需要的CNI外掛的幫助下被控制。這允許單獨的網路和IPAM外掛並幫助網路驅動程式呼叫IPAM外掛。
Kubernetes網路外掛
下面列出的外掛是專門為Kubernetes開發的。
Kubenet
Kubenet是專門用於單節點環境，它可以通過與設定規則的雲平臺一起使用來實現節點間的通訊。Kubenet是一個非常基本的網路外掛，如果你正在尋找跨節點的網路策略，Kubenet沒有任何幫助。
Flannel
Flannel是一個被CoreOS開發的，專門為Kubernetes設計的overlay網路方案。Flannel的主要優點是它經過了良好的測試並且成本很低。Flannel 為整個叢集的提供分散式處理。Kubernetes為正確的通訊和服務，進行埠對映和分配唯一的IP地址給每個pod。如果你用Google Compute，它將非常相容。然而，如果你用其他的雲服務商，可能會遇到很多困難。Flannel正解決這個問題。
Weave
Weave是由Weavenetwork開發，用於連線、監視、視覺化和監控Kubernetes。通過Weave，可以建立網路，更快的部署防火牆，並通過自動化的故障排除，提高網路運維效率。
用GRE/VXLAN的OpenVSwitch
OpenVSwitch用於跨節點建立網路。隧道型別可以是VxLAN或GRE（通用的路由封裝）。GRE用於在IP網路上進行資料幀的隧道化。在VXLAN的一幀資料中，包括了原來的2層資料包頭，被封裝的一個IP包頭，一個UDP包頭和一個VXLAN包頭。VXLAN更適用於要進行大規模網路隔離的大型資料中心。值得注意的是，OpenVSwitch也是Xen預設的網路方案，同樣也適用於像KVM，VIrtualBox，Proxmox VE或OpenStack等平臺。
Calico
從Kubernetes 1.0開始， Calico為Kubernetes pod提供了三層網路。Calico提供了簡單的，可擴充套件的，安全的虛擬網路。它用邊界閘道器協議（BGP）為每個Pod提供根分佈，並可使用IT基礎設施整合Kubernetes叢集。Calico可以幾乎與所有的雲平臺相容，在Kubernetes環境下，具有高可擴充套件性。除了Kubernetes，Calico 還支援OpenStack，Mesos和Docker。
總結
儘管容器的發展極大的改變了敏捷和持續交付的環境，但容器網路技術仍然在發展。在充滿活力的社群中，有些基於SDN技術的專案很快的將走向成熟，如Neutron和NSX。目前來講，Kubernetes提供了更廣泛的網路模型並且似乎已成為容器編排方案的標準。
原文連結：Networking in Kubernetes（翻譯：範浩）