DaoliNet宣布开源，为Docker容器量身打造动态敏捷的可编程网络【内附PPT】-CSDN博客

本文链接：https://blog.csdn.net/amone/article/details/80123492

文/ 毛文波道里云CEO

【编者按】5月27日，DaoliNet开源项目发布会及国内Docker社群线下沙龙在北京举行。此次发布会上，道里云CEO毛文波博士将多年来精心打造的Docker网络技术DaoliNet无偿贡献给开源社区，他希望更多企业与开发者能够在实践中应用DaoliNet，并积极参与和贡献力量，共同推进其发展壮大。来自Docker公司中国区代表、国内数家Docker创业公司创始人，多位Docker创投资本、企业级用户代表、Docker/SDN/云计算技术大牛和社区领袖等悉数到场表示祝贺，并对Docker及DaoliNet的技术和应用发展做了激烈的深度探讨。当前Docker发展如火如荼，毛博士认为，“DaoliNet + Docker = 轻灵的CPU + 轻灵的网络 + 各司其职的控制 = 适合于PaaS的网络”，本文是他对DaoliNet的深入介绍，希望有助于大家作更深入了解，同时附上演讲PPT：DaoliNet开源为Docker打造动态敏捷的可编程网络，请下载查阅。

毛文波宣布DaoliNet正式开源

Docker正如火如荼！

为何如火如荼？我认为Docker容器管理平台向世人揭示了容器应用虚拟化本质所体现的轻灵性：身轻如燕，即用即建，打包交付！居然还有用毕杀掉一说！当然此说法不能是Build, Ship, Run …的信达雅翻译 :-) 。Docker通过管理容器说明了PaaS层须向上层SaaS用户提供支撑业务逻辑所需的能力服务，这不同于IaaS层仅提供资源类服务。容器轻灵的属性也在后续出现的容器管理平台编排工具（orchestrator）如Kubernetes，Mesos，Docker Swarm中得到体现，如Kubernetes体现的是在不同服务器上分布部署服务的高可用冗余备份，Mesos体现的是在服务器集群上智能地调度容器分布部署，而Docker Swarm则侧重标记容器的服务内容以便于服务发现。我们可以从这三个平台的不同侧重点看到它们都在设法让所管理的容器摆脱IaaS层的物理资源属性，让云服务带有更多的业务逻辑语意，让用户看到各种服务能力。除了众所周知的Web服务器，数据库，中间件等能力，PaaS层可以提供的服务能力还包括但不限于：利用IaaS建立的资源池实现弹性扩展Scale-out服务，动态异地容灾备份，安全监控，NFV（网络功能虚拟化）服务链（Service Chaining），防火墙，入侵检测，身份认证，等。而Docker还利用overlay文件技术巧妙地实现了提供业务能力组合的一个重要优势：组装各种能力后打包交付！

显然一般情况下Docker打包组装的PaaS能力不能仅跑在一台服务器上，Docker自出世伊始就在呼唤跨服务器网络连通方案，至今已出现了四种开源技术：

Weave: UDP Overlay封包，早期版本在用户态做，后升级至内核态VXLAN
Flannel: UDP Overlay，也有用户态UDP及内核态VXLAN两种版本 
Docker Libnetwork Overlay: 内核态VXLAN
Calico: 服务器跑BGP路由算法铺平三层连通

显而易见前三种是UDP封包的同质技术，我们都知道MAC-in-UDP封包显然既可连通网络又可隔离租户（其实提到网络隔离，PaaS不是要隔离租户，而是要在业务能力和物理资源之间实现解耦），而Calico是在一个铺平的三层网络中做BGP路由，利用了一个非标准做法：ARP欺骗（又叫ARP poisoning），容器内部cache的全部目的MAC地址皆为容器所在服务器的MAC，于是作为路由的第一跳报文就会从源容器到达Calico虚拟路由器，即源容器所在的服务器。

