CloudFabric云数据中心网解决方案-容器网络设计指南

CloudFabric云数据中心网解决方案

设计指南（容器网络）

目录

1容器技术简介..........1

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

1.1.1容器依赖的底层技术........................................................................1

1.1.2容器原理简介..............................................................................2

1.1.3容器运行时................................................................................3

1.1.4Docker基础................................................................................5

1.1.5Docker网2各介名召............................................................................9

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

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

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

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

1.2容器技术与虚拟机...........................................................................14

1.3容器技术的发展趋势.........................................................................17

1.4容器技术的应用场景.........................................................................19

1.4.1PaaS平台建设.............................................................................19

1.4.2容器即服务...............................................................................19

1.4.3持续集成和发布...........................................................................20

2Kubernetes介绍...............................21

2.1容器集群管理技术的发展....................................................................21

2.2K8s组件架构..............................................................................22

2.3K8s业务模型...............................................................................24

2.4K8S网络需求..............................................................................27

2.4.1K8S网络三原贝ij.......................................................................................................................................................27

242K8s网络实现方式：CNI接匚................................................................27

2.4.3K8S网络典型实现模型......................................................................28

L2桥接.................................................................................29

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

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

2.43.4总结....................................................................................34

3CloudFabric容器网络方案........................35

3.1容器网络带来的挑战.......................................................................35

3.1.1控制面挑战...............................................................................35

3.1.2转发面挑战...............................................................................36

3.2裸机容器与虚机容器对比...................................................................36

3.3CloudFabric容器网络方案概述...............................................................38

3.3.1容器网络组件介绍.........................................................................38

3.3.2容器网络与物理网络联动...................................................................39

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

NetworkOverlay方案架构.................................................................41

3.323L2桥接，L3路由方案对比分析.............................................................45

3.4容器网络组网设计.........................................................................45

3.4.1容器网络推荐组网.........................................................................45

3.4.1.1管理面、数据面独立网卡.................................................................45

管理面、数据面共网卡...................................................................46

3.4.2L3路由模式路由发布......................................................................47

关闭BGP路由抑制.......................................................................48

3A2.2开启BGP路由抑制.......................................................................50

3.4.3K8S集群内Pod东西向流量互访.............................................................51

NetworkOverlayL2桥接...................................................................51

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

3.4.4K8S集群内外南北向流量互访...............................................................52

NetworkOverlayL2桥接...................................................................52

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

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

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

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

3.5容器网络自动化设计.......................................................................57

3.5.1容器平台对接控制器.......................................................................57

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

安装华为CNI插件.......................................................................59

351.3安装华为iMasterNCE-Fabric插件...........................................................59

3.S.2业务发放流程.............................................................................60

NetworkOverlayL2桥接模式业务部署......................................................60

NetworkOverlayL3路由模式业务部署......................................................64

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

.2容器IP随机分配........................................................................66

3.5.3方案约束..................................................................................69

3.6容器网络安全设计...........................................................................70

3.6.1容器网络安全总体设计.....................................................................70

3.6.2容器网络策略.............................................................................70

NetworkPolicy实现原理...................................................................70

CloudFabric容器网络策略.................................................................71

3.7容器网络运维设计..........................................................................74

3.7.1NetworkOverlayL2桥接....................................................................74

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

3.7.3普罗米修斯工具监控CE1800V..............................................................................................................................75

3.8容器网络对接CCE开源Calico方案...........................................................77

4容器网络部署最佳实践…….......................................79

A参考图片..........................................81

容器技术简介

1.1容器是什么

1.2容器技术与虚拟机

1.3容器技术的发展趋势

1.4容器技术的应用场景

1.1容器是什么

1.1.1容器依赖的底层技术

容器底层的核心技术包括Linux的Namespace和Cgroupo

Namespace

Linux支持6种namespace,简要介绍如F：

•主机和域名空间(UNIXTimesharingSystem)：每个容器拥有独立的hostname

和domainname,使其在网络上可以被视作一个独立的节点而非主机上的一个进

程；

•进程间通信空间(Inter-ProcessCommunication)：容器中进程交互还是采用了

Linux常见的交互方法，通过共享内存、信号量、消息队列和管道等方法实现，

在新的IPCnamespace中创建IPC,并不会与其他应用发生冲突：

•进程ID空间(ProcessID)：使得不同PIDnamespace里的进程ID可以重复且相

互之间不影响；

