Kubernetes網路模型

談到Kubernetes的網路模型，就不能不提它著名的“單Pod單IP”模型，即每個Pod都有一個獨立的IP，Pod內所有容器共享網路namespace（同一個網路協議棧和IP）。“單Pod單IP”網路模型為我們勾勒了一個Kubernetes扁平網路的藍圖，在這個網路世界裡：容器之間直接通訊，不需要額外的NAT（網路地址轉換）；Node與容器之間，同樣不需要額外的NAT；在其他容器和容器自身看到的IP也一樣的。扁平化網路的優點在於：沒有NAT的效能損耗，可追溯源地址進而為後面的網路策略做鋪墊，易排錯等。
總體而言，如果叢集內要訪問Pod，走Service，至於叢集外要訪問Pod，走的是Ingress。Service和Ingress是Kubernetes專門的抽象出來的和服務發現相關的概念，後面會做詳細討論。
類似於CRI之於Kubernetes的Runtime，Kubernetes使用CNI（Container Network Interface）作為Pod網路配置的標準介面。需要注意的是，CNI並不支援Docker網路，也就是說docker0網橋會被CNI的各類外掛“視而不見”。
上圖描繪了當使用者在Kubernetes裡建立了一個Pod後，CRI和CNI協同建立所有容器併為他們初始化網路棧的全過程。
具體過程如下：當用戶在Kubernetes的Master那邊建立了一個Pod後，Kubelet觀察到新Pod的建立，於是首先呼叫CRI（後面的Runtime實現，比如：dockershim，containerd等）建立Pod內的若干個容器。在這些容器裡面，第一個被建立的Pause容器是比較特殊的，這是Kubernetes系統“贈送”的容器，裡面跑著一個功能十分簡單的Go語言程式，具體邏輯是一啟動就去select一個空的Go語言channel，自然就永遠阻塞在那裡了。一個永遠阻塞而且沒有實際業務邏輯的pause容器到底有什麼用呢？用處大了。我們知道容器的隔離功能利用的是Linux核心的namespace機制，而只要是一個程序，不管這個程序是否處於執行狀態（掛起亦可），它都能“佔”著一個namespace。因此，每個Pod內的第一個系統容器Pause的作用就是為佔用一個Linux的network namespace，而Pod內其他使用者容器通過加入到這個network namespace的方式來共享同一個network namespace。使用者容器和Pause容器之間的關係有點類似於寄居蟹和海螺的關係。
因此，Container Runtime建立Pod內所有容器時，呼叫的都是同一個命令：

1. $ docker run --net=none

意思是隻建立一個network namespace，而不初始化網路協議棧。如果這個時候通過nsenter方式進入到容器，會看到裡面只有一個本地迴環裝置lo。那麼容器的eth0是怎麼創建出來的呢？答案是CNI。
CNI主要負責容器的網路裝置初始化工作。Kubelet目前支援兩個網路驅動，分別是：kubenet和CNI。
Kubenet是一個歷史產物，即將廢棄，因此這裡也不準備過多介紹。CNI有多個實現，官方自帶的外掛就有p2p，bridge等，這些外掛負責初始化Pause容器的網路裝置，也就是給eth0分配IP等，到時候Pod內其他容器就用這個IP與外界通訊。Flanne，Calico這些第三方外掛解決Pod之間的跨機通訊問題。容器之間的跨機通訊，可以通過bridge網路或overlay網路來完成。
上圖是一個bridge網路的示意圖。Node1上Pod的網段是10.1.1.0/24，接的Linux網橋是10.1.1.1，Node2上Pod的網段是10.1.2.0/24，接的Linux網橋是10.1.2.1，接在同一個網橋上的Pod通過區域網廣播通訊。我們發現，Node1上的路由表的第二條是：

1. 10.1.1.0/24 dev cni0

意思是所有目的地址是本機上Pod的網路包，都發到cni0這個Linux網橋去，進而廣播給Pod。
注意看第三條路由規則：

1. 10.1.2.0/24 via 192.168.1.101

