14.1. Serverless 与 AI/数据栈：Knative、KServe、Ray 与 vLLM

Serverless 把「缩到零、按事件触发」带进 Kubernetes；AI/数据栈把「GPU、模型、批处理、工作流」带进来。两者的共同点是：不能直接套用无状态 Web 服务的副本数与 HPA 策略。

层级:: L4 · 实战
难度:: 进阶
预计:: 50 分钟
前置:: Deployment、HPA、GPU/存储基础

14.1.1. Serverless：Knative 与事件驱动

组件	作用
Knative Serving	请求驱动、缩到零、版本与流量拆分
Knative Eventing	事件源、Broker/Trigger、CloudEvents
Dapr	服务调用、状态、发布订阅、绑定
Argo Events	事件源到工作流的触发
NATS	轻量消息与事件总线

knative-service.yaml

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: demoapp
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/minScale: "0"
        autoscaling.knative.dev/maxScale: "10"
    spec:
      containers:
        - image: ghcr.io/example/demoapp:v1.0
          ports:
            - containerPort: 8080

kn service create demoapp --image ghcr.io/example/demoapp:v1.0 --scale-min 0
kn service list
curl http://demoapp.default.example.com

缩到零适合低频、可容忍冷启动的流量；在线核心 API 不建议 minScale=0。

14.1.2. AI/模型服务

项目	定位
Kubeflow	训练/管道/Notebook 的平台套件
KServe	模型推理服务、多框架、自动伸缩
Ray	分布式计算/训练/推理
vLLM	高吞吐 LLM 推理引擎
NVIDIA Device Plugin	GPU 资源调度
MIG	GPU 切分与隔离

kserve-inferenceservice.yaml

apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
  name: sklearn-demo
spec:
  predictor:
    model:
      modelFormat:
        name: sklearn
      storageUri: s3://models/sklearn-demo
      resources:
        requests:
          cpu: "1"
          memory: 2Gi
        limits:
          cpu: "2"
          memory: 4Gi

GPU 推理要显式申请 nvidia.com/gpu，并用节点亲和/污点把 GPU 节点隔离；否则普通 Pod 会占满 GPU 节点或 GPU Pod 被调度到无 GPU 节点。

14.1.3. 数据与工作流

Spark on K8s：用 Spark Operator 提交批任务，注意 executor 的 resources 与动态分配。
Airflow：DAG 编排，KubernetesExecutor 可按任务起 Pod。
JupyterHub：多用户 Notebook，需隔离命名空间与资源配额。
Temporal：长时间运行的工作流与重试，适合异步业务。

AI/数据任务通常有「排队、gang scheduling、GPU、数据本地性」需求，优先用 Volcano/Kueue 或独立节点池，不要和在线服务抢同一套 HPA。

14.1.4. 实验：Knative 缩到零与恢复

kubectl apply -f knative-service.yaml
kubectl get ksvc demoapp
curl -H 'Host: demoapp.default.example.com' http://<kourier-ip>/
kubectl get pods -l serving.knative.dev/service=demoapp

等待几分钟无请求，观察 Pod 缩到 0；再次请求，观察冷启动时间。把 minScale 改成 1，对比延迟与资源占用。

14.1.5. 验证清单

Knative/KServe 控制器健康，CRD 已安装。
服务能从 0 扩容并处理请求，冷启动时间可接受。
GPU Pod 能调度到 GPU 节点，普通 Pod 不会占用 GPU。
模型/数据存储（S3/PVC）可读，推理服务能加载模型。
批任务与在线服务通过节点池/优先级隔离。
有队列/配额，避免训练任务打满集群。

14.1.6. 排错表

现象	原因	处理
Knative 一直 `NotReady`	网络层/Kourier 未就绪	查 `networking-*` 与 `ksvc` 事件
冷启动极慢	镜像大/模型未缓存	预拉取、模型缓存、minScale=1
GPU Pod Pending	没有 GPU 资源/污点不匹配	查节点 allocatable 与 tolerations
KServe 加载模型失败	storageUri/凭证错误	查 `InferenceService` 状态与 storage initializer
批任务挤占在线服务	未隔离/未设 priority	独立节点池、taint、PriorityClass

14.1.7. 进阶挑战

用 Knative 部署一个缩到零的服务，测量冷启动 P95。
用 KServe 部署一个 sklearn 模型，接 Prometheus 指标做 HPA。
用 Ray 跑一个分布式任务，观察 GPU/CPU 使用率。
用 Volcano/Kueue 给训练任务加队列与配额。

14.1.8. 小结

Serverless 的核心是请求驱动与缩到零，代价是冷启动与状态管理。
AI 工作负载的关键约束是 GPU、模型缓存、队列与成本。
数据/训练任务要与在线服务隔离，使用独立节点池与批调度。
先跑通一条推理链路，再谈平台化。