Kubernetes

一句话定位

Kubernetes 是容器与集群编排平台，负责 Pod 在节点上的落点、资源申请、重启、网络、服务发现、扩缩容和隔离。

它负责

CPU/GPU/内存等粗粒度资源分配
container lifecycle 与健康检查
service discovery、网络和存储挂载
deployment、autoscaling 与多租户隔离

它不负责

不定义模型并行算法
不执行 PyTorch forward/backward
不管理 vLLM 内部 KV block
不直接决定 Agentic RL 的 reward 或 policy update

从资源到线上服务

Deployment/Job
→ Pod 请求 GPU/CPU/内存
→ scheduler 选择节点
→ container 启动模型与 runtime
→ Service/Ingress 暴露流量
→ probes、metrics、autoscaling 与滚动更新

Kubernetes 只能保证资源和进程生命周期，不能保证模型已经加载、KV 没有抖动或 p99 满足目标；readiness 应反映真正可服务状态，扩缩容指标也要接近队列/并发/显存，而不只是 CPU。集群问题与 vLLM 内部调度要分层定位。

与 Ray 的边界

Kubernetes 调度 Pod/容器到节点；Ray 在已获得的资源内调度 Python task、actor 和 worker。Volcano 等工具可为 K8s 增加 batch/gang scheduling 能力。

GPU 服务的真实就绪条件

一个模型服务的容器启动成功，只代表进程存在，不代表请求可以被安全接收。模型权重可能仍在下载或加载，CUDA graph 可能未捕获，tokenizer/量化配置可能与权重不匹配，KV allocator 也可能尚未预留足够空间。因此 readiness 应逐层变严：进程存活、模型加载完成、一次短的 warmup 请求成功、依赖的 tokenizer/路由可用，最后才把 Pod 放进流量池。liveness 只负责判断是否需要重启，不能把短暂的模型加载延迟误判为死进程。

扩缩容指标为何容易选错

CPU 利用率在 GPU 推理服务上可能长期很低，而 GPU 利用率 90% 也可能是请求排队、KV 快满或单个长请求占住 batch。更接近用户 SLO 的信号是 admission queue、running sequences、KV 使用率、TTFT/TPOT 的分位数和 OOM/拒绝率。扩容还必须计入新 Pod 下载权重、初始化 kernel 和 warmup 的冷启动时间；如果冷启动长于流量峰值，简单 HPA 可能在峰值结束后才拉起副本。

traffic surge
→ queue / KV pressure rises
→ autoscaler requests Pod
→ scheduler finds GPU node
→ image + weights + runtime warm up
→ readiness passes
→ router admits traffic

每一步都应有耗时和失败原因。否则“扩容成功”可能只是 Pod 数增加，真正可服务容量没有变化。

故障分层实验

分别注入节点失联、容器进程崩溃、模型加载失败、readiness 失败和 vLLM 内部 OOM，观察 Deployment、Service、router 与引擎的响应。预期边界是：Kubernetes 恢复 Pod/节点级期望状态，服务层摘除不健康副本，推理引擎负责请求和 KV 的内部失败；若 Pod 被重启后没有恢复 checkpoint、缓存或权重版本，那是应用恢复契约缺失，不是 Kubernetes 已经解决的问题。