美团的容器集群管理平台叫做 HULK 。漫威动画里的HULK在发怒时会变成“绿巨人”，它的这个特性和容器的“弹性伸缩”很像，所以我们给这个平台起名为HULK。貌似有一些公司的容器平台也叫这个名字，纯属巧合。
2016年，美团开始使用容器，当时美团已经具备一定的规模，在使用容器之前就已经存在的各种系统，包括CMDB、服务治理、监控告警、发布平台等等。我们在探索容器技术时，很难放弃原有的资产。所以容器化的第一步，就是 打通容器的生命周期和这些平台的交互 ，例如容器的申请/创建、删除/释放、发布、迁移等等。然后我们又验证了容器的可行性，证实容器可以作为线上核心业务的运行环境。
2018年，经过两年的运营和实践探索，我们对容器平台进行了一次升级，这就是容器集群管理平台HULK 2.0。
把基于OpenStack的调度系统升级成 容器编排 领域的事实标准Kubernetes（ 以后简称K8s ）。
提供了更丰富可靠的容器弹性策略。
针对之前在基础系统上碰到的一些问题，进行了优化和打磨。
美团当前的容器使用状况是：线上业务已经超过3000多个服务，容器实例数超过30000个，很多大并发、低延时要求的核心链路服务，已经稳定地运行在HULK之上。本文主要介绍我们在容器技术上的一些实践，属于基础系统优化和打磨。
美团容器平台的基本架构
首先介绍一下美团容器平台的基础架构，相信各家的容器平台架构大体都差不多。
首先，容器平台对外对接服务治理、发布平台、CMDB、监控告警等等系统。通过和这些系统打通，容器实现了和虚拟机基本一致的使用体验。研发人员在使用容器时可以和使用VM一样，不需要改变原来的使用习惯。
此外，容器提供弹性扩容能力，能根据一定的弹性策略动态增加和减少服务的容器节点数，从而动态地调整服务处理能力。这里还有个特殊的模块——“服务画像”，它的主要功能是通过对服务容器实例运行指标的搜集和统计，更好的完成调度容器、优化资源分配。 比如 可以根据某服务的容器实例的CPU、内存、IO等使用情况，来分辨这个服务属于计算密集型还是IO密集型服务，在调度时尽量把互补的容器放在一起。
再比如， 我们可以知道某个服务的每个容器实例在运行时会有大概500个进程，我们就会在创建容器时，给该容器加上一个合理的进程数限制（ 比如最大1000个进程 ），从而避免容器在出现问题时，占用过多的系统资源。如果这个服务的容器在运行时，突然申请创建20000个进程，我们有理由相信是业务容器遇到了Bug，通过之前的资源约束对容器进行限制，并发出告警，通知业务及时进行处理。
往下一层是“ 容器编排”和“镜像管理 ”。容器编排解决容器动态实例的问题，包括容器何时被创建、创建到哪个位置、何时被删除等等。镜像管理解决容器静态实例的问题，包括容器镜像应该如何构建、如何分发、分发的位置等等。
最下层是我们的容器运行时，美团使用主流的 Linux+Docker容器 方案， HULK Agent 是我们在服务器上的管理代理程序。
把前面的“容器运行时”具体展开，可以看到这张架构图，按照从下到上的顺序介绍：
最下层是CPU、内存、磁盘、网络这些基础物理资源。
往上一层，我们使用的是CentOS 7作为宿主机操作系统，Linux内核的版本是3.10。我们在CentOS发行版默认内核的基础上，加入一些美团为容器场景研发的新特性，同时为高并发、低延时的服务型业务做了一些内核参数的优化。
再往上一层，我们使用的是CentOS发行版里自带的Docker，当前的版本是1.13，同样，加入了一些我们自己的特性和增强。HULK Agent是我们自己开发的主机管理Agent，在宿主机上管理Agent。Falcon Agent同时存在于宿主机和容器内部，它的作用是收集宿主机和容器的各种基础监控指标，上报给后台和监控平台。
最上一层是容器本身。我们现在主要支持CentOS 6和CentOS 7两种容器。在CentOS 6中有一个container init进程，它是我们开发容器内部的1号进程，作用是初始化容器和拉起业务进程。在CentOS 7中，我们使用了系统自带的systemd作为容器中的1号进程。我们的容器支持各种主流编程语言，包括Java、Python、Node.js、C/C++等等。在语言层之上是各种代理服务，包括服务治理的Agent、日志Agent、加密Agent等等。同时，我们的容器也支持美团内部的一些业务环境，例如set信息、泳道信息等，配合服务治理体系，可以实现服务调用的智能路由。
美团主要使用了CentOS系列的开源组件，因为我们认为Red Hat有很强的开源技术实力，比起直接使用开源社区的版本，我们希望Red Hat的开源版本能够帮助解决大部分的系统问题。我们也发现，即使部署了CentOS的开源组件，仍然有可能会碰到社区和Red Hat没有解决的问题。从某种程度上也说明，国内大型互联公司在技术应用的场景、规模、复杂度层面已经达到了世界领先的水平，所以才会先于社区、先于Red Hat的客户遇到这些问题。