其实跨服务器连通容器并不难，让编排工具在服务器上配置UDP封包点（Weave, Flannel, Docker Libnetwork Overlay），或在服务器上部署虚拟路由器跑路由算法（Calico）即可。这些手段正是这些Docker网络方案的共性所在：都仅仅做到了整合网络作为资源（IaaS）属性的服务。与我们前面评论容器PaaS管理平台的编排工具Docker Swarm， Kubernetes， Mesos各自提供差异化编排服务形成了明显的反差，上述Docker网络方案虽然都能很好地为容器整合网络资源，然而我们看不到它们对PaaS业务能力体现出什么差异之处，即便在IaaS层做评估，这些网络方案都是对服务器Linux网络协议栈通过配置成为固定连通的资源性网络，而Calico则由于利用ARP欺骗直接把路由器的MAC地址写死到容器的ARP缓存中，造成容器（业务能力）被固定死在服务器（物理资源）上，也就是说连IaaS所需的逻辑物理解耦服务都荡然无存。而若在PaaS层能力服务方面评估，我们就更看不见这些网络资源整合技术怎样撬动了容器的轻灵属性，动态性，可封装性所释放的PaaS 力量，向PaaS用户提供支撑业务的能力。如果说容器编排工具Docker Swarm，Kubernetes，Mesos，甚至OpenStack，等都正在用非同质技术竞争容器管理，提供差异化服务，那么在网络方面我们没能看到差异化竞争也在这些Docker网络连通方案中发生。

DaoliNet是什么？

先简要叙述OpenFlow是什么。源于斯坦福大学的一个网络技术创新：网络的控制面与网络的数据面分离。为什么要分离？举个栗子：还在用古董版车载导航吗？先下载地图，听它指挥吧！如今咱们中国日新月异，马路拉链可不少，不被导航到沟里算你运气！下载地图就是一种控制面与数据面不分离的情况，陷在数据中的控制无法对应动态变化中的路况，导航不仅是不认识路，而是要知道那条路畅！路况是实时动态变化的，当然要听在线导航的，控制器，请下车！

请网络控制器离开服务器（路由器）和Docker网络有什么关系？关系真的很大！控制器离开服务器后，Docker对容器轻灵的管理不仅再是Orchestrator独家任务了，网络控制器也可发担起有的责任了！怎么讲？

这里举个例子：

当某服务容器被大流量访问时，按现有控制面数据面非分离的网络，基本处理思路是让被访问容器自己发现异常报告容器管理平台，管理平台部署异常处理措施，也可以让管理平台事先在网络底层部署监控，只不过这种事先诸葛亮的事不会太容易设计与实现。异常处理措施很可能需要加强额外容器兵力援助，这样的援助容器应该部署在异常容器的网络访问前方，那么对新容器进行网络配置是不可避免的。这样配置纯属IaaS网络做法，很可能需要手动配置，会很慢，也很容易出错。我们还要注意到容器是轻量级微服务的，在一个容器中既提供业务服务能力又准备异常检测发现，这是与轻量级微服务做法背道而驰的，想想Docker怎么对这样的容器打服务标签吧！

而OpenFlow控制器会在第一时间感知网络请求出现的异常状况，控制器可以为此状况部署若干新容器，在网络拓扑上将这些新起的容器部署到目标异常容器的前端，有的新容器对包做初步分析，如简单丢弃Syn flood，有的做深包检测，还有的可能要做入侵检测，是否发生了针对TLS/SSL的攻击？补充说明，针对TLS/SSL的若干攻击比如DROWN/Padding-Oracle/Lucky13攻击等，攻击者需要向Server发起大量的非正常请求，在现有的主流防火墙产品上想要灵活添加这样的检测规则是有难度的，而OpenFlow控制器却可利用SDN技术灵活添加检测规则，在攻击发生的第一时间就感知到攻击流量。容器的应用虚拟化轻灵性可以让OpenFlow控制器动态部署所需的新容器快速实现应急处理。

图片描述

图1 DaoliNet的架构图

图1是DaoliNet的架构图，体现了DaoliNet网络控制器在PaaS平台中与容器编排工具各司其职分担责任的逻辑构造。在管理容器生命周期方面，编排器已经不是一个人在战斗了，网络控制器也加入了战斗行列，而且还是个高效得力的战友！

总结

DaoliNet的独到之处：抓住Docker容器的轻灵性，让网络控制器介入容器生命周期管理，提供满足应用策略的，支撑业务逻辑的PaaS能力属性服务，而非停留在提供IaaS层面资源属性服务。

DaoliNet + Docker = 轻灵的CPU + 轻灵的网络 + 各司其职的控制 = 适合于PaaS的网络。

致谢

感谢白小勇，黄晟与我就PaaS网络与IaaS网络的本质性不同做了深入讨论，这些讨论对我的工作产生了重要影响。在DaoliNet开源发布会上中油瑞飞同事提出Docker平台对企业级信息系统应用套装软件（如SAP，Weblogic等）的适配支持问题，以及如何使用DaoliNet解决企业应用在云环境中的结构化网络部署问题，很值得深思，在此感谢。

注：DaoliNet发布会上，毛博士演讲内容请点击【PPT下载】