容器网络流量研究教授20篇

容器网络流量研究教授20篇容器网络流量研究教授　　从容器到微服务，技术架构、网络和生态详解　　谈起容器技术，不得不提Docker技术。　　Docker是PaaS提供商DotCloud下面是小编为大家整理的容器网络流量研究教授20篇,供大家参考。

篇一：容器网络流量研究教授

　　从容器到微服务，技术架构、网络和生态详解

　　谈起容器技术，不得不提Docker技术。

　　Docker是PaaS提供商DotCloud开源的一个高级容器引擎，源代码托管在Github上，基于Go语言并遵从Apache2.0协议开源。Docker相当于物理行业的集装箱对物流的影响一样，成为Container上运行镜象的统一打包和交换的标准。

　　我们知道，Docker使用了容器的环境隔离和资源限制技术，把镜像和运行环境打包到Image中。Register支持容器上传和下载功能。

　　Docker同时提供了Build，Ship和Run，运维只需要在环境重配置好Docker，剩下的工作就是部署容器，实现BuildOnceRunAnywhere和ConfigureOnceRun

　　Anything；从而促进了容器技术的爆发。

　　在架构上，Docker采用ClientServer模式和插件式架构设计，Docker的后端采用非常松耦合的架构，模块之间相互独立，用户通过DockerClient与DockerDaemon建立通信，并发送请求给DockerDaemon。

　　DockerDaemon提供Server功能接受DockerClient的请求；随后通过Engine执行Docker内部的一系列工作，每项工作都是以一个Job的形式的存在。

　　Docker讲底层容器运行时剥离出来，实现更好的平台无关性。LibContainer是对各种容器的抽象，发展为RunC，并贡献给OCP组织作为定义容器环境的标准。Docker容器的三大编排工具，Compose、Swarm和Machine。Compose是服务编排工具，是定义和运行Docker主机上多容器应用的工具，通过单独文件，定义多容器应用并运行容器。

　　Docker的网络技术和能力一直是容器技术中最难、也是最不看好的技术之一，Libnetwork是Docker公司正在开发的新的网络底层架构，由libcontainer和DockerEngine中的网络相关的代码合并而成。Libnetwork的目标是引入了容器网络模型(CNM)，并为应用程序提供一致的编程API接口以及网络抽象。Libnetwork的容器网络模型包含了三个重要概念，NetworkSandbox，Endpoint和Network。

　　Weave创建了NetworkingPlugin技术，目前成熟的有NetworkingPlugin和VolumePlugin。

　　Weave方案包含两大组件，用户态Shell脚本和Weave虚拟路由容器。Weave虚拟路由容器需要在每个宿主机上布置第三方插件，把不同宿主机的Route容器连接起来，使得Docker工具生态无缝集成到Docker。(其他网络方案介绍，请参看<容器技术架构、网络和生态详解>电子书)

　　Weave创建一个虚拟网络，链接多个主机的Docker容器，并使他们可以被自动发

　　现，对使用该网络的应用来说，所以容器就像是链接在同一个网络交换机上，无需配置端口映射、链路等参数。

　　容器和容器OS

　　CoreOS是最为受欢迎的容器虚拟化OS，专为Docker设计和内核裁剪。CoreOS中有两个关键容器集群管理工具，etcd主要实现集群服务发现、信息共享和数据同步；而Fleet实现集群状态维护、容器操作和确保服务一致可用。

　　VMware也推出了容器OS系统Photon，在VMware上创建VM，并且安装Photon系统即可部署运行容器，并且支持目前主流的Docker、Rkt和PGC容器平台。Photon可以容器管理认证工具Lightwave配合，可以实现更好的权限管理。

　　Docker容器和存储

　　Docker容器在数据读写和存储上，是采用分层和COW的存储技术实现，Docker本身的COW文件系统不支持数据持久保存，在容器被删除或重启后，之前的文件更改就会丢失(变化的数据被以COW写到一个新的位置)。

　　Volume的引入虽然解决了数据丢失问题，但是当容器迁移后，数据卷无法跟随Docker容器一起迁移，ClusterHQ的Flocker的出现恰恰解决Volume的不足，使得数据跟随Docker迁移。

　　Flocker的容器和存储卷迁移分为全迁移和增量同步两个过程，配置文件描述Docker部署方式和状态，运行配置则生效(迁移Redis)；以迁移本地存储(非共享存储)为例，整个过程为先打快照，全迁移，增量同步。

　　Flocker以DockerVolumePlugin的方式部署在Docker中，与Docker集成。目前共享存储的支持能力比较成熟，支持的产品包括AWSEBS、ScaleIO和XtremIO等，并且支持如AWS、Rackspace等云平台；本地存储方式在技术成熟度上并不高。

　　Flocker通过StorageDriver屏蔽存储差异，并通过存储提供的Flocker标准接口实现对底层存储操作，当主机容器在不同主机间迁移时，Flocker只需要对容器的Volume进行主机的重映射。

　　Docker与PaaS

　　随之容器的发展，CaaS容器即服务的概念也应时而生，其大意就是基础设施以容器的方式来供给给应用使用。以容器为单位成为PaaS的共识，基于Docker的容器打包和分发有望成为PaaS平台的标准,Docker将大幅拓宽PaaS的应用范围，并促进PaaS的快速发展。

　　基于容器的打包一统新一代PaaS，第三代PaaS，DEIS、Flynn等均基于Docker，挑战老的PaaS平台。

　　PaaS已经出现了数年时间，第一批是Azure和Heroku等公用云服务，之后出现的CloudFoundry和OpensShift允许用户建立自己的PaaS，包括了内部数据中心以及云环境。现在，第三代PaaS浪潮正在到来。

　　Flynn是一个开源的PaaS平台，可自动构建部署任何应用到Docker容器集群上运行，其功能特性与组件设计大量参考了传统的PaaS平台Heroku。Flynn目前还不是很稳定。但整个系统非常灵活，相互松耦合，便于任意组件的替换。

　　Docker与IaaS平台

　　主流IaaS云平台都支持Docker的运行(AWS、GoogleComputeEngine、Rackspace等)。Docker弥合了不同IaaS之间的差异，Docker的轻量和可移动性使得其比较适合用在HybridCloud中。降低了IaaS服务商用户粘性，使得跨云服务商迁移更加自由。从而使得IaaS服务商被管道化。如果Container把安全问题解决了，可能就会有比较大的变化。

　　出现基于Docker的ContainerasaService或OrchestrationasaService，如Tutum，可以避免IaaS的锁定，甚至不用关心是运行在物理设施上，还是运行在哪家IaaS平台上。

　　2014年6月Rackspace宣布和CoreOS合作提供BaremetalasaService方案OnMetal，结合了云计算的灵活性和基于container的高性能虚拟化，提供singletenantbaremetalcloudserivce。

　　这种模式将影响当前以虚拟机为核心的IaaS平台，预计后续可能出现同时提供DockeroverBaremetal、DockeroverVM和VM三种混合的资源分配和调度云平台。

　　Docker也引发了基于容器的应用集群管理平台，如Kubernetes得到了微软、红帽、IBM、Vmware、Docker、Mesosphere、CoreOS和SaltStack等多家厂商的支持。容器集群管理技术可能导致Openstack边缘化。

　　Docker与DevOps

　　基于Docker可以更好的实现DevOps。虽然有许多工具适合DevOps部署，使开发人员和操作更贴近，但Docker是一个与DevOps原则密切相关的框架。使用Docker，开发人员可以专注于他们的代码，而不必担心在生产环境中运行它们的负面影响。

　　DevOps团队可以将整个容器作为容器处理，文件系统和依赖关系管理的分层方法使得环境的配置更容易维护。在相同的源代码控制系统（如Git工作流程）中版本化和维护Dockerfiles使得它非常有效地管理多个开发/测试环境。不同环境的多个容器可以在同一VM上运行时被隔离。Docker还可以很好地使用现有的工具，如Jenkins，Chef，Puppet，Ansible，SaltStack，Nagios和Opsworks。

　　Docker有可能对DevOps生态系统产生重大影响。它可以从根本上改变开发人员和运营专业人员合作的方式。新兴DevOps公司，如CloudMunch，Factor.io，Drone.io可能必须采用Docker并将其带入他们的CI和CD解决方案。

　　Docker与微服务架构

　　基于Docker容器和其生态系统的微服务架构是下一代PaaS的核心，在Docker出现之前，虽然我们谈论微服务架构，但是其实是很难实现的。微服务要运行，首先需要一套执行的环境。这套环境不能对外部有依赖性。同时，执行环境的粒度又必须足够的小，这样才能称之为”微“，否则必然是对资源的巨大浪费。

　　一个微服务可以跑在一台虚拟机上面，但是虚拟机粒度太大，即使最小的虚拟机，也至少也有1个核。服务一个用户的服务，显然用不了一个核。同时，虚拟机有没有一套方便的管理机制，能够快速的让这些服务之间能够组合和重构。

　　Docker出现以后，我们看到了微服务的一个非常完美的运行环境。一个容器就是一个完整的执行环境，不依赖外部任何的东西，具备独立性。一台物理机器可以同时运行成百上千个容器，粒度细。其计算粒度足够的小。容器可以在秒级进行创建和销毁，非常适合服务的快速构建和重组。数量众多的容器编排管理工具，能够快速的实现

　　服务的组合和调度。

　　从Docker到微服务

　　此篇文章通俗易懂讲解了Docker的概念和原理，但与微服务的知识海洋相比，这只是沧海一粟。微服务代表IT架构未来架构发展趋势和演进方向，目前已有大量关于微服务技术原理、实践总结和部署实施的文章，但对于初学者而言，零散学习并不能完全领会文章精髓，也无法构建完善的知识体系。

　　但值得庆幸的是，极客时间推出热门微服务课程，帮你从0开始构建微服务体系。具体来说，该专栏把微服务知识分为四个部分，帮助学习者循序渐进的掌握微服务知识。限时优惠，分享返现。具体每部分内容介绍如下:

　　第一部分，我会尽量用最通俗的语言去讲解微服务架构的基本原理，帮你解答三个问题：什

　　么是微服务？什么时候适合微服务改造？微服务架构到底是什么样的？

　　第二部分，我会结合在实际业务中的经验，给你讲述微服务架构改造过程中可能会遇到的问题和对应的解决方案，以及搭建微服务架构时，如何做技术选型。

　　第三部分，我会给你讲述微服务、容器化、DevOps这三者之间的关系，以及在具体实践中如何运用这三种技术以给业务的架构带来质的飞跃。

　　第四部分，我会给你介绍下一代微服务体系可能的发展方向，并分享作者对此的看法。

　　微服务也是当下移动互联网最火的后端架构之一，而专栏作者通过这几年亲自践行微服务的思想，使自己的技术水平不断提升，成长为一名技术专家。作为程序员的你，也一定渴望在技术的道路上不断进步，那么微服务能助力你纵身一跃，跳到优秀的架构师的行列。

篇二：容器网络流量研究教授

　　基于ELM的网络流量分类及可视化研究

　　陈幸如;魏书宁

　　【摘

　　要】精准的网络流量分类是网路流量监测和网络流量数据分析的重要基础.机器学习方法利用统计网络流量的各种特征,不依赖于协议端口和协议内容对网络流量数据进行分析.采用超限学习机(ELM)和改进算法分层超限学习机(H-ELM)作为机器学习的算法,识别客户端与服务器.对链路层、网络层和应用层数据进行分析,实现对多层次网络流量数据的可视化,对H-ELM和ELM算法的实验结果进行对比.实验结果表明,ELM算法能有效地应用于网络流量分类,基于ELM分类模型的网络流量识别训练速度快.H-ELM通过紧凑的特征去除冗余原始输入,改进了总体学习表现.

　　【期刊名称】《安徽师范大学学报（自然科学版）》

　　【年(卷),期】2018(041)002

　　【总页数】6页(P129-134)

　　【关键词】网络流量;超限学习机;分层超限学习机;数据可视化

　　【作

　　者】陈幸如;魏书宁

　　【作者单位】湖南师范大学

　　信息科学与工程学院,湖南

　　长沙410081;湖南师范大学

　　信息科学与工程学院,湖南

　　长沙410081

　　【正文语种】中

　　文

　　【中图分类】TP181

　　近代社会，由于科技的迅速发展，互联网的使用越来越普遍，使用范围越来越广，随着互联网的普及，大数据的云分布式处理技术成熟地发展，网络应用多元化已成为趋势。网络流量激增并且呈现多样化给网络管理带来挑战和压力，提高了网络流量管理的难度。网络流量分类在维持网络高效运行、预测网络服务类型和维护网络安全等许多方面发挥着越来越重要的作用。在TCP/IP协议中，端口号是应用程序识别通信的服务器和客户端的手段。源端口和目的端口皆为十六位的非负整数，它的范围是1至65535。一个客户端想要与服务器进行通信，需要一个端口号用来发送服务请求从服务器获得所需服务。根据LANA定制的知名端口号和注册端口号列表，LANA管理局规定的通信机制进行网络流量识别是基于端口网络流量识别技术的本质。传统的基于端口号以及网络载荷[1]的网络流量分析有其自身局限性和许多不可靠的因素，例如流行的P2P等新型网络应用利用随机，动态端口进行通信；还有一些采用隧道协议封装技术的应用。这些措施使得传统的网络流量分类方法失灵。不断更新发展的网络应用使利用端口进行网络流量分类技术的短板逐渐暴露。为了克服这些不足，已经应用在众多领域的机器学习方法引起了众人的关注[2][3][4]，机器学习[5][6]不依赖于端口号匹配和协议的解析，利用流特征对网络流量数据进行分类[7]。目前，基于网络流量统计特征的识别方法是一种新兴的网络流量分类方法，利用数据挖掘中机器学习算法，提取不同网络协议的统计特征，通过分类算法来训练网络流量分类模型。这种方法可以随着网络应用的更新重新训练新的分类模型。本文采用新加坡南洋理工大学黄广斌教授等人在2006年研究出的超限学习机(ExtremeLearningMachine，ELM)算法，在基于ELM算法上探究网络流量分类，并对网络流量做出可视化数据分析。

　　1基于机器学习的网络流量分类

　　1.1ELM算法理论

　　神经网络是一种有监督机器学习，基于已标注类型的样本集进行机器学习并建立分类规则，将未知数据分类成已知的类型。传统的神经网络算法有着各自的缺点，比

　　如：训练速度慢、网络更新迭代计算中容易陷入局部极小点、学习率敏感等。训练网络要想获得较好的性能，需要探索出一种训练快速、能达到全局最优解、具有良好泛化性的训练算法，这些性能目标也是现阶段研究的热点与难点。

　　超限学习机(ELM)算法是一种单隐层前馈神经网络(SLFNs)。ELM算法与传统BP神经网络不同点在于ELM算法的输入层与隐含层的连接权值w和隐含层神经元的阈值b都是随机产生的，由于后期训练中无需更新w和b，这个网络中无需设定过多的参数，只要确定了隐含层节点数便可获得唯一最优解。ELM的理论如下：

　　假设SLFNs有L个隐含层节点，对于输入向量x，SLFNs的输出可以由(1)式表示。其中，Gi是第i层隐含层节点激活函数，ai是连接输入层与第i层隐含层节点的输入权值向量，bi是第i层隐含层的偏置，βi是输出权值。

　　(1)对于激活函数g的附加节点，Gi定义为(2)式：

　　Gi(x,ai,bi)=g(bi+ai·x)

　　(2)对于具有激活函数g的径向基函数节点，Gi定义为(3)式：

　　Gi(x,ai,bi)=g(bi‖x-ai‖)

　　(3)黄广斌等人[8]已经证明了SLFNs可以逼近任意随机初始化自适应或者径向基函数节点的x∈Rd子集上的连续目标函数，随机生成的网络以最小均方得到的输出能够保持泛化逼近能力，甚至没有隐含层参数的更新。除此之外，ELM解决正则化最小二乘问题比标准支持向量机下解决二次规划问题或者梯度方法更快[8][9]。基于这种理论，ELM以快速学习而建立。从学习的角度来看，不同于传统学习算法，ELM理论旨在不仅达到最小训练错误而且达到最小规范化输出权值。

　　ELM算法不仅拥有良好的泛化性能，并且还具有通用逼近以及分类能力。相比于传统的神经网络算法，ELM不需要设置学习率，得到的输出权值是全局最优解，不会陷入局部最小值中且计算量小、训练速度快。这些优点是ELM算法被广泛地应用于模式识别、人机交互、疾病诊断、卫星图像实时远程遥感和网络安全等领域的原因。

　　1.2H-ELM框架

　　H-ELM(HierarchicalELM)是一种建立在多层方式上的算法，在随机特征映射和充分利用ELM的泛化逼近能力的基础上发展。如图1所示，可以看到H-ELM训练框架在结构上可以分为2个独立阶段：无监督分层特征表示和监督特征分类。在前一阶段，是用于提取输入数据多层稀疏特征的基于自编码的ELM。后一阶段原始分类ELM用于最终决策。

　　图1H-ELM结构框架

　　输入的原始数据被转换至ELM随机特征空间，每一个隐含层输出可以表示为

　　Hi=g(Hi-1·β)

　　(4)其中Hi是i层的输出，Hi-1是第i-1层的输出，g是隐含层激活函数，β是输出权值。H-ELM的每一层都是一个独立的模块，每一层的功能相当于功能提取器，随着层数的增加，特征会更加紧凑。一旦前一隐含层的特征被提取，本层的权值和参数被固定。

　　1.3基于流统计特征的ELM流量分类

　　已知数据中网络流数据集合F={F1,F2,…,Fn}，网络流的类型集合T={T1,T2,…,Ti}，利用pandas整理的一个n×(i+1)的.csv文件作为输入分类器的样本数据。其中，n为网络流数目，i为流属性数目。根据统计的流特征，利用已知的网路流类型集合去训练ELM分类模型；选取适应ELM分类模型需求的流特征作为输入继而拥

　　有更加精确快速的预测输出是流统计特征这一工作的意义。

　　分类实验中，流量在通信过程中展现出的网络流按照五元组进行定义:源IP、目的IP、源端口、目的端口和传输文件长度，分类算法执行步骤概括如下：

　　(1)输入训练样本,样本个数为Q，设置隐含层节点数L，选择激活函数g(x)为sigmoidal函数。

　　(2)随机生成权值w和阈值b。

　　(3)计算隐含层输出矩阵H：

　　(4)获得隐含层与输出层间的连接权值β。

　　图2基于ELM流量分类训练过程

　　流量分类过程可以概括为图2所示。先对数据集提取网络流量统计特征，如果训练集数目过大则需要进行抽样处理以减少训练时间，降低训练复杂度。

　　2数据可视化

　　绘图是数据分析工作中的最重要任务之一，是探索过程中的一部分。数据可视化旨在清楚明了地提供信息，通过图形化手段将复杂的数据模型表达出来，将数据的属性从各个维度观察和分析，直观地表示出数据，使数据中的规律可以被洞悉。数据可视化是一个新术语:它传达出的含义不仅仅是用图表的形式展示数据，更多的是数据背后的信息被揭示，图表的本身应该帮助人们看到数据结构。

　　目前，开源的编程工具例如：R语言、D3.js、Tableau和python的各种工具类库等使得数据可视化由单一的表示形式演变为数据运算与图表的融合。

　　3实验方案及结论

　　3.1实验数据及环境

　　本文采用的是CHINAVIS提供的BigBusiness公司的骨干通信链路上抓取的数据包。该数据集包含了数据链路层、网络层和应用层的相关信息，数据共有

　　2626937条，与只关注网络层活动的传统tcpflow数据不同的是此网络监控日志更加丰富全面，可以更好地、多层次多角度反应数据在网络中的流动过程。

　　在IP网络，应用层负责将需要传输的数据拆分为一个或多个数据包，应用层的数据项有：ID(记录序号)、IPSMALLTYPE(IP业务类型，主要是TCP和UDP)，FILELEN(本次网络连接传输数据的总长度)、FILEAFFIX(本次网络连接传输文件类型)和ISCRACKED(数据是否损坏)共计5个维度。网络层负责建立源地址和目的地址之间的逻辑连接，网络层的数据项有：STARTTIME(开始时间)、SRCIP(源地址)、DSTIP(目的地址)、SCRPORT(源端口)和DSTPORT(目的端口)共计5个维度。数据链路层负责为逻辑链接建立传输通道，数据链路层的数据项包括：VPL1，VPL2和ATMAAL1TYPE。VPL1和VPL2是虚拟管道的标识，ATMAAL1TYPE是这个虚拟线路中传输数据的属性。

　　由于数据集中存在有少量缺失值数据，实验首先对网络流量进行了数据清洗。数据清洗完成后对数据进行了数据集成，将多个数据源合并存放在一个一致的数据存储中。同时进行的是数据转换和规约。数据转换主要是对原始数据进行规范化处理，将数据转换成适当的形式以适应于数据挖掘和ELM算法的需要。数据规范化即归一化处理数据，不同指标往往具有不同量纲，数值之间差别可能很大，而这些会影响数据分析的结果。

　　实验中，网络流量数据的特征统计、绘图等数据分析方面的工作使用的是Python2.7.13，涉及的模块有：numpy，pandas，seaborn，matplotlib等；使用MATLABR2014b做基于ELM算法的网络流量分类工作。

　　3.2实验设计和可视化

　　根据不同的目的选择不同的特征作为分类依据，为了使实验更具有针对性，选择合适的网络流量特征是极为重要的。如表1所示，从不同角度分析数据，实验中可以统计的特征有很多，基于BigBusiness两个月的网络监控日志数据，对内部网

　　络的通信进行分析，本实验选取了以下4种网络流量特征对服务器进行筛选：

　　1.主机通信频率

　　2.主机传输文件长度

　　3.协议类型

　　4.传输文件类型

　　为了找出BigBusiness内部网络的服务器，对选取的网络流量特征使用python中pandas模块的Series和DataFrame进行切片处理，合并、统计整理好作为超限学习机算法的训练集和测试集。作为ELM算法的输入，训练集和测试集共有7个维度：标签、源IP地址主机通信频率、目的IP地址主机通信频率、主机发送数据的长度、主机接收数据的长度、协议类型代号和传输文件类型代号。

　　表1网络流量特征统计序号特征名称1主机通信频率2主机传输文件长度3端口号4包到达时间统计……

　　3.2.1基于ELM算法的分类实验

　　经过ELM网络训练、分类、测试，实验中本文在设置隐含层节点数时，以10作为起始数，共做了10次实验，输出为ELM训练的时间和分类的精度。输出结果如图3所示。

　　图3ELM分类器的输出结果图

　　由实验结果可知，超限学习机这种算法训练时间短，训练速度十分快且它的精度非常高。随着隐含层节点数的增加，训练时间会少许变长，然而并不是隐含层节点数越多时，ELM的精度越高，在针对本次实验的两种网络流量特征的分类上，当节点数为50时，精度达到最高为94.01%且由图3可知，其训练时间也是处于最低点处的。这些优势证明了ELM算法可以很好地应用于网络流量的分类。

　　3.2.2基于H-ELM算法的分类实验

　　在实验中，主要是超参数的选择，参数C是为了正则最小均方计算，参数L是隐含层节点数。对于两个参数的选择，C值的选择需要谨慎，L值应该选取得足够大。一方面，随着L值的增长，一个合适的C值使

　　测试精度曲线更加平缓。如图4所示。另一方面，不同的L值对于测试精度的影响并不大。如图5所示。

　　图4H-ELM参数的选择对测试精度的影响

　　图5隐含层节点数对测试精度的影响

　　3.2.3基于传统神经网络算法的分类实验

　　徐鹏等人[10]提出的基于支持向量机的流量分类方法中，利用非线性变换将流量分类问题转换为二次寻优问题。基于支持向量机的流量分类方法不依赖于样本空间分布，稳定性强。但是，此方法用的数据集流特征过多，流特征过多会导致计算复杂度增加，在实际应用中有过多的计算负荷。李平红等人[11]提出一种基于支持向量机的半监督网络流量分类方法，此方法引入增量式学习，使学习精度随着新样本的增加而提高；引入半监督学习[12]降低人工标记样本的错误率和成本。然而，此方法训练时间长。SVM方法在网络流量大规模样本分类实际应用上体现了其建模时间长，训练时间成本高的缺陷。

　　为了更好地与ELM分类器进行对比，本文将网络流量数据输入传统BP(Backpropagation)神经网络算法中，利用BP神经网络算法对同样的网络流量进行分类实验；在同等条件下将数据输入SVM算法中，对比实验结果如表2所示。

　　由对比实验结果可知，ELM算法在分类实验中展现了其建模时间短、训练速度快且分类精度高的优势。对于传统的机器学习算法，例如BP神经网络和SVM，虽然SVM算法的分类精度很高，但其建模和训练的时间消耗是巨大的；而对于传统的BP神经网络算法来说，它的缺点是非常明显的，实验结果显示：BP神经网络算法作为分类器的算法表现出建模时间长、训练速度慢且分类精度较低。不适用于大规模网络流量数据的分类和实际应用。

　　表2ELM算法与其他传统学习算法的对比试验结果算法建模时间分类精度BP30.07s87.14%SVM9.13s95.16%ELM0.87s94.01%3.2.4可视化分析

　　由基于ELM算法分类后的结果，实验找到了数据集中的服务器。

　　本文利用可视化来展示ELM算法分类后的主机网络流量特征:(1)从主机的度的角度来看，选取了前50个服务器的出度和入度如图6和图7所示，坐标轴横轴为度，纵轴是服务器IP地址。从图6和图7可以看出有的服务器的出入度相差不大，但有的服务器出入度相差很多。

　　图6服务器出度

　　图7服务器入度

　　(2)从主机的传输—接收流量大小的角度来看，根据样本中的167个服务器绘出线型图如图8所示，坐标轴横轴为主机序号，纵轴为传输流量大小。实线表示发出的流量，虚线表示接受的流量。由图8可以看出大部分服务器发出的流量和接收的流量大小持平，只有少数提供特定服务的主机发出的流量和接收的流量大小相差较大。

　　4结

　　语

　　图8主机传输—接收流量线型图

　　本文针对内网服务器识别分类问题提出的基于ELM的网络流量分类方法，无论是在训练时间还是分类精度方面都有良好的表现。通过对原始流量数据分析选择ElM分类模型，根据分类后的仿真结果对数据进行了可视化绘图从而进一步地了解ELM算法对网络流量数据分类的效果。最终的实验结果表明ELM算法可以取得较好的分类效果，可以满足网络流量分类识别的应用需求。H-ELM和ELM之间最主要的区别是在ELM特征分类前H—ELM用分层训练获得原始数据的多层稀疏表示，而在ELM中，原始数据是用来直接回归和分类的。总的来说H-ELM改善了学习表现。未来工作中将要注重网络流量的预测以及新样本加入训练时无需对样本重新训练的SLFNs的增量式学习算法OS-ELM解决网络流量分类问题的研究。

　　参考文献:[1]丁杰.基于n-gram多特征的流量载荷类型分类方法[J].计算机应用与软件，2017，34(2)：152-158.[2]孙靖超.一种基于机器学习的网页分类技术[J].信息网络安全，2017(9)：45-48.[3]戚铭钰，刘铭，傅彦铭.基于PCA的SVM网络入侵检测研究[J].信息网络安全，2015(2)：15-18.[4]王涛，余顺争.基于机器学习的网络流量分类研究进展[J].小型微型计算机系统，2012，33(5)：1034-1040.[5]刘琼，刘珍，黄敏.基于机器学习的IP流量分类研究[J].计算机科学，2010,37(12)：35-40.[6]李晓明.基于机器学习的网络流量分类算法分析研究[J].中国传媒大学学报(自然科学版)，2017，24(2)：9-14.[7]林平，余循宜，刘芳，等.基于流统计特性的网络流量分类算法[J].北京邮电大学学报，2008，31(2)：15-19.[8]HUANGG，BCHENL,SIEWCK.Universalapproximationusingincrementalconstructivefeedforwardnetworkswithrandomhiddennodes[J].IEEETransNeuralNetworks,2006，17(4)：879-892.[9]HUANGG，BZHOUH.DINGX.Extremelearningmachineforregressionandmulticlassclassification[J].IEEETransSystemsManCybernetics-PartB:Cybernetics,2012，42(2)：513-529.[10]徐鹏，刘琼，林森.基于支持向量机Internet流量分类研究[J].计算机研究与发展，2009,46(3):407-414．

　　[11]李平红，王勇，陶晓玲.支持向量机的半监督网络流量分类方法[J].计算机应用，2013，33(6)：1515-1518.[12]周文刚，陈雷霆，LubomirBic，等.基于半监督的网络流量分类识别算法[J].

　　电子测量与仪器学报，2014，28(4)：381-386.

篇三：容器网络流量研究教授

　　IT技术进阶：Docker容器的四种网络模式

　　docker容器技术可谓是炽手可热，docker不仅仅改变了传统软件服务的交付流程，更是为云计算和微服务大规模集群管理部署，提供了强有力的技术支撑。当今各大公司企业也是把容器化技术作为不可或缺的技术战略。

　　Docker是一个开源的应用容器引擎，基于

　　Go语言

　　并遵从Apache2.0协议开源。

　　Docker可以让开发者打包他们的应用以及依赖包到一个轻量级、可移植的容器中，然后发布到任何流行的

　　Linux机器上，也可以实现虚拟化。容器是完全使用沙箱机制，相互之间不会有任何接口（类似

　　iPhone的

　　app），更重要的是容器性能开销极低。

　　Docker容器是一个开源的应用容器引擎，让开发者可以以统一的方式打包他们的应用以及依赖包到一个可移植的容器中，然后发布到任何安装Docker引擎的服务器上，也可以实现虚拟化。

　　随着云计算的飞速发展以及企业需求的多样化，Docker容器技术成为云计算人才必备的技能之一。很多人想要快速掌握Docker容器技术，接下来就给大家讲解Docker容器的四种网络模式。

　　1、closedcontainer封闭式网络模式

　　没有网络协议栈的通信。

　　使用none模式，Docker容器拥有自己的workNamespace，但是，并不为Docker容器进行任何网络配置。也就是说，这个Docker容器没有网卡、IP、路由等信息，只有lo网络接口。需要我们自己

　　为Docker容器添加网卡、配置IP等。

　　2、bridgedcontainer桥接式网络模式

　　各个容器之间网络协议栈单独分离。

　　当Docker启动时，会自动在主机上创建一个docker0虚拟网桥，实际上是Linux的一个bridge，可以理解为一个软件交换机，它会在挂载到它的网口之间进行转发。同时，Docker随机分配一个本地未占用的私有网段（在

　　RFC1918中定义）中的一个地址给docker0接口。

　　当创建一个Docker容器的时候，同时会创建了一对vethpair接口。这对接口一端在容器内，即eth0；另一端在本地并被挂载到docker0网桥，名称以veth开头。通过这种方式，主机可以跟容器通信，容器之间也可以相互通信。Docker就创建了在主机和所有容器之间一个虚拟共享网络。

　　3、joinedcontainer联合挂载式网络模式

　　容器之间可以共享网络协议栈，即可以通过套接字来进行通信。

　　这个模式指定新创建的容器和已经存在的一个容器共享一个workNamespace，而不是和宿主机共享。新创建的容器不会创建自己的网卡，配置自己的IP，而是和一个指定的容器共享

　　IP、端口范围等。同样，两个容器除了网络方面，其他的如文件系统、进程列表等还是隔离的。两个容器的进程可以通过lo网卡设备通信。

　　4、opentainercontainer开放式网络模式

　　与主机共享网络协议栈。

　　Host模式使用是在容器启动时候指明--workhost，此时容器共享宿主机的workNamespace，容器内启动的端口直接是宿主机的端口，容器不会创建网卡和IP，直接使用宿主机的网卡和IP，但是容器内的其他资源是隔离的，如文件系统、用户和用户组。直接使用宿主机网络。同样启动一个nginx，此时共享主机网络，根据情况来使用，这样子也不用做端口转发，网络传输效率会比较高。

篇四：容器网络流量研究教授

　　容器云平台网络架构设计及优化

　　目录

　　1.

　　容器平台网络模型....................................................................................................................................................................................1

　　1.1

　　容器网络概述..............................................................................................................................................................................1

　　1.2

　　容器网络分类介绍......................................................................................................................................................................2

　　1.2.1

　　协议栈......................................................................................................................................................................2

　　1.2.2

　　穿越方式..................................................................................................................................................................2

　　1.2.3

　　隔离方法..................................................................................................................................................................3

　　1.3总结.............................................................................................................................................................................................4

　　2.

　　基于Docker网络基础和实现原理........................................................................................................................................................4

　　3.

　　Kubernetes网络场景分析....................................................................................................................................................................6

　　3.1

　　容器到容器的通信......................................................................................................................................................................6

　　3.2

　　Pod之间的通信.........................................................................................................................................................................7

　　3.3

　　Pod到Service之间的通信....................................................................................................................................................9

　　3.4

　　外部到内部的访问....................................................................................................................................................................11

　　3.5总结...........................................................................................................................................................................................12

　　4.

　　Kubernetes网络组件介绍.................................................................................................................................................................13

　　4.1

　　Kubernetes网络框架CNI.......................................................................................................................................................13

　　4.2

　　CNI支持的开源组件................................................................................................................................................................13

　　4.2.1

　　Flannel.....................................................................................................................................................................................134.2.2OVS......................................................................................................................................................................15

　　4.2.3

　　Calico....................................................................................................................................................................15

　　4.2.4

　　Contiv...................................................................................................................................................................17

　　4.3

　　总结对比..................................................................................................................................................................................17

　　容器平台的网络架构实践.......................................................................................................................................................................18

　　5.1

　　某金融企业使用OpenShift（基于Kubernetes的商业版本）实现其业务上云

　　.................................................................18

　　5.1.1

　　整体网络架构图.....................................................................................................................................................19

　　5.1.2

　　传统应用访问策略................................................................................................................................................195.1.3

　　数据库访问方案及防火墙策略..............................................................................................................................205.2

　　某金融企业两第三中心容器云网络架构.................................................................................................................................21

　　优化实践........................................................................................................................................................................................22

　　Ⅱ

　　1.1

　　容器网络概述

　　1容器平台网络模型

　　与传统的虚拟化相比，容器其生命周期更短、数量密度更高、集群变更速度更快。基于这些特性，容器平台网络就必须对集群节点之间的高速通信进行充分的考量。除此之外，在企业级的容器云平台上，承载众多租户的计算负载之间资源的安全隔离，也必须要考虑到的因素。

　　显而易见，传统的物理网络架构无法满足容器平台高灵活性的需求，容器平台网络构建必须要有一种崭新的设计架构来满足，这便推动了容器平台网络设计的发展。

