CloudFabric云數(shù)據(jù)中心網(wǎng)解決方案

設(shè)計(jì)指南（容器網(wǎng)絡(luò)）

目錄

1容器技術(shù)簡(jiǎn)介..........1

1.1容器是什么..................................................................................1

1.1.1容器依賴的底層技術(shù)........................................................................1

1.1.2容器原理簡(jiǎn)介..............................................................................2

1.1.3容器運(yùn)行時(shí)................................................................................3

1.1.4Docker基礎(chǔ)................................................................................5

1.1.5Docker網(wǎng)2各介名召............................................................................9

None模式................................................................................9

Bridge模式...............................................................................9

Hosi模式................................................................................11

MappedContainer模式.....................................................................12

1.2容器技術(shù)與虛擬機(jī)...........................................................................14

1.3容器技術(shù)的發(fā)展趨勢(shì).........................................................................17

1.4容器技術(shù)的應(yīng)用場(chǎng)景.........................................................................19

1.4.1PaaS平臺(tái)建設(shè).............................................................................19

1.4.2容器即服務(wù)...............................................................................19

1.4.3持續(xù)集成和發(fā)布...........................................................................20

2Kubernetes介紹...............................21

2.1容器集群管理技術(shù)的發(fā)展....................................................................21

2.2K8s組件架構(gòu)..............................................................................22

2.3K8s業(yè)務(wù)模型...............................................................................24

2.4K8S網(wǎng)絡(luò)需求..............................................................................27

2.4.1K8S網(wǎng)絡(luò)三原貝ij.......................................................................................................................................................27

242K8s網(wǎng)絡(luò)實(shí)現(xiàn)方式：CNI接匚................................................................27

2.4.3K8S網(wǎng)絡(luò)典型實(shí)現(xiàn)模型......................................................................28

L2橋接.................................................................................29

243.2L3路由..................................................................................29

2.433HostOverlay............................................................................................................................................................32

2.43.4總結(jié)....................................................................................34

3CloudFabric容器網(wǎng)絡(luò)方案........................35

3.1容器網(wǎng)絡(luò)帶來(lái)的挑戰(zhàn).......................................................................35

3.1.1控制面挑戰(zhàn)...............................................................................35

3.1.2轉(zhuǎn)發(fā)面挑戰(zhàn)...............................................................................36

3.2裸機(jī)容器與虛機(jī)容器對(duì)比...................................................................36

3.3CloudFabric容器網(wǎng)絡(luò)方案概述...............................................................38

3.3.1容器網(wǎng)絡(luò)組件介紹.........................................................................38

3.3.2容器網(wǎng)絡(luò)與物理網(wǎng)絡(luò)聯(lián)動(dòng)...................................................................39

NetworkOverlay方案全景.................................................................39

NetworkOverlay方案架構(gòu).................................................................41

3.323L2橋接，L3路由方案對(duì)比分析.............................................................45

3.4容器網(wǎng)絡(luò)組網(wǎng)設(shè)計(jì).........................................................................45

3.4.1容器網(wǎng)絡(luò)推薦組網(wǎng).........................................................................45

3.4.1.1管理面、數(shù)據(jù)面獨(dú)立網(wǎng)卡.................................................................45

管理面、數(shù)據(jù)面共網(wǎng)卡...................................................................46

3.4.2L3路由模式路由發(fā)布......................................................................47

關(guān)閉BGP路由抑制.......................................................................48

3A2.2開(kāi)啟BGP路由抑制.......................................................................50

3.4.3K8S集群內(nèi)Pod東西向流量互訪.............................................................51

NetworkOverlayL2橋接...................................................................51

NetworkOverlayL3路由..................................................................51

3.4.4K8S集群內(nèi)外南北向流量互訪...............................................................52

NetworkOverlayL2橋接...................................................................52

NetworkOverlayL3路由..................................................................53

3.4.5VPC互通.................................................................................54

NetworkOverlayL2橋接模式VPC互通......................................................55

NetworkOverlayL3路由模式VPC互通.....................................................56

3.5容器網(wǎng)絡(luò)自動(dòng)化設(shè)計(jì).......................................................................57

3.5.1容器平臺(tái)對(duì)接控制器.......................................................................57

3.5.i.l配置iMasterNCE-Fabric控制器............................................................57

