邊緣計(jì)算集群更靠近終端設(shè)備，能提供低延時(shí)、高帶寬、高可靠、本地安全隱私保護(hù)等特性，且集群服務(wù)器以linux系統(tǒng)為主，但海量服務(wù)器的存在增加了運(yùn)維難度。
談邊緣計(jì)算網(wǎng)絡(luò)，就得先說(shuō)說(shuō)容器以及容器編排系統(tǒng)。對(duì)于單機(jī)來(lái)說(shuō)，容器技術(shù)能有效地將單個(gè)操作系統(tǒng)的資源劃分到孤立的組中，以便更好地在孤立的組之間平衡有沖突的資源使用需求。容器實(shí)際上是結(jié)合了namespace 和 cgroup 的一般內(nèi)核進(jìn)程，注意，容器就是個(gè)進(jìn)程[1,2]。Docker 是一個(gè)開源的應(yīng)用容器引擎，在工業(yè)界和學(xué)術(shù)界引起了極大關(guān)注。Docker 使用客戶端-服務(wù)器(C/S) 架構(gòu)模式，使用遠(yuǎn)程API來(lái)管理和創(chuàng)建Docker容器。Docker 容器通過 Docker 鏡像來(lái)創(chuàng)建。其架構(gòu)如下圖所示[8]：
鏡像（Image）：Docker 鏡像（Image），就相當(dāng)于是一個(gè) root 文件系統(tǒng)。
容器（Container）：鏡像（Image）和容器（Container）的關(guān)系，就像是面向?qū)ο蟪绦蛟O(shè)計(jì)中的類和實(shí)例一樣，鏡像是靜態(tài)的定義，容器是鏡像運(yùn)行時(shí)的實(shí)體。容器可以被創(chuàng)建、啟動(dòng)、停止、刪除、暫停等。
倉(cāng)庫(kù)（Repository）：倉(cāng)庫(kù)可看著一個(gè)代碼控制中心，用來(lái)保存鏡像。
后來(lái)，為了實(shí)現(xiàn)一個(gè)集群（多臺(tái)服務(wù)器）中所有容器中的應(yīng)用相互協(xié)調(diào)、共同工作，Apache Mesos、Google Kubernetes 以及 Docker Swarm 等容器編排工具應(yīng)運(yùn)而生。那么讓集群中所有容器中的應(yīng)用相互協(xié)調(diào)工作的基礎(chǔ)是什么呢？這便是邊緣計(jì)算網(wǎng)絡(luò)要解決的問題。
Kubernetes在17年就已占據(jù)77%市場(chǎng)份額[3]，而后也逐年上升。因此，主要來(lái)看看kubernetes。Kubernetes（k8s）是自動(dòng)化容器操作的開源平臺(tái)，這些操作包括部署，調(diào)度和節(jié)點(diǎn)集群間擴(kuò)展。其架構(gòu)組件較多，不一一贅述，讀者可自行查閱。這里著重提一下Pod。Pod是kubernetes中可以被創(chuàng)建、銷毀、調(diào)度的最小單元，其中包含pause容器，以及一個(gè)或一組應(yīng)用容器。如下圖所示，一臺(tái)主機(jī)節(jié)點(diǎn)可以創(chuàng)建多個(gè)Pod，每個(gè)Pod中能容納多個(gè)容器，但都會(huì)在最初創(chuàng)建pause容器，其他容器與pause容器共享net、ipc、pid等資源。網(wǎng)絡(luò)模型也是基于docker的網(wǎng)絡(luò)模型創(chuàng)建和使用的。
Docker原生的跨主機(jī)網(wǎng)絡(luò)模型有overlay，macvlan。macvlan 本身是 linxu kernel 模塊，其功能是允許在同一個(gè)物理網(wǎng)卡上配置多個(gè) MAC 地址，即多個(gè) interface，每個(gè) interface 可以配置自己的 IP。macvlan本質(zhì)上是一種網(wǎng)卡虛擬化技術(shù)。macvlan 的最大優(yōu)點(diǎn)是性能極好，相比其他實(shí)現(xiàn)，macvlan 不需要?jiǎng)?chuàng)建 Linux bridge，而是直接通過以太 interface 連接到物理網(wǎng)絡(luò)[4]。但macvlan大大增加了路由的復(fù)雜度，為了避免對(duì)主機(jī)路由的干擾，常常使用overlay網(wǎng)絡(luò)模型[5]。
Kubernetes可以看做是一個(gè)大型的docker容器編排系統(tǒng)，他的CNI(Container NetworkInterface)也遵循docker的原生網(wǎng)絡(luò)模型。目前kubernetes CNI有非常多的選擇，如：Flannel、Calico、Canal、Weave、Kube-router[7]和Antrea。
Flannel: 最成熟、最簡(jiǎn)單的選擇
Calico: 性能好、靈活性最強(qiáng)，目前的企業(yè)級(jí)主流
Canal: 將Flannel提供的網(wǎng)絡(luò)層與Calico的網(wǎng)絡(luò)策略功能集成在一起。
Weave: 獨(dú)有的功能，是對(duì)整個(gè)網(wǎng)絡(luò)的簡(jiǎn)單加密，會(huì)增加網(wǎng)絡(luò)開銷
Kube-router: kube-router采用lvs實(shí)現(xiàn)svc網(wǎng)絡(luò),采用bgp實(shí)現(xiàn)pod網(wǎng)絡(luò)。
Antrea支持多種網(wǎng)絡(luò)模型（Overlayand non-overlay modes），可以使用VXLAN、Geneve、GRE或STT作為封裝協(xié)議[6]。
2019年計(jì)算機(jī)網(wǎng)絡(luò)方向頂級(jí)會(huì)議NSDI中一篇paper（Slim）吸引了筆者注意。它的motivation是原始o(jì)verlay網(wǎng)絡(luò)每個(gè)包在跨主機(jī)間通信的過程中，會(huì)遍歷兩次系統(tǒng)內(nèi)核網(wǎng)絡(luò)棧（如Figure 2），而Slim的做法是利用SlimRouter和SlimSocket來(lái)改造通信過程，讓每個(gè)包在跨主機(jī)通信時(shí)僅僅遍歷一次網(wǎng)絡(luò)棧（如Figure 4）。從而提升吞吐，降低CPU占用。
筆者親測(cè)了借助Slim在跨主機(jī)docker里的服務(wù)間通信，能讓TCP的bandwidth提升到主機(jī)間通信的極限，并且可以在Antrea這種CNI中直接使用。猜想一下，overlay模式下的其他CNI可能也可以借助Slim的思想或方法使TCP的bandwidth提升到主機(jī)間通信的極限。
以小見大，延伸到整個(gè)kubernetes網(wǎng)絡(luò)世界，筆者認(rèn)為，雖然因歷史原因，已經(jīng)有很多CNI共存于市場(chǎng)，但如果某種CNI能在不同網(wǎng)絡(luò)模型下都將性能提升到極致，并且更加方便用戶直接使用的同時(shí)留出接口，提供二次開發(fā)的可能，那么有可能如同kubernetes一樣良性循環(huán)，有望實(shí)現(xiàn)大一統(tǒng)。
作者：曹培睿，上海交通大學(xué)。
參考文獻(xiàn)：
[1]https://www.cnblogs.com/shuiguizi/p/10922049.html
[2]https://coolshell.cn/articles/17010.html
[3]https://www.kubernetes.org.cn/3241.html
[4]https://blog.csdn.net/wfs1994/article/details/80659232
[5] Zhuo D, Zhang K, Zhu Y, et al. Slim: OSKernel Support for a Low-Overhead Container Overlay Network[C]. networkedsystems design and implementation, 2019: 331-344.
[6]https://github.com/vmware-tanzu/antrea
[7]https://www.jianshu.com/p/d9330360fc8c
[8]https://www.runoob.com/docker/docker-architecture.html