　　容器网络发展到目前，已经形成了Docker主导的CNM模型和Google、CoreOS、Kubernetes主导的CNI模型两种模型共存的情况。CNM和CNI并不是网络实现，他们是网络规范和网络体系。从研发的角度来

　　看就是一些接口，主要是和网络管理相关的问题。容器平台的网络方案，通常可以从协议栈、穿越方式、隔离方法三个维度去设计方案：

　　图1网络架构示意图

　　协议栈：

　　◎二层（桥接、ARP+MAC）

　　◎三层（路由转发）

　　◎二层+三层（节点内部二层转发、跨节点三层转发）

　　穿越方式：

　　◎Overlay（隧道穿越底层基础设施）

　　◎Underlay（直接穿越底层基础设施）

　　隔离方法：

　　◎VLAN

　　◎VXLAN

　　1.2

　　容器网络分类介绍

　　1.2.1

　　协议栈

　　二层解决方案，常见于传统机房或者虚拟化场景中，针对ARP和MAC（桥接模式）学习，广播风暴是这个方案最核心要解决的问题。众所周知，二层广播，对整个集群中节点的数量也会有严格的限制。三层解决方案一般是基于BGP协议实现路由转发，通过自主学习完善整个数据中心的路由状态。这个方案的优势是IP穿透性，可以实现IP网络透传。因为基于IP，所以其优势在于规模性，具有非常优秀的扩展性。但在实际使用过程中，受限于各个企业自身网络安全的考量，例如生产网和开发测试网隔离，或者网络本身不支持BGP，那么这个方案就受限了。二层+三层的方案，集成了前面两种方案的优势（既解决了二层规模性扩展的问题，又解决三层网络隔离受限的问题），正成为容器云网络场景下首选的协议栈层级的解决方案。

　　1.2.2

　　穿越方式Underlay网络

　　提到Underlay网络，就必须从以太网说起，以太网从最开始设计出来就是一个分布式网络，没有中心的控制节点，网路中的各个设备之间通过协议传递的方式学习网络的可达信息，由每台设备自己决定要如何转发，这直接导致了没有整体观念，不能从整个网络的角度对流量进行调控。由于要完成所有网络设备之间的互通，就必须使用通用的语言，这就是网络协议，RFC就是网络协议的法律，相当于国际法，各个设备供应商遵从国际法行事，就基本保证了整个网络世界的正常运行。Underlay就是当前数据中心网路基础转发

　　架构的网络，只要数据中心网络上任意两点路由可达即可，指的是物理基础层。我们可以通过物理网络设备本身的技术改良、扩大设备数量、带宽规模等完善Underlay网络，其包含了一切现有的传统网络技术。

　　Overlay网络

　　Overlay技术可以分为网络Overlay，主机Overlay和混合式Overlay三大类。网络Overlay是指通过控制协议

　　对边缘的网络设备进行网络构建和扩展，也就是本文所讲的Overlay网络技术。Overlay网络技术多种多样，一般采用TRILL、VXLAN、GRE、NVGRE等隧道技术。TRILL（TransparentInterconnectionofLots

　　ofLinks）

　　技术是电信设备厂商主推的新型环网技术；NVGRE（NetworkVirtualizationusingGenericRoutingEncapsu-lation）STT（StatelessTransportTunnelingProtocol）是IT厂商主推的Overlay技术；以及大家非常熟悉的

　　VXLAN（Virtual

　　Extensible

　　LAN）等基于隧道的封装技术。由于这些也都是新增的协议，均需要升级现有网络设备才能支持。Overlay网络中应用部署的位置将不受限制，网络设备可即插即用、自动配置下发，自

　　动运行，Overlay网络业务变化，基础网络不感知，并对传统网络改造极少，最为重要的是虚拟机和物理服

　　务器都可以接入Overlay网络中。

　　1.2.3

　　根据基础设施划分

　　VLAN(VirtualLocalAreaNetwork)意为虚拟局域网，是在交换机实现过程中涉及到的概念，由802.1Q标准所定义。由于交换机是工作在链路层的网络设备，连接在同一台交换机的终端处于同一个三层网中，同时也处于同一个广播域。当交换机接入较多的终端时，任意一台终端发送广播报文时（例如：ARP请求），报文都会传遍整个网络。对于规模较大的组网场景，广播报文的泛滥对于网络通信将会造成较大的影响。VLAN技术为这一问题提供了解决方案，VLAN将同一网络划分为多个逻辑上的虚拟子网，并规定当收到广播报文时，仅仅在其所在VLAN中进行广播从而防止广播报文泛滥。VLAN技术在链路层的层次中实现了广播域的隔离。

　　随着大数据、云计算技术的兴起以及虚拟化技术的普及，VLAN技术的弊端逐渐显现出来，具体表现为

　　如下3个方面：

　　(1)

　　虚拟化技术的发展促使大数据、云计算技术公司采用单个物理设备虚拟多台虚拟机的方式来进行组网，随着应用模块的增加，对于支持VLAN数目的要求也在提升，802.1Q标准中的最多支持4094个VLAN的能力已经无法满足当下需求。

　　(2)

　　公有云提供商的业务要求将实体网络租借给多个不同的用户，这些用户对于网络的要求有所不同，而不同用户租借的网络有很大的可能会出现IP地址、MAC地址的重叠，传统的VLAN仅仅解决了同一链路层网络广播域隔离的问题，而并没有涉及到网络地址重叠的问题，因此需要一种新的技术来保证在多个租户网络中存在地址重叠的情况下依旧能有效通信的技术。

　　(3)

　　虚拟化技术的出现增加了交换机的负担，对于大型的数据中心而言，单台交换机必须支持数十台以上主机的通信连接才足以满足应用需求，而虚拟化技术使得单台主机可以虚拟化出多台虚拟机同时运行，而每台虚拟机都会有其唯一的MAC地址。这样，为了保证集群中所有虚机可以正常通信，交换机必须保存每台虚机的MAC地址，这样就导致了交换机中的MAC表异常庞大，从而影响交换机的转发性能。

　　基于以上需求，VXLAN技术被提出。

　　VXLAN技术是网络Overlay技术的一种实现，对于Overlay技术，笔者的理解是：在基于物理网络拓扑的

　　基础上通过一定的技术来构建虚拟的、不同于物理网络拓扑的逻辑网络，而物理网络的拓扑结构对于Over-

　　lay终端而言是透明的，终端不会感知到物理网络的存在，而仅仅能感知到逻辑网络结构。对于终端的视角，网络的情况和直接通过物理设备实现逻辑拓扑的效果是相同的。VXLAN技术可以基于三层网络结构来构建二层虚拟网络，通过VLAN技术可以将处于不同网段网络设备整合在同一个逻辑链路层网络中，对于终端用户而言，这些网络设备似乎“真实地”部署在了同一个链路层网络中。

　　相比VLAN技术，VXLAN技术具有以下的优势：

　　(1)

　　24位长度的VNI字段值可以支持更多数量的虚拟网络，解决了VLAN数目上限为4094的局限性的问题。

　　(2)

　　VXLAN技术通过隧道技术在物理的三层网络中虚拟二层网络，处于VXLAN网络的终端无法察觉到VXLAN的通信过程，这样也就使得逻辑网络拓扑和物理网络拓扑实现了一定程度的解耦，网络拓扑的配置对于物理设备的配置的依赖程度有所降低，配置更灵活更方便。

　　(3)

　　VLAN技术仅仅解决了二层网络广播域分割的问题，而VXLAN技术还具有多租户支持的特性，通过VXLAN分割，各个租户可以独立组网、通信，地址分配方面和多个租户之间地址冲突的问题也得到了解决。

　　1.3

　　总结

　　通过本章的学习，可以初步了解容器网络相关的基础概念，主要涉及到了容器网络的协议栈、穿越方式以及隔离方式。针对协议栈，到底是采用二层互通，还是采用三层互通，还是结合两种方式的优点整合一个综合的方式取决于业务场景；针对穿越方式，是采用传统的Underlay网络，还是基于SDN的Overlay网络，和客户现场情况，以及硬件设备支持的情况都有比较大的关联；同样，隔离方式采用VLAN还是VXLAN，也和场景强相关。由此可见，容器云网络的设计，需要因地制宜，因材施教，从客户需求以及现场情况发出，才能制定出一个完善的解决方案。

　　2基于Docker网络基础和实现原理

　　Docker网络方案基于OpenStack平台网络解决方案，在不断的摸索中，形成了自己的一套网络模型。Docker网络在整个Docker技术栈中的位置如图：

　　图2Docker生态技术栈

　　在容器网络项目探索中，随着容器的发展，容器网络的发展也出现了分歧。主要分为两派，一个是Docker原生的CNM（ContainerNetworkModel），另一个是兼容性更好的CNI（ContainerNetworkInter-face）。CNI就是后来为Kubernetes等容器平台广泛推崇使用的接口技术，后面的章节会详细讲述。这里，我们简要介绍CNM。

　　原先Docker的网络相关的代码是直接在Docker中的，网络功能也比较简单，对网络的诟病也是比较多。随着Docker越来越向平台化发展，将功能组件逐渐从Docker中解耦，Docker从1.7把网络相关的代码从Docker的代码中剥离出来新建了一个Libnetwork项目，引入了CNM的网络模型。

　　图3CNM（ContainerNetworkModel）

　　CNM模型下的Docker网络模型如上所示。它由Sandbox,Endpoint,Network三种组件组成。注意，该模型只是规定了三种组件各自的作用，他们都有各自的具体实现方式。Sandbox:Sandbox包含了一个

　　Con-tainer的网络相关的配置，如网卡Interface，路由表等。Sandbox在Linux上的典型实现是

　　Networknamespace。在Linux系统上的Docker环境中，Container，Networknamespace，Sandbox这三者是绑定在一起的。一个Sandbox可以包含多个Endpoint，这些Endpoint可以来自多个

　　Network。

　　Endpoint:Sandbox加入

　　Network的方式是通过

　　Endpoint完成的。Endpoint的典型实现方式是

　　Vethpair，每个

　　Endpoint都是由某个

　　Network创建。创建后，它就归属于该Network。同时，Endpoint还可以加入一个Sandbox。加入后，相当于该Sandbox也加入了此Network。

　　Network:Network的一种典型实现是Linuxbridge。一个Network可以创建多个Endpoint。将这些Endpoint加入到Sandbox，即实现了多个Sandbox的互通。

　　总结起来：如果要想两个Container之间可以直接通信，那么最简单的办法就是由一个Network创建两个Endpoint，分别加入这两个Container对应的Sandbox。

　　注意:不同Network之间默认的隔离性是docker通过设置Iptables完成的，通过改变Iptables的设置，可以使得两个Network互通。

　　标准的

　　Docker网络支持以下

　　4类网络模式：

　　host模式：使用--net=host指定

　　container模式：使用--net=container:Name_or_ID指定none模式：使用--net=none指定

　　bridge模式：使用--net=bridge指定，设为默认值

　　桥接模式是最常见的Docker容器网络类型。在桥接模式下，Docker会为每个容器分配IP地址及创建虚拟以太网网卡对（Veth）。所有的容器都被连接到Docker在主机绑定的桥接设备上。被连接到同一个桥接设备的所有容器，都可以实现互联互通。如果容器要对外界提供服务，则用户需要将容器内的服务端口与宿主机的某一段口绑定。这样所有访问苏主机目标端口的请求都将通过Docker代理转发到容器的服务端，最终到达应用。

　　除了桥接模式，Docker也支持主机（host）模式，让容器直接使用宿主机的网络设备。宿主机模式使得容器占用宿主机的端口资源，而且要求容器具有更高的权限，因此只有特殊需求的容器，才会使用这种模式，如OpenShift集群中的Router组件。Router主机需要监听计算节点上的端口，以接受外部的请求，因此Router组件的Pod的容器网络为主机模式。

　　本章节主要介绍了Docker网络的情况，从Docker整个生态栈入手，分析了基于单机和集群两种不同场景的Docker网络，着重分析了在单机模式下Docker网络的情况（host/bridge/none/container）。

　　Kubernetes网络场景分析

　　在实际的业务场景中，业务组件之间的关系十分复杂，特别是微服务概念的提出，应用部署的粒度更加细小和灵活。为了支持业务应用组件的通信联系，Kubernetes网络的设计主要致力于解决以下场景：

　　（1）紧密耦合的容器到容器之间的直接通信；

　　（2）抽象的Pod到Pod之间的通信；

　　（3）Pod到Service之间的通信；

　　（4）集群外部与内部组件之间的通信；

　　3.1

　　容器到容器的通信

　　在同一个Pod内的容器（Pod内的容器是不会跨宿主机的）共享同一个网络命名空间，共享同一个Linux协议栈。所以对于网络的各类操作，就和它们在同一台机器上一样，它们甚至可以用localhost地址访问彼此的端口。这么做的结果是简单、安全和高效，也能减少将已经存在的程序从物理机或者虚拟机移植到容器

　　的难度。

　　如图4中的阴影部分就是Node上运行着的一个Pod实例。容器1和容器2共享了一个网络的命名空间，共享一个命名空间的结果就是它们好像在一台机器上运行似的，它们打开的端口不会有冲突，可以直接用Linux的本地IPC进行通信。它们之间互相访问只需要使用localhost就可以。

　　图4容器到容器间通信

　　3.2

　　Pod之间的通信

　　每一个Pod都有一个真实的全局IP地址，同一个Node内的不同Pod之间可以直接采用对房Pod的IP地址通信，而不需要使用其他发现机制，例如DNS、Consul或者etcd。Pod既有可能在同一个Node上运行，也有可能在不用的Node上运行，所以通信也分为两类：同一个Node内的Pod之间的通信和不同Node上的Pod之间的通信。

　　1）同一个Node内的Pod之间的通信

　　如图，可以看出，Pod1和Pod2都是通过Veth连接在同一个Docker0网桥上的，它们的IP地址IP1、IP2都是从Docker0的网段上自动获取的，它们和网桥本身的IP3是同一个网段的。另外，在Pod1、Pod2的Linux协议栈上，默认路由都是Docker0的地址，也就是说所有非本地的网络数据，都会被默认发送到Docker0网桥上，由Docker0网桥直接中转，它们之间是可以直接通信的。

　　图5同一个Node内的Pod关系

　　2）不同Node上的Pod之间的通信

　　Pod的地址是与Docker0在同一个网段内的，我们知道Docker0网段与宿主机网卡是两个完全不同的IP网段，并且不同Node之间的通信只能通过宿主机的物理网卡进行，因此要想实现位于不同Node上的Pod容器之间的通信，就必须想办法通过主机的这个IP地址来进行寻址和通信。另外一方面，这些动态分配且藏在Docker0之后的所谓“私有”IP地址也是可以找到的。Kubernetes会记录所有正在运行Pod的IP分配信息，并

　　将这些信息保存在etcd中（作为Service的Endpoint）。这些私有IP信息对于Pod到Pod的通信也是十分重要的，因为我们的网络模型要求Pod到Pod使用私有IP进行通信。之前提到，Kubernetes的网络对Pod的地址是平面的和直达的，所以这些Pod的IP规划也很重要，不能有冲突。

　　综上所述，想要支持不同Node上的Pod之间的通信，就要达到两个条件：

　　（1）在整个Kubernetes集群中对Pod分配进行规划，不能有冲突；

　　（2）找到一种办法，将Pod的IP和所在Node的IP关联起来，通过这个关联让Pod可以互相访问。

　　根据条件1的要求，我们需要在部署Kubernetes的时候，对Docker0的IP地址进行规划，保证每一个

　　Node上的Docker0地址没有冲突。我们可以在规划后手工分配到每个Node上，或者做一个分配规则，由安

　　装的程序自己去分配占用。例如Kubernetes的网络增强开源软件Flannel就能够管理资源池的分配。

　　根据条件2的要求，Pod中的数据在发出时，需要有一个机制能够知道对方Pod的IP地址挂在哪个具体的Node上。也就是说要先找到Node对应宿主机的IP地址，将数据发送到这个宿主机的网卡上，然后在宿主

　　机上将相应的数据转到具体的Docker0上。一旦数据到达宿主机Node，则哪个Node内部的Docker0便知道如何将数据发送到Pod。

　　具体情况，如下图所示。

　　图6跨Node的Pod通信

　　在图6中，IP1对应的是Pod1，IP2对应的是Pod2。Pod1在访问Pod2时，首先要将数据从源Node的

　　eth0发送出去，找到并到达Node2的eth0。也就是说先要从IP3到IP4，之后才是IP4到IP2的送达。

　　3.3

　　Pod到Service之间的通信

　　为了支持集群的水平扩展、高可用，Kubernetes抽象出Service的概念。Service是对一组Pod的抽象，它会根据访问策略（LB）来访问这组Pod。

　　Kubernetes在创建服务时会为服务分配一个虚拟的IP地址，客户端通过访问这个虚拟的IP地址来访问服务，而服务则负责将请求转发到后端的Pod上。这个类似于反向代理，但是，和普通的反向代理有一些不同

　　：首先它的IP地址是虚拟的，想从外面访问需要一些技巧；其次是它的部署和启停是Kubernetes统一自动管理的。

　　Service在很多情况下只是一个概念，而真正将Service的作用落实的是背后的kube-proxy服务进程。在Kubernetes集群的每个Node上都会运行一个kube-proxy服务进程，这个进程可以看作Service的透明代理兼负载均衡器，其核心功能是将到某个Service的访问请求转发到后端的多个Pod实例上。对每一个TCP类型的KubernetesService，kube-proxy都会在本地Node上建立一个SocketServer来负责接收请求，然后均匀发送到后端某个Pod的端口上，这个过程默认采用RoundRobin负载均衡算法。Kube-proxy和后端Pod的通信方式与标准的Pod到Pod的通信方式完全相同。另外，Kubernetes也提供通过修改Service的service.spec.-sessionA?nity参数的值来实现会话保持特性的定向转发，如果设置的值为“ClientIP”，则将来自同一个ClientIP的请求都转发到同一个后端Pod上。此外，Service的ClusterIP与NodePort等概念是kube-proxy通过Iptables和NAT转换实现的，kube-proxy在运行过程中动态创建与Service相关的Iptables规则，这些规则实

　　现了ClusterIP及NodePort的请求流量重定向到kube-proxy进程上对应服务的代理端口的功能。由于Iptables机制针对的是本地的kube-proxy端口，所以如果Pod需要访问Service，则它所在的那个Node上必须运行kube-proxy，并且在每个Kubernetes的Node上都会运行kube-proxy组件。在Kubernetes集群内部，对ServiceClusterIP和Port的访问可以在任意Node上进行，这个因为每个Node上的kube-proxy针对该Service都设置了相同的转发规则。

　　综上所述，由于kube-proxy的作用，在Service的调用过程中客户端无需关心后端有几个Pod，中间过程的通信、负载均衡及故障恢复都是透明的，如下图所示。

　　图7Service的负载均衡转发

　　访问Service的请求，不论是用ClusterIP+TargetPort的方式，还是用节点机IP+NodePort的方式，都会被节点机的Iptables规则重定向到kube-proxy监听Service服务代理端口。Kube-proxy接收到Service的访问请求后，会如何选择后端Pod？

　　首先，目前kube-proxy的负载均衡只支持RoundRobin算法。该算法按照成员列表逐个选取成员，如果一轮循环完，便从头开始下一轮，如此循环往复。Kube-proxy的负载均衡器在RoundRobin算法的基础上还支持Session保持。如果Service在定义中指定了Session保持，则kube-proxy接收请求时会从本地内存中

　　查找是否存在来自该请求IP的a?nityState对象，如果存在该对象，且Session没有超时，则kube-proxy将请求转向该a?nityState所指向的后端Pod。如果本地存在没有来自该请求IP的a?nityState对象，记录请求的

　　IP和指向的Endpoint。后面的请求就会粘连到这个创建好的a?nityState对象上，这就实现了客户端IP会话

　　保持的功能。

　　接下来我们深入分析kube-proxy的实现细节。kube-proxy进程为每个Service都建立了一个“服务代理对象”，服务代理对象是kube-proxy程序内部的一种数据结构，它包括一个用于监听此服务请求的Socket-Server，SocketServer的端口是随机选择的一个本地空闲端口。此外，kube-proxy内部也建立了一个“负载均衡器组件”，用来实现SocketServer上收到的连接到后端多个Pod连接之间的负载均衡和会话保持能力。

　　kube-proxy通过查询和监听APIServer中Service与Endpoint的变化来实现其主要功能，包括为新创建的Service打开一个本地代理对象（代理对象是kube-proxy程序内部的一种数据结构，一个Service端口是一个代理对象，包括一个用于监听的服务请求的SocketServer），接收请求，针对发生变化的Service列表，kube-proxy会逐个处理。下面是具体的处理流程：

　　（1）如果该Service没有设置集群IP（ClusterIP），则不做任何处理，否则，获取该Service的所有端口定义列表（spec.ports域）

　　（2）逐个读取服务端口定义列表中的端口信息，根据端口名称、Service名称和Namespace判断本地是否已经存在对应的服务代理对象，如果不存在就新建，如果存在且Service端口被修改过，则先删除Iptables中和该Service相关的的规则，关闭服务代理对象，然后走新建流程，即为该Service端口分配服务代理对象并为该Service创建相关的Iptables规则。

　　（3）更新负载均衡器组件中对应Service的转发地址表，对于新建的Service，确定转发时的会话保持策略。

　　（4）对于已经删除的Service则进行清理。

　　11

　　图8Kube-proxy与APIServer的交互过程

　　3.4

　　外部到内部的访问

　　Pod作为基本的资源对象，除了会被集群内部的Pod访问，也会被外部使用。服务是对一组功能相同Pod的抽象，以它为单位对外提供服务是最合适的粒度。

　　由于Service对象在ClusterIPRange池中分配到的IP只能在内部访问，所以其他Pod都可以无障碍地访问到它。但如果这个Service作为前端服务，准备为集群外的客户端提供服务，就需要外部能够看到它。Kubernetes支持两种对外服务的Service的Type定义：NodePort和LoadBalancer。

　　（1）NodePort

　　在定义Service时指定spec.type=NodePort，并指定spec.ports.nodePort的值，系统就会在Kubernetes集群中的每个Node上打开一个主机上的真实端口号。这样，能够访问Node的客户端就能通过这个端口号访

　　问到内部的Service了。

　　（2）LoadBalancer

　　如果云服务商支持外接负载均衡器，则可以通过spec.type=LoadBalancer定义Service，同时需要指定负载均衡器的IP地址。使用这种类型需要指定Service的NodePort和ClusterIP。

　　对于这个Service的访问请求将会通过LoadBalancer转发到后端Pod上去，负载分发的实现方式依赖于云服务商提供的LoadBalancer的实现机制。

　　（3）外部访问内部Service原理

　　12

　　我们从集群外部访问集群内部，最终都是落在具体的Pod上。通过NodePort的方式就是将kube-proxy开放出去，利用Iptables为服务的NodePort设置规则，将对Service的访问转到kube-proxy上，这样

　　kube-proxy就可以使用和内部Pod访问服务一样的方式来访问后端的一组Pod了。这种模式就是利用

　　kube-proxy作为负载均衡器，处理外部到服务进一步到Pod的访问。而更常用的是外部均衡器模式。通常的实现是使用一个外部的负载均衡器，这些均衡器面向集群内的所有节点。当网络流量发送到LoadBalancer地址时，它会识别出这是某个服务的一部分，然后路由到合适的后端Pod。

　　所以从外面访问内部的Pod资源，就有了很多种不同的组合。

　　◎

　　外面没有负载均衡器，直接访问内部的Pod

　　◎

　　外面没有负载均衡器，直接通过访问内部的负载均衡器来访问Pod

　　◎

　　外面有负载均衡器，通过外部负载均衡器直接访问内部的Pod

　　◎

　　外面有负载均衡器，通过访问内部的负载均衡器来访问内部的Pod

　　第一种情况的场景十分少见，只是在特殊的时候才需要。我们在实际的生产项目中需要逐一访问启动的Pod，给它们发送一个刷新指令。只有这种情况下才使用这种方式。这需要开发额外的程序，读取Service下的Endpoint列表，逐一和这些Pod进行通信。通常要避免这种通信方式，例如可以采取每个Pod从集中的数据源拉命令的方式，而不是采取推命令给它的方式来避免。因为具体到每个Pod的启停本来就是动态的，如果依赖了具体的Pod们就相当于绕开了Kubernetes的Service机制，虽然能够实现，但是不理想。

　　第二种情况就是NodePort的方式，外部的应用直接访问Service的NodePort，并通过Kube-proxy这个负载均衡器访问内部的Pod。

　　第三种情况是LoadBalancer模式，因为外部的LoadBalancer是具备Kubernetes知识的负载均衡器，它会去监听Service的创建，从而知晓后端的Pod启停变化，所以它有能力和后端的Pod进行通信。但是这里有个问题需要注意，那就是这个负载均衡器需要有办法直接和Pod进行通信。也就是说要求这个外部的负载均衡器使用和Pod到Pod一样的通信机制。

　　第四种情况也很少使用，因为需要经历两级的负载均衡设备，而且网络的调用被两次随机负载均衡后，更难跟踪了。在实际生产环境中出了问题排错时，很难跟踪网络数据的流动过程。

　　（4）外部硬件负载均衡器模式

　　在很多实际的生产环境中，由于是在私有云环境中部署Kubernetes集群，所以传统的负载均衡器都对Service无感知。实际上我们只需要解决两个问题，就可以将它变成Service可感知的负载均衡器，这也是实际系统中理想的外部访问Kubernetes集群内部的模式。

　　◎

　　通过写一个程序来监听Service的变化，将变化按照负载均衡器的通信接口，作为规则写入负载均衡

　　器。

　　13

　　◎

　　给负载均衡器提供直接访问Pod的通信手段。如下图，说明了这个过程。

　　图9自定义外部负载均衡器访问Service

　　这里提供了一个ServiceAgent来实现Service变化的感知。该Agent能够直接从etcd中或者通过接口调用APIServer来监控Service及Endpoint的变化，并将变化写入外部的硬件负载均衡器中。

　　同时，每台Node上都运行着有路由发现协议的软件，该软件负责将这个Node上所有的地址通过路由发

　　现协议组播给网络内的其他主机，当然也包含硬件负载均衡器。这样硬件负载均衡器就能知道每个Pod实例的IP地址是在哪台Node上了。通过上述两个步骤，就建立起一个基于硬件的外部可感知Service的负载均衡器。

　　具体的案例，可以参见第五章的实践部分。

　　3.5

　　总结

　　本章重点介绍了Kubernetes网络的各种场景，包括容器之间、Pod之间、Pod到Service、外部到内部的这4种场景下，不同的通信模式。在设计Kubernetes容器平台的时候，建议按照这些通信模式，根据具体的场景，逐一比对选择合适的解决方案。其中，需要注意的是外部到内部的访问，既可以通过NodePort，也可以通过LoadBalancer的方式亦或是Ingress模式，需要按照具体的场景来分析。

　　NodePort服务是暴露服务的最原始方式，会在所有节点上打开特定的端口，并且发送到此端口的任何流量都将转发到该服务。这种方法有很多缺点：每个端口只能有一个服务；默认只能使用端口30000～

　　32767；如果节点IP地址发生更改，则会带来问题。由于这些原因，不建议在生产中使用这种方法。如果服务可用性不是特别关注，或者特别关注成本，则这个方案比较合适。

　　LoadBalancer是服务暴露的标准方式，将会启动一个网络负载均衡器，提供一个将所有流量转发到服

　　14

　　务的IP地址。如果直接暴露一个服务，这是默认的方法。指定的端口上所有的流量将被转发到该服务，没有过滤、路由等。这就意味着可以发送几乎任何类型流量，如HTTP、TCP、UDP、Websocket、gRPC或其

　　他。这个方式最大的缺点是，使用LoadBalancer公开的每项服务都将获得自己的IP地址，并且必须为每个

　　服务使用一个LoadBalancer，这将会付出比较大的代价。

　　Ingress实际上不是一种服务。相反，它位于多个服务之前，充当集群中的“智能路由器”或入口点。默认的Ingress控制器将会启动一个HTTP（s）负载均衡器。这将可以执行基于路径和基于子域名的路由到后端服务。Ingress可能是暴露服务最强大的方式了，但也可能是最复杂的。如果希望在相同的IP地址下暴露多个服务，并且这些服务都使用相同的L7协议，则Ingress是最有用的。

　　Kubernetes网络组件介绍

　　4.1

　　Kubernetes网络框架CNI

　　基于Docker的Kubernetes平台为什么没有选择CNM作为其网络设计框架，毕竟大部分容器平台肯定会支持Docker的网络组件，为什么不使用相同的组件呢？这就要从Kubernetes平台设计初衷说起，Kuberne-tes是一个支持多容器的运行环境，而Docker只是其中一个容器而已。Docker网络驱动设计中，做了很多和Kubernetes不兼容的假设。

　　例如，Docker中有“本地”驱动和“全局”驱动概念，“本地”驱动实现单机版，无法实现跨节点协作，“全

　　局”驱动libkv可实现跨节点协作。但是，libkv接口太过于底层，而且架构模式也是Docker内部的量身定制版本，对于Kubernetes的应用会带来性能、可扩展性和安全性方面的问题。

　　CNI（ContainerNetworkingInterface）提供了一种Linux的应用容器的插件化网络解决方案。最初是由rktNetworkingProposal发展而来。也就是说，CNI本身并不是完全针对Docker的容器，而是提供一种普适的容器网络解决方案。模型涉及两个概念：

　　容器：拥有独立Linux网络命名空间的独立单元。比如rkt/docker创建出来的容器。

　　网络（Networking）：网络指代了可以相互联系的一组实体。这些实体拥有各自独立唯一的IP。这些实体可以是容器，是物理机，或者是其他网络设备（比如路由器）等。

　　CNI的接口设计非常简洁，不需要守护进程，只有两个接口ADD/DELETE，通过一个简单的shell脚本就可以完成。相对于CNM的复杂设计，CNI更加适合快速开发和迭代。

　　4.2

　　CNI支持的开源组件

　　4.2.1

　　Flannel

　　15

　　Flannel之所以可以搭建Kubernetes依赖的底层网络，是因为它可以实现以下两点：

　　它给每个node上的docker容器分配相互不想冲突的IP地址；

　　它能给这些IP地址之间建立一个覆盖网络，同过覆盖网络，将数据包原封不动的传递到目标容器内。

　　Flannel是CoreOS团队针对Kubernetes设计的一个网络规划服务，简单来说，它的功能是让集群中的不同节点主机创建的Docker容器都具有全集群唯一的虚拟IP地址。

　　在默认的Docker配置中，每个节点上的Docker服务会分别负责所在节点容器的IP分配。

　　这样导致的一个问题是，不同节点上容器可能获得相同的内外IP地址。并使这些容器之间能够之间通过IP地址相互找到，也就是相互ping通。

　　Flannel的设计目的就是为集群中的所有节点重新规划IP地址的使用规则，从而使得不同节点上的容器能够获得“同属一个内网”且”不重复的”IP地址，并让属于不同节点上的容器能够直接通过内网IP通信。

　　Flannel实质上是一种“覆盖网络(OverlayNetwork)”，也就是将TCP数据包装在另一种网络包里面进行路由转发和通信，默认的节点间数据通信方式是UDP转发。

　　图10Flannel跨节点Pod通信图

　　举个例子，上图是跨节点Pod通信。

　　可以看到，Flannel首先创建了一个名为?annel0的网桥，而且这个网桥的一端连接Docker0网桥，另一端连接一个叫作?anneld的服务进程。?anneld进程并不简单，它上连etcd，利用etcd来管理可分配的IP地址段资源，同时监控etcd中每个Pod的实际地址，并在内存中建立了一个Pod节点路由表；它下连Docker0和物理网络，使用内存中的Pod节点路由表，将Docker0发给它的数据包包装起来，利用物理网络的连接将数据包投递到目标?anneld上，从而完成Pod到Pod之间的直接地址通信。

　　16

　　4.2.2

　　OVS

　　OpenvSwitch是一个开源的虚拟交换机软件，有点像Linux中的bridge，但是功能要复杂的多。OpenvSwitch的网桥可以直接建立多种通信通道（隧道）。这些通道的简历可以很容易地通过OVS的配置命令实现。在Kubernetes、Docker场景下，主要是建立L3到L3点隧道。如下图所示。

　　图11OVSwithGRE原理图

　　首先，为了避免Docker创建的Docker0地址产生冲突（因为DockerDaemon启动且给Docker0选择子网地址时只有几个备选列表，很容易产生冲突），我们可以将Docker0网桥删除，手动建立一个Linux网桥，然后手动给这个网桥配置IP地址范围。

　　其次，建立OpenvSwitch的网桥OVS，使用ovs-vsctl命令给OVS网桥增加GRE端口，在添加GRE端口时要将目标连接的NodeIP地址设置为对端的IP地址。对每一个对端IP地址都需要这么操作（对于大型集群网络，这可是个体力活，要做自动化脚本来完成）。最后，将OVS的网桥作为网络接口，加入Docker的网桥上（Docker0或者自己手工建立的新网桥）。

　　重启OVS网桥和Docker的网桥，并添加一个Docker的地址段到Docker网桥的路由规则项，就可以将两个容器的网络连接起来了。

　　OVS的优势是，作为开源虚拟交换机软件，它相对比较成熟和稳定，而且支持各类网络隧道协议，经过了OpenStack等项目的考验。另一方面，在前面介绍Flannel的时候可知

　　Flannel除了支持建立Overlay网络，保证Pod到Pod的无缝通信，还和Kubernetes、Docker架构体系结合紧密。Flannel能够感知Kubernetes的Service，动态维护自己的路由表，还通过etcd来协助Docker对整个Kubernetes集群中Docker0的子网地址分配。而我们在使用OVS的时候，很多事情就需要手工完成了。无论是OVS还是Flannel，通过Overlay网络提供的Pod到Pod通信都会引入一些额外的通信开销，如果是对网络依赖特别重的应用，则需要评估对业务的影响。

　　4.2.3

　　Calico

　　Calico是一个纯三层的数据中心网络方案（不需要Overlay），并且与OpenStack、Kubernetes、AWS、GCE等IaaS和容器平台都有良好的集成。Calico在每一个计算节点利用LinuxKernel实现了一个高效的vRouter来负责数据转发，而每个vRouter通过BGP协议负责把自己上运行的workload的路由信息像整个

　　Calico网络内传播——小规模部署可以直接互联，大规模下可通过指定的BGProutere?ector来完成。这样保证最终所有的workload之间的数据流量都是通过IP路由的方式完成互联的。Calico节点组网可以直接利用

