各大公司容器云的技术栈对比

重温战场

　　郑昀编著于2015/10/20
　　目前来看，几家历史包袱较重的公司都选择不让上层应用感知到底层是 VM 还是容器，所以都改了 docker 内核，如360、点评、汽车之家。最后附上我们的容器私有云技术栈以及系统截图。
　　点评容器技术栈

• 　　2014年启动基于 docker 搭建私有云，之前谈不上使用过私有云
  
• 　　运维工具：Puppet
  
• 　　NATS+Nginx+Zookepper：
  
  
  
  • 　　组件之间的交互使用了 NATS，通过消息的『发布-订阅』模型，将各个组件之间的耦合最小化
    
  • 　　对于Web类型的应用，通过和 Nginx 暴露的 Restful 接口交互，完成实例在集群内的注册以及注销。对于服务类型的应用，通过在 ZooKeeper 上注册和注销服务IP和端口，便于服务客户端发现和更新该服务
    
  
  
• 　　技术改造：
  
  
  
  • 　　由于不愿意让技术人员感知到从 KVM 到 Docker 的转换，所以做了不少工作（注：主要还是不愿意影响原有业务和发布流程）
    
  • 　　更改了 Docker 底层代码，让其从推荐的微服务架构演变到目前的『虚拟机』架构。开发和运维可以通过 IP 直接访问到 Docker『虚拟机』，基于IP的应用基础架构也不需要开发和运维做剧烈的改变
    
  
  
• 　　使用情况：
  
  
  
  • 　　基本上除搜索和数据库以外，点评现有的业务大多都有跑到容器上的
    
  
  
• 　　监控改造：
  
  
  
  • 　　通过收集 CGroups 和容器实例的实时信息，将内存、CPU、网络等源源不断地上报到 CAT，再由 CAT 提供查询，检索和展示。也可以做报警
    
  
  
• 　　组网：
  
  
  
  • 　　Bridge Networking 工作在 level 2 的模式，使公共 IP 得以暴露出来，这部分是做了定制的
    
  
  

　　360容器技术栈

• 　　运维工具：集群变更用 Puppet（master/slave）
  
• 　　持续集成：jenkins（master/slave）+mesos+marathon+zookeeper
  
  
  
  • 
    
    
  
  
• 　　技术改造：
  
  
  
  • 　　docker 底层改造
    
    
    
    • 　　能够设置 btrfs 磁盘限额，网络限速，IO 限制
      
    • 　　容器独立IP
      
    • 　　容器内多进程
      
    
    
  
  
• 　　registry V2
  

　　一些优化细节：

• 　　利用 Jenkins master-多个slave 缩短构建时间：
  
  
  
  • 　　分布式提高 build 性能
    
  • 　　slave 记忆利用 cache
    
  
  
• 　　利用 btrfs 和 ssd 缩短构建时间：
  
  
  
  • 　　devicemapper 换成 btrfs
    
  • 　　sas 硬盘换成 ssd 的
    
  
  

　　UCloud容器技术栈

• 　　docker版本：1.1.1，1.8.2
  
• 　　发行版：centos 6.x
  
• 　　k8s版本：1.0.6
  
• 　　实践经验：
  
  
  
  • 　　docker日志：日志打印耗费性能，最好关闭 logdriver，将日志打印在后台
    
  • 　　docker daemon：centos 6.3 service stop 耗时长，需要5分钟，是 init-scripts 的 bug
    
  • 　　docker网络：
    
    
    
    • 　　NAT模式下会启用 nf_conntrack 造成性能下降，可以调节内核参数
      
    
    
  • 　　合理设置 ulimit
    
  • 　　docker镜像：
    
    
    
    • 　　制作镜像时，commit 的信息要简单明了
      
    • 　　编写 dockerfile 规范，减少镜像层数，基础部分放前面
      
    • 　　分地域部署镜像 registry
      
    
    
  
  

　　汽车之家容器技术栈

• 　　docker版本：1.6.2
  
• 　　linux发行版：centos 6.4 kernel 3.10和4.0
  
• 　　registry V2
  
• 　　构建：
  
  
  
  • 　　有单独机器做构建
    
  • 　　基于centos:7+systemd+zabbix
    
    
    
    • 
      
      
    
    
  
  
• 　　Docker Hub
  
  
  
  • 　　Docker Registry 2.0
    
  • 　　Registry 本身不能够高可用，Nginx 负载多个 Registry
    
  • 　　使用网络存储共享镜像
    
  • 　　配置 Mirroring，获取官网镜像
    
    
    
    • 
      
      
    
    
  
  
• 　　Docker应用-网络问题
  
  
  
  • 　　Docker 目前提供的网络模式不适合业务环境
    
  • 　　--iptables =false
    
  • 　　修改 Docker 内核改成静态 IP 模式
    
  • 　　IP 是通过容器名字为标识从 IP Pool 获取
    
  • 
    
    
  
  

　　蚂蚁金服PAAS docker提到的迁移问题

• 　　老应用迁移的痛
  
  
  
  • 　　谁来写Dockerfile并制作应用镜像
    
    
    
    • 　　蚂蚁线上已经有上千应用，几千开发人员，很难一下推动他们都学习  docker，切换到新的研发模式下
      
    • 　　如果需要开发人员写 dockerfile，会影响推广效率
      
    
    
  • 　　蚂蚁原有的运维/监控/SCM/财务等系统都是以 vm 为纬度的
    
    
    
    • 　　基于 docker 的运维发布系统与原有系统对接比较麻烦
      
    • 　　以往运维都是先申请一批机器，测试网络正常后备用，上线前再决定跑什么应用
      
    • 　　发布应用不重启 vm，所以也不希望重启 container；
      
    
    
  • 　　怎么尽量保证开发测试环境与生产环境一致
    
  
  
• 　　应对策略
  
  
  
  • 　　开发辅助工具帮助研发同学编译应用/自动生成 dockerfile/制作镜像并搭建测试环境
    
  • 　　把 CAAS 当作轻量级的 IAAS，让运维把 container 当作轻量级 vm 用，便于和已有系统对接
    
  
  
• 　　使用通用的 sofa4/sofa3 container，可以不需要制作应用镜像
  
• 　　在基础镜像中集成 sshd，运行运维 ssh 到 container 中
  
• 　　使用 supervisor 启动应用和相关监控/运维 agent
  
• 　　提供 webconsole 允许开发人员登录 container 查看日志/进行一定权限的 操作
  
• 　　使用 data container 避免本地 mount
  

　　最后列举一下我们技术团队的容器私有云技术栈
　　截止到2015年9月，窝窝容器管理集群的技术栈包括以下内容：

• 　　mesos（资源调度）
  
• 　　marathon（服务编排）
  
• 　　chronos（分布式计划任务）
  
• 　　docker（容器引擎）
  
• 　　consul+registrator（服务注册和发现）
  
• 　　haproxy（负载均衡）
  
• 　　prometheus（服务监控）（注：同时数据也会推送到天机系统的 OpenTSDB 里）
  
• 　　nagios/zabbix（节点监控）
  
• 　　salt（节点配置管理）
  
• 　　cobbler（节点自动化装机）
  
• 　　ELK（日志收集分析）
  

　　窝窝持续集成管理平台在这些技术的基础上，实现了我们的集群管理、容器管理、应用管理等业务流程。
　　一些系统截图如下所示：

　　-END-
欢迎订阅我的微信订阅号『老兵笔记』，请扫描二维码关注：