安裝華為CNI插件.......................................................................59

351.3安裝華為iMasterNCE-Fabric插件...........................................................59

3.S.2業(yè)務(wù)發(fā)放流程.............................................................................60

NetworkOverlayL2橋接模式業(yè)務(wù)部署......................................................60

NetworkOverlayL3路由模式業(yè)務(wù)部署......................................................64

352.2.1容器固定IP.........................................................................................................................................................64

.2容器IP隨機(jī)分配........................................................................66

3.5.3方案約束..................................................................................69

3.6容器網(wǎng)絡(luò)安全設(shè)計(jì)...........................................................................70

3.6.1容器網(wǎng)絡(luò)安全總體設(shè)計(jì).....................................................................70

3.6.2容器網(wǎng)絡(luò)策略.............................................................................70

NetworkPolicy實(shí)現(xiàn)原理...................................................................70

CloudFabric容器網(wǎng)絡(luò)策略.................................................................71

3.7容器網(wǎng)絡(luò)運(yùn)維設(shè)計(jì)..........................................................................74

3.7.1NetworkOverlayL2橋接....................................................................74

3.7.2NetworkOverlayL3路由....................................................................75

3.7.3普羅米修斯工具監(jiān)控CE1800V..............................................................................................................................75

3.8容器網(wǎng)絡(luò)對(duì)接CCE開(kāi)源Calico方案...........................................................77

4容器網(wǎng)絡(luò)部署最佳實(shí)踐…….......................................79

A參考圖片..........................................81

容器技術(shù)簡(jiǎn)介

1.1容器是什么

1.2容器技術(shù)與虛擬機(jī)

1.3容器技術(shù)的發(fā)展趨勢(shì)

1.4容器技術(shù)的應(yīng)用場(chǎng)景

1.1容器是什么

1.1.1容器依賴的底層技術(shù)

容器底層的核心技術(shù)包括Linux的Namespace和Cgroupo

Namespace

Linux支持6種namespace,簡(jiǎn)要介紹如F：

?主機(jī)和域名空間(UNIXTimesharingSystem)：每個(gè)容器擁有獨(dú)立的hostname

和domainname,使其在網(wǎng)絡(luò)上可以被視作一個(gè)獨(dú)立的節(jié)點(diǎn)而非主機(jī)上的一個(gè)進(jìn)

程；

?進(jìn)程間通信空間(Inter-ProcessCommunication)：容器中進(jìn)程交互還是采用了

Linux常見(jiàn)的交互方法，通過(guò)共享內(nèi)存、信號(hào)量、消息隊(duì)列和管道等方法實(shí)現(xiàn)，

在新的IPCnamespace中創(chuàng)建IPC,并不會(huì)與其他應(yīng)用發(fā)生沖突：

?進(jìn)程ID空間(ProcessID)：使得不同PIDnamespace里的進(jìn)程ID可以重復(fù)且相

互之間不影響；

?文件系統(tǒng)空間(Mountnamespace)：用來(lái)隔離文件系統(tǒng)的掛載點(diǎn)，使得不同的

mountnamespace擁有自己獨(dú)立的掛載點(diǎn)信息，不同的namespace之間不會(huì)相互影

響，這對(duì)手構(gòu)建用戶或者容器自己的文件系統(tǒng)目錄非常有用；

?網(wǎng)絡(luò)協(xié)議棧空間(Networknamespace)：每個(gè)Networknamespace都有自己獨(dú)立

的網(wǎng)絡(luò)棧,路由表，防火墻規(guī)則，socka等；

?用戶空間(USERnamespace)：用來(lái)隔離user權(quán)限相關(guān)的Linux資源，包括user

IDs,groupIDs,keys,capabilitieso

Cgroup

Linux的namespace主要解決了環(huán)境隔離問(wèn)題，這只是虛擬化中最最基礎(chǔ)的一步，我們

還需要解決對(duì)計(jì)算機(jī)資源使用上的隔離，這就是Cgroup要做的事情。LinuxCgroup全

稱LinuxControlGroup,是Linux內(nèi)核的一個(gè)功能，向來(lái)限制、控制與分離一個(gè)施程

組群的資源（如CPU時(shí)間、內(nèi)存、網(wǎng)絡(luò)帶寬、磁盤輸入輸出等）。這個(gè)項(xiàng)目最早是由

