业界docker实现的技术

三月阳光

　　业界使用架构

• 京东
  
  
  
  • Openstack Icehouse + docker1.3 + OVS2.1.3/2.3.2+Centos6.6 ==> K8s + Docker + Flannel +Neutron + OVS + DPDK +JFS
    
  • 某个容器失效,自动触发RC(保持IP丌变“迁移”)
    
  • OVS-VLAN
    
  
  
• 知乎
  
  
  
  • Git+Jenkins(CI/CD) + mesos + 自研framework + group(隔离) + Consul + haproxy + DNS + Graphite + cAdvisor
    
    
    
    • 通过group做故障隔离
      
    • 镜像仓库通过hdfs和水平扩展做高可用
      
    • Mesos 集群的横向扩展
      
    
    
  • docker网络
    
    
    
    • bridge
      
    • NAT is not bad
      
    • iptables 有些坑
      
    
    
  • 服务发现
    
    
    
    • DNS Client
      
    
    
  • 自动Scale
    
    
    
    • 突发响应 & 资源高效利用
      
    • 根据cpu指标调整容器数量
      
    • 快伸慢缩
      
    • Max & Min Hard Limit
      
    • 支持自定义指标
      
    
    
  
  
• 携程
  
  
  
  • Openstack + Mesos + Docker + Chronos + ELK
    
  • 监控：telegraf -> Influxdb -> Grafana
    
  • 日志：elk
    
    
    
    • mesos stdout、stderr
      
    
    
  
  
• 去哪儿
  
  
  
  • OpenStack + nova-docker + VLAN =>Mesos + Marathon + Docker(--net=host) + 随机端口 => Mesos + Marathon + Docker + Calico
    
  
  
• 阿里电商云
  
  
  
  • 自研EWS, 基于compose, 参考Kubernetes的设计. 支持多region.
    
    
    
    • cAdvisor + InfuxDB + prometheus
      
    • etcd + consul + zk + docker overlay
      
      
      
      • 使用RDS,OSS,OCS等服务化存储
        
      
      
    
    
  • docker容器的正确姿势
    
    
    
    • 每次代码提交重新构建镜像
      
    • 禁止修改运行中的镜像
      
    • 利用volume保存持久化数据
      
    
    
  • 存储管理
    
    
    
    • 利用docker volume plugin支持不同的存储类型
      
      
      
      • 块存储，云盘
        
      • 对象存储，OSSFS
        
      • 网络文件系统 NFS
        
      
      
    
    
  
  
• 同程
  
  
  
  • swarm + swarm agent + etcd + zabbix + Jenkins + (Nginx+Lua) + 配置中心
    
  • 使用现状
    
    
    
    • 容器5000个,高峰扩容到8000
      
    • Docker应用600个, 塞入容器的还有:Mongodb, Redis,Mysql
      
    • cpu利用率由20%提升为80%
      
    
    
  • 资源隔离层面
    
    
    
    • 物理机利用率提升，合理的编排应用
      
    • 各应用间资源隔离，避免环境和资源的冲突，提示安全性
      
    • 爆发式流量进入： 快速扩容和迁移
      
    • 应用迁移： 减少买服务器的花费
      
    • 运维工作： 更多的自动化，更精细化的监控和报警
      
    
    
  • 优化
    
    
    
    • dockfile 优化，缩小层数从20层到5层，构建速度快1倍
      
    • 存储驱动从devicemapper改到overlayfs，构建速度快1倍
      
    • 发布一个较大应用，耗时只需40s
      
    • 自动测试系统直接调用容器系统部署环境，测试完成就可回收，供其他测试使用
      
    • 实测物理机和Container之间的性能几乎没有损耗
      
      
      
      • redis性能对比： redis-benchmark -h 127.0.01 -p6379 -q -d 100
        
      
      
    
    
  • 镜像管理
    
    
    
    • 基础镜像池的建设
      
    • 基础镜像之上再构建应用镜像
      
    • 应用镜像每次发布时重新构建
      
    • 应用镜像多版本存储
      
    • 一次构建镜像，各处可用
      
    • 各应用的回滚、扩容全部基于应用的镜像来完成
      
    
    
  • 网络的思考
    
    
    
    • 在私有云的网络可控性本身比较高
      
    • 多租户的隔离在私有云的意义不多
      
    • 稳定可控可扩展才是急需求
      
    • 整体带宽的高保证
      
    • 对docker容器的网络考虑
      
      
      
      • 本机网络模式和OVS模式
        
        
        
        • 本机网络模式：如web
          
        • OVS模式： 如数据分析
          
        
        
      
      
    
    
  
  
