與傳統(tǒng)的虛擬化相比，Kubernetes容器的生命周期更短、數(shù)量密度更高、集群變更速度更快。容器網(wǎng)絡就必須對集群節(jié)點之間的高速通信進行充分的考量。除此之外，在企業(yè)級的容器云平臺上，承載眾多租戶的計算負載之間資源的安全隔離，也必須要考慮到的因素。

顯而易見，傳統(tǒng)的物理網(wǎng)絡架構無法滿足容器高靈活性的需求，容器網(wǎng)絡必須要有一種嶄新的設計架構。Kubernetes快速發(fā)展演進，其中網(wǎng)絡這塊發(fā)展變革最快，生態(tài)最繁榮。

容器網(wǎng)絡的發(fā)展，從Docker主導的CNM模型，演進到Google、CoreOS、Kubernetes主導的CNI模型。CNM與CNI并不是網(wǎng)絡的實現(xiàn)，而是網(wǎng)絡規(guī)范和網(wǎng)絡體系。當前，容器網(wǎng)絡CNI基本是事實的標準，除了背后開源社區(qū)的陣營不同，更多是技術迭代演進，架構優(yōu)化調(diào)整。與Kubernetes在最新版本開始解耦Docker一樣。下圖是容器網(wǎng)絡發(fā)展脈絡，從運行效率與管理效率兩個方面推動容器持續(xù)迭代優(yōu)化。

1、單節(jié)點容器網(wǎng)絡

容器單節(jié)點網(wǎng)絡,在單個容器主機，通過Bridge或者Macvlan等方式實現(xiàn)共享宿主機物理網(wǎng)卡，多個容器使用“端口映射”的方式共享容器主機IP地址。存在問題是如何進行大規(guī)模管理，容器間跨主機無需經(jīng)過NAT無法直接通信。如下圖所示：

2、Kubernetes Flannel網(wǎng)絡

Kubernetes Flannel網(wǎng)絡，實現(xiàn)容器主機集群和跨節(jié)點Pod直連，每個容器主機分配一個網(wǎng)段用于容器內(nèi)Pod互聯(lián)。通過VxLAN協(xié)議封裝實現(xiàn)Overlay容器網(wǎng)絡，容器IP在物理網(wǎng)絡上傳輸時使用物理機IP，其真實IP會被封裝在VxLAN協(xié)議中。每個機器上有一個flanneld服務進行外部網(wǎng)絡通信時的封包和解包。存在問題是雖然大二層帶來了連通的便利，但是管控、訪問控制、租戶隔離沒有實現(xiàn)，如下圖所示：

3、多租戶 + NetworkPolicy容器網(wǎng)絡

多租戶 + NetworkPolicy容器網(wǎng)絡，Openshift v3 OVS網(wǎng)絡就是基于這個思路已經(jīng)實現(xiàn)。通過VxLAN實現(xiàn)跨集群互通，使用可編程OVS流表控制每個節(jié)點上的容器流量轉(zhuǎn)發(fā)控制，多租戶之間的網(wǎng)絡NetworkPolicy控制，基于Namespace級別控制，基于Pod、端口的控制。存在問題是OVS和流表依然是單機，大量的流程編程工作，SVC和LB暴露依賴iptables，性能開銷較大，如下圖所示。

4、SDN容器網(wǎng)絡

SDN容器網(wǎng)絡，隨著技術快速的發(fā)展，尤其是近幾年大型國企數(shù)字化轉(zhuǎn)型加速，各種各樣的應用容器化運行之后，OVS容器網(wǎng)絡的局限性開始突顯。首先就是統(tǒng)一控制平面效率不高。其次是OVS借助每個節(jié)點上iptables實現(xiàn)，iptables實現(xiàn)NAT時性能開銷大，同時Kubernetes Service管理復雜。最后是IPv6與Windows等新需求難以支持。

OVN是從OVS發(fā)展演進而來，是openvSwitch原生控制層實現(xiàn)，用于將分布式的openvSwitch交換機統(tǒng)一管理。OVN是集中式SDN控制器，實現(xiàn)集群層面做網(wǎng)絡編排，管理組件高可用，使用OpenFlow控制協(xié)議，利用OVS實現(xiàn)網(wǎng)絡轉(zhuǎn)發(fā)。

5、總結

OVN雖然很多功能(LB，Gateway，DNS, DHCP)依然使用OVS進行底層流量轉(zhuǎn)發(fā),但是大幅度提升了上層應用(Openstack、Kubernetes、Openshift)的管理能力。與其他的kubernetes CNI網(wǎng)絡插件相比，OVN是真正的SDN!

本文轉(zhuǎn)載自微信公眾號「巨子嘉」，可以通過以下二維碼關注。轉(zhuǎn)載本文請聯(lián)系巨子嘉公眾號。