CNUTCon（2015） 全球容器大会见闻

第一次参加这么高逼格的会议，内心还是有点小激动的，虽然门票花了1000多块，但现目前看来应该还是值的。在详细记录每个嘉宾的分享之前，先记一下大致整体的感受。纵观参会的公司，BAT榜上有名自不必说，redhet，coreos，Google等国外的大公司都有专家过来。大众点评，京东，360。。。总之上台分享的公司，都在江湖上有一席之地的，也算是开开眼界，见识一下了。

8月28日

外场

外场是各个赞助商的宣传地了，Daocloud占了A1的有利地形，亮哥的签名越来越好看了，一厚摞书一天就送的差不多了，大概又赚了不少新用户。其他的展商也是各尽手段，搞docker 的几家公司，都是磨拳擦掌的上了，灵雀云，时速云，bluemix，七牛，各种赞助商，实验室也有卖书的重任，磊哥在29号貌似还要搞签售会，但愿能多买基本书。外场整个都是眼花缭乱的感觉。

开场

Infoq 郭蕾,极客帮霍泰稳,介绍了会议举办的原因。

RedHat副总裁Ashesh Badani

印度英语听起来总是一股咖喱的味道，可能总裁级别的讲的都是比较high level的内容，感觉听完之后并没有什么卵用，因为没记住多少，同传翻译可能也对快语速的印度英语感到不适应，翻译的也是稀里糊涂，前句不接后句的。大体上就是讲了一下行业背景，技术人员大量的涌进不同的行业，IT运维成本，容器技术的发展起源，哪些是Linux本省就有的（selinux、namespace、cgroups）之后怎样对这些技术进行格式化，标准化，之后还要进行服务的编排，服务的发布。还有所谓的软件自定义一切的思想。。。最后举了Amadens公司使用openshift的一个例子。本来对于openshift一直也没有什么好感，之前部署的时候就被折腾得够呛，最后演示的时候还险些出了岔子。听得也就是将将就就了，Badani也提到了source to image 这算是第一个开始看的项目的源码了，最然只是看了个大概。

CoreOS 产品负责人 Kelsey Hightower

听老美讲英语就舒服多了。而且内容也熟悉多了，不过总感觉老美没什么诚意，主要就是讲了两组项目 一个是 Chubby + Borg 之后是 etcd + k8s 分别对比了Chubby以及etcd，以及Borg和k8s，细节没仔细记，一条条的那种，拍了照片。这个可能听google的工程师讲会更权威一点。之后就是对于etcd的集群功能的一个现场演示，还有对于k8s的基本功能特别是kubectl的演示。具体的ppt和demo都放在了 git上面 。 总是etcd这个，还得回去再看看，特别是集群部署，中间哪个节点停掉时候，关注一下leader选择的过程。还有一点是关于k8s的rolling update ，就是canary pattern(?先记下来，再仔细看看)大概就是灰度升级的过程吧。之前还一直不太用过这个功能，实验室的集群是使用gorouter来实现这个功能的，感觉有点鸡肋了，gorouter还是专注于内部域名那样就比较好，灰度升级这样用本来自带的就行。k8s的自带ui还是蛮酷炫的，还是自己搞起来试一试。

京东云平台 刘海峰

京东弹性计算云，软件定义数据中心与容器集群调度。京东云的项目初衷主要有两个 1 越来越多的物理机 2 随着服务的增加，研发团队的运维成本的上升。毕竟大厂，从2014年10月份开始引入docker到2015年2月确定战略，再到2015.6.18京东已经有 11000+个容器在线，新的数据中心也正在建设中。

京东最初的希望是通过一个平台，将物理机，虚拟机，容器，三种资源统一管理，随后的演化中，容器逐渐成为了一等公民。一种是容器直接在VM上，一种是让VM看起来像容器。为了和已有的技术整合，京东选用的是openstack + docker 的模式， 将docker融入到已有的技术体系中，而不是一上来就采用一个全新的平台 。最底层是openstack+docker，开始的时候他们希望使docker用起来像虚拟机，让开发人员更好适应，因此使用的是“胖容器”的模式，在容器中预制了ssh 、log等服务。再往上一层，是和业务层结合比较紧的一些模块。