•文件系统空间(Mountnamespace)：用来隔离文件系统的挂载点，使得不同的

mountnamespace拥有自己独立的挂载点信息，不同的namespace之间不会相互影

响，这对手构建用户或者容器自己的文件系统目录非常有用；

•网络协议栈空间(Networknamespace)：每个Networknamespace都有自己独立

的网络栈,路由表，防火墙规则，socka等；

•用户空间(USERnamespace)：用来隔离user权限相关的Linux资源，包括user

IDs,groupIDs,keys,capabilitieso

Cgroup

Linux的namespace主要解决了环境隔离问题，这只是虚拟化中最最基础的一步，我们

还需要解决对计算机资源使用上的隔离，这就是Cgroup要做的事情。LinuxCgroup全

称LinuxControlGroup,是Linux内核的一个功能，向来限制、控制与分离一个施程

组群的资源（如CPU时间、内存、网络带宽、磁盘输入输出等）。这个项目最早是由

Google的「程师在2006年发起，最早的名称为进程容器（processcontainers）。在

2007年时，因为在Linux内核中,容器（container）这个名词太过广泛,为避免混

乱，被重命名为cgroup,并且被合到了2.6.24版的内核。

LinuxCgroup可为系统中所运行的任务（进程）进行分组，并在分组的基础上对进程

进行资源控制.比如CPU时间、系统内存、网络带宽或者这些资源的组合，还可以

监控所配置的Cgroup,拒绝Cgroup访问某些资源，甚至在运行的系统中动态配置

Cgroup.使用Cgroup,系统管理员可更具体地控制对系统资源的分配、优先顺序、拒

绝、管理和监控，可更好地根据任务和用户分配硬件资源，提高总体效率。

图1-1LinuxCgroup示意图

Cgroup2

112容器原理简介

容器本身并不是全新的虚拟化技术，事实上它只是操作系统虚拟化技术的一种，它本

质上是使用/Linux的namespace实现资源隔离和Cgroup实现资源限制，彼此间相互

隔离的若干个linux进程的集合。

容器共享宿主机操作系统内核，通过宿主操作系统提供相互隔离的运行环境。每个容

器包含括独立的文件系统空间（MNTNS）,主机和域名空间（UTSNS）,进程间通信

空间（IPCNS）,进程ID空间（PIDNS）,网络协议栈空间（NETNS）,用户空间

（USERNS）。

图1-2容器与操作系统

1.1.3容器运行时

我们所说的容器运行时，准确来说包含两部分，一部分是上层容器运行时CRIshim

（即容器运行时管理程序，如Contained、CRI-O）,另一部分是下层容器运行时

Containerruntime（即容器运行时命令工具,如rune）。Kubernetes在引入CRI之后,

Kubelel的架构如下图所示。

图1-3Kubclct的架构

CRI（ContainerRuntimeInterface容器运行时接口）

Kubernetes如今已经成为容器编排调度领域的事实标准，其优良的架构不仅保证了丰

富的容器编排调度功能，同时也提供了各个层次的扩展接口以满足用户的定制化需

求。容器运行时作为Kubernetes管理和运行容器的关键组件，当然也提供了简便易用

的扩展接口，也就是CRI。CRI接口分为两部分，一个是容器运行时服务

RuntimeService＞负责管理pod和容器的生命周期；一个是镜像服务ImageService,

负责管理镜像的生命周期。

其实，Kubernetes在vl.5版本之前是没有CRI接口的,那时Kubclct源码内部只集成

了两个容器运行时（Docker和rkt）的相关代码。这两种容器运行时并不能满足所有用

户的使用需求.在某些业务场景，用户对容器的安全隔离性有着更高的需求，用户希

望Kubernetes能支持更多种类的容器运行时。因此，Kubernetes在1.5版本推出\CR!

接口，各个容器运行时只要实现了CRI接口规范，就可以接入到Kubernetes平台为用

户提供容器服务。CRI隔离了各个容器运行时之间的差异，通过统一的接口与各个容

器运行时之间进行交互，定义了容器生命周期的管理，促进了容器运行时社区的繁

荣，也为强隔离、多租户等复杂的场景带来更多的选择。当前实现了CRI的主流项目

有以下几种：

1.默认安装Kubemetes,kubelet已经内嵌dockershim(适配CRI),它接收到CRI

请求转化后发给docker处理，这也是目前非常成熟的方案；