• 网易蜂巢
  
  
  
  • openstack + K8S + etcd + OpenFlow + iscsi + Ceph + billing + 多机房
    
  
  
• 腾讯
  
  
  
  • Kubernetes + 网络(Bridge + VLAN / SR-IOV / overlay) + lxcfs + Ceph + configmap\secret + 蓝鲸管控平台
    
  • 目前，大概有15000多常驻的Docker容器, Docker平台上已经跑了数十款端游、页游和手游
    
  • 集群都是同时兼容Docker应用和非Docker类型的应用的
    
  • Gaia将网络和CPU、内存一样，作为一种资源维度纳入统一管理。业务在提交应用时指定自己的网络IO需求，我们使用TC（Traffic Control）+ cgroups实现网络出带宽控制，通过修改内核，增加网络入带宽的控制
    
  • 具体网络选型
    
    
    
    • 集群内 pod 与 pod 的之间的通信，由于不需要内网 IP（可以用虚拟 IP）所以采用 overlay 网络，由 flannel 组件实现。
      
    • 公司内网到集群内 pod 通信，例如 HAProxy，游戏某些模块，采用 SR-IOV 网络，由自己定制的 sriov-cni 组件实现。这类 pod 具备双重网络， eth0 对应 overlay 网络， eth1 对应 SR-IOV 网络。
      
    • pod 到公司内网之间的通信。在微服务场景下，游戏的数据存储，周边系统等，部署在物理机或者虚拟机上，因此 pod 到这些模块、系统的访问，走的是 NAT 网络。
      
    • (Internet) 接入，采用公司的 TGW 方案。
      
    
    
  
  
• 滴滴
  
  
  
  • Kubernetes
    
  • 目前了解的资料,滴滴使用docker化的时间不长,没有太多参考架构设计
    
  
  
• uber
  
  
  
  • 待补充
    
  
  
• 蘑菇街
  
  
  
  • Kubernetes + VLAN
    
  
  
• 七牛云
  
  
  
  • Mesos + 自研容器调度框架（DoraFramework) + Bridge+ NAT + Open vSwitch + Consul + Prometheus + Ansible
    
  • 七牛目前已经达到近千台物理机的规模, mesos支持大规模调度更合适
    
  • 不选择Mesos的核心框架Marathon 而选择自研
    
    
    
    • Marathon有些方面不支持我们期望的使用姿势，比如不太好无缝对接服务发现
      
    • Marathon采用 scala 开发，出了问题不好排查，也不方便我们做二次开发
      
    • 如果选用 Marathon的话，我们上面还是要再做一层对 Marathon的包装才能作为Dora的调度服务，这样模块就会变多，部署运维会复杂
      
    
    
  
  
• 魅族云
  
  
  
  • OVS & VLAN + SR-IOV +ceph(保证镜像存储可靠性) + 自己现有的监控系
    
  • 主机间Container通过大二层网络通讯，通过vlan隔离
    
  • 异地镜像同步
    
  • 容器设计理念
    
    
    
    • 容器化的虚拟机,创建的Container需要长时间运行
      
    • 每个Container拥有独立、唯一的IP
      
    • 主机间Container通过大二层网络通讯,通过vlan隔离
      
    • Container开启ssh服务,可通过堡垒机登陆
      
    • Container开启其他常用服务,如crond
      
    
    
  • 网络
    
    
    
    • Iperf test: Bridge < OVS veth pair < OVS internal port
      
    • Iperf test: Native > SR-IOV > OVS > Bridge
      
    • Docker with DPDK
      
      
      
      • 轮询处理数据包,避免中断开销
        
      • 用户态驱动,避免内存拷贝、系统调用 - CPU亲和、大页技术
        
      
      
    • Idea
      
      
      
      • virtio作后端接口
        
      • 用户态socket挂载到Container
        
      • Container内跑DPDK applications
        
      
      
    
    
  • Container存储
    
    
    
    • Devicemapper: 成熟稳定, 裸设备, snapshot
      
    • IOPS: Native 基本等于 Devicemapper
      
    • 数据盘存储-LVM
      
      
      
      • 按Container进行配额, 支持在线更改配额
        
      
      
    
    
  • 镜像存储与同步
    
    
    
    • 镜像存储
      
      
      
      • LVS前端负载均衡,保证高可用
        
      • distribution管理镜像
        
      • 后端ceph保证镜像存储可靠性
        
      
      
    • 异地镜像同步
      
      
      
      • webhook notification机制
        
      • 强一致同步机制
        
      
      
    
    
  • 容器集群调度系统
    
    
    
    • 调度请求落到集群相应节点
      
    • 根据IDC、资源与区、Container类型筛选宿主机
      
    • 根据宿主机资源状态、请求的CPU/内存/磁盘大小动态调度
      
    • 机柜感知,将同一业务Container调度到不同机柜
      
    
    
  
  
