业界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的"大二层"网络sdn组网方案 + ipvlan

主要问题类型和解决思路

模块配置

模块上下游关系, 后端服务

运行环境,机房的差异性配置等

一致性和依赖

开发、测试、运行环境的不一致性

依赖于不同的基础库

部署

部署效率低下，步骤多，耗时长

部署状态缺少检查机制

应用管理

大量容器实例的管理、扩容、缩容成本高

程序构建、打包、运行和运维统一管理

监控、日志分析

解决方案

分离环境、idc、资源类等差异化的配置项信息

配置模板，提交到cedebase进行版本化管理

对不同的deploys派生不同配置值，填充模板，启动脚本

运行在不同的deploys汇总，只需通过环境变量传递给container即可

开发、测试、线上运行环境均采用docker生成的镜像，保证一致

基础系统、基本工具、框架，分层构建

基础镜像在开发、测试、线上环境统一预部署

私有镜像仓库

v2版本

支持ufile驱动

定时pull最新镜像

一些经验

docker日志

日志打印耗费性能

最好关闭logdriver，将日志打印在后台

docker daemon

退出kill container， 升级docker daemon， kill可选

nat模式下会启用nf_conntrack，造成性能下降，调节内核参数

docker镜像

编写dockfile规范、减少镜像层数，基础部分放前面

分地域部署镜像registry

主要问题

单实例性能调优 + 万兆卡的性能发挥出来。需要对ovs（open vswitch）做一些改进

多机房:多机房及可用域支持

容器网络需求

跨主机容器间网络访问

容器网络是否需要具备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))

weave

macvlan

flannel

contiv

mesos cni

常见的解决方案有：

flannel vxlan，overlay方式

容器间网络三层隔离，无需要担心arp风暴

基于iptable/linux kernel包转发效率高，损耗低

calico没有多租户的概念，所有容器节点都要求可被路由，ip地址不能重复

ipvlan macvlan，物理二层/三层隔离，目前需要pipework工具在单个节点上配置，仅做了vlan隔离，不解决arp广播

swarm native vxlan，跟flannel vxlan类似

neutron sdn，选择就多种了，ml2+ovsplugin，midonet，vlan or vxlan

能够创建一个虚拟网络来连接部署在多台主机上的docker容器, 外部设备能够访问weave网络上的应用程序容器所提供的服务，同时已有的内部系统也能够暴露到应用程序容器上

思科主导，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的"大二层"网络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, 还有其他的隔离,比如网络隔离

更多的博客转移到个人博客上了，请点击以下链接：

个人博客