携程万台规模容器云平台运维管理实践

作者简介

周昕毅  

携程系统研发部云平台高级研发经理

前言

我分享的主题是“万台规模容器云平台运维管理实践”，给大家分享一下在携程私有云平台管理的实践过程中踩过的坑和遇到的问题，几年前分享的主题是“携程云平台 DevOps 时代发展历程”。今天的分享主要有以下三部分：

第一部分携程容器云的概览，有哪些组成部分
第二部分从实践的角度讲一下我们的团队如何对容器云进行管理
第三部分做一些总结和对未来发展方向的展望

一、携程容器云概览

携程目前是三个自建的数据中心再加上公有云，在阿里云、腾讯云、AWS 都购买了一些资源。携程的应用目前也有六千多个，包含了酒店、机票、汽车票、商旅各个业务部门，每个部门都有自己的研发团队负责应用代码的开发。

我们团队就负责为这些内部的业务部门提供基础设施，之前部署应用的时候是提供物理机，后来迈入容器时代，不再关注基础设施的事情。现在容器云有两千台的级别，生产发布七八千次，一次发布就是一个应用的版本，所以发布频率还是很频繁的。

2015年底的时候还是用 python 做容器调度管控，当然现在 node.js 有自己的优势。我们团队也吸取先进的经验，全面把我们的容器调度管理平台迁移到 K8S 。携程代码调度平台，很早期用 Application ，后面携程转入了代码技术栈非常多，主流的之外的就是 java 、node.js 、 python、php ，这一块保证每个研发团队按照我们的参数配置来做，这都是有一定的定制方案，是需要制定标准的。

资源方面我们以私有云为主，遇到突发流量会在公有云上面扩虚拟机。携程的高峰也是可以预期的，暑期是一个旅游的高峰，十一之前有会有一个很大流量的高峰，春节期间也是很大流量的。在这个阶段我们需要应用公有云的弹性来支撑我们的流量，日常我们还是以私有云为主，可以节省一定的成本。

部署在容器云上的应用目前分为两类：一种是标准应用，也就是 java 的应用程序，或者 python 的程序；第二类是 Application ，当然 Cache 的管理是比较大的话题，它也是在容器云上跑。

携程容器云技术选型主要分为三个阶段：

第一个阶段，携程从2015 年开始实施 OpenStack ，2014年所有数据中心都具有了 OpenStack 的能力，因为我们对 OpenStack 特别熟悉，所以第一个也会用 OpenStack 部署。

之后开发了 NovaDocker ，避免应用的顾虑，有些业务团队不希望基础设施做比较大的变革，会对性能和稳定性方面有些顾虑。

但是为了尽快迈出这一步，我们采用了相对折中的方式，通过 OpenStack 交互虚拟机的方式，当然这也有不好的地方，就是调度方式不灵活，因为容器时代跟虚拟机的调度和编排的需求不太一样，虚拟机部署出来它的生命周期就是上线周期到下线，容器需要更强的调度迁移的能力。

第二个阶段，到了2016年我们觉得 OpenStack 管理容器的方式很难支撑下去了，当时业界最火的调度技术是 Mesos ，我们调研了 Mesos 并在它的基础上自研了 framework 。

第三个阶段，从2017年到2018年两年时间，我们发现 Mesos 的社区越来越不活跃了，遇到问题也是自己解决，没有社区的力量。

调研之后我们决定全面投向 Kubernetes ，同时交付容器给用户这么一个概念，你在不适用申请虚拟机的情况下虚拟容器了，你申请的是服务，我们容器云给你提供服务，这个服务包括数据的容器、缓存的容器，我们提供一个 PAAS 服务给到团队。

我们容器云的中间一层是 CDOS ，模仿京东的 JDOS ，我们容器云把所有数据中心管控起来，像操作系统一样，把底层的计算资源、网络资源、存储资源以容器云 PAAS 的方式提供给客户使用，在 CDOS 上层有各大系统和业务框架的系统，包括SOA，相当于携程容器云在携程里处于数据中心的统一交付接口。

当然我们自身也集成了调度编排、日志监控、存储资源、镜像管理，用统一的方式交付给研发团队比较一致的交付体验。