Google的「程師在2006年發(fā)起，最早的名稱為進(jìn)程容器（processcontainers）。在

2007年時(shí)，因?yàn)樵贚inux內(nèi)核中,容器（container）這個(gè)名詞太過(guò)廣泛,為避免混

亂，被重命名為cgroup,并且被合到了2.6.24版的內(nèi)核。

LinuxCgroup可為系統(tǒng)中所運(yùn)行的任務(wù)（進(jìn)程）進(jìn)行分組，并在分組的基礎(chǔ)上對(duì)進(jìn)程

進(jìn)行資源控制.比如CPU時(shí)間、系統(tǒng)內(nèi)存、網(wǎng)絡(luò)帶寬或者這些資源的組合，還可以

監(jiān)控所配置的Cgroup,拒絕Cgroup訪問(wèn)某些資源，甚至在運(yùn)行的系統(tǒng)中動(dòng)態(tài)配置

Cgroup.使用Cgroup,系統(tǒng)管理員可更具體地控制對(duì)系統(tǒng)資源的分配、優(yōu)先順序、拒

絕、管理和監(jiān)控，可更好地根據(jù)任務(wù)和用戶分配硬件資源，提高總體效率。

圖1-1LinuxCgroup示意圖

Cgroup2

112容器原理簡(jiǎn)介

容器本身并不是全新的虛擬化技術(shù)，事實(shí)上它只是操作系統(tǒng)虛擬化技術(shù)的一種，它本

質(zhì)上是使用/Linux的namespace實(shí)現(xiàn)資源隔離和Cgroup實(shí)現(xiàn)資源限制，彼此間相互

隔離的若干個(gè)linux進(jìn)程的集合。

容器共享宿主機(jī)操作系統(tǒng)內(nèi)核，通過(guò)宿主操作系統(tǒng)提供相互隔離的運(yùn)行環(huán)境。每個(gè)容

器包含括獨(dú)立的文件系統(tǒng)空間（MNTNS）,主機(jī)和域名空間（UTSNS）,進(jìn)程間通信

空間（IPCNS）,進(jìn)程ID空間（PIDNS）,網(wǎng)絡(luò)協(xié)議?？臻g（NETNS）,用戶空間

（USERNS）。

圖1-2容器與操作系統(tǒng)

1.1.3容器運(yùn)行時(shí)

我們所說(shuō)的容器運(yùn)行時(shí)，準(zhǔn)確來(lái)說(shuō)包含兩部分，一部分是上層容器運(yùn)行時(shí)CRIshim

（即容器運(yùn)行時(shí)管理程序，如Contained、CRI-O）,另一部分是下層容器運(yùn)行時(shí)

Containerruntime（即容器運(yùn)行時(shí)命令工具,如rune）。Kubernetes在引入CRI之后,

Kubelel的架構(gòu)如下圖所示。

圖1-3Kubclct的架構(gòu)

CRI（ContainerRuntimeInterface容器運(yùn)行時(shí)接口）

Kubernetes如今已經(jīng)成為容器編排調(diào)度領(lǐng)域的事實(shí)標(biāo)準(zhǔn)，其優(yōu)良的架構(gòu)不僅保證了豐

富的容器編排調(diào)度功能，同時(shí)也提供了各個(gè)層次的擴(kuò)展接口以滿足用戶的定制化需

求。容器運(yùn)行時(shí)作為Kubernetes管理和運(yùn)行容器的關(guān)鍵組件，當(dāng)然也提供了簡(jiǎn)便易用

的擴(kuò)展接口，也就是CRI。CRI接口分為兩部分，一個(gè)是容器運(yùn)行時(shí)服務(wù)

RuntimeService＞負(fù)責(zé)管理pod和容器的生命周期；一個(gè)是鏡像服務(wù)ImageService,

負(fù)責(zé)管理鏡像的生命周期。

其實(shí)，Kubernetes在vl.5版本之前是沒(méi)有CRI接口的,那時(shí)Kubclct源碼內(nèi)部只集成

了兩個(gè)容器運(yùn)行時(shí)（Docker和rkt）的相關(guān)代碼。這兩種容器運(yùn)行時(shí)并不能滿足所有用

