中国最大电商公司之一的京东，最近分享了自己通过 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 解析服务。
评论