　　17

　　数据中心的网络结构（无论是L2或者L3），不需要额外的NAT，隧道或者OverlayNetwork。此外，Calico基于iptables还提供了丰富而灵活的网络Policy，保证通过各个节点上的ACLs来提供Workload的多租户隔离、安全组以及其他可达性限制等功能。下图是Calico的架构图。

　　图12Calico架构图

　　在满足系统要求的新配置的Kubernetes集群上，用户可以通过应用单个manifest文件快速部署Calico。如果您对Calico的可选网络策略功能感兴趣，可以向集群应用其他manifest，来启用这些功能。

　　尽管部署Calico所需的操作看起来相当简单，但它创建的网络环境同时具有简单和复杂的属性。与Flannel不同，Calico不使用Overlay网络。相反，Calico配置第3层网络，该网络使用BGP路由协议在主机之间路由数据包。这意味着在主机之间移动时，不需要将数据包包装在额外的封装层中。BGP路由机制可以本地引导数据包，而无需额外在流量层中打包流量。

　　除了性能优势之外，在出现网络问题时，用户还可以用更常规的方法进行故障排除。虽然使用VXLAN等技术进行封装也是一个不错的解决方案，但该过程处理数据包的方式同场难以追踪。使用Calico，标准调试工具可以访问与简单环境中相同的信息，从而使更多开发人员和管理员更容易理解行为。

　　除了网络连接外，Calico还以其先进的网络功能而闻名。网络策略是其最受追捧的功能之一。此外，Calico还可以与服务网格Istio集成，以便在服务网格层和网络基础架构层中解释和实施集群内工作负载的策略。这意味着用户可以配置强大的规则，描述Pod应如何发送和接受流量，提高安全性并控制网络环境。

　　如果对你的环境而言，支持网络策略是非常重要的一点，而且你对其他性能和功能也有需求，那么

　　Calico会是一个理想的选择。此外，如果您现在或未来有可能希望得到技术支持，那么Calico是提供商业支持的。一般来说，当您希望能够长期控制网络，而不是仅仅配置一次并忘记它时，Calico是一个很好的选择。

　　图13Calico功能模块图

　　18

　　Calico主要由Felix、etcd、BGPclient以及BGPRouteRe?ector组成

　　◎

　　Felix，CalicoAgent，跑在每台需要运行Workload的节点上，主要负责配置路由及ACLs等信息来确保Endpoint的连通状态；

　　◎etcd，分布式键值存储，主要负责网络元数据一致性，确保Calico网络状态的准确性；

　　◎BGPClient（BIRD）,主要负责把Felix写入Kernel的路由信息分发到当前Calico网络，确保Work-load间的通信的有效性；

　　◎BGPRouteRe?ector（BIRD），大规模部署时使用，摒弃所有节点互联的mesh模式，通过一个或者多个BGPRouteRe?ector来完成集中式的路由分发。

　　◎calico/calico-ipam，主要用作Kubernetes的CNI插件

　　4.2.4

　　Contiv

　　Contiv是思科开源的容器网络方案，是一个用于跨虚拟机、裸机、公有云或私有云的异构容器部署的开源容器网络架构，并与主流容器编排系统集成。Contiv最主要的优势是直接提供了多租户网络，并支持L2(VLAN),L3(BGP),Overlay(VXLAN)以及思科自家的ACI。

　　图14Contiv架构图

　　4.3

　　总结对比

　　19

　　图15各种开源技术性能对比

　　CalicoBGP方案最好，不能用BGP也可以考虑CalicoIPIPTunnel方案；如果是CoreOS系又能开UDPO?oad，Flannel是不错的选择；Docker原生Overlay还有很多需要改进的地方。

　　容器平台的网络架构实践

　　5.1

　　某金融企业使用OpenShift（基于Kubernetes的商业版本）实现其业务

　　上云

　　20

　　5.1.1

　　整体网络架构图

　　图16整体网络架构图

　　在DMZ和内网分别部署彼此独立的2套OpenShift，分别为内网和DMZ区两个网段，两套环境彼此隔离。DMZ区的OpenShift部署对外发布的应用，负责处理外网的访问。内网的OpenShift部署针对内网的应用，仅负责处理内网的访问。

　　5.1.2

　　传统应用访问策略

　　方案推荐通过NodePort类型的Service为某个应用对外暴露一个服务端口。NodePort类型的Service会在集群中的所有节点上监听一个特定的端口，访问任意一个计算机节点的端口，即可访问内部容器中的服务。在集群的所有节点的这个端口都会预留给该应用所用。在F5VS的PoolMember中配置所有节点，通过Kee-palived来实现HA。应用系统和用户不用改变现有的访问方式。

　　图17传统应用访问策略

　　21

　　5.1.3

　　数据库访问方案及防火墙策略

　　内网计算节点可以直接访问数据库，DMZ区计算节点访问数据库有2种方案：

　　（1）计算节点直接通过内网防火墙访问该应用数据库内网防火墙仅开通应用所在节点访问内部数据库的端口，例如本期方案中应用仅使用2个节点，则防火墙仅开通这2个节点访问数据库的权限。

　　图18计算节点直接通过内网防火墙访问该应用数据库

　　（2）计算节点经Outbound路由通过内网防火墙访问内网数据

　　这Outbound路由在OpenShift中称之为EgressRouter

　　图19经Outbound路由通过内网防火墙访问内网数据

　　因此，内网防火墙仅开通应用所在节点访问内部数据库的端口，例如，应用A仅通过路由节点A和B访问内部数据库，则防火墙仅开通这2个节点访问A数据库的权限。

　　22

　　图20通过OutBoundRouter访问数据库

　　5.2

　　某金融企业两第三中心容器云网络架构

　　图21某企业两第三中心容器云架构

　　平台基于多集群管理和联邦集群特性，对两地三中心、同城双活、异地灾备等业务场景提供了原生的支持。平台以统一多集群管理为核心，可对接稳定快速的物理机服务器、资源利用率高的虚拟机、不同云环境下的云主机创建Kubernetes集群。支持运行多集群，保证集群的高可用。提供跨云的多集群统一管理，解决多云灾备问题，实现统一部署、统一发布以及统一运维。通过mirror联邦集群，为已经存在的集群进行组件

　　23

　　联邦集群。可以在联邦内选择在一个或多个集群创建。

　　优化实践

　　网络优化是一个非常复杂的话题，现实场景中，如果出现服务不可用的情况，往往都会怀疑到网络上面

　　——网络不可达，网络拥塞，网络设备失效等等。一个容器平台网络的高效稳定安全，涉及方方面面的设计

　　考量。这里将我们在实践中的一些优化措施作了一些总结：

　　（1）主节点优化

　　在集群中，除了Pod之间的网络通信外，最大的开销就是master和etcd之间的通信了，因此：

　　Master侧可以优化：

　　◎

　　Master和etcd尽量部署在一起

　　◎

　　高可用集群中，Master尽量部署在低延迟的网络里

　　◎

　　确保**/etc/origin/master/master-con?g.yaml**里的etcds，第一个是本地的etcd实例Node侧可以优化：

　　Node节点的配置主要在**/etc/origin/node/node-con?g.yaml**里，可以优化：iptables,synchronizationperiod,MTU值，代理模式。配合自文件里还可以配置Kubelet的启动参数，主要关注亮点pods-per-core和max-pods，这两个决定了Node节点的Pod数，两者不一致时，取小。如果数值过大（严重超读）会导致：

　　◎

　　增加CPU消耗，主要是Docker和OpenShift自身管理消耗的

　　◎

　　降低Pod调度效率

　　◎

　　加大了OOM的风险

　　◎

　　分配PodIP出现异常

　　◎

　　影

　　响

　　应

　　用

　　性

　　能etcd节点：尽量和Master部署在一起，或者提供专网连接。

　　（2）主机节点万兆网卡性能优化

　　如果主机用万兆或者40Gbps，那么可以优化的方面：

　　24

　　◎

　　通过直接路由，负责Pod间通信，不过需要手动维护Node节点添加删除时的路由变化

　　◎

　　条件允许的话，可以考虑BGP的Calico网络方案

　　◎

　　购置支持UDPO?oad的网卡，需要注意的是，使用了UDPO?oad网卡和非Overlay网络相比，延迟是不会减少的，只是减少了CPU开销，提到带宽吞吐。

　　（3）IPIP模式的Flannel性能提升

　　汲取了Flannel/Calico容器网络开源项目的优点，实现了基于IPIP和HostGateway的Overlay网络，具体性能—短链接VXLAN比host差33%，IPIP比host差23%，Gateway比host只差6%。具体参见下图：

　　（4）使用指定的UnderlayIP优化

　　图22IPIP模式Flannel性能提升

　　FloatingIP指定宿主机提供的IP，将IP直接配置到容器中，有别于OpenStack（将FloatingIP配置到宿主机的网络空间再通过NAT转发）的实现，其性能更好，容器与物理机可以直接路由。Tunnel网卡在容器中创建，避免了使用NodePort带来的性能损耗。具体参见下图：

　　图23使用指定的UnderlayIP优化

　　（5）cgroup实现资源隔离

　　25

　　在cgroup提供的能力之上，实现了网络出入带宽、资源隔离的能力，并提供所有硬件资源的可弹性配置，使得容器硬件资源全维度可弹性配置，大度提升了应用的隔离性与稳定性。在实际的运营过程中，我们发现，用户往往不能很好的预先设置最急limit值，设置过大会导致资源浪费，设置过小又会导致业务性能损失甚至业务进程频繁OOM，弹性的优势在于，用户不需要配置limit值，系统可以自动将空闲资源交给业务容器使用。使得容器的稳定性、集群资源利用率均得到提升。

　　图24cgroup对网络资源的优化

　　如上图，某个cgroup网络繁忙时，能保证其设定配额不会被其他cgroup挤占；某个cgroup没有用满其配

　　额时，其他cgroup可以自动使用其空闲的部分带宽；多个cgroup分享空闲带宽时，优先级高的优先占用，优先级相同时，配额大的占用多，配额小的占用少，减少为了流控而主动丢包。

　　（6）基于DPDK技术实现对DDos攻击防护

　　（7）网络带宽QoS相关

　　网络带宽QoS主要是为了保证用户所申请的带宽资源，以及有效利用空闲的网络资源，尽可能提升用户带宽体验。那么我们可以做的事：

　　基于LinuxTra?cControl并修改OVS，实现保证速率，最大速率；

　　将小包按照MPU（MinimumPacketUnit）大小来处理

　　同时，针对VXLAN小包处理性能不好，网络小包过多导致宿主机CPU过载，影响网络性能和稳定性的问题，通过限制容器网络的PPS（PacketPerSecond）来处理。

　　26

篇五：容器网络流量研究教授

　　NetFlow流量采集与聚合的研究实现

　　时间：2009-07-1009:21:32来源：现代电子技术

　　作者：郭剑云

　　曹庆华

　　0引

　　言

　　近年来，随着信息技术的飞速发展，越来越多的企业和大型机构在其内部构建基于网络的应用，复杂程度及对网络的依赖程度日益提高，各种各样的网络问题也随之产生。网络流量监测是网络管理和系统管理的一个重要组成部分，网络流量数据为网络的运行和维护提供了重要信息。这些数据对网络的资源分布、容量规划、服务质量分析、错误监测与隔离、安全管理都十分重要。因此，对网络流量及相关情况实施科学合理的监管和深入分析，成为网络管理的重要环节之一；同时，它也为网络问题提供有效解决方案及进行网络的规划。

　　目前的网络流量分析方法主要有基于SNMP、基于实时抓包分析、基于网络探针和基于：Flow技术等几种。NetFlow基于Flow技术，目前已得到大多数网络设备厂商的支持，提供了网络监测方面非常完善的应用。基于NetFlow的流量采集方法可以获得包括源／目的主机IP、应用协议类型、源／目的端口等详细信息，根据这些信息就可以对协议(应用)、主机IP(用户)以及AS域等进行统计排行和趋势分析，也可对异常流量进行监测分析。此外，NetFlow避免了大量部署和配置监测探针的复杂过程，使得网络性能分析更加全面、灵活且简单易用。

　　lNetFlow技术

　　NetFlow是Cisco公司提出的基于CiscoIOS系统的一种应用。它用于提供网络设备上数据包形成的“流”的统计信息，并逐渐演变成为网络流量统计和安全分析的主要手段。目前利用：NetFlow可以实现网络流量监测，用户应用监控，网络安全，网络规划以及流量计费等功能。

　　NetFlow有两个核心的组件：NetFlow缓存，存储IP流信息；NetFlow的数据导出或传输机制，NetFlow利用此机制将数据发送到网络管理采集器。

　　1．1流(Flow)的定义

　　一条流由一个源主机与一个目的主机间的单方向传输的网络数据包组成，其中，源和目的主机由各自的IP地址和端口号来标识。一条流一般由以下七个关键字段惟一标识：

　　·源地址

　　·目的地址

　　·源端口号

　　·目的端口号

　　·第3层协议类型(如TCP，UDP)

　　·服务类型

　　·入逻辑接口标示符

　　1．2流(Flow)格式

　　启动NetFlow的设备会输出其缓冲区里的信息，以UDP包的形式传送给NetFlow流量采集器。包由包头和若干流记录组成。常用的NetFlOW输出包格式共有5个版本，它们分别是Version1，Version5，Ver-sion7，Version8和Version9，其中V5是最为流行和成熟的版本，目前得到最广泛的使用。最新的V9已经被列入IETF的标准，并有待进一步研究和规范。V9采用了模板技术与流记录相结合的方式，使NetFlow输出包的格式具有动态和可扩展的特性。NetFlowV9的输出格式主要由三部分构成：

　　(1)包头部(PacketHeader)：包括版本号、包中数据流总数、系统时间、数据流序列、数据源ID等。

　　(2)模板流集(TemplateFlowSet)：包含一个或多个模板，模板是用于描绘数据流中各个数据段的含义，可以在路由器上根据需要自行设置模板。

　　(3)数据流集(。DataFlowSet)：包含多个数据流，每个数据流集通过模板ID对应某个模板。数据采集端根据模板来解析数据流。

　　2NetFlow流量采集与聚合

　　2．1系统概述

　　根据NetFlow的特点，设计并实现了一个网络流量监测系统，其系统结构如图1所示。

　　当NetFlow采集器接收到从路由器发送来的Net-Flow数据包后，采集器将进行数据包的解析和数据流聚合，形成多种适合统计分析需要的数据，再分门别类地存入数据库。分析器则根据前端不同的查询请求，依照一定的查询策略从数据库不同的表中提取相应数据进行分析展现。

　　本系统的后台采集器和聚合处理部分用JAVA编写实现，数据库采用开源的MySQL，而NetFlow流量分析利用Tomcat服务器通过Web方式展现，前台部分用JSP编写实现。工作的重点即在于数据采集、数据聚合以及数据库设计部分。

　　2．2NetFlow流采集

　　2．2．1采集器的设计

　　数据采集模块是整个系统的基础。由于。NetFlow数据流量非常大，为防止丢包系统采用缓冲区和线程池结构，如图2所示。

　　当采集器监听到一个NetFlow数据包时，将该数据包接收到缓冲区，并从包解析线程池中取出一个线程，根据相应的NetFlow的报文格式解析出数据流信息，将该原始流信息放入缓冲区，然后将原始流存入数据库，同时采用相应的聚合策略聚合原始流生成聚合流并存入相应的数据库中。

　　2．2．2NetFlow数据包接收与解析

　　由于NetFlow数据是借助于UDP数据报来传送，因而倘若后续的处理速度跟不上数据包到达的速度，则会出现严重丢包的现象。为解决高速大流量数据的及时接收及较低丢包率问

　　题，采用了多线程的方式来实现。用独立的两个线程分别完成数据接收和解析操作：接收数据的线程在特定的IP地址监听相应的UDP端口，接收到的数据暂存在缓冲区中；解析线程从缓冲区提取数据，按照相应的报文格式进行解析。由于接收线程和解析线程共享同一个临界资源，即接收的缓冲区，需要对临界资源进行加锁操作。

　　下面为部分实现多线程采集的JAVA代码实例，其中packet为接收的NetFlow数据包对象，linkedLst为linkedList容器，利用synchronized进行线程间同步。

　　(1)接收线程

　　2．3NetFlow流聚合

　　NetFlow的原始数据数据量非常庞大，保存每一条流数据的原始记录将会使对数据进行查询分析时产生效率低下的问题，在绝大部分应用中也没有必要把数据粒度设计得如此之小。所谓流量聚合，是指对符合NetFlow数据格式的原始流记录根据一定条件进行流量合并，实现多条流合并为一条的过程，以实现原始流的压缩整理。

　　2．3．1聚合策略

　　流量聚合有三个关键要素：聚合条件(F)、时间粒度(T)和聚合项(C)。满足相同聚合条件和时间粒度的流进行流量叠加，并保留聚合项。三元组聚合策略：，其中：

　　按照实际流量分析的需要，从F，T，C中各取出一个值组成一个聚合策略。对于T的粒度要根据实际监控的时间长短和监测精度来设置，一般来说T＝3min适合于当天实时流量的监测；T＝30min用于一周流量的分析；T＝3h用于一月内流量的分析。

　　2．3．2聚合的实现

　　对于一个新采集的原始流，必须能根据其所携带的聚合条件信息快速匹配是否已存在与其相同聚合条件的聚合流，若有则做流量叠加，若没有则创建一条新的聚合流。Hash表具有从Key快速映射到Value的特点，这种特点对于实时性较高的聚合非常有意义。图3为流量聚合的}Iash表设计。

　　在图3中聚合条件(F)作为Key，聚合项(C)作为Hash函数的映射值，时间粒度(T)作为Hash表导出到数据库的时间。这样可以满足实时流量监测的需要，同时也压缩数据减少存储空间，提高数据的查询效率。

　　3实际NetFlow流采集与流量监测

　　在本系统设计的数据采集器的支持下，系统数据库为前端分析提供了充足且多样化的数据准备，前端程序只需通过简单的查询语句即可得到所需的数据集，简化了查询的工作量。利用该系统采集NetFlow数据包50000个，时间持续约7h，时间粒度为3min，主要检验丢包情况，以及聚合后压缩效率。这次采集无丢包发生，表1为该系统采集的数据结果。

　　图4是系统由所采集的数据生成的该时段的流量监测图。

　　4结

　　语

　　NetFlow数据流的海量特征使得服务器程序的效率至关重要，因此基于NetFlow的流量监测的主要任务是如何根据应用保存最重要的网络流特征以及如何更高效地实现数据检索。基于NetFlow特点，提出了一套适用于大流量网络的流量采集与聚合存储方案。流量采集通过多线程和缓冲区机制实现，有效提高了流量采集的可靠性。采集的原始流经聚合，并通过合理的分级存储策略进行存储组织，为前端的数据分析提供了全面支持。本系统在实际应用中取得了良好效果。下一步还将对采集和多级聚合存储方案进行改进，以丰富系统对网络流量统计分析功能，并力争为异常流量分析提供较为完善的数据支持。

　　第二篇：

　　Netflow的版本演进

　　在Netflow技术的演进过程中，思科公司一共开发出了5个主要的实用版本，即：

　　*NetflowV1，为Netflow技术的第一个实用版本。支持IOS11.1，11.2，11.3和12.0，但在如今的实际网络环境中已经不建议使用。

　　*NetflowV5，增加了对数据流BGPAS信息的支持，是当前主要的实际应用版本。支持IOS11.1CA和12.0及其后续IOS版本。

　　*NetflowV7，思科Catalyst交换机设备支持的一个Netflow版本，需要利用交换机的MLS或CEF处理引擎。

　　*NetflowV8，增加了网络设备对Netflow统计数据进行自动汇聚的功能（共支持11种数据汇聚模式），可以大大降低对数据输出的带宽需求。支持IOS12.0（3）T，12.0（3）S，12.1及其后续IOS版本。

　　*NetflowV9，一种全新的灵活和可扩展的Netflow数据输出格式，采用了基于模板（Template）的统计数据输出。方便添加需要输出的数据域和支持多种

　　Netflow新功能，如MulticaseNetflow，MPLSAwareNetflow，BGPNextHopV9，NetflowforIPv6等。支持IOS12.0（24）S和12.3T及其后续IOS版本。在2003年思科公司的NetflowV9还被IETF组织从5个候选方案中确定为IPFIX（IPFlowInformationExport）标准。

　　Netflow数据输出格式

　　下面对网络流量和流向分析系统中最常使用的NetflowV5数据输出的数据包格式进行一个简单介绍。

　　下图为Netflow输出数据包的包头格式：

　　下图为包含在每个NetflowV5输出数据包中的具体数据流的流量和流向统计信息的数据格式：

　　NetflowV9的数据输出格式与V5有较大区别，主要是因为NetflowV9采用了基于模板式的数据输出方式。网络设备在进行NetflowV9格式的数据输出时会向上层管理服务器分别发送数据包模板和数据流纪录。数据包模板确定了后续发送的数据流纪录数据包的格式和长度，便于管理服务器对后续数据包的处理。同时为避免传输过程中出现丢包或错误，网络设备会定期重复发送数据包模板给上层管理服务器。

　　如何利用Netflow技术进行IP网的流量和流向分析

　　为充分利用思科Netflow技术在网络流量和流向信息采集和分析领域的强大功能，运营商可以对现有网管中心的网络流量管理系统进行技术改造，在原有利用SNMP协议或RMON协议进行数据采集的基础上，用Netflow技术对其进行补充甚至进行替代。

　　下面对利用Netflow技术在运营商网络中的几种典型使用方式进行介绍。

　　互联网交换中心（NAP）流量和流向监控

　　互联网交换中心作为专为ISP提供网络互联和交换网络通信的汇聚点，需要及时、准确地掌握各个ISP网络间的通信流量和流向数据，为交换中心合理规划路由策略和调整ISP的接入带宽提供依据。

　　为此互联网交换中心的管理员可以在核心交换设备与每个ISP互联的网络端口上启动Netflow数据采集。如果ISP的接入端口为高速率端口（如速率超过

　　OC-12），还可以选择采用数据包抽样Netflow采集方式，减少对核心交换设备的资源消耗和Netflow统计结果的输出数据量。

　　通过进一步分析还可以发现，交换中心作为提供ISP互联的服务商，只需要关注下联ISP间的通信流量和流向统计，而无需进行更加详细的统计分析（如基于IP地址，IP网段，服务类型等的流量和流向分析）。由于每个ISP都有各自不同的BGPAS号码，所以交换中心管理员还可以进一步优化核心交换设备的Netflow数据输出选项：利用NetflowV8开始支持的统计数据内置汇聚功能，由核心交换设备对采集到的原始统计数据进行针对不同源和目的地BGPAS号的统计汇总，只把汇总后的统计结果发送给上层管理系统。这样不但可以大大减少输出给上层管理系统的统计数据量，还可以简化上层管理系统的数据分析负荷，使其能够更加简便快速地生成所需的统计报表。

　　下图为一个典型的互联网交换中心利用Netflow技术进行ISP间通信流量和流向管理的系统结构图：

　　运营商间互联链路的流量和流向监控

　　每个电信运营商的网络都是通过互联链路与一个或多个其它运营商的网络相连接的。运营商为更好地服务自己的企业客户或个人用户，需要了解自己客户访问网络的模式以及访问网络资源的所在位置；同时运营商为了和其它运营商谈判签订双边或多边网络访问协议，也需要对双方相互访问的网络资源进行评估，这些都需要对双方网络互联链路进行通信流量和流向的监控和统计。

　　为实现对运营商间互联链路的流量和流向管理，管理员可以在每个与其它运营商互联的边界路由器上启动Netflow，对互联网络端口进行数据采集。根据互联链路的端口速率，可以选择全Netflow采集或数据包抽样Netflow采集方式。

　　由于管理员需要分析自己客户的详细网络访问纪录，了解他们需要获取的网络资源的确切位置，所以管理中心应该收集尽可能详尽的Netflow统计数据，意味着启动了Netflow数据采集的边界路由器不应做任何统计数据的汇聚，而应把Netflow原始统计记录直接发送给上层管理服务器。管理服务器在接收到各个边界路由器发送来的Netflow原始统计记录后，可以对数据进行统一分类处理或把原始记录存储到数据仓库中，由后续的数据挖掘应用程序对入库的数据进行细致分析，并生成运营商需要的统计报表。

　　下图为运营商利用Netflow技术监控与其它运营商间互联链路流量和流向的管理系统实施示意图：

　　企业客户流量计费

　　随着中国宽带互联网的发展，越来越多的企业客户开始利用宽带网络改变公司的业务处理流程。电信运营商为了适应这种需求，需要提供比往更加丰富的服务内容，如不但提供数据接入业务，还可以提供IP电话、视频和网络存储等业务。由于不同类型业务的差异性，传统固定费率的计费方式也开始变得不能满足客户的需要。运营商需要跟随客户需求的转变，同步改变自己的运营支撑系统，提供多种灵活的业务计费方式供客户选择。

　　利用Netflow技术，运营商可以精确统计出客户租用的接入链路上传送各种不同类型业务的通信流量，包括业务类型，服务等级，通信时间和时长，通信数据量等参数。这些详细的通信流量统计数据可以被运营商的计费和帐务系统进行处理，生成基于客户业务流量的计费账单。

　　为实现客户的业务流量计费，需要在接入客户的所有接入路由器相应网络端口上都启动Netflow数据采集。由于计费数据要求高精确性，所以应该尽量采用全Netflow数据采集方式，避免使用数据包抽样的Netflow数据采集方式。

　　接入路由器采集到的Netflow流量统计数据需要被统一发送给运营商的计费系统，由其进行不同类型业务的流量分类，汇总、批价和计费，最终由帐务系统生成提交给客户的计费账单。

　　下图为利用Netflow技术采集客户业务流量信息的运营支撑系统结构图：

　　运营商网络优化

　　为提高客户对运营商网络的使用满意度，运营商需要及时了解自己网络的负载状况，正确预测可能出现的网络瓶颈，适时规划未来的网络升级，这些管理需求都可以通过利用Netflow技术对运营商网络进行准确的网络带宽使用率监测和网络流向分析来实现。

　　由于主要是实现对运营商网络的优化，所以不一定需要对网络中传送的所有流量数据进行100%的监测。为减少对网络设备的资源占用，降低对上层管理系统的容量要求，可以选用数据包抽样的Netflow数据采集方式，对核心网络的重点链路进行统计。采集到的抽样统计数据可以利用上层管理系统进行全网集中处理，也可以分区域进行局部处理，分别计算出全网的通信流量和流向统计报表或部分区域的通信流量和流向统计报表。由此管理员可以迅速发现网络当前的使用状况，不同链路的使用率变化趋势，并可以此为依据规划网络是否需要调整和扩容，最终实现网络的优化使用。

　　下图为利用Netflow技术进行运营商核心网络优化的管理系统结构图：

　　上一篇：用Netflow进行IP网流量和流向分析（１）

　　下一篇：菜鸟教程：子网掩码基础教学篇

　　V5：

　　FieldName

　　Description

　　Offset

　　Length

　　in

　　Bytes

　　SourceIPaddr

　　DestinationIPaddr

　　NexthoprouterIPaddress

　　InboundsnmpIFindex

　　IPaddressofthedevicethatsenttheflow

　　0

　　IPaddressofthedestinationdevice

　　n/a

　　SNMPindexnumberthatidentifiestheInbound12

　　interfaceonthePacketeerunit:

　　1Inside(built-in)

　　2Outside(built-in)

　　3Upper_Inside(upperLEM)

　　4Upper_Outside(upperLEM)

　　5Lower_Inside(lowerLEM)

　　6Lower_Outside(lowerLEM)

　　SNMPindexnumberthatidentifiestheOutboundinterfaceonthePacketeerunit:

　　1Inside(built-in)

　　2Outside(built-in)

　　3Upper_Inside(upperLEM)

　　4Upper_Outside(upperLEM)

　　5Lower_Inside(lowerLEM)

　　6Lower_Outside(lowerLEM)

　　PacketCount

　　ByteCount

　　TimeatStartofFlow

　　TimeatEndofFlow

　　SourcePort

　　DestinationPort

　　Onepadbyte

　　Numberofpacketsintheflow

　　Totalnumberofbytesintheflow

　　ValueofSysUpTimewhenthefirstpacketintheflowwasseen(measuredinmilliseconds)

　　ValueofSysUpTimewhenthelastpacketintheflowwasseen(measuredinmilliseconds)

　　Portnumberofthedevicethattheflowwentoutof

　　Portnumberofthedevicethattheflowwentto

　　n/a

　　Protocolstate(URG=32,ACK=16,PSH=8,TCPflags

　　RST=4,SYN=2,FIN=1).Forexample,avalueof27indicatestheflowhadaSYN,ACK,PUSH,andFIN(2+16+8+1=27).

　　Typeoflayer4protocol.Forexample,ICMP=1,TCP=6,Telnet=14,UDP=17

　　37

　　16

　　20

　　14

　　OutboundsnmpIFindex

　　24

　　28

　　32

　　34

　　36

　　Layer4Protocol

　　38

　　IPTypeofService(ToS)/Diffserv

　　Valuethatdesignatesspecialhandlingoftraffic(precedence,delay,throughput,andreliability)

　　39

　　SourceAutonomousSysID

　　Dest.AutonomousSysID

　　SourceMaskBitsCount

　　DestinationMaskBitsCount

　　TwoPadBytes

　　n/a

　　42

　　n/a

　　40

　　n/a

　　44

　　n/a

　　45

　　n/a

　　46

　　FLOWHEADERFORMATBytes

　　Contents

　　Description

　　NetFlowexportformatversionnumber

　　Numberofflowsexportedinthispacket(1-30)

　　Currenttimeinmillisecondssincetheexportdevicebooted

　　Currentcountofsecondssince0000UTC1970

　　Residualnanosecondssince0000UTC1970

　　0-1

　　version

　　2-3

　　count

　　4-7

　　sys_uptime

　　8-11

　　unix_secs

　　12-15

　　unix_nsecs

　　16-19

　　flow_sequence

　　Sequencecounteroftotalflowsseen

　　20

　　21

　　engine_type

　　engine_id

　　Typeofflow-switchingengine

　　Slotnumberoftheflow-switchingengine

　　Firsttwobitsholdthesamplingmode;remaining14bitsholdvalueof22-23

　　sampling_interval

　　samplinginterval

　　FLOWRECORDFORMATBytes

　　Contents

　　0-3

　　srcaddr

　　SourceIPaddress

　　4-7

　　dstaddr

　　DestinationIPaddress

　　Description

　　8-11

　　nexthop

　　IPaddressofnexthoprouter

　　12-13

　　input

　　SNMPindexofinputinterface

　　14-15

　　output

　　SNMPindexofoutputinterface

　　16-19

　　dPkts

　　Packetsintheflow

　　20-23

　　dOctets

　　TotalnumberofLayer3bytesinthepacketsoftheflow

　　24-27

　　first

　　28-31

　　last

　　SysUptimeatstartofflow

　　SysUptimeatthetimethelastpacketoftheflowwasreceived

　　32-33

　　srcport

　　TCP/UDPsourceportnumberorequivalent

　　34-35

　　dstport

　　TCP/UDPdestinationportnumberorequivalent

　　36

　　37

　　38

　　39

　　pad1

　　Unused(zero)bytes

　　tcp_flags

　　CumulativeORofTCPflags

　　prot

　　tos

　　IPprotocoltype(forexample,TCP=6;UDP=17)

　　IPtypeofservice(ToS)

　　Autonomoussystemnumberofthesource,eitheroriginorpeer

　　Autonomoussystemnumberofthedestination,eitheroriginorpeer

　　40-41

　　src_as

　　42-43

　　dst_as

　　44

　　45

　　src_mask

　　Sourceaddressprefixmaskbits

　　dst_mask

　　Destinationaddressprefixmaskbits

　　Unused(zero)bytes

　　46-47

　　pad2

　　Netflow数据输出格式

　　下面对网络流量和流向分析系统中最常使用的NetflowV5数据输出的数据包格式进行一个简单介绍。

　　下图为Netflow输出数据包的包头格式：

　　下图为包含在每个NetflowV5输出数据包中的具体数据流的流量和流向统计信息的数据格式：

　　系统处理能力估算模型的分析

　　：

　　2.6.1

　　计算数据的取定

　　首先取定以下计算数据:

　　a)一个NetFlowV5输出数据包的包长为1500Byte;

　　b)一个NetFlowV5输出数据包中包括的Flow的数量为30;

　　c)网络流量中数据包的平均包长为384Byte;

　　d)采样率:500:1

　　其中，NetFlowV5输出数据包的包长及其包括的Flow的数量是确定的，而网络流量中数据包的平均包长、采样率则需要根据具体的网络状况进行取定。

　　2.6.2

　　系统处理能力

　　流量分析系统实现对NetFlow数据的采集和分析处理，本文采用“每秒处理Flow数”来衡量系统的处理能力。

　　在估算系统处理能力时，首先要计算系统需要分析的流量大小(Gbit/s)，然后根据前面已经取定的计算数据，系统每秒需要进行处理的Flow数量为:(系统需要分析的流量大小×1024×1024×1024)/(500×384×8)

　　2.6.3

　　流量数据采集带宽

　　采集NetFlow数据需要占用一定的网络带宽。

　　计算出系统每秒需要进行处理的Flow数量之后，就可以计算出采集NetFlow数据需要的网络带宽(Mbit/s)最大为:(系统每秒需要进行处理的Flow数量/30)×1500×8/1024/1024

篇六：容器网络流量研究教授

　　龙源期刊网http://www.qikan.com.cn基于Docker容器技术的Host网络通信模式研究

　　作者：赵星月

　　来源：《科学与财富》2017年第06期

　　摘

　　要：Docker是PaaS提供商DotCloud[1]开源的一种虚拟化容器技术。对于正处于互联网云计算时代的我们，容器级别的应用服务已经逐步的走进了生活的每个角落，2015年春节晚会新浪微博的抽奖活动，就让13亿的国人享受了一次容器技术给我们带来的服务体验。自Docker发布以来容器间的通信模式一直都是一个技术研究的课题，那是因为人们针对容器使用的出发角度各不相同，本文主要针对Host网络通信模式进行了深入的研究，发现这种通信模式存在容器间端口冲突的问题，于是针对这个问题提出了通过Macvlan[2]构建虚拟容器网络的技术解决方案，并通过实验证明了该方案的可行性。通过Macvlan构建的虚拟容器网络可以让容器像主机一样拥有自己的IP地址和网卡端口等，这样依附于宿主机的容器就不必与宿主机共享端口，从而避免了端口冲突的问题。