前面讲了这么多会觉得容器云是比较复杂的系统，需要支持非常多的资源管理。基于传统的运维管理方式需要做一些变化，否则无法面对这样的挑战。

这两年做了比较大的转变，我们很少提 IAAS 这个概念了，做这个项目的时候每天都在说 IAAS ，把基础设施以服务的方式提供出来，这样还是跟不上业务的需求，现在全面转向 PAAS ，我要去申请一个机器或者申请IP直接给你服务，你不需要关注服务跑在物理机上还是容器上，它后台服务的IP地址是什么都不需要去关注。

我们一开始想的是，只要把技术平台搞稳定就行了，但是对于业务的需求来说它是希望我们提供秒级发布的体验，我们基础设施团队不能拖研发团队的后腿吧。

这个时候我们告诉他发布要排队肯定是不行的，我们容器云支撑秒级的发布。关于智能化也在做尝试，但是目前还是在小范围的探索阶段，没有在大规模用于什么，所以我的分享主要是在 AIOps 全面落地之前用一些相对比较传统的方式管理我们的容器云。

容器云有一个比较大的好处，我们具备了弹性计算的能力和应用容量预估的技术基础，最终可以实现提升资源利用率的目标。

在几年前业务团队申请虚拟机的时候，我们一旦给了用户虚拟机就很难动它了，因为业务部门总有种种理由说，首先我虚拟机迁移是有成本的，而且用户究竟在虚拟机里装了什么软件，做了什么特殊的配置我们是很难控制的。

但是在容器云的时代我们完全不管这些了，每一次的容器发布都是做重新的调度，每一次可以给全新的容器，而且确保跟上一个版本完全一样，因为用户没有权限做修改。这到底有什么好处呢？假设我本来有十台虚拟机，很难说把某台数据机腾出来，因为虚拟机的迁移成本比较高。

二、携程容器云运维实践

2.1 面对的挑战

容器云面对各种各样的挑战，从基础设施角度来讲，我们要集成计算资源的合理管理，还有存储的管理。存储的管理现在用 Ceph 来做的。

从网络层面IP的数量其实会有指数级的上升，虚拟机的时代可以单机多应用，会把部分部署在同一个虚拟机上，容器我们强制是单容器单应用，因为每个容器只能是由一个镜像导出来的，这一块只能强制用一个代码。

我们目前网络架构是单容器单架构，这样导致容器的数量比较多，IP数量也会多十倍，这样要上一套 SDN 的管理方案来进行多个 VPC 的隔离，传统虚拟机的管理方式已经不够用了。

第二个挑战也是每个做容器云遇到的挑战，也就是资源隔离相关的问题。每个业务的峰值是不一样的，如何保证每个业务容器CPU需求和网络流量突发过来的时候，它不影响其他的应用？这也是非常大的挑战。由于容器本身的特性，假设你用GBM自带的值取Disk的值，是获取到宿主机的值。这个 Defunct Process 是一个比较好的值，这时候重启机器的话，一个容器出现了 Process ，剩下的容器都要被迁移走。

还有如何平衡好 CPU Throttle Time ， Throttle Time 出现的时候也就是代表某一个容器没有办法申请时间段，几毫秒可能变成了几十毫秒。现在搞容器云投入专人来研究内核，因为容器的特性导致系统调用对内核增加额外系统调用，在3.10内核上造成各种容器相关的 systemd ，一旦出现内核死锁它的影响就很厉害的。还有多个版本升级非常快，从1.6到1.7、1.8到后面11.0、18.0，我们是否跟着升级每一个版本？还有解决遗留Bug，是否跟着社区的步伐？如果单独维护分支的话，没有BAT公司规模的话，从人力资源来说是比较难有这样的投入。

2.2 基础运维

刚才说了一些运维的挑战，回到运维基础来说，我们做了四个方面运维相关的事情。宿主机用的是 Centos 7.1 和 Docker 1.13 版本，Kernel 用的4.14的版本，曾经用的3.10有太多的Bug也没有精力一个一个修了，现在在4.14版本来说坑是最少的。

容器镜像的管理我们用 Harbor 做的仓库，所有的镜像都是在分布式的存储里，这样保证了它的稳定性，它的容量相对比较大的。