戶的使用需求.在某些業(yè)務(wù)場(chǎng)景，用戶對(duì)容器的安全隔離性有著更高的需求，用戶希

望Kubernetes能支持更多種類的容器運(yùn)行時(shí)。因此，Kubernetes在1.5版本推出\CR!

接口，各個(gè)容器運(yùn)行時(shí)只要實(shí)現(xiàn)了CRI接口規(guī)范，就可以接入到Kubernetes平臺(tái)為用

戶提供容器服務(wù)。CRI隔離了各個(gè)容器運(yùn)行時(shí)之間的差異，通過(guò)統(tǒng)一的接口與各個(gè)容

器運(yùn)行時(shí)之間進(jìn)行交互，定義了容器生命周期的管理，促進(jìn)了容器運(yùn)行時(shí)社區(qū)的繁

榮，也為強(qiáng)隔離、多租戶等復(fù)雜的場(chǎng)景帶來(lái)更多的選擇。當(dāng)前實(shí)現(xiàn)了CRI的主流項(xiàng)目

有以下幾種：

1.默認(rèn)安裝Kubemetes,kubelet已經(jīng)內(nèi)嵌dockershim(適配CRI),它接收到CRI

請(qǐng)求轉(zhuǎn)化后發(fā)給docker處理，這也是目前非常成熟的方案；

2.Containerd項(xiàng)目是從早期的Docker源碼中提煉出來(lái)的，它使用CRI插件來(lái)向

kubelet提供CRI接口服務(wù)；

3.CRLO完整實(shí)現(xiàn)CRI接口功能.CRLO比Conlainerd更專注,它只服務(wù)干

Kubernetes,Fl前由redhat主導(dǎo)；

4.Frakli是一個(gè)基于KubelelCRI的實(shí)現(xiàn)，Kubernetes官方維護(hù)的一個(gè)項(xiàng)目，它提供

了hypervisor級(jí)別的隔離性，但當(dāng)前社區(qū)并不活躍。

圖14CRI

OCI(OpenContainerInitiative開(kāi)放容器標(biāo)準(zhǔn))

為了保證容器生態(tài)的健康發(fā)展，保證不同的容器之間能夠兼容。2015年，由Docker、

IBM、微軟、紅帽及Google等廠商所組成的OCI聯(lián)盟成立，并于2016年4月推出了

第一個(gè)開(kāi)放容器標(biāo)準(zhǔn)。0CI規(guī)范包含兩部分內(nèi)容：容器運(yùn)行時(shí)標(biāo)準(zhǔn)(runtimespec)、容

器鏡像標(biāo)準(zhǔn)(imagespec)。runtimespec包含配置文件、運(yùn)行環(huán)境、生命周期三部分內(nèi)

容。imagespec對(duì)容器鏡像格式做了定義，它主要包括文件系統(tǒng)、config文件、

manifest文件、index文件。當(dāng)前主流的兼容OCI規(guī)范的容器運(yùn)行時(shí)項(xiàng)目有以下幾種：

表1-1主流的兼容OCI規(guī)范的容器運(yùn)行時(shí)項(xiàng)目

OCI-功能特性

runtime

runC基J-namespace和Cgroup實(shí)現(xiàn)的資源隔離和限制，docker容器引擎默

認(rèn)的運(yùn)行時(shí)

OCI-功能特性

runtime

runV基于hypervisor實(shí)現(xiàn)的、兼容OCI規(guī)范的虛擬機(jī)容器運(yùn)行時(shí)

kata整合了Intel的ClearContainer和Hypcr.sh的runV,兼容OCI規(guī)范的

container輕量級(jí)虛擬機(jī)容器運(yùn)行時(shí)，支持不同平臺(tái)的硬件（x86_64,ARM,

IBM等）

gVisor新型sndhox技術(shù),比虛擬機(jī)容器運(yùn)行時(shí)更輕量化,在sandhex中運(yùn)行

自己的虛擬內(nèi)核，攔截從應(yīng)用程序到主機(jī)內(nèi)核的所有系統(tǒng)調(diào)用，為它

們提供隔離，但付出的代價(jià)是系統(tǒng)調(diào)用性能比較差，資源消耗多

1.1.4Docker基礎(chǔ)

Docker屬于Linux容器的一種封裝，提供簡(jiǎn)單易用的容器使用接LI,它是目前最流