　　关键词：Docker；通信模式；Macvlan0引言

　　Docker支持的容器间网络通信模式有四种，分别是host模式、container模式、none模式和bridge模式[3]。而被大家广泛应用的host模式却存在一个基础性的端口冲突的问题，在同一宿主机上共存的两个容器如果采用host模式是不可以同时映射宿主机同一个端口号的，否则会导致后创建的容器启动失败。而通过Macvlan为容器创建虚拟Mac地址，从而创建专属的虚拟网卡，这样我们就可以为容器创建虚拟的网络IP，容器不需要再与宿主机映射端口号[6]来实现网络通信。这样既避免了Host模式下的端口冲突问题，又极大的增加了宿主机网络资源的利用率。本文通过实验对这个解决方案做出了详细的论证与分析。

　　1Host网络通信模式的原理

　　我们在宿主机上创建docker容器，根据docker引擎的命令语法规则需要通过参数p来配置需要映射的端口号，例如dockerrun-namehelloworld-p80：80helloworld：1.0tail-flook.log，然后docker引擎会查询宿主机80端口是否被占用，如果被占用则创建容器失败，如果未被占用，则将宿主机的80端口分配给helloworld这个容器，并且该容器不会创建自己专属的NetworkNamespace，而是与宿主机公用同一个NetworkNamespace[8]，容器也不会虚拟出属于自己的虚拟网卡和IP地址，容器就像宿主机中启动的一个软件一样共享者宿主机的网络资源，而容器的文件系统和进程资源还是与宿主机是相互隔离的。

　　1.1Host网络通信模式的过程

篇七：容器网络流量研究教授

　　龙源期刊网http://www.qikan.com.cn基于Kubernetes的容器云平台建设

　　作者：王伟军

　　来源：《电脑知识与技术》2019年第36期

　　摘要：Kubernetes（简称K8S）已经成为容器云管理的事实标准，如何构建K8S容器云平台具有很大的市场空间和现实意义。本文通过分析容器云的软硬件设施，K8S的核心部件构成，结合比较成熟的开源解决方案，给出了建设K8S容器云平台的基本架构，对于中小企业搭建容器云平台，具有现实的参考意义。关键词：Kubernetes;容器云;镜像仓库;日志管理;监控告警

　　中图分类号：TP391文献标识码：A

　　文章编号：1009-3044（2019）36-0047-02

　　在云计算时代，企业在线购买云厂商的云主机，在数分钟之内，就可以创建出所需的多台虛拟机，部署企业自己的应用。与购买硬件设备自己搭建的传统方法相比，响应速度有了很大的改进，实施效率有了很大的提高。

　　但是在云主机的操作系统上构建自己的应用，还涉及应用软件运行环境的准备，采用云主机方式仍然需要一个较长时间的部署过程。

　　容器技术的出现为云计算增添了新的活力，通过对应用和运行环境的整体打包，生成单一的镜像，在任何Docker平台上部署一个Web应用，只需要一条命令，在几秒之内就可以完成应用部署，极大地提升了应用部署的效率。

　　在单机上运行容器非常方便，对于多台机器上的容器之间，如何进行协同工作，容器编排管理成为竞争热点。经过了这几年容器技术的高速迭代和发展，K8S打败了Swarm和Me-sos，成为容器编排的企业标准。国外的主要云服务厂商亚马孙、谷歌，国内的阿里云、腾讯云和华为云等等，均已推出K8S容器云服务，为企业提供正式的商业服务。

　　Kubernetes具有很多优点：屏蔽了底层硬件的差异;支持上千台的大规模计算机集群;支持高可用部署;具有弹性伸缩能力，可以扩展或收缩容器的规模，应对突发访问请求;容器部署与复制白动完成;将容器组成服务，提供容器级的负载均衡;集群内机器宕机、容器失效，集群自动修复，具有容错能力、白愈能力;开源社区活跃，各大IT厂商纷纷支持;非常适合互联网应用。正因K8S具有这么多的优点，掌握K8S容器云技术，建设K8S容器云平台势在必行。

　　1容器云的硬件基础设施

　　龙源期刊网http://www.qikan.com.cn

　　云平台是运行在硬件设备上的，建设容器云平台，服务器、存储、交换机、防火墙等设备同样不可缺少。服务器可以直接使用裸机部署以减少性能损失，也可以通过KVM或VMWare，先虚拟化，获得更多的虚机，继而在虚机的基础之上，再进行架构设计。好处是虚拟机多，平台架构设计更加灵活，可以根据业务需要，创建多个K8S平台。缺点是多了一层虚拟化，硬件性能会有所损耗。

　　K8S需要存放应用的持久化数据，存储设备也是必不可少的，直接购买存储厂商的存储，性能和售后均有保障。如果企业有自己的研发力量，为降低成本，也可以自行构建Ceph、GlusterFS等分布式存储，提供文件系统和块存储设备以及对象存储设备。

　　运行K8S平台的主机节点，需要有网络层支撑。网络架构设计上划分管理网、数据网、外部网等也是必要的，可有效隔离网络管理流量和数据业务流量。服务器多个网卡，尽可能使用万兆设备解决网络带宽的瓶颈问题。在网络出口处，对外发布的应用，还需要相应的网络安全、负载均衡设备来保证应用的安全和性能。

　　2容器云的软件运行环境

　　K8S容器云是运行在Linux系统及Docker容器环境之上的，Linux系统有很多发行版本，UbuntuServerLTS版本是推荐的操作系统，更适合运行K8S容器云平台。整个K8S平台的架构，都是以Docker容器技术为基础的，K8S的所有组件以及用户的应用软件，都是运行在Docker容器环境之上。

　　3K8S核心组件的部署

　　K8S的核心组件分为两类，一类安装在管理节点上，另一类安装在工作节点上。

　　在管理节点上主要运行Etcd、APIServer、Scheduler、Control-ler-Manager等核心组件。APIServer为K8S集群提供统一的访问接口，实现身份认证、授权和准入控制、API注册和发现等功能，对于整个K8S集群的操作，都是通过API进行的，管理员使用Kubectl命令行工具通过APIServer实现对K8S集群的管理。Etcd数据库存储整个K8S集群的重要信息，只有APIServer能够访问Etcd数据库。Scheduler根据各种调度策略，负责将Pod调度到相应Node节点上运行。K8S中的各种资源有对应的控制器（Controller），Controller-Manager组件负责K8S中各种控制器的管理，监控并维护整个集群达到期望的状态。

　　工作节点上主要运行Kubelet和Kube-proxy等核心组件。Kubelet主要负责容器的创建删除等生命周期管理，以及容器的存储、网络管理、健康检查、监控等。Kube-proxy监听APIServer中Service和Endpoint的变化，通过IPtables或IPVS模式，创建路由规则，实现Service和Pod之间的服务负载均衡。

　　龙源期刊网http://www.qikan.com.cnK8S架构复杂，核心组件也较多，技术人员学习掌握比较困难。使用K8S二进制软件包方法安装、使用官方Kubeadmin工具安装K8S，许多镜像因为网络访问的问题无法下载，K8S部署经常出现问题。为解决K8S学习难操作难的问题，出现了Rancher和Kubesphere等比较优秀的开源K8S管理解决方案，大大降低了学习和操作的难度，K8S易用性有了很大提高，更适合企业云平台部署。

　　4私有镜像仓库管理

　　企业内部的应用往往包含敏感数据，不适合运行在公有云上，企业也希望这些应用的Docker容器镜像能保存在内部网络中。另外，与从公共镜像仓库下载容器镜像相比，内部网络带宽更大，K8S部署容器更快捷稳定。企业有必要在内部搭建一套私有镜像仓库。Harbor就是一款很好的私有镜像仓库产品。

　　Harbor是VMWare公司开源的容器镜像管理产品，它在Docker官方的简易仓库Registry基础上，加入多个组件，实现了项目管理、用户权限管理、镜像管理、Web图形界面等基本功能，成为一款企业级的开源镜像管理产品。由于它采用容器化的安装方式，部署非常方便，使用图形化的管理界面，用户操作方便，功能够用，很快得到了普及。

　　企业内的开发人员将应用的镜像通过Dockerpush命令上传到私有镜像仓库中。运维人员在K8S平台上部署应用时，直接到私有仓库中快速下载应用镜像，部署到K8S平台中。私有仓库是建设容器云必不可少的功能。

　　5容器云的集中日志管理系統

　　K8S可以管理上千个节点的集群，如果集群出现问题，需要通过日志进行排查，要想发现故障在哪一个环节，只靠命令行的方式去操作，简直无法想象。构建一套集群的日志收集、存储、查询和图形化展示的集中式日志管理系统对于系统运维非常必要。

　　EFK组合是常用的一种日志管理方案，主要有三个组件构成（ElasticSearch、Fluentd、Kibana）。Fluentd安装到所有的K8S节点上，充当日志代理角色，负责将各节点上的各种日志收集、过滤、发送到后端的ElastieSearch;ElastieSearch负责日志的存储和索引，通过HTTPAPI方式提供全文检索功能;最终在Kibana面板上对采集来的各种日志数据进行查询分析，用图形、表格形式进行集群日志展示。

　　6容器云的监控告警系统

　　Prometheus是开源的监控告警和时序数据库系统，是云原生计算基金会CNCF的产品之一，Prometheus项目非常活跃，社区提供了很好的支持，包括数据库、硬件设备、持续集成工

　　龙源期刊网http://www.qikan.com.cn具、存储软件、Web服务器软件、日志和监控软件等上百种应用都提供了专门的Exporter配合使用，一些应用直接内置Pro-metheus数据格式支持，比如Etcd、Kubernetes、SkyDNS等。

　　Prometheus也是时序数据库，它通过Pull方式到各应用的Exporter上拉去度量数据，存储到自身的时序数据库中，内置PromQL查询语言。Alertmanager组件是独立的告警管理器，可以根据事先设定的告警策略，向邮件系统、企业微信、钉钉、Slaek等即时通信工具发送告警数据，及时提醒管理人员。Grafana组件是一款常用的数据显示面板，可以将Prometheus数据库中的指标数据以图形化的方式直观地展示在面板中。

　　在K8S集群中的各节点上部署node-exporter组件，可以获取各节点上CPU、内存等资源的度量数据;通过部署kube-state-metries组件，可以获取K8S集群中Service、Deployment或者Daemonset等各种资源的数据;K8S已经内置Prometheus接口，Prometheus可以直接从集群获取K8S核心组件的度量数据;而对于很多第三方的容器应用，社区都已推出相应的exporter来支持Prometheus，根据需要将这些Exporter部署到集群中，由Prometheus向这些专用的exporter抓取度量数据。

　　有了监控告警系统，K8S容器云平台的整个运行状态可以用直观的图形化的方式在Grafana面板中集中展示，无论是资源占用、系统性能、告警事件、健康状态等，都能够一目了然。有利于运维人员及时了解集群状态，并在第一时间获取告警信息。

　　7容器云的图形化管理

　　Kubemetes官方提供Dashboard面板，能够查看K8S集群的节点状态、K8ST作负载、部署、服务、容器等各种资源的基本情况，在Web管理界面上完成集群的应用部署、日志查看等各项基本操作，功能比较简单。

　　Kubesphere、Rancher是另两款比较优秀的开源图形化K8S管理T具，除了可以实现对集群机器以及K8S的接管以外，还各自增加了特有的功能，集成了项目管理、多租户管理、应用商店、监控告警、持续集成和部署、服务网格等增强功能，极大降低了用户使用K8S的难度，虽是开源软件，但已达到了企业级应用的水平。

　　8结束语

　　Kubemetes功能非常强大，可以轻松管理和调度上千台计算机协同运作，提供强大的集群处理能力，已经成为容器云管理的事实标准。但由于其概念众多，操作复杂，非常不容易学习掌握和推广应用，完整的K8S平台高效运行所需的各个功能模块较多，本文通过对K8S容器云的硬件基础设施、软件运行环境、Kubernetes核心组件、私有镜像仓库以及事件日志、监控告警、图形化管理等运行容器云平台必备工具进行逐一介绍，像搭积木一样，将各个基本功能模块都搭建好，构建一套比较完整实用的容器云平台，对于容器云推广普及具有指导作用。

　　龙源期刊网http://www.qikan.com.cn

　　参考文献：

　　[1]龚正，吴治辉，崔秀龙，等.Kubernetes权威指南[M].电子工业出版社，2019.[2]浙江大学SEL实验室.Docker容器与容器云[M].人民邮电出版社，2016.[3]郑冰.基于Kubernetes的企业级容器云平台设计[J].数字技术与应用，2019（6）.[4]王骏翔，郭磊.基于Kubernetes和Docker技术的企业级容器云平台解决方案[J].上海船舶运输科学研究所学报，2018（3）.

　　【通联编辑：梁书】

　　收稿日期：2019-10-10

　　作者简介：王伟军，男，江苏阜宁人，工程硕士，南京报业传媒集团技术部工程师，中级职称，研究方向为计算机网络、云计算、容器

　　技术。

篇八：容器网络流量研究教授

　　一种多分类器联合的网络流量分类方法

　　谷跃;唐学文

　　【摘

　　要】由于以往的网络流量分类方法是单一的机器学习分类方法,这种方法的总体准确率(OverallAccuracy)提高困难,而且这个问题长期存在着,鉴于此,提出了一种新的网络流量分类的方法,以机器学习分类方法为基础,联合不同分类方法,运用集成学习的思想,使用加权组合权重的方式来实现网络流量的分类;实验表明,新方法提高了总体准确率,比单一的机器学习分类方法更好.

　　【期刊名称】《重庆工商大学学报（自然科学版）》

　　【年(卷),期】2016(033)004

　　【总页数】5页(P74-78)

　　【关键词】流量分类;支持向量机;贝叶斯增广朴素贝叶斯;BP神经网络;集成学习

　　【作

　　者】谷跃;唐学文

　　【作者单位】重庆大学计算机学院,重庆400030;重庆大学信息与网络管理中心,重庆400030

　　【正文语种】中

　　文

　　【中图分类】TP393

　　近年来，互联网流量急剧增大，为了更好地管理互联网的流量，优化网络质量，了解实时网络流量分布情况，以及预防及阻止网络攻击行为，需要更好的网络流量分类方法[1]。

　　在过去的研究中，基于主机、网络、应用层[2]，以及机器学习的[3-5]方法是流量

　　分类的基本方法。比如，文献[6]分析了有代表性的支持向量机等流量分类方法，文献[7]分析了IP流量分类方法，文献[8]研究了SVM在互联网中的流量分类，文献[9]分析了在概率模型下，朴素贝叶斯(Na?veBayes,NB)方法在流量分类中的应用，文献[10]介绍了不同网络环境中，8种不同方法的分类表现，并且进行了对比。

　　支持向量机方法(SVM)[11-12]是一种机器学习方法，其建立在统计学习理论(StatisticalLearningTheory，SLT)基础之上，该方法在分类问题上，使用非线性变换方法，将样本空间转化为高维特征空间(featurespace)，使得待处理的高维特征空间具有了良好的可分性[13]；又根据文献[14]，在分类问题上，特定条件下转变成二次寻优问题。其中，文献[8]分析了支持向量机在流量分类问题上的优势。即支持向量机方法能够得到全局最优解，能够避免过学习现象。但该方法也有一些缺点，如样本数量很大时收敛速度很慢；核函数及核参数难以选择。

　　贝叶斯增广朴素贝叶斯方法(BAN)解决了在估计后验概率上朴素贝叶斯方法存在的缺点，文献[15]将主元分析法与K-均值聚类算法相结合，构造出了一个改进的朴素贝叶斯网络分类方法，该算法摒弃了非类属性变量相对于类属性变量是相对独立的前提条件。文献[16]将BAN方法用于流量的分类，提高了估计后验概率的准确率，其联合条件概率可表示为

　　式(1)中，Parents(Ai)是Ai的父结点集合。BAN方法各属性之间有着很强的依赖性，分类总体准确率较好，但是当样本数量很小时，它在网络结构学习上很复杂。

　　Rumelhart等人在人工神经网络领域中获得了重大突破，提出了能够解决非线性问题的误差反向传播的多层前馈神经网络，即BP方法[17]，并且推导证明了该方法的正确性，使得BP方法有了坚实的理论依据。根据文献[18]内容，此处的BP神经网络基分类器流量的分类方法，釆用的是三层BP神经网络。三层BP神经网络已经满足了非线性多元分类的流量识别问题，如果再增加隐含层的层数，则会增大调整BP神经网络结构的难度。BP神经网络方法在实际应用中也有不足，其训

　　练学习效率比较低，需要较长的时间才能够收敛；采用梯度下降法寻找全局最优时容易陷入局部极小值，在训练学习过程中会存在“饱和”的现象。

　　根据文献[19-20]可知，集成学习技术具有很强的泛化能力，拥有比单个分类器更好的性能，主要体现在提高预测结果的准确率和稳定性等方面。集成学习方法被广泛地应用于文本分类、生命科学等领域。

　　选择准确率高和差异性大的分类器用于集成学习，能够很好地提高集成后分类器的性能。SVM、BAN和BP神经网络这3种方法的分类准确率都较高，并且它们之间的差异性较大，很好地满足了集成学习的条件。

　　因此，结合SVM，BAN，BP神经网络3种方法的不同优点，通过对3种分类器实行加权平均组合权重的方式，提出一种多分类器联合的集成学习网络流量分类方法。

　　算法描述如下：

　　①由训练集构建SVM，BAN，BP神经网络3种分类器。

　　②计算流强度，获取验证集。

　　流强度计算采用皮尔逊相关系数。设有流向量Fi={Ai1,Ai2,…,Aim}和流向量Fj={Aj1,Aj2,…,Ajm},式(2)表示流Fi与流Fj的强度。

　　式(2)中，m为流属性样本量；r为流的强弱程度；分别表示Fi与Fj的均值。

　　使用式(2)，获取相关性最强的K个网络流构成验证集。

　　③使用验证集，计算各分类器的权重。

　　由第②步得到了验证集，分别计算SVM，BAN，BP神经网络3种方法的权重，计算公式如下：

　　式(3)中，Wi(F)即权重，r即当前网络流与验证集中网络流的流强度；Ri表示第i个分类器验证集上的边界，当前分类器如果对验证集中的网络流分类准确，则Ri为1，否则为-1。

　　④加权平均，得到测试实例属于某种类型的后验概率。

　　经过第③步的计算，高权重的分类方法在加权平均计算后，能够显著的对后验概率起正向作用。

　　⑤选取后验概率最大类型作为判定结果。

　　加权平均后能够获得当前测试实例的所属类型，进而得到最后结果。

　　为了对比及分析，使用文献[9]中的实验数据集，其中总共有377526个网络流，囊括了10种类型。因为，在10种类型中，有3种类型的网络流极少，因此只使用网络流类型最多的7种类型。将实验数据集取名为DS，去除不相关的属性后，重新统计数据集的流信息如表1和表2所示。

　　实验使用的网络流量分析工具主要是Weka-3.5.6和Libsvm2.83。

　　分类模型的分类性能，采用整体总体准确率OA标准来衡量。具体形式如公式(4)所描述：

　　其中，STP表示实际是某种应用，被预测也是某种应用的样本数量；STN表示实际是某种应用，被预测不是某种应用的样本数量；SFP表示实际不是某种应用，被预测是某种应用的样本数量；SFN表示实际不是某种应用，被预测不是某种应用的样本数量。

　　为了比较分析准确率，先将DS数据集分为2个数据子集，DS_1数据集和DS_2数据集；再从数据集DS_1中依次抽出各类应用的0.1%，作为样本训练集；然后，在DS_1数据集构成的训练集上依次运行SVM，BAN，BP神经网络和集成方法，其中，支持向量机参照台湾大学林智仁(LinChih-Jen)教授等开发设计Libsvm的使用说明，BAN采用K2结构学习方法，BP神经网络方法采用3层结构。在实验中，集成方法的k值取训练集中流数量的30%；最后，在数据集DS_2上进行验证。紧接着，把训练集的范围依次增加到DS_1数据集的1%,10%,50%，然后重复这个过程，分别进行10次实验。取均值后，分类的总体准确率如图1所示。在

　　各种流类型上进一步比较分类总体准确率，结果如表3所示。

　　由图1和表3能够看出，随着训练集大小的提高，分类总体准确率也随之提高。其中，对于贝叶斯增广朴素贝叶斯方法来说，随着训练集的提高，分类准确率稳步上升；在样本空间比较小时，支持向量机表现出色；而BP神经网络收敛时间较长。集成学习方法联合SVM，BAN，BP神经网络这3种方法，运用集成学习的思想，使用加权组合权重的方式来实现网络流量的分类，其总体准确率优于单一的机器学习方法。

　　为了对比时间消耗，将DS数据集重新统计后，抽取其中的30%数据作为训练集，其余作为测试集。依次运行4种方法，得到分类方法的训练时间和测试时间如表4所示。

　　可以得出，3种分类器相互独立，可做并行处理，其中，在训练时间上BP神经网络方法与集成方法相同，测试阶段是主要存在的额外开销。

　　BAIJ,XIAJB,WUJX,etal.ASurveyofRealTimeNetworkTrafficClassification[J].ComputerScience,2013，40(9):8-15XIONGG,MENGJ,CAOZG,etal.ResearchProgressandProspectofNetworkTrafficClassification[J].JournalofIntegrationTechnology,2012(1):32-42ZHANGHL,LUG.EvaluationandComparisonofMachineLearningAlgorithmsforClassificationofUnbalancedProtocols[J].JournalofSoftware,2012,23(6):1500-1516LIUQ,LIUZH,HUANGM.ResearchonIPTrafficClassificationBasedonMachineLearning[J].ComputerScience,2010,37(12):35-40XUP,LIUQ,LINS.ResearchonInternetTrafficClassi-ficationBasedonSupportVectorMachine[J].ComputerResearchand

　　Development,2009,46(3):407-414XIASHY,WANGY,ZHANGQ.IncrementalAlgorithmofSupportVectorMachineBasedonKernelSpaceCombinedwithSampleCenter[J].ComputerApplicationsandSoftware,2012(4):121-124XIASHY.SupportVectorMachineAlgorithmandItsStressonForestHealthMonitoringSystem[D].Chongqing:ChongqingUniversityofTechnology,2012LIUYH,WANGY,TANSHQ.K-meansClusteringModelBasedonNaiveBayesianNetworkClassifier[J].JournalofChongqingTechnologyandBusinessUniversity(NaturalScienceEdition),2012,29(8):36-41LIJ,ZHANGSHY.Peer-to-peerRecognitionMethodBasedonBayesianNetwork[J].JournalofAppliedSciences,2009,27(2):125-130CHENB.Multi-classifiersIntegrationAlgorithmResearch[D].Jinan:ShandongNormalUniversity,2009

篇九：容器网络流量研究教授

　　关于IoC模式及轻量级容器的研究

　　王春枝;唐俊武

　　【期刊名称】《湖北工业大学学报》

　　【年(卷),期】2006(021)004

　　【摘

　　要】首先解释了IoC的基本概念,列举出传统的组件依赖性查找方法,归纳出了现在已经出现的几种IoC类型,以及各种轻量级容器对IoC的支持,分析了IoC模式在轻量级容器中的作用,对EJB3.0规范做出了展望.

　　【总页数】4页(P52-54,65)

　　【作

　　者】王春枝;唐俊武

　　【作者单位】湖北工业大学计算机学院,湖北,武汉,430068;湖北工业大学计算机学院,湖北,武汉,430068

　　【正文语种】中

　　文

　　【中图分类】TP393

　　【相关文献】

　　1.基于容器的IoC控制反转模式的研究[J],杨扬;侯红;郝克刚

　　2.轻量级IoC容器的研究与设计[J],娄锋;孙涌

　　3.基于Docker容器的轻量级大数据实验平台构建研究[J],谷瑞军

　　4.轻量级容器化技术驱动的虚拟网络部署研究[J],曹含笑;陈海浩;梁梅群;谢恩慧;韦晓慧

　　5.基于容器的轻量级工业控制系统网络安全测试床研究[J],张仁斌;赵季翔;杨戬;吴克伟

篇十：容器网络流量研究教授

　　电子科技大学计算机学院导师及其科研能力介绍

　　为方便大家报考我们学校,了解各位导师的学术和科研能力,科大考研网

　　www.**

　　将提供给大家详细的信息。

　　陈雷霆,1966年7月出生,男,现任电子科技大学计算机学院副教授、副院长,主管学院的科研、产业和外事工作,在职博士研究生;现为中国软件行业协会理事,四川省计算机学会理事。主要研究方向:(1)信息安全;(2)网络多媒体与虚拟现实。主要科研项目:国家“863-317-403”项目—综合业务多媒体通讯终端与系统;“八五”军事预研项目激光成像雷达系统;多媒体安全监控系统;“九五”军事预研项目激光防撞雷达系统;总装备部项目军用移动图象采集压缩传输系统;航空科技信息集成处理系统;模拟实战射击训练系统;国家“十五”863信息安全项目等。开设研究生课程:多媒体技术及应用、计算机图形学、软件认证;本科生课程:多媒体技术、数字逻辑。

　　--------------------------------------------------------------------------------李毅超,男,1969年6月,硕士,副教授。1997年4月毕业于电子科技大学,获计算机应用硕士学位。现任网络安全基础实验室主任,计算机网络与通信研究室主任,计算机网络与安全技术研究所副所长,兼成都市软件行业协会副秘书长。研究方向为计算机网络与通信、网络信息安全、嵌入式应用。

　　参加或主持"恩威网络MIS系统“、“420驻厂军代室光纤网络MIS系统”、“路由器开发”、信产部基金项目“IP电话网关”,成都华易“美视数字录像监控系统”、西部网信“软交换关守和IP电话多功能终端研发”等近10个科研项目,获得四川省科技三等奖1项,省部级科技成果鉴定5项,国家版权局软件著作权2项。出版《计算机网络》教材1本在国内外重要刊物和国际会议上发表论文十余篇。为本科和硕士生开设了若干课程。获得Microsoft、Novell、SCO、Cisco、Compaq等各大公司认证证书和授权讲师资格。

　　--------------------------------------------------------------------------------

　　蔡洪斌,1988年毕业于华中科技大学,获学士学位,1994年毕业于电子科技大学获硕士学位,2002年获电子科技大学计算机应用技术博士学位。2002年到2003年访问加拿大Concordia大学。参加和主持了多项科研工作,先后获得四川省科技进步三等奖和成都市技术开发二等奖各1项。出版发行著作4部,其中《Java程序设计基础与提高》获四川省优秀图书奖。在国内外重要学术刊物和学术会议上发表论文近20余篇,被EI检索2篇。曾荣获"华威?国腾"奖教金。主要研究领域是网格计算、网络安全、计算机网络技术及其应用和数据库等。

　　--------------------------------------------------------------------------------

　　崔金钟,1966年9月出生,硕士,高级工程师。目前的主要研究方向是:嵌入式计算机系统及其应用,SOC,计算机控制技术。学习工作经历:1985年9月考入电子科技大学计算机系,1989年7月毕业并获得工学学士学位,毕业后留校任教。1993年开始读在职研究生,1996年4月获硕士学位。2000年晋升为高级工程师。2000年出国在加拿大UBS公司工作,主要研究方向是嵌入式与实时系统。2001年11月回校工作,现担任计算中心主任。主要成果:近几年内,编写了两本书,作为主研人员已完成了项目多项。作为项目负责人和第一主研已完成项目2个,其中“压力参数成组校准系统”项目通过四川省电子厅鉴定,并获四川省教委科技进步三等奖。在研项目“电书Ebook的设计”

　　--------------------------------------------------------------------------------

　　黄廷祝,64年10月生,教授、博士生导师、应用数学学院院长、计算科学研究所所长.在西安交大计算数学专业获学士、硕士和博士学位.分别于94、97年破格晋升副教授和教授.学术:在国内外重要学术刊物发表科学计算理论和方法、大型矩阵与计算、神经网络与动力系统稳定性等方面论文约80篇,被SCI、EI收录和SCI引用(他引)37篇次,被同行他引约50篇次.获信息产业部科技进步二等奖(主持,99年)、省科技进步三等奖(主持,2001年)、省教委科技进步三等奖(独立).97年被遴选为省跨世纪杰出青年科技学术带头人.长期聘为国内外约20种重要学术刊物的审稿人.曾应邀在香港浸会大学计算机科学系和中科院应用数学所做合作研究和高级访问学者.为西安交大基础科学研究中心学术委员会成员、曾做客座教授,成都信息工程学院兼职教授.为省科技青年联合会理事、省生物数学学会副主任委员等。

　　教学:校级优秀主讲教师,历届学生评教优秀,为本科生、研究生开设多门课程。“十五”国家级规划教材作者,出版著作教材6部,获省优秀教学成果一等奖,校优秀教学成果一等奖和优秀教材一等奖.省自考先进工作者.获校一档奖教金、校“教学优秀教师奖”.国家级大学数学教学资源库建设专家组成员.--------------------------------------------------------------------------------

　　左志宏,男,1966年出生。1986年毕业于国防科技大学计算机系,获学士学位;1989年毕业于电子科技大学计算机系,获硕士学位;目前是电子科技大学在职博士。

　　1989年1月研究生毕业留校工作至今。1992年提讲师,1997年副教授。1997-1998在香港大学进行“汉英翻译”的合作研究。

　　留校至今,承担过研究生《计算理论》、《数理逻辑与逻辑程序设计》、《语言编译专题》的教学任务,本科生《形式语言与自动机》、《编译原理》、《数据结构》的教学任务。承担过电科院科研项目《计算机病毒的分析与防治》、《分布式实时语言研究》和《网络环境下计算机病毒的分析与防治》等科研项目。在国家一级刊物发表过论文数篇。

　　--------------------------------------------------------------------------------

　　顾小丰,男,生于1966年3月,1991年6月研究生毕业于兰州大学数学系计算数学专业,获理学硕士学位,2000年12月由四川省信息产业厅、人事厅评为高级工程师。

　　目前主要从事并行计算和网络计算等方面的研究,承担了研究生课程的《计算的复杂性》、《随机过程与排队论》的教学工作。在《计算机研究与发展》等刊物发表论文数篇,在电子工业出版社出版了《离散数学及其应用》教材,编印了《计算的复杂性讲义》。作为主要研究人员,参加并出色完成了“八.五”军事预研基金“关于超立方体拓扑结构中的基础理论研究”;“九.五”军事预研项目“并行算法及其在电子系统中的应用”(获2001年度国防科学技术进步奖二等奖)、电科院军事预研基金“基于消息驱动的可伸缩cluster体系结构及其算法研究”等课题的研究,以及“四川省地方税务办公自动化系统”的研制与推广工作。

　　--------------------------------------------------------------------------------

　　郝玉洁

　　,女,1961年12月出生

　　,技术职称:副教授。现任计算机学院软件系支部书记。

　　1979至1983年在电子科技大学计算机工程专业本科学习,获学士学位。1990至1993年在北方交通大学计算机系硕士研究生,获硕士学位,研究方向:计算机安全。曾先后在西南科技大学信控系计算机教研室、成都信息工程学院计算机系基础教研室任教并任教研室主任。

　　曾获得西南工学院1989年“课堂教学演讲比赛优秀奖”;成都信息工程学院1994-1996年度“学院三育人先进个人”光荣称号。成都信息工程学院1999年“课堂教学板书比赛”二等奖。成都信息工程学院2000年聘期二年的“学院优秀中青年教师”。

　　2000年底调入电子科技大学计算机学院软件系任教,近年来,一直致力于计算机安全技术,网

　　络多媒体领域的研究,并在该领域发表多篇论文。出版教材和外文译著三本

　　--------------------------------------------------------------------------------

　　黄迪明,教授,获国务院颁发的“政府特殊津贴”专家,加拿大麦克斯特大学计算机科学系访问学者。长期从事计算机学科的教学和科研工作,主持和参加过多项重大和大型科研项目,曾获国家级科技进步二等奖及国家级优秀教学成果奖共3项,省部级科研和教学奖共5项。编著教材七部(其中两部为全国统编教材),发表论文30余篇。主要研究方向为:网络多媒体技术、网络信息安全技术、图形技术。当前在研的主要项目有:通用教育信息平台、基于智能体的入侵控检测技术、通用教育信息平台等。承担过的研究生课程有:图形软件设计、软件技术基础、面向对象程序设计等。

　　--------------------------------------------------------------------------------

　　陆鑫,男,电子科大计算机学院副教授,硕士生导师。

　　1992年硕士毕业于电子科技大学计算机专业。留校至今一直从事计算机领域的教学和科研工作,现在职攻读计算机应用技术博士学位。主要研究领域是信息系统技术、软件工程、嵌入式系统技术等。

　　先后从事多门计算机专业课程教学,如计算机控制系统、单片机技术、微机系统与接口、计算机组成原理、互联网技术、信息科学技术导论、高级计算机体系结构、软件需求管理等。负责完成多项大型系统的项目开发,如泸天化企业集团大型MIS系统、大型商业自动化管理MIS系统、成都煤气总公司GIS信息系统、包装容器抗压与堆码微机测控系统等。

　　目前,研究方向兴趣为面向对象的软件工程技术、软件需求管理、嵌入式系统技术。在研项目为“高可靠快速实时以太网技术研究”,“家电控制器仿真软件开发平台研制”。2003年本科教学课程为“计算机组成原理”、“信息科学技术导论”,研究生教学课程为“高级计算机体系结构”、“软件需求管理”。

　　--------------------------------------------------------------------------------

　　雷航,副教授,计算机应用专业博士。

　　先后于1985年至1988年和1993年至1997年在电子科技大学攻读硕士和博士学位。现任中国计算机学会抗恶劣环境计算机专委会委员。

　　先后承担了国家七五重点攻关项目:“超级中英文显示终端的研制”、电子科技大学青年科学基金项目:“分布式实时软件可靠性建模”、国防科技预研基金项目:“实时软件的超时故障分析及可靠性评价模型的研究”、国防科工委九五预研项目:“实时并发软件可靠性测试评价系统”、“超微内核嵌入式实时操作系统”(获国防科技成果三等奖)、国防科工委十五预研项目:“嵌入式实时操作系统”等项目的主研工作,起草中华人民共和国国家标准:“虚拟终端基本类协议”和“协议实现一致性说明”。

　　目前的主要研究方向是:软件可靠性测试和评价技术、实时软件性能评价及优化技术、实时系统软硬件协同设计方法学等。先后在以上研究方向发表学术论文20余篇。

　　为硕士研究生开设专业基础课《现代微型计算机结构》,为本科生讲授《计算机组成原理》。