网络方面的改进，使用的是 vlan+OVS，对内核有一些相关的工作。

存储方面，就是基于镜像来进行 第一步 基础镜像+自动部署 （采用胖容器 每个容器一个ip 用起来就像虚拟机一样 每个容器的规格默认是固定的） 第二步 完全基于容器的镜像发布 （统一镜像中心 程序与配置分离）

管理调度 主要是自主研发，因为与业务结合的较紧，包括集群部署、日志服务、监控等等基本的工具链。以及负载伸缩。

其他部门通过调用api直接拿容器过来，部署应用，感觉上就像是虚拟机一样。简化了资源申请的流程，容器跑起来，动态扩展，伸缩，管理也比较方便。

大众点评 基于Docker的私有PaaS

之前的平台使用方式： openstack + KVM ，KVM统一从资源池中往出拿，过程麻烦，人力成本高。

采用docker之后，使用的技术栈： Docker ， NATS(消息队列)，Nginx，Zookeper ，将docker虚拟机注册到消息队列中。

对网路的改造：使得容器看起来像KVM，通过新创建的br0网桥与eth连接，使得docker 容器可以有自己独立的IP(这里每太听懂)

分享了过程中遇到的一些坑，因为使用的是centos，存储驱动是device mapper在使用puppet的时候还是有一些问题，具体涉及好多细节的地方，听得不太懂。

目前点评的规模是 600+应用， 2800+ docker容器， 200+物理机，2个数据中心。

时速云 k8s

中间漏掉了阿里的tae分享，有点可惜，跑过去听时速云关于k8s的分享，可能更有针对性吧。

前面的关于k8s的基本概念和优点就不再记录了。

主要是高可用性吧，etcd 它们在测试中，发现至少要3个节点才保证稳定，最好是要大于5个节点，但是具体etcd down的原因是什么，这个也没细说，因为什么会down，他们也没有再细说。

有的时候流量大了，apiserver也承受不了，可以多弄几个apiserver，之后在前面使用haproxy。貌似这个是官方推荐的（之前没太找到，官方文档上应该有，再好好看看）之后就是rolling update的使用，看来k8s本省就集成的很好了，这个还真应该用起来。

ten cloud的私有集群的master节点并不放在用户那边，而是在服务提供方那里注册之后，由服务提供方管理的，minion节点是用户自己的，这样其实在运维上是省了好多事的，想想实验室的master节点与minion节点都放在一起的架构，运维的想话也真是有点惨不忍睹。。。还有关于registry，不论是共有集群还是私有集群，registry都是统一维护的一个，从某个固定的地方push或者pull镜像，并且reristry中还要有权限控制，实验室的那种每个集群只有一个registry容器运行的模式，感觉有点玩玩的样子，怀疑并不能用到真正的生产中。而且它们的master也是采用多结点的那种方式。registry还实现了权限控制，就是通过namespace与secret结合来实现的，这个是k8s中secret使用的一种模式，在registry上，应该也没有做其他额外的改进。

关于一些issue : 7767(etcd多核模式) 8772（hyperkube中没有集成cadvisor）9952(关于RBD的挂载问题)

还有提到的kubectl 的patch功能实际使用中比较有效，这个回头也要仔细看看。

腾讯游戏docker实战

由于讲了很多细节的东西，特别是网络方面，好多都美听太懂，大概记。

360的容器化之路

从运维的角度讲360容器化的过程，条理性较好，感觉颇有启发。 1 docker for issue 如果docker拿来就用，不便于ssh排查问题，如何查看容器信息，docker是否稳定，其他基础服务如何接入，周边生态还不完善。。。 2 docker for iaas 对docker改进，适配已有的服务，落地，在生产中使用起来。

• 容器独立ip 不需要端口映射
• 容器内多进程
• 自动添加监控
• apu quota (硬限制) 通过octopus项目对docker进行二次封装，除了基本的docker命令外，还给它配上了独立的ip，监控，以及cpu quota等等。

