本文整理自2024云栖大会冯诗淳演讲

大家好，我是阿里云容器服务团队可观测负责人：冯诗淳，花名：行疾。我将会为大家带来分享《阿里云ACK容器服务生产级可观测体系建设实践》

首先在开始我的工作汇报之前，我们先来回归一下CNCF最近一年的周年官方统计数据。

从2022年76%线上生产环境选择K8s，到2023年这个数据增加到了89%，且围绕K8s生态的前10项目也有不低于50%的生产环境使用占比。

Kubernetes容器化架构，已经是生产级系统的主流选择以及事实标准。

k8s容器化带来诸多好处，但也会增加更多系统架构复杂度。一个Infra团队成熟与否，考验的是能否借助更多有效手段，建设更加稳固的运维体系。

可观测能力就是构建运维体系的最核心能力之一。

今年2024年权威评测机构Gartner刚发布的容器管理魔力象限，阿里云作为亚洲唯一，蝉联全球领导者。

可观测性是容器平台能力的核心评测项。

参考2022年权威咨询机构Forrester发布的公有云容器平台领域的分析报告中，阿里云首次成为该领域能比肩Google的全球领导者。

其中阿里云容器服务的可观测性，能力强大、无缝的产品体验、高效的问题定位能力，得到了分析师高度认可。

故，我想说明的是，可观测能力是构建用户运维体系的重要能力。

我的本次分享和工作汇报将：

1、第一部分首先介绍容器服务可观测体系概要。

2、今天我想重点向大家汇报近期咱们阿里云可观测能力在重点领域场景（如AI场景、容器网络、存储等场景）的高级容器可观测能力进展。

3、最后一部分将介绍容器可观测体系作为数据驱动力可以如何帮助用户建设如FinOps、AIOps体系。

首先先由我介绍可观测体系有什么用，以及用在哪些典型运维场景。

这里第一个，也是最重要场景，也就是我们很多客户Infra team、CTO会直接问到的，咱们把生家性命业务跑在咱们容器服务集群上，怎么保证我的线上重要业务稳定运行不出问题。

这里我举例一个典型最佳实践，即是咱们今年的巴黎奥运会，ACK Pro集群很荣幸提供了如“子弹时间”提效、多个奥运线上系统的云上基础设施，这里可观测能力也为奥运的多个线上系统提供重保，助力巴黎奥运圆满平稳运行。

今年不只通过稳定性全局大盘“红绿灯”式全面实时监控线上系统，AI场景也对GPU、作业任务调度的观测能力带来了新的挑战，这里稍后也会进行重点汇报。

第二个场景，为保障容器场景的生产级大规模集群稳定性，如何进行性能调优。

容器化架构，由于多了一层容器层，也增加了运维复杂度，阿里云容器服务对容器层本身的可观测能力进行了增强，透明化了容器层。

帮助很多客户的生产场景下，通过透明容器层，保障业务、集群本身的稳定性。

如图例所示就是以一个头部电商的大促业务为例，观测业务高峰时业务对集群的网关、APIServer等核心ControLPlane组件的访问突增，并帮助进行性能优化，保障流量洪峰时的稳定性。

这两个场景对可观测体系的场景覆盖、运维Ops体系的建设都是极大的考验，决定了出现异常是否能被观测到，观测发现了异常后是否能被快速地展示提示给对应负责处理此异常的“正确的人”，最终实现低MTTR，以及整体保证高SLA。

最后一个典型可观测应用场景，也是日常都会遇到的，日常业务的异常诊断。

图中是以一个在线业务线上故障的排查路径为例，ACK可观测体系提供链路各层观测能力覆盖，并最终定位问题的过程。

首先当已经构建了运维体系后，出现业务异常时首先会由报警通知和发现线上异常，如Pod宕掉，可以通过重调度、弹性等容器手段马上止血。

然后咱们容器可观测能力提供了全套链路的观测能力覆盖，包括业务网关流量便于观测流量影响、通过Prometheus多维指标可以分析出异常发生的时间和具体影响的资源维度。

通过日志服务SLS采集的容器日志可以进一步进入应用逻辑进行定位，以及通过分布式Tracing、代码级Profiling剖析出异常根因，并最终终态修复。

这个场景对可观测体系的端到端各层覆盖能力是极大的考验，在追查异常的根因过程中，如果观测的数据链路断层，会需要排查者付出更多人力成本进行人工排查，最终不会得到很低的MTTR故障恢复时间。

接下来我来简单介绍一下容器服务K8s可观测体系的概要和我们开箱即用的产品能力。

介绍完了容器可观测用在哪些典型场景，由我来汇报概要介绍一下当前容器可观测体系具体有哪些能力。

这是容器可观测体系的大图，包括体系概要介绍以及我们基于可观测数据提供的增值场景。

首先在容器场景数据源的建设上，咱们还是分层为4层，越是上层越离用户业务系统更近，越是下层越是离基础设施层更近。

