Kubernetes網絡解決方案技術原理深刻剖析-Kubernetes商業環境實戰

本套技術專欄是做者（秦凱新）平時工做的總結和昇華，經過從真實商業環境抽取案例進行總結和分享，並給出商業應用的調優建議和集羣環境容量規劃等內容，請持續關注本套博客。QQ郵箱地址：1120746959@qq.com，若有任何學術交流，可隨時聯繫。

1 Dokcer網絡模型

2 Kubernetes網絡模型

2.1 Flannel如何控制同一水平網絡

• Flannel是如何作到爲不一樣Node上的Pod分配IP且不產生衝突的？由於Flannel使用集中的etcd服務管理這些地址資源信息，它每次分配的地址段都在同一個公共區域獲取，這樣天然能隨時協調，避免衝突了。在Flannel分配好地址段後，接下來的工做就轉交給Docker完成了。Flannel經過修改Docker的啓動參數將分配給它的地址段傳遞進去。

  --bip=172.17.18.1/24
  複製代碼

  經過這些操做，Flannel就控制了每一個Node節點上的docker0地址段的地址，也能保障全部Pod的IP地址在同一水平的網絡中且不產生衝突了

2.1.1 Flannel內核原理

• flannel利用Kubernetes API或者etcd用於存儲整個集羣的網絡配置，其中最主要的功能爲:設置整個集羣的網絡地址空間段。例如，設定整個集羣內全部容器的IP都取自網段「10.1.0.0/16」。
• flannel在每一個物理主機中運行flanneld做爲agent，它會爲所在主機從集羣的網絡地址空間中（網段「10.1.0.0/16」），獲取一個小的網段subnet，本主機內全部容器的IP地址都將從中分配（如：分配主機1網段：10.1.1.0/24，主機2網段：10.1.2.0/24）
• flanneld再將本主機獲取的subnet以及用於主機間通訊的Public IP，一樣經過kubernetes API或者etcd存儲起來。
• flannel利用各類backend mechanism，例如udp，vxlan，hostgw等等，跨主機轉發容器間的網絡流量，完成容器間的跨主機通訊。

2.1.2 Flannel使用VXLAN協議網絡原理

• 每臺物理主機都安裝有flannel，假設k8s定義的flannel網絡爲10.0.0.0/16，各主機的flannel從這個網絡申請一個子網。pod1所在的主機的flannel子網爲10.0.13.1/24，pod2所在主機的flannel子網爲10.0.14.1/24。

• 每臺主機有cni0和flannel.1虛擬網卡。cni0爲在同一主機pod共用的網橋，當kubelet建立容器時，將爲此容器建立虛擬網卡vethxxx，並橋接到cni0網橋。flannel.1是一個tun虛擬網卡，接收不在同一主機的POD的數據，而後將收到的數據轉發給flanneld進程。

2.1.3 Pod1與Pod2不在同一臺主機網絡傳輸過程數據包流向：

• 1. pod1(10.0.14.15)向pod2(10.0.5.150)發送ping，查找pod1路由表，把數據包發送到cni0(10.0.14.1)
• 2. cni0查找host1路由，把數據包轉發到flannel.1
• 3. flannel.1虛擬網卡再把數據包轉發到它的驅動程序flannel
• 4. flannel程序使用VXLAN協議封裝這個數據包，向api-server查詢目的IP所在的主機IP,稱爲host2(不清楚何時查詢)
• 5. flannel向查找到的host2 IP的UDP端口8472傳輸數據包
• 6. host2的flannel收到數據包後，解包，而後轉發給flannel.1虛擬網卡
• 7. flannel.1虛擬網卡查找host2路由表，把數據包轉發給cni0網橋，cni0網橋再把數據包轉發給pod2

2.2 Calico 工做原理

• Calico把每一個操做系統的協議棧認爲是一個路由器，而後把全部的容器認爲是連在這個路由器上的網絡終端，在路由器之間跑標準的路由協議——BGP的協議，而後讓它們本身去學習這個網絡拓撲該如何轉發。因此Calico方案實際上是一個純三層的方案，也就是說讓每臺機器的協議棧的三層去確保兩個容器，跨主機容器之間的三層連通性。

• 對於控制平面，它每一個節點上會運行兩個主要的程序，一個是Felix，它會監聽ECTD中心的存儲，從它獲取事件，好比說用戶在這臺機器上加了一個IP，或者是分配了一個容器等。接着會在這臺機器上建立出一個容器，並將其網卡、IP、MAC都設置好，而後在內核的路由表裏面寫一條，註明這個IP應該到這張網卡。綠色部分是一個標準的路由程序，它會從內核裏面獲取哪一些IP的路由發生了變化，而後經過標準BGP的路由協議擴散到整個其餘的宿主機上，讓外界都知道這個IP在這裏，大家路由的時候獲得這裏來。

• 因爲Calico是一種純三層的實現，所以能夠避免與二層方案相關的數據包封裝的操做，中間沒有任何的NAT，沒有任何的overlay，因此它的轉發效率多是全部方案中最高的，由於它的包直接走原生TCP/IP的協議棧，它的隔離也由於這個棧而變得好作。由於TCP/IP的協議棧提供了一整套的防火牆的規則，因此它能夠經過IPTABLES的規則達到比較複雜的隔離邏輯。

• 每一個主機上都部署了calico/node做爲虛擬路由器，而且能夠經過calico將宿主機組織成任意的拓撲集羣。當集羣中的容器須要與外界通訊時，就能夠經過BGP協議將網關物理路由器加入到集羣中，使外界能夠直接訪問容器IP，而不須要作任何NAT之類的複雜操做。

• 從上圖能夠看出，當容器建立時，calico爲容器生成veth pair，一端做爲容器網卡加入到容器的網絡命名空間，並設置IP和掩碼，一端直接暴露在宿主機上，並經過設置路由規則，將容器IP暴露到宿主機的通訊路由上。於此同時，calico爲每一個主機分配了一段子網做爲容器可分配的IP範圍，這樣就能夠根據子網的CIDR爲每一個主機生成比較固定的路由規則。

  當容器須要跨主機通訊時，主要通過下面的簡單步驟：

  • 容器流量經過veth pair到達宿主機的網絡命名空間上。
  • 根據容器要訪問的IP所在的子網CIDR和主機上的路由規則，找到下一跳要到達的宿主機IP。 流量到達下一跳的宿主機後，根據當前宿主機上的路由規則，直接到達對端容器的veth pair插在宿主機的一端，最終進入容器。
  • 跨主機通訊時，整個通訊路徑徹底沒有使用NAT或者UDP封裝，性能上的損耗確實比較低。

• calico目前只支持TCP、UDP、ICMP、ICMPv6協議，若是使用其餘四層協議（例如NetBIOS協議），建議使用weave、原生overlay等其餘overlay網絡實現。 基於三層實現通訊，在二層上沒有任何加密包裝，所以只能在私有的可靠網絡上使用。 流量隔離基於iptables實現，而且從etcd中獲取須要生成的隔離規則，有一些性能上的隱患

總結

Kubernetes網絡解決方案爲大規模集羣部署提供化多爲一的網絡，本文結合做者在大規模IOT物聯網大數據支撐平臺的實踐經驗，進行總結，此文尚不完善，請持續關注凱新雲技術社區

秦凱新