3 docker for paas 运维工程师的理念=》让产品失败得更廉价 hae项目，专为小业务快速上线而打造。基于docker做一些常见的运行时环境的模板。 比如 爆米兔 水清直播 魔盒ui等。

4 docker for caas 持续集成 配置转化（通过界面操作较快的方式生成docker file）-》jekinmaster + jekinslave build push to registry 。

构建的时候提高效率，缩短构建时间的改进:device mapper - > btrfs SAS->SSD (SSD可以减少IO) build的时候可以 用小容量的SSD也没关系。docker in docker (docker deamon本身一次只能build一个？每个任务启一个独立的docker deamon来进行build )

镜像存储方面，就使用官方的v1和v2版的registry。

调度方面，使用的是marathon+mesos ，会将die了的机器上的容器迁移到其他的机器上去。

全天感受

还是感觉大厂的docker实践更有发言权，实际上他们对于docker的实践才是真正切合实际的，因为docker 或者说是paas、caas都和VM不同，整个工具栈越往上走，对于原有业务的相关性也就越多，耦合度也就越高，所需要做的适配也就越多。做paas的共有云，这个路到底能不能成功，具体怎么走，其实都是探索阶段的，包括Daoclod、灵雀云等等，它们都是第一批。

几个过来分享的大厂，它们对于docker的实践，至少可以说是“初步成功的”，因为从他们展示的数据和对容器的使用状况来看，确实发挥出了容器的优势，由于有实际线上服务的驱动，他们的解决方案也都是“经得起实践检验的”，虽然各有不同，但好歹都是“落地”的项目。

但各个厂的解决方案，定制的过程，玩法，基本上是各有各的招（第一步都是网络的改进，大概是某种渐进式的，某种程度上把docker当成虚拟机的来用），究其原因，还是因为自由业务，自由平台，容器化的过程并没有那么简单。完全用一套新的方案，是不现实的，怎么样能在最大程度上复用已有组件/工具链的同时，又引入容器化的优势，这才是难点，也是各个公司解决方案千差万别的原因，合适自己公司的，才是最好的。

像K8s这种，整体上还是理念较新的技术，大厂似乎没有采用的，貌似很难与自己已有的服务契合上去，只有新开始的创业公司，才赶打着共有云的旗号，上这些服务，但明显还有很长的路要走。

8月29日

K8s和Borg的设计哲学

Dawn Chen据说是google的Borg的早期的项目设计成员，还是K8s项目的主要的维护者之一，而且还是磊哥他们的code reviewer，开始还不知道有这么牛。但是中英文转来转去，听起来实在是有点费劲。

整体感觉上分享的也都是一些high level的内容，大概自己水平还有差距吧，听起来感觉混混然的样子。

先是将一些容器技术的起源，从共享主机，到虚拟机（与os紧耦合）再到容器（process tracking）:容器就是通过多个不是很相关的Linux API 封装出来的一个进程，开始的时候使用cgroups、capability 、chroots最后再到capability。

还谈到了一个挺有意思的比喻,vm vs container 就像 pets vs cattel （只要id标识 单个容器的健康状况并不会有特别的care）。

之后主要还是围绕Borg论文中的一些内容，比如为何要使用容器。

之后是k8s borg omega的一些特性，感觉还不如听磊哥讲得细致，大致记了一些，比如 k8s与borg的对比： declarative > imperative （rc的那种形式，就是提前定义好需要复制的实例数）ctrol loop( observe rectify repeat)这里应该说的是，面向etcd的这种编程方式，死循环，然后watch etcd 之后根据不同的watch结果有不同的执行流程。

之后就是一些k8s的相关特性。其他的一些内容还是等infoq把ppt公布出来再对着ppt来看吧。

Swarm的现状与未来

华为的线超博是swarm项目的maintaner。

swarm大致意思是动物的集群行为，管理多个docker agent。主要的特点是友好，对外以docker api的方式呈现，轻量，易部署，插件式框架，对Docker的命令支持较完善。

之后从架构，集群管理，资源管理，资源调度几个方面做了介绍，具体看ppt

最后讲了一些进入开源社区的经验，主要是还是对代码熟悉，持续投入，从小做起，积极参与，多发表见解，表现自己的存在感。

