Kubernetes 1.35：从容器编排到通用调度平台的范式转移

1. 从“容器编排器”到“通用调度平台”的十字路口最近在社区里看到不少关于Kubernetes 1.35版本更新的讨论一个很有意思的观点是“K8s正在变成另一种系统”。作为一个从K8s早期版本就开始在生产环境里折腾的老兵我对这个说法感触颇深。它不再仅仅是我们认知里那个“把Docker容器管起来”的编排工具了。这次更新尤其是围绕AI Workload的一系列增强更像是一个明确的信号标志着Kubernetes正在从一个“容器编排器”向一个“通用、异构工作负载调度平台”进行深刻的范式转移。AI负载只是一个开始它暴露了K8s底层架构为了适应未来更广泛、更复杂计算场景所必须做出的改变。回想几年前我们部署一个Web服务关心的是副本数、服务发现、滚动更新。那时的K8s核心是“调度Pod到Node”资源模型相对简单CPU、内存、磁盘、网络。但如今当你试图把一个大规模语言模型训练任务或者一个实时推理服务塞进集群时你会发现原有的那套模型有点“捉襟见肘”。你需要考虑的不再是几个容器而是GPU卡的拓扑结构、高速网络如InfiniBand的亲和性、模型分片与流水线并行、Checkpoint存储的巨量I/O甚至是特定AI芯片如NPU、TPU的驱动与资源隔离。K8s 1.35的更新正是在这些“痛点”上持续发力试图为这些异构、有状态、对资源拓扑极度敏感的工作负载提供原生级的支持。所以当我们说K8s在变成“另一种系统”时我们到底在说什么我认为核心在于两点一是资源抽象模型的极大扩展与精细化从简单的标量资源到复杂的扩展资源、拓扑感知调度二是控制平面的职责边界在模糊和延伸它开始更多地介入到工作负载的生命周期管理、硬件特性的协调而不仅仅是容器的启停。接下来我们就结合1.35版本的一些关键特性深入聊聊这场静默的变革。2. 1.35版本更新为AI与异构计算铺平道路Kubernetes 1.35版本包含了一系列更新其中不少都直接或间接地服务于AI、高性能计算HPC以及更广泛的异构工作负载。这些更新不是孤立的功能点而是构成新能力基座的一块块拼图。2.1 动态资源分配Dynamic Resource Allocation, DRA进入稳定版这是本次更新中最重磅的特性之一。在以前K8s管理像GPU、FPGA、智能网卡这类设备主要依赖device plugin机制和extended resources。这种方式是静态的节点上报我有几个“nvidia.com/gpu”调度器按整数个进行分配。但这带来了几个问题1无法细分资源比如共享一块GPU的内存2设备初始化配置如GPU的MIG模式划分与K8s调度脱节3设备的上报、分配、清理生命周期难以精细管理。DRA机制就是为了解决这些问题而生的。它引入了一个名为ResourceClaim的API对象。工作负载Pod不再直接请求nvidia.com/gpu: 1而是创建一个ResourceClaim来声明自己需要某种类型的资源。这个Claim会被一个特定的ResourceDriver由设备厂商提供处理。ResourceDriver可以动态地决定如何满足这个Claim——它可以分配一整块设备也可以分配一个子分区如一个MIG实例甚至可以进行复杂的设备初始化配置。为什么这对AI负载至关重要想象一个场景你的集群里有A100 GPU。有些训练任务需要整卡有些小的推理任务只需要一部分算力。通过DRA和对应的NVIDIAResourceDriver你可以实现将一块A100物理卡划分为多个MIGMulti-Instance GPU实例。训练任务Pod申请一个“完整的A100” Claim获得整卡。推理任务Pod申请一个“A100-MIG-1g.5gb” Claim获得一个算力为整卡1/7的实例。 调度器和资源驱动协同工作实现了单块物理GPU资源的细粒度、动态共享极大提升了昂贵硬件资源的利用率。这超越了简单的“调度”进入了“资源切分与编排”的领域。2.2 基于污点的节点驱逐机制进入BetaNode taint based eviction这个特性听起来很底层但它对运行长时间任务如AI训练的稳定性至关重要。传统上当节点出现内存压力、磁盘压力等问题时kubelet会基于eviction signal直接驱逐Pod。这种方式是“一刀切”的可能误伤那些高优先级或难以迁移的Pod比如已经运行了数天的训练任务。新机制允许你给节点添加诸如memory-pressure、disk-pressure之类的污点。当节点条件满足时自动打上污点。关键点在于Pod可以通过tolerationSeconds来容忍这些污点一段时间。例如一个AI训练Pod可以设置tolerations: - key: memory-pressure, operator: Exists, effect: NoExecute, tolerationSeconds: 300。这意味着当节点内存不足时该Pod不会被立即驱逐而是获得了5分钟的“宽限期”。在这5分钟内监控系统可以告警运维人员可以介入排查或者工作负载自身可能完成一个临时的Checkpoint。这给了复杂有状态负载一个宝贵的缓冲地带避免了非受控的中断是K8s向“任务感知型”平台演进的一小步。2.3 结构化身份验证配置Structured Authentication Configuration稳定化这个特性主要面向安全和管理。它允许集群管理员通过Kubernetes API而不是静态文件来定义身份验证链。例如你可以配置同时支持客户端证书、静态Token、Webhook等多种认证方式并定义它们的顺序。对于AI/ML平台而言这意味着可以更灵活地集成企业内部的统一认证系统如LDAP、OIDC并为不同的用户组数据科学家、算法工程师、运维配置不同的认证方式。平台团队可以动态管理认证策略无需重启API Server。这虽然不直接提供算力但为多租户、企业级的AI平台奠定了安全基石使得K8s能更好地融入企业IT环境承担更核心的调度角色。2.4 其他值得关注的增强Pod就绪门Pod Ready GatesPod除了容器就绪外可以定义自定义的“门”条件。这对于AI负载很有用比如一个推理服务Pod可能需要等待从外部存储加载完巨大的模型参数文件后才能被视为真正“就绪”并接收流量。这使生命周期管理更精细化。容器检查点Container CheckpointAPI (Alpha)允许对运行中的容器创建检查点并恢复。这虽然还在早期阶段但为未来实现AI训练任务的“热迁移”或快速恢复提供了想象空间是K8s向管理“有状态计算任务”迈进的技术储备。3. AI Workload的独特挑战与K8s的应对逻辑要理解K8s为何要变必须看清AI工作负载到底带来了哪些传统微服务不曾有过的挑战。我结合自己部署和管理大规模分布式训练任务的经验总结出以下几个核心痛点以及K8s社区相应的解决思路。3.1 挑战一对硬件拓扑的极致敏感传统的Web服务对“在哪台机器运行”不敏感只要资源够用就行。但分布式AI训练尤其是使用GPU完全不同。GPU间通信同一台机器上的多块GPU通过NVLink高速互联跨机器的GPU则通过InfiniBand或RoCE网络。训练任务希望同一模型分片Model Shard或同一数据并行组内的GPU能尽量放在NVLink互连的卡上其次是同一台机器最差才是跨机。网络与存储参数服务器PS或All-Reduce通信模式对网络延迟和带宽要求极高。数据预处理流水线则需要高吞吐的存储。K8s的应对拓扑感知调度Topology-Aware Scheduling这不仅仅是nodeSelector选个有GPU的节点那么简单。它需要调度器理解节点内部的硬件拓扑。K8s通过设备插件上报拓扑信息NVIDIA k8s-device-plugin等可以上报GPU的NUMA节点归属、NVLink连接关系等。调度器扩展使用NodeResourceTopologyAPI或调度器插件如TopologyManager让调度器在做决策时不仅考虑资源数量是否足够还要考虑资源的质量拓扑关系。例如它可以优先选择那些能提供2块通过NVLink互连的GPU的节点给一个需要紧密通信的2卡训练任务。在1.35及之前的版本中相关的特性如TopologyManager、CPUManager都在持续增强目标就是让调度决策从“二维”有/无资源升级到“三维”有资源且资源的拓扑排列最优。3.2 挑战二任务的生命周期与协同复杂度高一个分布式训练Job不是一组独立Pod的集合。它通常包含Master/Worker角色一个负责协调的Master Pod和多个执行计算的Worker Pod。严格的启动顺序Worker需要等待Master准备好通信地址后才能启动。集体故障处理一个Worker失败整个训练任务可能需要暂停、恢复或重启。弹性伸缩需求弱训练任务通常资源需求固定但推理服务可能需要根据请求量快速伸缩。K8s的应对工作负载API与操作符Operator的兴起原生Deployment/StatefulSet擅长管理无状态和简单的有状态应用但对上述复杂模式力不从心。因此社区催生了更高级的抽象Job与CronJob的增强用于批处理任务但分布式协同仍需自己处理。Kubernetes Operator模式这是应对此挑战的“事实标准”。例如Kubeflow Training Operator、PyTorch Operator、MPI Operator。这些Operator是专门为管理特定类型AI任务而生的控制器。它们封装了领域知识知道如何为PyTorch Elastic Job配置正确的环境变量让Worker能自动发现彼此。知道在训练任务失败时是应该重启整个Job还是尝试从最新的Checkpoint恢复。提供了自定义资源定义CRD如PyTorchJob、TFJob让用户可以用声明式的方式提交一个分布式训练任务而无需手动编排一堆Pod和服务。Operator的出现意味着K8s的控制平面被“扩展”了。用户不再直接与Pod API交互而是与一个代表“AI训练任务”的高级抽象交互。K8s的核心系统API Server, Scheduler, Controller Manager提供了让这些领域特定控制器安全运行的平台自身则专注于提供更强大的底层原语如DRA、拓扑调度供Operator调用。这是K8s变成“另一种系统”的典型体现它成为了一个“用于构建领域特定编排系统的系统”。3.3 挑战三资源类型与配置的爆炸性增长AI领域硬件迭代飞快从通用GPU到训练专用芯片TPU、推理专用芯片NPU再到各种内存计算、光计算设备。每种设备都有其独特的驱动、运行时库和配置方式。K8s的应对扩展资源与设备插件框架的演进K8s很早就通过“扩展资源”Extended Resources和“设备插件”Device Plugin框架来支持自定义硬件。其演进逻辑是标准化接入接口提供一个统一的Device PluginAPI任何硬件厂商只要实现这个接口就能将其设备资源接入K8s集群被调度器感知。资源抽象与解耦Pod通过resources.limits来请求vendor-domain/resource-name如amd.com/gpu。调度器只关心资源的数量不关心具体实现。向动态、精细化管理演进这就是DRA要解决的问题让资源的分配从静态整数走向动态、可配置。这个框架的成功使得K8s能够以相对统一的方式管理几乎任何类型的计算设备为它成为“通用调度平台”打下了最关键的基础。4. 超越AIK8s作为通用调度平台的未来图景如果K8s的改变仅仅是为了服务AI那或许还称不上“变成另一种系统”。真正的趋势是为AI负载打磨的这些能力恰好解锁了K8s管理其他各类复杂、异构工作负载的潜力。我们可以从几个维度来看这个未来。4.1 边缘计算与混合云边缘场景的特点是资源极度异构从x86服务器到ARM工控机再到带GPU的边缘盒子、网络不稳定、需要轻量级。K8s的衍生项目K3s、KubeEdge等已经证明了其架构在边缘的适用性。而1.35中稳定的DRA、增强的拓扑调度使得K8s能更好地调度边缘设备上特定的硬件加速器如AI推理卡、视频编码卡并根据网络拓扑优化任务放置例如将人脸识别任务调度到摄像头最近的、带NPU的边缘节点上。4.2 高性能计算HPC传统HPC使用Slurm、PBS等作业调度系统。这些系统对MPI任务调度、高性能网络InfiniBand绑定有着深厚的积累。现在我们看到K8s正在通过MPI Operator、对RDMA网络的支持、以及拓扑感知调度逐渐侵入这个领域。K8s的优势在于其统一的API、强大的容器化隔离、以及丰富的生态系统。未来一个科研机构或许可以用同一套K8s集群既运行传统的Web服务也运行需要MPI和InfiniBand的分子动力学模拟任务。4.3 大数据处理Spark、Flink等大数据框架早已支持在K8s上运行。但它们的资源请求往往是粗粒度的。随着DRA等技术的成熟Spark任务或许可以更精细地申请带特定SSD的本地存储资源用于Shuffle或者申请带智能网卡的节点来加速网络传输。K8s提供的统一资源视图和调度能力有望让大数据平台和AI平台更深度地融合共享底层硬件资源池。4.4 平台工程的基石最后从软件工程的角度看K8s正在成为“平台工程”Platform Engineering的理想底座。平台团队基于K8s提供的强大原语CRD、Operator、调度框架、资源模型为内部用户开发者、数据科学家构建高度抽象、领域特定的“内部开发者平台”。数据科学家提交一个PyTorchJob开发者部署一个Serverless Function所有这些都运行在同一个K8s集群上但通过不同的Operator和抽象层被管理。K8s本身则退居幕后成为那个稳定、可靠、提供无限可能的“资源操作系统”。5. 拥抱变化从业者的实操思考与建议面对K8s的这种演进作为一线工程师或架构师我们应该如何应对以下是我基于实践经验的一些思考。5.1 技术选型与学习路径的调整过去学习K8s核心是Pod、Service、Deployment、Ingress这些对象。现在和未来你需要拓宽视野深入理解调度原理不能满足于知道nodeSelector和affinity。要去理解Scheduler Framework、Scheduling Profile、TopologyManager的工作原理。这是K8s智能化的核心。掌握Operator开发模式如果你所在团队有特定的、复杂的工作负载不一定是AI考虑学习Operator SDK为你自己的领域构建一个自定义控制器。这能极大提升运维效率和用户体验。关注硬件与底层多了解一些硬件知识比如GPU的架构、NVLink、InfiniBand、NUMA。当你需要排查“为什么我的训练任务比别人慢”时这些底层知识会成为关键。拥抱云原生生态关注像Kueue用于作业队列管理、Volcano用于批处理调度这样的上游孵化项目。它们代表了社区在特定调度领域的最新探索。5.2 集群规划与运维的考量资源模型标准化提前规划你的扩展资源命名规范。例如统一使用company.com/gpu而不是混用nvidia.com/gpu和amd.com/gpu可以通过设备插件来映射。这为未来混合硬件池打下基础。混合工作负载隔离在同一个集群内运行AI训练抢占式、高资源消耗和在线服务延迟敏感需要精细化的隔离策略。除了传统的Namespace配额要善用PriorityClass、Pod Disruption Budget并考虑使用Node Pool或Taint/Toleration进行物理或逻辑隔离。监控与可观测性升级传统的CPU/内存监控不够了。你需要监控GPU利用率、显存、NVLink带宽、InfiniBand网络状态、自定义设备指标。Prometheus生态的node-exporter需要搭配dcgm-exporter、kube-state-metrics以及各设备厂商的exporter来构建全景视图。存储与数据流水线AI对存储的需求是海量和高速的。对象存储如S3兼容用于模型仓库和数据集高性能分布式文件系统如CephFS Lustre用于训练过程中的Checkpoint和临时数据。在K8s中需要通过CSI驱动妥善集成这些存储并利用Local PersistentVolume等特性优化数据本地性。5.3 一个具体的场景部署支持多租户的AI平台假设我们要基于K8s 1.35构建一个内部AI平台支持多团队提交训练和推理任务。架构思考如下底层资源池集群节点分为多个节点组高配GPU训练节点组、通用GPU推理节点组、CPU节点组。为GPU节点打上相应的taint如dedicatedgpu-training:NoSchedule。调度与队列使用Kueue项目。用户提交的PyTorchJob通过Training Operator创建并不会直接创建Pod而是先成为一个Workload资源进入Kueue管理的队列。Kueue根据集群资源情况、团队配额Quota和优先级决定何时、何地启动这个Job。这实现了公平共享和资源超卖的管理。多租户与安全每个团队一个Namespace。使用ResourceQuota限制总资源用量。结合Structured Authentication Configuration集成公司的OIDC实现单点登录和团队映射。使用NetworkPolicy严格隔离网络。任务管理平台提供封装好的PyTorchJob/TFJobCRD模板用户只需填写镜像、命令、数据集路径等业务参数。平台Operator负责注入必要的配置如GPU拓扑感知的环境变量、分布式训练的初始化方法等。数据与存储为每个团队创建独立的PVC后端连接高性能共享存储。通过初始化容器Init Container在任务启动前将指定数据集从中心仓库如S3同步到该PVC。训练输出的模型和日志也统一写入该PVC再由Sidecar容器同步回中心仓库。监控与成本集成DCGM、Prometheus为每个训练任务提供实时的GPU指标看板。开发一个简单的成本核算系统根据任务消耗的GPU小时数按团队进行统计。在这个架构里K8s扮演的角色远远超出了容器编排。它是资源池化者、调度决策者、安全边界实施者并通过Operator模式将领域知识如何运行一个分布式训练固化为了平台能力。用户感受到的是一个“AI平台”而非一个“容器平台”。Kubernetes的这次演进本质上是在回应一个更根本的需求在云原生时代如何统一地管理所有类型的计算任务从无状态Web服务到有状态数据库再到如今的AI训练、边缘推理、科学计算这些工作负载形态各异但对资源调度、生命周期管理、运维可视化的核心诉求是相通的。K8s没有停留在容器的层面而是选择向下吸收更复杂的硬件抽象向上通过扩展点CRD, Operator, Scheduler Framework开放出无限的可能性。AI Workload只是一个催化剂它加速了K8s内核中那些为“通用性”而设计的能力的成熟。所以是的Kubernetes正在变成另一种系统。它正在从一个优秀的“容器编排系统”蜕变为一个更具野心的“通用工作负载调度与管理系统”。对于开发者而言这意味着我们需要更新对它的认知对于企业而言这代表了一个更具性价比和统一性的技术战略选项。这个过程不会一蹴而就中间会有复杂度提升的阵痛但方向已然清晰。我们能做的就是理解其背后的逻辑然后顺势而为利用这些新能力去解决更实际、更复杂的生产问题。毕竟最好的技术永远是那个能优雅地适应变化的技术。