ECS容器網(wǎng)絡(luò)最佳實(shí)踐-多網(wǎng)卡方案

摘要：?容器是相比于虛擬機(jī)(Virtual Machine，VM)更輕便，部署更方便快捷的一種虛擬化技術(shù)。 Docker是目前主流的容器引擎，支持Linux，Windows等多種平臺，同時支持Kubernetes(K8S), Swarm及Rocket(RKT)等主流Docker編排系統(tǒng)。

概述

容器是相比于虛擬機(jī)(Virtual Machine，VM)更輕便，部署更方便快捷的一種虛擬化技術(shù)。 Docker是目前主流的容器引擎，支持Linux，Windows等多種平臺，同時支持Kubernetes(K8S), Swarm及Rocket(RKT)等主流Docker編排系統(tǒng)。常見的容器網(wǎng)絡(luò)支持Bridge，Overlay，Host及用戶自定義網(wǎng)絡(luò)等多種模型，K8S等系統(tǒng)依賴于容器網(wǎng)絡(luò)接口(Container Network Interface, CNI)插件來完成網(wǎng)絡(luò)管理，常見的有Calico/Flannel等知名CNI插件。本文將介紹一些容器網(wǎng)絡(luò)的基本知識，基于阿里云的彈性網(wǎng)絡(luò)接口（Elastic Network Interface， ENI）技術(shù)實(shí)現(xiàn)了ECS容器網(wǎng)絡(luò)的高性能，易部署及維護(hù)， 具有強(qiáng)隔離的高安全容器網(wǎng)絡(luò)。

多網(wǎng)卡容器網(wǎng)絡(luò)

當(dāng)VM擁有多張網(wǎng)絡(luò)接口卡（Network Interface Card, NIC），而且這些NIC是能夠動態(tài)熱插拔時，NIC就能夠用于容器網(wǎng)絡(luò)， 這樣容器網(wǎng)絡(luò)將不再需要利用Linux VETH及Bridge等技術(shù)，同時報文轉(zhuǎn)發(fā)下移到了位于宿主機(jī)上的虛擬交換機(jī)(Virtual Switch，vSwitch)，通過減少流程提升網(wǎng)絡(luò)性能。

方案介紹

如下圖所示，在宿主機(jī)上運(yùn)行有vSwitch，用于轉(zhuǎn)發(fā)VM及容器的流量， 在vSwitch上連接有多張?zhí)摂MNIC。在VM內(nèi)啟動容器時，在宿主機(jī)上動態(tài)地將虛擬NIC綁定容器所在的VM，然后在VM內(nèi)部將NIC綁定到容器所在的網(wǎng)絡(luò)命名空間，容器內(nèi)的網(wǎng)絡(luò)流量能夠直接通過這塊NIC直接發(fā)送到位于宿主機(jī)上的vSwitch（容器網(wǎng)絡(luò)直通vSwitch）， vSwith內(nèi)應(yīng)用ACL/QoS/Session等規(guī)則過后將流量進(jìn)行轉(zhuǎn)發(fā)。當(dāng)位于宿主機(jī)1上的VM內(nèi)運(yùn)行的容器訪問位于宿主機(jī)2上的VM內(nèi)運(yùn)行的容器時，流量大致會經(jīng)歷如下流程：

?

1>??網(wǎng)絡(luò)報文經(jīng)過容器內(nèi)核網(wǎng)絡(luò)協(xié)議棧，查找路由后通過eth0網(wǎng)卡發(fā)送報文；