10.1.2.0/24是Node2上Pod的網段，192.168.1.101又恰好是Node2的IP。意思是，目的地址是10.1.2.0/24的網路包，發到Node2上。
這時候我們觀察Node2上面的第二條路由資訊：

1. 10.1.2.0/24 dev cni0

就會知道這個包會被接著發給Node2上的Linux網橋cni0，然後再廣播給目標Pod。回程報文同理走一條逆向的路徑。因此，我們可以得出一個小小的結論：bridge網路本身不解決容器的跨機通訊問題，需要顯式地書寫主機路由表，對映目標容器網段和主機IP的關係，叢集內如果有N個主機，需要N-1條路由表項。
至於overlay網路，它是構建在物理網路之上的一個虛擬網路，其中VXLAN是當前最主流的overlay標準。VXLAN就是用UDP包頭封裝二層幀，即所謂的MAC in UDP。
上圖即一個典型overlay網路的拓撲圖。和bridge網路類似，Pod同樣接在Linux網橋上，目的地址是本機Pod的網路包同樣發給Linux網橋cni0。不一樣的是，目的Pod在其他節點上的路由表規則，例如：

1. 10.1.0.0/16 dev tun0

這次是直接發給本機的TAP裝置tun0，而tun0就是overlay隧道網路的入口。我們注意到，叢集內所有機器都只需要這麼一條路由表，而不需要像bridge網路那樣，寫N-1條路由表項。那如何才能將網路包正確地傳遞到目標主機的隧道口另一端呢？一般情況下，例如flannel的實現，會藉助一個分散式的資料庫，用於記錄目的容器IP與所在主機的IP的對映關係，而且每個節點上都會執行一個agent，例如flanneld，會監聽在tun0上，進行封包和解包操作。例如：Node1上的容器發包給Node2上的容器，flanneld會在tun0處將一個目的地址是192.168.1.101:8472的UDP包頭（校驗和置成0）封裝到這個包的外層，然後接著主機網路的東風順利到達Node2。監聽在Node2的tun0上的flanneld捕獲這個特殊的UDP包（檢驗和為0），知道這是一個overlay的封包，於是解開UDP包頭，將它發給本機的Linux網橋cni0，進而廣播給目的容器。
什麼是CNI
CNI是Container Network Interface的縮寫，是容器網路的標準化，試圖通過JSON來描述一個容器網路配置。
從上圖可以看出，CNI是Kubernetes與底層網路外掛之間的一個抽象層，為Kubernetes遮蔽了底層網路實現的複雜度，同時也解耦了Kubernetes的具體網路外掛實現。
CNI主要有兩類介面，分別是在建立容器時呼叫的配置網路介面：AddNetwork(net NetworkConfig, rt RuntimeConf) (types.Result,error)和刪除容器時呼叫的清理網路介面：DelNetwork(net NetworkConfig, rt RuntimeConf)。
不論是配置網路介面還是刪除網路介面，都有兩個入參，分別是網路配置和runtime配置。網路配置很好理解，Rumtime配置則主要是容器執行時傳入的網路namespace資訊。符合CNI標準的預設/第三方網路外掛有：
其中CNI-Genie是一個開源的多網路的容器解決方案，感興趣的讀者可以自行去Github上搜索。
下面我們將舉幾個CNI網路外掛的例子。
上圖是一個host-local + bridge外掛組合的例子，在這麼一個JSON檔案中，我們定義了一個名為mynet的網路，是一個bridge模型，而IP地址管理（ipam）使用的是host-local（在本地用一個檔案記錄已經分配的容器IP地址）且可供分配的容器網段是10.10.0.0/16。至於Kubernetes如何使用它們？Kubelet和CNI約好了兩個預設的檔案系統路徑，分別是/etc/cni/net.d用來儲存CNI配置檔案和/opt/cni/bin目錄用來存放CNI外掛的二進位制檔案，在我們這個例子中，至少要提前放好bridge和host-local這兩個外掛的二進位制，以及10-mynet.conf配置檔案（叫什麼名字隨意，Kubelet只解析*.conf檔案）。由於主流的網路外掛都集成了bridge外掛並提供了各自的ipam功能，因此在實際Kubernetes使用過程中我們並不需要操心上面過程，也無需做額外配置。
再來看一個最近Kubernetes V1.11版本合到社群主幹的頻寬控制外掛的使用方法。當我們書寫了以下Pod配置時：
Kubernetes就會自動為我們這個Pod分別限制上傳和下載的頻寬為最高10Mb/s。注意，由於這個特性較新，我們需要自己在/etc/cni/net.d目錄下寫一個配置檔案，例如my-net.conf：