2.Containerd项目是从早期的Docker源码中提炼出来的，它使用CRI插件来向

kubelet提供CRI接口服务；

3.CRLO完整实现CRI接口功能.CRLO比Conlainerd更专注,它只服务干

Kubernetes,Fl前由redhat主导；

4.Frakli是一个基于KubelelCRI的实现，Kubernetes官方维护的一个项目，它提供

了hypervisor级别的隔离性，但当前社区并不活跃。

图14CRI

OCI(OpenContainerInitiative开放容器标准)

为了保证容器生态的健康发展，保证不同的容器之间能够兼容。2015年，由Docker、

IBM、微软、红帽及Google等厂商所组成的OCI联盟成立，并于2016年4月推出了

第一个开放容器标准。0CI规范包含两部分内容：容器运行时标准(runtimespec)、容

器镜像标准(imagespec)。runtimespec包含配置文件、运行环境、生命周期三部分内

容。imagespec对容器镜像格式做了定义，它主要包括文件系统、config文件、

manifest文件、index文件。当前主流的兼容OCI规范的容器运行时项目有以下几种：

表1-1主流的兼容OCI规范的容器运行时项目

OCI-功能特性

runtime

runC基J-namespace和Cgroup实现的资源隔离和限制，docker容器引擎默

认的运行时

OCI-功能特性

runtime

runV基于hypervisor实现的、兼容OCI规范的虚拟机容器运行时

kata整合了Intel的ClearContainer和Hypcr.sh的runV,兼容OCI规范的

container轻量级虚拟机容器运行时，支持不同平台的硬件（x86_64,ARM,

IBM等）

gVisor新型sndhox技术,比虚拟机容器运行时更轻量化,在sandhex中运行

自己的虚拟内核，拦截从应用程序到主机内核的所有系统调用，为它

们提供隔离，但付出的代价是系统调用性能比较差，资源消耗多

1.1.4Docker基础

Docker属于Linux容器的一种封装，提供简单易用的容器使用接LI,它是目前最流

行的Linux容器解决方案。Docker将应用程序与该程序的依赖打包在一个文件里

面，运行这个文件，就会生成一个虚拟容器c程序在这个虚拟容器里运行，就好像在

真实的物理机上运行一样。

Docker包括三个基本的概念：Image（镜像）,Container（容器）,Repository（仓库）。

Image（镜像）

Docker镜像可以看作是一个特殊的文件系统，除了提供容器运行时所需的程序、库、

资源、配置等文件外，还包含了一些为运行E寸准备的配置参数（如匿名卷、环境变

量、用户等）。镜像不包含任何动态数据，其内容在构建之后也不会被改变。

镜像就是一堆只读层（read-onlylayer）的统一视角。如下图所示，镜像由多个只读层

组成，除了最下面一层，具它层都会有一个指针指向下一层，每层叠加之后，从外部

看来就如同一个独立的对象。这些层是Docker内部的实现细节，并且能够在主机的文

件系统上访问到。统一文件系统（unionfilesystem）技术能够将不同的层整合成一个文

件系统，为这些层提供一个统一的视角，这样就隐藏/多层的存在，在用户的角度看

来，只存在一个文件系统。

图1-5Docker镜像

91e54dfb11790B

d74508fb66321.895KB

c22013c84729194.5KB

d3a1f33e8a5a188.1MB

Ubuntu:15.04

Image

root@29fi4375e9k6:/#Is

Bindevhomelib64mntprocrunsrvBHffvar

Bootetclibmediaoptrootsbinsysuser

Container（容器）

容器的定义和境像几乎一模一样，也是一堆层的统一视角，唯一区别在于容器的最上

面那一层是可读可写的，所以实际上，容器:镜像+读写层。创建新的容器时，会在基

础层之上增加一个读写层，这一层通常称为“容器层二对运行中容器的所有更改，例

如写入新文件.修改现有文件或者删除文件等，都将写入这个薄的读写层。

图1~6Container(容器)

ThinR/W丁La丁yer一丁一ContainerLayer

91e54dfb11790B

d74508fb66321.895KB

ImageLayers

c22013c84729194.5KB(R/0)

d3a1f33e8a5a188.1MB

Ubuntu:15.04

Container

(basedonUbuntu:15.04image)

容器和镜像之间的主要区别是最顶上的读写层。在容器中添加新数据或修改现有数据

的所有写操作都存储在这个读写层中。删除容器后，读写层也会被删除，但是镜像保