2>? 宿主機(jī)上的vSwitch從虛擬端口收到來自容器的報文，運(yùn)行vSwitch的轉(zhuǎn)發(fā)邏輯，將報文通過物理網(wǎng)絡(luò)端口發(fā)送到ToR交換機(jī) (Top of Rack Switch, ToR Switch)，如果針對容器或者虛擬機(jī)網(wǎng)絡(luò)建立了虛擬私有云 (Virtual Private Cloud， VPC）則需要對報文使用VxLAN等隧道技術(shù)進(jìn)行封裝；

3>??ToR Switch通過查詢路由信息，通過連接宿主機(jī)2的物理端口將報文轉(zhuǎn)發(fā)；

4>??位于宿主機(jī)2上的vSwitch接收物理端口報文，經(jīng)轉(zhuǎn)發(fā)邏輯發(fā)送到連接容器的虛擬端口；

5>??容器內(nèi)協(xié)議棧eth0收到由另一端發(fā)送來的報文，由容器內(nèi)網(wǎng)絡(luò)協(xié)議棧進(jìn)行處理。

方案特點(diǎn)

與傳統(tǒng)的在VM內(nèi)運(yùn)行容器的方案對比，本方案具有高性能，易管理及強(qiáng)隔離等特點(diǎn)。

VPC直通

讓容器通過多網(wǎng)卡直通的方案，直接接入VPC網(wǎng)絡(luò)平面，能讓每個容器具備全量的VPC網(wǎng)絡(luò)功能，包括：EIP、SLB、高防、安全組、HAVIP、NAT、用戶路由等眾多高級功能。

跨VPC

容器多網(wǎng)卡直通方案，直接接入了VPC網(wǎng)絡(luò)平面，因此可以可以使用VPC的一些高級功能，例如能夠使用peer 功能，也可以使用跨VPC的彈性網(wǎng)卡訪問云產(chǎn)品, 也可以給容器分配多個不通VPC內(nèi)的彈性網(wǎng)卡，使其能夠同時跨多個VPC。

高性能

在多網(wǎng)卡方案中，容器內(nèi)的網(wǎng)絡(luò)流量不再需要經(jīng)過在VM內(nèi)部的Iptables/Bridge等進(jìn)行轉(zhuǎn)發(fā)，而是直通到位于宿主機(jī)上的vSwitch，這樣既省去VM內(nèi)的數(shù)據(jù)報文轉(zhuǎn)發(fā)邏輯，同時也減少了數(shù)據(jù)拷貝過程，可以在很大程度上提高容器網(wǎng)絡(luò)的性能。如下表是單次測試的基本性能數(shù)據(jù)對比：

單線程 （Mbps）單線程（pps）多線程 （pps）tbase實(shí)測 1kB（QPS）LinuxBridge32.867295980234166936.33W多網(wǎng)卡方案51.389469865385192247.09W性能提升56.35 %58.7 %64.49 %29.6%

強(qiáng)隔離

傳統(tǒng)的Bridge方案，所有的容器實(shí)例都在同一個大二層網(wǎng)絡(luò)里，存在各種廣播、多播、未知單播泛濫的情況。而通過多網(wǎng)卡直通配合ECS網(wǎng)絡(luò)提供的ACL和安全組功能，就能夠做到有效的安全隔離，甚至容器的管理平面都看不到容器的網(wǎng)絡(luò)流量； 安全規(guī)則的力度也可以達(dá)到容器而不再是虛擬機(jī)級別。

易管理

當(dāng)管控系統(tǒng)將容器調(diào)度到某個VM時， 管控系統(tǒng)在VM所在宿主機(jī)上的vSwitch上創(chuàng)建一個NIC，通過熱插拔技術(shù)將NIC插入到VM，在VM部將NIC配置到容器網(wǎng)絡(luò)命名空間，通過配置vSwitch的流量轉(zhuǎn)發(fā)規(guī)則，然后在xGW上配置HaVIP，外部應(yīng)用及客戶端就能夠訪問容器提供的服務(wù)。

多網(wǎng)卡方案還利于容器的遷移。以遷移到同一臺宿主機(jī)上的另一個VM為例，K8S的kubelet模塊遷移應(yīng)用，然后通過CNI插件重新配置網(wǎng)絡(luò)，管理容器IP及VIP， 配置訪問容器應(yīng)用的方式，這個一個復(fù)雜的過程；多網(wǎng)卡方案能夠很好的解決這個問題，容器被調(diào)度到一個VM后，將舊的容器綁定的NIC從舊的VM拔出，然后插入新的容器所在的VM，在VM內(nèi)部將NIC綁定到容器網(wǎng)絡(luò)命名空間，新的容器就能夠正常進(jìn)行通信了，不再需要重新進(jìn)行網(wǎng)絡(luò)配置。

支持DPDK

由于優(yōu)越的性能優(yōu)勢，DPDK變得流行起來，越來越多的應(yīng)用開始基于DPDK開發(fā)。 傳統(tǒng)的容器網(wǎng)絡(luò)使用VETH作為網(wǎng)絡(luò)設(shè)備，目前無法直接使用DPDK的PMD驅(qū)動，所以無法直接在容器內(nèi)部使用基于DPDK的應(yīng)用。 而在多網(wǎng)卡的方案中，容器使用ECS的網(wǎng)絡(luò)設(shè)備，網(wǎng)絡(luò)設(shè)備為常見的E1000 或者 virtio_net設(shè)備， 這兩種設(shè)備都有PMD驅(qū)動，容器使用這個設(shè)備就能夠直接運(yùn)行基于DPDK的應(yīng)用，能夠在一定程度上提升容器內(nèi)應(yīng)用的網(wǎng)絡(luò)性能。

背景介紹

本章節(jié)會簡介傳統(tǒng)容器網(wǎng)絡(luò)的工作原理及多網(wǎng)卡容器網(wǎng)絡(luò)方案用到的虛擬機(jī)多網(wǎng)卡技術(shù)。

容器網(wǎng)絡(luò)

CNI是CNCF(Cloud Native Computing Foundation)基金會管理的一個開源項(xiàng)目，制定標(biāo)準(zhǔn)及提供源碼庫用于各大廠商開發(fā)Linux容器網(wǎng)絡(luò)管理的插件。知名的CNI插件有Calico和Flannel，Calico通過Flex/Bird實(shí)現(xiàn)BGP等協(xié)議，存儲到分布式的內(nèi)存數(shù)據(jù)庫實(shí)現(xiàn)了一個大三層網(wǎng)絡(luò)，使不同宿主機(jī)上的容器在不發(fā)送ARP的前提下能夠與不同子網(wǎng)的容器進(jìn)行通信。Flannel基于VxLAN等隧道技術(shù)實(shí)現(xiàn)了容器Overlay網(wǎng)絡(luò)。Calico/Flannel等CNI配置容器網(wǎng)絡(luò)就是利用的VETH成對出現(xiàn)的特性，在配置容器網(wǎng)絡(luò)時創(chuàng)建一對VETH設(shè)備，將一端綁定到容器, 另一端保留在VM，VM內(nèi)通過網(wǎng)絡(luò)協(xié)議棧(Overlay網(wǎng)絡(luò))，Iptables(Calico插件)或者Linux Bridge等技術(shù)來實(shí)現(xiàn)容器網(wǎng)絡(luò)的轉(zhuǎn)發(fā)（容器網(wǎng)絡(luò)通過ECS內(nèi)的網(wǎng)橋連接到虛擬交換機(jī)， VPC 只能達(dá)到ECS級別，容器網(wǎng)絡(luò)為網(wǎng)橋上的私有網(wǎng)絡(luò)）。

目前主流容器網(wǎng)絡(luò)工作流如下圖所示，與多網(wǎng)卡容器網(wǎng)絡(luò)存在如下的差異：

?

1>??宿主機(jī)1上容器發(fā)送出報文通過VETH傳輸?shù)絍M內(nèi)部的Linux Bridge上， LinuxBridge運(yùn)行轉(zhuǎn)發(fā)邏輯將報文VM內(nèi)的NIC發(fā)送到位于宿主機(jī)上的vSwitch。