行的Linux容器解決方案。Docker將應(yīng)用程序與該程序的依賴打包在一個(gè)文件里

面，運(yùn)行這個(gè)文件，就會(huì)生成一個(gè)虛擬容器c程序在這個(gè)虛擬容器里運(yùn)行，就好像在

真實(shí)的物理機(jī)上運(yùn)行一樣。

Docker包括三個(gè)基本的概念：Image（鏡像）,Container（容器）,Repository（倉(cāng)庫(kù)）。

Image（鏡像）

Docker鏡像可以看作是一個(gè)特殊的文件系統(tǒng)，除了提供容器運(yùn)行時(shí)所需的程序、庫(kù)、

資源、配置等文件外，還包含了一些為運(yùn)行E寸準(zhǔn)備的配置參數(shù)（如匿名卷、環(huán)境變

量、用戶等）。鏡像不包含任何動(dòng)態(tài)數(shù)據(jù)，其內(nèi)容在構(gòu)建之后也不會(huì)被改變。

鏡像就是一堆只讀層（read-onlylayer）的統(tǒng)一視角。如下圖所示，鏡像由多個(gè)只讀層

組成，除了最下面一層，具它層都會(huì)有一個(gè)指針指向下一層，每層疊加之后，從外部

看來(lái)就如同一個(gè)獨(dú)立的對(duì)象。這些層是Docker內(nèi)部的實(shí)現(xiàn)細(xì)節(jié)，并且能夠在主機(jī)的文

件系統(tǒng)上訪問(wèn)到。統(tǒng)一文件系統(tǒng)（unionfilesystem）技術(shù)能夠?qū)⒉煌膶诱铣梢粋€(gè)文

件系統(tǒng)，為這些層提供一個(gè)統(tǒng)一的視角，這樣就隱藏/多層的存在，在用戶的角度看

來(lái)，只存在一個(gè)文件系統(tǒng)。

圖1-5Docker鏡像

91e54dfb11790B

d74508fb66321.895KB

c22013c84729194.5KB

d3a1f33e8a5a188.1MB

Ubuntu:15.04

Image

root@29fi4375e9k6:/#Is

Bindevhomelib64mntprocrunsrvBHffvar

Bootetclibmediaoptrootsbinsysuser

Container（容器）

容器的定義和境像幾乎一模一樣，也是一堆層的統(tǒng)一視角，唯一區(qū)別在于容器的最上

面那一層是可讀可寫的，所以實(shí)際上，容器:鏡像+讀寫層。創(chuàng)建新的容器時(shí)，會(huì)在基

礎(chǔ)層之上增加一個(gè)讀寫層，這一層通常稱為“容器層二對(duì)運(yùn)行中容器的所有更改，例

如寫入新文件.修改現(xiàn)有文件或者刪除文件等，都將寫入這個(gè)薄的讀寫層。

圖1~6Container(容器)

ThinR/W丁La丁yer一丁一ContainerLayer

91e54dfb11790B

d74508fb66321.895KB

ImageLayers

c22013c84729194.5KB(R/0)

d3a1f33e8a5a188.1MB

Ubuntu:15.04

Container

(basedonUbuntu:15.04image)

容器和鏡像之間的主要區(qū)別是最頂上的讀寫層。在容器中添加新數(shù)據(jù)或修改現(xiàn)有數(shù)據(jù)

的所有寫操作都存儲(chǔ)在這個(gè)讀寫層中。刪除容器后，讀寫層也會(huì)被刪除，但是鏡像保

持不變。正因?yàn)槊總€(gè)容器都有自己的讀寫層，并且所有更改都存儲(chǔ)在該讀寫層中，所

以多個(gè)容器可以共享同一個(gè)鏡像，但擁有自己的數(shù)據(jù)狀態(tài)。

圖1-7容器與鏡像

Repository(倉(cāng)庫(kù))

Docker倉(cāng)庫(kù)是集中存放鏡像文件的場(chǎng)所。鏡像構(gòu)建完成后，可以很容易的在當(dāng)前宿主

機(jī)上運(yùn)行，但是，如果其它服務(wù)器也需要使用這個(gè)鏡像，我們就需要一個(gè)集中的存