1. {

3. "type": "bandwidth",

4. "capabilities": {"bandwidth": true}

6. }

這個配置檔案會告訴Kubelet去呼叫CNI的預設bandwidth外掛，然後根據Pod annotation裡面關於頻寬的ingress/egress值進行容器上行/下行頻寬的限制。當然，CNI外掛最後呼叫的還是Linux tc工具。
Kubernetes Service機制

容器網路模型講完後，我們再看下Kubernetes叢集內訪問的Service機制。先從一個簡單的例子講起，客戶端訪問容器應用，最簡單的方式莫過於直接容器IP+埠了。
但，簡單的生活總是暫時的。
當有多個後端例項，如何做到負載均衡？如何保持會話親和性？容器遷移，IP發生變化如何訪問？健康檢查怎麼做？怎麼通過域名訪問？
Kubernetes提供的解決方案是在客戶端和後端Pod之間引入一個抽象層：Service。什麼是Kubernetes的Service呢？
Kubernetes的Service有時候也稱為Kubernetes的微服務，代表的是Kubernetes後端服務的入口，它注意包含服務的訪問IP（虛IP）和埠，因此工作在L4。既然Service只儲存服務入口資訊，那如何關聯後端Pod呢？Service通過Label Selector選擇與之匹配的Pod。那麼被Service選中的Pod，當它們Running且Ready後，Kubernetes的Endpoints Controller會生成一個新的Endpoints物件，記錄Pod的IP和埠，這就解決了前文提到的後端例項健康檢查問題。另外，Service的訪問IP和Endpoint/Pod IP都會在Kubernetes的DNS伺服器裡儲存域名和IP的對映關係，因此使用者可以在叢集內通過域名的方式訪問Service和Pod。
Kubernetes Service的定義如下所示：
其中，spec.ClusterIP就是Service的訪問IP，俗稱虛IP，spec.ports[].port是Service的訪問埠，而與之對應的spec.ports[].targetPort是後端Pod的埠，Kubernetes內部會自動做一次對映。
Kubernetes Endpoints的定義如下所示：
其中，subsets[].addresses[].ip是後端Pod的IP，subsets[].ports是後端Pod的埠，與Service的targetPort對應。
下面我們來看下Kubernetes Service的工作原理。
如上圖所示，當用戶建立Service和對應後端Pod時，Endpoints Controller會觀察Pod的狀態變化，當Pod處於Running且Ready狀態時，Endpoints Controller會生成Endpoints物件。執行在每個節點上的Kube-proxy會觀察Service和Endpoints的更新，並呼叫其load balancer在主機上模組重新整理轉發規則。當前主流的load balancer實現有iptables和IPVS，iptables因為擴充套件性和效能不好，越來越多的廠商正開始使用IPVS模式。
Kubernetes Service有這麼幾種型別：ClusterIP，NodePort和Load Balancer。其中，ClusterIP是預設型別，自動分配叢集內部可以訪問的虛IP——Cluster IP。NodePort為Service在Kubernetes叢集的每個Node上分配一個埠，即NodePort，叢集內/外部可基於任何一個NodeIP:NodePort的形式來訪問Service。因此NodePort也成為“乞丐版”的Load Balancer，對於那些沒有打通容器網路和主機網路的使用者，NodePort成了他們從外部訪問Service的首選。LoadBalancer型別的Service需要Cloud Provider的支援，因為Service Controller會自動為之建立一個外部LB並配置安全組，Kubernetes原生支援的Cloud Provider就那麼幾個：GCE，AWS。除了“外用”，Load Balancer還可以“內服”，即如果要在叢集內訪問Load Balancer型別的Service，kube-proxy用iptables或ipvs實現了雲服務提供商LB（一般都是L7的）的部分功能：L4轉發，安全組規則等。
Kubernetes Service建立好了，那麼如何使用，即如何進行服務發現呢？Kubernetes提供了兩種方式：環境變數和域名。
環境變數即Kubelet為每個Pod注入所有Service的環境變數資訊，形如：
這種方式的缺點是：容易環境變數洪泛，Docker啟動引數過長影響效能甚至直接導致容器啟動失敗。
域名的方式是，假設Service（my-svc）在namespace（my-ns）中，暴露名為http的TCP埠，那麼在Kubernetes的DNS伺服器會生成兩種記錄，分別是A記錄：域名（my-svc.my-ns）到Cluster IP的對映和SRV記錄，例如：_http._tcp.my-svc.my-ns到一個http埠號的對映。我們會在下文Kube-dns一節做更詳細的介紹。
前文提到，Service的load balancer模組有iptables和IPVS實現。下面會一一進行分析。
Iptables是使用者空間應用程式，通過配置Netfilter規則表（ Xtables ）來構建linux核心防火牆。下面就是Kubernetes利用iptables的DNAT模組，實現了Service入口地址（10.20.30.40:80）到Pod實際地址（172.17.0.2:8080）的轉換。
IPVS是LVS的負載均衡模組，亦基於netfilter，但比iptables效能更高，具備更好的可擴充套件性。
如上所示，一旦建立一個Service和Endpoints，Kube-proxy的IPVS模式會做三樣事情：