　　--------------------------------------------------------------------------------

　　刘玓,本人于1983年在成都电讯工程学院计算机系计算机应用专业本科毕业,并留校任教;于1991年在电子科技大学计算机系计算机软件专业硕士研究生毕业。

　　曾先后参加国家“六五”、“七五”和“八五”科技攻关项目,并获得机电部科技进步一等奖和

　　四川省科技进步一等奖等多项奖励。发表论文多篇及全国统编教材一本。

　　本人现从事计算机操作系统,特别是UNIX操作系统及其网络应用方面的工作;曾先后多次参加过

　　涉及电信、银行、证券、期货和生产制造等行业的应用系统开发,多次参加和组织实施通用商品软件的

　　开发和应用推广工作,在大型应用软件开发和软件项目管理等方面积累了丰富的经验。

　　在教学方面,开始了“UNIX操作系统基础”、“C语言程序设计”、“基于UNIX操作系统的编程技术”

　　和“开放式操作系统结构”等课程。

　　--------------------------------------------------------------------------------

　　傅彦

　　副院长

　　1962年11月生,计算机科学与工程学院副院长,副教授。于1988年3月毕业于电子科技大学计算机学院,获硕士学位。

　　目前主要从事软件开发环境的研究和人工智能方面的研究,承担了计算机学院本科的《离散数学》课程和全校研究生的《人工智能》课程的全部教学工作。先后主持和参与科研项目几十项,发表文章几十篇,著书4本。

　　近三年的主要工作如下:在科研方面,参加了《软件开发环境的研究》、《神经网络的动力学行为》(国家自然科学基金)、《计算机远程教学系统建设》等项目的研究与开发。近期在《电子科技大学学报》、《电子高等教育理论与实践》、《成都中医药大学学报》、《电子高教研究》等发表了多篇科研与教学文章。近期先后在电子工业出版社和电子科技大学出版社公开出版了《离散数学及其应用》、《离散数学及其应用习题解吸》、《离散数学基础及其应用》教材。在教学工作方面,成绩突出,荣获电子科技大学首届“优秀主讲教师”称号,并获A级证书。如选了电子科技大学第二期“人才工程”稳定性人才,并在中期检查中获得优秀奖。近期参加了计算机专业主干课程建设和教学改革项目的研究,在2000年--2001年先后获得电子科技大学优秀教学成果一等奖,四川省教育厅优秀教学成果一等奖,全国高等教育部优秀教学成果二等奖。

　　--------------------------------------------------------------------------------

　　廖建明,男,1963年2月出生,副教授,电子科技大学计算机学院计算机工程与技术系(计算机网络与安全技术研究所)教师。

　　1982年7月毕业于重庆大学无线电技术专业,1989年和1996年分别到日本广岛大学计算机研究室和日本千叶大学计算机研究室留学访问。自毕业以来长期从事计算机专业的教学和科研工作。先后主持或参加了大庆油田“试油试采数据采集与无线传输系统的研制”、“计算机热分析数据采集与处理系统的研制”、“塔里木油田油气开发综合管理信息系统与辅助规划决策系统”、“通用考试系统的研制”、“无线信息接收与处理PDA的研制”、电子生产发展专用基金项目“教育网及CAI信息开发”等科研项目,并多次获奖。编写出版了《Internet与Web基础教程》、《计算机网络》、《计算机应用基础》等多部教材。在《电子科技大学学报》、《计算机应用研究》、《分析测试仪器通讯》等杂志发表多篇学术论文。

　　目前从事的主要研究方向:嵌入式系统及应用技术;网络信息技术;家庭信息网络技术

　　--------------------------------------------------------------------------------

　　刘乃琦,男,电子科技大学计算机科学与工程学院教授。出生于1950年9月,四川成都人,毕业于成都电讯工程学院计算机工程专业,留校任教,并随研究生班附读,1985年至1987年作为访问学者于加拿大渥太华卡尔顿大学进修、工作。1988年至1994年任电子科技大学计算机科

　　学与工程系副系主任;1994年至2001年任电子科技大学计算机学院副院长、计算机系系主任。

　　现为IEEE/ACM(国际电气电子工程师协会/美国计算机协会)会员,中国电子学会会员和计算机学会计算机辅助设计与图形学专业委员会委员,全国高等学校计算机教育研究会副理事长、全国高职高专计算机专业教材编委会副主任、四川省公安厅信息领导小组顾问,四川计算机应用工程学会理事等多种职务。

　　从事高等学校教学和管理工作近30年,先后担任"计算机操作系统"、"计算机图形学"、"软硬件开发技术"、"图形处理技术"、"计算机安全技术"、"计算机硬件技术与系统集成"等硕士研究生和本科生课程教学。先后参与完成多项计算机应用科研项目,曾获得部省级一、二等奖,机电部青年教师教书育人优秀奖和校级教学优秀、管理优秀和优秀实验等多项奖励。发表论文八十余篇,先后出版《混合语言编程技术》、《C语言问题及习题解答》、《计算机图形技术基础》、《操作系统原理及应用》、《计算机操作系统》、《计算机专业英语》、《互联网络技术》、《实用加解密技术》、《信息安全》等教材书籍十余本。专业方向为计算机信息系统,系统与网络安全技术,图形与多媒体技术等。

　　--------------------------------------------------------------------------------

　　刘心松

　　教授

　　博导

　　1940-12-15男国家科技进步奖发明奖仪器仪表组特邀评审委员,电子部科技进步奖计算机和软件组资格评审委员,中国计算机学会系统结构专委会副主任委员,四川省通信计算机学科高级工程师评审组组长,IEEProceedingsofComputer&DigitalTechniques特邀审稿人,机电部有突出贡献专家,享受国务院特殊津贴,获省部级科技成果一、二、三等奖,国际文化奖,科学大会奖,国家科技优秀表彰奖,正式发表学术论文100余篇。

　　研究领域:

　　宽带网络与通信,分布并行处理,计算机网络及通信,网络软件与操作系统

　　--------------------------------------------------------------------------------

　　卢显良

　　1943年12月生。

　　1967年毕业于成都电讯工程学院。现任电子科技大学计算机学院教授,博士生导师。中国计算机学会高级会员。1981年至1983年在美国伊里诺大学(UniversityofIllinoisatUrbana-Champaign)作访问学者。1983年以来主要在电子科技大学从事计算机教学和科研工作。1990年至1993年受机电部计算机司聘请任总设计师在北京中国计算机软件与服务总公司负责COSA系统软件平台开发。主持和参加过多项国家“六五”、“七五”、“八五”和“九五”重点科技攻关项目。先后获国家科技进步二等奖、三等奖各一项,省部科技进步特等奖、一等奖多项。出版发行著作四本,并在已国内外学术刊物和学术会议发表论文六十余篇。主要研究领域是计算机操作系统,计算机网络及分布式系统。目前承担国防973,国防跨行业预研基金,电子信息发展基金等多项科研任务。

　　--------------------------------------------------------------------------------

　　罗克露,女,1948年7月生,共产党员,电子科技大学计算机学院计算机工程与技术系主任,教授,硕士生导师

　　1982年毕业于成都电讯工程学院计算机系计算机本科专业,获工学学士学位。由国家教委公派,于1985年~1989年先后在意大利罗马大学信息与系统系、罗马SIELTE通信公司计算机开发部研修多微处理机系统内部节点通信技术与CAD技术等。1989年回国至今,在电子科技大学计算机学院任教。

　　为研究生、本科生主讲多门课程。主持开发多项科研项目与教改项目,“计算机专业主干课程建设与教学改革”项目2001年荣获全国教学成果二等奖、四川省教学成果一等奖、电子科技大学教学成果一等奖。发表多篇论文。参编与主编多本教材,其中三本为全国统编教材,《计算机组成原理》(修订本)1998年获得教育部科技进步奖教材类三等奖。

　　主要研究方向为嵌入式实时系统及应用。

　　--------------------------------------------------------------------------------

　　罗蕾,教授,主要从事嵌入式系统软件(操作系统、网络、开发系统等)和应用软件的研究、开发及教学工作。

　　承担并主持了多项嵌入式系统软件研究开发课题,主要有:“机载嵌埋式实时操作系统CRTOS/386R”、“32位嵌埋式实时操作系统CRTOS/386P”、“NTRTES:WindowsNT实时特性实验系统”、“超微内核嵌入式实时操作系统”、“宽带边缘路由器”及863软件重大专项“智能手机嵌入式实时软件平台”等。其中“军用可剪裁实时操作系统(嵌埋型)”,获得1996年电子工业部科技进步二等奖。“超微内核嵌入式实时操作系统”,获得2001年国防科技三等奖。发表论文十余篇。

　　--------------------------------------------------------------------------------

　　罗惠琼

　　教授

　　从1975年至今一直在电子科技大学计算机学院从事教学和科研工作,共计27年教龄,曾经为本科生、研究生和博士生讲授过多种课程,受到学生好评,并多次获得校教学奖,获得国家和四川省的教学成果奖。参加过多项科研项目,并多次获得省市科技进步奖,也发表过多篇论文。四川省有突出贡献专家。特别是近十年来主要从事网络通信方面的研究。

　　--------------------------------------------------------------------------------

　　秦志光,男,1956年2月出生,四川隆昌人。1989年7月在湖南湘潭大学获理学硕士学位,1996年3月在电子科技大学获工学博士学位。1983年10月加入中国共产党。现在电子科技大学计算机科学与工程学院从事科研和研究生教学工作。教授、博士生导师、硕士生导师。现任电子科技大学计算机网络与安全技术研究所所长,电子科技大学IBM技术中心主任,新型计算机应用技术重点实验室主任,电子科技大学电子商务实验室主任。IBM认证专家,Lotus认证教师、认证专家。四川省科技青年联合会理事,国际电子电器工程师学会(IEEE)会员,国家信息安全基地(西部)专家,四川省软件企业认定专家组成员,四川省软件行业协会常务理事,成都市软件行业协会专家。

　　1994年以来,先后在《计算机辅助设计与图形学学报》、《应用科学学报》、《计算机应用》、《微型计算机》等各种重要期刊或学术会议上发表学术论文30多篇、获得四川省和成都市科技进步三等奖各一项、负责研究开发的应用软件有两项通过国家软件评测中心评测和中国实验室国家认可。主持和参加过国家“85”科技攻关项目“工作站基础图形软件”;高校基金项目“开放系统的理论研究”;中国工程物理研究院基金项目“Internet网络安全”;电子科技大学“211工程”建设项目“校长办公室办公自动化系统”;四川省科技攻关项目“网络信息防护技术研究”,“不停车收费软件研究与开发”;国家863计划项目“2002AA”;国家863计划引导项目“2002AA”;国家计算机网络与信息安全管理中心项目“2001-研3-022”和“密罐技术研究”。研究领域是计算机开放系统与网络安全性、信息系统安全、ITS(智能交通)、电子商务。

　　--------------------------------------------------------------------------------

　　桑楠,1987年毕业于四川大学计算机软件专业;毕业后在电子科技大学任教,现主要从事嵌入式/实时操作系统、开发环境及其应用、实时软件工程的研究。

　　在科研方面,参与了10多项国家和省部级项目,其中已完成8项(两项作为项目第一负责人),主要包括:分布式软件调试工具、分布式实时操作系统、RTEMS嵌入式开发环境(嵌入式软件开发环境GNU/RTEMS分析与研究)、嵌入式实时操作系统、信息家电嵌入式软件基本开发平台技术、嵌入式软件新型开发平台体系结构、科技局办公自动化系统、离散数学智能辅

　　助教学系统、编译原理教学辅助系统等。

　　在教学方面,目前主要讲授本科和研究生课程:嵌入式系统应用开发技术、软件工程专题、嵌入式系统设计等。

　　此外,还发表了多篇学术论文,编写了一本教材(嵌入式系统原理及应用开发技术)。

　　--------------------------------------------------------------------------------

　　佘堃,参与和主持各类项目10多项,其中担任课题第一负责人7项,包括国家863项目和国家十五军事预研项目各一项,鉴定项目共6项。在代表学校和学院参与的国家金卡工程项目中,本人作为最重要角色参与了CMM认证的全过程,以优异成绩通过了CMM2级软件企业认证,并培养了一个科研梯队,梯队骨干都是留校博士生。

　　2001.12,学校与国内信息安全领头企业成都卫士通信息产业股份公司合作,成立了电子科大---卫士通信息安全联合实验室,本人担任常务副主任,主持该实验室的日常工作。

　　本人在在国内一级刊物上已第一作者发表文章共4篇,E1收入2篇,核心刊物上以第一作者发表文章10篇,国内会议刊物以第一作者发表5篇。

　　--------------------------------------------------------------------------------

　　孙世新教授,1940年3月生,湖北孝感县人,汉族,中共党员。电子科技大学计算机学院教授,计算机应用技术博士生导师,国务院政府特殊津贴专家,第十届成都市政协委员,全国并行计算专业委员会委员。1966年毕业于四川大学数学系,1984年至1987年在法国格勒诺贝尔第一大学计算机与应用数学研究所作访问学者兼客座研究员,1990年又分别赴意大利罗马大学和法国格勒诺贝年尔第一大学讲学与工作半年,1997年2月赴香港科技大学计算机系访问与工作,1999年9月赴法国格勒诺贝尔第一大学和贡比涅大学作访问研究,2000年11月赴香港和马来西亚作学术访问,2001年6月到7月赴美国、加拿大作学术访问。

　　主要从事计算机科学理论的研究与教学工作,主要研究方向为网络计算技术、并行/分布式计算及其应用、信息压缩技术、数值计算与组合算法等。主持参与“九五”军事预研项目、国家高性能计算基金、863计划等多项课题研究。自88年至今,在国内外著名期刊杂志发表论文60余篇,其中近20余篇被国际著名的三大检索系统SCI、EI、ISTP以及美国的著名检索杂M.R.和西德的“数学文摘”等收录评论,出版《组合数学》教材一部。获省科技进步三等奖(唯一作者),国防科技二等奖(第一主研),校优秀教材奖,优秀论文奖和摩托罗拉教师奖教金和托普基础课教师奖多项。在1995年带头为电子科技大学成功申请计算机科学理论硕士点一个,参与申请计算机体系结构博士点一个。

　　--------------------------------------------------------------------------------

　　谭浩,男,1970年7月生,博士,副教授。1999年毕业于电子科技大学,获计算机应用博士学位。毕业后留校从事科研、教学工作,并担任了开放系统与中间件技术研究室主任。自参加工作以来,在科研、教学等多项工作中取得出色成绩。在科研方面,作为项目负责人,主持开发了“计算机会议系统的设计与实现”研究项目。该项目通过四川省信息产业厅鉴定,并在贵州省军区和成都军区成功应用。作为主研,参与了多个“九五”国防科技预研项目并做出了突出贡献。其中一个项目通过了信息产业部的鉴定,并获得国防科技三等奖。此外,在国内外重要刊物上发表论文十数篇,其中多篇被EI、ISTP检索,具有重要的学术价值和实用价值。在教学方面,先后为博士和硕士生开设了若干课程。

　　--------------------------------------------------------------------------------

　　唐雪飞,男,1964年生,博士,副教授。1996年4月毕业于电子科技大学计算机学院,获博士学位。

　　译著两部,近70万字;发表学术论文30余篇;通过省部级鉴定项目10余项。目前主讲的课程是《软件工程》,主要研究领域:开放分布式计算,数据融合和网络多媒体应用。

　　--------------------------------------------------------------------------------

　　汪文勇

　　北京航空航天大学计算机系,计算机专业本科,工学学士。电子科技大学微型计算机研究所,计算机专业硕士,工学硕士。

　　工作经历

　　1991-1994电子科技大学,微型计算机研究所一室,先后任助教、讲师。

　　1994借调国家教育委员会科技司,作为国家教育委员会信息化领导小组技术秘书,参与中国教育和科研计算机网(CERNET)示范工程的立项组织和项目论证工作,直到同年十二月该项目被国家计划委员会批准。

　　1995-1997电子科技大学,信息网络管理办公室副主任。获副教授职称。

　　1997借调国家教委,技术组负责人,参加国家教委科技工作会议,负责实施和维护会议的信息系统,包括会议管理系统、互联网接入和大屏幕演示。

　　1999借调电子工业部,参与国家信息网络总体规划。

　　1997-2001电子科技大学,网络中心副主任。

　　2001-电子科技大学计算机学院教师

　　主要成果

　　出版专著7本,获电子部优秀教材一等奖一次;发表论文10余篇;获部省级奖5次。

　　--------------------------------------------------------------------------------

　　朱清新博士、教授、博导,美国数学学会(AMS)会员,中国计算机学会高级会员,1982年1月四川师范大学数学系本科毕业获学士学位,1984年7月北京理工大学应用数学专业获硕士学位,1984年8月起任兵器工业第209研究所工程师、副研究员,从事数字图象处理与视频信号编码、高精度稳定平台计算机控制系统等研究工作,作为技术骨干参加了国防科工委7712工程并获三等奖,1993年5月毕业于渥太华大学应用数学和电子工程系控制论专业获博士学位,1993年5月至1996年3月在渥太华大学电子工程系和加拿大卡尔顿大学计算机学院从事博士后研究并攻读计算机硕士二学位,方

　　向为网络流量工程与拥塞控制,最优控制与最优搜索策略与仿真,1996年3月至1997年11月任加拿大北方电讯公司和OmniMark高级研究员,1998年3月应聘回国到电子科技大学计算机学院工作,1999年聘为教授、2001年聘为博士生导师,2002年9月至2003年3月赴加拿大蒙特利尔Concordia大学计算机系访问研究,方向为计算机视觉和模式识别。现任计算机学院学术委员会主任,网络多媒体技术与虚拟现实研究室主任,计算机网络与安全技术研究所所长。主要研究领域为:计算机图形与机器视觉、信息安全、网络通信、最优控制与最优搜索。

篇十一：容器网络流量研究教授

　容器云平台网络架构设计及优化

　　目录

　　1.

　　容器平台网络模型....................................................................................................................................................................................1

　　1.1

　　容器网络概述..............................................................................................................................................................................1

　　1.2

　　容器网络分类介绍......................................................................................................................................................................2

　　1.2.1

　　协议栈......................................................................................................................................................................2

　　1.2.2

　　穿越方式..................................................................................................................................................................2

　　1.2.3

　　隔离方法..................................................................................................................................................................3

　　1.3总结.............................................................................................................................................................................................4

　　2.

　　基于Docker网络基础和实现原理........................................................................................................................................................4

　　3.

　　Kubernetes网络场景分析....................................................................................................................................................................6

　　3.1

　　容器到容器的通信......................................................................................................................................................................6

　　3.2

　　Pod之间的通信.........................................................................................................................................................................7

　　3.3

　　Pod到Service之间的通信....................................................................................................................................................9

　　3.4

　　外部到内部的访问....................................................................................................................................................................11

　　3.5总结...........................................................................................................................................................................................12

　　4.

　　Kubernetes网络组件介绍.................................................................................................................................................................13

　　4.1

　　Kubernetes网络框架CNI.......................................................................................................................................................13

　　4.2

　　CNI支持的开源组件................................................................................................................................................................13

　　4.2.1

　　Flannel.....................................................................................................................................................................................134.2.2OVS......................................................................................................................................................................15

　　4.2.3

　　Calico....................................................................................................................................................................15

　　4.2.4

　　Contiv...................................................................................................................................................................17

　　4.3

　　总结对比..................................................................................................................................................................................17

　　容器平台的网络架构实践.......................................................................................................................................................................18

　　5.1

　　某金融企业使用OpenShift（基于Kubernetes的商业版本）实现其业务上云

　　.................................................................18

　　5.1.1

　　整体网络架构图.....................................................................................................................................................19

　　5.1.2

　　传统应用访问策略................................................................................................................................................195.1.3

　　数据库访问方案及防火墙策略..............................................................................................................................205.2

　　某金融企业两第三中心容器云网络架构.................................................................................................................................21

　　优化实践........................................................................................................................................................................................22

　　Ⅱ

　　1.1

　　容器网络概述

　　1容器平台网络模型

　　与传统的虚拟化相比，容器其生命周期更短、数量密度更高、集群变更速度更快。基于这些特性，容器平台网络就必须对集群节点之间的高速通信进行充分的考量。除此之外，在企业级的容器云平台上，承载众多租户的计算负载之间资源的安全隔离，也必须要考虑到的因素。

　　显而易见，传统的物理网络架构无法满足容器平台高灵活性的需求，容器平台网络构建必须要有一种崭新的设计架构来满足，这便推动了容器平台网络设计的发展。

　　容器网络发展到目前，已经形成了Docker主导的CNM模型和Google、CoreOS、Kubernetes主导的CNI模型两种模型共存的情况。CNM和CNI并不是网络实现，他们是网络规范和网络体系。从研发的角度来

　　看就是一些接口，主要是和网络管理相关的问题。容器平台的网络方案，通常可以从协议栈、穿越方式、隔离方法三个维度去设计方案：

　　图1网络架构示意图

　　协议栈：

　　◎二层（桥接、ARP+MAC）

　　◎三层（路由转发）

　　◎二层+三层（节点内部二层转发、跨节点三层转发）

　　穿越方式：

　　◎Overlay（隧道穿越底层基础设施）

　　◎Underlay（直接穿越底层基础设施）

　　隔离方法：

　　◎VLAN

　　◎VXLAN

　　1.2

　　容器网络分类介绍

　　1.2.1

　　协议栈

　　二层解决方案，常见于传统机房或者虚拟化场景中，针对ARP和MAC（桥接模式）学习，广播风暴是这个方案最核心要解决的问题。众所周知，二层广播，对整个集群中节点的数量也会有严格的限制。三层解决方案一般是基于BGP协议实现路由转发，通过自主学习完善整个数据中心的路由状态。这个方案的优势是IP穿透性，可以实现IP网络透传。因为基于IP，所以其优势在于规模性，具有非常优秀的扩展性。但在实际使用过程中，受限于各个企业自身网络安全的考量，例如生产网和开发测试网隔离，或者网络本身不支持BGP，那么这个方案就受限了。二层+三层的方案，集成了前面两种方案的优势（既解决了二层规模性扩展的问题，又解决三层网络隔离受限的问题），正成为容器云网络场景下首选的协议栈层级的解决方案。

　　1.2.2

　　穿越方式Underlay网络

　　提到Underlay网络，就必须从以太网说起，以太网从最开始设计出来就是一个分布式网络，没有中心的控制节点，网路中的各个设备之间通过协议传递的方式学习网络的可达信息，由每台设备自己决定要如何转发，这直接导致了没有整体观念，不能从整个网络的角度对流量进行调控。由于要完成所有网络设备之间的互通，就必须使用通用的语言，这就是网络协议，RFC就是网络协议的法律，相当于国际法，各个设备供应商遵从国际法行事，就基本保证了整个网络世界的正常运行。Underlay就是当前数据中心网路基础转发

　　架构的网络，只要数据中心网络上任意两点路由可达即可，指的是物理基础层。我们可以通过物理网络设备本身的技术改良、扩大设备数量、带宽规模等完善Underlay网络，其包含了一切现有的传统网络技术。

　　Overlay网络

　　Overlay技术可以分为网络Overlay，主机Overlay和混合式Overlay三大类。网络Overlay是指通过控制协议

　　对边缘的网络设备进行网络构建和扩展，也就是本文所讲的Overlay网络技术。Overlay网络技术多种多样，一般采用TRILL、VXLAN、GRE、NVGRE等隧道技术。TRILL（TransparentInterconnectionofLots

　　ofLinks）

　　技术是电信设备厂商主推的新型环网技术；NVGRE（NetworkVirtualizationusingGenericRoutingEncapsu-lation）STT（StatelessTransportTunnelingProtocol）是IT厂商主推的Overlay技术；以及大家非常熟悉的

　　VXLAN（Virtual

　　Extensible

　　LAN）等基于隧道的封装技术。由于这些也都是新增的协议，均需要升级现有网络设备才能支持。Overlay网络中应用部署的位置将不受限制，网络设备可即插即用、自动配置下发，自

　　动运行，Overlay网络业务变化，基础网络不感知，并对传统网络改造极少，最为重要的是虚拟机和物理服

　　务器都可以接入Overlay网络中。

　　1.2.3

　　根据基础设施划分

　　VLAN(VirtualLocalAreaNetwork)意为虚拟局域网，是在交换机实现过程中涉及到的概念，由802.1Q标准所定义。由于交换机是工作在链路层的网络设备，连接在同一台交换机的终端处于同一个三层网中，同时也处于同一个广播域。当交换机接入较多的终端时，任意一台终端发送广播报文时（例如：ARP请求），报文都会传遍整个网络。对于规模较大的组网场景，广播报文的泛滥对于网络通信将会造成较大的影响。VLAN技术为这一问题提供了解决方案，VLAN将同一网络划分为多个逻辑上的虚拟子网，并规定当收到广播报文时，仅仅在其所在VLAN中进行广播从而防止广播报文泛滥。VLAN技术在链路层的层次中实现了广播域的隔离。

　　随着大数据、云计算技术的兴起以及虚拟化技术的普及，VLAN技术的弊端逐渐显现出来，具体表现为

　　如下3个方面：

　　(1)

　　虚拟化技术的发展促使大数据、云计算技术公司采用单个物理设备虚拟多台虚拟机的方式来进行组网，随着应用模块的增加，对于支持VLAN数目的要求也在提升，802.1Q标准中的最多支持4094个VLAN的能力已经无法满足当下需求。

　　(2)

　　公有云提供商的业务要求将实体网络租借给多个不同的用户，这些用户对于网络的要求有所不同，而不同用户租借的网络有很大的可能会出现IP地址、MAC地址的重叠，传统的VLAN仅仅解决了同一链路层网络广播域隔离的问题，而并没有涉及到网络地址重叠的问题，因此需要一种新的技术来保证在多个租户网络中存在地址重叠的情况下依旧能有效通信的技术。

　　(3)

　　虚拟化技术的出现增加了交换机的负担，对于大型的数据中心而言，单台交换机必须支持数十台以上主机的通信连接才足以满足应用需求，而虚拟化技术使得单台主机可以虚拟化出多台虚拟机同时运行，而每台虚拟机都会有其唯一的MAC地址。这样，为了保证集群中所有虚机可以正常通信，交换机必须保存每台虚机的MAC地址，这样就导致了交换机中的MAC表异常庞大，从而影响交换机的转发性能。

　　基于以上需求，VXLAN技术被提出。

　　VXLAN技术是网络Overlay技术的一种实现，对于Overlay技术，笔者的理解是：在基于物理网络拓扑的

　　基础上通过一定的技术来构建虚拟的、不同于物理网络拓扑的逻辑网络，而物理网络的拓扑结构对于Over-

　　lay终端而言是透明的，终端不会感知到物理网络的存在，而仅仅能感知到逻辑网络结构。对于终端的视角，网络的情况和直接通过物理设备实现逻辑拓扑的效果是相同的。VXLAN技术可以基于三层网络结构来构建二层虚拟网络，通过VLAN技术可以将处于不同网段网络设备整合在同一个逻辑链路层网络中，对于终端用户而言，这些网络设备似乎“真实地”部署在了同一个链路层网络中。

　　相比VLAN技术，VXLAN技术具有以下的优势：

　　(1)

　　24位长度的VNI字段值可以支持更多数量的虚拟网络，解决了VLAN数目上限为4094的局限性的问题。

　　(2)

　　VXLAN技术通过隧道技术在物理的三层网络中虚拟二层网络，处于VXLAN网络的终端无法察觉到VXLAN的通信过程，这样也就使得逻辑网络拓扑和物理网络拓扑实现了一定程度的解耦，网络拓扑的配置对于物理设备的配置的依赖程度有所降低，配置更灵活更方便。

　　(3)

　　VLAN技术仅仅解决了二层网络广播域分割的问题，而VXLAN技术还具有多租户支持的特性，通过VXLAN分割，各个租户可以独立组网、通信，地址分配方面和多个租户之间地址冲突的问题也得到了解决。

　　1.3

　　总结

　　通过本章的学习，可以初步了解容器网络相关的基础概念，主要涉及到了容器网络的协议栈、穿越方式以及隔离方式。针对协议栈，到底是采用二层互通，还是采用三层互通，还是结合两种方式的优点整合一个综合的方式取决于业务场景；针对穿越方式，是采用传统的Underlay网络，还是基于SDN的Overlay网络，和客户现场情况，以及硬件设备支持的情况都有比较大的关联；同样，隔离方式采用VLAN还是VXLAN，也和场景强相关。由此可见，容器云网络的设计，需要因地制宜，因材施教，从客户需求以及现场情况发出，才能制定出一个完善的解决方案。

　　2基于Docker网络基础和实现原理

　　Docker网络方案基于OpenStack平台网络解决方案，在不断的摸索中，形成了自己的一套网络模型。Docker网络在整个Docker技术栈中的位置如图：

　　图2Docker生态技术栈

　　在容器网络项目探索中，随着容器的发展，容器网络的发展也出现了分歧。主要分为两派，一个是Docker原生的CNM（ContainerNetworkModel），另一个是兼容性更好的CNI（ContainerNetworkInter-face）。CNI就是后来为Kubernetes等容器平台广泛推崇使用的接口技术，后面的章节会详细讲述。这里，我们简要介绍CNM。

　　原先Docker的网络相关的代码是直接在Docker中的，网络功能也比较简单，对网络的诟病也是比较多。随着Docker越来越向平台化发展，将功能组件逐渐从Docker中解耦，Docker从1.7把网络相关的代码从Docker的代码中剥离出来新建了一个Libnetwork项目，引入了CNM的网络模型。

　　图3CNM（ContainerNetworkModel）

　　CNM模型下的Docker网络模型如上所示。它由Sandbox,Endpoint,Network三种组件组成。注意，该模型只是规定了三种组件各自的作用，他们都有各自的具体实现方式。Sandbox:Sandbox包含了一个

　　Con-tainer的网络相关的配置，如网卡Interface，路由表等。Sandbox在Linux上的典型实现是

　　Networknamespace。在Linux系统上的Docker环境中，Container，Networknamespace，Sandbox这三者是绑定在一起的。一个Sandbox可以包含多个Endpoint，这些Endpoint可以来自多个

　　Network。

　　Endpoint:Sandbox加入

　　Network的方式是通过

　　Endpoint完成的。Endpoint的典型实现方式是

　　Vethpair，每个

　　Endpoint都是由某个

　　Network创建。创建后，它就归属于该Network。同时，Endpoint还可以加入一个Sandbox。加入后，相当于该Sandbox也加入了此Network。

　　Network:Network的一种典型实现是Linuxbridge。一个Network可以创建多个Endpoint。将这些Endpoint加入到Sandbox，即实现了多个Sandbox的互通。

　　总结起来：如果要想两个Container之间可以直接通信，那么最简单的办法就是由一个Network创建两个Endpoint，分别加入这两个Container对应的Sandbox。

　　注意:不同Network之间默认的隔离性是docker通过设置Iptables完成的，通过改变Iptables的设置，可以使得两个Network互通。

　　标准的

　　Docker网络支持以下

　　4类网络模式：

　　host模式：使用--net=host指定

　　container模式：使用--net=container:Name_or_ID指定none模式：使用--net=none指定

　　bridge模式：使用--net=bridge指定，设为默认值

　　桥接模式是最常见的Docker容器网络类型。在桥接模式下，Docker会为每个容器分配IP地址及创建虚拟以太网网卡对（Veth）。所有的容器都被连接到Docker在主机绑定的桥接设备上。被连接到同一个桥接设备的所有容器，都可以实现互联互通。如果容器要对外界提供服务，则用户需要将容器内的服务端口与宿主机的某一段口绑定。这样所有访问苏主机目标端口的请求都将通过Docker代理转发到容器的服务端，最终到达应用。

　　除了桥接模式，Docker也支持主机（host）模式，让容器直接使用宿主机的网络设备。宿主机模式使得容器占用宿主机的端口资源，而且要求容器具有更高的权限，因此只有特殊需求的容器，才会使用这种模式，如OpenShift集群中的Router组件。Router主机需要监听计算节点上的端口，以接受外部的请求，因此Router组件的Pod的容器网络为主机模式。

　　本章节主要介绍了Docker网络的情况，从Docker整个生态栈入手，分析了基于单机和集群两种不同场景的Docker网络，着重分析了在单机模式下Docker网络的情况（host/bridge/none/container）。

　　Kubernetes网络场景分析

　　在实际的业务场景中，业务组件之间的关系十分复杂，特别是微服务概念的提出，应用部署的粒度更加细小和灵活。为了支持业务应用组件的通信联系，Kubernetes网络的设计主要致力于解决以下场景：

　　（1）紧密耦合的容器到容器之间的直接通信；

　　（2）抽象的Pod到Pod之间的通信；

　　（3）Pod到Service之间的通信；

　　（4）集群外部与内部组件之间的通信；

　　3.1

　　容器到容器的通信

　　在同一个Pod内的容器（Pod内的容器是不会跨宿主机的）共享同一个网络命名空间，共享同一个Linux协议栈。所以对于网络的各类操作，就和它们在同一台机器上一样，它们甚至可以用localhost地址访问彼此的端口。这么做的结果是简单、安全和高效，也能减少将已经存在的程序从物理机或者虚拟机移植到容器

　　的难度。

　　如图4中的阴影部分就是Node上运行着的一个Pod实例。容器1和容器2共享了一个网络的命名空间，共享一个命名空间的结果就是它们好像在一台机器上运行似的，它们打开的端口不会有冲突，可以直接用Linux的本地IPC进行通信。它们之间互相访问只需要使用localhost就可以。

　　图4容器到容器间通信

　　3.2

　　Pod之间的通信

　　每一个Pod都有一个真实的全局IP地址，同一个Node内的不同Pod之间可以直接采用对房Pod的IP地址通信，而不需要使用其他发现机制，例如DNS、Consul或者etcd。Pod既有可能在同一个Node上运行，也有可能在不用的Node上运行，所以通信也分为两类：同一个Node内的Pod之间的通信和不同Node上的Pod之间的通信。

　　1）同一个Node内的Pod之间的通信

　　如图，可以看出，Pod1和Pod2都是通过Veth连接在同一个Docker0网桥上的，它们的IP地址IP1、IP2都是从Docker0的网段上自动获取的，它们和网桥本身的IP3是同一个网段的。另外，在Pod1、Pod2的Linux协议栈上，默认路由都是Docker0的地址，也就是说所有非本地的网络数据，都会被默认发送到Docker0网桥上，由Docker0网桥直接中转，它们之间是可以直接通信的。

　　图5同一个Node内的Pod关系

