中国最大电商公司之一的京东，最近分享了自己通过Kubernetes对基于应用程序容器的基础架构进行革新，取代OpenStack托管的IaaS基础架构过程中所获得的经验。本次迁移同时涉及内部网络组件，借此可将资源利用率提高30%。
在采用应用程序容器技术之前，京东的基础架构部署经历了两个阶段：物理机（2004 – 2014）以及操作系统容器（2014 – 2016）。第一阶段主要使用手工管理的裸机硬件，但这一阶段遇到了很多问题，例如上线前的准备时间过长（从分配到应用程序上线约需要一周时间），缺乏隔离机制，资源利用率不足，调度机制不够灵活。计算机失败后往往需要花费数小时迁移应用，且缺乏自动缩放能力。工程团队针对日志收集、自动化部署、编译和打包，以及资源监视等常用任务开发了内部工具。
京东基础架构的第二阶段开始采用容器技术。当时使用了操作系统容器，这意味着需要将现有应用程序和部署架构整体迁入容器中。当时的容器可以看作是对他们原本采用的物理机进行精简后一种运行速度更快的“物理机”，并未采用已经完全成熟的“容器哲学”。
尽管如此，通过采用容器技术，他们已经在第二阶段从时间和资源的使用率方面获得了巨大的收益。当时他们使用OpenStack作为编排层，并使用nova Docker驱动实现容器的管理。该团队选择Docker作为自己的容器平台，并逐渐向其中增添新的功能。所有应用陆续迁移到容器中，借此将计算资源请求的实现时间从原本的一周缩短至几分钟。应用程序的平均部署密度和物理机的利用率提升了三倍。该团队还针对部署任务构建了统一的API，公司内部将其称之为JDOS（JD Datacenter Operating System）1.0。
他们基于OpenStack的平台通过一个群集承载了大约4000至10000个计算节点。截至2016年11月，京东团队共运行了将近150,000个容器。这个平台帮助他们顺利度过了两次大流量在线促销活动，包括2016年双十一活动，共完成大约3千万个订单。
在第二阶段迁移至容器技术后，该工程团队已经可以对部署架构进行改动，使用容器作为基本的部署单位。公司内部将其称之为JDOS 2.0。这个方法关注的并非基础架构本身的管理，而在于可感知应用程序的容器管理。他们的平台设计包含两个抽象：系统和应用程序。一个“系统”可包含多个“应用程序”，每个应用程序可包含多个提供相同服务的Pod。一个系统对应着一个Kubernetes名称空间。
其他组件还包括部署流程和容器化的DevOps工具，这些内容均部署在Kubernetes管理的平台上，此外还包括Gitlab、Jenkins、Logstash、Harbor、Elasticsearch，以及Prometheus。部署过程中，源代码和Dockerfile会被推送至代码库和Jenkins构建。Jenkins被配置为主从模式，其中从节点负责构建和打包应用程序，此外还有一个类似的节点负责构建容器映像。他们使用了Harbor这一开源的Docker注册表存储所创建的映像。
图片来源：http://blog.kubernetes.io/2017/02/inside-jd-com-shift-to-kubernetes-from-openstack.html
为了在Kubelets和OpenStack Neutron之间实现更好的集成，京东根据Container Networking Interface标准自行开发了一个名为Cane的解决方案。在创建、删除或修改Kubernetes负载均衡器后，Cane可以通知Neutron负载均衡即服务（LBaaS）系统。此外他们通过在Cane内部运行的Hades组件为Pod提供内部的DNS解析服务。
本文转自d1net（转载）
