京东大规模容器集群之 kubernetes 实践

4 月 22 日，由 K8S 技术社区、Linux 中国联合主办的 K8S GeekGathering 2017 吸引了国内容器领域关注者100+人到场参与，以下是京东容器云产品部总经理郭理靖的演讲实录整理：

大家下午好，我负责整个京东云产品的设计，包括容器、主机等。我分享云计算的下一个时代—容器时代，我会在第一章，讲讲为什么容器时代是云的下个时代，下面几个会讲京东云怎么做容器服务的，接下来会讲容器实践的一些案例，包括我们京东内部的，包括我们客户的。

 

01 容器时代已经到来

当前，容器的占有率可能比想象中还要快地增长，这个是使用 Docker 镜像的受欢迎的程度，可以看到几个排在前面的。然后平均一个公司有多少容器在跑，只有 7 个。但是在 06 年的时候，5 个都不到，其实增长还蛮快。

我觉得这个图挺有意思的，讲的是一个容器的平均生命周期，比较的是容器和未来的生命周期，容器的平均生命周期是 2.5 天，VM 是 23 天，这 2.5 天里面分了两部分，一部分是用了编排，一部分没有用编排。如果用户没有用 K8S 工具，平均的容器生命周期是一天，但是用了 K8S 编排，生命周期是5天，但是这个数据代表了什么意义呢？这个数据最直观的意义是成本，也就是说你用 Docker 也好，用 VM 也好，你可能解决同样的问题，因为 VM 的创建，或者各方面的因素，导致你上手的代价挺大，所以懒得删除了，容器的话很容易，更容易让你删除它。从某种角度上讲，你做同样一件事情，你用容器的成本是用 VM 的 1/9。

我觉得这个数据稍微有点夸张，实际上我们内部和用户的数据体验来看，用容器比 VM 成本降低 50% 一点问题都没有。通过这么一组数据，我想表达一个观点，云计算的下一个时代已经是来临了，而不是三年前说可能是容器，这个数据告诉我们，下一个时代就是容器时代，毫无质疑。

0 2 京东云：将虚拟化和容器结合

容器时代，容器的优点是启动快，应用方便，在虚拟化时代，它的安全是强隔离的，生态也是比较完善，因为经过十年的发展，虚拟化的网络、存储都是相当成熟的。

我们做一个什么事情呢？我们做了把虚拟化和容器结合的工作。我们怎么做？为什么这么做？容器最大的问题是隔离性的问题，毕竟是说它用的技术，理论上存在很多容器逃逸的可能性，历史上发生很多，在一个物理机上起两个容器服务的时候，服务 A 和 B，A 可能很容易逃脱宿主机，拿到容器 B 的数据的权限，因为容器的权限管理很难做，权限给的少用起来不舒服，给得高，应用很容易逃脱。但是这个问题在私有云里面其实并不严重，因为我们在自己的公司里面我们都相信自己开发者开发出的应用是比较安全的，不可能 A 部门的应用读到 B 部门的东西，我们有自己的代码审核机制，安全防范机制，公司内部用传统的容器部署方案没有问题。

公有云上不可能。因为我们永远不知道来的用户是什么人，什么目的，可能是捣乱的，所以我们认为公有云上的用户，应用是不可信的，我们要在公有云上给我们用户提供完整地，安全的服务，让我们怎么做，我们仔细分析 Docker，两部分组成：第一部分是容器部分，用来做隔离，第二部分是 Docker 最创新的地方，用分层的方式存储，可以利用文件系统分级存储，能够快速启动一个容器，其实这个才是 Docker 的精华。因为我们想为什么我们启动虚拟机的时候会慢，慢是有原因的，因为你拉一个镜像就慢了，或者给镜像备份的时候。你这个应用大了，镜像大了，可能会使整体应用慢一些，我们就改写 KVM，让 KVM 适配Docker 的镜像，这样我们利用了虚拟化的安全生态和它的成熟度，同时又保留了容器的启动、体积和应用的优势。

