内容来源：2017年4月21日，京东云产品部总经理郭理靖在“K8S技术社区”进行《云计算的下一个时代——“容器时代”》演讲分享。IT 大咖说（Id : itdakashuo）作为独家视频合作方，经主办方和讲者审阅授权发布。

阅读字数：2329 | 4分钟阅读

嘉宾演讲视频地址：suo.im/4OjYfk

摘要

随着容器技术的发展，容器成为了目前最受欢迎和关注的项目。京东在容器的实践过程中，结合虚拟机，对容器技术做了优化和改进，他们是怎么做的？

容器趋势分析

在容器和服务发现相关的内容里，docker和kubernetes排在前面。在整个工具链里，docker、jenkins和kubernetes比较受用户的关注。

容器是未来的一个趋势。我在2013年的时候就开始接触容器，后来发现docker开源之后非常合适我们，所以我们就开始在内部尝试容器化。

我们坚信容器是下一个未来，是将来的大主流，所以容器上面的编排是非常重要的。据数据显示，用容器的公司在九个月之内都会把自己容器的规模double一下。未来容器占有率的增长速度可能会比我们想象的还要快。根据我们内部以及用户的数据来看，用容器比用VMS的成本降低约50%。

通过这么一组数据，我想表达一个观点，计算的下一个时代已经来临了。

京东做容器有很长一段时间了。我们从2003年开始应用容器，到2006年的时候，京东内部已经大规模容器化。

传统的虚拟化技术就是在宿主机里套一层虚拟机管理软件，让虚拟机去做所有的安全隔离修复。而容器的优点就在于启动快体积小，应用发布方便。

在虚拟化时代，它的安全是强隔离的，生态也比较完善。经过十年的发展，虚拟化的网络存储都相当成熟。我们把虚拟化和容器结合了起来。

容器最大的问题还在于隔离性。虽然我们相信自己开发出的应用比较安全，可以在公司内部用传统的容器部署方案，但在公用云上不行，因为我们永远不知道各种各样的用户有什么目的，公用云用户的应用是不可信的。我们要在公用云上给我们的用户提供完整安全的服务。

有时启动一个虚拟机会更慢，可能因为是拉一个镜像就使它变慢了，或者给自己的镜像做备份的时候里面装一些应用。应用和镜像大了，整体的启动就会慢一些。我们启动VM工作进行了一些简化，改写了KVM，让KVM适配docker标准的镜像。既利用了虚拟化的安全、生态和它的成熟度，同时要保留容器启动速度、体积和应用的优势。

我们也提出了很多标准化的东西。我们的接口、模块都是标准化的，并兼容docker的API管理工具，有很好的兼容性。

蜂鸟的容器云服务核心是多样化配置。传统最小的云主机一般是1核1G，但在蜂鸟容器云服务里，最小的配置可以做到1核64兆，成本缩减了1/12。

JCLOUD容器和我们在京东云上创建的云主机可以放到同一个VPC里，也就意味着我们支持VM和容器相互通信。

存储的插件也是我们自己做的。京东云借鉴了OpenStack所有API的设计和架构。存储这一块我们用的是自己的云硬盘。在京东云里，容器和主机是对等关系，它们共用底下的网络和存储。

京东容器云服务和传统的一些业界做法不太一样。我们把虚拟机和容器融为一体，和网络深度结合。

我们保留了Kubernetes的原生组件，换了POD，还有网络和存储。

京东有世界上最大的容器集群之一，能保证京东618、双11的大促。我们内部99%的应用已经做好了容器化。刚接触容器的时候，为了减少损耗和风险，我们把VM换成容器。但还没有利用到docker的精髓。因为Docker不仅提供隔离的方案，还有提供应用分发的解决。直到2.0版本的时候，才变成一个真正的容器kubernetes集群，应用也可以double到镜像里。

在容器工具层内部，我们开始用的是docker。如果直接用docker的话，在公用云里面是没法直接提供服务的，所以我们把这个容器工具改造hypervisor，这样就能给用户提供安全的隔离。内部我们用的网络比较简单，在外部我们组建了一个很强网络团队，去开发CDN网络，毕竟公用云环境跟内部的环境是完全不一样的。在公用云里稍微有一些定制化。内外部容器最大的不同主要是这些。

容器云有一个非常典型的应用，就是数据采集，我们也可以叫爬虫。对于爬虫最大的问题还是ip。我们提供了丰富的ip池，包含了一百个C的ip。每个用户来申请ip的时候，都会给它分配均匀。每个用户爬取采集的网站是不一样的。所以我们对每个用户都有一个黑名单的ip，这样就能保证每个ip都是可用的。

对于微服务的概念大家可能已经耳熟能详了。我们在京东云上面提供的电商云服务，就是电商云标准的一个微服务框架。我们先是把电商中心、用户中心、商品中心、客服中心这些拆成一个微服务，通过容器部署上去。

微服务是docker非常好的应用场景，也是业界用得最大的应用场景。

很多企业里微服务还是用得最多的一个场景。容器刚好解决了微服务的好多痛点。容器够小，微服务也小，刚好可以匹配，解决部署微服务对机器数量的要求。每个容器都是独立的，而且是和应用绑定，容器刚好能解决微服务多语言的问题。

做微服务的时候不应该强制每个服务用同样的语言实现。每个服务有自己不同的使命，对于不同的服务，应该采用不同的语言去解决，反而能够提高效率。

容器的横向扩容和纵向扩容跟微服务息息相关。

不管是微服务还是容器服务，最终目的还是要提高整个团队开发和部署效率。

其实用容器和用虚拟机省下来的钱可能只有一点点，但是在这个人工上省的钱是非常多的。所以微服务和容器主要的优势不是节省的机器成本，而是节省管理和能源上的成本。

DevOps的开发环境、测试环境和市场环境统一化之后带来的好处就是，如果有一个相对比较完整的开发环境，不依赖于别人的进度，对每个开发者而言，效率能够提高升很多。

不管是容器也好，微服务也好，这种理念需要整个团队所有人都认可之后，才能产生这个工具应该产生的效率和效用。