资源隔离目前做的CPU隔离和网络资源的隔离。调度平台前面也介绍了目前三套都是在运行着，逐渐往 K8S 上做牵引。

2.3 运维工具

从运维工具角度来说，配置管理工具我们用了 SaltStack 和 Rundeck 两个比较常用的配置工具，监控告警携程运维团队有一个自研的 Ctrip-Hickwall 工具，开源的是 Prometheus ，稍微做一些配置和改造就可以监控整个云平台各种指标，包括系统层面、调度成功率、资源可靠性都可以搞定。

日志系统也是用的比较主流的技术栈，用 ELK、TIGK 和 ElasticBeats ，可以做日志收集和包的收集，监控告警和日志系统采集的结果会放在中心的数据库，比如说 HDFS 这些存储系统，为 AIOps 的团队提供一个数据的输入。

同时我们引入了一个 StackStorm 的软件，在尝试用 ChatBot 的实践，也达到了比较好的效果。

2.4 运维流程

从运维流程来讲，所有的运维标准都是通过 SaltStack 来安装的，包括3.10内核和4.14的升级。我们会和容器云做的比较好的公司，比如说阿里、京东、网易做一些学习和交流。我们主要从三块关注容器平台是否做变革，效率、成本、创新。

刚才提到了工作流的工具 StackStorm ，它跟传统化运维有些区别。我们整体工具都是用 StackStorm 实现的，它主要是做日常的排障以及云平台持续交付的功能。其中聊天机器人也会跟 StackStorm 工具做集成，可以提高排障的效率。

我们写一些脚本关注 OpenStack ，我们会针对 OpenStack 写一些运维的工具。这个工具在容器云的时代是可以被继续用的，它都会被定义不同的 Action ，让我们的运维流程处于不断完善的过程。

上图是我们的一个聊天机器人的例子，普罗米修斯对接的机器人，这个机器人对接都会为云平台各个服务做采集，比如说发现了 ChatOps 坏掉了，他会发送到 CdosBot 。它可以跳转相关环境的监控页上去，看一下到底发生什么样的事情，判断故障是什么原因导致的，回复一个消息给机器人，故障从发生以及相应处理是有纪录的，这样就可以很全面的做一个知识库，新加入团队的工程师可以翻聊天室看一看历史上出现了哪个故障，是否有预案应对？

这一块每个业务容器发布失败三次，基本上可以认为是云平台本身的问题导致的，那就需要工程师看一下错误日志，这种错误是很难处理的，但是我们可以让工程师很快发现问题，因为我们把所有相关的错误日志汇总在一个页面，通过点击连接，工程师可以快速把故障建立一个关联。

最终的目标还是要往 AIOps 上走，能够自动把日志分析好，判断出故障的原因，在 AIOps 最终落地之前，我们这样的 ChatOps 也为他们提供比较好的数据来源。你事情没做好就是你的问题，事情做好了是应该的。让组内的工程师有干活的动力，我们让他们在 ChatOps 方面充分发挥，对他们来说也是一个知识的传承和工作总结，他们干活也会比较有动力一些。

这里总结一下我个人认为 ChatOps 的好处吧，对于老板来说每个团队都是有困难的，每个团队都是希望招人的，但是往往很难。

运维工程师也不愿意做去重复的 routine task ，我会跟他们说你们去招聘一个机器人，工程师觉得你这样说也不错，我们的 ChatOps 的工具也提供了这样的可能，对团队协作方面也有很大的提升。

之前也有做工具，有自己的运维平台、运维工具都很丰富，它可能没有那么强的积累和分享的能力，只能在系统日志里看出端倪， ChatOps 会在聊天室里留下记录。

2.5 关注变化

我们容器云运维最关注平台发生的变化，因为平台的变化往往都是故障的先兆，对于异常的事情需要让工程师做深度的挖掘，往往是暂时没有出现影响业务的异常，在深度挖掘之后会是非常大的坑，在不久的将来就会让业务受到比较大的影响。

