k8s網絡主題系列：
K8s網絡設計與實現是在學習k8s網絡過程中總結的內容。在學習k8s網絡各種插件之前我覺得有必要先搞清楚其設計思路是怎樣的，在知道其規范的情況下肯定能跟深刻理解k8s網絡的各種插件。就像擁有指南針的船，才不會跑偏。
一、K8s網絡設計
1.每個Pod都擁有一個獨立IP地址，Pod內所有容器共享一個網絡命名空間
2.集群內所有Pod都在一個直接連通的扁平網絡中，可通過IP直接訪問
(1) 所有容器之間無需NAT就可以直接互相訪問
(2) 所有Node和所有容器之間無需NAT就可以直接互相訪問
(3) 容器自己看到的IP跟其他容器看到的一樣
二、K8s網絡要求
K8s對網絡的要求總的來講主要有兩個最基本的要求，分別是：
- 要能夠為每一個Node上的Pod分配互相不沖突的IP地址；
- 要所有Pod之間能夠互相訪問；
三、K8s網絡規范
CNI是由CoreOS提出的一個容器網絡規范。已采納規范的包括Apache Mesos, Cloud Foundry, Kubernetes, Kurma 和 rkt。另外 Contiv Networking, Project Calico 和 Weave這些項目也為CNI提供插件。
CNI 的規范比較小巧。它規定了一個容器runtime和網絡插件之間的簡單的契約。這個契約通過JSON的語法定義了CNI插件所需要提供的輸入和輸出。一個容器可以被加入到被不同插件所驅動的多個網絡之中。一個網絡有自己對應的插件和唯一的名稱。CNI 插件需要提供兩個命令：一個用來將網絡接口加入到指定網絡，另一個用來將其移除。這兩個接口分別在容器被創建和銷毀的時候被調用。
容器runtime首先需要分配一個網絡命名空間以及一個容器ID。然后連同一些CNI配置參數傳給網絡驅動。接着網絡驅動會將該容器連接到網絡並將分配的IP地址以JSON的格式返回給容器runtime。
四、K8s網絡實現
隧道方案
隧道方案在IaaS層的網絡中應用也比較多，將pod分布在一個大二層的網絡規模下。網絡拓撲簡單，但隨着節點規模的增長復雜度會提升。
Weave：UDP廣播，本機建立新的BR，通過PCAP互通
Open vSwitch（OVS）：基於VxLan和GRE協議，但是性能方面損失比較嚴重
Flannel：UDP廣播，VxLan
Racher：IPsec
路由方案
路由方案一般是從3層或者2層實現隔離和跨主機容器互通的，出了問題也很容易排查。
Calico：基於BGP協議的路由方案，支持很細致的ACL控制，對混合雲親和度比較高。
Macvlan：從邏輯和Kernel層來看隔離性和性能最優的方案，基於二層隔離，所以需要二層路由器支持，大多數雲服務商不支持，所以混合雲上比較難以實現。
五、K8s Pod的網絡創建流程
1.每個Pod除了創建時指定的容器外，都有一個kubelet啟動時指定的基礎容器
2.kubelet創建基礎容器，生成network namespace
3.kubelet調用網絡CNI driver，由它根據配置調用具體的CNI 插件
4.CNI 插件給基礎容器配置網絡
5.Pod 中其他的容器共享使用基礎容器的網絡
以上內容主要來自博客文章。