　　2）不同Node上的Pod之间的通信

　　Pod的地址是与Docker0在同一个网段内的，我们知道Docker0网段与宿主机网卡是两个完全不同的IP网段，并且不同Node之间的通信只能通过宿主机的物理网卡进行，因此要想实现位于不同Node上的Pod容器之间的通信，就必须想办法通过主机的这个IP地址来进行寻址和通信。另外一方面，这些动态分配且藏在Docker0之后的所谓“私有”IP地址也是可以找到的。Kubernetes会记录所有正在运行Pod的IP分配信息，并

　　将这些信息保存在etcd中（作为Service的Endpoint）。这些私有IP信息对于Pod到Pod的通信也是十分重要的，因为我们的网络模型要求Pod到Pod使用私有IP进行通信。之前提到，Kubernetes的网络对Pod的地址是平面的和直达的，所以这些Pod的IP规划也很重要，不能有冲突。

　　综上所述，想要支持不同Node上的Pod之间的通信，就要达到两个条件：

　　（1）在整个Kubernetes集群中对Pod分配进行规划，不能有冲突；

　　（2）找到一种办法，将Pod的IP和所在Node的IP关联起来，通过这个关联让Pod可以互相访问。

　　根据条件1的要求，我们需要在部署Kubernetes的时候，对Docker0的IP地址进行规划，保证每一个

　　Node上的Docker0地址没有冲突。我们可以在规划后手工分配到每个Node上，或者做一个分配规则，由安

　　装的程序自己去分配占用。例如Kubernetes的网络增强开源软件Flannel就能够管理资源池的分配。

　　根据条件2的要求，Pod中的数据在发出时，需要有一个机制能够知道对方Pod的IP地址挂在哪个具体的Node上。也就是说要先找到Node对应宿主机的IP地址，将数据发送到这个宿主机的网卡上，然后在宿主

　　机上将相应的数据转到具体的Docker0上。一旦数据到达宿主机Node，则哪个Node内部的Docker0便知道如何将数据发送到Pod。

　　具体情况，如下图所示。

　　图6跨Node的Pod通信

　　在图6中，IP1对应的是Pod1，IP2对应的是Pod2。Pod1在访问Pod2时，首先要将数据从源Node的

　　eth0发送出去，找到并到达Node2的eth0。也就是说先要从IP3到IP4，之后才是IP4到IP2的送达。

　　3.3

　　Pod到Service之间的通信

　　为了支持集群的水平扩展、高可用，Kubernetes抽象出Service的概念。Service是对一组Pod的抽象，它会根据访问策略（LB）来访问这组Pod。

　　Kubernetes在创建服务时会为服务分配一个虚拟的IP地址，客户端通过访问这个虚拟的IP地址来访问服务，而服务则负责将请求转发到后端的Pod上。这个类似于反向代理，但是，和普通的反向代理有一些不同

　　：首先它的IP地址是虚拟的，想从外面访问需要一些技巧；其次是它的部署和启停是Kubernetes统一自动管理的。

　　Service在很多情况下只是一个概念，而真正将Service的作用落实的是背后的kube-proxy服务进程。在Kubernetes集群的每个Node上都会运行一个kube-proxy服务进程，这个进程可以看作Service的透明代理兼负载均衡器，其核心功能是将到某个Service的访问请求转发到后端的多个Pod实例上。对每一个TCP类型的KubernetesService，kube-proxy都会在本地Node上建立一个SocketServer来负责接收请求，然后均匀发送到后端某个Pod的端口上，这个过程默认采用RoundRobin负载均衡算法。Kube-proxy和后端Pod的通信方式与标准的Pod到Pod的通信方式完全相同。另外，Kubernetes也提供通过修改Service的service.spec.-sessionA?nity参数的值来实现会话保持特性的定向转发，如果设置的值为“ClientIP”，则将来自同一个ClientIP的请求都转发到同一个后端Pod上。此外，Service的ClusterIP与NodePort等概念是kube-proxy通过Iptables和NAT转换实现的，kube-proxy在运行过程中动态创建与Service相关的Iptables规则，这些规则实

　　现了ClusterIP及NodePort的请求流量重定向到kube-proxy进程上对应服务的代理端口的功能。由于Iptables机制针对的是本地的kube-proxy端口，所以如果Pod需要访问Service，则它所在的那个Node上必须运行kube-proxy，并且在每个Kubernetes的Node上都会运行kube-proxy组件。在Kubernetes集群内部，对ServiceClusterIP和Port的访问可以在任意Node上进行，这个因为每个Node上的kube-proxy针对该Service都设置了相同的转发规则。

　　综上所述，由于kube-proxy的作用，在Service的调用过程中客户端无需关心后端有几个Pod，中间过程的通信、负载均衡及故障恢复都是透明的，如下图所示。

　　图7Service的负载均衡转发

　　访问Service的请求，不论是用ClusterIP+TargetPort的方式，还是用节点机IP+NodePort的方式，都会被节点机的Iptables规则重定向到kube-proxy监听Service服务代理端口。Kube-proxy接收到Service的访问请求后，会如何选择后端Pod？

　　首先，目前kube-proxy的负载均衡只支持RoundRobin算法。该算法按照成员列表逐个选取成员，如果一轮循环完，便从头开始下一轮，如此循环往复。Kube-proxy的负载均衡器在RoundRobin算法的基础上还支持Session保持。如果Service在定义中指定了Session保持，则kube-proxy接收请求时会从本地内存中

　　查找是否存在来自该请求IP的a?nityState对象，如果存在该对象，且Session没有超时，则kube-proxy将请求转向该a?nityState所指向的后端Pod。如果本地存在没有来自该请求IP的a?nityState对象，记录请求的

　　IP和指向的Endpoint。后面的请求就会粘连到这个创建好的a?nityState对象上，这就实现了客户端IP会话

　　保持的功能。

　　接下来我们深入分析kube-proxy的实现细节。kube-proxy进程为每个Service都建立了一个“服务代理对象”，服务代理对象是kube-proxy程序内部的一种数据结构，它包括一个用于监听此服务请求的Socket-Server，SocketServer的端口是随机选择的一个本地空闲端口。此外，kube-proxy内部也建立了一个“负载均衡器组件”，用来实现SocketServer上收到的连接到后端多个Pod连接之间的负载均衡和会话保持能力。

　　kube-proxy通过查询和监听APIServer中Service与Endpoint的变化来实现其主要功能，包括为新创建的Service打开一个本地代理对象（代理对象是kube-proxy程序内部的一种数据结构，一个Service端口是一个代理对象，包括一个用于监听的服务请求的SocketServer），接收请求，针对发生变化的Service列表，kube-proxy会逐个处理。下面是具体的处理流程：

　　（1）如果该Service没有设置集群IP（ClusterIP），则不做任何处理，否则，获取该Service的所有端口定义列表（spec.ports域）

　　（2）逐个读取服务端口定义列表中的端口信息，根据端口名称、Service名称和Namespace判断本地是否已经存在对应的服务代理对象，如果不存在就新建，如果存在且Service端口被修改过，则先删除Iptables中和该Service相关的的规则，关闭服务代理对象，然后走新建流程，即为该Service端口分配服务代理对象并为该Service创建相关的Iptables规则。

　　（3）更新负载均衡器组件中对应Service的转发地址表，对于新建的Service，确定转发时的会话保持策略。

　　（4）对于已经删除的Service则进行清理。

　　11

　　图8Kube-proxy与APIServer的交互过程

　　3.4

　　外部到内部的访问

　　Pod作为基本的资源对象，除了会被集群内部的Pod访问，也会被外部使用。服务是对一组功能相同Pod的抽象，以它为单位对外提供服务是最合适的粒度。

　　由于Service对象在ClusterIPRange池中分配到的IP只能在内部访问，所以其他Pod都可以无障碍地访问到它。但如果这个Service作为前端服务，准备为集群外的客户端提供服务，就需要外部能够看到它。Kubernetes支持两种对外服务的Service的Type定义：NodePort和LoadBalancer。

　　（1）NodePort

　　在定义Service时指定spec.type=NodePort，并指定spec.ports.nodePort的值，系统就会在Kubernetes集群中的每个Node上打开一个主机上的真实端口号。这样，能够访问Node的客户端就能通过这个端口号访

　　问到内部的Service了。

　　（2）LoadBalancer

　　如果云服务商支持外接负载均衡器，则可以通过spec.type=LoadBalancer定义Service，同时需要指定负载均衡器的IP地址。使用这种类型需要指定Service的NodePort和ClusterIP。

　　对于这个Service的访问请求将会通过LoadBalancer转发到后端Pod上去，负载分发的实现方式依赖于云服务商提供的LoadBalancer的实现机制。

　　（3）外部访问内部Service原理

　　12

　　我们从集群外部访问集群内部，最终都是落在具体的Pod上。通过NodePort的方式就是将kube-proxy开放出去，利用Iptables为服务的NodePort设置规则，将对Service的访问转到kube-proxy上，这样

　　kube-proxy就可以使用和内部Pod访问服务一样的方式来访问后端的一组Pod了。这种模式就是利用

　　kube-proxy作为负载均衡器，处理外部到服务进一步到Pod的访问。而更常用的是外部均衡器模式。通常的实现是使用一个外部的负载均衡器，这些均衡器面向集群内的所有节点。当网络流量发送到LoadBalancer地址时，它会识别出这是某个服务的一部分，然后路由到合适的后端Pod。

　　所以从外面访问内部的Pod资源，就有了很多种不同的组合。

　　◎

　　外面没有负载均衡器，直接访问内部的Pod

　　◎

　　外面没有负载均衡器，直接通过访问内部的负载均衡器来访问Pod

　　◎

　　外面有负载均衡器，通过外部负载均衡器直接访问内部的Pod

　　◎

　　外面有负载均衡器，通过访问内部的负载均衡器来访问内部的Pod

　　第一种情况的场景十分少见，只是在特殊的时候才需要。我们在实际的生产项目中需要逐一访问启动的Pod，给它们发送一个刷新指令。只有这种情况下才使用这种方式。这需要开发额外的程序，读取Service下的Endpoint列表，逐一和这些Pod进行通信。通常要避免这种通信方式，例如可以采取每个Pod从集中的数据源拉命令的方式，而不是采取推命令给它的方式来避免。因为具体到每个Pod的启停本来就是动态的，如果依赖了具体的Pod们就相当于绕开了Kubernetes的Service机制，虽然能够实现，但是不理想。

　　第二种情况就是NodePort的方式，外部的应用直接访问Service的NodePort，并通过Kube-proxy这个负载均衡器访问内部的Pod。

　　第三种情况是LoadBalancer模式，因为外部的LoadBalancer是具备Kubernetes知识的负载均衡器，它会去监听Service的创建，从而知晓后端的Pod启停变化，所以它有能力和后端的Pod进行通信。但是这里有个问题需要注意，那就是这个负载均衡器需要有办法直接和Pod进行通信。也就是说要求这个外部的负载均衡器使用和Pod到Pod一样的通信机制。

　　第四种情况也很少使用，因为需要经历两级的负载均衡设备，而且网络的调用被两次随机负载均衡后，更难跟踪了。在实际生产环境中出了问题排错时，很难跟踪网络数据的流动过程。

　　（4）外部硬件负载均衡器模式

　　在很多实际的生产环境中，由于是在私有云环境中部署Kubernetes集群，所以传统的负载均衡器都对Service无感知。实际上我们只需要解决两个问题，就可以将它变成Service可感知的负载均衡器，这也是实际系统中理想的外部访问Kubernetes集群内部的模式。

　　◎

　　通过写一个程序来监听Service的变化，将变化按照负载均衡器的通信接口，作为规则写入负载均衡

　　器。

　　13

　　◎

　　给负载均衡器提供直接访问Pod的通信手段。如下图，说明了这个过程。

　　图9自定义外部负载均衡器访问Service

　　这里提供了一个ServiceAgent来实现Service变化的感知。该Agent能够直接从etcd中或者通过接口调用APIServer来监控Service及Endpoint的变化，并将变化写入外部的硬件负载均衡器中。

　　同时，每台Node上都运行着有路由发现协议的软件，该软件负责将这个Node上所有的地址通过路由发

　　现协议组播给网络内的其他主机，当然也包含硬件负载均衡器。这样硬件负载均衡器就能知道每个Pod实例的IP地址是在哪台Node上了。通过上述两个步骤，就建立起一个基于硬件的外部可感知Service的负载均衡器。

　　具体的案例，可以参见第五章的实践部分。

　　3.5

　　总结

　　本章重点介绍了Kubernetes网络的各种场景，包括容器之间、Pod之间、Pod到Service、外部到内部的这4种场景下，不同的通信模式。在设计Kubernetes容器平台的时候，建议按照这些通信模式，根据具体的场景，逐一比对选择合适的解决方案。其中，需要注意的是外部到内部的访问，既可以通过NodePort，也可以通过LoadBalancer的方式亦或是Ingress模式，需要按照具体的场景来分析。

　　NodePort服务是暴露服务的最原始方式，会在所有节点上打开特定的端口，并且发送到此端口的任何流量都将转发到该服务。这种方法有很多缺点：每个端口只能有一个服务；默认只能使用端口30000～

　　32767；如果节点IP地址发生更改，则会带来问题。由于这些原因，不建议在生产中使用这种方法。如果服务可用性不是特别关注，或者特别关注成本，则这个方案比较合适。

　　LoadBalancer是服务暴露的标准方式，将会启动一个网络负载均衡器，提供一个将所有流量转发到服

　　14

　　务的IP地址。如果直接暴露一个服务，这是默认的方法。指定的端口上所有的流量将被转发到该服务，没有过滤、路由等。这就意味着可以发送几乎任何类型流量，如HTTP、TCP、UDP、Websocket、gRPC或其

　　他。这个方式最大的缺点是，使用LoadBalancer公开的每项服务都将获得自己的IP地址，并且必须为每个

　　服务使用一个LoadBalancer，这将会付出比较大的代价。

　　Ingress实际上不是一种服务。相反，它位于多个服务之前，充当集群中的“智能路由器”或入口点。默认的Ingress控制器将会启动一个HTTP（s）负载均衡器。这将可以执行基于路径和基于子域名的路由到后端服务。Ingress可能是暴露服务最强大的方式了，但也可能是最复杂的。如果希望在相同的IP地址下暴露多个服务，并且这些服务都使用相同的L7协议，则Ingress是最有用的。

　　Kubernetes网络组件介绍

　　4.1

　　Kubernetes网络框架CNI

　　基于Docker的Kubernetes平台为什么没有选择CNM作为其网络设计框架，毕竟大部分容器平台肯定会支持Docker的网络组件，为什么不使用相同的组件呢？这就要从Kubernetes平台设计初衷说起，Kuberne-tes是一个支持多容器的运行环境，而Docker只是其中一个容器而已。Docker网络驱动设计中，做了很多和Kubernetes不兼容的假设。

　　例如，Docker中有“本地”驱动和“全局”驱动概念，“本地”驱动实现单机版，无法实现跨节点协作，“全

　　局”驱动libkv可实现跨节点协作。但是，libkv接口太过于底层，而且架构模式也是Docker内部的量身定制版本，对于Kubernetes的应用会带来性能、可扩展性和安全性方面的问题。

　　CNI（ContainerNetworkingInterface）提供了一种Linux的应用容器的插件化网络解决方案。最初是由rktNetworkingProposal发展而来。也就是说，CNI本身并不是完全针对Docker的容器，而是提供一种普适的容器网络解决方案。模型涉及两个概念：

　　容器：拥有独立Linux网络命名空间的独立单元。比如rkt/docker创建出来的容器。

　　网络（Networking）：网络指代了可以相互联系的一组实体。这些实体拥有各自独立唯一的IP。这些实体可以是容器，是物理机，或者是其他网络设备（比如路由器）等。

　　CNI的接口设计非常简洁，不需要守护进程，只有两个接口ADD/DELETE，通过一个简单的shell脚本就可以完成。相对于CNM的复杂设计，CNI更加适合快速开发和迭代。

　　4.2

　　CNI支持的开源组件

　　4.2.1

　　Flannel

　　15

　　Flannel之所以可以搭建Kubernetes依赖的底层网络，是因为它可以实现以下两点：

　　它给每个node上的docker容器分配相互不想冲突的IP地址；

　　它能给这些IP地址之间建立一个覆盖网络，同过覆盖网络，将数据包原封不动的传递到目标容器内。

　　Flannel是CoreOS团队针对Kubernetes设计的一个网络规划服务，简单来说，它的功能是让集群中的不同节点主机创建的Docker容器都具有全集群唯一的虚拟IP地址。

　　在默认的Docker配置中，每个节点上的Docker服务会分别负责所在节点容器的IP分配。

　　这样导致的一个问题是，不同节点上容器可能获得相同的内外IP地址。并使这些容器之间能够之间通过IP地址相互找到，也就是相互ping通。

　　Flannel的设计目的就是为集群中的所有节点重新规划IP地址的使用规则，从而使得不同节点上的容器能够获得“同属一个内网”且”不重复的”IP地址，并让属于不同节点上的容器能够直接通过内网IP通信。

　　Flannel实质上是一种“覆盖网络(OverlayNetwork)”，也就是将TCP数据包装在另一种网络包里面进行路由转发和通信，默认的节点间数据通信方式是UDP转发。

　　图10Flannel跨节点Pod通信图

　　举个例子，上图是跨节点Pod通信。

　　可以看到，Flannel首先创建了一个名为?annel0的网桥，而且这个网桥的一端连接Docker0网桥，另一端连接一个叫作?anneld的服务进程。?anneld进程并不简单，它上连etcd，利用etcd来管理可分配的IP地址段资源，同时监控etcd中每个Pod的实际地址，并在内存中建立了一个Pod节点路由表；它下连Docker0和物理网络，使用内存中的Pod节点路由表，将Docker0发给它的数据包包装起来，利用物理网络的连接将数据包投递到目标?anneld上，从而完成Pod到Pod之间的直接地址通信。

　　16

　　4.2.2

　　OVS

　　OpenvSwitch是一个开源的虚拟交换机软件，有点像Linux中的bridge，但是功能要复杂的多。OpenvSwitch的网桥可以直接建立多种通信通道（隧道）。这些通道的简历可以很容易地通过OVS的配置命令实现。在Kubernetes、Docker场景下，主要是建立L3到L3点隧道。如下图所示。

　　图11OVSwithGRE原理图

　　首先，为了避免Docker创建的Docker0地址产生冲突（因为DockerDaemon启动且给Docker0选择子网地址时只有几个备选列表，很容易产生冲突），我们可以将Docker0网桥删除，手动建立一个Linux网桥，然后手动给这个网桥配置IP地址范围。

　　其次，建立OpenvSwitch的网桥OVS，使用ovs-vsctl命令给OVS网桥增加GRE端口，在添加GRE端口时要将目标连接的NodeIP地址设置为对端的IP地址。对每一个对端IP地址都需要这么操作（对于大型集群网络，这可是个体力活，要做自动化脚本来完成）。最后，将OVS的网桥作为网络接口，加入Docker的网桥上（Docker0或者自己手工建立的新网桥）。

　　重启OVS网桥和Docker的网桥，并添加一个Docker的地址段到Docker网桥的路由规则项，就可以将两个容器的网络连接起来了。

　　OVS的优势是，作为开源虚拟交换机软件，它相对比较成熟和稳定，而且支持各类网络隧道协议，经过了OpenStack等项目的考验。另一方面，在前面介绍Flannel的时候可知

　　Flannel除了支持建立Overlay网络，保证Pod到Pod的无缝通信，还和Kubernetes、Docker架构体系结合紧密。Flannel能够感知Kubernetes的Service，动态维护自己的路由表，还通过etcd来协助Docker对整个Kubernetes集群中Docker0的子网地址分配。而我们在使用OVS的时候，很多事情就需要手工完成了。无论是OVS还是Flannel，通过Overlay网络提供的Pod到Pod通信都会引入一些额外的通信开销，如果是对网络依赖特别重的应用，则需要评估对业务的影响。

　　4.2.3

　　Calico

　　Calico是一个纯三层的数据中心网络方案（不需要Overlay），并且与OpenStack、Kubernetes、AWS、GCE等IaaS和容器平台都有良好的集成。Calico在每一个计算节点利用LinuxKernel实现了一个高效的vRouter来负责数据转发，而每个vRouter通过BGP协议负责把自己上运行的workload的路由信息像整个

　　Calico网络内传播——小规模部署可以直接互联，大规模下可通过指定的BGProutere?ector来完成。这样保证最终所有的workload之间的数据流量都是通过IP路由的方式完成互联的。Calico节点组网可以直接利用

　　17

　　数据中心的网络结构（无论是L2或者L3），不需要额外的NAT，隧道或者OverlayNetwork。此外，Calico基于iptables还提供了丰富而灵活的网络Policy，保证通过各个节点上的ACLs来提供Workload的多租户隔离、安全组以及其他可达性限制等功能。下图是Calico的架构图。

　　图12Calico架构图

　　在满足系统要求的新配置的Kubernetes集群上，用户可以通过应用单个manifest文件快速部署Calico。如果您对Calico的可选网络策略功能感兴趣，可以向集群应用其他manifest，来启用这些功能。

　　尽管部署Calico所需的操作看起来相当简单，但它创建的网络环境同时具有简单和复杂的属性。与Flannel不同，Calico不使用Overlay网络。相反，Calico配置第3层网络，该网络使用BGP路由协议在主机之间路由数据包。这意味着在主机之间移动时，不需要将数据包包装在额外的封装层中。BGP路由机制可以本地引导数据包，而无需额外在流量层中打包流量。

　　除了性能优势之外，在出现网络问题时，用户还可以用更常规的方法进行故障排除。虽然使用VXLAN等技术进行封装也是一个不错的解决方案，但该过程处理数据包的方式同场难以追踪。使用Calico，标准调试工具可以访问与简单环境中相同的信息，从而使更多开发人员和管理员更容易理解行为。

　　除了网络连接外，Calico还以其先进的网络功能而闻名。网络策略是其最受追捧的功能之一。此外，Calico还可以与服务网格Istio集成，以便在服务网格层和网络基础架构层中解释和实施集群内工作负载的策略。这意味着用户可以配置强大的规则，描述Pod应如何发送和接受流量，提高安全性并控制网络环境。

　　如果对你的环境而言，支持网络策略是非常重要的一点，而且你对其他性能和功能也有需求，那么

　　Calico会是一个理想的选择。此外，如果您现在或未来有可能希望得到技术支持，那么Calico是提供商业支持的。一般来说，当您希望能够长期控制网络，而不是仅仅配置一次并忘记它时，Calico是一个很好的选择。

　　图13Calico功能模块图

　　18

　　Calico主要由Felix、etcd、BGPclient以及BGPRouteRe?ector组成

　　◎

　　Felix，CalicoAgent，跑在每台需要运行Workload的节点上，主要负责配置路由及ACLs等信息来确保Endpoint的连通状态；

　　◎etcd，分布式键值存储，主要负责网络元数据一致性，确保Calico网络状态的准确性；

　　◎BGPClient（BIRD）,主要负责把Felix写入Kernel的路由信息分发到当前Calico网络，确保Work-load间的通信的有效性；

　　◎BGPRouteRe?ector（BIRD），大规模部署时使用，摒弃所有节点互联的mesh模式，通过一个或者多个BGPRouteRe?ector来完成集中式的路由分发。

　　◎calico/calico-ipam，主要用作Kubernetes的CNI插件

　　4.2.4

　　Contiv

　　Contiv是思科开源的容器网络方案，是一个用于跨虚拟机、裸机、公有云或私有云的异构容器部署的开源容器网络架构，并与主流容器编排系统集成。Contiv最主要的优势是直接提供了多租户网络，并支持L2(VLAN),L3(BGP),Overlay(VXLAN)以及思科自家的ACI。

　　图14Contiv架构图

　　4.3

　　总结对比

　　19

　　图15各种开源技术性能对比

　　CalicoBGP方案最好，不能用BGP也可以考虑CalicoIPIPTunnel方案；如果是CoreOS系又能开UDPO?oad，Flannel是不错的选择；Docker原生Overlay还有很多需要改进的地方。

　　容器平台的网络架构实践

　　5.1

　　某金融企业使用OpenShift（基于Kubernetes的商业版本）实现其业务

　　上云

　　20

　　5.1.1

　　整体网络架构图

　　图16整体网络架构图

　　在DMZ和内网分别部署彼此独立的2套OpenShift，分别为内网和DMZ区两个网段，两套环境彼此隔离。DMZ区的OpenShift部署对外发布的应用，负责处理外网的访问。内网的OpenShift部署针对内网的应用，仅负责处理内网的访问。

　　5.1.2

　　传统应用访问策略

　　方案推荐通过NodePort类型的Service为某个应用对外暴露一个服务端口。NodePort类型的Service会在集群中的所有节点上监听一个特定的端口，访问任意一个计算机节点的端口，即可访问内部容器中的服务。在集群的所有节点的这个端口都会预留给该应用所用。在F5VS的PoolMember中配置所有节点，通过Kee-palived来实现HA。应用系统和用户不用改变现有的访问方式。

　　图17传统应用访问策略

　　21

　　5.1.3

　　数据库访问方案及防火墙策略

　　内网计算节点可以直接访问数据库，DMZ区计算节点访问数据库有2种方案：

　　（1）计算节点直接通过内网防火墙访问该应用数据库内网防火墙仅开通应用所在节点访问内部数据库的端口，例如本期方案中应用仅使用2个节点，则防火墙仅开通这2个节点访问数据库的权限。

　　图18计算节点直接通过内网防火墙访问该应用数据库

　　（2）计算节点经Outbound路由通过内网防火墙访问内网数据

　　这Outbound路由在OpenShift中称之为EgressRouter

　　图19经Outbound路由通过内网防火墙访问内网数据

　　因此，内网防火墙仅开通应用所在节点访问内部数据库的端口，例如，应用A仅通过路由节点A和B访问内部数据库，则防火墙仅开通这2个节点访问A数据库的权限。

　　22

　　图20通过OutBoundRouter访问数据库

　　5.2

　　某金融企业两第三中心容器云网络架构

　　图21某企业两第三中心容器云架构

　　平台基于多集群管理和联邦集群特性，对两地三中心、同城双活、异地灾备等业务场景提供了原生的支持。平台以统一多集群管理为核心，可对接稳定快速的物理机服务器、资源利用率高的虚拟机、不同云环境下的云主机创建Kubernetes集群。支持运行多集群，保证集群的高可用。提供跨云的多集群统一管理，解决多云灾备问题，实现统一部署、统一发布以及统一运维。通过mirror联邦集群，为已经存在的集群进行组件

　　23

　　联邦集群。可以在联邦内选择在一个或多个集群创建。

　　优化实践

　　网络优化是一个非常复杂的话题，现实场景中，如果出现服务不可用的情况，往往都会怀疑到网络上面

　　——网络不可达，网络拥塞，网络设备失效等等。一个容器平台网络的高效稳定安全，涉及方方面面的设计

　　考量。这里将我们在实践中的一些优化措施作了一些总结：

　　（1）主节点优化

　　在集群中，除了Pod之间的网络通信外，最大的开销就是master和etcd之间的通信了，因此：

　　Master侧可以优化：

　　◎

　　Master和etcd尽量部署在一起

　　◎

　　高可用集群中，Master尽量部署在低延迟的网络里

　　◎

　　确保**/etc/origin/master/master-con?g.yaml**里的etcds，第一个是本地的etcd实例Node侧可以优化：

　　Node节点的配置主要在**/etc/origin/node/node-con?g.yaml**里，可以优化：iptables,synchronizationperiod,MTU值，代理模式。配合自文件里还可以配置Kubelet的启动参数，主要关注亮点pods-per-core和max-pods，这两个决定了Node节点的Pod数，两者不一致时，取小。如果数值过大（严重超读）会导致：

　　◎

　　增加CPU消耗，主要是Docker和OpenShift自身管理消耗的

　　◎

　　降低Pod调度效率

　　◎

　　加大了OOM的风险

　　◎

　　分配PodIP出现异常

　　◎

　　影

　　响

　　应

　　用

　　性

　　能etcd节点：尽量和Master部署在一起，或者提供专网连接。

　　（2）主机节点万兆网卡性能优化

　　如果主机用万兆或者40Gbps，那么可以优化的方面：

　　24

　　◎

　　通过直接路由，负责Pod间通信，不过需要手动维护Node节点添加删除时的路由变化

　　◎

　　条件允许的话，可以考虑BGP的Calico网络方案

　　◎

　　购置支持UDPO?oad的网卡，需要注意的是，使用了UDPO?oad网卡和非Overlay网络相比，延迟是不会减少的，只是减少了CPU开销，提到带宽吞吐。

　　（3）IPIP模式的Flannel性能提升

　　汲取了Flannel/Calico容器网络开源项目的优点，实现了基于IPIP和HostGateway的Overlay网络，具体性能—短链接VXLAN比host差33%，IPIP比host差23%，Gateway比host只差6%。具体参见下图：

　　（4）使用指定的UnderlayIP优化

　　图22IPIP模式Flannel性能提升

　　FloatingIP指定宿主机提供的IP，将IP直接配置到容器中，有别于OpenStack（将FloatingIP配置到宿主机的网络空间再通过NAT转发）的实现，其性能更好，容器与物理机可以直接路由。Tunnel网卡在容器中创建，避免了使用NodePort带来的性能损耗。具体参见下图：

　　图23使用指定的UnderlayIP优化

　　（5）cgroup实现资源隔离

　　25

　　在cgroup提供的能力之上，实现了网络出入带宽、资源隔离的能力，并提供所有硬件资源的可弹性配置，使得容器硬件资源全维度可弹性配置，大度提升了应用的隔离性与稳定性。在实际的运营过程中，我们发现，用户往往不能很好的预先设置最急limit值，设置过大会导致资源浪费，设置过小又会导致业务性能损失甚至业务进程频繁OOM，弹性的优势在于，用户不需要配置limit值，系统可以自动将空闲资源交给业务容器使用。使得容器的稳定性、集群资源利用率均得到提升。

　　图24cgroup对网络资源的优化

　　如上图，某个cgroup网络繁忙时，能保证其设定配额不会被其他cgroup挤占；某个cgroup没有用满其配

　　额时，其他cgroup可以自动使用其空闲的部分带宽；多个cgroup分享空闲带宽时，优先级高的优先占用，优先级相同时，配额大的占用多，配额小的占用少，减少为了流控而主动丢包。

　　（6）基于DPDK技术实现对DDos攻击防护

　　（7）网络带宽QoS相关

　　网络带宽QoS主要是为了保证用户所申请的带宽资源，以及有效利用空闲的网络资源，尽可能提升用户带宽体验。那么我们可以做的事：

　　基于LinuxTra?cControl并修改OVS，实现保证速率，最大速率；

　　将小包按照MPU（MinimumPacketUnit）大小来处理

　　同时，针对VXLAN小包处理性能不好，网络小包过多导致宿主机CPU过载，影响网络性能和稳定性的问题，通过限制容器网络的PPS（PacketPerSecond）来处理。

　　26

篇十二：容器网络流量研究教授

　基于PSO-混合核函数的SOM网络流量分类研究

　　李涛;李娟

　　【摘

　　要】针对基于核函数的自组织特征映射SOM(Self-organizingfeatureMap)算法中核函数的单一性选取和核函数参数的不确定性,提出一种基于PSO-混合核函数的SOM算法.用两种核函数混合构造新的核函数,采用改进的粒子群算法PSO对核函数中的参数以及两种核函数的混合参数进行优化确定,并应用于网络流量数据.实验结果表明,基于PSO-混合核函数的SOM算法,相对于传统的SOM算法以及单一核函数SOM算法,分类的可靠性和稳定性有明显的提高.

　　【期刊名称】《计算机应用与软件》

　　【年(卷),期】2015(032)011

　　【总页数】5页(P117-120,125)

　　【关键词】自组织神经网络;混合核函数;粒子群算法;参数优化;网络流量

　　【作

　　者】李涛;李娟

　　【作者单位】南京信息工程大学电子与信息工程学院

　　江苏南京210044;南京信息工程大学电子与信息工程学院

　　江苏南京210044

　　【正文语种】中

　　文

　　【中图分类】TP393

　　网络流量是网络业务的直接承载体［1］。对网络流量进行分类可以发现流量的瓶颈和拥塞的情况，检测到恶意攻击，使得网络用户得到更好的服务质量。近些年来，随着数据挖掘算法［2］在各行各业的广泛运用，根据流的统计特征，采用数据挖

　　掘的方法对网络流量进行分类受到很大的关注，通过选取网络流量数据的特征属性，采用数据挖掘的方法对网络流量进行分类，分类的结果较好［3－5］。自组织神经网络SOM是一种无监督学习的竞争式网络，已经得到了广泛的应用［6］。当有外界信息输入时，它会对其产生不同的响应，从而对样本进行分类，但由于网络流量数据复杂的非线性特征，其在网络流量数据分类上的效果常很难令人满意。文献［6］采用基于RBF核函数的SOM分类方法对网络流量数据进行分类，虽然可以克服SOM网络在对高维非线性的网络流量数据进行分类时出现的弊端，但是没有考虑到核函数的单一性选取以及核函数参数的随机性选取所带来的问题对分类精度的影响。

　　针对以上问题，本文提出一种基于混合核函数的SOM网络的分类方法对网络流量数据进行分类，并采用改进的粒子群算法PSO对分类模型中的参数进行优化确定，以解决核函数的单一性选取以及核函数参数的随机性选取所带来的问题，提高了网络流量数据的分类精度。

　　芬兰Helsinki大学的KohonenT教授提出了一种SOM网络，又称Kohonen网络［7］。Kohonen认为，一个神经网络当有外界信息输入时，将会自动分为不同的对应区域，产生不同的响应，SOM网络正是根据这一看法提出的，其特点与人脑的自组织特性相类似［8］。

　　SOM网络共有两层：输入层和输出层。

　　输入层：输入层的节点数即样本的特征维数。

　　输出层：输出层也叫竞争层。其神经元的排列有一维线阵、二维平面阵以及三维栅格阵等多种形式［8］。其中二维平面阵最常使用，它具有大脑皮层的形象，如图1所示。

　　SOM算法在学习时有两个关键步骤，在随机初始化竞争层的连接权值之后，第一个关键步骤是计算输入样本与竞争层各神经元之间的欧氏距离，找到距离最近的神

　　经元作为获胜神经元；第二个关键步骤是获胜神经元周围一定邻域内的神经元的权值要做相应调整。所以SOM算法学习时依赖输入样本和初始权值之间的欧氏距离来调整权值，但是对于线性不可分的网络流量数据集，采用传统SOM算法分类时，没有很好的可靠性和稳定性，如果将其映射到特征空间，可以在特征空间简化其复杂的非线性结构，从而实现更好的划分。

