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

2020 年 2 月 19 日

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

随着虚拟化技术和云计算技术的普及,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


2020 年 2 月 19 日 20:30227

评论

发布
暂无评论
发现更多内容

【求锤得锤的故事】Redis锁从面试连环炮聊到神仙打架。

why技术

redis 分布式锁 分布式系统

原创 | 使用JUnit、AssertJ和Mockito编写单元测试和实践TDD (十三)编写测试-生命周期方法

编程道与术

Java 编程 TDD 单元测试 JUnit

Redis持久化了解一波!

不才陈某

redis 程序员 后端

架构学习历程

机器学习算法评估指标——2D目标检测

做技术BP的文案Gou

游戏夜读 | 2020周记(5.24-5.31)

game1night

MySQL实战笔记-事务隔离和MVCC

shiziwen

MySQL 学习 事务隔离级别

开源分布式文件系统大检阅

焱融科技

sds 存储 开源项目 焱融科技 文件存储

Linux 自动化运维工具 ansible

杨仪军

Linux 运维自动化

一个人,沿着童年的路究竟可以走多远?

zhoo299

童年 NASA 航天

情绪的力量:如何使用情绪来达成目标

七镜花园-董一凡

情绪

Vue生态篇(二)

shirley

Vue

从技术到管理,我在极客时间的成长历程

邓建春

Go语言分布式系统配置治理

田晓亮

微服务

MySQL的各种日志

超超不会飞

MySQL

ARTS 第二周打卡

陈文昕

杂谈-JSONP探索

卡尔

Java jsonp

互联网时代的界限管理

非著名程序员

程序员 职场 提升认知 界限管理

程序员修炼的务实哲学

博文视点Broadview

程序员 软件 编程思维 工程师 编程之路

产品经理的商业能力

夜来妖

程序人生 产品经理 商业 商业模式 商业价值

信息的表示与存储-整数的表示

引花眠

patroni 通过服务启动报错

yafeishi

数据库 高可用 AntDB

这些Java8官方挖的坑,你踩过几个?

码大叔

Java 踩坑 加密 「Java 25周年」

匆忙的一周 ARTS第二周

困到清醒

关于区块链的“去中心化”,90% 的人都搞错了

CECBC区块链专委会

CECBC 区块链技术 去中心化 专制

[Redis] 你了解 Redis 的三种集群模式吗?

猴哥一一 cium

redis redis高可用 redis哨兵模式 群集安装

从 0 到 1 搭建技术中台之发布系统实践:集泳道、灰度、四端和多区域于一体的设计与权衡

伴鱼技术团队

架构 系统设计 系统架构 系统性思考 架构设计

Python 自动化办公之"你还在手动操作“文件”或“文件夹”吗?"

JackTian

Python 自动化

这是一个测试文档

Geek_073cad

我的 windows 利器

玄兴梦影

工具

【Java 25周年有奖征文获奖名单公布!!!】关于Java,你最想赞扬、吐槽、期待的变化是什么?

InfoQ写作平台

写作平台 Java25周年 活动专区

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