大家好，說到容器、Docker，大家一定會想到Kubernetes，確實如此，在2016年ClusterHQ容器技術應用調查報告顯示，Kubernetes的使用率已經達到了40%，成為最受歡迎的容器編排工具；那麼Kubernetes到底是什麼呢？它是一個用於容器叢集的自動化部署、擴容以及運維的開源平臺；那麼通過Kubernetes能幹什麼呢？它能快速而有預期地部署你的應用，極速地擴充套件你的應用，無縫對接新的應用功能，節省資源，優化硬體資源的使用。

隨著Kubernetes王者時代的到來，計算、網路、儲存、安全是Kubernetes繞不開的話題，本次主要分享Kubernetes網路原理及方案，後續還會有Kubernetes其它方面的分享，另外有容雲5.22釋出了基於Kubernetes的容器雲平臺產品

一、Kubernetes網路模型

在Kubernetes網路中存在兩種IP（Pod IP和Service Cluster IP），Pod IP 地址是實際存在於某個網絡卡(可以是虛擬裝置)上的，Service Cluster IP它是一個虛擬IP，是由kube-proxy使用Iptables規則重新定向到其本地埠，再均衡到後端Pod的。下面講講Kubernetes Pod網路設計模型：

1、基本原則：

每個Pod都擁有一個獨立的IP地址（IPper Pod），而且假定所有的pod都在一個可以直接連通的、扁平的網路空間中。

2、設計原因：

使用者不需要額外考慮如何建立Pod之間的連線，也不需要考慮將容器埠對映到主機埠等問題。

3、網路要求：

所有的容器都可以在不用NAT的方式下同別的容器通訊；所有節點都可在不用NAT的方式下同所有容器通訊；容器的地址和別人看到的地址是同一個地址。

二、Docker網路基礎

• Linux網路名詞解釋：

1、網路的名稱空間：Linux在網路棧中引入網路名稱空間，將獨立的網路協議棧隔離到不同的命令空間中，彼此間無法通訊；docker利用這一特性，實現不容器間的網路隔離。

2、Veth裝置對：Veth裝置對的引入是為了實現在不同網路名稱空間的通訊。

3、Iptables/Netfilter：Netfilter負責在核心中執行各種掛接的規則(過濾、修改、丟棄等)，執行在核心 模式中；Iptables模式是在使用者模式下執行的程序，負責協助維護核心中Netfilter的各種規則表；通過二者的配合來實現整個Linux網路協議棧中靈活的資料包處理機制。

4、網橋：網橋是一個二層網路裝置,通過網橋可以將linux支援的不同的埠連線起來,並實現類似交換機那樣的多對多的通訊。

5、路由：Linux系統包含一個完整的路由功能，當IP層在處理資料傳送或轉發的時候，會使用路由表來決定發往哪裡。

• Docker生態技術棧

下圖展示了Docker網路在整個Docker生態技術棧中的位置：

• Docker網路實現

1、單機網路模式：Bridge 、Host、Container、None，這裡具體就不贅述了。

2、多機網路模式：一類是 Docker 在 1.9 版本中引入Libnetwork專案，對跨節點網路的原生支援；一類是通過外掛（plugin）方式引入的第三方實現方案，比如 Flannel，Calico 等等。

三、Kubernetes網路基礎

1、容器間通訊：

同一個Pod的容器共享同一個網路名稱空間，它們之間的訪問可以用localhost地址 + 容器埠就可以訪問。

2、同一Node中Pod間通訊：

同一Node中Pod的預設路由都是docker0的地址，由於它們關聯在同一個docker0網橋上，地址網段相同，所有它們之間應當是能直接通訊的。

3、不同Node中Pod間通訊：

不同Node中Pod間通訊要滿足2個條件： Pod的IP不能衝突； 將Pod的IP和所在的Node的IP關聯起來，通過這個關聯讓Pod可以互相訪問。

4、Service介紹：

Service是一組Pod的服務抽象，相當於一組Pod的LB，負責將請求分發給對應的

Pod；Service會為這個LB提供一個IP，一般稱為ClusterIP。

5、Kube-proxy介紹：

Kube-proxy是一個簡單的網路代理和負載均衡器，它的作用主要是負責Service的實現，具體來說，就是實現了內部從Pod到Service和外部的從NodePort向Service的訪問。

實現方式：

• userspace是在使用者空間，通過kuber-proxy實現LB的代理服務，這個是kube-proxy的最初的版本，較為穩定，但是效率也自然不太高。

• iptables是純採用iptables來實現LB，是目前kube-proxy預設的方式。

下面是iptables模式下Kube-proxy的實現方式：

