Kubernetes 控制器与调度器源码解剖:从控制循环到自研调度框架
Kubernetes 控制器与调度器源码解剖:从控制循环到自研调度框架 Kubernetes 有两个"看起来不难、写起来全是坑"的地方:控制器的调谐循环,和调度器的插件框架。 前者难在并发——你面对的是一个最终一致的分布式缓存,写操作和缓存可见性之间有延迟,稍不留神就会重复创建 Pod;后者难在契约——十几个扩展点、几十个插件、三种队列状态,要理解"为什么这个 Pod 现在不能被调度"得同时看懂队列、缓存和抢占。 本文的读法是从基础设施往上层走:先看 client-go 那套事件流水线(Reflector → DeltaFIFO → Indexer → Workqueue),再用 Deployment 和 ReplicaSet 两个内置控制器把控制循环串起来;然后拆 kube-scheduler 的调度周期与框架契约;最后落到自研调度器 Sky-Scheduler——看它在 kube-scheduler 的框架之外,为什么选择了另一套 Session / Action / Statement 模型。 代码基线:Kubernetes v1....
containerd Snapshotter 接口深度解析:懒加载镜像方案的技术基石
containerd Snapshotter 接口深度解析:懒加载镜像方案的技术基石 在《容器镜像加速全景指南》中我们反复提到一个结论:Nydus / eStargz / SOCI 等懒加载方案之所以能在 containerd 生态落地,根本原因是 containerd 把"文件系统准备"抽象成了一个可插拔接口,并且这个接口的契约里留了一个"关键的后门"——它只要求返回有效的挂载配置,并不要求层数据已经下载到本地。 本文把这个抽象彻底拆开讲透。理解了它,你就理解了所有 remote snapshotter 方案的设计原理。 一、问题域:从 blob 到 rootfs 之间缺失的一环 先看 containerd 内部从 pull 到 run 的完整数据流: 1234567891011121314151617┌──────────────┐ pull ┌───────────────┐│ Registry │ ────────► │ Content Store │ ← 第一站:内容寻址 blob 存储│ (OCI 镜像)...
容器镜像加速全景指南:构建、缓存、懒加载与分发优化
容器镜像加速全景指南:构建、缓存、懒加载与分发优化 容器启动慢,76% 的时间花在"拉镜像"上,而拉下来的数据平均只有 6.4% 会被真正读到。这组来自 AWS 的测量数据,揭示了容器启动优化最核心的矛盾:我们在为"用不到的数据"付出高昂的时间成本。 这篇文章从底层概念讲起,沿着"构建期瘦身 → 本地缓存复用 → 按需懒加载 → 网络分发加速"的完整链路,系统拆解容器快速启动与镜像快速拉取的所有主流方案。 第一部分:先补齐底层概念——镜像到底是个什么东西 要理解所有加速方案,必须先理解容器镜像的物理本质。这一部分是后面所有内容的地基。 1.1 容器 = Namespace + Cgroups + Rootfs Linux 容器本质上并不神秘,它是三个内核机制的组合: Namespace(如 mount、pid、net、uts)给进程一个"隔离的视野"——容器内看到的文件系统、进程列表、网络栈都是独立的; Cgroups 限制进程能用的 CPU、内存等资源额度; Rootfs(根文件系统)则是容...
mmap 能映射什么:一张全景图
mmap 能映射什么:一张全景图 引言 mmap 本质上是一种**"把任意字节序列对象映射进进程虚拟地址空间"的通用机制**——它的作用域取决于 fd 指向什么。 fd 可以是普通文件、tmpfs 文件、字符设备、GPU 节点、VFIO 组,甚至完全不要 fd(MAP_ANONYMOUS)。内核为每次 mmap 创建一个 vm_area_struct(VMA),并绑定对应的文件操作表 f_op->mmap。 所以真正决定"能不能映射、映射出来是什么"的,从来不是 mmap 这个系统调用本身,而是 fd 背后的 file_operations 实现。 123456789mmap(addr, len, prot, flags, fd, offset) │ ├─ 无 fd ──────────────► 匿名内存(零页 + COW) └─ 有 fd │ ├─ 通用路径 do_mmap() → 新建 VMA └─ f_op->mmap(fil...
Agent 沙盒基础设施实践:从 DSec 与 AgentENV 看调度层的选型与落地
Agent 沙盒基础设施实践:从 DSec 与 AgentENV 看调度层的选型与落地 引言 随着 Agentic RL 训练规模的爆发,如何为成千上万个并行 Agent 提供隔离、可复用、可快速调度的沙盒执行环境,已经成为基础设施团队绕不开的课题。 团队调度侧近期的工作重心正是这个方向——目标是对齐 DeepSeek 的 DSec 论文(arXiv:2609.22978)所描述的"调度层支持 FnCall、Container、VM 等多级运行时应对异构工作负载"的能力。目前我们的路径是:镜像分发加速在做,运行时已经落成了一套四模板形态(见 §3.12),网络和内核隔离在规划中。 平台的形态是:控制面统一编排云上 GPU 训练集群与边缘侧的机器人、传感器、摄像头,从 RL/LLM 训练一路打通到边缘部署。边缘侧通过 Kubernetes Device Plugin 把机械臂、摄像头暴露成可调度资源(资源名形如 rlinf.io/device-franka),让训练任务里的仿真环境和真机环境能用同一套声明式抽象描述。 "具身"这个定语给沙盒基...
具身智能训练存储与数据管线:JuiceFS + Lance 深度实践
具身智能训练存储与数据管线:JuiceFS + Lance 深度实践 具身智能的存储问题,难点不在"存得下",而在"读得随机、写得突发、流得动"——一段双臂叠衣 episode 里藏着 3 路 30Hz 相机视频、100Hz 关节状态、未来 50 步的 action chunk,训练时 DataLoader 要从数万条 episode 里随机抽 timestep 并把这几路异频流对齐成同一行。 招商局狮岩 AI Lab 的实测给出了量化答案:用 Lance 把长视频切成 GOP 尺度 blob 后,随机读吞吐相对 LeRobot 提升 1.7–6×、存储降低 42%;而地瓜机器人的集群数据则验证了另一端:JuiceFS 多云 + 分布式缓存把训练任务启动从 20 分钟压到 3 分钟、缓存命中率从 45% 提到 92%。本文把这两套栈拼成具身训练的完整存储底座。 一、具身训练的 I/O 画像:与 LLM/CV 根本不是一回事 先明确负载形态,后面所有选型推理都从这里出发。 具身数据的最小单元是 episode,不是 token,也不是单张图...
Queue Quota 深度解析:从 Volcano 三级模型到 MiniMax 级 AI 集群的调度治理实践
Queue Quota 深度解析:从 Volcano 三级模型到 MiniMax 级 AI 集群的调度治理实践 Queue Quota 的本质一句话就能说清:它是队列级别的资源记账单元,声明"这个队列能用多少资源、必须保多少资源、最多借多少资源、愿意借出多少资源"——区别于 namespace 级的 ResourceQuota,它的作用域是队列而不是命名空间,并且支持跨队列的借用与回收。 而 MiniMax 这类大模型公司的实际做法,是基于 Volcano 二次开发批调度器,把 Quota 建模从单纯的 CPU/内存扩展到 GPU 卡数、卡型、NVLink 域、IB 域、CPU 沙盒等多个维度,队列树直接对齐业务组织结构,配合夜间潮汐复用把 ETTR(有效训练时间比例)做到 97% 这个业界最高档位。 以下分两个层面展开:先把 Queue Quota 的理论语义讲透,再切到一线调度器研发的真实工作。 一、Queue Quota 的完整语义 1.1 为什么不能只用 ResourceQuota 原生 Kubernetes 的 ResourceQuota 工作在 ...
AI Infra 全景复盘:GPU 性能、分布式训练与调度层深度解析
AI Infra 全景复盘:GPU 性能、分布式训练与调度层深度解析 本文以一次 AI Infra 岗位一面为线索,围绕 GPU 性能分析、分布式训练、RayJob 弹性伸缩、GPU 混部与调度可行性判断五大模块展开;再把面试中经常被追问的调度层作为独立章节补齐——抢占、队列、调度器框架、DRF、调度器与 Node 的解耦关系、多调度器冲突、backfill/preempt/reclaim 的跨队列语义,一次讲透。 核心观点先抛出来:Infra 面试考的不是名词背诵,而是"瓶颈定位 → 决策依据 → 工程权衡"这条完整链路的推理能力。调度层的所有机制,本质上都在"分布式一致性"和"资源效率"之间做权衡。 一、GPU 性能与分布式训练:Nsight 与并行策略 1.1 Nsight 是什么、怎么用 Nsight 是 NVIDIA 提供的 GPU 性能分析工具套件,其中最核心的是两把"不同倍率的放大镜": 工具 定位 分析粒度 典型命令 Nsight Systems (nsys) 全系统时间...
VPC 与 Cilium ClusterMesh:多集群组网的地基与上层建筑
VPC 与 Cilium ClusterMesh:多集群组网的地基与上层建筑 VPC 是公有云上通过逻辑隔离为你划出的一块"私有网段+自管路由"的虚拟网络,而 Cilium ClusterMesh 解决的是多个 Kubernetes 集群之间的 Pod IP 直连、跨集群服务发现、跨集群 NetworkPolicy 与负载均衡问题;跨集群通信通常通过 VPC Peering/专线打通底层网络后,由 Cilium ClusterMesh、Submariner 等方案组网;集群与机房并非一一对应,常见是"单机房多集群(隔离/灰度)""多机房单集群(同城双活)"和"多机房多集群(异地容灾)"三种模式按容灾等级选择;混合云场景下则建议用"专线 + VPN 主备链路 + 路由器统一打通 CIDR"的思路,把公有云 VPC 与私有化机房做成一张可路由的大内网。 先看两个概念在定位上的差异: 维度 VPC Cilium ClusterMesh 层级 IaaS 层的逻辑网络 Kube...
Anchor 论文精读:解耦 GPU 内存所有权,让"浅层中断"不再付出全量恢复的代价
Anchor 论文精读:解耦 GPU 内存所有权,让"浅层中断"不再付出全量恢复的代价 论文:Anchor: Mitigating GPU Shallow Disruptions with Decoupled Memory 作者:Haoyi Ma、Shiwei Gao、Youmin Chen、Junrong Huang、Youyou Lu、Jiwu Shu(清华大学 & 上海交通大学) 发表:SOSP '26(ACM SIGOPS 第 32 届操作系统原理研讨会) TL;DR 大规模 LLM 集群中的绝大多数故障其实是"浅层中断"——进程崩了,但 GPU 硬件和 OS 内核毫发无损。现有恢复机制对此一视同仁:checkpoint → 重启 → 全量重载,哪怕数据本来就还完好在显存里。 Anchor 的核心主张是:内存所有权不应与进程生命周期绑定。它用一个 daemon 进程持有 GPU 内存,worker 通过 GPU IPC 机制零开销地映射访问;worker 崩溃后,新 worker 直接把同一块物理显存重新映射回来,数据从...