2> 宿主機(jī)2上VM收到vSwitch發(fā)送的報文，通過LinuxBridge的轉(zhuǎn)發(fā)邏輯后由VETH發(fā)送給容器

?

在整個網(wǎng)絡(luò)系統(tǒng)中，VM內(nèi)部需要K8S等編排系統(tǒng)的CNI插件進(jìn)行網(wǎng)絡(luò)配置，vSwitch支持Openflow或Netconf等通信協(xié)議，通過軟件定義網(wǎng)絡(luò)(Software Defined Network, SDN)控制器進(jìn)行管理配置。主流ToR Switch 使用Netconf協(xié)議進(jìn)行遠(yuǎn)程配置，市面也有支持Openflow的SDN物理交換機(jī)。

要管理整個網(wǎng)絡(luò)，就需要兩個不同的網(wǎng)絡(luò)控制系統(tǒng)進(jìn)行控制，配置相對復(fù)雜，且因?qū)崿F(xiàn)機(jī)制等因素導(dǎo)致整個系統(tǒng)存在一定的性能瓶頸，宿主機(jī)上的安全策略也不能做到容器應(yīng)用級別。

虛擬機(jī)多網(wǎng)卡

在為了讓物理主機(jī)實(shí)現(xiàn)跨域，需要在物理機(jī)上插入多張NIC，由于受限于PCI插槽數(shù)目及成本控制，物理機(jī)上很少部署多于兩張NIC；硬件設(shè)備的上下電都或多或少的給整個系統(tǒng)增加脈沖，影響到整機(jī)的穩(wěn)定性，設(shè)備熱插拔收到一定的限制，比較常見的熱插拔設(shè)備是USB設(shè)備，PCI設(shè)備由于需要進(jìn)行2次枚舉及功率影響等原因，熱插拔在最近幾年才得以受限支持。

