携程：我们是如何利用容器实现快速弹性伸缩的？(2)

携程除了容器之外的东西都是用 OpenStack 来管理的,OpenStack 可以用一个模块(nova-docker)来管理容器,携程在 OpenStack 方面有多年的二次开发技术积累、也大规模的部署运维经验,但最终没有选用 OpenStack,因为 OpenStack 整体过于复杂,调度效率也比较低,API 调度是 10 秒以上,可以进行优化,但我们觉得优化代价太大,OpenStack 整体的复杂度也很高；

我们早期的胖容器(把容器当 vm 来使用,做代码包发布)的确是用 OpenStack 来做的,原因是我们希望把注意力放在容器本身,以最低的代价将容器先用起来,积累开发、运维经验；

而到了瘦容器阶段(基于容器镜像做发布),我们发现 OpenStack 整体的设计理念从本质上讲还是为虚拟机隔离粒度的虚拟化方案设计的,而容器本身与 vm 其实差别很大,玩法也相去甚远,于是我们对 Mesos/K8s 进行评估；

回顾我们的容器调度探索之旅,基本上可以用以下三个阶段来总结:

1. 第一阶段,需要最快的使用起来,用最熟悉的技术来解决部署和调度.
2. 第二阶段有新的需求,引入 mesos 和 chronos,提供分布式 cron? job 调度.
3. 第三阶段是使用 Python 重新实现 chronos,并且单独实现了 CExecutor 等组件.

   图3

   OpenStack 用于管理 bm/vm 是很合适的,并且在网络方面有很成熟的支持,无论是 vlan+OVS 还是最新的SDN 都能适配,尤其各大厂商的支持力度都很大；这也是为什么我们虽然不用 OpenStack 调度容器,但容器的网络其实还是用 neutron 来管理的；

   2、K8S

   K8S?有很多很先进的设计理念,比如有 replication? controller/Pod/Yaml?配置管理等,但这些理念在携程都很难落地,因为跟现有的运维模式、发布流程有较大的冲突.

   而且当前还缺乏大规模部署案例,网络尚无比较成熟的方案,例如 L4/L7 负载均衡; 而在携程 L4/L7 服务已经比较成熟稳定,并且与我们现有的发布系统Tars集成得非常好；

   3、Mesos

   Mesos?和 K8S?解决问题的思路是不一样的,基于?Mesos?我们可以非常容易的开发出适合我们场景的调度框架,并且非常容易和我们现有的运维基础服务对接集成；包括 L4/L7 负载均衡、发布系统等；

   图4

   五、容器网络选型

   • Neutron+OVS+VLan

   -DPDK

   -https硬件加速

   -单容器单IP,可路由

   • vxlan+SDN? controller

   -vxlan offload TOR 解封装

   Neutron+OVS+VLan,这个模式非常稳定,对于网络管理也是非常的透明的.这也是携程的选择,现在的网络无论是胖容器还是容器轻量发布都用这种模式.我们也在测试?DPDK 和 https 硬件加速的效果.

   我们也评估过类似 flannel 的网络,要求每个物理机独立网段,通过这个特性来做路由；非常不灵活的一点是容器如果迁移到另外一台物理机就需要换IP,无法满足我们的需求；

   接下来会走 vxlan+?基于BGP EVPN协议自研轻量级 SDN?controller 的路线,vxlan?offload?TOR 解封装提高性能；对于 OpenStack 可见的还是大二层网络(vlan),而实际上是通过 underlay 的三层路由进行转发；openstack与我们的控制器能实现元数据的一致性；关于这块,后续我们也会有相应的分享单独进行探讨；

   如何配置容器网络

   图?5

   如图?5?用dwait 和 dresponse,基于?Go 开发,dwait 会通过?unix socket?请求外部服务dresponse?做容器的初始化.当这个容器起来的时候,它的网络没有那么独立,在 Docker 里面是需要依赖外部提供信息的,所以需要知道哪个网段或者说创建的?neutronport?再配置到 Docker?容器内.这样做后就不会有网络丢失的情况.

   六、Docker遇到的问题

   接下来分享一下我们碰到的一些比较经典的Docker/Mesos相关的问题

   1、Docker?Issue

   图?6

   在我们尝试使用?Chronos?跑?cronjob?时,由于我们的?Job?执行频率非常高,导致物理机上出现非常频繁地容器创建和销毁,容器的创建和销毁比单个进程的创建和销毁代价大,会产生很多次内核的调用,磁盘的分配销毁,这对内核是一个非常大的压力考验.

   我们在实际操作过程中就遇到了一个?bug,如图?6?这台机器逐步失去响应,产生了?kernel soft lockup,慢慢的导致所有进程都死锁了,最终物理机重启了.为了避免频繁创建销毁容器,我们没有在?Chronos 这种一个?task?一个容器的路上继续走下去,我们自己研发了?mesos framework,改成了一个Job,一个容器的调度方式.

   2、Mesos?Issue
   • running 的容器数量较多以后,无法再启动新的容器kernel.keys.root_maxkeys debian default 200,centos default 1M
   • mesos docker inspect?执行低效,尤其是单机容器数量大
   • MESOS_GC_DELAY:6h 20K->1h
   • MESOS_DOCKER_REMOVE_DELAY 1m
   • docker force pull false
   • API?性能差,功能不完善,获取异步 event 困难
   • overall,很稳定,调度性能足够

   Mesos??性能很稳定,基本上不需要修改?Mesos?代码,只需要在我们自己写的 Framework 进行控制调度,控制如何启动容器.

   3、CExecutor

   （编辑：ASP站长网）