干货 | 携程云原生基础设施演进之路
作者简介
周昕毅，携程系统研发部云平台高级研发经理。目前负责携程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在携程的落地，大家分工进行各技术栈容器镜像规范制定、镜像打包平台建设、PAAS平台与Mesos平台对接、下一代网络方案调研及落地。
在验证了大规模Mesos集群的稳定性之后，团队将之前运行在虚拟机上的java应用分批次迁移到Mesos集群。至此，团队的工作重心从资源交付转向应用交付，研发新申请容器实例到投产平均仅需30秒的时间。
在Generation2.0的时期，大家逐步认识到容器化带来的实际优势，不可变基础设施的理念不仅帮助了运维团队减轻工作，也为研发团队提升了交付效率，各业务积极配合容器化改造，JAVA应用容器化覆盖率在很短的时间内超过90%。
三、Generation2.5：Ctrip Paas + Kubernetes平台化
在基于Mesos平台快速完成JAVA应用容器化之后，我们也挖掘出了更多的需求：Python/Nodejs/golang等多语言技术栈需要进行容器化改造；调度系统的需求越来越复杂（应用分散策略，CPU绑定，网络Qos，指定CPU指令集的调度）；部分应用有强烈的自动扩容缩容的需求等。越来越多的应用侧需求需要下沉到基础设施层（在当前阶段是容器编排调度平台）来实现。
在连续几个月进行Mesos调度器的二次开发工作之后，我们发现Kubernetes社区也越来越活跃，Kubernetes很快演进成了一套Production Ready的容器调度平台。在评估了工作成本和风险之后，团队在2018年初启动了Mesos至Kubernetes的迁移。同时，Ctrip PAAS平台已借助Kubernetes的底层能力，为研发提供了更丰富的服务。
图2 Ctrip DataCenter OS & Kubernetes整合
图3 Ctrip研发服务平台
在Generation2.5时代，我们完成了数千个Node规模的Kubernetes集群建设，接入了携程超过1万个线上应用，覆盖了Java/Nodejs/Python/golang等主流技术栈。期间团队在DockerDaemon稳定性、内核方面踩坑多次，投入很多精力进行了相关问题的排查和解决，确保平台上业务的持续、高效、稳定运行。在集群规模大了之后，底层网络的问题陆续多了起来，大集群的快速扩容、高频次的HPA，现有Neutron集中式IPAM分配管理机制已经成为了瓶颈。
图4 Generation2.5 Neutron组件监控看板
我们发现部分应用也仅仅是完成了容器化，即部署模式从物理机或虚拟机换成了Docker容器（Cloud Hosting任务达成）。而Kubernetes基础设施平台化能够带来的好处还包括：中心化的资源编排可以最大限度的减少资源浪费(前提是Kubernetes覆盖足够大)；强大的管控能力让各领域专家的精力可以集中在领域本身，运维、部署、容灾、分布式、资源分配等繁琐工作由Kubernetes来统一解决；Kubernetes社区的活跃度也可以让业界一流的架构和技术快速在自己的组织中落地。这几大好处促使我们不满足于Cloud Hosting，掀开了下一阶段工作重心：Cloud Native basedon Kubernetes的序幕。
四、Generation3.0：Cloud Native & Kubernetes
1991年9月Linux0.0.1版本的发布震动了整个开源界，Linux自由与分享的哲学在开源界传承至今。2015年,Google发布了Kubernetes 1.0版本，Kubernetes在2017年开始成为了容器编排系统的事实标准。在携程云平台基础设施从2013年至今不断演进的过程中，我们愈发认同Jim Zemlin的观点：‘Kubernetes is becoming the Linux of the cloud’。我们团队目前致力于打造Cloud Native基础设施，追求更高资源利用率、更快部署速度、更强应用治理能力。
图5 Kubernetes统一控制平面
目前携程已经接入Kubernetes的应用类型包括：在线应用、ElasticSearch集群、Redis集群、Spark离线计算job集群、AI协作平台等，其中在线应用集群具有显著的波峰和波谷，可以利用混部将波谷资源释放给CPU密集型的离线计算Job，可以显著提升集群资源利用率。如下图：
图6 混步后的资源利用率提升
集中式的Kubernetes集群监控工具可以快速识别各种潜在异常：
图7 携程云管平台Kubernetes集群体检中心
在提升Provision速度方面，团队主要围绕两个方面进行优化工作：一是打造容器镜像管理平台，快速构建新镜像，按需分发至多地数据中心，基础镜像提前下发预热，宿主机镜像多数据中心就近下载。二是进行新一代容器网络架构调整，解决集中式IPAM的瓶颈，提供更加”云原生”的网络解决方案。
Cilium on Kubernetes的网络架构基于ebpf技术、容器间通信的链路更短；Node级别的IPAM与Neutron相比更高效，也降低了全局性网络故障的潜在风险。
Cilium是Kubernetes Native的一套高性能、高动态的网络解决方案，可以原生支持私有云和公有云，同时可以适配OpenStack、为后续管理VM和物理机管理提供了备选方案。Application层面，Cilium原生支持所有Kubernetes的资源，可以在应用无感知的情况下对网络进行透明的拦截(ebpf技术)，对混沌工程的支持非常方便。
图8 Cilium on Kubernetes
Infrastructre as Code实践：
图9 Infra as Code实践
Kubernetes平台为Infrastructure as Code实践提供了绝佳的平台，我们基础设施的各类管理服务都在使用IAC的方式进行部署和统一管理，在提升稳定性和运维效率的同时享受云原生带来的社区红利。
基于Cilium，我们同时进行Network Control as Code实践，为混沌工程中的网络故障模拟场景提供了便捷落地的可能；同时，基于内核和ebpf我们可以从底层进行网络排障工具研发，从底层定位各类网络侧疑难杂症的根因。
图10 & 图11：Network Control as Code实践
五、写在最后
在线应用的底层基础设施变更有一定风险，需要投入较多人力进行迁移方案设计，“给高速飞行中的飞机换零件”挑战在于：运行中的系统给迁移方案带来了诸多先天限制，原则上只允许成功，不允许失败。
现在云计算的发展日新月异，不断有新的技术和架构出现，各领风骚三五年，要求架构师们具备一定的技术前瞻性和敏锐的嗅觉，同时在设计架构时需要考虑底层变更的成本。Cloud Native架构的开放性和包容性及其对于更高的资源利用率、更快的部署速度、更强的管控能力的不断追求，让我们相信这是值得持续投入的正确道路。
注：携程技术微信公众号后台回复“云原生”，可下载讲师分享PPT。
【推荐阅读】
“携程技术”公众号
分享，交流，成长