儲(chǔ)、分發(fā)鏡像的服務(wù)，DockerRegistry(倉(cāng)庫(kù)注冊(cè)服務(wù)器)就是這樣的服務(wù)。Docker倉(cāng)庫(kù)

的概念跟Git類似，注冊(cè)服務(wù)器可以理解為GilHub這樣的托管服務(wù)。實(shí)際上，一個(gè)

DockerRegistry中可以包含多個(gè)倉(cāng)庫(kù)(Repository),每個(gè)倉(cāng)庫(kù)可以包含多個(gè)標(biāo)簽

(Tag),每個(gè)標(biāo)簽對(duì)應(yīng)著一個(gè)鏡像。所以說(shuō)，鏡像倉(cāng)庫(kù)是Docker用來(lái)集中存放鏡像文

件的地方類似于我們常用的代碼倉(cāng)庫(kù)。

通常，一個(gè)倉(cāng)庫(kù)會(huì)包含同一個(gè)軟件不同版本的鏡像，而標(biāo)簽就常用于對(duì)應(yīng)該軟件的各

個(gè)版本。我們可以通過(guò)〈倉(cāng)庫(kù)名＞：＜標(biāo)簽》的格式來(lái)指定具體是這個(gè)軟件哪個(gè)版本的鏡

像，如果不給出標(biāo)簽，將以latest作為默認(rèn)標(biāo)簽。

圖1-8Docker倉(cāng)庫(kù)

上面這張圖包含了Docker的所有元素，Docker使用Cliem/Server架構(gòu)。Docker客戶

端與Docker服務(wù)器進(jìn)行交互，Docker服務(wù)端負(fù)責(zé)構(gòu)建、運(yùn)行和分發(fā)Docker鏡像。

Dockerdeamon監(jiān)聽(tīng)著客戶端的請(qǐng)求，并且管理著docker的鏡像、容器、網(wǎng)絡(luò)、磁盤

等對(duì)象.Docker客戶端和服務(wù)端可以運(yùn)行在一臺(tái)機(jī)器上，也可以通過(guò)RFSTfnl或網(wǎng)絡(luò)

接口與遠(yuǎn)程Docker服務(wù)端進(jìn)行通信。

1.1.5Docker網(wǎng)絡(luò)介紹

None模式

顧名思義，none網(wǎng)絡(luò)就是什么都沒(méi)有的網(wǎng)絡(luò),none模式下的容器除了loopback口，沒(méi)

有其他任何網(wǎng)卜。容器創(chuàng)建時(shí)，可以通過(guò)-nelwork=none指定使用none網(wǎng)絡(luò)。使用

none網(wǎng)絡(luò)模式，通常是對(duì)安全性要求高，并且不需要聯(lián)網(wǎng)的應(yīng)用。

linux-72gS:~-dockerrun-it--namebusybox_rest--network=nonebusybox:1.28

/#ifeonfig

loLinkencap:LocalLoopback

inetaddr:Mask:

inet6addr:::1/128scope:Host

UPLOOPBACKRUNNINGMTU:65536Metric:!

RXpackets:0errors:0dropped:0overruns:0frame:0

TXpackets:0errors:0dropped:0overruns:0carrier:0

collisions:?txqueuelen:l

RXbytes:0(0.0B)TXbytes:0(0.0B)

I?

Bridge模式

Bridge模式是docker默認(rèn)的網(wǎng)絡(luò)模式，同一宿主機(jī)容器直接在網(wǎng)橋上互通，如果需要

實(shí)現(xiàn)跨主機(jī)容器互通，則需要使用overlay或者macvlan網(wǎng)絡(luò)。Bridge模式卜，容器訪

問(wèn)外網(wǎng)、外網(wǎng)訪問(wèn)容器都是通過(guò)NAT實(shí)現(xiàn)。Bridge模式如圖所示：

?容器訪問(wèn)外網(wǎng)：通過(guò)Linux的iptables將容器IP做SNAT（源地址轉(zhuǎn)換）轉(zhuǎn)換成宿

主機(jī)的IP，宿主機(jī)具有訪問(wèn)外網(wǎng)的能力，

?外部訪問(wèn)容器：docker可將容器對(duì)外提供服務(wù)的端口映射到宿主機(jī)上的某個(gè)端

