本文根据演讲者在 GOPS 2023·深圳站演讲整理而成，如有图文不妥，请以视频为准。更多精彩，请关注高效运维公众号。
田国良，中国移动通信集团江苏有限公司-资深架构师、资深专家。
一、容器云运维的背景和问题
应用系统规模化上云以后，面临着一系列的问题，平台的资源关系和拓扑关系，变得非常的复杂，需要投入大量的人力去做数据分析。
另外，随着微服务化的演进，我们系统的规模也越来越大，需要不断地做 IT 云的布局优化，资源调整。与此同时我们整个容器云平台的运维指标变化也比较频繁，以往通过设定固定阈值的方式来触发告警，在容器云环境下，它并不能满足运维的诉求。
现在面临着组网复杂，系统越来越庞大，还有海量的数据，导致我们定位问题比较困难。
目前运营团队人力比较有限，那么就导致人少事多责任大，怎么样才能更好地解决这些问题？首先要准确地识别问题，结合我们江苏移动的生产实践，识别出来以下这个 5 个方向的问题。
-
第一、针对容器云的健康状态，缺乏衡量的手段，容器云的健康直接影响到整个系统健康的运行，但是目前还缺乏全面的数字化衡量方式。
-
第二、针对 pod 的异常，目前 K8S 的健康检查机制也不是很健全， K8S 检测到 pod 异常以后，它的做法是重启，反复的重启会引起整个系统的波动。至于 pod 为什么异常，其实 K8S 并不是很关心，不具备根因定位和分析的能力。
-
第三、面对业务量的突增，现在K8S的扩缩容机制，它不能随着业务量的变化而变化。
-
第四、目前的 K8S 的资源调度也存在着不均衡的问题，尤其是在资源超卖的这种场景下，很容易导致部分集群资源使用率过高，另外一部分集群的使用率又比较空闲，这种忙闲不均的情况很容易导致整个集群的不稳定性。
-
第五、系统微服务化以后，实现了多中心的部署，对于集群级或中心级的故障，传统的运营方式只能等待着问题的解决和处理，显然也不能满足当前业务连续性的要求。
二、容器云智能运维建设实践
针对以上的问题，我司在运维方面做了一些实践。
首先从大的思路上，分为云上、云中、云外这三个方向。在云上构建了应用可用性管理，在云中构建了健康可视化管理+资源的异常管理，在云下构建了容量的管理，在云外构建了应急容灾的管理。
除此之外，我们还搭建了容器云运维一体化指标体系，从基础资源到容器资源到应用的各类性能指标，拓扑关系以及时序指标，把这些指标收集完了以后，统一汇总到智能运维引擎，会对这些数据进行分维度、分类别的分析和检测。
可以及时发现整个云的健康状态及异常情况。另外它也可以调度 K8S，实现资源调度。在这个基础之上，我们也实现了几个能力。
-
在应用可用性管理方面，打造了 PC 端的可用性探测和移动 APP 的仿真探测。
-
在健康可视化管理方向，打造了系统的健康度评分能力和系统智能巡检能力，以及跨系统的调用链能力。
-
在资源异常管理，构建了 pod 的异常发现和故障自愈的能力。
-
在容量管理，实现了智能扩缩容的能力，资源均衡调度能力。
-
在应急容灾管理方面，构建灰度发布能力和多活多中心无感切换的能力。
2.1、技术实践之一览众山小
如何做到对于云的全局性掌握，首先要实现对云的可见性。针对容器云上的应用，如何从客户感知的角度，第一时间主动发现应用的可用性问题，尤其是对于隐藏在PaaS 或 IaaS 层的隐患，构建了容器云应用可用性探测的反馈机制。
这个能力是依托的，我们对于容器资源，微服务的资源自动拓扑的实现。它构建了从基础资源到中间件到业务系统到应用的上游，就是全链路的整个拓扑关系。然后实现了 IaaS、 PaaS 和 SaaS 层的全方位资源的管理。
另外，对要探测的对象和场景进行梳理，构建了两个应用，一个是业务可用性探测应用，另一个是移动 APP 的仿真探测应用，这两个应用都是 7× 24 小时在对系统做不间断拔测。业务可用性探测实际上实现了整个应用系统所关联到的所有资源关系和对象，包括硬件，容器、业务指标，还有前端页面指标进行不间断测试探测可以及时了解到问题发生的情况。
移动 APP的仿真探测，是模拟的移动终端环境，模仿用户去操作手机 APP 的流程，然后把它固化成脚本，以任务的方式调度它，实现自动的业务探测，实现了整个对于 APP 应用用户操作全流程数据记录，包括在这个页面的响应时长，网络耗时，对 CPU 内存的使用情况，通过多维度、多指标，接入和分析，及时了解到移动 APP 的应用在哪些环境上有性能问题，可以反馈应用的开发人员，及时进行优化调整。
通过两个能力的打造，实现容器云运营模式的转变，从被动发现问题到主动发现问题，从片面到全局，从单维到多维的转变。而且利用这种主动探测的方式，可以及时地发现系统出现的异常，第一时间知道有问题发生，第一时间知道影响了哪些应用。
应用可用探测系统的截图，它支持很多种协议，包括 HTTP、JDBC、FTP、TCP 这种方式，而且支持接口报文的探测。移动终端的探测，目前我们已经应用到中国移动 APP 几乎所有的核心业务探测试里，它可以对整个业务流程的各个环节指标数据进行采集和分析，然后助力于移动开发人员对性能比较慢的环节进行一个优化。
另外应用可用性探测，也是以系统角度对各个探测的对象进行收敛，最后收敛成一张图，这张图上可以直观地看到系统运行的整体健康度，如果探测有问题，它会根据问题的严重程度以红色或者黄色的高亮显示，运维人员发现异常，可以通过层层下钻方式来定位到异常发生的点，以便进行及时处理。
2.2、技术实践之云深也知处
系统微服务改造上云以后，最大的一个问题叫云深不知处。针对这个问题，我们构建了一系列能力，首先打造运维指标体系，把应用的一些响应时长的指标数据，系统负载、日志、 pod 异常，还有系统告警这些数据，全部进行收集汇总，吐到智能分析引擎里边。
分析引擎它可以对这些复杂数据进行聚类，并进行一些关联分析，从而检测出异常情况。基于这个这一点，我们打造了三个能力，一个是系统健康度评分能力，一个是系统智能巡检能力，还有一个跨系统调用链。
-
系统健康度评分能力，是对系统所关联的最核心的资源对象进行健康度的评测，对它的指标进行量化，给出从 0 到 100 的打分，从分值上可以很直观地看到系统运行的情况。
-
系统智能巡检能力，通过构建运维的脚本库，利用智能算法把异常检测和巡检路径做结合，它最大特点是根据系统健康度检测结果去评估它要巡检的对象。如果巡检对象健康度比较高，它可以直接剪掉，不做巡检，通过剪枝的方式提升整个巡检的效率。
-
跨系统调用链，它通过引入 trace ID 的方式，把整个请求链路上的数据做串联，然后把各个环节的性能数据指标也做采集，可以直观地展示各个流程中哪些环节有问题，后端的研发和维护人员及时处理。
如图：系统健康度评分能力和调用链在现场环境中应用，系统健康度评分能力，是对整个系统的健康情况给出粗粒度的评估，让你知道它是好的还是坏的。调用链可以给出比较详细的前后端调用关系，以及各个环节性能消耗情况，给出一个细粒度的分析，这种粗细结合对日常运营工作起到非常重要作用，大大节省对系统问题的判断。
系统健康度评分能力是把整个应用系统各个维度进行细粒度打分，在这个基础上，比如 Pod 资源的健康度、应用的健康度，还有主机资源的健康度，还有低分 pod 的健康度等。然后把这些维度会再做一次综合性评估和权重分配，给出更加直观的展示，对于低分节点的情况，可以点进去看一下原因。
2.3、技术实践之灯火阑珊处
对于容器云来说，其实最繁忙的就是 pod，我们最应该关注 pod 的异常。那么如何感知 pod 的异常？是我们面临的问题，现有的 K8S 机制的覆盖面不是很广，可能是端口的探活、健康页面的探活、还有脚本的探活等，有很多场景没办法覆盖到。
针对这个空白，我们从感知、分析、决策到自愈的全流程来构建 pod 异常发现和处置能力。
首先在感知环节，新增了很多 pod 异常场景。针对 pod 异常的状态，首先比如说 pod 处于 terminating 状态，或者 pod 状态正常，但是工作不正常。还有 pod 文件系统挂载异常等。第二个主机节点的夯死情况也经常发生，比如说节点状态 no not ready，或者节点负载的过高、节点资源分配不足等情况。
针对这些场景，沿用资源的异常管理和容量治理两个方向，把系统指标、日志状态和事件做多维度数据接入，利用多种AI 算法进行分析决策，实现异常事件分析和判定。识别出哪种 pod 异常场景，然后给出决策建议，通过事件来驱动 K8S 去完成自愈的动作，比如说是 pod 隔离还是重启。
日常故障分析过程中发现很多场景是主机节点夯死导致的，前期方法是通过 K8S 把它手工从集群中剔除，这种方式比较滞后、也不灵活。想构建 pod 夯死预测的能力，我们将像 CPU 内存、文件系统等数据做综合性的监控和分析，来预判夯死的趋势。一旦发生准备夯死的情况，就提前介入对资源进行重新配置，避免主机夯死的情况。
2.4、技术实践之如意知我心
对于 pod 的容量管理，我们也是想可以按时按量按需的去完成扩缩容。为了实现这个需求，我们增加时间周期、舆情活动、指标趋势和自我感知决策的能力打造 pod 扩缩容能力。
-
时间趋势，比如一天之内有高峰期、低谷期，我们希望在高峰期能够对pod进行扩容的动作，在低谷期对 pod 进行缩容的动作；
-
舆情活动，比如双 11 活动，或者一些重大的营销事件开展的时候，对于业务量的突增它能够进行及时的容量调整，可以避免业务并发请求量过高导致系统崩盘。
-
指标趋势，希望我们构建针对 CPU 内存趋势增长的分析能力，来判断资源的诉求，它是增长趋势还是下降趋势，增长的时候就扩容资源，下降就缩减 pod。
通过容量分析，加上多维的智能决策，我们给用户资源也打标签，做资源的画像。它是什么资源类型，然后再结合时间周期、舆情活动和指标趋势，基本上实现了在生产活动中大部分 POD 扩缩容的需求。
右下角，是生产系统中的业务实例。在用这个能力之前，是固定给他 48 个实例，随着业务水位线的增长，需要每次进行人工扩容，应用了扩充能力以后，应用实例数平常就回落到 16个左右。业务增长的时候，比如月底、月初或者其他繁忙的时候，它会自动扩容到 48 个实例，减少了这个资源占用。实现提前的扩容，减少系统波动次数。
2.5、技术实践之七平八稳
在实现 pod 扩缩容的过程中，我们发现 K8S 原生的资源检查机制，它是静态检查方式，在资源扩缩容的时候，它会导致局部资源的过热，时间一久就会引发整个容器云波动。这个问题的原因：比如江苏移动的容器云 Paas 资源对于节点的纳管，它不是物理节点，有很多虚拟机，物理机在做虚拟机的时候会有资源超卖情况，那 Paas 他并不知道他纳管的是虚拟机还是物理机，就导致他不知道资源有超卖的情况，如果多个租户对资源有诉求的时候，他有可能把这个资源的调度都调度到一批物理节点上。导致这一批物理节点非常的繁忙，然后就会引发系统波动。
为了规避这种情况，引入算法，通过把静态资源数据，再加上PaaS实时的运行数据，再融合 IaaS 的繁忙情况。结合时间周期的分析来构建资源均衡调度。这个方法避免局部资源被过度调度的情况，实现资源规整的复用。一方面提升系统的利用率，另一方面提升了整个系统持续运行的稳定性。
系统微服务化上云以后，基本上都是多中心部署，有时候也会发生中心级故障，比如说整个集群出现了问题，或者一个完整的中心因为异常，导致整个中心的请求响应失败率很高，怎么规避中心级的故障？还有版本上线完以后出现了问题，我们怎么避免？思路就是借鉴狡兔三窟，构建多中心的部署加多活的方式。通过对于核心硬件故障的采集和业务中心瘫痪的指标采集，来判断整个业务中心是不是有问题。结合智能辅助决策给出流量切换建议，根据这个建议，把有问题的集群直接切换到其他的生产集群上，达到中心级的故障逃逸的效果。
灰度发布，借鉴了敏捷发布的原理。版本发布都是先发布灰度环境，灰度环境验证完了以后，再做全中心的版本拉齐。因为业务系统都是多中心部署，比如说一个业务系统有四个中心，那在上线的时候，先把 1 中心流量切换到 2 中心上，然后在 1 中心流量版本发布完了以后，再把一二的流量切到 1 中心上来，实现中心的轮动发布。可以避免在版本发布过程中业务系统的中断情况。
这张图是多活多中心一键切换的系统截图，可以比较直观地看到目前集群的状态，可用性的状态，核心的业务支撑系统 CM 系统，它有七大中心，其中有 4 个生产中心，两个容灾中心，还有一个灰度中心，除了灰度中心以外的其他中心，一个中心都可以承载两个中心的业务量。
当有某个中心出现异常的时候，我们的智能推荐会给出一个决策建议，需要把这个中心的流量切换到另外哪个中心去，只需要在这个界面上点击下鼠标，就完成秒级中心级的切换，实现故障的快速规避。因为有时候中心级的故障发生的时候，定位的时间比较长，没必要等着问题定位了以后再做故障的恢复。我们现在的策略就是先恢复应用，然后再去排查问题发生的原因。
右边图就是我们灰度中心的建设，我们灰度中心的建设也是参考了亚马逊的灰度中心建设的原理。我们单独构建了物理恢复中心，这个中心可以承载一个地市的业务量。当做版本发布的时候，我们先在灰度中心做新版本的发布，然后再把指定的某个地市的流量，通过流量网关的方式把它切过来，做业务验证。如果这个版本有问题，我们只需要通过左边这个界面一键切换到生产环境，也不需要做代码回退，实现了非常快捷的发布和问题的规避。
三、容器云运维演进方向思考
在容器云智能运维这个领域，我觉得我们还需要继续做一些深耕，建议是从三个点上做一些考虑。
-
一、迭代优化，现有的容器平台运维的手段和流程，要不断地做一些运营，优化调整，结合生产活动中出现的问题，及时做弥补和迭代，来持续地保证整个容器云的稳定性。
-
二、可以构建提前预测故障的能力，就是让运维工作左移，不要每次等问题出现了以后，想着办法怎么去定位问题，解决问题，可以去做一些预判性的能力，在问题发生之前就去感知到风险，然后及时进行一个介入处置，把这个问题消灭在萌芽状态。
-
三、就是我们运维流程可能还需要做进一步的迭代，那么遵循着这种可视化、可编排、可编程的原则，来持续地推进我们运维流程的自动化和智能化的发展。基于以上的探索，未来肯定可以更好地支撑容器云的保障工作。
作者简介：
田国良，中国移动通信集团江苏有限公司-资深架构师、资深专家。
运维如何优雅转型？XOps 了解一下啊~
6月29-6月30，DOIS DevOps 国际峰会 2023 · 北京站，BizDevOps、精益/敏捷、SRE 稳定性、AIOps，你想看的内容，都在这里！
近期好文：
投稿邮箱：jiachen@greatops.net，或添加联系人微信：greatops1118。
发表评论