我们鼓励工程师花时间做深入挖掘而不是满足正常运行就可以了，灰度运行一定要落实的，这个时候也需要提供工具让工程师落地灰度变更，通过流程和工具来做保障。我们会组织一些会议回顾近期踩过的坑，有时候需要把节奏慢下来，在今年年底之前需要把所有宿主机干掉，在这样的工作压力下，也不能让节奏变的太快，也需要不同的回顾。实现关注变化的技术手段依赖于各种监控系统、巡检工具以及 CI/CD 的工具链。

上图是我们镜像的监控，我们认为一个镜像服务维护的水准是一个容器云运维能力非常重要的指标，因为镜像对于容器来说特别关键。我们会从每个数据中心建立一个单独的 Harbor 集群，让用户从第二个备份的数据中心拉容器，第二个数据中心出问题也会有保障，它的带宽变化、相应时间变化都会有分析。

容器云的网络也是我们特别关注的一个点，这个指标会去看每一个端口创建的时间，包括IP资源的情况都会做单独的监控。

2.6 关注趋势

前面讲的是关注变化，关注变化算是比较基础的一个工作，因为做运维的工程师都会关注我们是否有告警，平台是否有变化，而趋势往往会被工程师所忽视。我们关注趋势可以设定长期目标，让运维工作比较有计划性，运维工作有计划性是非常重要的，怕就怕的是运维工程师每天都在处理突发的工作，没有时间对你管理的平台做前瞻性的规划，把事情做在前面，不要把压力留给自己。所以需要建立技术储备，让工程师有一定的前瞻性，必须要在异常真正发生之前能够解决潜在问题。
云平台的组件实在太多了，包括存储、计算每一个环节都会出现问题，监控做的太细的话，让你淹没在日常事件里，核心的指标会被忽视，用户关注的是整个服务的交付的速度和服务整体的可控性。我们目前用的是 TIGK 、StackStorm 、SaltStack 和 ChatOps 。
上图是我们做的机器负载变化趋势的看板，可以快速帮助我们发现某一个集群的利用率，这个集群CPU还是比较富裕的，它的内存也只有71.47%。我们会做一些分析，看看是不是给他分配的容器太多了。像左下角这些宿主机要主动的维护，持续增加的话机器某一天就会坏掉了，造成非常大的影响。

这是应用维度的变化趋势，像这个应用在线容器数有三百个，但是CPU的表现是很稳定的，CPU突然出现50%左右的增长，我们也会告警他是否做一些分析或者扩容。

2.7 容量管理

下面介绍一下我们的容量管理，容量管理往往是老板比较关心的，因为涉及到花钱。每个季度到底投多少钱买宿主机？动态调度的能力有没有？应用有波峰和波谷的，尽量把波峰的应用挫开，我们需要对它进行资源使用情况的预判，这样才能实现弹性计算。

为了实现容量管理我们主要借助了监控系统、 Hadoop 平台以及自己运维的监控工具，最终通过 PAAS 平台实现容器弹性的调度。最终目标是把资源合理利用出去，同时又保证一定的稳定性。

这是我们容量的整体情况，会发现它的内存基本上用的非常满，这个集群它的CPU资源也是用的比较满，我们会从一些维度去做整体的分析和个别的分析。

三、总结与展望

前面基本上就是运维大概做的所有事情，下面简单说一下我个人的思考。之前做 OpenStack 私有云的管理，做完之后我们要把运营工具做成产品化，不能用工具的思维做事情，这样不能很好的解决用户的问题。

所以我们现在也是在尝试做一些日志产品和监控产品，在云原生的 DevOps 工作方式。我们运维人还是要以用户至上的，整体出发点保证平台稳定、持续、高效运行。还有一个总结是对 ChatBot 与事件的整合有比较好的效果，一方面让事件可追溯，另外一方面让工程师有更好的热情。

展望团队工作的话，接下来会有混合云运维的实践，携程这些采购公有云的产品，阿里云、AWS还没有做很好的整合，下一步把混合云管理起来，真正做到云原生。另一方面业界都在转 Kubernetes ，但还要进行思考，在 Kuberentes 时代下一步要做什么。做容器云的价值就是实现了弹性计算，而我们要在弹性计算这条路上做更多的事情，真正体现出容器的价值。

标签：容器,平台,运维,万台,虚拟机,携程,我们
来源： https://blog.51cto.com/15127563/2665032