1. 確保一塊dummy網絡卡（kube-ipvs0）存在。至於為什麼要建立dummy網絡卡，因為IPVS的netfilter鉤子掛載INPUT chain，我們需要把Service的訪問IP繫結在dummy網絡卡上讓核心“覺得”虛IP就是本機IP，進而進入到INPUT chain。

2. 把Service的訪問IP繫結在dummy網絡卡上。

3. 通過socket呼叫，建立IPVS的virtual server和real server，分別對應Kubernetes的Service和Endpoints。

好了，都說IPVS效能要好於iptables，無圖無真相，上實測資料！
通過上圖我們可以發現，IPVS重新整理規則的時延明顯要低iptables幾個數量級。
從上圖我們又可以發現，IPVS相較於iptables，端到端的吞吐率和平均時延均由不小的優化。注意，這是端到端的資料，包含了底層容器網路的RTT，還能有30%左右的效能提升。
上圖是iptables和IPVS在資源消耗方面的對比，孰優孰劣，不言而喻。
最後，問個開放性的問題。如何從叢集外訪問Kubernetes Service？
前文已經提到，可以使用NodePort型別的Service，但這種“屌絲”的做法除了要求叢集內Node有對外訪問IP外，還有一些已知的效能問題（具體請參考本公眾號另外一篇乾貨文章《 記一次Docker/Kubernetes上無法解釋的超時原因探尋之旅》）。使用LoadBalancer型別的Service？它又要求在特定的雲服務上跑Kubernetes。而且Service只提供L4負載均衡功能，而沒有L7功能，一些高階的，L7的轉發功能，比如：基於HTTP header，cookie，URL的轉發就做不了。
在Kubernetes中，L7的轉發功能，叢集外訪問Service，這些功能是專門交給Ingress的。

Kubernetes Ingress

何謂Ingress？從字面意思解讀，就是“入站流量”。Kubernetes的Ingress資源物件是指授權入站連線到達叢集內服務的規則集合。具體含義看下面這個例子便一目瞭然：
通常情況下，Service和Pod僅可在叢集內部網路中通過IP地址訪問。所有到達邊界路由的流量或被丟棄或被轉發到其他地方。Ingress就是在邊界路由處開個口子，放你進來。因此，Ingress是建立在Service之上的L7訪問入口，它支援通過URL的方式將Service暴露到Kubernetes叢集外；支援自定義Service的訪問策略；提供按域名訪問的虛擬主機功能；支援TLS通訊。
在上面這個例子，Ingress就可以基於客戶端請求的URL來做流量分發，轉發給不同的Service後端。
我們來看下Ingress資源物件的API定義：