可以看到其实我们做的事情，我们其实，我们的底层还是一个 hypervisor，我们的容器云不能简单说是容器云，为了方便大家理解叫容器云，我们跑 APP 的空间不是 Container，大家知道启动一个虚拟机比较慢，可能要好几分钟，如果大家在公有云用过云主机的话，创建云主机时间比较慢，为什么慢？其实这个慢的过程，跟 KVM 关系不是特别大，关系在于，启动一个 VM 的时候，他认为自己是一个机器，要做很多的引导程序、引导检查这种工作，会导致变慢，但是你在物理机里面的虚拟机，很多工作可以不用做，所以我们在这边启动 VM 的工作进行了简化，同时在，这上面是传统的启动 Docker 的流程，下面是我们启动自己的，叫京东容器 Container 的技术。

03 京东容器云中的 K8S 实践

前面介绍一下我们怎么做容器云服务的，我们在容器云服务里面怎么跟 K8S 结合的。我们对 K8S 改造并不是那么大，大部分用了 K8S 原生的组建和架构，我们只是把容器的运行时换了，里面本来有多个 Container，我们换成 JCLOUDContainer，其他的服务并没有大动。

右侧可以看到，我们跟公有云绑定的，我们的多租户验证与授权管理自己做的。另外，网络和存储，网络接自己开发的 SDN 网络，JCLOUDContainer，跟公有云上创建的云主机，可以放在一个里面，我们支持VM和容器相互通性，每个 JCLOUD，带来便利性，可以放在一块，持久性的存储，我们用的是自己的硬盘，JCLOUDContainer 用的硬盘如果不用了，也可以插到云主机上用。

所以在我们的京东云里面，容器和主机是对等的一个关系，他们都是一等公民，在容器和主机下面，才是我们的云硬盘，我们的网络，监控也是一样，用统一的跟云主机一样的模块。这个图可以让大家很方便看，我们现在容器云服务，京东云容器服务，跟一些传统的其他家或者业界其他做法不一样，如果我们说，如果在一年前，我们说自己用虚拟机搭一套 Swarm 的话，肯定去公有云厂商里面启动一系列的虚拟机，再做。

04 京东容器云的典型应用

接下来介绍京东云的实践之路，介绍我们京东内部是怎么做容器的，同时讲讲内部做容器跟我们在公有云上提供容器服务有什么差异点，以及我们用户是怎么用容器云的，我们有世界上最大的容器集群之一，20 万的容器集群，保证了京东 618，双 11 大促，内部 99% 做了容器化。

内部的做法也是非常标准的做法，本质上并没有跟其他厂商有什么区别，只是在内部的容器化的过程中，我可以讲讲我们经历，因为我们最早还是做虚拟化的。然后在虚拟化的基础上我们做了很多工具，包括我们的子化部署，统一的监控，日志收集，服务发现，整体的管理都是有，我们第一部接触容器的时候没有现在这么彻底，这是最终的图，之前我们采取的做法是，为了减少损耗和风险，我们之前干的第一件事情是把 VM 换成一个容器，先把事情做了，那个时候就是把 VM 换容器最主要的目的是什么呢？主要是把容器用在轻量级隔离，速度和带来的损耗比较少。

第二，容器是隔离技术，对我们重要的一点是可以动态地调整 CPU 内存不影响应用，对大公司很重要，因为很多申请的时候，说 32 核，64G，整体运维没有反抗的余地，他说不给我那么多，影响业务，造成我们资源浪费，资源可调整之后，就方便了。但是我们并没有把 Docker 的精髓用起来，因为 Docker 不仅提供了隔离的方案，还提供了应用分发，还要把我们的自动化部署，把代码和价包拉过来，比较费劲，1.0 过后，到 2.0 的时候，就完全变成真正的容器的K8S的集群，应用也是达到了镜像里面了，不是到我们上面自动拉东西了。

然后我讲讲我们非常典型的应用，就是在容器云内测的，我们已经开始内测了，非常典型的应用就是数据采集，直白一点就是爬虫，都叫数据采集，爬虫比较敏感。爬虫是非常适合用容器做的场景，因为爬虫的应用特别容易做分布式，可能每个应用都长得一样，它的任务可能是爬一个网站，爬完之后就销毁，对于爬虫而言，最大的问题还是在于 IP 的问题，因为爬虫和反爬永远是业界的两个热点，很多人对网站的信息不喜欢被爬，有反爬机制，一段时间的访问请求次数有控制，所以我们提供了很丰富的IP池，包含 100 个 C 的 IP 池，前面两条，灵活这个我们容器解决，但是 IP 这个问题，我们要靠一个大的 IPS 解决，每个用户到我们这里申请 IP 的时候，我们分配得比较均匀。有可能对方把你这个 C 封了，我们有大的 IP 池之后。

