阿里搜索业务容器化中的一些经验和思考

原文链接

摘要： 　从个人对容器的发展来看。大会上几位问到一些隔离的问题，分享嘉宾都说这个比较复杂，要么说这块他们没有解决，确实经常出问题，要么说私下来讨论；其实我们在接入和调度容器的时候，也发现了目前的容器技术在隔离上还欠缺很多，如果要能更好的提高物理机的资源利用率，降低成本，单机隔离和单机弹性将是一大关键技术和核心竞争力。

概要

参加了上一次CNUTCON 大会，有来自coreos的李响，分享了很多关于etcd的事情，以及关于k8s包括自己和coreos公司的一些观点；还有来自mesos的tim chen, 他分享了很多mesos的思路以及一些接入容器过程中踩过的一些坑；swarm kit的负责人陈东洛也分享了swarm的思路，这方面由于刚出来没多久以及分享的同学也只有他，所以东西并不多；总的来说，感触很深。

关于容器和编排，想到开源和创业

　　从会议分享者来看。相比去年，容器技术有了更大的发展；docker很热，每一个主题都在涉及docker。且基本上大家都认同docker的镜像。对于容器，虽然也有其他的一些选择，比如rkt,lxc等，但对于runtime以及接口，大家基本趋于一致，短期也不会期望有大的变化，大家开始从更高层次思考容器的应用，比如直接提供给用户编排的工具，服务或系统，而不是一个容器。swarmkit的发布就有这个意思，大家开始把重心转移到编排和调度。
　　从个人对容器的发展来看。大会上几位问到一些隔离的问题，分享嘉宾都说这个比较复杂，要么说这块他们没有解决，确实经常出问题，要么说私下来讨论；其实我们在接入和调度容器的时候，也发现了目前的容器技术在隔离上还欠缺很多，如果要能更好的提高物理机的资源利用率，降低成本，单机隔离和单机弹性将是一大关键技术和核心竞争力。
我们采用了跟mesos一样的架构和思路，因此我重点听了mesos相关的topic，希望是能够吸取到好的经验，能实际实施到我们的系统中，然后听了更多的k8s的topic。整体个人感觉,在开源解决方案中，k8s目前要热过mesos，k8s在web service这方面确实占据了很大的市场，吸引了很多开发者，但在有状态服务的应用特别是大数据上面目前并没有很好的解决方案，社区也一直在讨论和抽象当中。相反mesos在大数据服务场景下能够很好的解决，并在集群规模上也有很好的优势,但拿到mesos是不能直接解决用户的需求，需要用户写一个scheduler。swarm的思路则是另外一种哲学，或是另一个极端，跟docker的思路是同承一脉的，把更多的东西集成进系统里，提供给用户简单统一的接口，装好docker就可以编排调度了，这方面后续发展如何，很难说，暂且不论。总的来说，这一开源领域目前仍是K8s、Swarm、Mesos三足鼎立，近期也看不到谁会完全胜出。它们的功能比较如下图所示。

　　无论mesos这种2次调度，扩展性强的哲学，还是swarm kit这种集装箱式的哲学，其次是k8s先取其中，优先发展自己优势的思路。国外这种开源以及项目创业的一些共性值得我们思考和学习，这里举一个例子， coreos公司他们把他们的目标和使命定义为"secure the internet", 在zookeeper的发展满足不了他们需求的时候，他们能做出这么大的决定重新build一个如此大的项目，并且成功了，成为容器界基本都依赖的一个项目，这个勇气和思路值得学习。
我们的项目前身是hippo，跟google borg相似，采用自建的方式，借鉴了很多mesos的思路，但确没有使用mesos开源版本进行改进，与社区缺乏交流，不能共享mesos社区新的feature，也不能对开源进行影响；另外我们系统暂时也不能对国内技术全产生很大的影响，吸收群体的智慧有限，这是一大遗憾。都说开源是有利益目的的，你认同吗?

从mesos接入docker，想到hippo接入docker

　　为什么想到这个，实际上我们在接入的过程当中踩到了相同的坑，有的mesos解决的好，有的还没有解，可以作为后续改进的一个参考。

mesos和hippo容器化之路 (Containerizer)

容器接入的接口设计

　　我们团队关注docker很早，在hippo启动前就开始就关注docker。
　　14年我们直接用cgroup和namespace等标准的os feature完成了引擎进容器的demo，证明了隔离的可行性。
　　一直想完善我们的隔离，docker开始崭露头角，但docker在2.6.32内核上要跑到生产还不行，而t4在阿里在生产已经跑了一段时间，因此我们14年为了让混布，提高资源利用率，节省成本，选择了t4进行落地。
　　跟mesos一样，在容器技术没有完全统一的情况下，我们当时在设计的时候也考虑了支持不同的容器以及不同的隔离策略，以实现用户的定制需求和可插入性，或者可配置性。
　　mesos在最开始的时候，为了支持External Containerizer，定义了一套回调的脚本接口，用户可以在脚本里完成各个阶段的工作。但docker非常火，连k8s也在学习docker的接口设计理念，而且External Containerizer变得很难用，最终这种方式被废弃掉。
　　hippo是自建方案，有一个好处我们不需要考虑太多其他人的兼容性，这样我们在设计实现的时候，相对的在接口设计方面做得直接些，没有过度设计，从t4到docker基本上，对主体结构代码没有太多的侵入性。createInstance，destoryInstance，checkInstance几个简单的接口不论是什么容器，都适用。
现在的mesos，对docker是native integration。没有额外的setup。只需要docker daemon和docker client。可以说在这方面和hippo是殊途同归了。

容器接入踩了很多坑，还有很多未解决的

　　真的就是3个接口那么简单吗？mesos在接入docker的时候，在处理日志，recovery, tag containers, cgroup资源更新等等踩了很多坑。以docker update为例，docker在1.2以前是一直不支持的，且后续版本也支持的不够。
更能说明这个问题的是如果mesos自己跑在容器里，如何去更新其他容器的资源，因为这个时候已经chroot。mesos采用了一个跑在宿主机的docker exectute的代理（如图2）。这个方案我觉得比我们做的好，我们的pouch(阿里自研容器产品)把很多的逻辑直接做在了docker daemon，这样侵入性太高，跟踪最新的docker版本成本很高，无法及时享受修复的bug以及新的feature。

还讲到一些cgroup的坑，我们最近在升级7u的过程也踩到过。主要是systemd+docker+mesos。这三者都会涉及cgroup节点。在7u中，systemd管控了整个系统的资源。https://issues.apache.org/jira/browse/MESOS-3009 ，他们踩到一些坑复现后发现是docker创建的容器，systemd有在干预它的cgroup。hippo也踩到了这样的坑，对应的内存,cpu限制不住，我们的实际做法是通过采用cgroup driver为systemd，并在pouch里面通过systemd api来控制cgroup来避开这些冲突。

原文链接