　　1.1基于核函数的SOM网络

　　1.2混合核函数选取和构建

　　不同的样本，只有基于不同的核函数的SOM算法才能实现有效的划分。核函数主要分为两种：局部性核函数和全局性核函数。局部性核函数就是在测试点附近小范围内对核函数的值有影响，而全局性核函数即使远离测试点对核函数的值也有影响，是大范围的［9］。

　　算法中常用的一些满足Mercer条件的核函数有：

　　（1）多项式核函数

　　（2）径向基核函数（RBF）

　　（3）Sigmoid函数

　　RBF函数就是一个典型的局部性核函数，而多项式核函数是一个典型的全局性核函数［9］。本文选取一个局部性核函数和一个全局性核函数，将两者混合起来，构造混合核函数，如下的命题［10］说明了混合核函数依然满足Mercer条件。

　　设K1，K2是X×X上的核，X∈Rn，f（x）是X上的实值函数；φ（x）：X→Rn。K3是Rn×Rn上的核，B是一个n×n维的对称半定矩阵，则下述函数是核函数。

　　（1）K（x，y）＝K1（x，y）＋K2（x，y）

　　（2）K（x，y）＝K1（x，y）K2（x，y）

　　（3）K（x，y）＝K3（φ（x），φ（y））

　　（4）K（x，y）＝exp（K1（x，y））

　　所以混合核函数K＝λK1＋（1－λ）K2满足Mercer条件，文中K1选取多项式核函数，K2选取径向基核函数，λ为混合参数，λ∈（0，1），则混合核函数为：

　　K（x，y）＝λ［（xT×y）＋1］q＋（1－λ）exp（－‖x－y‖2／σ2）（7）根据新的核函数式（7）结合式（2）、式（3）得到新的距离度量公式和权值调整公式。

　　核函数的参数选取对SOM算法的性能和效率有很大的影响［11］，混合参数的不同也会影响不同核函数的性能发挥。混合核函数中q，σ，λ的选取与模型训练精度有着密切的关系，因此选取合适的优化算法，搜索出最优的参数组合q，σ，λ，才能提高SOM分类模型的训练精度。

　　2.1粒子群算法及改进

　　粒子群算法（PSO）是一种有效的全局寻优算法，最早由美国的Kennedy和Eberhart于1995年提出［12］。其可描述为：假设需要优化n个参数，即确定粒子的位置和速度的维数为n，首先随机得到m个粒子Z＝｛Z1，Z2，…，Zm｝，初始化粒子的位置Zi＝｛zi1，zi2，…，zin｝，每个位置代表粒子刚开始找到的最优解pid＝｛pi1，pi2，…，pin｝，每个粒子都有自己的速度，记作Vi＝｛vi1，vi2，…，vin｝。从每个粒子刚开始找到的最好的位置中找到最好的符合目标函数的位置得到全局最优解pgd＝｛pg1，pg2，…，pgn｝。粒子根据式（8）、式（9）不断改变自己的位置Zi和速度Vi，找寻新的解，如果搜到的新解比自己之前搜到的最优解好，则更新自己找到的最优解pid，如果自己搜到的最优解比全局最优解还要好，则更新全局最优解pgd。

　　其中，vid（t＋1）表示第i个粒子在t＋1次迭代中第d维上的速度，ω为惯性权重，它使粒子保持运动惯性，传统ω的更新方式为ω＝ωmax－（ωmax－ωmin）×t／tmax，其中ωmax，ωmin分别取0.9和0.4，tmax为最大迭代次数，η1，η2为加速常数，通常取为2，rand（）为0～1之间的随机数。

　　惯性权值ω对粒子群算法的收敛十分重要［12］。传统的线性减小ω的方法局部

　　搜索能力不强，因此可能会错过全局最优解，采用非线性减小ω的方法代替传统方法，使得ω在全局搜索时刻保持较长时间较大值，从而提高全局搜索效率，在局部搜索时也能保持较长时间的较小值，提高局部搜索的精度。新的ω的更新方式变为：

　　2.2改进PSO算法优化参数步骤

　　首先我们需要自己构建与参数有关的目标函数，在训练SOM网络时，连接权值与样本值越接近，即‖X－Wj‖2越小，则连接权值越能代表样本，训练结果就越准确。因此我们构建目标函数为：

　　其中l代表样本序号，c为样本总数，xl为第l个输入样本，wjl为与xl响应的连接权值，‖φ（xl）－φ（wjl）‖2为xl与wjl的特征空间距离。目标函数越小，说明训练结果越准确，用于分类的精度就越高。

　　（1）确定q，σ，λ的取值范围，和粒子的速度变化界限［－Vmax，Vmax］，初始化每个粒子（q，σ，λ）的Zi和Vi；

　　（2）读入流量数据，适应度值设为fitness＝k／J，k为常数，目标函数越小，粒子的适应度越大。通过训练SOM模型计算得出每个粒子的适应度，找出具有最大适应度的粒子，它对应的适应度值就是最初的全局极值pgd；

　　（3）根据式（8）、式（9）调整粒子的Zi和Vi，且其中的ω按式（10）进行减小；

　　（4）进行速度、位置限制，当Vid＞Vmax或Vid＜Vmin时，令Vid＝Vmax或Vid＝Vmin，当Zid＞Zmax或Zid＜Zmin时，Zid＝Zmax，Vid＝－Vid或Zid＝Zmin，Vid＝－Vid；

　　（5）计算粒子在新位置的适应度，较之前位置的适应度以及群体最好位置的适应度大小，更好则更新pid和pgd；

　　（6）如果找到足够好的位置，则输出最好的位置，否则返回（3）。

　　3.1实验数据

　　网络流量数据集包含匹配协议端口，解析协议内容和流的统计特征等特征属性，数据挖掘方法不依赖于匹配协议端口、解析协议内容来识别网络应用，而是利用流量在传输过程中流的统计特征进行识别。

　　目前大多数关于网络流量的研究都是以文献［13］中基于流的248种属性作为区分标准［14－16］，并以Moore等人在文献［13］中所用的实验数据集（简称Moore_set）中的13个流量类型作为研究对象，Moore_set数据集中每个样本都是从一条完整的TCP双向流抽取而来，一共包含248项属性，最后一项就是分类目标的属性，表明样本的流量类型。所以本文采用Moore_set作为实验数据集，为了减少算法的冗杂度，除去几种数据量非常小的流量类型，仅采用8类数据量较大的流量类型数据进行实验，分别是WWW，MAIL，BULK，DB，SERV，P2P，ATT，MULT。选取每种类型各100组数据，其中80组作为训练集，20组作为测试集。

　　由于采用混合核函数，因此在进行训练时，处于［0，1］的数据最为灵敏。为了分类模型训练的效率，在建模之前对网络流量数据进行归一化处理：

　　其中x表示原始流量数据，xmax、xmin表示最大值、最小值。

　　3.2特征选择

　　Moore_set数据集中每条网络流量数据有248个特征属性，如果全部选取，数据量较大，计算繁琐，采用文献［17］的FCBF算法从248个属性特征中选出8个合适的属性特征构成特征子集，作为SOM分类算法的输入向量。这8个特征子集分别是：①源端口号；②ACK报文总数；③PUSH报文总数；④MSS；⑤发送到初始窗口字节总数；⑥丢失数据；⑦重传最大数；⑧报文控制字节最小值。

　　3.3参数设置

　　首先确定SOM网络输入层8个神经元，竞争层采用二维平面，神经元数为

　　20×20＝400个，对SOM网络初始化：最大迭代次数取为2000次，初始学习率η0取为0.8，邻域内神经元初始学习率η′0取为0.2，邻域初始值N0取为8，本文使用MATLAB软件作为仿真环境。根据实验的初步验证，得到（q，σ，λ）的搜索区间为q∈［1，10］，σ∈［0.001，30］，λ∈［0，1］，在PSO算法中设置种群规模ps＝20，最大迭代次数为tmax＝100，ωmax，ωmin分别取0.9和0.4，η1，η2取为2，适应度中的k设为6，Vmax通常设置为参数变化范围的10%～20%，这里设置为Vmax＝［2，6，0.2］。

　　图2描绘了惯性权值ω与迭代次数之间的变化关系，根据式（10）中n的选取不同，得到不同的变化曲线。有图2可知当n＝5时，搜索刚开始时ω能保持较长时间的较大值，搜索快结束时ω也能保持较长时间的较小值。

　　图3描绘了基于PSO算法优化混合核函数SOM模型参数在100次迭代寻优过程中的适应度值fitness＝k／J的变化过程，J为目标值函数，连接权值与样本值越接近，目标函数越小，适应度值越大，说明训练结果越准确。

　　从图3可以看出，当迭代次数达到67次的时候，最优适应度值基本不再变化，得到最优参数值q＝4，σ＝10，λ＝0.53。

　　采用本文算法和SOM算法以及分别基于三种核函数的SOM算法，其中多项式、径向基及Sigmoid核函数的参数值随机设置为q＝2，σ＝0.003，c＝2，用于网络流量数据训练集上的正确率如表1、表2所示。

　　从表1、表2可知，本文算法用在网络流量数据训练集上的准确率最高，传统SOM算法的准确率最低。基于任一核函数的SOM算法的准确率都高于传统SOM算法，说明将输入空间映射到特征空间时，SOM算法的原理同样适用，且更优于传统SOM算法；对于核函数的不同，基于多项式和基于径向基核函数的准确率相差不大，基于径向基核函数的准确率略高于基于多项式核函数的准确率，基于Sigmoid核函数的准确率较低，说明本文选取两种准确率相对较高的核函数混

　　合构成新的核函数有一定的依据，并且将多项式和径向基核函数根据优化确定的混合参数λ混合起来，提高了SOM网络的训练精度。

　　将训练后的模型应用于网络流量数据验证集，分别运行20次，为了验证和评价算法的性能，采用量化误差Eq［18］作为评判标准得到的相应评价指标比较如图4所示。

　　定义量化误差：

　　式（14）是针对基于核函数的SOM算法的量化误差。式（15）是针对传统的SOM算法的量化误差。其中c为输入样本总数，xl为第l个输入样本，wjl为与xl响应的连接权值，‖xl－wjl‖为xl与wjl的距离，‖φ（xl）－φ（wjl）‖为xl与wjl的特征空间距离。量化误差越小，说明连接权值越能准确代表输入样本。

　　图4中o为SOM，＋为sigmoid，*为多项式，◇为径向基，▽为PSO-混合。可以看出，传统SOM算法的量化误差变化幅度最大，基于任一核函数的SOM算法较传统的SOM算法，误差的变化幅度较小且相对平稳，说明对于非线性的网络流量数据，采用基于核函数的SOM算法将其映射到特征空间进行分类，不仅分类的结果较好，而且更加稳定。实验还发现基于PSO-混合核函数的SOM算法的量化误差较基于任一核函数的SOM算法都小，误差的变化也更加平稳，说明采用混合核函数作为新的核函数，并通过粒子群算法优化确定核函数的参数以及混合参数，与较单一的核函数相比，提高了网络流量数据分类的可靠性和稳定性。

　　网络流量数据的非线性特征导致传统SOM算法分类的可靠性较差，基于核函数的SOM算法能够克服这一不足，但单一的核函数选取以及核函数参数的不确定性对分类结果有很大的影响。针对这一问题，本文提出了基于PSO-混合核函数的SOM算法，通过将两种不同的核函数混合起来构造新的核函数作为特征空间中的内积，将网络流量数据映射到特征空间，使得复杂的流量数据在特征空间得到简化，并采用改进粒子群算法（PSO）对核函数中的参数以及混合参数进行优化确定。

　　实验结果表明，本文提出的算法相对于传统的SOM算法，以及基于单一核函数的SOM算法，在网络流量数据分类的可靠性和稳定性有很大的提高。

　　【相关文献】

　　［1］尹波，夏靖波，付凯.基于IPSO混沌支持向量机的网络流量预测研究［J］.计算机应用研究，2012，12（11）：4293-4295.［2］KaragiannisT，PapagiannakiK，FaloutsosM.BLINC：Multileveltrafficclassificationinthedark［C］//Philadelphia：ProcoftheACMSIGCOMM，2005：229-240.［3］MattiHirvonen，Jukka-PekkaLaulajainen.Two-phasednetworktrafficclassificationmethodforqualityofservicemanagement［C］//Procofthe13-thIEEEInternationalSymposiumonCon-sumerElectronics，2009：962-966.［4］PeterTeufl，UdoPayer，MichaelAmling.InFeCT-networktrafficclassification［C］//ProcofSeventhInternationalConfere-nceonNetworking，2008：439-444.［5］MooreAW，ZuevD.InternettrafficclassificationusingBayesiananalysistechniques［C］//Procofthe2005-ACMSIGMETRICSInt’lConfonMeasurementandModelingofComputerSystems，2005：50-60.［6］胡婷，王勇，陶晓玲.基于核函数的SOM网络流量分类方法［J］.计算机工程与设计，2011，32（4）：1195-1198.［7］呼大永，冯玉强，唐振宇，等.基于自组织神经网络和DEA的采购拍卖获胜者确定问题模型［J］.系统工程理论与实践，2012，16（2）：398-404.［8］任军号，吉沛琦，耿跃.SOM神经网络改进及在遥感图像分类中的应用［J］.计算机应用研究，2011，11（3）：1170-1172.［9］SmitsGF，JordanEM.ImprovedSVMregressionusingmixturesofkernels［C］//IEEEProcofthe2002-IntJointConfonNeuralNetworks，2002：2785-2790.［10］CristianiniN，Shawe-TaylorJ.Anintroductiontosupportvectormachines［M］.CambridgeUniversityPress，2000.［11］章永来，史海波，尚文利.面向乳腺癌辅助诊断的改进支持向量机方法［J］.计算机应用研究，2013，30（8）：2372-2376.［12］陈崚，沈洁，秦玲.基于分布均匀度的自适应蚁群算法［J］.软件学报，2003，14（8）：1379-1387.［13］MooreAW，ZuevD.InternettrafficclassificationusingBayesiananalysistechniques［C］//Procofthe2005-ACMSIGMETRICSInt’lConfonMeasurementandModelingofComputerSystems，2005：50-60.［14］剌婷婷，师军.基于GA-CFS和AdaBoost算法的网络流量分类［J］.计算机应用研究，2012，29（9）：3411-3414.［15］顾成杰，张顺颐，高飞.基于混沌粒子群优化算法的认知网络流量分类方法研究［J］.计算机应用与软件，2011，28（11）：153-156，160.［16］柏骏，夏靖波，鹿传国，等.基于RVM的网络流量分类研究［J］.电子科技大学学报，2014，13（2）：241-246.［17］YuLei，LiuHuan.Featureselectionforhigh-dimensionaldata：Afastcorrelation-basedfiltersolution［C］//ProceedingsoftheTwentiethInternationalConferenceonMachineLearning，2003.［18］唐贤伦，仇国庆，李银国，等.基于粒子群优化和SOM网络的聚类算法研究［J］.华中科技大学学报：自然科学版，2007，35（5）：32-37.

篇十三：容器网络流量研究教授

　5种场景

　　容器网络技术方案选型推荐

　　放驴人

　　收集整体

　　SDN是Software-definednetworking的缩写。在许多介绍Kubernetes的文档，特别是安装文档中，当介绍到Kubernetes所需的容器网络时常常会提到这个缩写，告知用户需要使用某种SDN技术用以解决“每个Pod有独立IP，Pod之间可以不经过NAT直接互访”这一Kubernetes集群最基本的技术要求。

　　大多数非网络工程师背景的技术人员对SDN这个概念会比较陌生，当读到这个段落时，往往会选择把它当作Kubernetes的底层依赖，照着文档所推荐的流程安装一款SDN工具，比如Flannel，Calico，Weave等。由于不了解这些工具的原理，同时缺乏实际的使用经验，当出现文档以外的异常情况时，整个安装流程就卡住了。SDN俨然成为了Kubernetes大规模普及的拦路虎。

　　那些按照文档顺利搭建起来的集群当中，还有不少使用了并不适合该集群所处环境的SDN技术，造成了额外的运维负担以及潜在的安全风险。让我们不得不思考一个问题，怎样才是正确的在Kubernetes集群中使用SDN技术的方法？

　　今天我们来详细聊聊这个话题。

　　结论先行

　　在大多数的Kubernetes集群中，都不需要使用SDN技术，Kubernetes的容器网络要求可以使用更加简单易懂的技术来实现，只有当企业有特定的安全或者配置要求时，才需要使用SDN技术。SDN应当作为一个附加选项，用以解决特定的技术问题。

　　理解Kubernetes的容器网络

　　下图是一张Kubernetes容器网络的示意图

　　可以看到在图中，每台服务器上的容器有自己独立的IP段，各个服务器之间的容器可以根据目标容器的IP地址进行访问。

　　为了实现这一目标，重点解决以下这两点：

　　?

　　各台服务器上的容器IP段不能重叠，所以需要有某种IP段分配机

　　?5种场景

　　容器网络技术方案选型推荐

　　制，为各台服务器分配独立的IP段

　　?

　　从某个Pod发出的流量到达其所在其他的服务器会收到这条新记录，并更新本地的IP段映射表。

　　Flannel的IP段分配发生在各台服务器上，由flannel进程将结果写入到etcd中。路由也由Flannel完成，网络流量先进入Flannel控制的Tunnel中，由Flannel根据当前的IP段映射表转发到对应的服务器上。

　　需要指出的是Flannel有多种backend，另外新增的kube-subnet-mgr参数会导致服务器时，服务器网络层应当具备根据目标IP地址将流量转发到该IP所属IP段所对应的目标服务器的能力。

　　总结起来，实现Kubernetes的容器网络重点需要关注两方面，分配和路由。

　　Flannel的工作方式

　　这里我们以比较常见的Flannel为例子，看看SDN系统是如何解决分配和路由的问题的。

　　下图是Flannel的架构示意图

　　Flannel的工作方式有所不同，在这里就不详细展开了。有兴趣的朋友可以去查阅Flannel的文档以及源代码了解更多的细节。

　　更见简化的网络配置方法

　　Flannel的工作方式有2点是需要注意的。一是所有服务器上运行的Flannel均需要etcd的读写权限，不利于权限的隔离和安全防护。二是许多教程中所使用的默认backend类型为vxlan，虽然它使用了内核中的vxlan模块，造成的性能损失并

　　可以看到Flannel依赖etcd实现了统一的配置管理机制。当一台服务器上的Flannel启动时，它会连接所配置的etcd集群，从中取到当前的网络配置以及其他已有服务器已经分配的IP段，并从未分配的IP段中选取其中之一作为自己的IP段。当它将自己的分配记录写入etcd之后，不大，但是在常见的二层网络的环境中，其实并不需要使用Tunnel技术，直接利用路由就可以实现流量的转发，这时使用hostgw模式就可以达成目标。

　　大部分的Kubernetes集群服务器数量并不会超过100台，不论是在物理机房当中或是利用IaaS提供的VPC技术，我们会把这些服务器均放在同一个网段，这时?1

　　?5种场景

　　容器网络技术方案选型推荐

　　我们可以去掉Flannel这一层，直接使用Kubernetes内置的kubenet功能，配合上我们为Kubernetes定制的hostroutes工具，即可实现容器网络的要求。

　　watch所有的Node资源的变化，用所有Node资源的PodCIDR字段来配置服务器本地路由表。这时所有Pod发出的流量将通过Linux自带的路由功能进行转发，性能优异。Linux的路由功能也是大部分技术人员已经掌握的技能，理解维护起来没有任何负担。

　　在这一简化的模式下，controller-manager负责分配容器IP段，kubenet负责本地网络接口的控制，hostroutes负责路由。我们最大程度使用了Kubernetes已有的功能，并且用hostroutes来解决kubenet只管网络接口不管路由的问题。整个方案中，需要写入权限的仅有部署在master节点的controller-manager，运行在Node节点上的kubenet和hostroutes均只需要读取权限即可，增强了安全性。另外此方案将Kubernetes作为唯一的配置来源，去除了对etcd的依赖，简化了配置，降低了运维负担和安全风险。

　　kubenetkubenet是kubelet内置的网络插件中的一个，它非常的简单，会根据当前服务器对应的Node资源上的PodCIDR字段所设的IP段，配置一个本地的网络接口cbr0，在新的Pod启动时，从IP段中分配一个空闲的IP，用它创建容器的网络接口，再将控制权交还给kubelet，完成后续的Pod创建流程。

　　由于kubenet会自己管理容器网络接口，所以使用kubenet时，不需要修改任何的Docker配置，仅需要在启动kubelet时，传入–network-plugin=kubenet参数即可。

　　allocate-node-cidrs不同的技术方案虽说实现细节不同，allocate-node-cidrs是controller-manager的一个参数，当它和cluster-cidr参数共同使用的时候，controller-manager会为所有的Node资源分配容器IP段，并将结果写入到PodCIDR字段。

　　但是只要围绕着分配和路由这两个关键点进行比较，我们就可以更加明确的在不同方案之间进行选择。

　　容器网络技术方案选型推荐

　　hostrouteshostroutes是我们为kubenet开发的一个配套小工具，它也非常的简单，它会任何的技术方案都离不开场景，在这里我们根据不同的场景给大家推荐几种技术方案：

　　?2

　　?5种场景

　　容器网络技术方案选型推荐

　　?

　　单服务器：不需要网络组件，使用

　　Docker自带的网络即可

　　?

　　小规模集群：使用kubenet+hostroutes，简单、易配合管理

　　?

　　云环境中的小规模集群：使用kubenet+master组件上运行的网络控制器，充分利用IaaS所提供的VPC环境中的路由功能，简化网络配置

　　?

　　服务器不在一个网段的集群：使用Flannel提供的vxlan或者其他类似的Tunnel技术

　　?

　　安全要求高的集群：使用Calico或者OpenvSwitch等支持Policy的SDN技术

　　总结

　　在本篇文章中，我们探讨了Kubernetes的容器网络的工具方式，并以Flannel为案例分析了已有的SDN解决方案，并提出了适合小规模集群的kubenet+hostroutes的解决方案。希望可以帮助读者理清在Kubernetes集群搭建过程中容器网络这一部分的思路，不再因为容器网络影响了Kubernetes的整体使用。

　　在实际工作中，各个企业对集群的要求都有自己的特点，技术人员需要根据企业的需要，充分比较现有的各种方案的优劣，选择最适合的方案。直接照抄教程的搭建方式会为将来的运行埋下隐患，应当尽可能的避免。

　　?3

篇十四：容器网络流量研究教授

　（19）中华人民共和国国家知识产权局

　　（12）发明专利申请

　　（21）申请号

　　CN201710383829.8

　　（22）申请日

　　2017.05.26

　　（71）申请人

　　华中科技大学

　　地址

　　430074湖北省武汉市洪山区珞喻路1037号

　　（10）申请公布号

　　CN107241752A

　　（43）申请公布日2017.10.10

　　（72）发明人

　　辜希武;李瑞轩;王格;李玉华;杨琪;黄凤玲

　　（74）专利代理机构

　　华中科技大学专利中心

　　代理人

　　廖盈春

　　（51）Int.CI

　　权利要求说明书

　　说明书

　　幅图

　　（54）发明名称

　　一种感知网络流量的YARN调度方法及系统

　　（57）摘要

　　本发明公开了一种感知网络流量的YARN

　　调度方法及系统，包括：节点检测节点的网络流量，周期性地将网络流量发送给资源管理器，由资源管理器记录每个节点当前的网络流量信息，收到节点汇报的网络流量信息时，对这个值进行更新，在节点移除时，删掉该节点的网络流量信息；在应用向资源管理器申请容器时，为容器设置类型，以便资源管理器能识别容器的类型；在调度方面，根据当前节点与整个集群的网络流量

篇十五：容器网络流量研究教授

　基于XMPP协议的XML数据流压缩模型研究

　　齐铖;吴静

　　【摘

　　要】XMPP协议作为基于XML数据流的即时通信协议,可用于构建统一、高效的智能家居监控消息推送方案.针对XMPP协议存在的流量冗余较大的不足,提出了一种基于容器模型和BWT变换思想的XMPP数据流压缩模型.该模型通过对XML数据流的容器划分、前缀编码和预处理,在单次扫描数据流的基础上达到压缩率的最大化.实验证明,该模型方案能有效节约XMPP协议通信过程产生的网络流量,并具有可行性.

　　【期刊名称】《微型机与应用》

　　【年(卷),期】2016(035)001

　　【总页数】4页(P60-62,66)

　　【关键词】XMPP协议;流压缩;容器模型;BWT

　　【作

　　者】齐铖;吴静

　　【作者单位】西南科技大学信息工程学院,四川绵阳621010;特殊环境机器人技术四川省重点实验室,四川绵阳621010;西南科技大学信息工程学院,四川绵阳621010;特殊环境机器人技术四川省重点实验室,四川绵阳621010

　　【正文语种】中

　　文

　　【中图分类】TP391

　　在智能家居系统的应用背景中，通过手机等移动终端对设备进行远程控制、监测是基本需求。XMPP协议(ExtensibleMessagingandPresenceProtocol)是基于

　　XML的开放可扩展协议，用于在两个或多个网络实体之间进行结构化和可扩展的实时信息交流。将该协议引入智能家居控制领域，可以为异构设备群组成的家居体系提供统一的通信标准。但是XML格式数据流中大量的结构信息造成了较大的流量冗余，给移动控制终端造成了较大的网络流量消耗。因此，基于提高协议的运行效率、消除其流量冗余的考虑，应该对协议双方通信过程中产生的数据流进行有效的压缩[1]。

　　现有的XML压缩工具，如XMill、XGrind、Xpress等都是针对静态XML文档，对动态数据流的支持不理想[2]。王腾蛟等提出了一种XSC压缩算法，该方法借助DTD和字典压缩思想构建高效的索引完成对数据流的实时压缩[3]。张晓琳等提出了一种基于动态Huffman编码的XML数据流压缩技术，该算法利用XMLSchema和动态树结构进行编码，达到压缩目的[4]。本文根据XMPP协议数据流传输的特点，结合容器划分理念和BWT的思想，构建了一种基于容器模型和BWT预处理的非对称XML数据流压缩方法。该方法单次扫描数据流，不用借助DTD和XMLSchema等格式定义文档，并有较好的压缩效率。

　　1.1XML数据流压缩算法的原理

　　本算法针对实时传输的XML数据流，结合XML数据格式的特点，考虑将数据流中的相关节点利用SAX解析器解析形成触发事件流，并触发对应的处理程序，处理程序结合静态存储的字典，利用前缀索引编码将数据分别存放到对应结构的结构容器和对应内容的内容容器中，达到结构与内容分离的目的。然后，将分离的每个容器中的内容进行BWT变换的预处理，变换的目的是将容器内相关语义的编码尽量靠拢，减小信息熵，这样可以有效地提高对内容进行字典压缩的压缩率。

　　算法的整体框架图如图1所示。

　　1.2基于改进的字典编码的容器划分模型

　　1.2.1数据流容器划分思想

　　容器划分模型参考了标准XMill压缩器的思想，XML数据流经过SAX解析器后，数据流被解析成触发事件流，根据传输的XML流中的结构和数据部分触发事件的不同，将数据流中的结构部分和数据部分[5]按静态字典与前缀索引结合的方式进行编码，分别进行收集和压缩。考虑到XMPP协议是基于规范性和统一性格式的，即协议传递的数据包中的XML元素标签和属性标签是固定的，一段通信过程的协议格式为：

　　uid=1&devid=2&ordercode=3&ordervalue=34stream标签标志一段数据流的开始。、、元素称为XML节，每个节点下对应、、等属性标签，设置了一个消息片段的发送方、接收方以及消息实体等信息[6]。协议传输的XML数据流的元素/属性节点类型是固定的，因此可以在通信双方内存中构建静态字典，字典的键为自定义的索引标号，值为协议对应的XML元素/属性节点内容。在数据部分，数据以原始形态被分配到字符容器中。利用相应的压缩算法对每个容器进行处理。容器划分模型的流程图如图2所示。

　　1.2.2结构索引字典编码

　　一般常用的字典编码压缩方法，为了算法的实时性，往往选择动态构建字典的形式，这在处理大型的内容未知的静态XML文档时是一种较好的处理方式[7]。但常规字典编码方案在动态构建字典时会消耗较多时间。对于XMPP协议支持的通信双方

　　实时传输的数据流，基于协议结构节点固定这一特性，考虑采用事先设定好的静态字典形式，并在编码字典索引中加入前缀索引以便接受方快速定位每一个XML节中的信息体。通过上一节抓取的实际XMPP数据流阐述改进的字典编码步骤。该数据流展示了XMPP客户端test1向test2发送一段消息指令，内容为：“uid=1&devid=2&ordercode=3&ordervalue=26”。数据流经过SAX解析器后，由SAX的事件触发机制，将数据流按触发事件的不同分别引入元素、属性和内容三个容器中。

　　根据上一节所述，设定一个静态的结构字典，如表1所示，结构字典中包含有标准XMPP协议中定义的全部XML节。

　　根据表1所示的静态结构字典，可以方便地将数据流中的“结构信息”进行字典顺序编码并得到如下结果：0a1a1dff0b1a1b1c0b1a1b1c0c1a1b1c1d0dff0effff；通过对以上结果的分析可以发现，因为协议数据流中元素的嵌套结构较多，而“属性”结构通过简单的字典编码并不能确定其具体属于哪一个元素。因此，本文考虑在对数据流的结构信息进行基础的字典编码时，动态加入与其所属的元素对应的前缀索引信息，如表2。

　　包含前缀索引的字典编码按容器划分方法依次填入相关容器，以message节点为例，最终容器划分结果以及各容器中的数据如表3所示。

　　1.3BWT变换思想

　　BWT变换也称作块排序，是一种针对一个数据块的排序压缩方法，其目的是将数据块中出现频率较高、重复出现的数据段尽量整合到一起。其核心思想是对目标数据块中的内容进行矩阵变换。BWT变换本身并不会减小数据块的大小，只是改变了排序顺序[8]。根据信息论中关于信源信息熵的定义，将一个随机变量的熵表示为：

　　其中P(xi)为信源取第i个符号的概率。

　　根据数据压缩的原理，假设一个包含n个字符的字符串，每个字符的出现概率为p1,p2…pn,那么经过任何压缩算法后的二进制占位至少为：

　　+...式(2)的结果可理解为字符串的压缩极限：∑log2(1/pn)。可见，对于长度相同的数据，p决定了压缩极限的大小，p越大表明文件越有规律，其压缩极限越小[9]。根据实验可以发现，经过BWT变换的数据块，相同的字符会趋向于聚集在一起，信息熵比原始数据源小，因此有更小的压缩极限值。

　　BWT变换基于字符串矩阵的变换。假设输入的数据为字符串：“ABCACBBD”，使用BWT变换对该字符串进行预处理，步骤如下：

　　(1)构造N×N矩阵O，O中每一行是原字符串依次左移构成。

　　(2)对O矩阵中的行按字典顺序递减重新排列，得到矩阵O′。

　　(3)输出O′矩阵的最后一列以及原字符串在O′矩阵中的行数，即(L，index)=([DCCABBAB]，1)，可方便进行反变换以还原原字符串。

　　BWT变换将出现频率较高的字母排列在一起。以常规LZW编码为例，一段160B的数据的原字符串与BWT变换后的字符经过LZW编码后的压缩率分别为80%和71.25%，有明显提升。XMPP协议传输的数据流具有较多的重复字符，适合将BWT变换引入其中作为常规数据压缩前的预处理。在接收实体接收到经过BWT变换的内容后，根据前序查找的方法，以原字符串末尾为起始，可以还原字符串。

　　对上述容器划分模型在IntelCorei5/3.1GHz的PC上进行试验验证，运行环境为Windows7旗舰版操作系统。实验使用的服务器端为openfire3.9.3，使用的客户端为基于Smack开发包开发的模拟用户端。数据源为抓包软件采集的智能空调设备与手机App之间的监测、控制数据流。

　　通过表4对比可见，采用了本文所述的压缩方案后，网络中传输的一个完整通信过程所需的数据流大小与原始数据流相比有了明显减小。

　　模拟用户对智能设备进行控制并接收设备上报的监测信息，设备每10s上报一次实时数据，用户每分钟对设备发送一条控制指令。通过“科来”网络流量监测软件对一个时段内流经协议端口5222的数据流量在不经过压缩处理、经过基本LZW编码压缩处理和经过本文压缩模型处理后的统计如图3所示。

　　可见经过本文设计的压缩模型改进的服务器端，通信协议产生的网络流量与原始服务器和启用了默认LZW压缩方案的服务器端相比有了一定的减少，且随着时间的增加，流量节约更加明显。

　　本文针对XMPP协议数据流量冗余的问题，提出了一种使用于XML数据流的基于改进的字典编码的容器划分模型算法，该算法可以在不破坏协议实时性的基础上，对XMPP协议通信双方的XML流进行结构索引字典编码，分结构和内容分别进行压缩，同时针对信息体中重复字符较多的特点对信息体采用BWT编码预处理。实验证明，基于改进的字典编码的容器划分模型可以有效减少XML数据流的冗余，达到节约网络流量的目的。适用于需要长连接的智能家居检测、控制系统中。

　　齐铖(1990-)，通信作者，男，硕士研究生，主要研究方向：网络通信、协议分析。E-mail:152****************。

　　吴静(1963-)，女，副教授，主要研究方向：通信技术、三网融合。

　　【相关文献】

　　[1]刘涌，张彦功，梁崑涛.移动设备上XMPP功耗与带宽的研究[J].小型微型计算机系统，2013,34(2)：272-276.[2]钟世明，邵锐，张胜，等.基于位置服务系统中XML数据流压缩方法[J].武汉理工大学学报，2006,30(1)：29-32.[3]王腾蛟，高军，杨冬青，等.面向XPath执行的XML数据流压缩方法[J].软件学报，2005,16(5):870-877.[4]张晓琳，翟国峰，谭跃生，等.基于动态哈夫曼编码的XML数据流压缩技术[J].内蒙古科技大学学报，2007,26(4)：332-336.