在虛擬化環(huán)境中，虛擬NIC的低成本及靈活性大大增加了VM的可用性，用戶能夠根據(jù)需求動態(tài)的分配或者釋放NIC，能夠?qū)IC在不影響VM正常運(yùn)行的前提下動態(tài)的插入或者拔出VM， libvirt/qemu模擬虛擬設(shè)備的方式具有物理主機(jī)無法比擬的優(yōu)勢：

資源限制

針對NIC，只要系統(tǒng)有足夠的內(nèi)存等資源，就能夠模擬出多張NIC分配給同一個VM，可以實(shí)現(xiàn)一個VM里面安裝有64張甚至128張NIC。由于這些NIC都是軟件模擬的，相對于物理硬件環(huán)境可以極大的節(jié)約成本，而針對主流硬件支持的多隊列及一些卸載功能也有很好的支持，增加了系統(tǒng)的靈活性。

動態(tài)熱插拔

VM上NIC是通過軟件模擬的，因此在需要NIC的時候，通過軟件分配一些基本的資源后模擬出NIC設(shè)備，通過libvirt/qemu的熱插拔框架能夠很輕松的綁定到某個已經(jīng)正在運(yùn)行的VM，VM就能夠使立即使用這個NIC發(fā)送網(wǎng)絡(luò)報文；當(dāng)不再需要這個NIC后，在不停止VM的情況下，通過libvirt/qemu接口調(diào)用就能“拔”掉這個NIC并將NIC的資源進(jìn)行銷毀，回收重利用其所占用的內(nèi)存，中斷等。

配置實(shí)踐

本章節(jié)將介紹如何一步步通過使用虛擬機(jī)多網(wǎng)卡實(shí)現(xiàn)容器網(wǎng)絡(luò)通信。

?

1. 在阿里云控制臺部署創(chuàng)建虛擬機(jī)實(shí)例，創(chuàng)建實(shí)例時候選擇支持多網(wǎng)卡， 在虛擬機(jī)內(nèi)部能夠看到多張網(wǎng)卡：

1. 在虛擬機(jī)內(nèi)部部署容器應(yīng)用：

～# docker run -itd --net none ubuntu:16.04

注： 在啟動docker 的時候指定容器的netowrk 類型為none

1. 登錄到VM內(nèi)部， 將其中一個NIC綁定到容器命名空間， 在下面的例子中，新動態(tài)插入的網(wǎng)絡(luò)接口卡為eth2， 容器的網(wǎng)絡(luò)命名空間為2017（為方便區(qū)分，以docker inspect看到的PID作為網(wǎng)絡(luò)命名空間名）

~# mkdir /var/run/netns ~# ln -sf /proc/2017/ns/net /var/run/netns/2017 ~# ip link set dev eth2 netns 2017 ~# ip netns exec 2017 ip link set eth2 name eth0 ~# ip netns exec 2017 ip link set eth0 up ~# ip netns exec 2017 dhclient eth0

注： 根據(jù)發(fā)行版的不同，可能不需要用戶自己手動創(chuàng)建連接來“創(chuàng)建” 容器的網(wǎng)絡(luò)命名空間， 在將eth2綁定到容器的網(wǎng)絡(luò)命名空間后，將其重命名為eth0.

1. 在VM內(nèi)及容器內(nèi)查看NIC配置狀態(tài)：

虛擬機(jī)內(nèi)查看NIC是否還繼續(xù)存在：

～# ifconfig -a

容器內(nèi)查看是否有新配置的NIC：

/# ifcofig -a

可以看到，eth2已經(jīng)從VM內(nèi)部移除，應(yīng)用到了容器內(nèi)部。

?

1. 重復(fù)步驟1～4啟動另一個VM及容器。

2. 使用sockperf等工具進(jìn)行性能測試及對比。

$ cat server.sh #!/bin/bash for i in $(seq 1 $1) do ? ?sockperf server --port 123`printf "%02d" $i` & done $ sh server.sh 10

