Kubernetes容器编排实战：大模型推理服务的弹性扩缩容与流量治理

Kubernetes承载大模型推理服务的架构选择

大模型推理服务对基础设施的弹性调度和流量治理提出了新要求。传统Web应用的水平扩容模式在LLM推理场景下并不适用——每个推理Pod占用大量GPU资源，冷启动时间长达数十秒，扩缩容决策需要考虑GPU预热延迟和KV Cache状态迁移。Kubernetes作为容器编排事实标准，在v1.30+版本中提供了更好的GPU调度和弹性伸缩支持，是当前大模型推理服务部署的首选平台。

核心架构选择：使用KServe或Triton Inference Server作为推理运行时，配合KEDA作为弹性扩缩容控制器，Istio/Envoy作为流量治理层。这种组合在多个生产环境中验证可行。

GPU调度与资源分配策略

Kubernetes的GPU调度需要安装NVIDIA device plugin，并在节点上配置GPU资源上报：

# Device Plugin DaemonSet部署
kubectl apply -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/v0.16.0/deployments/static/nvidia-device-plugin.yml

# 验证GPU资源上报
kubectl describe node gpu-node-01 | grep -A 5 "Allocatable"

推理Pod的资源请求配置直接影响调度效率。关键配置项：

resources:
  limits:
    nvidia.com/gpu: 1  # 每个Pod独占1张GPU
    memory: 32Gi
  requests:
    nvidia.com/gpu: 1
    memory: 32Gi

# 使用Multi-Instance GPU (MIG)时
# limits:
#   nvidia.com/mig-1g.10gb: 2  # 2个MIG实例
#   nvidia.com/mig-2g.20gb: 1

MIG（Multi-Instance GPU）允许将一张A100/H100切分为多个GPU实例，适合小模型推理场景。但在MoE大模型推理中，跨MIG实例的专家路由会引入不可接受的延迟，此时应独占整张GPU。

KEDA弹性扩缩容配置

KEDA（Kubernetes Event-Driven Autoscaler）比HPA更适合推理服务场景，它支持基于自定义指标的弹性伸缩，且具有冷却期配置，避免因请求波动导致的频繁扩缩容。

# KEDA ScaledObject配置
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: llm-inference-scaler
  namespace: ai-serving
spec:
  scaleTargetRef:
    name: llm-inference-deployment
  minReplicaCount: 2       # 最低保活2副本
  maxReplicaCount: 16      # 最大16副本
  cooldownPeriod: 300      # 缩容冷却期5分钟
  triggers:
  - type: prometheus
    metadata:
      serverAddress: http://prometheus.monitoring:9090
      metricName: http_requests_waiting
      threshold: "50"       # 等待队列超过50时扩容
      query: |
        sum(http_requests_waiting{job="llm-inference"})
  - type: prometheus
    metadata:
      serverAddress: http://prometheus.monitoring:9090
      metricName: gpu_utilization
      threshold: "85"       # GPU利用率超过85%时扩容
      query: |
        avg(dcgm_gpu_utilization{job="llm-inference"})

冷却期设计的重要性：推理Pod从Pending到Ready需要经过GPU驱动初始化、模型权重加载、KV Cache预热等步骤，全程可能耗时30-60秒。冷却期设为300秒可以避免在流量短暂波峰后立即缩容导致下一波请求到来时重新冷启动。对于已知的有规律的流量高峰（如工作日9:00-12:00），建议配合CronTrigger预设最低副本数：

  - type: cron
    metadata:
      timezone: Asia/Shanghai
      start: 0 9 * * 1-5
      end: 0 12 * * 1-5
      desiredReplicas: "8"

推理服务的流量治理

大模型推理的流量治理有三个核心场景：灰度发布、请求路由和故障隔离。

灰度发布：使用Istio VirtualService实现按权重分配流量到新旧版本推理服务：

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: llm-inference
spec:
  hosts:
  - llm-api.example.com
  http:
  - route:
    - destination:
        host: llm-inference-v2
        port:
          number: 8000
      weight: 10    # 10%流量到新版本
    - destination:
        host: llm-inference-v1
        port:
          number: 8000
      weight: 90    # 90%流量到旧版本
    retries:
      attempts: 2
      perTryTimeout: 30s

请求路由：不同模型版本或不同规格的推理服务需要根据请求中的模型标识进行路由。在Istio中使用Header匹配：

  - match:
    - headers:
        x-model-version:
          exact: "k3-chat"
    route:
    - destination:
        host: llm-inference-k3
  - match:
    - headers:
        x-model-version:
          exact: "k3-reasoning"
    route:
    - destination:
        host: llm-inference-k3-reasoning

故障隔离：单个推理Pod的OOM或GPU异常可能导致整个请求堆积。配置CircuitBreaker防止级联故障：

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: llm-inference-cb
spec:
  host: llm-inference
  trafficPolicy:
    connectionPool:
      http:
        h2UpgradePolicy: DEFAULT
        http1MaxPendingRequests: 100
        http2MaxRequests: 200
    outlierDetection:
      consecutive5xxErrors: 3
      interval: 30s
      baseEjectionTime: 120s
      maxEjectionPercent: 50

DevOps流水线集成

推理服务的CI/CD需要增加模型验证环节。标准流水线阶段：

1. 代码构建：推理服务代码的单元测试与容器镜像构建
2. 模型下载与校验：从模型仓库下载权重文件，校验SHA256
3. 推理性能测试：使用预定义的prompt集合验证推理延迟和输出质量
4. 灰度发布：10%流量切换到新版本，观察5分钟
5. 全量发布：逐步提升到100%

关键监控指标：P50/P95/P99推理延迟、请求成功率、GPU利用率、KV Cache命中率、请求排队深度。使用Grafana Dashboard统一展示，设置Prometheus告警规则推送到企业IM。