1. apiVersion: extensions/v1beta1

2. kind: Ingress

3. metadata:

4. name: test-ingress

5. spec:

6. tls:

7. - secretName: testsecret

8. backend:

9. serviceName: testsvc

10. servicePort: 80

把上面這個Ingress物件建立起來後，kubectl get一把，會看到：

其中，ADDRESS即Ingress的訪問入口地址，由Ingress Controller分配，一般是Ingress的底層實現LB的IP地址，例如：Ingress，GCE LB，F5等；BACKEND是Ingress對接的後端Kubernetes Service IP + Port；RULE是自定義的訪問策略，主要是基於URL的轉發策略，若為空，則訪問ADDRESS的所有流量都轉發給BACKEND。
下面給出一個Ingress的rules不為空的例子。

1. apiVersion: extensions/v1beta1

2. kind: Ingress

3. metadata:

4. name: test

5. spec:

6. rules:

7. - host: foo.bar.com

8. http:

9.  paths:

10.  - path: /foo

11.    backend:

12.      serviceName: s1

13.      servicePort: 80

14.  - path: /bar

15.    backend:

16.      serviceName: s2

17.      servicePort: 80

這個例子和上面那個最明顯的區別在於，rules定義了path分別為/foo和/bar的分發規則，分別轉發給s1:80和s2:80。Kubectl get一把一目瞭然：
需要注意的是，當底層LB準備就緒時，Ingress Controller把LB的IP填充到ADDRESS欄位。而在我們的例子中，這個LB顯然還未ready。
Ingress是一個非常“極客”和需要DIY的產物，Kubernetes只負責提供一個API定義，具體的Ingress Controller需要使用者自己實現！官方倒是提供了Nginx和GCE的Ingress Controller示例供開發者參考。實現一個Ingress Controller的大致框架無非是，List/Watch Kubernetes的Service，Endpoints，Ingress物件，重新整理外部LB的規則和配置。
這還不算，如果想要通過域名訪問Ingress？需要使用者自己配置域名和Ingress IP的對映關係，比如：host檔案，自己的DNS（不是kube-dns）。下文會講到，“高冷”的kube-dns只會負責叢集內的域名解析，叢集外的一概不管。
Kubernetes DNS

Kubernetes DNS說，剛剛誰唸叨起本宮了？
一言以蔽之，Kubernetes的DNS，就是用來解析Kubernetes叢集內的Pod和Service域名的，而且一般是供Pod內的程序使用的！血統高貴，一般不給外人使用。那可能會有人好奇問一句，Pod到底怎麼使用Kubernetes DNS呢？原來，kubelet配置--cluster-dns把DNS的靜態IP傳遞給每個容器。Kubernetes DNS一般通過外掛方式部署到Kubernetes上，併為之繫結一個Service，而Service的Cluster IP往往是固定的。Kubernetes DNS目前有兩個實現，分別是kube-dns和CoreDNS。
對於Service，Kubernetes DNS伺服器會生成兩類DNS記錄，分別是：A記錄和SRV記錄。而A記錄又對普通Service和headless Service有所區別。普通Service的A記錄是：{service name}.{service namespace}.svc.cluster.local -> Cluster IP的對映關係。後面域名後面一串子域名：svc.cluster.local是Kubelet通過--cluster-domain配置的偽域名。
Headless Service的A記錄是：{service name}.{service namespace}.svc.cluster.local -> 後端Pod IP列表的對映關係。
至於SRV記錄，則是按照一個約定俗稱的規定：

1. _{port name}._{port protocol}.{service name}.{service namespace}.svc.cluster.local –> Service Port

實現了對服務埠的查詢。
對於Pod，A記錄是：

1. {pod-ip}.{pod namespace}.pod.cluster.local -> Pod IP

如果Pod IP是1.2.3.4，上面的{pod-ip}即1-2-3-4。Pod的A記錄其實沒什麼用，因為如果都知道Pod IP了，還用查DNS嗎？
如果在Pod Spec指定hostname和subdomain，那麼Kubernetes DNS會額外生成Pod的A記錄就是：

