一个集群,多个调度器:Kubernetes 多调度器共存实践指南
一个集群,多个调度器:Kubernetes 多调度器共存实践指南 “我们集群里已经有 kube-scheduler 了,还能再装一个 Volcano 吗?会不会打架?”——这是 AI Infra 团队在做调度器选型时最常被问到的第一个问题。答案是:可以,而且这正是 Kubernetes 的设计初衷之一。但"装上就能用"和"用对"之间,隔着一整篇本文要讲的内容。 一、为什么这个问题重要 大模型时代的集群里,工作负载的分裂前所未有:在线服务要打散、要低延迟;训练任务要 Gang 调度、要拓扑聚拢;推理服务要 SLO 感知、要弹性伸缩。没有任何一个调度器能同时把这些语义做到极致,于是"多调度器共存"从边缘玩法变成了生产标配——华为云 CCE 的"kube-scheduler 管在线 + Volcano 管训练"双轨架构就是典型代表。 Kubernetes 从设计之初就考虑了这个需求:每个 Pod 通过 schedulerName 字段指定由谁来调度,各调度器通过 watch API Server 只处理与...
Kafka 设计原理全览:从分布式日志到高吞吐高可用
Kafka 设计原理全览:从分布式日志到高可用 引言 Kafka 最初由 LinkedIn 开发,后捐给 Apache 基金会,如今已是流式数据事实标准。它能在一台普通服务器上跑到 10 万级消息/秒的吞吐,同时保证消息的持久化与高可用——这背后不是玄学,而是一套围绕"分布式日志"的精巧设计。 本文以"分布式日志"为内核,系统梳理 Kafka 的架构与核心原理,目标是读完一篇就建立完整的心智模型。参考了腾讯云开发者社区《Kafka 设计原理全览》及若干资料,综合整理。 一、Kafka 是什么:不止是消息队列 Kafka 是一个分布式流处理平台,有三重身份: 消息系统:生产者发消息、消费者收消息,提供解耦、削峰、异步、系统恢复等能力,还支持顺序保证和回溯消费。 存储系统:消息以日志形式持久化到磁盘,配合多副本实现高可靠的冗余存储。 流处理平台:提供完整的流处理类库(Kafka Streams),可在消息之上做转换、聚合、连接。 为什么用它做消息队列?核心价值:解耦(上下游不直接耦合)、削峰(峰值流量暂存管道、下游按自己速度消费)、可扩展...
Kubernetes 跨调度器抢占:机制、冲突根因与选型实践
Kubernetes 跨调度器抢占:机制、冲突根因与选型实践 Kubernetes 的 kube-scheduler 原生支持"基于优先级的抢占",由调度框架的 PostFilter 扩展点和 DefaultPreemption 插件实现;但"跨调度器抢占"在社区中并没有统一标准——每个调度器只能基于全局(且往往是滞后的)资源视图独立决策,互相感知不到对方的优先级语义和绑定动作,多调度器并存时会出现决策冲突、重复抢占甚至资源超卖的问题。下面从机制、冲突根因、调度器对比和典型实例四个层面展开。 一、kube-scheduler 原生抢占机制回顾 调度框架把每个 Pod 的调度过程分为 scheduling cycle 和 binding cycle,而抢占发生在 Filter 失败之后的 PostFilter 扩展点。DefaultPreemption 插件的核心目标是:为一台节点找到一组"最优受害者 Pod",它们被删除后能腾出足够资源让高优先级的抢占者调度成功,同时尽量不违反 PDB、优先级尽量低、造成的 Pod c...
Sky-Scheduler:面向 AI 训练的拓扑感知与 Quota 两级调度器
Sky-Scheduler:面向 AI 训练的拓扑感知与 Quota 两级调度器 把一个千卡训练任务调度好,比把一百个 Web 服务调度好难得多。难点不在"算力够不够",而在三件 Web 服务从不操心的事: 通信拓扑要聚拢:TP/PP 切出来的通信组,必须落在同一片 RDMA 交换机域里,跨机架一跳,AllReduce 延迟能差好几倍。 资源要"留得住":训练任务动辄跑几小时几天,中途被别的任务抢占、重启就要从头来;但集群又要混部在线/离线,不能不让抢。 同卡型才好比:A100 节点和 H100 节点不能混进同一个通信组,不然快的等慢的,贵的卡当便宜的用。 通用调度器(kube-scheduler)对这三件事基本无解,Volcano 解决了 Gang 但也没碰拓扑。Sky-Scheduler 就是冲着这三件事来的——一个 Volcano 衍生的 Kubernetes 调度器,在 Volcano 的 session 框架上做了几处关键改造:把"Pod→Node 一跳"改成 “Task→Quota→Node 两跳”,引入...
Volcano Queue 全流程拆解:一个 Job 从提交到运行
Volcano Queue 全流程拆解:一个 Job 从提交到运行 本文是 一个集群,多个调度器:Kubernetes 多调度器共存实践指南 的下篇——上一篇讲了多调度器并存,本文深入 Volcano 内部,回答一个更具体的问题:Queue 在整个调度流程中到底扮演什么角色?我用一个"两个队列、三个 Job"的资源博弈场景,把从 YAML 提交到 Pod 运行的每一步拆开看——包括 YAML 怎么写、每个字段如何影响调度决策、队列之间如何"借用"与"回收"资源。 引言:为什么需要理解 Queue 的完整流程 Volcano 的 Queue 是多租户资源分配的最上层抽象——它不参与"Pod 放哪个节点"的决策,而是先决定"这个任务有没有资格、以什么优先级、能用多少资源进入调度"。 如果没有 Queue,调度器只有"先来后到"一种公平观:谁先提交谁先用,大任务可能饿死小任务,一个团队的突发负载可以吃光整个集群。Queue 补上了配额隔离、弹性借用、公平分配三块...
Kthena 源码解析：云原生 LLM 推理平台的架构与实现
Kthena 源码解析：云原生 LLM 推理平台的架构与实现 项目地址：https://github.com/volcano-sh/kthena ｜ 官网：https://kthena.volcano.sh 本文基于 kthena 仓库 main 分支源码进行系统分析，覆盖整体架构、控制面 CRD 与控制器、数据面路由与调度器、PD 分离、弹性扩缩容与运行时 Agent 等核心模块。 一、Kthena 是什么 Kthena 是 Volcano 社区推出的 Kubernetes 原生 LLM 推理平台，目标是把大模型推理这件事在 K8s 上变得简单、可扩展、低成本。它不替代 vLLM / SGLang 这类推理引擎，而是作为推理引擎之上的「流量枢纽 + 调度中心」，用声明式 CRD 管理模型全生命周期，用智能路由分发推理流量。 定位上有三个关键词值得记住： Lightweight（轻量）：整个平台就是两个自包含的 Go 二进制，依赖面小，安装便宜、升级简单。 Modular（可组合）：控制面（workload）和数据面（networking）是两个独立的 Helm 子 cha...
推理调度器(Inference Scheduler)调研报告
推理调度器(Inference Scheduler)调研报告 当前主流推理调度方案可分为三层:引擎层调度(vLLM continuous batching、TensorRT-LLM in-flight batching)、集群层调度(Kthena、AIBrix、llm-d、KServe 等 K8s 原生方案)、路由层调度(KV Cache/Prefix 感知的请求级路由),而云厂商普遍采取"引擎层优化 + 集群层自研 + 路由层智能化"的组合策略。推理调度的核心矛盾已从训练场景的"资源凑齐"(Gang 调度)转向推理场景的"延迟-吞吐-SLO-成本四方权衡",KV Cache 感知路由和 PD 分离(Prefill-Decode disaggregation)成为当前最活跃的技术竞争点。 一、推理调度与训练调度的本质差异 训练调度的核心是资源分配问题:用 Gang 调度保证分布式作业的所有 Worker 同时启动,用拓扑感知减少通信开销,调度粒度是"作业级",一次决策影响整个训练过程。 推理调度的核...
从 KServe 到 Kthena:云原生模型服务平台的技术演进
从 KServe 到 Kthena:云原生模型服务平台的技术演进 在 Kubernetes 上部署一个模型服务,为什么需要专门的平台?本文从 Serverless 的本质出发,深入拆解 KServe 的拓扑架构与技术细节,并对比 2026 年新晋的 LLM 推理专用平台 Kthena,梳理云原生推理领域的技术选型思路。 一、为什么需要模型服务平台 在 KServe 出现之前,在 Kubernetes 上部署一个推理服务,意味着手动拼装 Deployment、Service、HPA、Ingress、ConfigMap 等一堆资源。而模型服务还有其独特的痛点: 框架异构:PyTorch、TensorFlow、XGBoost、ONNX、vLLM、TGI……每个引擎的部署方式各不相同; 成本压力:GPU 极其昂贵,闲置时的空转是巨大的浪费; 运维复杂:版本灰度、流量切分、可解释性、日志审计,每一项都需要额外的工程投入。 KServe(前身是 Kubeflow 下的 KFServing,2022 年独立,2025 年 9 月进入 CNCF 孵化)给出的答案是:用一个 Inferenc...
DPDK 实战：从一个开源示例项目拆解用户态包处理的全流程
上一篇《高性能网络包处理三板斧：XDP、DPDK 与 AF_XDP》讲的是「三条 kernel bypass 路径怎么选」。这篇落到代码：拿一个真实的 DPDK 开源示例项目 The-DPDK-Examples，把概念、封装层、收发包主循环、三个数据面示例、LRU 实现和哈希基准测试一次性拆透。 但在拆代码之前，得先把 DPDK 里那一堆名词讲清楚——否则代码里每一行都看不懂。所以本文前半部分用拓扑图把概念讲透，后半部分逐文件拆代码。如果你已经熟悉 DPDK，可以直接跳到第五节。 一、为什么需要「内核旁路」 先建立基准：标准 Linux 收一个网络包，要走的路是这样的： 123456789101112131415161718192021222324┌─────────────────────────────────────────────────────────────────┐│ 传统内核网络栈 ││ ...
剖析 infini-agent-framework 的双层中间件:原理、实现与自定义
剖析 infini-agent-framework 的双层中间件:原理、实现与自定义 引言 在构建一个 Agent 应用时,我们几乎一定会遇到这样的需求:在每次 LLM 调用前后打日志、压缩过长的对话历史、给工具调用加一层错误兜底、给 HTTP 请求注入上下文、采集 Prometheus 指标……这些需求有一个共同特征——它们不是业务本身,而是横切在业务调用链路上的通用能力。把它们硬塞进业务代码会让系统迅速腐化,于是"中间件(Middleware)"这种模式应运而生。 infini-agent-framework(以下简称框架)作为一个基于 LangGraph + FastAPI 的 Python Agent 框架,在中间件的设计上做了一个值得细看的选择:它没有另起炉灶造一套自研中间件类型,而是直接复用了 Starlette 与 LangChain 两套成熟的中间件抽象,并在此基础上做了组合与编排。这导致框架内存在两套独立、互不共享类型的中间件系统: 层级 基类来源 作用范围 文件位置 HTTP 中间件 Starlette BaseHTTPMid...