Docker容器平台选型调研
[TOC]
Docker容器平台选型调研
编排选型
Swarm
1. Swarm可以从⼀个Dockerfile来构建镜像，但是构建的镜像只能在单⼀节点上运⾏，⽽不能够被分布到集上的其他节点上。因此，
应⽤被认为是⼀个容器，这种⽅式不是细粒度的。
2. Swarm需要使⽤docker-compose scale来扩展其中⼀个容器，这个新的容器将会根据调度器规则进⾏调度。如果容器负载过
重，Docker Swarm并不会⾃动扩展容器
1. 正常情况下，必须去检查容器是否达到瓶颈, 能够及时的扩容
3. Swarm cluster ，在docker1.12版本中已经⽀持失败节点⾃动检测并拉取
4. ⽬前 Swarm 可以通过overlay networks 来⽀持多主机容器⽹络的访问, 旧版不⽀持.
Mesos & Marathon(最新版1.4.1)
1. Mesos 提供资源管理和调度框架抽象的功能，第三⽅应⽤需要实现 Mesos 框架提供的 API 才能接⼊ Mesos 所管理的资源.
1. mesos在底层添加⼀个轻量的共享层，提供⼀个统⼀的api接⼝，供其他框架集访问.
2. Mesos并不负责调度⽽是负责委派授权，有很多相应框架已经实现了复杂的调度，如Marathon
2. 相⽐于Swarm，Mesos的容错性更强，因为Mesos能够在JSON⽂件中对某个应⽤使⽤监测检查
3. Marathon 有⽤户UI界⾯，可以将其视为⼀个应⽤程序，它可以看作⼀个框架来管理容器, 容器可以通过REST API 与Marathon ⼀起
⼯作, ⽅便运维。
1. 新版Marathon很好的⽀持了应⽤的更新和回滚，除去了容器启动对静态配置⽂件的依赖，使应⽤容
器更新发布、回滚更加⽅便.
4. Mesos在弹性扩缩容后会导致宿主机上产⽣⼤量的 Exit 状态的 Docker 容器，清除时较消耗资源，影响系统稳定性。
1. 默认 Mesos 只有基于时长的清除策略，⽐如⼏⼩时，⼏天后清除，没有基于指定时间的清除策略，⽐如在系统闲时清除，也⽆
法针对每个服务定制清除策略。
2. 可以修改 Marathon 的源码程序，添加 Docker 容器垃圾清理接⼝，可以对不同服务按指定策略将Exit状态的Docker容器进⾏
清理。
5. Mesos不⽀持抢占，⽆法设置任务优先级
1. ⽬前 Apache Aurora 这个插件已经⽀持优先级和资源抢占, 但是它是和marathon同级别的.
6. 对于 mysql / Kafka这类有状态的存储类应⽤，⽬前 mesos+ Marathon还⽀持得不是很好
1. 在有失败发⽣或者⼀个简单的服务重启的场景下，Marathon会随机的在任何符合服务定义约束的资源上重启服务，这样对于有
docker重启容器命令
状态服务是不适合的，因为这样的话需要很⾼的操作代价来将本地状态迁移到新的服务上
2. 但是可以通过Marathon本地持久化卷来达到能够部署有状态服务的⽬的
1. 本地持久化卷后，下次再启动该容器的时候marathon与mesos会将这个容器再次部署到原先的宿主机上，⽽不是其他机器.
7. 可以⾃研所需的framwork.插件化处理. 不过Marathon本⾝是Scala编写的，UI是React编写，不利于⼆次开发
8. 其他组件如: mesos-dns 和 marathon-lb.
1. mesos-dns 是⼀个服务发现⼯具
2. marathon-lb 不仅是服务发现⼯具，还是负载均衡⼯具, 要使⽤marathonn-lb，每组app必须设置HAPROXY_GROUP标签,
采⽤haproxy进⾏负载均衡
9.
Kubernetes(最新版1.6)
1. Kubernetes使⽤ReplicationController来保证应⽤⾄少有⼀个实例在运⾏。当在Kubernetes集中创建了⼀个pod时，需要创建⼀
个叫做负载均衡的Kubernetes服务，它负责转发流量到各个容器。
1. 如果只有⼀个实例，也可以使⽤这种服务，因为它决定了能否将流量准确的转发到拥有动态IP的pod上。
2. Kubernetes添加了pod和replica的逻辑。这个为调度器和编排⼯具提供了更加丰富的功能，⽐如说负载均衡，扩展或者收缩应⽤的能
⼒。并且还能够更新正在运⾏中的容器实例。Kubernetes 拥有⾃我修复，⾃动化推出和回滚和存储编排. 主要优点:
1. AutoScale：根据收集的业务 metric 来决定是否需要⾃动扩缩容
2. Rolling Deployents：滚动部署新版本并不中断服务，在新版本部署完成后⽼版本退出
3. Work Queue：将 Service 从 1:1 的关系扩展到 1：N，为被访问的 Service 前置⼀层代理 Agent，⽤来转发请求
3. Kubernetes 擅长⾃动修复问题, 并且可以快速地对容器进⾏重启. 这会导致使⽤⽅不会注意容器是否崩溃
1. 为了解决这个问题，可以添加⼀个集中式⽇志系统 或其他⽅式 进⾏监控
4. 有状态服务集: StatefulSets (1.4版本叫PetSets )
1. 对于PetSet中的Pod，每个Pod挂载⾃⼰独⽴的存储，如果⼀个Pod出现故障，从其他节点启动⼀个同样名字的Pod，要挂在上
原来Pod的存储继续以它的状态提供服务。(保证ip/hostname不变)
2. 适合于PetSet的业务包括数据库服务MySQL/PostgreSQL，集化管理服务Zookeeper、etcd等有状态服务。
3. 使⽤PetSet，Pod仍然可以通过漂移到不同节点提供⾼可⽤，⽽存储也可以通过外挂的存储来提供⾼可靠性，PetSet做的只是
将确定的Pod与确定的存储关联起来保证状态的连续性
5. golang语⾔编写, 有助于⼆次开发, 社区活跃度⾼, 可以加⼊社区提⾼公司影响⼒
6. ⼤致统计下使⽤kubernetes的公司: eBay、Yahoo、微软、IBM、英特尔、华为、VMware、HPE、Mirantis、⽹易、普元、亚信,
乐视 , 腾讯, 京东
容器技术栈
技术点技术⽅案
资源调度 & 编排Mesos + marathon Swarm(Compose) Kubernetes
镜像 & 仓库harbor DockerHub Quay.io Artifactory
监控cAdvisor Graphite Sysdig Datadog Prometheus ,Zabbix + pythonAgent
⽇志ELK Graylog flume heka fluentd
服务注册和发现 / 负载均衡HAProxy Etcd consul nginx Confd / DNS(好像有坑)
存储devicemapper, overlayfs, Volume, Ceph ，Gluster ， NFS, OpenStack swift， glance ,iSCSI SAN
⽹络HOST, VXLAN IPSEC . OpenFlow .Flannel. Docker Bridge, Calico, Neutron ,pipework ,weave , SocketPlane
分布式计划任务chronos
安全Notary Vault
⾃动化⼯具ansible, salt
业界使⽤架构
1. 京东
1. Openstack Icehouse + docker1.3 + OVS
2.1.3/2.
3.2+Centos6.6 ==> K8s + Docker + Flannel +Neutron + OVS +
DPDK +JFS
2. 某个容器失效,⾃动触发RC(保持IP丌变“迁移”)
3. OVS-VLAN
2. 知乎
1. Git+Jenkins(CI/CD) + mesos + ⾃研framework + group(隔离) + Consul + haproxy + DNS + Graphite + cAdvisor
1. 通过group做故障隔离
2. 镜像仓库通过hdfs和⽔平扩展做⾼可⽤
3. Mesos 集的横向扩展
2. docker⽹络
1. bridge
2. NAT is not bad
3. iptables 有些坑
3. 服务发现
1. DNS Client
4. ⾃动Scale
1. 突发响应 & 资源⾼效利⽤
2. 根据cpu指标调整容器数量
3. 快伸慢缩
4. Max & Min Hard Limit
5. ⽀持⾃定义指标
3. 携程
1. Openstack + Mesos + Docker + Chronos + ELK
2. 监控：telegraf -> Influxdb -> Grafana
3. ⽇志：elk
1. mesos stdout、stderr
4. 去哪⼉
1. OpenStack + nova-docker + VLAN =>Mesos + Marathon + Docker(--net=host) + 随机端⼝ => Mesos + Marathon +
Docker + Calico
5. 阿⾥电商云
1. ⾃研EWS, 基于compose, 参考Kubernetes的设计. ⽀持多region.
1. cAdvisor + InfuxDB + prometheus
2. etcd + consul + zk + docker overlay
1. 使⽤RDS,OSS,OCS等服务化存储
2. docker容器的正确姿势
1. 每次代码提交重新构建镜像
2. 禁⽌修改运⾏中的镜像
3. 利⽤volume保存持久化数据
3. 存储管理
1. 利⽤docker volume plugin⽀持不同的存储类型
1. 块存储，云盘
2. 对象存储，OSSFS
3. ⽹络⽂件系统 NFS
6. 同程
1. swarm + swarm agent + etcd + zabbix + Jenkins + (Nginx+Lua) + 配置中⼼
2. 使⽤现状
1. 容器5000个,⾼峰扩容到8000
2. Docker应⽤600个, 塞⼊容器的还有:Mongodb, Redis,Mysql
3. cpu利⽤率由20%提升为80%
3. 资源隔离层⾯
1. 物理机利⽤率提升，合理的编排应⽤
2. 各应⽤间资源隔离，避免环境和资源的冲突，提⽰安全性
3. 爆发式流量进⼊： 快速扩容和迁移
4. 应⽤迁移： 减少买服务器的花费
5. 运维⼯作： 更多的⾃动化，更精细化的监控和报警
4. 优化
1. dockfile 优化，缩⼩层数从20层到5层，构建速度快1倍
2. 存储驱动从devicemapper改到overlayfs，构建速度快1倍
3. 发布⼀个较⼤应⽤，耗时只需40s
4. ⾃动测试系统直接调⽤容器系统部署环境，测试完成就可回收，供其他测试使⽤
5. 实测物理机和Container之间的性能⼏乎没有损耗
1. redis性能对⽐： redis-benchmark -h 127.0.01 -p6379 -q -d 100
5. 镜像管理
1. 基础镜像池的建设
2. 基础镜像之上再构建应⽤镜像
3. 应⽤镜像每次发布时重新构建
4. 应⽤镜像多版本存储
5. ⼀次构建镜像，各处可⽤
6. 各应⽤的回滚、扩容全部基于应⽤的镜像来完成
6. ⽹络的思考
1. 在私有云的⽹络可控性本⾝⽐较⾼
2. 多租户的隔离在私有云的意义不多
3. 稳定可控可扩展才是急需求
4. 整体带宽的⾼保证
5. 对docker容器的⽹络考虑
1. 本机⽹络模式和OVS模式
1. 本机⽹络模式：如web
2. OVS模式： 如数据分析
7. ⽹易蜂巢
1. openstack + K8S + etcd + OpenFlow + iscsi + Ceph + billing + 多机房
8. 腾讯
1. Kubernetes + ⽹络(Bridge + VLAN / SR-IOV / overlay) + lxcfs + Ceph + configmap\secret + 蓝鲸管控平台
2. ⽬前，⼤概有15000多常驻的Docker容器, Docker平台上已经跑了数⼗款端游、页游和⼿游
3. 集都是同时兼容Docker应⽤和⾮Docker类型的应⽤的
4. Gaia将⽹络和CPU、内存⼀样，作为⼀种资源维度纳⼊统⼀管理。业务在提交应⽤时指定⾃⼰的⽹络IO需求，我们使⽤
TC（Traffic Control）+ cgroups实现⽹络出带宽控制，通过修改内核，增加⽹络⼊带宽的控制
5. 具体⽹络选型
1. 集内 pod 与 pod 的之间的通信，由于不需要内⽹ IP（可以⽤虚拟 IP）所以采⽤ overlay ⽹络，
由 flannel 组件实现。
2. 公司内⽹到集内 pod 通信，例如 HAProxy，游戏某些模块，采⽤ SR-IOV ⽹络，由⾃⼰定制的 sriov-cni 组件实现。
这类 pod 具备双重⽹络， eth0 对应 overlay ⽹络， eth1 对应 SR-IOV ⽹络。
3. pod 到公司内⽹之间的通信。在微服务场景下，游戏的数据存储，周边系统等，部署在物理机或者虚拟机上，因此 pod 到
这些模块、系统的访问，⾛的是 NAT ⽹络。
4. (Internet) 接⼊，采⽤公司的 TGW ⽅案。
9. 滴滴
1. Kubernetes
2. ⽬前了解的资料，滴滴使⽤docker化的时间不长，没有太多参考架构设计
0. uber
1. 待补充
1. 蘑菇街
1. Kubernetes + VLAN
2. 七⽜云
1. Mesos + ⾃研容器调度框架（DoraFramework) + Bridge+ NAT + Open vSwitch + Consul + Prometheus + Ansible
2. 七⽜⽬前已经达到近千台物理机的规模, mesos⽀持⼤规模调度更合适
3. 不选择Mesos的核⼼框架Marathon ⽽选择⾃研
1. Marathon有些⽅⾯不⽀持我们期望的使⽤姿势，⽐如不太好⽆缝对接服务发现
2. Marathon采⽤ scala 开发，出了问题不好排查，也不⽅便我们做⼆次开发
3. 如果选⽤ Marathon的话，我们上⾯还是要再做⼀层对 Marathon的包装才能作为Dora的调度服务，这样模块就会变多，
部署运维会复杂
3. 魅族云
1. OVS & VLAN + SR-IOV +ceph(保证镜像存储可靠性) + ⾃⼰现有的监控系
2. 主机间Container通过⼤⼆层⽹络通讯，通过vlan隔离
3. 异地镜像同步
4. 容器设计理念
1. 容器化的虚拟机，创建的Container需要长时间运⾏
2. 每个Container拥有独⽴、唯⼀的IP
3. 主机间Container通过⼤⼆层⽹络通讯，通过vlan隔离
4. Container开启ssh服务，可通过堡垒机登陆

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。