从容器编排到 AI 原生的进化#

我记得 2020 年刚开始接触 Kubernetes 的时候，大家讨论最多的话题是怎么把微服务跑稳、怎么配置网关才能让流量不丢、怎么用包管理工具管理应用依赖。谁能想到六年后的 2026 年最热门的话题已经变成了怎么在 K8s 上跑大模型训练、GPU 调度怎么做才能不让昂贵的 H100 闲置、推理服务的自动扩缩容阈值应该设多少。这不是段子这是正在发生的现实。KubeCon 2026 印度大会的主题演讲里超过一半的议题都跟 AI 和机器学习基础设施相关。Kubernetes 已经从纯粹的容器编排工具华丽转身变成了 AI 原生基础设施平台。今天咱们就好好聊聊这个转变是怎么发生的以及作为开发者该怎么上车。

根据 CNCF 2025 年度的官方调查报告，Kubernetes 管理的基础设施中已经有超过百分之四十的工作负载是 AI 和机器学习相关的。这个数据来自 CNCF 官方发布而且比例还在持续增长。更具体地说现在的 Kubernetes 集群中除了传统的 Web 服务和微服务之外还跑着大量的模型训练任务、推理服务部署、数据预处理管道和特征存储系统。AI 工作负载已经从实验性的小规模试点变成了生产级的大规模部署。这意味着所有使用 K8s 的团队都需要掌握 AI 工作负载的部署和管理技能。

问题来了：传统的 K8s 调度器是为 CPU 密集型微服务设计的，它知道怎么管理 CPU 核数和内存大小但它完全不懂 GPU 是什么东西。一张 H100 GPU 在 2026 年依然要三万美元以上，调度不好就是巨大的资源浪费。在 2026 年 K8s 的 GPU 调度已经变得非常精细化了。以前只能说给我四张卡，现在可以指定每张卡的算力百分比、显存带宽分配和分区方式等细粒度参数。就像以前去餐馆只能点一个固定套餐现在可以自助搭配了。你可以指定某张卡一半的算力用来做推理另一半用来做训练，或者给不同的容器分配不同的显存带宽，资源利用率大幅提升。下面这个配置展示了这种新的 GPU 调度方式。

1
apiVersion: v1
2
kind: Pod
3
metadata:
4
  name: training-job
5
  annotations:
6
    nvidia.com/gpu-parts: "1:2"
7
    nvidia.com/gpu-memory: "40960"
8
    scheduler.alpha.kubernetes.io/ai-profile: "training"
9
spec:
10
  containers:
11
  - name: trainer
12
    image: nvidia/pytorch:25.05-py3
13
    resources:
14
      requests:
15
        nvidia.com/gpu: 4
16
        nvidia.com/gpu-compute: "95"
17
        nvidia.com/gpu-memory-bandwidth: "2000"
18
      limits:
19
        nvidia.com/gpu: 4

推理服务部署的实战指南#

训练大模型只是一部分工作，更常见也更贴近我们普通开发者的场景是模型推理服务的部署。你把训练好的模型部署到线上面对大量用户请求，需要负载均衡、自动扩缩容、健康检查、零停机更新等一系列操作。这些正是 Kubernetes 最擅长的事情。我推荐用 vLLM 作为推理引擎，它是目前最稳定也最高效的开源方案之一。vLLM 支持连续批处理和分页注意力机制，推理吞吐量比传统的方案高出好几倍。

但在部署过程中有几个非常容易踩的坑。第一个坑是模型加载时间。很多人第一次部署推理服务时会把健康检查的初始延迟设得太短。像 Qwen3.6-35B 这种三百五十亿参数级别的模型，加载到 GPU 显存至少需要六十到九十秒，如果是从远程仓库拉取模型文件时间更长。如果你只给了十秒的延迟，Kubernetes 会认为容器不健康然后不断重启它，形成启动再被杀再启动再被杀的死循环。这个坑我在生产环境踩过不止一次，被同事嘲笑过好几回。后来我把初始延迟设为一百二十秒才彻底解决这个问题。

第二个坑是自动扩缩容的配置。传统基于 CPU 利用率的扩缩容策略完全不适用于推理服务，因为推理的瓶颈完全在 GPU 上。应该用 GPU 利用率作为扩缩容指标，阈值根据业务来调整。如果你们的用户对响应延迟非常敏感可以把阈值设低到百分之五十保留更多的冗余算力应对突发流量；如果你们更在乎 GPU 资源的使用效率不想浪费可以把阈值设高到百分之八十五让 GPU 跑得更满。还有一个容易被忽略的问题是缩容抖动，流量的一时波动会导致频繁创建和销毁容器，必须设置稳定窗口时间来避免这种抖动。

Docker 国内镜像的现状#

最后说说 Docker 镜像的问题。2026 年 Docker Hub 在国内的访问依然受到一些限制但好消息是五月份的最新实测显示还有几个国内镜像源可用。配置方法很简单编辑 Docker 的配置文件添加镜像源地址然后重启 Docker 服务就可以了。我目前在用的有 docker.139.red、docker.m.daocloud.io 和 docker.nju.edu.cn 这几个，拉取 pytorch 这样的大镜像基本能跑满带宽。不过 2026 年的趋势是用 containerd 替代 dockerd，很多新建的 Kubernetes 集群已经不再依赖 Docker 了而是使用 containerd 加 nerdctl 的组合，性能更好镜像拉取也更快。很多企业还通过 Harbor 搭建内部镜像仓库，既解决了网络问题也提高了安全性。还在用 Docker Desktop 的朋友建议试试用 colima 或 rancher-desktop 来替代，它们在 2026 年已经有非常成熟的生态了。

