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

前言

本文将分享携程在私有云平台管理实践过程中踩过的坑和遇到的问题，包含：

第一部分，携程容器云概览

第二部分，容器云管理实践

第三部分，云平台运维管理发展方向展望

一、携程容器云概览

携程使用混合云架构，自建数据中心结合公有云实现弹性资源管理。机票、酒店、商旅、度假等业务线，数以千记的应用运行在携程容器云上。业务研发基于容器云可以实现快速功能迭代，按需扩容缩容，整个平台每周变更次数超过 1 万次。

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

第一个阶段，携程从 2013 年开始实施 OpenStack ，2014 年所有数据中心都具有了 OpenStack Provision 的能力，因此我们对 OpenStack 特别熟悉。容器云平台第一个版本也是尝试了基于 OpenStack 技术来实施。

2015 年当时容器在生产环境上运行的还较少，各大厂都在试水的阶段，基于性能和稳定性的考虑，大家不希望对基础设施做太大变革。

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

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

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

调研之后我们决定全面投向 Kubernetes ，同时给用户灌输概念：不再是单独申请，你申请的是服务，容器云给你提供服务，这个 PAAS 服务包括应用、缓存、数据库服务、日志与监控服务等。

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

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

IAAS 的理念是把基础设施以服务的方式提供出来，这样对业务的体验还是不够好；现在全面转向 PAAS 的理念 ，用户不再需要去申请一个机器或者申请 IP， 直接给用户提供服务，你不需要关注服务跑在物理机上还是容器上，它后台服务的 IP 地址是什么都不需要去关注。

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

在几年前业务团队申请虚拟机的时候，我们一旦给了用户虚拟机就很难动它了，虚拟机热迁移是需要很高成本的，而且用户究竟在虚拟机里装了什么软件，做了什么特殊的配置我们是很难控制的。

容器云的时代该问题得到很大改善，每一次的容器发布都是做重新的调度，每一次可以给全新的容器，而且确保跟上一个版本完全一样，因为用户没有权限做修改。

二、携程容器云运维实践

2.1 面对的挑战

容器云面对各种各样的挑战，从基础设施角度来讲，我们需要解决计算、网络、存储三个方面的问题。

首先，网络层面，IP 的数量会有指数级的上升，虚拟机的时代可以单机多应用，部分应用可以部署在同一个虚拟机上；单容器单应用架构会导致容器的数量比较多，IP 数量也会多十倍，这样要上一套 SDN 的管理方案来进行多个 VPC 的隔离，传统虚拟机的管理方式已经不适用了。

第二个挑战是计算资源隔离相关的问题。每个业务的峰值是不一样的，如何保证每个业务容器 CPU 需求和网络流量突发过来的时候，它不影响其他的应用？这也是非常大的挑战。

由于容器本身的特性，假设你用程序获取 Mem/CPU/Disk 的值，可能获取到宿主机的值。还有比较麻烦的 DefunctProcess 问题，一旦容器中的某个进程变为 Defunct Proccess，只能通过重启宿主机的方式来结束它、此时同宿主机其他容器也需要被重启。

还有如何平衡好 CPU Throttle Time 也是一大挑战。 Throttle Time 出现的时候也就是代表某一个容器没有办法申请到 CPU period、在等待状态。因为容器的特性，同宿主机部署应用密度上升，导致系统调用对内核增加额外系统调用次数，在 3.10 内核上遇到过触发内核死锁的 BUG。Docker 版本升级非常快，从 1.6 到 1.7、1.8 到后面 17.0、18.0，我们是否跟着升级每一个版本？是单独维护分支，还是紧跟社区的步伐？

2.2 基础运维

2.3 运维工具

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

日志系统也是用的比较主流的技术栈，用 ELK、TIGK 和 ElasticBeats ，监控告警和日志系统采集的结果会放在中心的数据库，为 AIOPS 提供数据基准。

同时我们基于 StackStorm 开发了系列工具，进行 ChatOps 工程实践，也达到了比较好的效果。

2.4 运维流程

刚才提到了工作流的工具 StackStorm ，它跟传统化运工具有些区别。我们开发的聊天机器人也可以和 StackStorm 工具做集成，提高排障的效率。

上图是我们的一个聊天机器人的例子，普罗米修斯对接的机器人，这个机器人对接都会为云平台各个服务做采集，发现某个服务异常，会自动发送到 IRC Chat。工程师可以点击链接跳转相关环境的监控页上去，看一下当前到底发生什么样的事情，判断故障是什么原因导致的，回复一个消息给机器人。

故障从发生到被响应应处理是有纪录的，这样就可以很全面的做一个知识库，新加入团队的工程师可以翻聊天室看一看历史上出现了哪个故障，是否有预案应对？

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

这里总结一下我个人认为 ChatOps 的好处吧，对于老板来说每个团队都是有困难的，每个团队都是希望招人的，但是往往很难。运维工程师也不愿意做去重复的 routine task ，我会跟他们说你们去招聘一个机器人，工程师觉得这样说也不错，我们的 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 时代下一步要做什么。做容器云的价值就是实现了弹性计算，而我们要在弹性计算这条路上做更多的事情，真正体现出容器的价值。

作者介绍：

周昕毅，携程系统研发部云平台高级研发经理。现负责携程容器云平台运维，Cloud Storage 及 Cloud Network 基础设施研发及运维。

本文转载自公众号携程技术（ID：ctriptech）。

原文链接：

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