东京OpenStack峰会归来：与容器云结合新的思考
编者按：高可用架构分享及传播在架构领域具有典型意义的文章，本文根据杨保华博士的分享记录。转载请注明高可用架构公众号ArchNotes。
杨保华
IBM研究院高级研究员，主要研究领域包括云计算、分布式系统、网络与虚拟化、数据分析等。他领导了多个云计算项目架构设计和实现。作为开源技术的拥护者，积极参与开源社区活动。是DockerPool开源社区的发起人之一。著有《Dockter技术入门与实战》、《OpenStack项目源码分析系列》、《软件定义网络》
背景
高可用架构已经不少文章讨论使用容器技术的宝贵经验。今天我主要讨论 OpenStack 这样一个 IaaS 平台，聊聊它面对容器技术，特别是 Docker 所出现的一些新的项目和进展。
可能有人觉得，现在容器云这么热，OpenStack 这样的传统 IaaS 平台是不是有点过时了？目前新兴的容器云，从功能上看主要有两类：一种是直接托管一个（系统）容器，让用户自己访问并管理，看到的是一个系统；另一种是用（应用）容器托管应用，用户只提供代码，看到的是部署好的业务服务。后者是典型的 PaaS 场景，也有很多优秀的开源项目，但实际上很多企业业务在往 PaaS 上迁移的过程中挑战比较大，今天不展开这个。至于托管容器方式，在用户体验上，其实跟托管虚拟机很类似。现在已经有一些云，开始提供所谓的虚实例（Virtual Instance）允许用户访问和操作，很多场景下，用户并不知道也不关心底下是容器还是虚机，更关注的是业务稳定性和性能。
既然需求类似，那么传统 IaaS 要考虑要解决的很多问题，容器云迟早也会碰到，比如多租户、比如扩展性、比如安全……现有容器集群管理工具毕竟还不太成熟。实际上现在不少人在讨论和实践，先在下面搭一层 IaaS，然后再装一层容器平台。有人可能说，我自己部门搭建的容器集群没考虑这么多问题，也跑得很好。确实如此。私有云为什么好做？因为它很多时候需求都比较单一，规模也相对小。现在很多客户想搭建私有云，找供应商的时候，要先看你公有云做得咋样。因为他们知道，敢做并且能做好公有云的，去做私有云方案，技术上往往不会有大问题。所以无论企业现在有没有部署 OpenStack，都值得了解下，看看考虑了分布式、松耦合、高可用等等很重要的特性之后的 IaaS 应该怎么设计。
Nova-Docker 项目的定位和现状
OpenStack 之前面向的主要对象就是虚拟机，主要是 Nova 项目在负责，实现上是调用 Libvirt 这样的驱动库。很自然的，Nova 可以加插件直接调用 Docker 的 API，把虚机替为容器，都作为 Nova Instance 来管。基本逻辑如下图所示，用 Docker 替掉了虚拟机。
图1
这样做好处很多，可以直接利用 OpenStack 里面包括网络、存储、用户管理和认证等等服务，整体性能也不错。但问题也有不少。比较大的，计算节点只支持一种 hypervisor 类型；缺乏镜像管理；缺乏针对容器的监控；不支持迁移调整等；缺乏网络控制等等。实践来看，直接基于 Nova-Docker 做容器云的话，要做好大量二次开发的准备。其实社区是讨论过的，希望添加一些针对容器的特性进来，但是 Nova 这块项目整体历史包袱（过于成功）比较大，进度比较缓慢。所以后来干脆另起一拨人，搞了个 Magnum 项目，口号直接就是 Container as a Service。
Magnum 项目的介绍和性能评测
Magnum 是另一种思路，既然 OpenStack 已有很多很好的特性都是针对虚拟机的，能不能保留住，基于虚拟机这一层往上建容器云？基本思路就是用 Nova 管好虚拟机这一层，在虚拟机这一层上部署现成的一些容器集群工具，比如 Swarm，Kubernetes，以及 Mesos/Marathon，来构建一个容器云。Nova 不用改动，现有容器集群工具也不用改动，看起来皆大欢喜。基本的结构如下图所示。
图2
用户可以比较方便的申请到一个容器集群（一个 bay），然后自己来进行管理。资源模型上借鉴了 Kubernetes 中概念，比如 Pod，RC 等等。实际实现上是调用了预先编写好的 Heat 模板，使用预先配置好的虚机镜像，一个创建 API 扔过来，Heat 把各个虚机一起就 OK 了。这样做的好处很多，用成熟的虚拟机这一层来松耦合上层的容器服务和下层的基础架构服务，两边的好处都能兼顾到；并且以后进行扩展都很容易。
主要的问题也比较明显，首先层数太多，性能就是个问题；而且要整合已有的不同的容器集群接口，来提供统一的容器服务 API 也比较困难。特别是网络这块，因为 Neutron 已经是提供了一套 Overlay 网络，而有些容器集群方案自己又搞了一套，两套直接复用的话，容易造成不小的性能损失。比如下图，两个跨节点的容器之间的访问路径，可能会变得非常长（大家可以自己数一数一共要多少跳）。
图3
我们测试了不进行任何优化的情况下，直接引入两层 Overlay 后容器性能的下降。先看下吞吐量的降低，下降了 85%。
图4
再看时延，增加了 45% 多，突破了 1ms 这个重要关口。
图5
虽然这只是比较简单的比较，但也说明目前这种看似灵活的模式是比较有问题的。根子上的原因就是设计系统的人跟设计应用的人彼此交流不够、出现了配合不合理的地方。后面要讲的 libnetwork 和 Kuryr 项目就是希望能缓解这个问题。
容器与 OpenStack 的新进展： Libnetwork 与 Kuryr
从 1.7 版本开始，Docker 把网络跟存储这两部分的实现都以插件化（Pluggable）形式剥离出来。这也是 Docker 希望构建围绕着容器的一个完整生态系统的一些很好的尝试。剥离出来的独立容器网络项目叫 libnetwork，从名字就能看出来，它希望将来为不同容器定义一层统一规范的网络标准接口。libnetwork 中容器网络模型（Container Networking Model）十分简单，可以看出做应用的人对网络服务的理解和需求。
图6
简单说一下，sandbox 就是指容器的网络空间；endpoint 就是网络上的接入点；network 就是连接多个 endpoint 的网络。具体你网络拿啥技术实现，彼此怎么隔离，有没有 QoS，都不关心。只要插件能提供接入点给我，我只管把容器给接上、拔下，剩下的都是插件驱动自己去实现，这样子就比较灵活。基本过程如下面流程图：驱动注册后，先创建网络，再创建接口，然后把容器连接到接口上；销毁则是反过来。
图7
目前驱动类型有四种：Null、Bridge、Overlay、Remote。简单说：
1.Null 就是不提供网络服务；
2.Bridge 就是 Docker 传统上默认用 Linux 网桥和 Iptables 实现的单机网络；
3.Overlay 是用 vxlan 隧道实现的跨主机容器网络；
4.Remote 是指定外部实现的方案，比如自己有一套 SDN 的方案，就可以接进来。
很自然就能想到，Neutron 就是一套 SDN 方案，能否接进来？如果真能实现，以后容器集群直接跑在 Neutron 管理的虚拟网络上，性能会改善；同时 Neutron 提供的各种高级服务（LBaaS、FWaaS、VPNaaS 等）也都能直接用了。于是 OpenStack 社区新成立一个项目，叫 Kuryr，试图让容器以 Libnetwork 网络插件的形式，来使用 Neutron。实现上，主要是遵循 libnetwork 的流程，在绑端口的阶段，把容器接到 Neutron 实现的虚拟网口上。支持 Baremetal 和 VM 两种类型。
图8
Kuryr 项目刚在最新的 Liberty 版本（2015 年 10 月）中提出，预计到明年上半年能基本实现功能，大家可以关注下。或许有人觉得 Kuryr 在 baremetal 情况下跟 Nova-Docker 很像。网络上确实很类似，但本质上已经不同了。实际管容器的集群管理工具可以是 Swarm、Kubernetes、Mesos 中任意一种，只要它支持 libnetwork。另外，还有一些其它跟容器相关的项目，比如 Kolla 是将 OpenStack 自身的服务放到容器中运行；Heat 也支持直接部署容器，这里不再赘述。
总结与东京OpenStack峰会见闻
从 Nova-Docker、Magnum 到 Libnetwork、Kuryr，能看出传统 IaaS 对容器技术的积极态度和极大热情，能看出面向应用的技术遇到面向平台的技术，产生的冲击和取舍，能看出在云的时代，技术应对新兴需求而出现的敏捷变化。个人认为，如果没有成熟的底层方案，是没法很好支撑上层各种大规模的（容器）服务和平台的。
最后，谈一下今年的 OpenStack Summit 的一些见闻。本次峰会是 10.27 ~ 10.30 四天，在东京的品川站附近召开，6000 多人参会，主要分报告、design summit 两种活动。报告就是几个人讲，下面大家听；design summit 是对某个特定项目感兴趣的成员，找个小房间一起讨论交流。最大一个感触是容器和网络相关的话题真的很热门，特别是容器技术，很多项目都在积极讨论如何支持。说明大家都意识到要跟着应用需求走。
另一个是 OpenStack 现在的主要项目代码已经开始（趋于）成熟和稳定，不再着急加新功能了，而是把已有功能做好做稳定，并开始关注运维的一些问题。云里面，运维肯定是重头戏。还有就是 OpenStack 现在评审项目放宽松了，采取大帐篷（Big Tent）的模式，新项目不需要再经过孵化阶段，直接就是正式项目。Summit 更多内容分享也欢迎查看我的博文：。
Q&A
Q1：针对我们应用方，建议使用的成熟稳定的容器网络方案是什么？
猜测问题问的是私有环境下用容器做应用服务托管。如果比较在意性能，短时间内还是推荐打通容器层网络到物理层，直接在硬件设备上进行转发和路由。可以考虑用 vlan 来进行一些简单的隔离。长期规划，建议关注下 SDN 的一些方案。
Q2：目前创业公司都是使用公有云，如果要搭一个容器云，采用何种方案合适？
创业公司往往规模不大，如果非要自己搭建私有容器云。比较推荐从 Swarm 和 Kubernetes 开始入手，规模比较大了以后可以结合 Mesos。
Q3：有个观点说，把物理机加上虚拟化软件，上层再用 Docker，虚拟化管理软件也许没有存在的必要了，这个您怎么看？
如果所提到的虚拟化软件指的是 Xen 或者 Kvm 这样的 Hypervisor 层，短期内仍然是需要有一套管理它们的机制的。
Q4: 分享提到网络存储，Magnum也使用Openstack的存储吗？Ceph 呢？能否说说？
Magnum 里面虚机镜像、容器镜像都可以用 OpenStack Glance，可以支持 Ceph。另外，社区也在加强对 Cinder 的支持。
Q5: 容器虚拟化之后，极大的提高的运维的效率，会不会给未来运维的工作重心带来变化？
是的。一个重要的趋势将是促进 Dev 和 Ops 相互靠近；Ops 需要懂业务。另外，运维自动化程度会大大提高，脏活苦活累活会减少，但需要学习不少新的技术。
Q6: 请教个问题，关于云中应用 Lifecycle 自动化，Murano怎么看？趋势如何？
Murano 定位做 Application Catalog，这点是没问题的。只是目前实现上过于依赖 Heat，暂时持保留态度。
Q7: 层数多的情况下，跨节点的容器之间的访问路径过长，如果中间某个环节出故障，它是怎么恢复的？
得看具体情况，出在哪个环节，故障是啥。一般的，越靠下面的问题，越难恢复，比如最底层网桥的流表规则出了问题，就很难排查。
Q8: 为什么不从 OpenStack 入手搭建私有云？是因为太重了吗？
一个是 OpenStack 确实比较复杂，从很多做 OpenStack 云的公司中工程师队伍的规模就能看出来；一个还是要看具体的业务需求。如果确实需要提供 IaaS，那么，OpenStack 的社区运营地十分优秀，选择它可以降低长期风险。
本文策划及审校庆丰、编辑Jsy，转载请注明来自"高可用架构(ArchNotes)"微信公众号。高可用架构聚焦互联网架构分享，咨询投稿或报名分享请回复“speaker”。