口，外網(wǎng)通過(guò)宿主機(jī)的IP和端口號(hào)訪問(wèn)容器。

圖1-9Bridge模式

Docker安裝時(shí)會(huì)創(chuàng)建一個(gè)名為dockerO的Linuxbridge,如果不指定-network,新建的

容器會(huì)自動(dòng)橋接到docked）上。如下圖所示，當(dāng)前docked）上沒(méi)有任何其他網(wǎng)絡(luò)設(shè)備，

我們創(chuàng)建?個(gè)容器看看有什么變化。

linux-ol69:~?brctlshow

bridgenamebridgeidSTPenabledinterfaces

dockerO8000.0242fdfa8fdfno

創(chuàng)建容器后，一個(gè)新的網(wǎng)絡(luò)接口veth85e781被掛到了dockerO上，veth85傷781就是新

創(chuàng)建容器的虛擬網(wǎng)卡，并且剛才創(chuàng)建的容器被分到了一個(gè)IP地址/16。

linux-ol69:~#dockerrun-dbusybox:l.28sleep3600

83310d7345ec5861a3880eb7a4c42fl9db6a7655a7bl80758f29dd0127572a07

linux-ol69:~#brctlshow

bridgenamebridgeidSTPenabledinterfaces

dojckerO________8000,0242fdfa8fdf_______no______________veth81f9Z81

Iinux-ol69:~?dockerexec-it8331Od7345ecsn

/#ifconfig

ethOLinkencap：EthernetHWaddr02:42:AC:11:00:02

inetaddr:Beast:Mask:

inet6addr:fe80::42:acff:fell:2/64scope:Link

UPBROADCASTRUNNINGMULTICASTMTU：1500Merric：l

RXpackets:10errors:0dropped:0overruns:0frame:0

TXSpackets:8errors:0dropped:0overruns:0carrier:0

iisions:0txqueuelen:0

RXbytes:828(828.0B)TXbytes:648(648.0B)

loLinkencap:LocalLoopback

inetaddr:Mask:

inet6addr:::1/128scope:Host

UPLOOPBACKRUNNINGMTU：65536Metric：l

RXpackets:0errors:0dropped:0overruns:0frame:0

TXpackets:0errors:0dropped:0overruns:0carrier:0

collisions:0txqueuelen:l

RXbytes:0(0.0B)TXbytes:0(0.0B)

/#

Host模式

Host網(wǎng)絡(luò)模式需要在容器創(chuàng)建時(shí)指定--network二host,host模式可以讓容常共享宿主

機(jī)網(wǎng)絡(luò)協(xié)議棧,容器的網(wǎng)絡(luò)配置與宿主機(jī)完全一樣，這樣的好處是外部主機(jī)與容器直

接通信，但是容器的網(wǎng)絡(luò)缺少隔離性。

圖1-10Host網(wǎng)絡(luò)模式

直接使用host網(wǎng)絡(luò)的最大好處就是性能，如果容器對(duì)?網(wǎng)絡(luò)的傳輸效率有較高要求，則

可以選擇host網(wǎng)絡(luò)。不便之處就是要犧牲一些靈活性，比如需要考慮端口沖突問(wèn)題，

宿主機(jī)上已經(jīng)使用的端口就不能再用了。

Iinux-72g5:~fdockerrun-it--namebusybox_test--network=hostbusybox:1.28

/#ifconfig

dockerOLinkencap:EthernetHwaddrO2:42:7A：3O:32:5C

inetaddr:172.17.0.1Beast:0.0.0.0Mask:2SS.255.0.0

UPBROADCASTMULTICASTMTU：1500Metric：1

RXpackets:0errors:0dropped:。overruns:0frame:0

TXpackets:0errors:0dropped:0overruns:0carrier:0

collisions:?txqueuelen:0

RXbytes:0(0.0B)TXbytes:0(0.0B)

ethlLinkencap:EthernetHwaddr60：FA：90：DD：13：E1

inet6addr:fe80::62fa:9dff:fedd:13el/64scope:Link

UPBROADCASTRUNNINGMULTICASTMTU：1500Metric：l

RXpackets:570157errors:0dropped:0overruns:?frame:0

TXpackets:142553errors:0dropped:0overruns:?carrier:0

collisions:。txqueuelen:i000

RXbytes：194994217(185.9MiB)TXbytes：48751187(46.4MiB)