• ucloud
  
  
  
  • kubernetes + Jenkins
    
    
    
    • -v 挂载到主机, Flume/Logstash/rsyslog + elasticserach (日志)
      
    • vswitch overlay的&quot;大二层&quot;网络SDN组网方案 + ipvlan
      
    
    
  • 主要问题类型和解决思路
    
    
    
    • 模块配置
      
      
      
      • 模块上下游关系, 后端服务
        
      • 运行环境,机房的差异性配置等
        
      
      
    • 一致性和依赖
      
      
      
      • 开发、测试、运行环境的不一致性
        
      • 依赖于不同的基础库
        
      
      
    • 部署
      
      
      
      • 部署效率低下，步骤多，耗时长
        
      • 部署状态缺少检查机制
        
      • 应用管理
        
        
        
        • 大量容器实例的管理、扩容、缩容成本高
          
        • 程序构建、打包、运行和运维统一管理
          
        • 监控、日志分析
          
        
        
      
      
    • 解决方案
      
      
      
      • 模块配置
        
        
        
        • 分离环境、IDC、资源类等差异化的配置项信息
          
        • 配置模板，提交到cedebase进行版本化管理
          
        • 对不同的deploys派生不同配置值，填充模板，启动脚本
          
        • 运行在不同的deploys汇总，只需通过环境变量传递给container即可
          
        
        
      • 一致性和依赖
        
        
        
        • 开发、测试、线上运行环境均采用docker生成的镜像，保证一致
          
        • 基础系统、基本工具、框架，分层构建
          
        • 基础镜像在开发、测试、线上环境统一预部署
          
        
        
      • 私有镜像仓库
        
        
        
        • V2版本
          
        • 支持UFile驱动
          
        • 定时pull最新镜像
          
        
        
      
      
    • 一些经验
      
      
      
      • docker日志
        
        
        
        • 日志打印耗费性能
          
        • 最好关闭logdriver，将日志打印在后台
          
        
        
      • docker daemon
        
        
        
        • 退出kill container， 升级docker daemon， kill可选
          
        
        
      • docker网络
        
        
        
        • NAT模式下会启用nf_conntrack，造成性能下降，调节内核参数
          
        
        
      • docker镜像
        
        
        
        • 编写dockfile规范、减少镜像层数，基础部分放前面
          
        • 分地域部署镜像registry
          
        
        
      
      
    
    
  
  

　　主要问题

• 单实例性能调优 + 万兆卡的性能发挥出来。需要对OVS（Open vSwitch）做一些改进
  
• 多机房:多机房及可用域支持
  
• 容器网络需求
  
  
  
  • Iptables 有些坑
    
  • 跨主机容器间网络访问
    
  • 容器网络是否需要具备IP地址漂移能力
    
  
  
• 容器网络面临的问题
  
  
  
  • Docker Host 模式,混布存在端口冲突。
    
  • Docker NAT 模式,Ip地址敏感服务改造大,无法支持服务发现
    
  • Overlay网络,涉及IP地址规划,MAC地址分配,网络设备收敛比等问题
    
  • Overlay网络安全性,可维护性, 容量规划
    
  
  
• 版本升级(docker/mesos/k8s)本身的升级
  
• docker 对有状态的服务进行容器化的问题
  
  
  
  • kafka / mysql
    网络选型(k8s和mesos)
    
  
  

　　思考 && 痛点

• 可否跨机器访问? 跨域访问?
  
  
  
  • flannel可以跨容器通信
    
  • 跨主机的容器互联
    
  • 容器与外部互联
    
  
  
• 是否支持静态ip , 固定ip ? 域名访问?
  
  
  
  • 固定ip的话,那么就需要每次部署或者更新或重启的时候,ip保持不变
    
  • overlay network, Docker 1.6 可以实现跨主机通信
    
  
  
