FDE W7D7 学习手册 · K8s 基础拓扑、灰度回滚与企业平台整合

W7 Day7 · B 级（平台整合与交付收口）· 4h · 学完能讲清"K8s 下 AI 服务怎么部署/灰度/回滚 + W7 整体如何串成企业 Agent 平台最小版"

一、K8s 基础概念与核心对象

1.1 为什么 AI 平台要用 K8s

K8s 提供声明式编排、自动调度、自愈、扩缩容、服务发现、滚动发布。对一个要 7×24 的企业 AI 平台（网关 + 业务 + 模型服务），这些是生产必备，手动 Docker 做不到。

1.2 三大核心对象（本次重点）

二、Deployment：AI 服务的无状态部署

2.1 结构

Deployment 定义"我要跑几个副本、用哪个镜像、探针怎么配"，K8s 保证实际状态向期望状态收敛（自愈）。

apiVersion: apps/v1
kind: Deployment
metadata: { name: litellm-gateway }
spec:
  replicas: 3                      # 多副本高可用
  selector: { matchLabels: { app: litellm } }
  template:
    metadata: { labels: { app: litellm } }
    spec:
      containers:
      - name: litellm
        image: ghcr.io/berriai/litellm:main
        ports: [{ containerPort: 4000 }]
        readinessProbe:             # 模型/依赖就绪才接流量
          httpGet: { path: /health/liveliness, port: 4000 }
          initialDelaySeconds: 10
        livenessProbe:              # 进程死才重启
          httpGet: { path: /health/liveliness, port: 4000 }
        resources:
          requests: { cpu: "500m", memory: "512Mi" }
          limits:   { cpu: "1",    memory: "1Gi" }

2.2 AI 场景注意

• 网关/业务：无状态，多副本横向扩展，资源按 CPU/内存限。
• GPU 模型服务：用 resources.limits.nvidia.com/gpu 申请 GPU，节点需有 GPU 且装 device plugin。
• 探针阈值：呼应 D6，模型加载慢，initialDelaySeconds 给足。

三、Service：服务发现与负载均衡

3.1 作用

Pod 会漂、会重建、IP 会变。Service 给一组 Pod 一个稳定虚拟 IP + DNS 名，自动负载均衡到健康 Pod。调用方只认 Service 名，不认 Pod IP。

3.2 类型

四、Ingress：对外暴露与路由

4.1 作用

Ingress 是 K8s 的七层（HTTP）入口：按域名/路径把外部流量路由到对应 Service。例如 /api/ai/* 进网关 Service，/admin/* 进管理界面。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata: { name: ai-platform-ingress }
spec:
  rules:
  - host: ai.example-insurance.com
    http:
      paths:
      - path: /v1
        pathType: Prefix
        backend: { service: { name: litellm-gateway, port: { number: 4000 } } }
      - path: /admin
        pathType: Prefix
        backend: { service: { name: litellm-ui, port: { number: 80 } } }

4.2 与 Service 的配合

Ingress 是"大门+楼层指示牌"，Service 是"房间号"。外部请求先到 Ingress，再按规则转到内部 Service，再到 Pod。

五、AI 服务在 K8s 的部署形态（含 GPU/资源）

5.1 三类负载

5.2 GPU 调度要点

• 节点打标签（如 nvidia.com/gpu），Pod 用 nodeSelector/toleration 调度到 GPU 节点。
• 模型权重用 PVC/对象存储挂载，不进镜像（呼应 D6）。
• GPU 共享/切分（如 MIG）按场景，避免浪费。

六、滚动更新（Rolling Update）

6.1 原理

Deployment 更新镜像时，默认滚动更新：逐批用新 Pod 替换旧 Pod，期间服务不中断（新旧并存）。

6.2 配置

spec:
  strategy:
    rollingUpdate:
      maxSurge: 1          # 最多比期望多 1 个新 Pod
      maxUnavailable: 0     # 更新期间不允许旧 Pod 低于副本数（零停机）
  minReadySeconds: 15      # 新 Pod 就绪后等 15s 再继续

七、金丝雀发布（Canary）

7.1 原理

金丝雀：先放少量流量（如 5%~10%）到新版本，观察指标（错误率/延迟/成本）正常，再逐步放量到 100%。是比滚动更新更稳妥的"小步验证"。

7.2 在 K8s 怎么实现

7.3 适用

模型/网关升级风险高（新模型效果未知、新网关配置可能错），先金丝雀看真实效果再全量，避免"全量上线发现更差"。

八、回滚（Rollback）到上一版本

8.1 原理

Deployment 每次更新会生成修订版本（revision）。出问题 kubectl rollout undo 即可回滚到上一个稳定 revision，K8s 自动把 Pod 换回旧镜像。

8.2 回滚前提

• 保留旧镜像：回滚靠旧镜像还在仓库，别删。
• 状态兼容：若新版本改了数据库 schema 且不兼容，回滚后旧代码可能读不了新数据——要配迁移策略。
• 快速检测：要有监控/告警，才能"及时发现→快速回滚"。

九、企业 Agent 平台最小版：组件清单

9.1 W7 整体产出盘点

十、企业 Agent 平台最小版：调用链串联

10.1 端到端调用链

10.2 与 D6 单一职责呼应

• 路由：网关一层做（业务只选虚拟 Key）。
• 重试：网络重试只一层（如 Spring AI），业务级带反馈重试在应用层。
• 成本：网关落库唯一可信来源。
• 发布：网关/业务各自 Deployment，独立滚动/金丝雀/回滚。

十一、整体可观测与成本（呼应 W7 全局）

11.1 三层可观测

11.2 成本闭环

网关（LiteLLM）落库的成本数据 → Prometheus 抓取/BI 报表 → Grafana 看板，实现"哪个业务线/项目花多少"的可视化（呼应 D5 项目级成本）。结合告警，预算超 80% 自动通知。

十二、W7 整体整合：从零到"企业 Agent 平台最小版"

12.1 一句话总结 W7

12.2 给面试官的"周成果陈述"模板

十三、面试达标线①：K8s 部署与灰度回滚

十四、面试达标线②：W7 整体形成"企业 Agent 平台最小版"

1. 组件：业务(Deployment)、网关(Deployment)、Postgres(StatefulSet)、模型(外部/Deployment)、Ingress 入口、Secret/探针/隔离交付件。
2. 调用链：与 D6 单一职责呼应，路由/重试/成本各一层，Trace 贯穿。
3. 治理：虚拟 Key、预算、多租户、项目级成本（D5），可观测三件套+成本看板（D7）。
4. 发布：网关与业务独立滚动/金丝雀/回滚（D7）。
5. 决策：Build vs Buy + ADR 留痕（D5），让平台选型可辩护。

十五、W7D7 自测清单

十六、高频面试题速记卡