总体上看，swarm还不适合在生产环境中使用，按磊哥的话说是，由于docker公司的原因，swarm缺乏集群管理的视角，还不足以在生产环境中发挥优势。

百度开放云

感觉还是大厂对于容器的实践比较牛逼，在docker没出来之前，他们就都着眼于容器技术了，应该说他们更能理解容器技术的本质吧。对相关技术的实践也都是很丰富更加系统。2013年百度就开始了Marix集群操作系统的实践，后来分别有对内和对外的服务。

对内服务的业务分类上，包括在线类（需要低延时，高可靠）、离线计算类（batch类型，要吞吐量不要求时间延）、storage（对cpu消耗小）、idle类（不着急的计算任务，利用机器的空闲时间计算）

主要面对的困难是在线离线业务的混部（不同质容器的混部），将服务与机器解耦、预算调度（共享资源池变化 资源池面向的资源是一个个的container）的困难。

本质来讲，具体的挑战体现在两个方面，一个是调度上，一个是linux kernal上，百度貌似对kerna作何很多定制化的操作，这点主要是体现在从内核角度上对container的隔离性进行改造。毕竟大厂，还是很牛逼的。

大厂普遍面临的问题还是服务前迁移的问题，说白了还是上云的问题，或者新潮一点，就是为服务化的问题。都需要针对具体的业务进行具体的定制，很难有一个通用的解决方案。

百度使用的容器技术并没有引入镜像的相关内容，直接是在cgroup （划出一个资源框）namespace（内部的话 只需要部分）的基础上定制操作。再通过agent来把这些所谓的“容器”启动起来，部署的时候通过package的方式进行部署，不想docker那样通过镜像的方式（？package的base环境都是一致的）。具体的逻辑分层上似乎与k8s的不谋而合，一个App里面可以包含很多模块，一个模块又可以成为一个service，service1,service2…之后每个service可以有多个实例，实现伸缩扩容。

具体单机上的agent资源模型从以下几个角度来描述：cpu,memory,network(in out),disk_space,disk_inode,threads 对于一个container来说，会通过ip+端口来进行标识。

架构上有统一的container操作接口 ，支持cgroup,LXC,kvm等虚拟化的方案。

还有就是百度对于容器的安全性也有了很多实践，其实所说的安全性就是让容器上的代码不会跳到主机上去，让host上的代码不会逃逸出去。貌似还基于 Dune的论文(这个？) 有了一个实现。还提到了一个Intel的clean container的项目。

vmware

Daocloud架构演化

从为服务的角度上细致介绍了docker hub的架构演化流程，有图有真相。

但是代码本身的边界定义要清楚，边界范围要清晰，才有利于后期的为服务化。

其实本来写最初的代码的时候就应该是这样的。

Rancher labs

由于停磊哥的分享，误了这个。不过听网易的大神们说，这个分享还是很不错的，具体见ppt吧。

k8s实战

磊哥分享，逻辑很好，信息量很大，首先是从docker入手，从linux的角度分析了下docker run的启动流程。之后分享了Borg论文的一些简洁，具体可以看Infoq上的文章，最后就是对k8s的深入分析了，从原理上，分析了几个关键概念，之后对不同的paas解决方案（主要是 docker mesos swarm ）进行了下对比,还是直接看ppt吧。

后来又想了想k8s的网络模型，这么做其实就是通过把pod作为资源管理的单位，屏蔽了docker端口映射的那种网络模式，对比Daocloud那种原生的网络模型，似乎要更好一点了，因为不需要对端口映射做管理，而且更能体现混合云的概念，因为后端架构更灵活，可以用自己的后端的数据库服务，不一定为要用平台提供的数据库镜像。 目测云服务特别是这种paas云的最终面向用户还是企业级用户，对其从架构上进行有针对性的为服务化。散户多是玩一玩的，因为并没有那么大的业务，需要从架构的角度上去为服务化，只有在运维成本迅速增加急需提高资源利用率的时候才需要更细粒度的资源控制，弹性伸缩，种种。

整理不动了，好多内容也都是一知半解的，先放在这里再慢慢看吧。