淺析Kubernetes網絡模型
通過我們對各種容器網絡模型的實現原理已經有了基本的認識，然而真正將容器技術發揚光大的是Kubernetes容器編排平臺。Kubernetes通過整合規模龐大的容器實例形成集群，這些容器實例可能運行在異構的底層網絡環境中，如何保證這些容器間的互通是實際生產環境中首要考慮的問題之一。
Kubernetes網絡基本要求
Kubernetes對容器技術做了更多的抽象，其中最重要的一點是提出pod的概念，pod是Kubernetes資源調度的基本單元，我們可以簡單地認為pod是容器的一種延伸擴展，從網絡的角度來看，pod必須滿足以下條件：
- 每一個Pod都有一個獨特的IP地址，所有pod都在一個可以直接連通的、扁平的網絡空間中
- 同一個pod內的所有容器共享同一個netns網絡命名空間
基于這樣的基本要求，我們可以知道：
- 同一個pod內的所有容器之間共享端口，可直接通過localhost+端口來訪問
- 由于每個pod有單獨的IP，所以不需要考慮容器端口與主機端口映射以及端口沖突問題
事實上，Kubernetes進一步確定了對一個合格集群網絡的基本要求：
- 任意兩個pod之間其實是可以直接通信的，無需顯式地使用NAT進行地址的轉換;
- 任意集群節點node與任意pod之間是可以直接通信的，無需使用明顯的地址轉換，反之亦然;
- 任意pod看到自己的IP跟別人看見它所用的IP是一樣的，中間不能經過地址轉換;
也就是說，必須同時滿足以上三點的網絡模型才能適用于kubernetes，事實上，在早期的Kubernetes中，并沒有什么網絡標準，只是提出了以上基本要求，只有滿足這些要求的網絡才可以部署Kubernetes，基于這樣的底層網絡假設，Kubernetes設計了pod-deployment-service的經典三層服務訪問機制。直到1.1發布，Kubernetes才開始采用全新的CNI(Container Network Interface)網絡標準。
CNI
其實，我們在前面介紹容器網絡的時候，就提到了CNI網絡規范，CNI相對于CNM(Container Network Model)對開發者的約束更少，更開放，不依賴于Docker。事實上，CNI規范確實非常簡單，詳見：https://github.com/containernetworking/cni/blob/master/SPEC.md
實現一個CNI網絡插件只需要一個配置文件和一個可執行的文件：
- 配置文件描述插件的版本、名稱、描述等基本信息
- 可執行文件會被上層的容器管理平臺調用，一個CNI可執行文件自需要實現將容器加入到網絡的ADD操作以及將容器從網絡中刪除的DEL操作(以及一個可選的VERSION查看版本操作)
Kubernetes使用CNI網絡插件的基本工作流程：
- kubelet先創建pause容器生成對應的netns網絡命名空間
- 根據配置調用具體的CNI插件，可以配置成CNI插件鏈來進行鏈式調用
- 當CNI插件被調用時，它根據環境變量以及命令行參數來獲得網絡命名空間netns、容器的網絡設備等必要信息，然后執行ADD操作
- CNI插件給pause容器配置正確的網絡，pod中其他的容器都是用pause容器的網絡
如果不清楚什么是pause容器，它在pod中處于什么樣的位置，請查看之前的筆記：https://morven.life/notes/from-container-to-pod/
pod網絡模型
要了解kubernetes網絡模型的實現原理，我們就要從單個pod入手，事實上，一旦熟悉了單個pod的網絡模型，就會發現kubernetes網絡模型基本遵循和容器網絡模型一樣的原理。
通過前面的筆記從docker容器到pod，我們知道pod啟動的時候先創建pause容器生成對應的netns網絡命名空間，然后其他容器共享pause容器創建的網絡命名空間。而對于單個容器的網絡模型我們之前也介紹過，主要就是通過docker0網橋設備與veth設備對連接不同的容器網絡命名空間，由此，我們可以得到如下圖所示的單個pod網絡模型的創建過程：
可以看到，同一個pod里面的其他容器共享pause容器創建的網絡命名空間，也就是說，所有的容器共享相同的網絡設備，路由表設置，服務端口等信息，仿佛是在同一臺機器上運行的不同進程，所以這些容器之間可以直接通過localhost與對應的端口通信;對于集群外部的請求，則通過docker0網橋設備充當的網關，同時通過iptables做地址轉換。我們會發現，這其實就是對當個容器的bridge網絡模型的擴展。
主流kubernetes網絡方案
上一小節我們知道單個pod的網絡模型是容器網絡模型的擴展，但是pod與pod之間的是怎么相互通信的呢?這其實與容器之間相互通信非常類似，也分為同一個主機上的pod之間與跨主機的pod之間兩種。
如容器網絡模型一樣，對于統一主機上的pod之間，通過docker0網橋設備直接二層(數據鏈路層)網絡上通過MAC地址直接通信：
而跨主機的pod之間的相互通信也主要有以下兩個思路：
- 修改底層網絡設備配置，加入容器網絡IP地址的管理，修改路由器網關等，該方式主要和SDN(Software define networking)結合。
- 完全不修改底層網絡設備配置，復用原有的underlay平面網絡，解決容器跨主機通信，主要有如下兩種方式:隧道傳輸(Overlay)： 將容器的數據包封裝到原主機網絡的三層或者四層數據包中，然后使用主機網絡的IP或者TCP/UDP傳輸到目標主機，目標主機拆包后再轉發給目標容器。Overlay隧道傳輸常見方案包括Vxlan、ipip等，目前使用Overlay隧道傳輸技術的主流容器網絡有Flannel等;
修改主機路由：把容器網絡加到主機路由表中，把主機網絡設備當作容器網關，通過路由規則轉發到指定的主機，實現容器的三層互通。目前通過路由技術實現容器跨主機通信的網絡如Flannel host-gw、Calico等;
下面簡單介紹幾種主流的方案：
- Flannel是目前使用最為普遍的方案，提供了多種網絡backend，它支持多種數據路徑，也適合于overlay/underlay等多種場景。對于overlay的數據包封裝，可以使用用戶態的UDP，內核態的Vxlan(性能相對較好)，甚至在集群規模不大，且處于同一個二層域時可以采用host-gw的方式修改主機路由表;
- Weave工作模式與Flannel很相似的，它最早只提供了UDP(稱為sleeve模式)的網絡方式，后來又加上了fastpass方式(基于VxLAN)，不過Weave消除了Flannel中用來存儲網絡地址的額外組件，自己集成了高可用的數據存儲功能;
- Calico主要是采用了修改主機路由，節點之間采用BGP的協議去進行路由的同步。但是現實中的網絡并不總是支持BGP路由的，因此Calico也支持內核中的IPIP模式，使用overlay的方式來傳輸數據;
下表是幾種主流Kubernetes網絡方案的對比：
- | A | Overlay-Network | Host-RouteTable | NetworkPolicy Support | Decentralized IP Allocation | | – | — | — | — | — | | Flannel | UDP/VXLAN | Host-GW | N | N | | Weave | UDP/VXLAN | N/A | Y | Y | | Calico | IPIP | BGP | Y | N |
策略控制(Network Policy)
Network Policy)是Kubernetes提供的基于策略的網絡控制，用于隔離應用并提高安全性。它使用Kubernetes中常用的標簽選擇器模擬傳統的分段網絡，并通過策略控制它們之間的東西流量以及與外部交流的南北流量。
- Note: 確保使用的網絡插件支持策略控制(Network Policy)，比如Flannel就沒有實現Network Policy;
下面的例子是配置一個典型的Network Policy的實例：
- apiVersion: networking.k8s.io/v1
- kind: NetworkPolicy
- metadata:
- name: test-network-policy
- namespace: default
- spec:
- podSelector:
- matchLabels:
- role: db
- policyTypes:
- - Ingress - Egress ingress:
- - from:
- - ipBlock:
- cidr: 172.17.0.0/16
- except:
- - 172.17.1.0/24
- - namespaceSelector:
- matchLabels:
- project: myproject
- - podSelector:
- matchLabels:
- role: frontend
- ports:
- - protocol: TCP
- port: 6379
- egress:
- - to:
- - ipBlock:
- cidr: 10.0.0.0/24
- ports:
- - protocol: TCP
- port: 5978
它使用標簽選擇器namespaceSelector與posSelector控制pod之間的流量，流量的行為模式主要由以下三個對象決定：
- 控制對象：通過spec.podSelector篩選
- 流量方向：ingress控制入pod流量，egress控制出pod流量
- 流量特征：對端-IP-協議-端口
通過使用Network Policy可以實現對進出流的精確控制，它采用各種選擇器(標簽或namespace)，找到一組滿足條件的pod，或者找到相當于通信的兩端，然后通過流量的特征描述來決定它們之間是不是可以連通，可以理解為一個白名單的機制。