eth6Linkencap:EthernetHwaddrDC:99:14:01:8B：65

inetaddr:192.152.80.231Bcast:192.152.80.255Mask:

inet6addr:fe80::de99:14ff:fe01:8b65/64scope:Link

UPBROADCASTRUNNINGMULTICASTMTU：1500Metric：1

RXpackets:2026S141errors:0dropped:17O2941overruns:?frane:0

TXpackets:11659038errors:0dropped:。overruns:0carrier:0

collisions:?txqueuelen:1000

RXbytes：5078173345(4.7GiB)TXbytes：1234016584(1.1GiB)

kniOLinkencap:EthernetHwaddrC6:8E：24：ED：B0：F9

inetaddr:32.32.32.2Beast:32.J2.32.15Mask:40

inet6addr:fe80::c48e:24ff:feed:bOf9/64scope:Link

UPBROADCASTRUNNINGMULTICASTMTU：1500Metric：1

RXpackets:?errors:0dropped:?overruns:?frame:0

TXpackets:7errors:Odropped:0overruns:0carrier:0

collisions:?txqueuelen:1000

RXbytes:0(0.0B)TXbytes:818(818.0B)

loLinkencap:LocalLoopback

inetaddr:127.0.0.1Mask:255.0.0.0

inet6addr:::1/128Scope:Host

UPLOOPBACKRUNNINGMTU：65536Metric：1

RXpackets:100369593errors:0dropped:?overruns:0frame:0

TXpackets:100369593errors:0dropped:0overruns:0carrier:0

collisions:?txqueuelen:l

RXbytes:7603860529(7.0GiB)TXbytes:7603860529(7.0GiB)

MappedContainer模式

MappedContainer模式是一種較為特別的網(wǎng)絡(luò)模式，它可以使兩個(gè)或多個(gè)容器共享一個(gè)

網(wǎng)絡(luò)棧，共享網(wǎng)卡和配置信息，但是容器的文件系統(tǒng)、進(jìn)程和其他資源都是隔離開(kāi)

的。

圖1-11MappedContainer模式

HOST1

這里先創(chuàng)建一個(gè)busybox容器，名字為busybox1,可以看到容器分到了IP地址

/24。

linux-ol69:~#dockerrun-d--name=busyboxlbusybox:1.28sleep3600

0212cd32d516457d8b7bl264fc66bb3196a9c973de3d0a371a022b95ee509911

1inux-ol69:~#dockerexec-it0212cd32d516sh

/#ifconfiq

ethoLinkencap:EthernetHwaddr02:42:AC:11:00:02

inetaddr:Beast:Mask:

inet6addr:fe80::42:acff:fell:2/64scope：Link

UPBROADCASTRUNNINGMULTICASTMTU：1500Metric：l

RXpackets:10errors:0dropped:0overruns:?frame:0

TXpackets:8errors:0dropped:0overruns:0carrier:0

collisions:。txqueuelen:0

RXbytes:828(828.0B)TXbytes:648(648.0B)

loLinkencap:LocalLoopback

inetaddr:Mask:

inet6addr:::1/128scope:Host

UPLOOPBACKRUNNINGMTU：65536Metric：l

RXpackets:0errors:0dropped:0overruns:0frame:0

TXpackets:0errors:0dropped:0overruns:0carrier:。

collisions:。txqueuelen:l

RXbytes:0(0.0B)TXbyres:0(0.0B)

#exit

linux-ol69:~?

隨后再創(chuàng)建名為busybox2的容器，并通過(guò)-network=container：busybox1指定加入

busyboxl的網(wǎng)絡(luò)協(xié)議棧?？梢钥吹?，這兩個(gè)容微網(wǎng)卡IP和MAC地址完全一樣，他們

共享了同一個(gè)網(wǎng)絡(luò)協(xié)議棧，并且可以通過(guò)127.O.O.1訪問(wèn)彼此提供的服務(wù)。

linux-ol69:~?dockerrun-d--network-container:bu>yboxl--name?busybox2busybox:1.28sleep3600

4d9e3ele68384576Scb9a86eflfO4e29O7b5OOel3bf7O7658c43271Of4ee2579

linux-ol69:~?

1inux-ol69:~?dockerexec-it4d9e3ele68