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

阅读数:1 2020 年 2 月 19 日 20:30

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

随着虚拟化技术和云计算技术的普及,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 基础设施,追求更高资源利用率、更快部署速度、更强应用治理能力。

4.1 关于更高资源利用率

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

图 5 Kubernetes 统一控制平面

目前携程已经接入 Kubernetes 的应用类型包括:在线应用、ElasticSearch 集群、Redis 集群、Spark 离线计算 job 集群、AI 协作平台等,其中在线应用集群具有显著的波峰和波谷,可以利用混部将波谷资源释放给 CPU 密集型的离线计算 Job,可以显著提升集群资源利用率。如下图:

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

图 6 混步后的资源利用率提升

集中式的 Kubernetes 集群监控工具可以快速识别各种潜在异常:

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

图 7 携程云管平台 Kubernetes 集群体检中心

4.2 关于更快的部署速度

在提升 Provision 速度方面,团队主要围绕两个方面进行优化工作:一是打造容器镜像管理平台,快速构建新镜像,按需分发至多地数据中心,基础镜像提前下发预热,宿主机镜像多数据中心就近下载。二是进行新一代容器网络架构调整,解决集中式 IPAM 的瓶颈,提供更加”云原生”的网络解决方案。

Cilium on Kubernetes 的网络架构基于 ebpf 技术、容器间通信的链路更短;Node 级别的 IPAM 与 Neutron 相比更高效,也降低了全局性网络故障的潜在风险。

Cilium 是 Kubernetes Native 的一套高性能、高动态的网络解决方案,可以原生支持私有云和公有云,同时可以适配 OpenStack、为后续管理 VM 和物理机管理提供了备选方案。Application 层面,Cilium 原生支持所有 Kubernetes 的资源,可以在应用无感知的情况下对网络进行透明的拦截 (ebpf 技术),对混沌工程的支持非常方便。

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

图 8 Cilium on Kubernetes

4.3 关于更强的应用治理能力

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 架构的开放性和包容性及其对于更高的资源利用率、更快的部署速度、更强的管控能力的不断追求,让我们相信这是值得持续投入的正确道路。

作者介绍

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

本文转载自公众号携程技术(ID:ctriptech)。

原文链接

https://mp.weixin.qq.com/s/quJVriicGMmXvZZmWViKzg

评论

发布