　　[5]李瑞.XMLPre：一种基于预处理的XML压缩算法[D].西安：西安电子科技大学，2014.[6]周文琼，王乐球，周桐，等.基于XMPP的企业即时通信系统研究与应用[J].吉林大学学报，2010,28(1)：108-111.[7]许霞，马光思，鱼涛.LZW无损压缩算法的研究与改进[J].计算机技术与发展，2009,19(4):126-127.[8]王磊，孟昭鹏，刘亚琼.一种基于LFU置换的BWT压缩算法的改进[J].微计算机应用，2008,29(3):80-83.[9]邓宏贵，王晋秀，曹莉凌，等.基于BWT改进的LZW算法在传感器网络中的应用[J].传感技术学报，2008,21(6):1048-1051.

篇十六：容器网络流量研究教授

　2021年中国容器云市场研究报告

　　核心摘要：

　　容器的发展历史：容器技术在国内发展主要经历了三个阶段，分别是2014-2016年的技术探索期、2017-2018年的行业试水期以及2019年以后的规模应用期，容器与国内欣欣向荣的云计算产业发展紧密结合，为企业提供更高效的容器云服务。

　　容器云的企业价值：容器云架构的敏捷、轻简和高度兼容性使得容器成为云原生生态中最基础的一环，无论是混合云/多云在的推广还是DevOps、微服务应用的推进，容器都将扮演至关重要的角色，助力企业数字化转型和降本增效。

　　我国的容器云市场：我国云技术密集行业的头部企业已经对容器云的应用价值给予了肯定，目前的公有云市场上容器已经广泛地覆盖了20%~35%的虚拟化应用，预计2020年末基于容器的私有云系统平台市场规模将会达到15亿元。

　　容器云的应用展望：容器作为一种充满活力和可塑性的技术，其未来的应用前景非常可观。随着容器技术的不断发展，容器云将进一步赋能DevOps、微服务、无服务器等云原生应用的进步，更好地服务与网络服务、多云管理和边缘计算等场景。

　　容器云技术与应用场景铺陈

　　容器基础架构简介

　　借助镜像打包技术，容器得以便捷复制实现扩容

　　从内部架构上看，容器架构可被理解为一个高度精简的、独立运

　　行的程序包，其底层为BootFS（一种文件系统）用于接入宿主机的服务器操作系统；中层为镜像层，镜像层在程序运行的过程中不可改写，主要包含上层程序的代码和运行该程序所需的一切系统环境；上层为可改写的容器，镜像中代码的运行和结果的产生都在容器中进行，各个容器彼此独立。由于容器镜像文件大小较小，且包含程序运行的一切条件，可快速实现容器程序的复制，从而实现容器架构的弹性扩容。

　　以建筑为类比理解容器封装

　　容器是更轻量、更高效的虚拟机

　　如果以建房作比，土地对应计算机系统中的“物理服务器”，工程器械和建筑材料分别对应着“操作系统”和“环境配置”，而“程序代码”是一个应用程序的内核，类似房屋的设计图。使用虚拟机如同将操作系统、环境配置和程序代码一同打包从而部署到不同物理服务器上；而容器则仅仅打包环境配置和程序代码，部署到多个操作系统上。对于应用开发和提供商而言，下游客户通常已经具备操作系统环境，使用虚拟机再次打包操作系统会造成资源的浪费并降低程序运行速度。容器在提供虚拟化运行空间的同时减少了资源的调用，可以被视作更为轻量、高效的虚拟机。

　　集群管理方案使容器架构如虎添翼

　　Kubernetes(K8s)已成为容器编排的事实标准

　　在容器的企业级应用中，即便是提供单个服务往往也需要大量容器的共同参与，从而增加了程序运行的复杂性，对大规模容器的编排管理和程序故障后的排查溯源等需求催生了进一步统筹容器的工具

　　的需求，Kubernetes（K8s）在这一背景下应用而生。Kubernetes前身是谷歌的集群管理系统Borg，2014年谷歌将其开源并捐赠给Linux基金会。2015年专注于云原生开源技术的云原生计算基金会（CNCF）正式成立，Kubernetes至今仍是该社区最活跃、规模最大的项目。据统计，目前Kubernetes是全球最受欢迎的Docker集群管理工具，其使用比例远超其他同类软件，已经成为容器编排的事实标准。

　　容器技术与云计算的结合

　　更加弹性的云上资源，更加灵活的云上应用

　　云计算概念在2006年被提出，云计算发展的第1个十年是“市场的十年”，在这一时期云计算理念得到了广泛接纳，相关市场实现了从无到有、从小到大的高速增长；而云计算的第2个十年将是“技术的十年”，云原生技术将在这一时期得到深度的发掘和应用。Docker容器技术的发展正是这一时期到来的标志和推动力。一方面，底层云资源的容器化进一步放大了虚拟化时代的云计算已经具备的弹性拓展、按量付费的优势；另一方面，云上应用的容器化以更标准化和轻量级的形态赋予高效开发和部署以可能性。总的来说，容器技术与云计算的深度结合将赋能云计算的进一步技术发展和场景拓展，成为云计算市场增长的重要推动力量。

　　容器云应用在国内的前进步伐

　　经历前中期技术探索和行业试水，容器云市场稳步增长

　　Docker为代表的容器技术在2013年下半年之后在全球范围内得到了推广，而此后容器云在国内的推广和应用则大致经历了3个阶

　　段。2014-2016年的三年间Docker和K8s技术即便在全球范围内也都还不成熟，生态建设也不够健全，在国内信息技术市场上也还处于技术探索领域，同时一些云计算创新企业也开始将容器云产品化。2017-2018年期间，容器云技术和产品形态基本成熟，金融、能源等对云技术需求较强的行业开始试水容器云产品，这一时期市场资本对容器云产业的投入也有了显著的增长。2019年后，市场对容器云的技术认知基本成熟，容器云技术的应用领域继续扩大，生态建设更加成熟，容器云市场进入了规模化发展的阶段。

　　企业部署容器云的基本模式

　　企业普遍将容器部署在虚拟机云服务器上

　　尽管从理论上讲容器是较虚拟机更加轻量、敏捷、高效率的基础资源调用方式，也能够直接部署于物理机上并作为云资源的调度器，然而在当前国内乃至全球的企业用云实践中，裸金属容器（第5页左图中的容器部署方式）的运用仍然较少，究其原因，一方面是以虚拟化为基础的云架构已经发展十数年，构建起成熟的行业生态和标准，无法一时间转移为裸金属容器架构，另一方面，裸金属容器与服务器之间普遍缺少隔离层，尤其对于服务器资源共享的公有云而言，其安全策略也更加倾向于将容器部署在虚拟机上，而容器的高效封装和灵活迁移性仍然得以发挥作用。

　　容器云的功能及应用价值

　　兼具快捷轻量与强大功能特性的云计算基础设施

　　容器云技术为企业带来多方面的价值：Docker容器兼容Linux和

　　微软，并能够在AWS、Azure等多个主流云平台上跨平台运行，为企业上云和数字化建设提供了广阔的生态空间，并为混合云/多云资源调度和管理提供了便捷的渠道；容器精简小巧的架构使得企业通过容器云平台进行应用开发和服务部署的成本都大大降低，而应用分发和效率得到提高，随着DevOps理念的不断实践和微服务结构的发展，容器云将能够为企业提供越来越高效的应用管理；对于电商、金融、传媒等并发流量较为密集的企业而言，容器架构出色的弹性伸缩能力能够在最大化资源利用的前提下更好地应对高并发访问，为用户提供更好的使用体验。

　　中国容器云市场发展洞察

　　中国容器云市场及技术链图谱

　　供给端：国内容器云服务商优势各异

　　新兴云服务厂商更多专注于容器技术发展

　　从业务背景上看，我国容器云服务市场的参与者可以包括四类，一是在云计算领域拥有丰富资源和完整服务生态的综合云服务厂商，包括阿里、华为等，这类企业主要依托公有云市场上的优势，以容器架构为载体向用户提供有别于传统虚拟化架构的公有云服务，与之在业务领域上形成鲜明对比的是部分新兴的云服务厂商，它们主要服务于企业用户的私有云需求，同样为企业提供基于虚拟化或者容器架构的云平台搭建和云应用迁移等服务，这些企业参与容器技术的国内实践较早，相较于虚拟化技术更有相对优势。此外，一些IT服务供应商和具有互联网背景的云服务企业也纷纷在容器技术上进行投入，发挥

　　各自的优势，不断推动容器云的行业深化。

　　需求侧：我国容器云用户行业分布

　　容器云的下游用户主要集中在金融与互联网科技行业

　　我国容器云行业下游主要应用领域主要包含金融、互联网、运营商、制造业、政府和其他互联网+行业。其中金融业和互联网行业近年来对网络服务质量的追求较高，金融业有着雄厚的资本支持、而互联网行业对技术迭代更加敏感，是在容器云领域投入较多的两个行业。5G技术商用带来的高并发流量给运营商的网络服务能力带来了考验，目前国外已有运营商利用容器将5G核心网络云化，在国内云网融合的大背景下，运营商对容器云技术的需求确定性较高。此外，拥有广大用户群体的政务行业、不断向智能制造和物联网拓展的传统制造业以及伴随新兴技术发展起来的互联网+行业都对容器云有着相当可观的需求量。

　　公有云市场为容器应用提供广阔舞台

　　未来5年容器对公有云市场的覆盖率有望超过50%目前公有云在我国的云计算市场上占有较大比重（预计2020年约为67%），预计未来这一趋势将会持续，企业选择公有云服务，一般是看重公有云服务的标准化和灵活度以及丰富的产品生态。目前国内主要公有云服务商均推出了基于Docker以及Kubernetes架构的弹性容器服务及其相关产品，容器云服务的弹性和标准化特性对正符合企业对于公有云服务的一般需求。目前容器云（含部署在公有云虚拟机上的容器）在公有云服务中的覆盖率已经达到20%~35%，用户大多以

　　各行业的头部企业为主，随着各行业内示范效应逐步发挥，容器云在公有云市场上的渗透率将进一步提升，2025年有望超过5成。

　　私有云容器云平台市场高速增长

　　未来5年私有云容器云平台市场CAGR将达到33%在公有云市场上，容器技术尽管得到了非常广泛的应用，但其普遍作为公有云厂商提供基础云服务的底层平台，其本身并不向用户收费。而在私有云市场上，容器云与传统虚拟化各有千秋，已经成为云厂商为企业用户搭建私有云平台的重要基础构架构。得益于2014-2016年国内云计算以及容器技术的不断探索以及期间对容器应用的市场教育，近年来容器云应用得到了市场的充分肯定。2017年以来，我国私有云领域的容器云平台的市场规模呈现高速增长态势，到2020年末市场规模将超过15亿元，过去3年该市场的复合增长率超过40%，预计未来5年也仍将以33.4%的高增速持续增长。容器云市场的不断扩大意味着我国企业对容器技术的进一步接纳，也意味着以容器架构为基础的云原生生态将在国内市场不断繁荣。

　　容器云企业融资活跃度较高

　　容器云行业已进入规模化和集约化并行的发展阶段

　　近年来我国的容器云（私有云）企业在融资市场上保持着较高的活跃度，如前文所述，这类企业更加专注于容器云的技术拓展与应用创新，大部分在2015-2016年获得天使轮投资。随着技术的不断成熟以及市场的快速拓展，2017-2018年间市场资本集中加大了对容器云行业的投入，无论是容器事件的密集度还是单词融资的规模，较前两

　　年都有着显著的提高，显示市场对这一市场增长潜力的充分认可。这一方面是对我国的云计算行业，尤其是私有云和混合云市场的看好，也是对新兴容器技术应用前景的期待。2019年前三季度一级市场热度整体有所下降，资本主要流入了业务相对传统和稳定的行业，此后容器云企业的C轮以后的融资增多，规模渐趋稳定，容器云行业呈现规模化和集约化并行的发展特点。

　　容器云应用具备长期增长潜力

　　容器云为国内企业带来降本增效、生态支持等多重价值

　　调查结果显示容器云给我国企业带来的价值和增效主要体现在两方面，一方面是容器云技术本身的弹性伸缩、快速响应等优势给企业带来降本增效的成果，另一方面是由于容器提供的标准运行环境能够为多云管理和DevOps等云计算应用提供良好的生态环境。另有调查显示到2020年超过八成的受访企业已经开始使用或者计划使用容器云，说明容器云应用在我国受到广泛的认可、落地状况良好，未来云原生领域的技术进步将会进一步赋能我国企业的数字化转型进程，云原生应用的不断创新和丰富也会保障相关市场的良好前景。

　　发展趋势：完善产品生态

　　高效简洁、生态完善及混合云支持能力受到最多用户关注

　　随着容器云平台和容器云应用生态的不断发展，国内市场也逐步从技术探索过渡到规模化应用阶段，此时企业客户也对容器云产品及厂商的服务能力提出了多方位需求。根据艾瑞自主调查，企业客户对容器云（厂商）的服务能力和质量关注最多的是容器云的高效易用、云计算综合生态的完善程度以及容器对混合云/多云的支持。其中高效易用是对容器云产品本身的效用要求，而其余两点均体现了企业客户对全方位提升上云以及数字化转型水平的需求。值得注意的是，弹性伸缩、安全隔离等服务要素并非不具备重要性，而是市场上的容器云产品在相关领域的水准差异较小，因此受到关注不多。

　　云原生语境下的容器云应用展望

　　功能演进：逐步内生的安全防护

　　容器云的隔离性隐忧将随技术创新得到进一步改善

　　相较于软件领域应用历史更为长久的虚拟机架构而言，利用容器架构打包运行的程序不是运行在虚拟层（Hypervisor）之上而是直接与宿主机的操作系统对接，容器逃逸或夺取宿主机控制权的问题带来极大的安全隐患，这也是IT领域对容器架构应用的主要担忧。随着容器云技术的不断完善，由传统的容器架构带来的安全问题也不断在容器的内部架构设计上得到改善，得到应用的技术包括Clear-Container以及X-Container等。

　　功能演进：渐趋成熟的裸金属架构

　　裸金属服务器为容器提供更加理想的运行环境

　　目前为了兼顾容器的高效和虚拟机的安全稳定，业界往往是在物理服务器上部署虚拟机，继而在虚拟机上部署容器，但在如此架构下虚拟机层仍对服务器资源造成了不必要的占用，且虚拟机资源并不能完全被部署其上的容器利用，一定程度上抵消了容器架构的优势。为此，脱胎于“裸金属虚拟机”的虚拟化模式被逐步应用到容器领域中来，容器与裸金属服务器结合诞生了“裸金属容器”，在这一架构下，容器直接被部署于物理服务器上，这既是容器技术的优化创新，也是容器在产业领域应用的应有之义。

　　功能演进：K8s从CO走向OSKubernetes有望成为下一代虚拟化架构的操作系统

　　尽管K8s一直以来被认作是Docker容器的编排工具（ContainerOperation,OC），但如果观察云计算平台的架构，K8s已经成为了云原生领域事实上的“操作系统（OperationSystem,OS）”——2020年12月Kubernetes宣布未来不再继续推荐Docker作为容器运行时，标志着Kubernetes团队对于这一工具的定位有更高的期待。我们对PC操作系统的一般理解是连接硬件和软件、一面管理硬件资源、一面为软件运行提供环境配置的程序，如果将云计算环境下的底层虚拟化类比为传统的硬件设施、将云原生或者是迁移至云上的应用程序理解为传统的软件，则K8s在这一架构中的确乘载着操作系统的职能。不可否认的是，相比起Windows、Linux等计算机操作系统，K8s对于底层计算资源、数据信息等的管理能力是较弱的，在网络管理方面也还有很大的提升空间，这也是近年来CNCF的开发者在不断努力的方向。随着云计算领域对轻量和敏态的追求进一步提升、K8s对底层资源的管理能力持续加大，K8s在云计算架构中的地位有望进一步向底层延展。

　　技术联结：与微服务的不谋而合

　　容器云技术有效服务于微服务架构的松耦合理念

　　微服务的核心理念是将集成式的程序内部的不同功能模块拆分并独立运行，通过API连接来进行持续集成和持续交付。相对于传统的单体式架构，微服务的优势在于高度的颗粒化，使技术人员一次针对一个微服务模块进行开发和运维，在程序运行过程中也有助于实现资源的高效利用，这一理念与其后出现的容器架构不谋而合。当前微服务架构已与容器技术密不可分，每个微服务模块中往往就包含一个或多个基于容器架构运行的程序，在5G、边缘计算等领域这一组合将会有更多的应用场景和发展潜力。

　　技术联结：为DevOps坚实筑基

　　容器云架构保障DevOps实现的技术可行性

　　DevOps一词是“开发（Development）”与“Operations（运维）”两个词的结合，代表开发和运维流程一体化的一系列方法。DevOps的诞生和虚拟机/容器技术一样都是为了促进开发部门和运维部门之间的沟通、协作和整合，消除研发过程中的内部摩擦，从而提高网络服务的上线速度和服务质量。与虚拟机/容器技术相比，DevOps更是一种理念和文化，以“规划-编程-建设-测试-分发-部署-运行-监控-规划”的闭环构建企业级程序开发的良性生态，各个环节总计包含不下数十种工具，而Docker容器提供的标准化交付模式以及K8s编排搭建的容器调度平台正是DevOps的基础环境，DevOps的进一步发展和普及也有待于容器云技术的完善。

　　技术联结：和无服务器的相辅相成

　　容器与无服务器架构互为补充应用于不同场景

　　无服务器计算允许在构建、运行应用的时候不需要选择服务器配置或者管理服务器运行，其运行环境由云服务商统一提供。无服务器架构下的程序由一系列事件触发，计算资源只有在被触发时才被创建，对计算资源的空耗极低，利于企业进一步节约成本。由智能设备和物联网设备触发的偶发、非连续的事件在未来数年将呈现爆发式增长态势，为无服务器计算提供了充足的应用空间。一方面，基于微服务理念和无服务器架构的serverless容器技术逐步成熟，容器和无服务器架构的融合发展有巨大前景；另一方面，无服务器架构相对不适合需要长时间运行、或是加载大量数据的进程，该架构与传统容器架构能够互为补充，为企业和开发者提供更多部署云上服务的选项。

　　场景拓展：后疫情时代的线上生活

　　在线服务加速渗透生产生活，拓宽弹性容器用武之地

　　2020年初开始的疫情对我国经济和社会生活都造成了较为严重的影响，在导致交通阻塞、线下门店关闭的同时，疫情却也促进了互联网产业的发展，帮助我国部分互联网产业突破原有的天花板。疫情期间，互联网公司集中进行业务拓展，极大程度地培养了我国在线会议/远程办公、在线医疗和在线互动课堂领域的用户习惯，加速了相关行业的渗透，也进一步打开了网络游戏、直播、在线视频等网络传媒行业的市场。这些具有高并发性、需求弹性计算的互联网服务加速渗透我国社会生产生活，将为以容器云为代表的云计算产业提供更广阔的应用空间。

　　场景拓展：混合云时代的多云管理

　　多云环境下的数据沟通及应用管理由容器云平台构建

　　大型企业及对数据安全要求较高的企业选择私有云、中小型企业为节省上云成本使用公有云——这是目前我国企业上云最常见的途径。但若综合考虑成本优化、数据安全、业务性能和生态构建等问题，采用混合云/多云架构能够为企业的数字化建设带来更多助益。混合云/多云也是发达国家企业上云采用的最普遍的模式，可以预见将会成为我国云计算产业未来的发展方向。严格来讲，“混合云”强调公有云/私有云的结合、“多云”强调不同厂商提供的云平台的并用，二者在实践过程中面临的资源统一调度、数据跨平台传输等问题，而容器凭借其轻量标准化、跨平台运行的优势能够充当不同云平台之间的“外交大使”角色，以解决跨云环境下的各类协调管理问题。

　　场景拓展：万物互联时代的边缘计算

　　容器以轻量精简的结构乘载海量异构的边缘终端

　　进入万物互联的时代，智能手机、智能家电和智能穿戴设备大量出现，5G通信网络的普及更是使互联网数据的规模呈现指数级的增长趋势。传统的云计算采用的是中心化架构，数据从终端到云中心的传输和计算会造成高时延，从而降低网络服务的用户体验，这一模式已经越来越不适应网络流量爆炸的当下。边缘计算的程序在终端侧发起，能够有效降低时延，并提供更好的安全性、隐秘性和智能化体验。边缘计算场景通常具有短时、单个计算低负载和大量同质化计算的特点，而容器架构轻量、便捷移动和快速复制的属性非常契合边缘计算场景的需求，目前多家企业已经推出边缘容器平台，以容器技术赋能

　　边缘计算的进一步深化发展。

篇十七：容器网络流量研究教授

　容器和虚拟网络

　　佚

　　名

　　【期刊名称】《网络运维与管理》

　　【年(卷),期】2014(000)024

　　【摘

　　要】企业基础设施已经集成到一定程度，当你部署或重新配置一组资源时，很难不影响到其他资源。在服务器中的变化会给网络基础设施带来影响，而这可能需要新水平和类型的存储。在虚拟环境更是如此。

　　【总页数】1页(P7-7)

　　【正文语种】中

　　文

　　【中图分类】TP393.1

　　【相关文献】

　　1.国际虚拟网络社区涉华舆论特征及引导策略*--基于国际虚拟网络社区2013涉华舆论的实证研究[J],相德宝

　　2.自主创新全面提高PET包装容器的质量技术水平——在塑料中空容器行业联合中心PET包装容器技术发展研讨会上的发言[J],蔡明池

　　3.面向动态虚拟网络请求的虚拟网络映射算法[J],苑迎;王聪;王翠荣;宋欣;吕艳霞

　　4.轻量级容器化技术驱动的虚拟网络部署研究[J],曹含笑;陈海浩;梁梅群;谢恩慧;韦晓慧

　　5.基于vDPA的虚拟网络转发技术研究与优化[J],欧阳卓玥;邹素雯

　　因版权原因，仅展示原文概要，查看原文内容请购买

篇十八：容器网络流量研究教授

　（19）中华人民共和国国家知识产权局

　　（12）发明专利申请

　　（21）申请号

　　CN202010214685.5

　　（22）申请日

　　2020.03.24

　　（71）申请人

　　广西梯度科技有限公司

　　地址

　　530000广西壮族自治区南宁市洪胜路5号丽汇科技工业园标准厂房综合楼

　　（10）申请公布号

　　CN111371696A

　　（43）申请公布日2020.07.03

　　1516-11号房

　　（72）发明人

　　王伟华;梅进

　　（74）专利代理机构

　　东莞领航汇专利代理事务所(普通合伙)

　　代理人

　　高辉

　　（51）Int.CI

　　权利要求说明书

　　说明书

　　幅图

　　（54）发明名称

　　一种在Kubernetes中实现Pod网络流控的方法

　　（57）摘要

　　本发明公开了一种在Kubernetes中实现

　　Pod网络流控的方法，包括步骤1基于Kubernetes集群平台实现的Pod网络流控管理功能，步骤2启动“流控服务端”程序，连接到Kubernetes集群，步骤3通过容器云平台部署Deployment资源步骤4：在Pod运行的宿主节点之上，为Pod配置网络流量控制规则步骤5：判断Pod使用的容器网络类型，随后为Pod中的网

篇十九：容器网络流量研究教授

　基于容器技术的电子政务云平台的实现与运用

　　摘

　　要：

　　信息化与自动化是提高政府办公效率的有效手段,但传统的政务管理系统存在着业务模块耦合度过高、可用性差及运维成本高等问题。本文基于我国电子政务的现实特点,探讨了一种基于容器的云计算解决方案在电子政务服务平台中的应用。其框架为,政府机构将所有的信息化电子流程全面迁移云平台,在云平台的基础上将各个业务模块进行分离,降低各个业务模块的耦合度。此外将线上的模块全面容器化和标准化,达到一个在物理上是相对独立的模块。

　　关键词：

　　容器技术;电子政务;云计算;

　　一、绪论

　　电子政务是一种新型的基于计算机信息技术的政务工作平台,该平台以实现政务公开为目的,能提高政府的办公效率与服务效率。服务型电子政务的普及化体现着政府的服务与管理性质,更有利于政府进行高效管理。但传统的电子政务服务平台架构模式存在着许多缺陷,例如物理服务器数量巨大且分布零散,不适用于高并发、高性能、高流量的场

　　景中,无法将单台服务器的性能发挥到最优的效果等。近年来,随着云计算技术的不断进步,形成了许多成熟的落地解决方案。云计算技术的基本原理就是将许多物理计算机的计算能力和存储能力都集中起来,形成一个计算池,在此基础上再计算池中分割出所需要的业务模块进行部署应用,提供给各个服务模块使用,进而提供给用户。

　　随着电子政务概念的出现,云计算技术与服务型政府的结合越来越受到关注,构建了“政府云”和“智慧型政府”成为政治改革的主要内容之一。本文的研究目的旨在构建一个基于云计算技术的电子政务服务平台,该平台能通过虚拟基础设施向公众提供各种政府信息来源,从而实现政府信息资源的共享。

　　二、容器技术理论基础

　　(一)虚拟化相关理论基础

　　虚拟化技术指通过软件的方式将硬件资源同时提供给多个操作系统使用。该模式打破了传统的单台物理服务器上运行单个操作系统的瓶颈。通过虚拟化技术,可以显着提高物理设备的使用效率、减少电力能源消耗并方便进行资源的

　　统一管理与配置。

　　政府部门和企业对于大量数据的分析需求日益增强,而对海量数据的计算方式也由以往的单台服务器模式转变为为分布式计算的形式。现代的云计算服务是将许多物理服务器节点结合起来,组成一个高性能的计算集群。用户可以通过客户端按需要申请得到计算能力,避免了计算能力的空闲。云计算使得企业和政府部门的数据中心构建摆脱了传统数据中心的系统规划、系统开发、硬件釆购、系统实施与后期维护的构建模式。只需按照企业和政府部门的管理要求,提出数据中心的信息需求,通过高速互联网的数据作系统的内存,CPU或磁盘。这保证了容器内的进程不会影响到容器外的任何进程。

　　三、基于容器技术电子政务云平台的实现

　　(一)存储功能的实现

　　Hadoop分布式计算框架中为其提供文件存储的系统为HDFS,该系统的构建可以达到数据的低冗余和极高的安全级别。在很早以前的HDFS结构中,只有一个节点负责传输,便可快捷的获取云服务,使得企业和政府部门能够更加专注于

　　自己的核心业务和管理职能。

　　图1虚拟机与容器的架构对比

　　(二)Docker技术基础

　　容器类似于一个集装箱,容器与容器之间相互独立,容器内所存储的内容可以提前定制和预装,针对需要的内容提取对应的容器。这种系统架构模式能有效避免部署环境不同,版本不兼容的问题。

　　由于容器技术具有灵活便捷、可以自由编排、环境规范统一等特点,允许我们在资源隔离的过程中,运行应用程序和其依赖项的、轻量的、操作系统级别的虚拟化技术。运行应用程序所需的所有必要组件都打包为单个镜像,当镜像运行时,它是运行在独立的环境中,并不会和其他的应用共享主机操管理数据存储的元数据,容易造成当元数据的节点宕机时整个系统的瘫痪,因为此节点维护着数据最重要的元数据部分。其主要功能包括:(1)文件系统的索引树,能够根据

　　索引找到每一个数据块的位置并进行访问和读取。

　　(2)通过在保存数据节点的主机上寻找数据存放在存储空间的那个位置,然后由数据节点将位置返回给客户端,进而达到了数据查询的目录。

　　(二)网络功能的实现

　　面向服务的架构在很大程度上依赖于节点之间的网络架构。接下来,我们将从Docker的原始网络体系结构开始讨论Docker提出的多主动网络优化解决方案。在Docker中,默认情况下,网络接口是一个虚拟接口,可以随时向主机提供不同的工作端口的实现不同的手法效率。这是因为通过在网卡之间的虚拟接口需要分组数据,到发送缓冲器的发送接口被直接复制到内核接口接收器的接收缓冲器就是数据的拷贝,而不需要外部的物理网络设备交换。同一主机上的容器可以相互通信,并向邻近容器提供服务,而无需其他配置

　　(暴露或端口版本)。主机系统只将来自docker0的请求指向目的地。容器可能会将其端口暴露给主机以接收外部流量。易受攻击的端口可以通过专用端口映射到主机或由Docker映射到主机以选择随机空闲端口。容器可以将其端口发布到主机,端口发布端口映射以托管接口,以便它们可以与外部世界进行交互。易受攻击的端口可以映射到主机上的特定端

　　口,或者Docker可以自动选择高空闲端口。

　　图2网站系统架构示意图

　　(三)分布式计算的实现

　　分布式系统是基于网络之上的软件系统,分布式系统中的独立电脑通过网络相互通信、相互传输消息并协调工作。在分布式系统中,如果需要对数据进行大量计算,系统会先对数据进行分区,然后由若干台电脑各自计算完成后将结果上传,再对结果进行统一合并,得到最后想要的结果。当前分布式系统在进行数据计算时通常会调动全球各区域成千上万的志愿者电脑的闲置资源,借助互联网传输数据,以完成计算。所以使用分布式计算系统完成计算,不仅能够完成目标,而且还能节省费用、降低成本。

　　共享稀有资源和平衡负载是计算机分布式计算的核心思想之一。SparkStreaming作为Spark核心API的扩展,它具备容错机制,能够完成吞吐量高的实时流数据处理。Spark

　　Streaming的内部处理流程是,先接收输入的实时流数据,然后对数据基于一定的时间间隔进行拆分,形成批数据,再由SparkEngine对批数据进行处理得到结果。

　　四、基于容器的电子政务平台应用

　　(一)网站系统架构的实现

　　网站系统架构示意图2所示。Web服务是系统的一个主要组成部分,包含多个服务组件和调度服务可提供给用户。由示例图我们可以看到,将容器集中管理部署到一个云平台上,当客户端发起到服务器端的请求时,可以由前端的调度器均衡负载和调度,随后将请求调度给容器所代理的业务模块部署平台上。与此同时,前端模块也同时在接受其他任何用户的请求,这个过程是同步进行,并发进行的。如果docker模块容器发生错误或者异常时,可以由运维人员执行自动化运维脚本替换容器或者自动初始化容器,使之恢复到原始的状态。这种切换和恢复的过程对于客户来说是透明的,不可见的,客户无法感知这种变化。

　　(二)基于容器的网站服务系统设计

　　本文以在Linux6.4虚拟机上的部署环境来描述Web服务在Docker容器中的运行实现过程。首先,基于JAX-WS2.0框架,将Web服务运行所需求的各组件在新创建的Docker容器里进行部署。完成环境要求后将容器创建成镜像,登录Hub.Docker,在Docker的官方镜像仓库中找到由Tomcat官方所发布的Docker镜像。然后在linux命令行使用dockerpull命令,将Tomcat官方放在docker官方仓库中的镜像拉取到本地,并通过dockerrun命令将其启动为容器。

　　然后把服务部署需要的一些环境组件JAR包复制到刚刚启动的Tomcat容器里面来,然对Tomcat进行卷绑定,把宿主机上面的目录与容器里面的指定目录进行绑定。最后Tomcat容器实现端口映射,将Tomcat容器的8080端口映射到宿主机的6000端口上,专门用来处理Web服务动态请求的处理,最后在把Tomcat容器使用dockercommit–P–p8080:6000创建成我的web服务所需求的镜像。

　　为了以后对远程服务器上面的docker容器的方便管理,我们需要编写相应的dockerstart、dockerstop、dockerrestart的Shell脚本,来实现对容器的启动、关闭、重启的简单管理操作。再将Docker镜像包复制到准备运行Docker容器的linux宿主机中,并且将之前写好的shell脚本也部署在宿主机上,

　　做为对Docker容器的管理组件。编写完对服务的远程调用管理脚本后,对各服务进行服务注册,使用java语言的编写的服务注册组件来远程管理Docker容器。

　　五、结论与展望

　　由于使用中央云资源的优势,电子政务和云计算的结合是未来电子政务发展的总体趋势。电子政务云模型为电子政务向云提供理论解决方案,并遵循理论的解决方案。该方案的构建模式可以有效地结合电子政务系统和云计算本身的特点,认识到政府员工在云中工作,社交人士在云中享受一站式服务体验。基于模型的电子政务使命是未来发展的方向。本课题提出了一种新电子政务系统实现方式,描述了该模型的运行过程和运行机制,分析了这种新模式的优缺点,并讨论了创建这种新模型的必要性和可行性,富了云和电子政务技术的理论内容。

　　容器技术虚拟化技术已经成为一种被大家广泛认可的容器技术服务器资源共享方式,容器技术可以在按需构建容器技术操作系统实例的过程当中为系统管理员提供极大的灵活性。出现了一种称为容器技术

　　(Container)的新型虚拟化技术来帮助解决这些问题。

　　参考文献

　　[1]刘谦.面向云计算的虚拟机系统安全研究[D].上海:上海交通大学.2010

　　[2]李刚健.基于虚拟化技术的云计算平台架构研究[J].吉林建筑大学学报,2011,28(1):79-81.

　　[3]朱晓铭,汪卫霞.我国电子政务信息资源整合研究综述[J].情报探索,2011(3):69-72.

　　[4]JeongChunHai@Ibrahim.(2007).FundamentalofDevelopmentAdministration.Selangor:ScholarPress.ISBN978-967-5045-08-0.

　　[5]刘邦凡.电子政务建设与管理[M].北京:北京大学出版社,2005.

篇二十：容器网络流量研究教授

　CSDN流量东西扩展

　　CSDN流量东西扩展不断创新的技术带来了一系列好处，例如自动化、敏捷性和效率，提高了公司的生产率。但是，随着新技术的到来，漏洞和安全威胁也随之而来。尽管具有所有优点，但是容器化还带有一些漏洞，容器普遍寿命较短，迫切需要加强对容器环境安全性和合规性问题的研究与投入。此外，容器环境在默认配置下，其K8s底层网络是“全连通”的，即在同一集群内运行的所有Pod都可以自由通信。同时，由于容器平台体量巨大、上下线周期短、容器网络外部不可见等原因，平台的东西向网络安全问题往往难以解决。

　　CSDN流量东西扩展主流三种技术路线基础设施隔离\虚拟化层隔离\工作节点Agent隔离，主要采用通过在公有云、私有云、混合云模式下的工作负载安装Agent，采集工作负载之间的网络流量，以可视化展示网络访问关系，实现根据业务需求设置访问控制策略，工作负载支持主机服务器、虚拟主机、容器等节点模式。

　　采用链接跟踪（conntrack）技术方案采集容器间的网络流量，基于netfilter实现的conntrack机制以及procfs提供的进程信息分析。conntrack本身并不会对包进行过滤，而是提供一种基于状态和关系的过滤依据，只关注网络流量的基础数据。同时使用procfs提供的进程信息将进程和网络做了一个连接，从而达到所需的监控要求。

推荐访问:容器网络流量研究教授 容器 网络流量 教授