1. {hostname}.{subdomain}.{pod namespace}.pod.cluster.local –> Pod IP

同樣，後面那一串子域名pod.cluster.local是kubelet配置的偽域名。
讓我們看下kube-dns的架構吧。
如上圖所示，kube-dns是“三程序”架構。

• kubedns：List/Watch Kubernetes Service和Endpoints變化。接入SkyDNS，在記憶體中維護DNS記錄，是dnsmasq的上游。

• dnsmasq：DNS配置工具，監聽53埠，為叢集提供DNS查詢服務。提供DNS快取，降低kubedns壓力。

• exechealthz：健康檢查，檢查kube-dns和dnsmasq的健康。

需要注意的是，dnsmasq是個C++寫的一個小程式，有記憶體洩露的“老毛病”。
雖然kube-dns血統純正，而且早早地進入到Kubernetes的“後宮”，也早有“名分”，但近來CoreDNS卻獨得Kubernetes SIG Network的聖寵。CoreDNS是個DNS伺服器，原生支援Kubernetes，而且居然還是一個CNCF的專案！
與kube-dns的三程序架構不同，CoreDNS就一個程序，運維起來更加簡單。而且採用Go語言編寫，記憶體安全，高效能。值得稱道的是，CoreDNS採用的是“外掛鏈”架構，每個外掛掛載一個DNS功能，保證了功能的靈活、易擴充套件。儘管資歷不深，但卻“集萬千寵愛於一身”，自然是有兩把刷子的。
值得一提的是，以上效能測試資料是不帶cache情況下取得的，明顯要高於kube-dns。那麼為什麼建議使用CoreDNS呢？Kubernetes官方已經將CoreDNS扶正，成為了預設模式。除了效能好以外，還有什麼其他優勢嗎？CoreDNS修復了kube-dns的一些“令人討厭”的“老生常談”的問題：

• dns#55 - Allow custom DNS entries for kube-dns

• dns#116 - Missing ‘A’ records for headless service with pods sharing hostname

• dns#131 - ExternalName not using stubDomains settings

• dns#167 - Enable round robin A/AAAA records

• dns#190 - kube-dns cannot run as non-root user

• dns#232 - Use pod’s name instead of pod’s hostname in DNS SRV records

同時，還有一些吸引人的特性：

• Zone transfers - list all records, or copy records to another server

• Namespace and label filtering - expose a limited set of services

• Adjustable TTL - adjust up/down default service record TTL

  Negative Caching - By default caches negative responses (e.g. NXDOMAIN)

其中，原生支援基於namespace隔離和過濾Service和Pod的DNS記錄這一條特性，在多租戶場景下格外有用。
Network Policy

Kubernetes預設情況下，底層網路是“全連通”的。但如果我們需要實現以下願景：
即，只允許訪問default namespace的Label是app=web的Pod，default namespace的其他Pod都不允許外面訪問。這個隔離需求在多租戶的場景下十分普遍。Kubernetes的解決方案是Network Policy。
Network Policy說白了就是基於Pod源IP（所以Kubernetes網路不能隨隨便便做SNAT啊！）的訪問控制列表，限制Pod的進/出流量，用白名單實現了一個訪問控制列表（ACL）。Network Policy作為Pod網路隔離的一層抽象，允許使用Label Selector，namespace selector，埠，CIDR這四個維度限制Pod的流量進出。和Ingress一副德行的是，Kubernetes對Netowrk Policy還是隻提供了API定義，不負責實現！
一般情況下，Policy Controller是由網路外掛提供的。支援Network Policy的網路外掛有Calico，Cilium，Weave Net，Kube-router，Romana。需要注意的是，flannel不在這個名單之列，似乎又找到了一個不用flannel的理由？
讓我們先來見識幾個預設網路策略：
注：{}代表允許所有，[]代表拒絕所有。
如果要拒絕所有流量進入呢？比如，場景長這樣：
那麼Network Policy物件應該定義成：
如果要限制部分流量進入呢？比如，場景長這樣： 那麼Network Policy物件應該定義成：
如果只允許特定namespace的Pod流量進入呢？比如，場景長這樣：

相關推薦