阿里云云原生技术实践营 _ 上海站.pdf

云原生技术实践营-上海站2024/01/05基于Kubernetes的云原生AI工程化落地实践徐之浩阿里云容器服务团队2024/01/05目录云原生AI的趋势与工程化挑战01云原生AI套件介绍02AIGC/大模型应用场景案例03云原生AI的趋势与工程化挑战01 Optimization Scaling Tuning Update Scale outDebugPrepare dataBuild model TrainInference特点:1.端到端 Raw data in,executable model out2.长时任务 小时天周/月3.迭代优化 梯度下降,超参数调优,AutoML4.海量数据，大量计算资源挑战:应对:运行性能开发效率运维成本可扩展可组装可重现AI应用的特点和挑战云原生AI产生背景 资源管理分散 生产流程割裂、效率低 团队协作、共享困难传统架构 资源池化：弹性、灵活 生产流程高效闭环 多角色协同，加速迭代云原生架构数据管理平台服务部署平台算法建模/训练平台资源管理平台数据业务AI工程化算法工程师/数据科学家AI平台/K8S运维人员更大的算力需求更高的稳定性要求更快的创新和迭代交付人工智能机器学习深度学习OCRFace-ReImage-ReMultimedia AINLPTTSAIGCLLM电商社交游戏自动驾驶传媒金融医疗健康科学计算随着AI技术快速发展和应用，AI工程化向云原生架构演进。AI/大模型应用容器化趋势Stable Diffusion聊天AIGC Applications媒体内容规划游戏娱乐搜索客服Kubernetes和容器技术帮助用户简化GPU资源运维流程，承载用户业务AI应用的同时利用弹性优势节省成本阿里云异构资源CPUGPUFPGAASICRDMA100GEth CPFS/NAS/OSS持续优化异构资源效率高效运行AI等异构负载ACK云原生AI套件开发探索数据准备模型构建模型训练模型推理调优提效持续发布弹性Service MeshServerlessAI应用开源框架FasterTransformerMegatronK8s运维人员IaaS运维人员AI平台运维人员算法工程师数据科学家AI应用容器化面临的新挑战挑战:Kubernetes为通用应用而生，缺乏AI应用上下文如何构建对AI应用开发者友好的开发平台？如何统一管理AI平台的资产？如何提升AI应用迭代、运维效率？如何更好地运维大规模GPU集群？云原生AI套件介绍02云原生AI套件为用户提供了四部分能力的参考组件实现，满足云原生AI工程化不同落地阶段、不同业务属性的需求。云原生AI套件异构算力管理AI任务管理AI数据加速AI工程管理成本分析资源管理运维监控诊断资源接入资源弹性伸缩HPA、Cluster AutoscalerGPU共享调度与隔离资源调度与共享任务提交运行任务调度任务弹性数据集管理数据访问加速数据集编排命令行工具控制台AI工程化IaaSK8sACK ProACK ServerlessACK EdgeACK灵骏公共云专有云混合云边缘CPU/GPU拓扑感知调度用户自建 AI 平台阿里云 AI 服务开源 AI 框架与模型三方 AI 优化方案PaaSJupyterLabPipelinesKubeflow任务队列弹性配额调度Batch任务调度ECS/ECI GPU扩展弹性推理弹性训练数据集弹性数据集监控多数据源接入自动化数据流应用协同编排混合云数据加速Serverless数据加速可扩展的分布式缓存引擎降低大规模降低大规模GPUGPU管理复杂度管理复杂度智能削峰填谷，减少智能削峰填谷，减少GPUGPU资源浪费资源浪费最大化提升最大化提升GPUGPU利用率利用率多类型任务快速提交和编排多类型任务快速提交和编排多种策略满足复杂调度场景多种策略满足复杂调度场景提升任务运行效率和优化成本提升任务运行效率和优化成本数据抽象和统一接入管理数据抽象和统一接入管理数据缓存预热加速访问数据缓存预热加速访问数据使用的简化和自动化数据使用的简化和自动化屏蔽底层复杂性，简化任务管理屏蔽底层复杂性，简化任务管理可视化配置、管理、监控集群可视化配置、管理、监控集群AIAI生产效率和体验优化生产效率和体验优化Arena SDKArena CLIAI运维控制台AI开发控制台LLMOpsMLOps云原生AI套件能力架构概述Arena 数据科学家的AI任务管理工具12Kubernetes/DockerKubeflowArena CLI,SDKOther backends CRDPyTorch,Tensorflow,DeepSpeed,MPICPU/GPU/NPUEthernet/RDMAHDFS/OSS/CPFS/NASTriton,TensorRT,Kserve,HuggingFaceArena#提交分布式训练任务arena submit mpijob-name=tf-dist-data-workers=6-gpus=2-data=tfdata:/data_dir-env=num_batch=100-env=batch_size=80-image=ali-tensorflow:gpu-tf-1.6.0/root/hvd-distribute.sh 12 2”#查看训练任务arena get tf-dist-dataNAME STATUS TRAINER AGE INSTANCE NODEtf-dist-data RUNNING tfjob3d tf-dist-data-tfjob-ps-0 192.168.1.120tf-dist-data SUCCEEDED tfjob3d tf-dist-data-tfjob-worker-0 N/Atf-dist-data SUCCEEDED tfjob3d tf-dist-data-tfjob-worker-1 N/AYour tensorboard will be available on:192.168.1.117:32594用一个工具屏蔽所有底层资源、环境管理、任务调度、GPU分配和监控的复杂性兼容多种深度学习框架 PyTorch,Tensorflow,MPI,DeepSpeed,Horovod提供命令行，go/java/python SDK深度学习生产流水线 训练数据管理，任务管理，模型开发，分布式训练、评估，推理上线等全流程已开源贡献到Kubeflow社区,https:/ submit):PyTorchHorovodDeepSpeedTensorflow一键拉起可扩展一键拉起可扩展AI推理服务推理服务(arena serve):Triton Inference ServerKServeHuggingFace Text-generation-inference(TGI)TensorRTStable Diffusion WebUIArena AI生产流水线生命周期管理14Model v1Submit training job1.arena submitKubernetes for trainingKubeFlow(TF,MPI Operator)1.Deploy job2.Lifecycle mgmt/job:ps/task:0/job:ps/task:0/job:worker/task:1/job:worker/task:0(chief)/job:worker/task:2Continuous TrainingModel v2Model v3ExportData ScientistUpdating model for inferenceModel RepositoryOperatorMulti-version models2.arena serve kserveUpdate canary traffic percentA/B TestKubernetes for serving90%Pre revision10%Latest revisionREST API or gRPCApplications3.arena serve update kserve是一个面向云原生数据密集型应用的数据编排框架，帮助用户管理和运维缓存、简化系统部署和访问、编排数据消费流程。Fluid核心功能：数据抽象与管理:通过Dataset、Runtime、DataOperations概念分别描述数据源、缓存运行时和数据缓存运维操作。缓存弹性与调度:结合自动弹性，亲和性调度等多维度能力管理多种分布式缓存系统，提升数据访问效率异构环境无缝兼容:支持原生K8s、Serverless K8s、混合云等运行环境。兼容云上云下异构存储系统。数据流任务编排:支持多个数据消费和操作间的依赖定义，自动化数据消费过程。开源项目https:/ Project之一Fluid AI数据加速与编排框架Fluid-可弹性伸缩的计算侧分布式缓存业务场景决定模型加载的频次和数据I/O访问模式，造成对数据缓存的不同需求模型推理服务一次发布更新完成，模型均已加载到GPU对外提供服务=缩容缓存节省资源业务洪峰触发推理服务扩容=临时自动缓存扩容，加速服务冷启动Fluid：精细化控制数据缓存生命周期，根据业务需求弹性扩容、缩容数据缓存Cache WorkerCache WorkerStep 1:缓存部署Cache WorkerCache WorkerStep 2:推理服务拉起ModelServingModelServingStep 3.a:缓存缩容Cache WorkerCache WorkerCache WorkerStep 3.b:业务感知扩容Cache Replicas=0业务洪峰场景270.9388.841.456.40200400600Llama-30BFalcon-40B模型加载耗时对比（单位：秒）OSSFluid缓存优化云原生AI套件控制台集群大盘开发、调试一键发布服务ACKPytorchTensorflowGPU NodegpugpuPytorchTensorflowGPU NodegpugpuDatasetSchedulingvolumevolumearenaarenaArenaCLI/SDKSLB负载均衡用户AI运维控制台数据集一键加速成本分析作业大盘Scaling提交、管理训练任务定时任务工作流编排模型评测用户权限配额管理低延时LB直通pod蓝绿发布、服务化运维算力、数据的弹性、加速GPU大盘运维管理员数据科学家/算法工程师两类角色通过开发/运维控制台简便操作。角色间职责分离，控制AI资产权限隔离的同时，确保角色间高效协同。GPU共享调度开发控制台 数据科学家的web版实验室18帮助数据科学家集中式管理，包括：查找集群资源 Web IDE帮助开发调试模型代码 提交、管理训练任务 执行定时任务 管理数据集和训练代码源 管理模型 评估模型质量 发布模型推理服务1.创建自己的notebook开发环境（支持Jupyter和VSCode）2.调试训练代码3.b 也可以用内置arena命令行提交训练任务3.a arenasdk 提交训练代码运维控制台 AI平台管理员的运维中心19帮助AI平台Admin，可视化地配置、管理和监控集群，包括：GPU资源和任务大盘 用户接入凭证、资源配额 数据集管理和缓存加速 弹性任务状态和成本监控集群级别大盘节点级别大盘任务级别大盘用户配额管理弹性成本分析AIGC/大模型应用场景案例03文生图场景的解决方案OSS 全量冷模型池Fluid Cache workerFluid Cache workerFluid Dataset热模型缓存（弹性分布式缓存）SD文生图服务SD WebUI 服务 Pod（AIACC推理优化）SD WebUI 服务 Pod（AIACC推理优化）FUSE PodArena CLI/Helm应用Fluid DataFlow模型一键下载文件缓存预热一键部署模型推理服务（用户体验优化）数据处理流水线（运维流程简化）模型加载加速（性能优化）应用场景为用户提供多风格SD模型的实时图片生成服务，用户可自选不同风格的模型，也可以上传自己微调后的风格模型。Service&Load Balancer模型推理加速（性能优化）LLM+知识库问答的解决方案应用场景基于私域知识+大语言模型（LLM）提供为用户提供客服式知识问答。Helm应用Chat应用前端PodChat应用前端PodChat ServiceLLM ServiceLLM推理Pod(DeepGPU推理优化)LLM推理Pod(DeepGPU推理优化)Ingress一键部署架构方案（用户体验优化）模型推理性能优化（性能优化）阿里云AnalyticDB高效向量检索（性能优化）Baichuan、通义千问多模型支持（AI生态集成）ACK云上大规模Kubernetes集群高可靠性保障实战刘佳旭（佳旭）阿里云容器服务 技术专家目录01集群稳定性和大规模场景的挑战02稳定性治理和优化策略03稳定性产品功能和最佳实践集群稳定性和大规模场景的挑战01Kubernetes 集群常见的稳定性痛点！在发布、弹性等高峰期，集群控制面服务时断时续，甚至完全不可用节点上kubelet并发拉取镜像遇到网络带宽限制，需要镜像加速功能支持集群节点批量 NotReady导致雪崩，严重影响业务！部分节点出现NotReady，节点上Pod被驱逐或者Terminate调度到健康节点，健康节点由于压力过大也变为NotReady，加剧产生了更多NotReady的节点，业务持续重启需要大量的线上场景分析和优化、故障处理、规模压测等，来分析、整理并落地最佳实践和配置Kubernetes在提供丰富的技术功能之外，因架构和运维的高复杂性，产生诸多的痛点业务高峰期需快速弹性，节点上拉取Pod镜像耗时长达分钟级，影响业务Master节点/组件运维复杂度高，包含资源配置、参数调优、升级管理等面对大流量请求，如果控制面没有自动弹性扩容能力，会无法对负载自适应、导致控制面服务不可用。例如：客户端存在持续LIST大量资源，集群apiserver/etcd无法自动弹性就会联动出现 OOM。Kubernetes 集群架构控制面数据面节点(ECS/ECI)负载均衡kubernetes svc系统组件（监控/日志/安全等）用户业务等其他组件负责集群的API层、调度、资源管理、云资源管理等控制面功能K8s组件：apiserver/etcd/scheduler/kube-controller-manger/cloud-controller-manager控制面负责集群的节点管理、Pod生命周期管理、Service实现等数据面功能，承载业务Pod的主体K8s组件：kubelet/kube-proxy系统组件：日志、监控、安全等组件其他组件:用户业务组件数据面负责为K8s集群提供节点、SLB等云资源，与云厂商的产品实现直接关联云资源：负载均衡SLB、云服务器ECS、弹性容器实例ECI、专有网络VPC、文件存储NAS、弹性公网IP EIP等云资源控制面、数据面和云资源是有机结合的整体！集群的全链路中，有任何一个组件、子链路成为瓶颈，都可能影响到集群的整体稳定性Kubernetes 稳定性体现服务可用性集群控制面组件和数据面组件提供稳定可靠的服务例如：无持续重启、OOM、资源泄露、IOHang请求QPS和流量吞吐系统对请求和流量吞吐的处理能力在预期范围内例如：APIServer处理请求不会持续出现限流；对APIServer、Ingress的SLB等云资源的带宽和连接数不出现持续打满处理时延请求时延在预期范围内例如：APIServer的请求时延(RT)、弹性扩容节点的拉起时间、Kubelet创建Pod的端到端时间资源水位CPU/内存/IO等资源的波动在安全预期的范围内例如：节点水位，K8s核心组件水位集群稳定性涵盖 Kubernetes 服务可用性、服务质量以及用户体验等要素Kubernetes 稳定性风险和挑战集群内资源种类繁多，数量巨大大规模集群场景下常见。包含原生K8s资源和丰富灵活的CRD资源。例如：单集群超过1万节点规模、单集群有10W+的namespace以及ns下secret/configmap资源数据面压力、以及数据面与控制面同步压力的风险数据面节点出现压力以及异常。节点负载压力过高，导致kubelet/运行时响应慢或者无响应，甚至节点状态NotReady。数据面与控制面同步瓶颈。数据面与控制面网络带宽打满或者网络不通，kubelet 无法及时更新node 状态，导致节点状态 NotReady，导致容器调度、service后端流量转发受影响。控制面压力的风险控制面组件缓存集群的部分或者全部资源。在大规模场景下，每个组件都会有明显的资源压力。超过资源Limits就会触发OOM等问题。例如apiserver将etcd中全部资源在内存中缓存以便响应客户端对Cache的LIST请求。请求来源复杂。包括随节点规模正增长的kubelet/kube-proxy/daemonset，也包括系统组件和用户部署的组件。云资源稳定性和高可用稳定性有限的云资源容量。例如SLB的连接数、带宽，ECS的内存、CPU等等，存在打满的风险。集群的核心云资源和组件需要按高可用架构部署。包括跨节点、AZ等不同高可用等级。ACK 集群稳定性治理和优化策略02ACK K8s 稳定性优化ACK对线上丰富的客户和业务场景提供全面支持ACK全网管理数万托管版 Kubernetes集群全场景覆盖阿里巴巴电商场景极限压力ACK作为底座承载阿里巴巴双十一、618等超大规模在线/离线业务原生K8s的深度优化和产品化能力实现对社区原生K8s做参数、性能、架构等优化，并融合进产品能力2023年7月，ACK 成为首批通过中国信通院“云服务稳定运行能力-容器集群稳定性”评估的产品，并荣获“先进级”认证。ACK稳定性源于大规模实践经验沉淀。010203Spark/Flink 等大数据场景ECI/Spot 等快速弹性场景Tensorflow/Pytorch/Arena 等 AI 场景ArgoWorkflow 等任务流场景云上规模化，支持单集群上万节点场景针对丰富的业务类型和大规模场景进行优化针对典型业务AI、大数据等丰富的场景，均做过场景化和规模化优化方案，形成云产品和客户的支持案例4.集群容量规划和自动弹性1.高可用架构5.可观测性增强2.K8s 优化3.系统组件优化、用户组件优化最佳实践6.质量巡检、故障演练、压测体系ACK集群稳定性治理关键点控制面全面按高可用架构部署。数据面提供丰富的高可用产品能力和配置，便于用户提升集群的高可用性。控制面托管组件支持根据请求负载自动弹性扩缩容。例如：规范LIST请求使用、优先使用Informer机制、优先使用PB协议等等。包括APIServer/Etcd/KCM/Scheduler/Kubelet/Kube-proxy等组件的优化、参数配置等。控制面可观测对用户透出。数据面提供丰富的集群、节点、工作负载、Ingress等监控告警。数据面支持快速扩容和快速启动。ACK组件和集群自动化巡检、定期进行的故障演练和应急预案恢复验证、高效的压测体系7.数据面优化节点自动运维和自愈能力，P2P镜像加速传输控制面实现可用区级别高可用全部控制面组件实现与阿里云 ECS 的可用区能力对齐的高可用打散。以 APIServer 为例，多副本跨AZ、跨节点高可用部署方式，任何一个AZ 失效不影响服务可用性。在 3AZ 地域，ACK 托管集群控制面的 SLA 是 99.95%。对于不具备3AZ 的地域，ACK 托管集群控制面 SLA 是 99.5%（不具备单可用区的故障容忍）。数据面支持客户配置丰富的高可用策略对于Pod，支持基于节点、部署集、AZ等不同故障域，结合K8s调度中的拓扑分布约束（Topology Spread Constraints），实现不同等级的高可用策略；云盘、负载均衡、虚机节点等云资源均支持K8s场景下按多AZ打散配置。高可用架构高可用架构设计是K8s系统稳定性的基石ACK集群架构拓扑Kubernetes API 请求深入解析GET/LIST 请求携带ResourceVersion(RV=X)：1.如果Cache中版本=X,返回Cache中版本;否则 在3s超时期间内持续重试；否则报错“Too large resource version”2.如果RV=0，返回Cache中版本GET/LIST 请求不携带ResourceVersion：Apiserver对etcd一致性读（quorum read）Etcd过滤Etcd Key结构：/registry/resource type/namespace)/resource name 所以Etcd中过滤仅限于资源/namespace/具体资源，其他任何过滤 例如：基于labelSelector/fieldSelector的过滤都在apiserver 内存中进行过滤。Informer请求包括：LIST（RV=0）+WATCH（RV=X，X来自于LIST请求），在客户端本地维护Cache并WATCH apiserver进行更新，避免了频繁的LIST请求来进行更新。推荐使用Informer方式访问APIServer。GET/LIST请求分析结论不带ResourceVersion的LIST请求，请求会击穿到etcd和apiserver，对系统压力最大，如果使用labelSelector/fieldSelector只能在apiserver内存中过滤，不会减少对etcd压力；informer 通过LIST+WATCH的请求组合，最大化降低对控制面apiserver和etcd的压力，是推荐的机制。K8s资源有ResourceVersion(RV)，等于etcd保存对象的revisionapiserverclient(informer)CachehandlerhandlerstorageGET/LISTRV=“”clientclientGET/LISTRV=XhandlerWATCH通过Event增量更新clientcacheWatcherLIST请求示例请求示例方法1.LISTLIST apiapi/v/v1 1/pods?filedSelectorpods?filedSelector=spec=spec.nodeNamenodeName%3 3DworkerNodeDworkerNode1 1访问 apiserver 跳过缓存，从 etcd 进行一致性读数据etcd 只是 KV 存储，没有按 labelSelector/fieldSelector 的过滤功能（只处理 limit/continue），apiserver 是从 etcd 读取全量数据，然后在内存做过滤2.LISTLISTapiapi/v/v1 1/pods?filedSelectorpods?filedSelector=spec=spec.nodeNamenodeName%3 3D D3 3DworkerNodeDworkerNode1 1&resourceVersion=&resourceVersion=0 0跟#1 的区别是加上了 resourceVersion=0，因此 apiserver 会从缓存读数据，性能会有量级的提升，尤其在大规模场景下3.LISTLIST apiapi/v/v1 1/pods?limitpods?limit=500500&resourceVersion=&resourceVersion=0 0虽然使用了limit分页方式访问，但 resourceVersion=0 会导致 apiserver 忽略 limit=500，所以客户端从缓存中拿到的数据是全量pod数据控制集群资源集群稳定性优化方法1.控制Node、Service、Secrets、Configmap等K8s资源的数量以及单个资源的Size；https:/ Operator会Watch集群中全部secret，客户单集群Secret达到40W，导致Operator启动时间慢，占用大量内存到5-6GiB，甚至OOM2.K8s资源合理分配到不同namespace（避免全部资源全部放到一个namespace）案例：集群在一个namespace下定时创建Job，且没有label，导致出现数十万Job，甚至无法LIST并删除。最终用户提工单求助、ACK通过从管控etcd直接读取Job清单提供客户用于清理。3.避免单个集群规模过大，单集群也是一种形态的单点架构，合理拆分集群当单个集群规模过大时，不仅会给Master资源容量和性能带来挑战，也会增加集群业务层面的故障爆炸半径。单个集群节点数上限为5000，通过白名单可以继续提升配额。建议选择多个集群承载业务。作用资源隔离，降低管控面压力，降低流量传输规范组件LIST请求序列化编码方式统一组件稳定性优化方法必须使用全量LIST时添加resourceVersion=0，从APIServer cache读取数据，避免一次请求访问全量击穿到etcd；从etcd读取大量数据，需要基于limit使用分页访问方法对非CRD资源的API序列化协议不使用JSON，统一使用Protobuf作用相比于JSON更节省传输流量客户端访问资源频度作用降低对管控的资源和带宽压力方法客户端控制访问大规模全量资源的频度优先使用Informer机制大规模场景下，频繁LIST大量资源会对管控面APIServer和etcd产生显著压力。频繁LIST的组件需要切换使用Informer机制。作用基于Informer的LIST+WATCH机制优雅的访问控制面，提升访问速度，降低对控制面压力作用加快访问速度，降低对控制面压力降低管控的资源和带宽压力，提升稳定性方法大规模场景下，对于Daemonset、ECI pod等对APIServer进行访问的场景，可以设计可横向扩容的中继组件，由中继组件统一访问APIServer，其他组件从中继组件获取数据。例如ACK的系统组件poseidon在ECI场景下作为networkpolicy中继使用。作用组件稳定性优化对APIServer访问的中继方案APIServer 稳定性优化方法：ACK 管控基于访问压力和集群容量实现 APIServer实例自动弹性。作用：实现动态自适应请求压力。方法：负载不均会导致个别APIServer实例资源开销大、容易触发OOM。Goaway特性概率性断开并新建TCP连接，实现负载均衡的效果。作用：帮助稳定运行的集群能解决负载不均衡问题。方法：APIServer启动后，如果APIServer与etcd之间的cache还没Ready，拒绝资源消耗大的LIST请求并返回429；cache Ready后，提供LIST服务。作用：保障 APIServer在刚启动后不会因为资源消耗大的请求而触发OOM。apiserverapiserverCachehandlerstorageclient(informer)clientLISTAPIServer自动弹性软负载均衡APISever CacheReady保护APIServer 稳定性优化GO 参数优化托管组件可观测性透出ECI 场景索引优化方法1.GOGC参数配置Go1.18 gc阀值算法调整，Go1.18 对应的1.24版本内存会提高25%(数据来自社区:https:/ GC 配置管理，控制 APIServer 内存资源堆积，进而减少 OOM 的可能性；通过并发度控制，提升APIServer goroutine 效率方法作用ECI场景下支持多索引。在原生K8s只支 持 node-name-index 索 引 基 础上，添加 pod-name-index 索引。压测中降低 60%CPU 消耗以上数据来源于阿里云内部测数据1.全部托管组件apiserver、etcd等监控告警对用户透出APIServer 稳定性优化集群资源清理 关闭不需要功能及 时 清 理 不 使 用 的 Kubernetes 资 源，例 如 configmap、secret、pvc等关闭不使用的功能，降低资源开销。例如资源消耗较大的ServerSideApply功能Data 和 Event etcd分拆AutoDefragEtcd 根据资源画像 VPAEtcd 稳定性优化数据和事件流量分离，消除事件流量对数据流量的影响；降低了单个 etcd 集群中存储的数据总量，提高了扩展性apiserver根据资源画像动态VPA方法Data和Event存放到不同的etcd集群作用动态资源容量调整，减少 OOM方法根据Etcd资源使用量，动态调整etcd Pod request/limits作用降低db大小，提升查询速度方法operator监控etcd集群db使用情况，自动触发defrag清理db作用QPS/Burst 参数调优控制器客户端限流Request succeededRequest throttledScheduler/KCM/CCM 稳定性优化保证控制器可以高效通过APIServer同步数据和状态，避免出现更新延迟的问题方法KCM/Scheduler/CCM的QPS/Burst参数在规模化场景下需要提升，避免核心组件出现客户端限流；同时观测APIServer监控，避免APIServer对核心组件限流。作用稳定性产品能力和最佳实践03ACK 稳定性产品功能助力客户从可观测性（监控告警）、故障预防与定位、自动化节点运维角度提升透明可观测、风险可预测、故障可定位、运维自动化的稳定性保障Prometheus For ACK Pro容器AIOps套件（故障预防与定位）托管节点池Prometheus for ACK ProPrometheus for ACK Pro包含一组符合关联分析逻辑且可交互的大盘，包含：全局资源总览、节点总览Kubernetes核心托管组件（APIServer、etcd、scheduler、kcm、ccm、etc）集群事件分析eBPF无侵入式应用指标，系统指标，网络指标(以上截图来自于阿里云测试账号)容器AIOps套件-故障预防与定位10年大规模容器运维经验沉淀，自动化诊断覆盖90%的问题场景全栈巡检集群健康度巡查应用可用性巡检平台安全性巡检升级检查版本兼容性评估配置冲突检测业务影响评估智能诊断集群事件流分析网络仿真与诊断OS内核指标分析专家系统+大模型容器服务 ACK集群公有云IDC在偶发性网络抖动场景，基于ACK内核网络智能化分析，快速定位异常网络栈路径，定位时间从周缩短到小时在容器应用响应时间抖动场景，使用AI智能诊断，联动Ingress、容器、内核快速定位，从小时优化到分钟级别（以上数据为客户业务场景应用结果）托管节点池用户专注上层应用部署，ACK负责节点池基础运维管理自升级自愈安全修复弹性Kubelet节点组件运行时内核CVE修复内核加固快速启动快速扩容容器优化OS：ContainerOSP90统计下，1000节点扩容 55s通用OSAlibaba Cloud Linux、CentOS容器服务 ACK集群节点诊断和自愈：运行时、操作系统CVE安全问题自动修复节点kubelet小版本自动升级节点组件自动升级（containerd/systemd等）展 望ACK稳定性保障建设会持续演进，会继续为客户提供安全、稳定、性能、成本持续优化的产品和稳定性保障！阿里云ACK云原生GPU集群管理与运维如何应对大规模异构计算集群的运维和管理挑战？霍智鑫（凭御）阿里云-云原生-容器智算2024/01/05异构计算集群运维难点异构计算集群物理架构以NVIDIA GPU为例，一个GPU集群在硬件层面运维与管理的复杂度表现在多个方面（网络、存储通信等）GPU NodeGPU NodeGPU NodeGPU NodeRDMARDMAEthernetEthernet异构计算集群软件架构以NVIDIA GPU为例，一个GPU集群所需要的软件栈从OS、Driver到CUDA、Application(Pytorch、Tensorflow)OS SupportOS Support(RedHat,Ubuntu)(RedHat,Ubuntu)(gcc,(gcc,glibcglibc)RDMA StackRDMA StackGDR LibGDR LibNVIDIA GPU Stack(Driver,fabricNVIDIA GPU Stack(Driver,fabric-manager)manager)CUDACUDA LibLibCUDNNCUDNN Lib,CUBLAS Lib,NCCL LibLib,CUBLAS Lib,NCCL LibPytorchPytorchTensorflowTensorflow传统 GPU 集群运维管理TeamTeam 1 1TeamTeam 2 2TeamTeam 3 3ClusterCluster AdministratorAdministrator硬件环境复杂度用户管理与使用方式运维复杂度存在问题一个团队&一个GPU节点低(低可扩展性)(低性能)Linux用户管理SSH多用户登录使用低(运维管理单台多用户节点的运行环境)多用户GPU进程设备抢占；单节点性能差，可扩展性低；适用业务规模有限制；一个团队&GPU集群高(中可扩展性)(一般性能)Linux用户管理SSH多用户多机登录使用高(运维管理多用户的集群运行环境)多用户GPU进程设备抢占；运维难度高于线性增加；分布式使用方式复杂；多个团队&GPU集群高(中可扩展性)(一般性能)Linux用户管理SSH多用户多机登录使用高(运维管理多租户和多用户的集群运行环境)多用户GPU进程设备抢占；运维难度高于线性增加；分布式使用方式复杂；无法进行较好的多租资源管理；多个团队&高性能GPU集群极高(高可扩展性)(高性能)Linux用户管理SSH多用户多机登录使用极高(运维管理多租户和多用户的复杂集群环境)多用户GPU进程设备抢占；运维难度指数级上升；分布式使用方式复杂；无法进行较好的多租资源管理；较难将集群中硬件资源进行充分利用；传统的GPU节点或集群的管理和运维方式具有比较差的用户和运维体验与较高的管理复杂度ACK GPU集群解决方案ACK 云原生AI架构全景图K8s、容器运维人员IaaS运维人员AI平台运维人员算法工程师数据科学家用户用户AIAI平台平台阿里云阿里云AI服务服务开源开源AI框架与模型框架与模型命令行工具管理控制台SDK弹性数据集分布式缓存大数据集成弹性分布式训练弹性推理服务批任务调度弹性配额拓扑感知数据感知CPUGPUNPUFPGA混合负载监控多租户弹性伸缩模型AI容器镜像第三方第三方AIAI方案方案公共云公共云专有云专有云边缘边缘混合云混合云AIAI任务管理任务管理AIAI数据加速数据加速AIAI弹性弹性AIAI调度调度异构算力加速异构算力加速仓库仓库运维运维GPU/NPU共享实验容器服务（容器服务（ACK/ASK/ACK/ASK/ACKEdgeACKEdge）流水线RDMA异构存储接入异构存储接入OSSHDFS优先级队列工作流开发环境故障诊断Kubeflow/Spark/MPI在阿里云ACK上的问题解决多容器共享GPU，提升运行密度GPU分配策略，避免资源碎片GPU显存维度池化，新老卡统一利用GPU弹性伸缩，优化持有成本GPU拓扑感知调度，保证分布式训练通信最大带宽从单个GPU设备入手从多GPU集群入手GPU软件栈分层自动化部署，用法高度可自定义化节点上GPU设备维度的GPU监控多型号多规格GPU设备支持，卡间高性能通信支持GPU集群节点池化管理，便于对不同节点分类管理完整的集群维度和任务维度的GPU监控GPU集群高弹性，高可扩展性从单台GPU节点入手从整个GPU集群入手GPU集群运维管理GPU集群资源利用率提升软件栈自动化部署Kubernetes组件自动化部署GPU实例弹性伸缩NVIDIA GPU Driver(可自定义版本)NVIDIA-Container-Runtime(可自定义版本)