• 在這種模式下，kube-proxy監視Kubernetes主伺服器新增和刪除服務和端點物件。對於每個服務，它安裝iptables規則，捕獲到服務的clusterIP（虛擬）和埠的流量，並將流量重定向到服務的後端集合之一。對於每個Endpoints物件，它安裝選擇後端Pod的iptables規則。

• 預設情況下，後端的選擇是隨機的。可以通過將service.spec.sessionAffinity設定為“ClientIP”（預設為“無”）來選擇基於客戶端IP的會話關聯。

• 與使用者空間代理一樣，最終結果是繫結到服務的IP:埠的任何流量被代理到適當的後端，而客戶端不知道關於Kubernetes或服務或Pod的任何資訊。這應該比使用者空間代理更快，更可靠。然而，與使用者空間代理不同，如果最初選擇的Pod不響應，則iptables代理不能自動重試另一個Pod，因此它取決於具有工作準備就緒探測。

6、Kube-dns介紹

Kube-dns用來為kubernetes service分配子域名，在叢集中可以通過名稱訪問service；通常kube-dns會為service賦予一個名為“service名稱.namespace.svc.cluster.local”的A記錄，用來解析service的clusterip。

Kube-dns元件：

• 在Kubernetes v1.4版本之前由“Kube2sky、Etcd、Skydns、Exechealthz”四個元件組成。

• 在Kubernetes v1.4版本及之後由“Kubedns、dnsmasq、exechealthz”三個元件組成。

 Kubedns

• 接入SkyDNS，為dnsmasq提供查詢服務。
• 替換etcd容器，使用樹形結構在記憶體中儲存DNS記錄。
• 通過K8S API監視Service資源變化並更新DNS記錄。
• 服務10053埠。

Dnsmasq

• Dnsmasq是一款小巧的DNS配置工具。

• 在kube-dns外掛中的作用是：

1. 通過kubedns容器獲取DNS規則，在叢集中提供DNS查詢服務
2. 提供DNS快取，提高查詢效能
3. 降低kubedns容器的壓力、提高穩定性

• Dockerfile在GitHub上Kubernetes組織的contrib倉庫中，位於dnsmasq目錄下。

• 在kube-dns外掛的編排檔案中可以看到，dnsmasq通過引數–server=127.0.0.1:10053指定upstream為kubedns。

Exechealthz

• 在kube-dns外掛中提供健康檢查功能。
• 原始碼同樣在contrib倉庫中，位於exec-healthz目錄下。
• 新版中會對兩個容器都進行健康檢查，更加完善。

四、Kubernetes網路開源元件

1、技術術語：

IPAM：IP地址管理；這個IP地址管理並不是容器所特有的，傳統的網路比如說DHCP其實也是一種IPAM，到了容器時代我們談IPAM，主流的兩種方法： 基於CIDR的IP地址段分配地或者精確為每一個容器分配IP。但總之一旦形成一個容器主機叢集之後，上面的容器都要給它分配一個全域性唯一的IP地址，這就涉及到IPAM的話題。

Overlay：在現有二層或三層網路之上再構建起來一個獨立的網路，這個網路通常會有自己獨立的IP地址空間、交換或者路由的實現。

IPSesc：一個點對點的一個加密通訊協議，一般會用到Overlay網路的資料通道里。

vxLAN：由VMware、Cisco、RedHat等聯合提出的這麼一個解決方案，這個解決方案最主要是解決VLAN支援虛擬網路數量（4096）過少的問題。因為在公有云上每一個租戶都有不同的VPC，4096明顯不夠用。就有了vxLAN，它可以支援1600萬個虛擬網路，基本上公有云是夠用的。

網橋Bridge： 連線兩個對等網路之間的網路裝置，但在今天的語境裡指的是Linux Bridge，就是大名鼎鼎的Docker0這個網橋。

BGP： 主幹網自治網路的路由協議，今天有了網際網路，網際網路由很多小的自治網路構成的，自治網路之間的三層路由是由BGP實現的。

SDN、Openflow： 軟體定義網路裡面的一個術語，比如說我們經常聽到的流表、控制平面，或者轉發平面都是Openflow裡的術語。

2、容器網路方案：

隧道方案（ Overlay Networking ）

隧道方案在IaaS層的網路中應用也比較多，大家共識是隨著節點規模的增長複雜度會提升，而且出了網路問題跟蹤起來比較麻煩，大規模叢集情況下這是需要考慮的一個點。

• Weave：UDP廣播，本機建立新的BR，通過PCAP互通
• Open vSwitch（OVS）：基於VxLan和GRE協議，但是效能方面損失比較嚴重
• Flannel：UDP廣播，VxLan
• Racher：IPsec

