About the Author
Zhou Xinyi
Senior R&D Manager of Cloud Platform, Ctrip System R&D Department
Preface
The topic I shared is "Operation and maintenance management practices of 10,000-scale container cloud platforms". I will share with you the pits and problems encountered in the practice of Ctrip's private cloud platform management. The topic I shared a few years ago was " The development history of Ctrip cloud platform DevOps era". Today’s sharing mainly consists of the following three parts:
The first part is an overview of Ctrip's container cloud and what are the components. The
second part will talk about how our team manages the container cloud from a practical point of view. The
third part will summarize and look forward to the future development direction.
1. Overview of Ctrip Container Cloud
Ctrip currently has three self-built data centers plus a public cloud, and it has purchased some resources from Alibaba Cloud, Tencent Cloud, and AWS. Ctrip currently has more than 6,000 applications, including hotels, air tickets, bus tickets, and business travel departments. Each department has its own R&D team responsible for the development of application code.
Our team is responsible for providing infrastructure for these internal business departments. Before deploying applications, we provided physical machines. Later, we entered the container era and no longer paid attention to infrastructure. At present, there are two thousand container clouds, seven to eight thousand production releases, and one release is an application version, so the release frequency is still very frequent.
At the end of 2015, python was still used for container scheduling control. Of course, node.js now has its own advantages. Our team also learned advanced experience and fully migrated our container scheduling management platform to K8S. Ctrip's code scheduling platform used Application very early, and later Ctrip moved into the code technology stack. The mainstream ones are java, node.js, python, and php. This ensures that each R&D team can configure it according to our parameters. To do this, there is a certain customized plan, which requires the development of standards.
In terms of resources, we focus on private clouds, and we will expand virtual machines on public clouds when encountering sudden traffic. The peak of Ctrip is also predictable. The summer vacation is a peak of tourism. There will be a peak of high traffic before November, and there will be a lot of traffic during the Spring Festival. At this stage, we need to apply the elasticity of public clouds to support our traffic. We still use private clouds as the main daily, which can save a certain amount of cost.
部署在容器云上的应用目前分为两类：一种是标准应用，也就是 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 平台实现容器弹性的调度。最终目标是把资源合理利用出去，同时又保证一定的稳定性。
This is the overall situation of our capacity. We will find that its memory is basically very full, and the CPU resources of this cluster are also relatively full. We will do overall analysis and individual analysis from some dimensions.
3. Summary and Outlook
The previous is basically all the things that the operation and maintenance probably does. Let's briefly talk about my personal thinking. Before doing the management of OpenStack private cloud, after finishing it, we have to make the operation tools into products, and we can't do things with the thinking of tools. This can't solve the problems of users well.
So we are now also trying to make some log products and monitoring products, working in cloud-native DevOps. Our operation and maintenance personnel still need to put the user first, and the overall starting point is to ensure the stable, continuous, and efficient operation of the platform. Another conclusion is that the integration of ChatBot and events has a better effect. On the one hand, the events can be traced, and on the other hand, the engineers have better enthusiasm.
Looking forward to the work of the team, the next step will be the practice of hybrid cloud operation and maintenance. Ctrip purchases public cloud products. Alibaba Cloud and AWS have not yet done a good integration. The next step is to manage the hybrid cloud and truly achieve cloud native. On the other hand, the industry is shifting to Kubernetes, but it still needs to think about what to do next in the era of Kubernetes. The value of container cloud is to achieve elastic computing, and we have to do more on the road of elastic computing to truly reflect the value of containers.