電子發(fā)燒友App
摘要：?容器是相比于虛擬機(Virtual Machine，VM)更輕便，部署更方便快捷的一種虛擬化技術。 Docker是目前主流的容器引擎，支持Linux，Windows等多種平臺，同時支持Kubernetes(K8S), Swarm及Rocket(RKT)等主流Docker編排系統(tǒng)。
概述
容器是相比于虛擬機(Virtual Machine，VM)更輕便，部署更方便快捷的一種虛擬化技術。 Docker是目前主流的容器引擎，支持Linux，Windows等多種平臺，同時支持Kubernetes(K8S), Swarm及Rocket(RKT)等主流Docker編排系統(tǒng)。常見的容器網(wǎng)絡支持Bridge，Overlay，Host及用戶自定義網(wǎng)絡等多種模型，K8S等系統(tǒng)依賴于容器網(wǎng)絡接口(Container Network Interface, CNI)插件來完成網(wǎng)絡管理，常見的有Calico/Flannel等知名CNI插件。本文將介紹一些容器網(wǎng)絡的基本知識，基于阿里云的彈性網(wǎng)絡接口（Elastic Network Interface， ENI）技術實現(xiàn)了ECS容器網(wǎng)絡的高性能，易部署及維護， 具有強隔離的高安全容器網(wǎng)絡。
多網(wǎng)卡容器網(wǎng)絡
當VM擁有多張網(wǎng)絡接口卡（Network Interface Card, NIC），而且這些NIC是能夠動態(tài)熱插拔時，NIC就能夠用于容器網(wǎng)絡， 這樣容器網(wǎng)絡將不再需要利用Linux VETH及Bridge等技術，同時報文轉(zhuǎn)發(fā)下移到了位于宿主機上的虛擬交換機(Virtual Switch，vSwitch)，通過減少流程提升網(wǎng)絡性能。
方案介紹
如下圖所示，在宿主機上運行有vSwitch，用于轉(zhuǎn)發(fā)VM及容器的流量， 在vSwitch上連接有多張?zhí)摂MNIC。在VM內(nèi)啟動容器時，在宿主機上動態(tài)地將虛擬NIC綁定容器所在的VM，然后在VM內(nèi)部將NIC綁定到容器所在的網(wǎng)絡命名空間，容器內(nèi)的網(wǎng)絡流量能夠直接通過這塊NIC直接發(fā)送到位于宿主機上的vSwitch（容器網(wǎng)絡直通vSwitch）， vSwith內(nèi)應用ACL/QoS/Session等規(guī)則過后將流量進行轉(zhuǎn)發(fā)。當位于宿主機1上的VM內(nèi)運行的容器訪問位于宿主機2上的VM內(nèi)運行的容器時，流量大致會經(jīng)歷如下流程：
?
1>??網(wǎng)絡報文經(jīng)過容器內(nèi)核網(wǎng)絡協(xié)議棧，查找路由后通過eth0網(wǎng)卡發(fā)送報文；
2>? 宿主機上的vSwitch從虛擬端口收到來自容器的報文，運行vSwitch的轉(zhuǎn)發(fā)邏輯，將報文通過物理網(wǎng)絡端口發(fā)送到ToR交換機 (Top of Rack Switch, ToR Switch)，如果針對容器或者虛擬機網(wǎng)絡建立了虛擬私有云 (Virtual Private Cloud， VPC）則需要對報文使用VxLAN等隧道技術進行封裝；
3>??ToR Switch通過查詢路由信息，通過連接宿主機2的物理端口將報文轉(zhuǎn)發(fā)；
4>??位于宿主機2上的vSwitch接收物理端口報文，經(jīng)轉(zhuǎn)發(fā)邏輯發(fā)送到連接容器的虛擬端口；
5>??容器內(nèi)協(xié)議棧eth0收到由另一端發(fā)送來的報文，由容器內(nèi)網(wǎng)絡協(xié)議棧進行處理。
方案特點
與傳統(tǒng)的在VM內(nèi)運行容器的方案對比，本方案具有高性能，易管理及強隔離等特點。
VPC直通
讓容器通過多網(wǎng)卡直通的方案，直接接入VPC網(wǎng)絡平面，能讓每個容器具備全量的VPC網(wǎng)絡功能，包括：EIP、SLB、高防、安全組、HAVIP、NAT、用戶路由等眾多高級功能。
跨VPC
容器多網(wǎng)卡直通方案，直接接入了VPC網(wǎng)絡平面，因此可以可以使用VPC的一些高級功能，例如能夠使用peer 功能，也可以使用跨VPC的彈性網(wǎng)卡訪問云產(chǎn)品, 也可以給容器分配多個不通VPC內(nèi)的彈性網(wǎng)卡，使其能夠同時跨多個VPC。
高性能
在多網(wǎng)卡方案中，容器內(nèi)的網(wǎng)絡流量不再需要經(jīng)過在VM內(nèi)部的Iptables/Bridge等進行轉(zhuǎn)發(fā)，而是直通到位于宿主機上的vSwitch，這樣既省去VM內(nèi)的數(shù)據(jù)報文轉(zhuǎn)發(fā)邏輯，同時也減少了數(shù)據(jù)拷貝過程，可以在很大程度上提高容器網(wǎng)絡的性能。如下表是單次測試的基本性能數(shù)據(jù)對比：
單線程 （Mbps）單線程（pps）多線程 （pps）tbase實測 1kB（QPS）LinuxBridge32.867295980234166936.33W多網(wǎng)卡方案51.389469865385192247.09W性能提升56.35 %58.7 %64.49 %29.6%
強隔離
傳統(tǒng)的Bridge方案，所有的容器實例都在同一個大二層網(wǎng)絡里，存在各種廣播、多播、未知單播泛濫的情況。而通過多網(wǎng)卡直通配合ECS網(wǎng)絡提供的ACL和安全組功能，就能夠做到有效的安全隔離，甚至容器的管理平面都看不到容器的網(wǎng)絡流量； 安全規(guī)則的力度也可以達到容器而不再是虛擬機級別。
易管理
當管控系統(tǒng)將容器調(diào)度到某個VM時， 管控系統(tǒng)在VM所在宿主機上的vSwitch上創(chuàng)建一個NIC，通過熱插拔技術將NIC插入到VM，在VM部將NIC配置到容器網(wǎng)絡命名空間，通過配置vSwitch的流量轉(zhuǎn)發(fā)規(guī)則，然后在xGW上配置HaVIP，外部應用及客戶端就能夠訪問容器提供的服務。
多網(wǎng)卡方案還利于容器的遷移。以遷移到同一臺宿主機上的另一個VM為例，K8S的kubelet模塊遷移應用，然后通過CNI插件重新配置網(wǎng)絡，管理容器IP及VIP， 配置訪問容器應用的方式，這個一個復雜的過程；多網(wǎng)卡方案能夠很好的解決這個問題，容器被調(diào)度到一個VM后，將舊的容器綁定的NIC從舊的VM拔出，然后插入新的容器所在的VM，在VM內(nèi)部將NIC綁定到容器網(wǎng)絡命名空間，新的容器就能夠正常進行通信了，不再需要重新進行網(wǎng)絡配置。
支持DPDK
由于優(yōu)越的性能優(yōu)勢，DPDK變得流行起來，越來越多的應用開始基于DPDK開發(fā)。 傳統(tǒng)的容器網(wǎng)絡使用VETH作為網(wǎng)絡設備，目前無法直接使用DPDK的PMD驅(qū)動，所以無法直接在容器內(nèi)部使用基于DPDK的應用。 而在多網(wǎng)卡的方案中，容器使用ECS的網(wǎng)絡設備，網(wǎng)絡設備為常見的E1000 或者 virtio_net設備， 這兩種設備都有PMD驅(qū)動，容器使用這個設備就能夠直接運行基于DPDK的應用，能夠在一定程度上提升容器內(nèi)應用的網(wǎng)絡性能。
背景介紹
本章節(jié)會簡介傳統(tǒng)容器網(wǎng)絡的工作原理及多網(wǎng)卡容器網(wǎng)絡方案用到的虛擬機多網(wǎng)卡技術。
容器網(wǎng)絡
CNI是CNCF(Cloud Native Computing Foundation)基金會管理的一個開源項目，制定標準及提供源碼庫用于各大廠商開發(fā)Linux容器網(wǎng)絡管理的插件。知名的CNI插件有Calico和Flannel，Calico通過Flex/Bird實現(xiàn)BGP等協(xié)議，存儲到分布式的內(nèi)存數(shù)據(jù)庫實現(xiàn)了一個大三層網(wǎng)絡，使不同宿主機上的容器在不發(fā)送ARP的前提下能夠與不同子網(wǎng)的容器進行通信。Flannel基于VxLAN等隧道技術實現(xiàn)了容器Overlay網(wǎng)絡。Calico/Flannel等CNI配置容器網(wǎng)絡就是利用的VETH成對出現(xiàn)的特性，在配置容器網(wǎng)絡時創(chuàng)建一對VETH設備，將一端綁定到容器, 另一端保留在VM，VM內(nèi)通過網(wǎng)絡協(xié)議棧(Overlay網(wǎng)絡)，Iptables(Calico插件)或者Linux Bridge等技術來實現(xiàn)容器網(wǎng)絡的轉(zhuǎn)發(fā)（容器網(wǎng)絡通過ECS內(nèi)的網(wǎng)橋連接到虛擬交換機， VPC 只能達到ECS級別，容器網(wǎng)絡為網(wǎng)橋上的私有網(wǎng)絡）。
目前主流容器網(wǎng)絡工作流如下圖所示，與多網(wǎng)卡容器網(wǎng)絡存在如下的差異：
?
1>??宿主機1上容器發(fā)送出報文通過VETH傳輸?shù)絍M內(nèi)部的Linux Bridge上， LinuxBridge運行轉(zhuǎn)發(fā)邏輯將報文VM內(nèi)的NIC發(fā)送到位于宿主機上的vSwitch。
2> 宿主機2上VM收到vSwitch發(fā)送的報文，通過LinuxBridge的轉(zhuǎn)發(fā)邏輯后由VETH發(fā)送給容器
?
在整個網(wǎng)絡系統(tǒng)中，VM內(nèi)部需要K8S等編排系統(tǒng)的CNI插件進行網(wǎng)絡配置，vSwitch支持Openflow或Netconf等通信協(xié)議，通過軟件定義網(wǎng)絡(Software Defined Network, SDN)控制器進行管理配置。主流ToR Switch 使用Netconf協(xié)議進行遠程配置，市面也有支持Openflow的SDN物理交換機。
要管理整個網(wǎng)絡，就需要兩個不同的網(wǎng)絡控制系統(tǒng)進行控制，配置相對復雜，且因?qū)崿F(xiàn)機制等因素導致整個系統(tǒng)存在一定的性能瓶頸，宿主機上的安全策略也不能做到容器應用級別。
虛擬機多網(wǎng)卡
在為了讓物理主機實現(xiàn)跨域，需要在物理機上插入多張NIC，由于受限于PCI插槽數(shù)目及成本控制，物理機上很少部署多于兩張NIC；硬件設備的上下電都或多或少的給整個系統(tǒng)增加脈沖，影響到整機的穩(wěn)定性，設備熱插拔收到一定的限制，比較常見的熱插拔設備是USB設備，PCI設備由于需要進行2次枚舉及功率影響等原因，熱插拔在最近幾年才得以受限支持。
在虛擬化環(huán)境中，虛擬NIC的低成本及靈活性大大增加了VM的可用性，用戶能夠根據(jù)需求動態(tài)的分配或者釋放NIC，能夠?qū)IC在不影響VM正常運行的前提下動態(tài)的插入或者拔出VM， libvirt/qemu模擬虛擬設備的方式具有物理主機無法比擬的優(yōu)勢：
資源限制
針對NIC，只要系統(tǒng)有足夠的內(nèi)存等資源，就能夠模擬出多張NIC分配給同一個VM，可以實現(xiàn)一個VM里面安裝有64張甚至128張NIC。由于這些NIC都是軟件模擬的，相對于物理硬件環(huán)境可以極大的節(jié)約成本，而針對主流硬件支持的多隊列及一些卸載功能也有很好的支持，增加了系統(tǒng)的靈活性。
動態(tài)熱插拔
VM上NIC是通過軟件模擬的，因此在需要NIC的時候，通過軟件分配一些基本的資源后模擬出NIC設備，通過libvirt/qemu的熱插拔框架能夠很輕松的綁定到某個已經(jīng)正在運行的VM，VM就能夠使立即使用這個NIC發(fā)送網(wǎng)絡報文；當不再需要這個NIC后，在不停止VM的情況下，通過libvirt/qemu接口調(diào)用就能“拔”掉這個NIC并將NIC的資源進行銷毀，回收重利用其所占用的內(nèi)存，中斷等。
配置實踐
本章節(jié)將介紹如何一步步通過使用虛擬機多網(wǎng)卡實現(xiàn)容器網(wǎng)絡通信。
?
在阿里云控制臺部署創(chuàng)建虛擬機實例，創(chuàng)建實例時候選擇支持多網(wǎng)卡， 在虛擬機內(nèi)部能夠看到多張網(wǎng)卡：
在虛擬機內(nèi)部部署容器應用：
～# docker run -itd --net none ubuntu:16.04
注： 在啟動docker 的時候指定容器的netowrk 類型為none
登錄到VM內(nèi)部， 將其中一個NIC綁定到容器命名空間， 在下面的例子中，新動態(tài)插入的網(wǎng)絡接口卡為eth2， 容器的網(wǎng)絡命名空間為2017（為方便區(qū)分，以docker inspect看到的PID作為網(wǎng)絡命名空間名）
~# 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)絡命名空間， 在將eth2綁定到容器的網(wǎng)絡命名空間后，將其重命名為eth0.
在VM內(nèi)及容器內(nèi)查看NIC配置狀態(tài)：
虛擬機內(nèi)查看NIC是否還繼續(xù)存在：
～# ifconfig -a
容器內(nèi)查看是否有新配置的NIC：
/# ifcofig -a
可以看到，eth2已經(jīng)從VM內(nèi)部移除，應用到了容器內(nèi)部。
?
重復步驟1～4啟動另一個VM及容器。
使用sockperf等工具進行性能測試及對比。
$ 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é)
本文介紹了一種基于虛擬機多網(wǎng)卡熱插拔的容器網(wǎng)絡解決方案，通過給虛擬機動態(tài)熱插拔網(wǎng)卡并應用到容器中用于容器網(wǎng)絡數(shù)據(jù)報文的收發(fā)，借助運行在虛擬機內(nèi)的虛擬軟件交換機對網(wǎng)絡報文的轉(zhuǎn)發(fā)，大大簡化了容器網(wǎng)絡的管理控制系統(tǒng)的復雜度，同時也大幅提高了網(wǎng)絡性能，同時增強了容器網(wǎng)絡的安全性。
?
附錄1. 業(yè)務實測
Tier-Base(tbase) 是一個跟Redis類似的分布式KV數(shù)據(jù)庫，使用C++語言編寫，幾乎支持所有的Redius數(shù)據(jù)結(jié)構，同時支持 RocksDB作為后端. tbase在螞蟻金服里面比較常用，本章節(jié)將介紹本方案tbase業(yè)務實測情況。
傳統(tǒng)LinuxBridge測試
測試環(huán)境
server: 16C60G x 1(half ?A8)
client: 4C8G x 8
tbase server部署方式：7G x 7個實例
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<10msENI 多網(wǎng)卡測試
測試環(huán)境
server: 16C60G x 1(half A8)
client: 4C8G x 8
tbase?server部署方式：7G x 7個實例
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來看，帶寬和吞吐基本上沒有損失，延遲會相對宿主機的有0.1ms左右的延遲，使用nginx測試qps，在頁面較小時的損失在10%左右；對于ENI方案看，帶寬，吞吐，相對宿主機基本上沒損失，在延遲上比宿主機稍微低一些，在應用測試上性能優(yōu)于宿主機網(wǎng)絡10%左右，原因應該是POD內(nèi)部基本上沒有經(jīng)過iptables；對于默認的flannel vxlan，帶寬和吞吐?lián)p失5%左右，而在nginx測試小頁面的最大qps中，相對宿主機損失大概30%的性能。
附錄2. 相關鏈接
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)載。
工商網(wǎng)監(jiān)
評論