干货 | 携程云原生基础设施演进之路

作者简介

 

周昕毅，携程系统研发部云平台高级研发经理。目前负责携程K8S平台运维管理、分布式存储和云平台网络组件研发及运维管理。熟悉云基础设施建设，从事运维自动化及DevOps工具研发工作十年以上。长期关注云原生技术领域，Infrastructure AS Code理念的坚定践行者。

随着虚拟化技术和云计算技术的普及，IT互联网基础设施发生了很大的变化，计算、存储、网络等底层架构也越来越复杂。本文主要介绍携程云平台团队在追求云原生的道路上不断演进携程云基础设施的历程，包括架构选型的思路和踩坑经验的总结。

一、Generation1.0：OpenStack & IAAS平台建设

携程云1.0时代，云平台团队基于OpenStack构建IAAS平台，旨在提升资源交付效率、统一资源交付标准。虚拟化网络方案基于OpenStack Neutron及Openvswitch技术实现，网络架构是传统的大三层架构。网络架构如下图：

图1 传统大三层网络架构示意图

 

经过对OpenStack nova调度器的优化、KVM/Vmware镜像自动下发，虚拟机的交付时长稳定在2分钟至5分钟左右。但由于虚拟机和物理机镜像的管理成本较高，IAAS平台仅负责交付标准的预装OS(如Ubuntu1604/CentOS71/CentOS76/Windows2012等)，在postinstall过程中安装Provision系统的agent（比如SaltStack Minion），代码运行环境的标准化是由Provision系统来实施。再加上CMDB、负载均衡系统、自动发布系统等对接的步骤，从用户申请虚拟机到可以提供线上服务，预期时间在20分钟到30分钟之间。

二、Generation2.0：容器化推进 & Mesos平台建设

2015年底开始，云平台开始进行容器化的尝试。由于前几年在OpenStack平台积累了很多经验，团队在第一时间选择用novadocker组建来进行容器化落地。

容器的网络方案与Generation1.0时代的虚拟机网络模型保持一致，继续使用Neutron+Openvswitch来落地，这样节省了很多网络选型和测试的时间。

Novadocker的调度模式与虚拟机类似，第一次实例创建后即落地在固定的宿主机上，因此内部又将novadocker创建出的容器定义为“胖容器”。胖容器接入了部分生产业务并稳定运行之后，大家觉得在稳定性方面容器和VM并没有太大差异，很快我们启动容器调度平台的选型，让容器实例“动”起来。

2016年初，在调研了Docker Swarm、Mesos、Kubernetes之后，团队普遍认为Mesos最为成熟，于是着手开始进行Mesos在携程的落地，大家分工进行各技术栈容器镜像