Kubernetes網絡概述

【編者的話】本文比較了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（翻譯：範浩）