路由方案

路由方案一般是從3層或者2層實現隔離和跨主機容器互通的，出了問題也很容易排查。

• Calico：基於BGP協議的路由方案，支援很細緻的ACL控制，對混合雲親和度比較高。
• Macvlan：從邏輯和Kernel層來看隔離性和效能最優的方案，基於二層隔離，所以需要二層路由器支援，大多數雲服務商不支援，所以混合雲上比較難以實現。

3、CNM & CNI陣營：

容器網路發展到現在，形成了兩大陣營，就是Docker的CNM和Google、CoreOS、Kuberenetes主導的CNI。首先明確一點，CNM和CNI並不是網路實現，他們是網路規範和網路體系，從研發的角度他們就是一堆介面，你底層是用Flannel也好、用Calico也好，他們並不關心，CNM和CNI關心的是網路管理的問題。

CNM（Docker LibnetworkContainer Network Model）:

Docker Libnetwork的優勢就是原生，而且和Docker容器生命週期結合緊密；缺點也可以理解為是原生，被Docker“綁架”。

• Docker Swarm overlay
• Macvlan & IP networkdrivers
• Calico
• Contiv
• Weave

CNI（Container NetworkInterface）：

CNI的優勢是相容其他容器技術（e.g. rkt）及上層編排系統（Kubernetes & Mesos)，而且社群活躍勢頭迅猛，Kubernetes加上CoreOS主推；缺點是非Docker原生。

• Kubernetes
• Weave
• Macvlan
• Calico
• Flannel
• Contiv
• Mesos CNI

4、Flannel容器網路：

Flannel之所以可以搭建kubernets依賴的底層網路，是因為它可以實現以下兩點：

• 它給每個node上的docker容器分配相互不想衝突的IP地址；
• 它能給這些IP地址之間建立一個覆蓋網路，同過覆蓋網路，將資料包原封不動的傳遞到目標容器內。

Flannel介紹

• Flannel是CoreOS團隊針對Kubernetes設計的一個網路規劃服務，簡單來說，它的功能是讓叢集中的不同節點主機建立的Docker容器都具有全叢集唯一的虛擬IP地址。
• 在預設的Docker配置中，每個節點上的Docker服務會分別負責所在節點容器的IP分配。這樣導致的一個問題是，不同節點上容器可能獲得相同的內外IP地址。並使這些容器之間能夠之間通過IP地址相互找到，也就是相互ping通。
• Flannel的設計目的就是為叢集中的所有節點重新規劃IP地址的使用規則，從而使得不同節點上的容器能夠獲得“同屬一個內網”且”不重複的”IP地址，並讓屬於不同節點上的容器能夠直接通過內網IP通訊。
• Flannel實質上是一種“覆蓋網路(overlaynetwork)”，也就是將TCP資料包裝在另一種網路包裡面進行路由轉發和通訊，目前已經支援udp、vxlan、host-gw、aws-vpc、gce和alloc路由等資料轉發方式，預設的節點間資料通訊方式是UDP轉發。

5、Calico容器網路：

Calico介紹

• Calico是一個純3層的資料中心網路方案，而且無縫整合像OpenStack這種IaaS雲架構，能夠提供可控的VM、容器、裸機之間的IP通訊。Calico不使用重疊網路比如flannel和libnetwork重疊網路驅動，它是一個純三層的方法，使用虛擬路由代替虛擬交換，每一臺虛擬路由通過BGP協議傳播可達資訊（路由）到剩餘資料中心。
• Calico在每一個計算節點利用Linux Kernel實現了一個高效的vRouter來負責資料轉發，而每個vRouter通過BGP協議負責把自己上執行的workload的路由資訊像整個Calico網路內傳播——小規模部署可以直接互聯，大規模下可通過指定的BGP route reflector來完成。
• Calico節點組網可以直接利用資料中心的網路結構（無論是L2或者L3），不需要額外的NAT，隧道或者Overlay Network。
• Calico基於iptables還提供了豐富而靈活的網路Policy，保證通過各個節點上的ACLs來提供Workload的多租戶隔離、安全組以及其他可達性限制等功能。

Calico架構圖

五、網路開源元件效能對比分析

效能對比分析：

效能對比總結：

CalicoBGP 方案最好，不能用 BGP 也可以考慮 Calico ipip tunnel 方案；如果是 Coreos 系又能開 udp offload，flannel 是不錯的選擇；Docker 原生Overlay還有很多需要改進的地方。

最後，再提下我們有容雲5.22釋出了基於Kubernetes的容器雲平臺產品UFleet，UFleet採用的是Flannel網路，後續我們將支援Calico網路，如需試用，歡迎聯絡有容雲。