• 是否支持dns?
  
• 4层/7层访问
  
• 容器库容后的网络
  
• ip端口,最好不要自行手动规划
  
• 网络策略,防御 ,隔离 ?
  
  
  
  • 容器集群不同应用之间的网络隔离和流量限制
    
  
  
• 　　docker 网络
  
  
  
  • host模式: 容器都是直接共享主机网络空间的，容器需要使用-p来进行端口映射, 无法启动两个都监听在 80 端口的容器, 并且没有做到隔离
    
  • container模式: 一个容器直接使用另外一个已经存在容器的网络配置：ip 信息和网络端口等所有网络相关的信息都共享
    
  • Bridge模式: 从docker0子网中分配一个IP给容器使用，并设置docker0的IP地址为容器的默认网关
    
    
    
    • 容器的IP在容器重启的时候会改变
      
    • 不同主机间容器通信需要依赖第三方方案如:pipework
      方案
      
    
    
  
  
• 方案类别
  
  
  
  • 隧道方案, 通过隧道，或者说Overlay Networking的方式：
    
    
    
    • Weave，UDP广播，本机建立新的BR，通过PCAP互通。
      
    • Open vSwitch（OVS），基于VxLAN和GRE协议，但是性能方面损失比较严重。
      
    • Flannel，UDP广播，VxLan。
      
    
    
  • 路由方案
    
    
    
    • Calico，基于BGP协议的路由方案，支持很细致的ACL控制，对混合云亲和度比较高。
      
    • Macvlan，从逻辑和Kernel层来看隔离性和性能最优的方案，基于二层隔离，所以需要二层路由器支持，大多数云服务商不支持，所以混合云上比较难以实现。
      
    • 性能好,没有NAT，效率比较高, 但是受限于路由表,另外每个容器都有一个ip,那么业务ip可能会被用光.
      
    
    
  
  
• 网络的两大阵营
  
  
  
  • Docker Libnetwork Container Network Model（CNM）阵营(Docker Libnetwork的优势就是原生，而且和Docker容器生命周期结合紧密)
    
    
    
    • Docker Swarm overlay
      
    • Macvlan & IP network drivers
      
    • Calico
      
    • Contiv（from Cisco）
      
    
    
  • Container Network Interface（CNI）阵营 (CNI的优势是兼容其他容器技术（e.g. rkt）及上层编排系统（Kuberneres & Mesos))
    
    
    
    • Kubernetes
      
    • Weave
      
    • Macvlan
      
    • Flannel
      
    • Calico
      
    • Contiv
      
    • Mesos CNI
      
    
    
  
  
• 常见的解决方案有：
  
  
  
  • flannel vxlan，overlay方式
    
  • calico
    
    
    
    • 容器间网络三层隔离，无需要担心arp风暴
      
    • 基于iptable/linux kernel包转发效率高，损耗低
      
    • Calico没有多租户的概念，所有容器节点都要求可被路由，IP地址不能重复
      
    
    
  • ipvlan macvlan，物理二层/三层隔离，目前需要pipework工具在单个节点上配置，仅做了vlan隔离，不解决arp广播
    
  • swarm native vxlan，跟flannel vxlan类似
    
  • neutron sdn，选择就多种了，ml2+ovsplugin，midonet，vlan or vxlan
    
  • Weave
    
    
    
    • 能够创建一个虚拟网络来连接部署在多台主机上的Docker容器, 外部设备能够访问Weave网络上的应用程序容器所提供的服务，同时已有的内部系统也能够暴露到应用程序容器上
      
    
    
  • contiv
    
    
    
    • 思科主导，sdn解决方案，可以用纯软的ovs，也可以用ovs+cisco硬件sdn controller
      
    • 基于 OpenvSwitch，以插件化的形式支持容器访问网络，支持 VLAN，Vxlan，多租户，主机访问控制策略等
      
    • SDN能力，能够对容器的网络访问做更精细的控制
      
    • 京东基于相同的技术栈（OVS + VLAN）已支持10w+ 容器的运行
      
    
    
  • linux bridge+三层交换机：host上 linux bridge 设置为三层交换机的子网网段，容器之间通信走二层交换，容器与外部走三层交换机的网关。
    
  
  
