容器编排（Kubernetes）

Kubernetes 是容器编排系统，把一批机器抽象成统一的计算资源池：应用打包成容器镜像后交给它调度，它负责选择节点、拉起进程、探活并在崩溃时重启，还能按负载自动扩缩容。对 AI 服务来说，它是把模型从「能跑」变成「稳定对外提供」的关键一层。它和单纯的容器运行时也有区别：容器运行时只负责在一台机器上把进程跑起来，编排系统解决的是跨机器调度、副本数量与故障恢复，以及服务发现、配置分发这些运行期问题。

AI 场景里它管什么

• 推理服务编排：按 GPU 资源申请调度副本，配合就绪与存活探针、滚动升级，把新版本逐步替换上线，出问题时也能快速回滚。
• 弹性扩缩容：按请求量、队列长度或显存占用调整副本数，空闲时缩容，避免为偶尔出现的峰值长期付钱。
• 训练任务管理：批量任务与分布式训练的排队、调度、失败重试与优先级抢占，都要靠它统一安排。
• 资源隔离：用命名空间与配额把不同团队、不同环境分开，并限制单个任务的资源上限，防止互相挤占。

关键机制

它的核心是一个期望状态循环：用户提交声明式的目标状态，控制器不断比对实际状态并做出调整，节点掉线时把副本重新调度到健康节点上。调度器按资源请求、亲和性与污点等条件给节点打分；探针则决定一个实例是否算健康，探针设置不当会让扩容出来的副本在模型还没加载完时就被判失败，陷入反复重启。这也是它的使用要点——声明目标而不是描述步骤，把「怎么恢复」交给控制器，代价是排查问题时要多看一层抽象。

落地时的现实问题

• GPU 分配粒度：默认按整卡申请，容易产生碎片与浪费，常配合显存切分或共享调度提升利用率。
• 冷启动与镜像体积：镜像大、模型加载慢会拖长扩容时间，通常把权重缓存到节点本地或挂载共享存储。
• 批调度与排队：默认调度器逐个分配资源，分布式训练容易出现整组任务互相等待，需要成组调度能力。
• 可观测性：指标、日志与链路追踪要按副本维度采集，否则定位一次超时要翻好几层，排查效率很低。

它适合需要长期在线、副本多、迭代频繁的服务；如果只是单机跑一个脚本或做一次性实验，直接起进程或用一个简单的调度脚本成本更低。引入它的代价是学习曲线与运维复杂度：集群本身也需要专人维护，版本升级、证书轮换与网络插件都可能是新的故障来源。选择托管服务可以省掉一部分维护工作，但代价是可控性下降，出问题时能看到的细节更少。