总结#

2026 年 K8s 最重要的三个趋势：第一是 AI 原生化，GPU 调度和推理部署已成为核心能力，这是所有 K8s 开发者都需要掌握的技能。第二是平台工程的兴起，内部开发者平台把 K8s 的复杂性封装起来让开发者只需要关心业务代码。第三是边缘计算场景下轻量级 K8s 发行版的快速普及。别再以为 K8s 只是容器编排了，在 2026 年它是 AI 的基础设施操作系统。掌握 这些就是我在生产环境中运行 K8s AI 工作负载时积累的全部经验，希望对正在搭建或运维 AI 基础设施的朋友有帮助。其实还有一个趋势值得单独拿出来说，那就是 Kubernetes 对多架构的支持。2026 年 ARM 架构的服务器在云原生领域的占比越来越高，AWS 的 Graviton、华为的鲲鹏和 Ampere 的 Altra 处理器在性价比上对 x86 形成了很大的竞争压力。很多 AI 推理场景其实并不需要 x86 的复杂指令集，ARM 处理器的能效比更高。K8s 在 2026 年已经原生支持了多架构集群的混合调度，同一集群中可以同时运行 x86 和 ARM 节点。你可以把训练任务调度到 x86 GPU 节点上执行，把推理服务部署到 ARM CPU 节点上来降低成本。这种混合架构的多集群管理正在成为大型 AI 平台的标准配置。使用 K8s 的节点亲和性和污点容忍度可以非常灵活地控制工作负载的调度目标，这也是所有 K8s 运维人员需要掌握的高级调度技巧。下期我们来手把手搭建一个生产级的 K8s 推理集群，从 GPU 节点配置到模型部署到压测调优，全流程实战干货敬请期待。

在实际的 Kubernetes 运维中还有很多细节值得注意。首先是集群的监控和日志收集。当你开始运行 AI 工作负载后传统的监控指标可能不够用了，你需要关注 GPU 利用率、显存占用、GPU 温度、NVLink 带宽这些新的指标。推荐使用 DCGM Exporter 来采集 GPU 指标配合 Grafana 做可视化。其次是网络配置的问题。多节点训练任务需要高速网络互联，建议使用 RDMA 和 InfiniBand 来减少通信延迟。如果你的集群不具备这些硬件条件，也可以使用 Kubernetes 的拓扑感知调度功能把训练任务尽量调度到同一个节点或者同一个机架内来减少跨节点通信。第三是存储的选择。模型文件通常很大而且需要快速加载，建议使用 NVMe 本地盘或者高性能分布式文件系统来做模型存储。不要把模型文件放在普通的网络存储上因为加载速度太慢会严重影响推理服务的启动时间。这些经验都是我在生产环境中一步步摸索出来的，希望对大家有帮助。另外还想提醒一个容易被忽视的点就是安全问题。在 K8s 上运行 AI 工作负载时要注意容器镜像的安全扫描，因为很多 AI 相关的镜像来自社区可能包含安全漏洞。建议在 CI 流程中加入镜像安全扫描步骤，使用 Trivy 或 Grype 这类工具定期扫描镜像仓库中的镜像。还有一点是网络策略的配置，推理服务通常需要对外暴露 API 接口但训练任务不需要。建议使用 Kubernetes 的网络策略功能限制训练任务的网络访问权限，只允许它们访问必要的存储和集群内部服务，不要暴露到公网。这样即使某个训练容器被攻破攻击者也无法通过网络访问你的其他服务。GPU 节点的安全也需要特别关注，因为这些节点通常有很高价值的硬件资源。建议对 GPU 节点启用节点级别的安全加固，比如使用容器优化操作系统、禁用不必要的系统服务、开启审计日志等。多花一些精力在安全方面绝对值得，因为一次安全事件的损失可能远远超过你花在安全防护上的时间和成本。最后再补充一个关于成本优化的建议。在 K8s 上运行 AI 工作负载的成本主要来自三块：GPU 资源的租赁费用、存储费用和网络流量费用。GPU 费用占比最大，优化 GPU 利用率是降低成本的关键。除了前面提到的自动扩缩容之外还可以考虑使用抢占式实例来运行训练任务，因为训练任务通常可以中断后恢复，用抢占式实例可以节省百分之六十以上的 GPU 成本。另外建议对不同的工作负载设置不同的资源优先级，推理服务使用按需实例保证稳定性，训练任务和批处理任务使用抢占式实例降低成本。存储方面模型文件建议使用对象存储而不是块存储，因为对象存储的成本更低而且支持直接通过 HTTP 访问。网络方面尽量把推理服务和用户部署在同一个区域来减少跨区域的网络流量费用。这些细节加起来每月的成本差异可能是数万元，值得花时间去优化。还有一个容易被忽略的点是资源标签管理。在大型 K8s 集群中同时运行着多个团队的训练任务和推理服务，如果没有合理的资源标签和成本分摊机制，月底看到账单的时候根本不知道哪个团队花了多少钱。建议在部署 AI 工作负载时强制要求带上团队标签、项目标签和环境标签，配合 Kubecost 或者开源工具 OpenCost 来做成本可视化和分摊。这样做不仅能让每个团队清楚自己的资源消耗，还能激励大家主动优化自己的资源使用效率。

K8s 加 AI 工作负载的部署和管理能力，已经成为 2026 年云原生工程师的必备技能。