• 业界常用网络选型
  
  
  
  • kubernetes + flannel
    
    
    
    • Kubernetes采用扁平化的网络模型，要求每个Pod拥有一个全局唯一IP，Pod直接可以跨主机通信。目前比较成熟的方案是利用Flannel
      
    • Flannel已经支持UDP、VxLAN、AWS VPC和GCE路由等数据转发模式。
      
    • kubernetes 下有 flannel、openvswitch和weave可以实现Overlay Network
      
    • 唯品会 contiv netplugin方案(固定外网ip) + flannel
      
    • 京东 Flannel + Neutron + OVS
      
    • Flannel性能: 官方:带宽没有下降,延迟明显变大
      
    
    
  • Mesos + Caclio
    
    
    
    • Mesos支持CNI标准规范
      
    • 一容器一ip, 网络隔离, DNS服务发现, ip分配, L3的虚拟网络
      
    • 去哪儿 Mesos + Caclio
      
    • 七牛 Bridge+ NAT + Open vSwitch
      
    
    
  • 魅族云 OVS & VLAN + SR-IOV
    
  • ucloud: vswitch overlay的&quot;大二层&quot;网络SDN组网方案 + ipvlan
    日志监控选型(包括监控,统计)
    
  
  

　　docker由于分层设计模式,容器里面无法固化数据, 容器销毁里面的数据就会丢失, 因此建议将日志挂载到宿主机上, 或者使用分布式存储如ceph
stdout/stderr类型的日志，可通过logspout转发到syslog中心来收集
Docker 的LogDriver 能输出日志到特定的端点，例如Fluentd，Syslog，或者Journald。 Logspout能将容器日志路由到Syslog或者第三方的诸如Redis，Kafka或者Logstash的模块中。

• 方案介绍
  
  
  
  • 采用容器外收集。将主机磁盘挂在为容器中的日志目录和文件。
    
  • 将容器中应用的控制到日志也重定向到日志目录。
    
  • 在主机上对应用日志目录和docker日志目录做日志收集和轮换。
    
  
  
• 监控可选方案
  
  
  
  • cAdvisor + InfluxDB + Grafana
    
  • cAdvisor + Prometheus + Grafana
    
  • Graphite
    
  • Zabbix
    
  • Datadog
    
  
  
• 日志可选方案
  
  
  
  • logstash
    
  • ELK
    
  • Graylog
    
  • flume
    
  • heka
    
  • fluentd
    
  
  
• 　　业界方案
  
  
  
  • 阿里云 : cAdvisor + InfuxDB + prometheus
    
  • 协程: ELK
    
  • 知乎: Graphite + cAdvisor
    镜像管理
    
  
  
• 镜像总是从Dockerfile生成
  
• 镜像之间应该避免依赖过深，建议为三层，这三层分别是基础的操作系统镜像、中间件镜像和应用镜像
  
• 所有镜像都应该有对应的Git仓库，以方便后续的更新
  
• 　　Registry
  
  
  
  • 单点问题，对应的解决方案可以考虑DRBD、分布式存储以及云存储
    
  • Regitry的性能问题，目前可用的解决方案是通过HTTP反向代理缓存来加速Layer的下载, 或者提供镜像mirror
    
  • Registry用户权限，Nginx LUA可以提供一个简单快速的实现方案
    个人理解
    
  
  
• 选型不能只看编排, 还要看存储/网络等方面的支持
  
  
  
  • swarm以前有些缺陷,如不能检测失败节点并重启,最新版的也实现
    
  • k8s 只是用来调度docker
    
  • mesos是用来管理机器集群. 通过Marathon才能间接管理docker
    
  
  
• 对应网络的支持
  
  
  
  • 是否能够跨主机/跨域
    
  • 是否能够固定ip/ dns解析?
    
  • CNI 标准的支持?
    
  
  
• 对于存储的支持
  
  
  
  • 是否能够固化?
    
  • 是否支持分布式存储?
    
  
  
• 对于编排/调度/升级
  
  
  
  • 是否支持回滚? 在线升级? 滚动升级?
    
  • 是否能够细粒度分配cpu/内存等
    
  • 是否支持有状态服务的容器化 和 调度
    
  • 自动扩缩容能力?
    
  
  
• 服务注册/发现机制 / 负载均衡
  
  
  
  • 是否有合适的服务注册机制?
    
  • 负载均衡是否能够满足各种业务场景需求?
    
  
  
• 其他
  
  
  
  • 隔离, 除了cgroup和namespace, 还有其他的隔离,比如网络隔离
    
  
  

cn539

学习。