$ cat client.sh #!/bin/bash for i in $(seq 1 $1) do ? ?sockperf tp -i 192.168.2.35 --pps max --port 123`printf "%02d" $i` -t 300 & done$ sh client 10

總結(jié)

本文介紹了一種基于虛擬機(jī)多網(wǎng)卡熱插拔的容器網(wǎng)絡(luò)解決方案，通過給虛擬機(jī)動態(tài)熱插拔網(wǎng)卡并應(yīng)用到容器中用于容器網(wǎng)絡(luò)數(shù)據(jù)報文的收發(fā)，借助運(yùn)行在虛擬機(jī)內(nèi)的虛擬軟件交換機(jī)對網(wǎng)絡(luò)報文的轉(zhuǎn)發(fā)，大大簡化了容器網(wǎng)絡(luò)的管理控制系統(tǒng)的復(fù)雜度，同時也大幅提高了網(wǎng)絡(luò)性能，同時增強(qiáng)了容器網(wǎng)絡(luò)的安全性。

?

附錄1. 業(yè)務(wù)實(shí)測

Tier-Base(tbase) 是一個跟Redis類似的分布式KV數(shù)據(jù)庫，使用C++語言編寫，幾乎支持所有的Redius數(shù)據(jù)結(jié)構(gòu)，同時支持 RocksDB作為后端. tbase在螞蟻金服里面比較常用，本章節(jié)將介紹本方案tbase業(yè)務(wù)實(shí)測情況。

傳統(tǒng)LinuxBridge測試

測試環(huán)境

server: 16C60G x 1(half ?A8)

client: 4C8G x 8

tbase server部署方式：7G x 7個實(shí)例

tbase client部署方式：8 x (16threads + 1 client) => 128 threads + 8 clients?

測試報告

操作包大小clients網(wǎng)卡load1cpuQPSavg rt99th rtset1KB8424MB7.1544%36.33W0.39ms<1msget1KB8421MB7.0645%35.70W0.39ms<1msset64KB11884MB2.317%2.90W0.55ms<5msset128KB12252MB2.5318%1.82W0.87ms<6msset256KB12804MB2.3620%1.11W1.43ms<5msset512KB13104MB2.6120%0.60W2.62ms<10ms

ENI 多網(wǎng)卡測試

測試環(huán)境

server: 16C60G x 1(half A8)

client: 4C8G x 8

tbase?server部署方式：7G x 7個實(shí)例

tbase client部署方式：16 x (16threads + 1 client) => 256 threads + 16 clients

測試報告

操作包大小clients網(wǎng)卡load1cpuQPSavg rt99th rtset/get1KB16570MB6.9745%47.09W0.30ms<1

?測試結(jié)論

基于ENI多網(wǎng)卡方案，整體性能和延遲情況比Bridge方案有較明顯提升（QPS提升30%，平均延遲降低23%），16C60G的情況下，QPS 47.09W左右，avg / p99 = 0.30ms / <1ms，CPU消耗分別為user 45% + sys?29% + si?18% + st 2%，si消耗比Bridge有明顯下降，通過內(nèi)核隊列打散，st消耗分散到了多個不同的core上，處理資源使用更均衡。

對于VPC路由表的的解決方案flannal/canal來看，帶寬和吞吐基本上沒有損失，延遲會相對宿主機(jī)的有0.1ms左右的延遲，使用nginx測試qps，在頁面較小時的損失在10%左右；對于ENI方案看，帶寬，吞吐，相對宿主機(jī)基本上沒損失，在延遲上比宿主機(jī)稍微低一些，在應(yīng)用測試上性能優(yōu)于宿主機(jī)網(wǎng)絡(luò)10%左右，原因應(yīng)該是POD內(nèi)部基本上沒有經(jīng)過iptables；對于默認(rèn)的flannel vxlan，帶寬和吞吐?lián)p失5%左右，而在nginx測試小頁面的最大qps中，相對宿主機(jī)損失大概30%的性能。

附錄2. 相關(guān)鏈接

?1. 功能介紹：?https://help.aliyun.com/document_detail/58496.html?spm=5176.10695662.1996646101.searchclickresult.7b0c6774Iohqb0

2. 用戶指南：?https://help.aliyun.com/document_detail/58503.html?spm=a2c4g.11186623.6.729.A5vnwY

3. 開發(fā)指南：?https://help.aliyun.com/document_detail/25485.html?spm=5176.10695662.1996646101.searchclickresult.16561e264s4VLv

閱讀原文

本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。