如果本文對你有幫助，歡迎關注、點贊、收藏、轉發給朋友，讓我有持續創作的動力
Overview
本文將探討kube.NETes中的網絡模型，以及對各種網絡模型進行分析。
Underlay Network Model
什么是Underlay Network
底層網絡 Underlay Network 顧名思義是指網絡設備基礎設施，如交換機，路由器, DWDM 使用網絡介質將其鏈接成的物理網絡拓撲，負責網絡之間的數據包傳輸。
圖：Underlay network topology
underlay network 可以是二層，也可以是三層；二層 underlay network 的典型例子是以太網 Ethernet，三層是 underlay network 的典型例子是互聯網 Internet。
而工作與二層的技術是 vlan，工作在三層的技術是由OSPF, BGP等協議組成
kubernetes中的underlay network
在kubernetes中，underlay network 中比較典型的例子是通過將宿主機作為路由器設備，Pod 的網絡則通過學習成路由條目從而實現跨節點通訊。
圖：underlay network topology in kubernetes
這種模型下典型的有 flannel 的 host-gw 模式與 calico BGP 模式。
flannel host-gw
flannel host-gw 模式中每個Node需要在同一個二層網絡中，并將Node作為一個路由器，跨節點通訊將通過路由表方式進行，這樣方式下將網絡模擬成一個underlay network。
圖：layer2 ethernet topology
Notes：因為是通過路由方式，集群的cidr至少要配置16，因為這樣可以保證，跨節點的Node作為一層網絡，同節點的Pod作為一個網絡。如果不是這種用情況，路由表處于相同的網絡中，會存在網絡不可達
Calico BGP
BGP（Border Gateway Protocol）是去中心化自治路由協議。它是通過維護IP路由表或'前綴'表來實現AS （Autonomous System）之間的可訪問性，屬于向量路由協議。
圖：BGP network topology
與 flannel 不同的是，Calico 提供了的 BGP 網絡解決方案，在網絡模型上，Calico 與 Flannel host-gw 是近似的，但在軟件架構的實現上，flannel 使用 flanneld 進程來維護路由信息；而 Calico 是包含多個守護進程的，其中 Brid 進程是一個 BGP 的客戶端 與路由反射器(Router Reflector)，BGP 客戶端負責從 Felix 中獲取路由并分發到其他 BGP Peer，而反射器在BGP中起了優化的作用。在同一個IBGP中，BGP客戶端僅需要和一個 RR 相連，這樣減少了AS內部維護的大量的BGP連接。通常情況下，RR 是真實的路由設備，而 Bird 作為 BGP 客戶端工作。
圖：Calico Network Architecture
IPVLAN & macVLAN
IPVLAN 和 MACVLAN 是一種網卡虛擬化技術，兩者之間的區別為， IPVLAN 允許一個物理網卡擁有多個IP地址，并且所有的虛擬接口用同一個MAC地址；而 MACVLAN 則是相反的，其允許同一個網卡擁有多個MAC地址，而虛擬出的網卡可以沒有IP地址。
因為是網卡虛擬化技術，而不是網絡虛擬化技術，本質上來說屬于 Overlay network，這種方式在虛擬化環境中與Overlay network 相比最大的特點就是可以將Pod的網絡拉平到Node網絡同級，從而提供更高的性能、低延遲的網絡接口。本質上來說其網絡模型屬于下圖中第二個。
- 虛擬網橋：創建一個虛擬網卡對(veth pair)，一頭栽容器內，一頭栽宿主機的root namespaces內。這樣一來容器內發出的數據包可以通過網橋直接進入宿主機網絡棧，而發往容器的數據包也可以經過網橋進入容器。
- 多路復用：使用一個中間網絡設備，暴露多個虛擬網卡接口，容器網卡都可以介入這個中間設備，并通過MAC/IP地址來區分packet應該發往哪個容器設備。
硬件交換，為每個Pod分配一個虛擬網卡，這樣一來，Pod與Pod之間的連接關系就會變得非常清晰，因為近乎物理機之間的通信基礎。如今大多數網卡都支持SR-IOV功能，該功能將單一的物理網卡虛擬成多個VF接口，每個VF接口都有單獨的虛擬PCIe通道，這些虛擬的PCIe通道共用物理網卡的PCIe通道。
圖：Virtual networking modes: bridging, multiplexing and SR-IOV
在kubernetes中 IPVLAN 這種網絡模型下典型的CNI有，multus 與 danm。
multus
multus 是 intel 開源的CNI方案，是由傳統的 cni 與 multus 組成，并且提供了 SR-IOV CNI 插件使 K8s pod 能夠連接到 SR-IOV VF 。這是使用了 IPVLAN/MACVLAN 的功能。
當創建新的Pod后，SR-IOV 插件開始工作。配置 VF 將被移動到新的 CNI 名稱空間。該插件根據 CNI 配置文件中的 “name” 選項設置接口名稱。最后將VF狀態設置為UP。
下圖是一個 Multus 和 SR-IOV CNI 插件的網絡環境，具有三個接口的 pod。
- eth0 是 flannel 網絡插件，也是作為Pod的默認網絡
- VF 是主機的物理端口 ens2f0 的實例化。這是英特爾X710-DA4上的一個端口。在Pod端的 VF 接口名稱為 south0 。
- 這個VF使用了 DPDK 驅動程序，此 VF 是從主機的物理端口 ens2f1 實例化出的。這個是英特爾® X710-DA4上另外一個端口。Pod 內的 VF 接口名稱為 north0。該接口綁定到 DPDK 驅動程序 vfio-pci。
圖：Mutus networking Architecture overlay and SR-IOV
Notes：terminology NIC：network interface card，網卡SR-IOV：single root I/O virtualization，硬件實現的功能，允許各虛擬機間共享PCIe設備。VF：Virtual Function，基于PF，與PF或者其他VF共享一個物理資源。PF：PCIe Physical Function，擁有完全控制PCIe資源的能力DPDK：Data Plane Development Kit
于此同時，也可以將主機接口直接移動到Pod的網絡名稱空間，當然這個接口是必須存在，并且不能是與默認網絡使用同一個接口。這種情況下，在普通網卡的環境中，就直接將Pod網絡與Node網絡處于同一個平面內了。
圖：Mutus networking Architecture overlay and ipvlan
danm
DANM是諾基亞開源的CNI項目，目的是將電信級網絡引入kubernetes中，與multus相同的是，也提供了SR-IOV/DPDK 的硬件技術，并且支持IPVLAN.
Overlay Network Model
什么是Overlay
疊加網絡是使用網絡虛擬化技術，在 underlay 網絡上構建出的虛擬邏輯網絡，而無需對物理網絡架構進行更改。本質上來說，overlay network 使用的是一種或多種隧道協議 (tunneling)，通過將數據包封裝，實現一個網絡到另一個網絡中的傳輸，具體來說隧道協議關注的是數據包（幀）。
圖：overlay network topology
常見的網絡隧道技術
- 通用路由封裝 ( Generic Routing Encapsulation ) 用于將來自 IPv4/IPv6的數據包封裝為另一個協議的數據包中，通常工作與L3網絡層中。
- VxLAN (Virtual Extensible LAN)，是一個簡單的隧道協議，本質上是將L2的以太網幀封裝為L4中UDP數據包的方法，使用 4789 作為默認端口。VxLAN 也是 VLAN 的擴展對于 4096（ 位 VLAN ID） 擴展為1600萬（ 位 VNID ）個邏輯網絡。
這種工作在 overlay 模型下典型的有 flannel 與 calico 中的的 VxLAN, IPIP 模式。
IPIP
IP in IP 也是一種隧道協議，與 VxLAN 類似的是，IPIP 的實現也是通過linux內核功能進行的封裝。IPIP 需要內核模塊 ipip.ko 使用命令查看內核是否加載IPIP模塊lsmod | grep ipip ；使用命令modprobe ipip 加載。
圖：A simple IPIP network workflow
Kubernetes中 IPIP 與 VxLAN 類似，也是通過網絡隧道技術實現的。與 VxLAN 差別就是，VxLAN 本質上是一個 UDP包，而 IPIP 則是將包封裝在本身的報文包上。
圖：IPIP in kubernetes
圖：IPIP packet with wireshark unpack
Notes：公有云可能不允許IPIP流量，例如Azure
VxLAN
kubernetes中不管是 flannel 還是 calico VxLAN的實現都是使用Linux內核功能進行的封裝，Linux 對 vxlan 協議的支持時間并不久，2012 年 Stephen Hemminger 才把相關的工作合并到 kernel 中，并最終出現在 kernel 3.7.0 版本。為了穩定性和很多的功能，你可以會看到某些軟件推薦在 3.9.0 或者 3.10.0 以后版本的 kernel 上使用 VxLAN。
圖：A simple VxLAN network topology
在kubernetes中vxlan網絡，例如 flannel，守護進程會根據kubernetes的Node而維護 VxLAN，名稱為 flannel.1 這是 VNID，并維護這個網絡的路由，當發生跨節點的流量時，本地會維護對端 VxLAN 設備的MAC地址，通過這個地址可以知道發送的目的端，這樣就可以封包發送到對端，收到包的對端 VxLAN設備 flannel.1 解包后得到真實的目的地址。
查看 Forwarding database 列表
$ bridge fdb 26:5e:87:90:91:fc dev flannel.1 dst 10.0.0.3 self permanent
圖：VxLAN in kubernetes
圖：VxLAN packet with wireshark unpack
Notes：VxLAN使用的4789端口，wireshark應該是根據端口進行分析協議的，而flannel在linux中默認端口是8472，此時抓包僅能看到是一個UDP包。
通過上述的架構可以看出，隧道實際上是一個抽象的概念，并不是建立的真實的兩端的隧道，而是通過將數據包封裝成另一個數據包，通過物理設備傳輸后，經由相同的設備（網絡隧道）進行解包實現網絡的疊加。
weave vxlan
weave也是使用了 VxLAN 技術完成的包的封裝，這個技術在 weave 中稱之為 fastdp (fast data path)，與 calico 和 flannel 中用到的技術不同的，這里使用的是 Linux 內核中的 openvswitch datapath module，并且weave對網絡流量進行了加密。
圖：weave fastdp network topology