持不变。正因为每个容器都有自己的读写层，并且所有更改都存储在该读写层中，所

以多个容器可以共享同一个镜像，但拥有自己的数据状态。

图1-7容器与镜像

Repository(仓库)

Docker仓库是集中存放镜像文件的场所。镜像构建完成后，可以很容易的在当前宿主

机上运行，但是，如果其它服务器也需要使用这个镜像，我们就需要一个集中的存

储、分发镜像的服务，DockerRegistry(仓库注册服务器)就是这样的服务。Docker仓库

的概念跟Git类似，注册服务器可以理解为GilHub这样的托管服务。实际上，一个

DockerRegistry中可以包含多个仓库(Repository),每个仓库可以包含多个标签

(Tag),每个标签对应着一个镜像。所以说，镜像仓库是Docker用来集中存放镜像文

件的地方类似于我们常用的代码仓库。

通常，一个仓库会包含同一个软件不同版本的镜像，而标签就常用于对应该软件的各

个版本。我们可以通过〈仓库名＞：＜标签》的格式来指定具体是这个软件哪个版本的镜

像，如果不给出标签，将以latest作为默认标签。

图1-8Docker仓库

上面这张图包含了Docker的所有元素，Docker使用Cliem/Server架构。Docker客户

端与Docker服务器进行交互，Docker服务端负责构建、运行和分发Docker镜像。

Dockerdeamon监听着客户端的请求，并且管理着docker的镜像、容器、网络、磁盘

等对象.Docker客户端和服务端可以运行在一台机器上，也可以通过RFSTfnl或网络

接口与远程Docker服务端进行通信。

1.1.5Docker网络介绍

None模式

顾名思义，none网络就是什么都没有的网络,none模式下的容器除了loopback口，没

有其他任何网卜。容器创建时，可以通过-nelwork=none指定使用none网络。使用

none网络模式，通常是对安全性要求高，并且不需要联网的应用。

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默认的网络模式，同一宿主机容器直接在网桥上互通，如果需要

实现跨主机容器互通，则需要使用overlay或者macvlan网络。Bridge模式卜，容器访

问外网、外网访问容器都是通过NAT实现。Bridge模式如图所示：

•容器访问外网：通过Linux的iptables将容器IP做SNAT（源地址转换）转换成宿

主机的IP，宿主机具有访问外网的能力，

•外部访问容器：docker可将容器对外提供服务的端口映射到宿主机上的某个端

口，外网通过宿主机的IP和端口号访问容器。

图1-9Bridge模式

Docker安装时会创建一个名为dockerO的Linuxbridge,如果不指定-network,新建的

容器会自动桥接到docked）上。如下图所示，当前docked）上没有任何其他网络设备，

我们创建•个容器看看有什么变化。

linux-ol69:~♦brctlshow

bridgenamebridgeidSTPenabledinterfaces

dockerO8000.0242fdfa8fdfno

创建容器后，一个新的网络接口veth85e781被挂到了dockerO上，veth85伤781就是新

创建容器的虚拟网卡，并且刚才创建的容器被分到了一个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网络模式需要在容器创建时指定--network二host,host模式可以让容常共享宿主

机网络协议栈,容器的网络配置与宿主机完全一样，这样的好处是外部主机与容器直

接通信，但是容器的网络缺少隔离性。

图1-10Host网络模式

直接使用host网络的最大好处就是性能，如果容器对•网络的传输效率有较高要求，则

可以选择host网络。不便之处就是要牺牲一些灵活性，比如需要考虑端口冲突问题，

宿主机上已经使用的端口就不能再用了。

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模式是一种较为特别的网络模式，它可以使两个或多个容器共享一个

网络栈，共享网卡和配置信息，但是容器的文件系统、进程和其他资源都是隔离开

的。

图1-11MappedContainer模式

HOST1

这里先创建一个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:~♦

随后再创建名为busybox2的容器，并通过-network=container：busybox1指定加入

busyboxl的网络协议栈。可以看到，这两个容微网卡IP和MAC地址完全一样，他们

共享了同一个网络协议栈，并且可以通过127.O.O.1访问彼此提供的服务。

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

4d9e3ele68384576Scb9a86eflfO4e29O7b5OOel3bf7O7658c43271Of4ee2579

linux-ol69:~♦

1inux-ol69:~♦dockerexec-it4d9e3ele68