这个其实我觉得有点像云计算分时租赁的味道，每个用户去爬取的网站不一样，用户A爬新浪微博，但是用户B爬的是淘宝，被新浪微博的IP也可以访问淘宝，我们对每个用户有黑名单的 IP，可以打一个 tab，下次申请新IP的时候，如果带上新浪这个我不会把黑名单的IP池分配给你，用户有自己分组的黑名单，保证你的 IP 可用，保证你不会拿到被扔到 IP 池的 IP。

下面，我们内部用的微服务，这个概念，大家一定耳熟能详了，我们也一样，我们内部，在京东云上提供的微服务，通过我们的容器的部署去部署上去。当然我们框里面都是微服务，后面像数据库、日志是用 Docker 部署的，不能适用于微服务，我讲讲 Docker 为什么和微服务结合得很紧密，确实说微服务是 Docker 非常好的应用场景，刚才说的爬虫的例子，也是可以很好用容器解决的。很多里面，容器刚好解决了微服务的很多痛点，包括容器共享，大家可以看到，他最少可以做到一个 C 4 兆，小对小刚好匹配上了，每个容器是单独独立的，而且说它是跟应用绑定的。我们有一个用户是做机器学习和基因研究的，他们团队里面有很多个不同部门的工程师，每个工程师用的工具链，工具包完全不一样。

他们运维直接崩溃了，因为每个小组需要的语言和工具链不一样，给每个应用安装部署花很多时间，用容器化就特别容易做这个事情，直接每个小组部门容器化，做微服务的时候，不应该强制每个服务用同样的语言去出现，因为你微服务做得够小，有些微服务需要高效的，有些不需要，不同的微服务需要不同的语言解决反而会提高效率，开发环境和生产环境相同。然后应用是一体化的，那你以前整个微服务的，代码和业面可以共用一套管理体系，我们做微服务的时候希望微服务快速响应，多的时候启多一些，少的话小一些。

纵向的扩容就是内存调整，我们用 Container 的技术。最重要的还是省钱，不管是微服务还好，容器服务也好，最终的目的是提高整个团队开发的效率，部署的效率，我觉得给大家讲一个我的理解和概念，其实用容器和用虚拟机省下来的钱可能只有一点点。

比如你的服务器只有一百台，用容器后可能变成 60 台、 50 台，省下来的钱也许不多，但是在人工上省的钱非常多，我们现在都知道工程师非常贵。如果开发一个东西原先需要 10 个人，现在需要 5 个人，省下来的钱非常多。微服务也好，主要是省人工的。大家要明白容器带来的，或者 K8S 带来的更多的优势不是你节省的机器成本，更多节省你的管理和人员成本。

最后一个场景是我们常见的，比较推崇的 DevOps，开发环境、测试环境、生产环境统一后带来的好处，以及开发环境可以用多个 Container 的时候，如果你能在自己的环境里面，因为每个开发者都有自己的笔记本，在自己的笔记本里面可以很轻松地搭建完整的开发环境的话，效率非常高，哪怕加自己的两台虚拟机可以搭建起来的话，那个是非常重要的，我们在大公司开发会发现，你的工程进度不取决于你写代码的速度，取决于其他团队跟你协调的速度，或者对方把这些东西写好了，你要部署起来，这个挺费时间，如果你自己有相对比较完整的开发环境的话，你不依赖于别人的进步，对每个开发者而言是效率提高的，在这个效率提升来讲，我个人认为是非常划算的。

我们非常推崇走这个 DevOps 路线，保证自己有完整的开发环境，每个团队做这样的微服务的架构，每个模块，可以，不是以人与人为主，是以文档为主，可以有效提高我们的效率，所以不管是容器好还是K8S还好，微服务也好，这种理念是整个团队所有人认可之后，才能产生应该有的效率。以上就是我的整体分享，非常感谢大家的时间。

点此下载演讲 PPT，下载提取码:  uyvf