自上而下，分别是应用/微服务层负责用户业务流量、tracing、profiling等监控；容器监控层监控集群健康状况，以及监控集群上部署的应用；操作系统层提供透明化的内核观测能力；底层云基础设施层提供如宿主机、网络、存储、中间件等与集群环境相关的云基础设施的观测能力。

在容器层监控与操作系统层，近期我们对重点场景进行了增强。

通过我们阿里云可观测团队的数据/监控平台服务能力提供强大的数据计算存储分析能力。

在容器场景上我们也凭借可观测数据驱动力发挥出更大的增量价值。

自上而下，我们首先可以更好地进行业务层感知，剖析容器架构上业务应用的问题Profiling，或进行业务异常根因定位，以及流控管理；

容器层提供ControLPlane的观测能力，面对生产级大规模集群的压力挑战；专家诊断系统支持通过多维的观察数据对集群全方位异常诊断，并帮助进行集群容量规划；

在集群优化分析中尤其体现可观测提供的数据驱动力，包括安全性、FinOps成本效率方面以及集群高可靠性保障方面。

在数据集成方面，报警中心提供经过阿里云容器服务团队经验沉淀的默认报警规则，覆盖日程运维异常问题，提供开箱即用的保障；以及集群托管节点池会通过对丰富的观测数据发现其中异常并自动自愈集群等运维环境问题。

以及在数据驱动的自动化方面，支持基于Metric的HPA等高级弹性能力，帮助自动化地维护频繁变动的业务的稳定性，并形成兼顾成本效率与稳定性的平衡。

阿里云容器服务可观测体系中，事件数据链路也进行了多方面增强，在社区原有的k8s事件基础上，还增强了集群资源管控、集群控制面事件、操作系统内核层异常事件、以及集群底层云基础设施层的事件源，从事件链路形成端到端的全栈容器可观测能力。

在指标体系中我们仍然在统一标准Prometheus指标协议中，扩展所有容器场景的指标观测能力：如通过扩展GPU观测能力来支持容器上的AI训练等重点场景。

在产品一致性和用户体验方面，通过升级的预制监控大盘，容器服务产品支持在用户进行集群、应用管控时，统一查看监控，做到监管控一体的无缝体验。

ACK Pro版集群，所有用户也能开箱即用地获取我们对大客户重保沉淀下来的运维体系和经验能力，如控制面组件APIServer、ETCD等监控大盘。

Tracing方面，容器服务当前提供三个档位的tracing能力来满足不同场景需求：

1、推出基于eBPF的无侵入式应用监控能力；

2、以及支持OpenTelemetry标准协议的OpenTracing tracing数据接入；

3、以及侵入式但拥有强大Profiling的能力的JAVA、Golang（需预编译）APM能力。

得益于eBPF的成熟，我们目前提供基于eBPF技术的无侵入、深入内核层、低overhead消耗的应用监控能力。

支持集群拓扑感知，无侵入地完整观测整个集群中各层网络流量情况，以及下钻到细节查看端到端网络流量情况。

前面的汇报快速概要地介绍当前阿里云容器可观测体系的概要全貌。

接下来想要重点向各位分享汇报我们近期在客户中的重点场景下面对的新观测挑战以及我们当前的解决方案。

我们首先来聚焦AI场景的典型观测需求。

当前咱们的用户在AI场景对容器平台能力的要求，逐渐从 “能运行就行”，变成了“生产级”系统的要求。

容器化架构提供高灵活性和资源复用，也是AI场景的主流选择。

通过客户案例的经验积累，我们总结出AI场景对GPU场景的观测需求：

1、GPU价格昂贵，且坏卡率高，如何自动进行坏卡检测，从而任务、环境自愈，是保证AI生产任务不间断的基本保障需求；

2、在生产环境如进行推理任务时，如何保障集群、AI业务任务的环境稳定性，除了前面说的运维体系外还需要面对GPU这多一维度资源的观测挑战；

3、模型如何调参，任务为什么跑得慢，都需要暴露更多透明化的观测能力帮助进行模型性能优化，帮助调参。

当前通用的AI场景生产系统的容器化架构，可以纵向分为如图多层。

其中如Ray、Slurm、Spark、大模型RAG等可通过ACK AI套件接入并进行针对性优化的同时，每层也提供了增强的观测能力，也都可以通过阿里云Prometheus统一的指标监控能力得到一致性的观测体验。

阿里云容器服务通过提供开箱即用的GPU监控大盘，以及GPU坏卡状态检测，以及GPU应用的成本分析能力。

帮助进行AI业务的稳定性保障，以及任务调参优化。

除了ACK提供GPU性能监控指标。

我们还推出基于eBPF技术的低消耗、无侵入、轻量级的GPU Profiling任务剖析能力。

支持pytorch场景深入内核级分析AI任务的耗时瓶颈，提升AI任务的性能调优诊断效率。

这里是一张GPU Profiling的时序耗时图，多级指标关联，综合分析host进程、系统调用、CUDA Kernel、NCCL通信、Pytorch算子耗时，快速定位AI任务性能瓶颈。

第二个重点场景，是容器网络观测能力。

