第三阶段是使用 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
五、容器网络选型
-DPDK
-https硬件加速
-单容器单IP,可路由
-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,一个容器的调度方式.
- 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
（编辑：源码网）
【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!
