开放社区正在把 Kubernetes 变成 AI 的通用运行底座

AI 基础设施正在从少数团队维护的专用平台，转向由开放社区共同定义的通用运行环境。CNCF 2025 年度云原生调查显示，82% 的容器用户已经在生产环境运行 Kubernetes；在托管生成式 AI 的组织中，66% 使用 Kubernetes。对工程团队而言，这意味着模型服务、GPU 调度、扩缩容和可观测性正逐渐进入同一套云原生控制面。

Kubernetes 为什么适合承载 AI

把 Kubernetes 称为 AI 的“操作系统”，关键不在于它直接训练或推理模型，而在于它统一管理 AI 工作负载依赖的计算资源和生命周期。

训练任务通常需要 GPU、持久化存储、失败重试和批处理调度；推理服务则关注稳定发布、弹性扩缩容、健康检查和流量治理。Kubernetes 提供声明式 API，让团队用相同的资源模型描述这些需求，并通过控制器持续校正实际状态。

这套机制还能降低基础设施之间的迁移成本。工作负载可以在本地集群、公有云或混合环境中采用相近的部署方式。不过，可移植性并非自动成立：GPU 型号、驱动、存储类和云厂商负载均衡器仍然可能形成环境绑定，团队需要主动隔离这些差异。

“社区驱动”不只是开放源代码

开放 AI 基础设施的价值，不只是能够查看代码。更重要的是，用户、供应商和维护者可以围绕公共接口协作，把模型服务、调度、存储、网络和观测组件接入同一个生态。

这种协作方式带来三个直接影响：

• 接口比单一产品更长寿：团队可以围绕 Kubernetes API、容器镜像和标准指标构建内部能力。
• 组件可以替换：推理引擎、监控系统或存储实现能够按需求调整，不必整体推倒平台。
• 问题由真实生产场景推动：大规模调度、多租户隔离和异构硬件管理会进入社区讨论，而不是停留在某家厂商的封闭路线图中。

开放并不等于没有成本。版本兼容、组件选型、安全修复和升级测试都需要明确负责人。组件越多，平台团队承担的集成工作也越重。

可以这样实践：部署一个 GPU 推理服务

下面是一个可改造的最小示例。它创建一个 Deployment 和一个集群内 Service，并声明使用一块 NVIDIA GPU。运行前需要准备可用的 Kubernetes 集群、GPU 节点以及对应的 NVIDIA device plugin；还要把 YOUR_REGISTRY/model-server:1.0 替换成实际镜像。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: model-server
spec:
  replicas: 1
  selector:
    matchLabels:
      app: model-server
  template:
    metadata:
      labels:
        app: model-server
    spec:
      containers:
        - name: server
          image: YOUR_REGISTRY/model-server:1.0
          ports:
            - name: http
              containerPort: 8000
          resources:
            requests:
              cpu: "2"
              memory: 8Gi
              nvidia.com/gpu: "1"
            limits:
              cpu: "4"
              memory: 16Gi
              nvidia.com/gpu: "1"
          readinessProbe:
            httpGet:
              path: /health
              port: http
            initialDelaySeconds: 10
            periodSeconds: 5
          livenessProbe:
            httpGet:
              path: /health
              port: http
            initialDelaySeconds: 30
            periodSeconds: 10
---
apiVersion: v1
kind: Service
metadata:
  name: model-server
spec:
  selector:
    app: model-server
  ports:
    - name: http
      port: 80
      targetPort: http

将内容保存为 model-server.yaml 后，可以执行：

kubectl apply -f model-server.yaml
kubectl rollout status deployment/model-server
kubectl get pods -l app=model-server -o wide
kubectl port-forward service/model-server 8080:80

随后在另一个终端验证服务。以下请求假设镜像提供 /health 和 /v1/generate 接口，实际路径及请求体需要按所用推理服务器修改：

curl --fail http://127.0.0.1:8080/health

curl http://127.0.0.1:8080/v1/generate \
  -H 'Content-Type: application/json' \
  -d '{"prompt":"Explain Kubernetes in one sentence.","max_tokens":64}'

这个示例只解决基本部署问题。进入生产环境前，还应补充模型权重挂载、鉴权、网络策略、Pod 中断预算、指标采集和请求超时。对于昂贵的 GPU 服务，也不要仅按 CPU 使用率扩容；队列长度、并发请求数、首 token 延迟和显存占用通常更有参考价值。

采用时先守住边界

团队不必为了追随趋势一次性搭建庞大的 AI 平台。更稳妥的方式，是从一个可观测、可回滚的推理服务开始，验证 Kubernetes 是否真正解决了资源调度和交付问题。

落地前可以检查以下事项：

• GPU 驱动、device plugin、Kubernetes 版本和推理镜像是否形成经过测试的兼容矩阵。
• 模型权重、提示词日志和用户数据是否有清晰的访问控制与保留策略。
• 是否记录吞吐量、延迟、错误率、队列深度以及单次请求成本。
• 开源组件是否有持续维护者、升级路径和安全响应机制。
• 平台抽象是否保留原生 Kubernetes 资源的可诊断性，避免故障时只能面对黑盒。

Kubernetes 的普及说明，AI 基础设施正在汇入成熟的云原生工程体系。真正可持续的方向，不是把所有能力锁进一个封闭平台，而是围绕公共接口、可替换组件和社区协作建立生产能力。同时，开放生态只有配合严格的版本治理、安全管理和运维责任，才能从“可选择”变成“可依赖”。