由于网络问题定位流程长、定位时间跨度大、经验要求高，定位容器网络问题是巨大挑战。

容器网络是我们经手的最复杂的场景，我们团队的容器网络专家需要花费大量时间来case by case排查用户网络问题。

这里由咱们容器服务团队的网络专家推出 KubeSkoop k8s网络问题诊断工具集。

提供基于eBPF技术增强的容器网络观测能力，从此排查网络问题从telnet、routetrace、wireshake，到只需要点一下诊断再看一眼监控数据。

面对每天日常的网络连不通问题，KubeSkoop提供端到端全链路覆盖的连通性检查能力。

通过Prometheus，支持历史访问关系数据的回溯，过去的异常现场也能排查，并绘制整个集群的的网络拓扑图。

对网络延迟问题，KubeSkoop在连通性判断的基础上更进一步，支持探测网络延时异常。

由于K8s架构的动态调度性和网络结构复杂性，抓包也需要分布式同时在多个节点上并行进行，再绘制出完整的端到端包传递诊断现场。

进一步剖析其中的技术原理，在ACK上，KubeSkoop通过Net-Exporter组件提供标准的Prometheus监控指标和标准事件日志。

基于eBPF技术，采集内核级网络栈信息。

容器存储也是一个需要观测能力来保障业务稳定性的场景。

挂盘异常、写入、容量异常也是日常常见的运维问题。

对一些高吞吐量场景，如AI训练的频繁IO写入写出，也需要观测并帮助性能优化。

容器服务已经通过CSI标准容器存储方案统一容器场景各种存储介质的接入方案。

当前我们也通过增强阿里云容器服务的CSI实现，提供增强的容器存储观测能力、包括Prometheus与标准K8s事件、日志。

统一地为上层有状态的场景提供增强的容器存储观测能力。

尤其对高吞吐量的场景，如多集群多卡AI训练、以及大规模生物计算等。

提供吞吐量估测能力，帮助进行合适的存储介质方案选型，以及IO瓶颈的优化。

去年阿里云操作系统团队提供的SysOM内核级容器观测能力，也在经过一年的能力打磨中，帮助解决了很多容器化问题。

最典型的就是内存“黑洞”问题，如常见的java应用容器化，会导致进程申请超出JVM的pagecache，在容器场景会导致PodOOMKilling。

在SysOM内核级内存剖析中，可以清晰看到内存消耗来源，并结合Koordinator混部解决方案无侵入地精细化收敛解决这些内存“黑洞”问题。

采用多云架构也是很多用户选择的一个趋势。在多云场景下，阿里云容器服务ACK ONE多集群舰队支持将ACK集群、ACK注册集群纳管的自建K8s集群统一地进行管理，并提供统一的监控大盘，以及成本分析能力。

在复杂的多云集群管理场景下，极氪汽车通过ACK ONE统一管理多个k8s集群和统一成本分析，实现减少了25%的资源用量。

以上是重点垂直领域场景的可观测数据链路建设，进一步发挥可观测数据驱动力的价值，我们希望凭借这些数据驱动力帮助用户建设Ops体系。

阿里云容器FinOps套件，基于可观测能力，提供成本效率的强大数据驱动，帮助进行成本优化的决策。

这里FinOps套件已帮助多家头部客户进行不同程度的成本优化，并取得到了非常好的效果。

容器服务FinOps套件，提供开箱即用的集群多维成本大盘，支持细粒度到Pod的分账分析。

并提供集群成本浪费分析，以及优化/节省建议。

通过数据驱动有理有据进行容器场景降本增效。

刚才说了这么多丰富的容器观测能力，咱们的用户一定不知道去哪里具体找想要的功能。

不要担心，我们的容器可观测体能力也正在迈进下一个时代。

我们将会推出ACK AI助手2.0。

结合容器服务可观测体系的数据驱动力，以及阿里云容器服务团队沉淀的专家诊断经验。

不用在复杂的大盘里找某个异常数据，直接通过ChatOps告知数据、状态异常，极大缩短交互路径，处理故障时极大缩短MTTR平均故障响应时间。

AI助手通过阿里通义千问作为强大的智能引擎，结合容器服务博大精深的可观测体系的数据驱动力，让我作为一个技术人梦寐以求的下一时代可观测功能形态。

更加有体感的ACK AI助手产品功能介绍，ACK AI助手在去年发布事后异常应用智能诊断的基础上，今年也提供了事前的集群体检和应用智能分析等功能，结合可观测数据为用户提供全生命周期的智能稳定性保障。

当前我们的ACK AI助手从去年云栖大会发布也已经上线了一年了，当前也分享一些效果数据。

首先在处理所有容器服务对客问题时，AI助手智能给出的采纳率当前可以达到40%以上，并在诊断场景结合我们AIOps套件的专家诊断系统，诊断根因定位率可以达到70%以上。

阿里云容器团队诚招内转【开发&SRE】【产品经理】【PDSA】- 杭州、北京、深圳的岗位均可，欢迎大家帮助推荐。

/ END /