1. 云原生基础与容器核心

  • Docker 原理、镜像、仓库、多阶段构建

Docker 是基于 Linux 内核 Namespace、Cgroups 与 UnionFS 实现的轻量级容器化技术，核心是镜像打包、容器运行、仓库分发、多阶段构建优化，实现 “一次构建、到处运行”。

一、基础认知（概念 + 本质 + 关系）

1. Docker 核心原理

Docker 基于 Linux 三大内核特性实现隔离与资源管控：

  • Namespace：实现进程、网络、挂载、用户、UTS、IPC 六大隔离，让容器拥有独立运行环境。
  • Cgroups：限制容器 CPU、内存、磁盘 I/O、网络带宽等资源，避免资源抢占。
  • UnionFS（overlay2）：分层文件系统，实现镜像只读分层、容器可写层、层共享复用。
  • 架构：C/S 模式，Docker Client 发指令，Docker Daemon 管理镜像 / 容器 / 网络 / 卷，Containerd 负责容器生命周期，runc 执行容器创建。
2. 镜像（Image）
  • 定义：只读的分层模板，包含应用代码、运行时、依赖库、环境变量、配置文件，是容器的 “静态模具”。
  • 本质：多层只读文件系统叠加（如 alpine 基础层 + nginx 安装层 + 配置层），层可跨镜像共享。
  • 核心特点：不可变、分层存储、通过 Dockerfile 构建、存储于仓库。
3. 仓库（Registry）
  • 定义：集中存储、分发 Docker 镜像的服务，类似 “镜像 GitHub”。
  • 类型：
    • 公共仓库：Docker Hub（官方默认）、阿里云 ACR、腾讯云 TCR 等。
    • 私有仓库：Harbor（企业级）、Nexus、AWS ECR，用于内部私有镜像管理。
  • 核心逻辑：镜像 push 上传、pull 拉取，实现跨环境镜像共享。
4. 多阶段构建（Multi-stage Build）
  • 定义：在单个 Dockerfile 中定义多个构建阶段，分离 “构建环境” 与 “运行环境”，仅保留运行必需文件。
  • 核心价值：解决单阶段构建镜像体积大、含构建依赖 / 冗余文件、安全风险高的问题。
5. 四者关系

原理（底层支撑）→ 镜像（打包载体）→ 仓库（分发枢纽）→ 多阶段构建（优化手段）→ 容器（运行实例），形成 “构建 - 优化 - 分发 - 运行” 闭环。

二、核心配置（Dockerfile + 仓库 + 多阶段语法）

1. 镜像核心配置（Dockerfile 关键指令）

Dockerfile 是镜像构建的 “源代码”，每条指令对应一层镜像：

表格

指令 作用 示例
FROM 指定基础镜像（必选） FROM alpine:3.18
WORKDIR 设置工作目录 WORKDIR /app
COPY 复制本地文件到镜像 COPY . .
RUN 执行命令（创建新层） RUN apk add nginx
ENV 设置环境变量 ENV PORT=80
EXPOSE 声明暴露端口 EXPOSE 80
CMD 容器启动默认命令 CMD ["nginx", "-g", "daemon off;"]
ENTRYPOINT 容器入口命令（不可被覆盖） ENTRYPOINT ["nginx"]
2. 仓库核心配置
  • 镜像标签（Tag）：[仓库地址]/[命名空间]/[镜像名]:[版本]，如 docker.io/library/nginx:1.25-alpine。
  • 登录 / 推送 / 拉取：

    bash

    # 登录私有仓库
docker login registry.example.com
# 推送镜像
docker push registry.example.com/myapp:v1
# 拉取镜像
docker pull registry.example.com/myapp:v1
  • 私有仓库部署：以 Harbor 为例，支持镜像签名、漏洞扫描、权限控制、Webhook 触发 CI/CD。
3. 多阶段构建核心语法
  • 阶段命名：FROM ... AS [阶段名]，区分构建阶段与运行阶段。
  • 跨阶段复制：COPY --from=[阶段名] [源路径] [目标路径]，仅复制运行必需产物。
  • 基础模板：

    dockerfile

    # 阶段1：构建阶段（含编译工具、依赖）
FROM golang:1.21 AS builder
WORKDIR /app
COPY . .
RUN go build -o myapp

# 阶段2：运行阶段（仅含运行时+产物）
FROM alpine:3.18
COPY --from=builder /app/myapp /usr/local/bin/
CMD ["myapp"]

三、实操场景（从构建到分发的全流程）

场景 1：单阶段构建基础镜像（入门）
  1. 编写 Dockerfile（单阶段）：

    dockerfile

    FROM python:3.10-slim
WORKDIR /app
COPY . .
RUN pip install -r requirements.txt
EXPOSE 5000
CMD ["python", "app.py"]
  2. 构建镜像：docker build -t myapp:v1 .
  3. 运行容器：docker run -d -p 5000:5000 myapp:v1
  4. 问题：镜像体积大（约 500MB），含 pip 缓存、构建工具等冗余文件。
场景 2：多阶段构建优化（生产必备）

以 Python Web 应用为例，剥离构建依赖：

dockerfile

# 阶段1：安装依赖+打包（builder 阶段）
FROM python:3.10-slim AS builder
WORKDIR /app
COPY requirements.txt .
RUN pip install --user -r requirements.txt
COPY . .

# 阶段2：仅复制运行依赖+代码
FROM python:3.10-alpine
WORKDIR /app
COPY --from=builder /root/.local/lib/python3.10/site-packages /usr/local/lib/python3.10/site-packages
COPY --from=builder /app /app
EXPOSE 5000
CMD ["python", "app.py"]
  • 效果：镜像体积从 500MB 降至 100MB 以内，无构建冗余，安全风险降低。
场景 3：Java/Golang 编译型应用多阶段构建
  • Java（Maven 构建）：

    dockerfile

    FROM maven:3.8-openjdk17 AS builder
WORKDIR /app
COPY . .
RUN mvn package -DskipTests

FROM eclipse-temurin:17-jre-alpine
WORKDIR /app
COPY --from=builder /app/target/*.jar app.jar
CMD ["java", "-jar", "app.jar"]
  • Golang：

    dockerfile

    FROM golang:1.22 AS builder
WORKDIR /app
COPY . .
RUN CGO_ENABLED=0 go build -o myapp

FROM alpine:3.18
COPY --from=builder /app/myapp /usr/local/bin/
CMD ["myapp"]
场景 4：镜像仓库分发（公共 + 私有）
  1. 标记镜像（适配私有仓库）：docker tag myapp:v1 registry.example.com/myapp:v1
  2. 推送至私有仓库：docker push registry.example.com/myapp:v1
  3. 其他服务器拉取运行：

    bash

    docker pull registry.example.com/myapp:v1
docker run -d registry.example.com/myapp:v1

四、进阶扩展（优化 + 安全 + 企业级）

1. 镜像构建进阶优化
  • 分层缓存利用：将不常变的依赖安装（如 RUN pip install）放 Dockerfile 上层，频繁变的代码复制（COPY . .）放下层，复用缓存加速构建。
  • 最小基础镜像：优先用 alpine（~5MB）、distroless 镜像，替代 ubuntu、centos（~100MB），减少体积与漏洞面。
  • 清理冗余：构建时删除缓存、临时文件，如 RUN apt-get update && apt-get install -y nginx && apt-get clean && rm -rf /var/lib/apt/lists/*。
  • 多架构镜像：用 docker buildx 构建 arm64/x86_64 兼容镜像，适配异构集群。
2. 多阶段构建进阶技巧
  • 多阶段复用：多个阶段共享基础层，如 FROM builder AS test 复用构建阶段环境做测试。
  • 阶段参数化：用 ARG 定义阶段变量，灵活切换构建环境，如 ARG BUILD_ENV=prod。
  • 跨阶段权限控制：运行阶段用非 root 用户，避免容器以 root 运行，提升安全。
3. 仓库企业级扩展
  • 镜像安全：集成 Trivy、Clair 做漏洞扫描，用 Notary 做镜像签名，防止篡改。
  • 权限与治理：Harbor 配置 RBAC 权限、镜像生命周期管理（自动清理过期镜像）、策略控制（禁止 latest 标签推送）。
  • CI/CD 集成：仓库 Webhook 触发 Jenkins/GitLab CI 流水线，实现 “代码提交→镜像构建→推送→部署” 自动化。
4. 原理深度扩展
  • UnionFS 写时复制（CoW）：容器修改文件时，从只读层复制到可写层修改，不影响原镜像，提升效率。
  • 容器与虚拟机区别：容器共享宿主机内核，秒级启动、资源占用低；VM 模拟完整 OS，启动慢、资源占用高。
  • 容器持久化：用 Volume、Bind Mount 绕过 UnionFS，实现数据持久化，独立于容器生命周期。

  • 容器 runtime、cgroup /namespace、安全隔离

一、基础认知：它们到底是什么、关系是什么

1. 容器 runtime

容器运行时 = 真正 “启动、运行、停止、销毁容器” 的底层程序。

  • 负责：创建容器进程、挂载文件系统、配置网络、调用内核能力。
  • 常见：
    • runc：最底层、标准实现（OCI runtime）
    • containerd：管理镜像、容器生命周期，给 Docker/K8s 用
    • crun / kata / gVisor：安全 / 高性能 runtime

一句话：runtime 是容器的 “执行者”，cgroup/namespace 是 Linux 给它的 “隔离工具”。

2. Namespace（命名空间）

作用：让容器 “看” 起来像一台独立机器。把全局系统资源 “包” 起来，每个 namespace 里是独立视图。

Linux 6 大核心 namespace：

  • PID：进程号隔离，容器里 PID=1 看不到宿主机进程
  • NET：独立网卡、IP、端口、路由表
  • MNT：独立文件系统挂载点
  • UTS：独立主机名、域名
  • IPC：独立进程间通信（共享内存、信号量）
  • USER：用户 / 组隔离，容器内 root ≠ 宿主机 root

一句话：Namespace = 视线隔离，让容器 “看不见” 宿主机资源。

3. Cgroup（Control Group）

作用：限制容器能 “用” 多少资源，防止一个容器打垮整机。

可限制 / 统计：

  • CPU 使用率 / 核心数
  • 内存最大用量
  • 磁盘 I/O 带宽
  • 网络带宽
  • 进程数上限

一句话：Cgroup = 用量限制，不让容器乱吃资源。

4. 安全隔离

容器安全 = 三层防护：

  1. Namespace：看不见
  2. Cgroup：用不多
  3. 能力限制 + 权限控制：闯不出

目标：即使容器被攻破，也尽量无法逃逸、无法破坏宿主机。

二、核心配置：它们怎么配、怎么生效

1. 容器 runtime 核心配置

以 containerd + runc 为例：

  • config.toml：配置 runtime 类型、cgroup 版本、镜像仓库、快照器。
  • runc spec：生成 config.json，定义：
    • 要启用哪些 namespace
    • 要挂哪些 cgroup
    • 允许 / 禁止的系统调用（syscall）
    • 挂载路径、权限、用户

常见开关：

  • rootless：非 root 运行容器
  • readonly：根文件系统只读
  • no-new-privileges：禁止提权
2. Namespace 核心配置

创建 / 进入 namespace 的系统调用：

  • clone()：创建新进程并加入新 namespace
  • unshare()：脱离当前 namespace
  • setns()：加入已有 namespace

Docker 里等价配置：

plaintext

--pid=container:id     # 共享PID命名空间
--net=host             # 共享主机网络（不隔离）
--uts=host
--user=root            # 用户命名空间
3. Cgroup 核心配置（v1 /v2）

通过文件系统 /sys/fs/cgroup/* 配置：

  • 内存限制

    plaintext

    memory.limit_in_bytes = 512M
  • CPU 限制

    plaintext

    cpu.cfs_quota_us = 50000  # 最多用 50% CPU
  • 进程数限制

    plaintext

    pids.max = 100

Docker 命令：

bash

运行

docker run --memory=512m --cpus=0.5 --pids-limit=100 ...
4. 安全隔离核心配置
  • 禁止特权模式

    plaintext

    --privileged=false  # 默认就是，千万别乱开
  • 只读根文件系统

    plaintext

    --read-only
  • 删除 Linux 能力

    plaintext

    --cap-drop=ALL
--cap-add=NET_BIND_SERVICE  # 只加需要的
  • 非 root 用户运行

    plaintext

    --user=1000:1000
  • seccomp / AppArmor / SELinux限制系统调用、文件访问。

三、实操场景：落地怎么用

场景 1：用 unshare 手工造一个 “容器”

bash

运行

sudo unshare --pid --net --ipc --uts --mount --fork /bin/bash

你会得到：

  • 看不见宿主机进程
  • 独立 hostname
  • 独立网络

这就是最原始的容器。

场景 2：给服务限制资源（生产必做）

bash

运行

docker run -d \
  --name myapp \
  --memory=1g \
  --cpus=2 \
  --pids-limit=500 \
  --read-only \
  --user=1001 \
  --cap-drop=ALL \
  nginx:alpine

作用：

  • 内存炸不了宿主机
  • 无法提权、无法篡改文件
  • 即使被入侵也很难逃逸
场景 3：K8s 里的对应配置

yaml

resources:
  limits:
    cpu: 2
    memory: 1Gi
  requests:
    cpu: 100m
    memory: 256Mi

securityContext:
  runAsUser: 1000
  readOnlyRootFilesystem: true
  allowPrivilegeEscalation: false
  capabilities:
    drop: ["ALL"]

底层就是：cgroup + namespace + 安全能力。

场景 4：排查容器 “穿透宿主机” 问题
  • 容器能看到宿主机进程？→ 用了 --pid=host，PID namespace 没隔离。
  • 容器占满 CPU / 内存？→ 没配 cgroup 限制。
  • 容器改了宿主机文件？→ 挂载了危险路径 / 特权模式 / 权限过大。

四、进阶扩展：原理 & 生产级深度

1. runtime 进阶：runc、containerd、CRI
  • runc：只干 “创建容器” 这件事，OCI 标准。
  • containerd：管理镜像、网络、存储、生命周期。
  • CRI：K8s 调用容器运行时的接口。

架构：

plaintext

K8s → kubelet → CRI → containerd → runc → 容器
2. Namespace 进阶：不是完全虚拟化
  • 容器共享同一个 Linux 内核。
  • Namespace 是逻辑隔离，不是硬件级隔离。
  • 有少数全局资源无法完全隔离：
    • 时间
    • 部分 /proc、/sys
    • 内核模块
3. Cgroup v2 进阶（现代主流）

Cgroup v2 优势：

  • 单一路径 /sys/fs/cgroup
  • 资源控制更统一、更安全
  • 支持：内存保护、压力信息、更细粒度网络限速

Docker / K8s 现在都推荐用 cgroup v2。

4. 安全隔离进阶：容器逃逸与防御

常见逃逸路径：

  • 特权模式 --privileged
  • 挂载 /var/run/docker.sock
  • 内核漏洞
  • 不安全 syscall、能力过大

防御体系：

  1. 最小权限：drop all caps
  2. 只读 FS
  3. 非 root 运行
  4. seccomp/apparmor/selinux
  5. Runtime 沙箱：kata、gVisor（硬件级强隔离）
5. 企业级总结
  • namespace：隔离视图
  • cgroup：限制用量
  • runtime：执行生命周期
  • 安全隔离：最小权限 + 内核防护 + 沙箱

一句话串起来：容器 runtime 依靠 Linux namespace 做视线隔离、cgroup 做资源限制，再配合最小权限与安全机制，实现轻量但可控的 “安全沙箱”。

  • 微服务架构、服务网格基础

一、基础认知：是什么、为什么、关系

1. 微服务架构

把一个大应用，拆成多个小、独立、可独立部署的服务。

核心特点：

  • 按业务域拆分（用户、订单、支付、商品）
  • 服务独立开发、独立部署、独立扩缩容
  • 服务之间通过 HTTP/gRPC 通信
  • 每个服务可使用不同技术栈（Java/Go/Node/Python）

对比单体：

  • 单体：代码耦合、发布风险大、无法局部扩容
  • 微服务：松耦合、可独立演进、适合大型团队

微服务带来的新问题：

  • 服务太多，通信、治理、安全、可观测性变复杂
  • 重试、限流、熔断、监控、路由、安全 要每个服务自己写
2. 服务网格（Service Mesh）

专门解决微服务通信与治理的基础设施层。

一句话定位：服务网格 = 微服务的 “通信管家 + 治理平台”

核心思想：

  • 把流量控制、安全、可观测从业务代码里抽出来
  • 交给一个独立的数据面（Sidecar） 统一处理
  • 业务只写业务逻辑，不再写治理代码

两大组件：

  • 数据面（Data Plane）：Sidecar 代理（如 Envoy），接管所有进出流量
  • 控制面（Control Plane）：统一配置、下发规则、收集指标（如 Istiod）

微服务与服务网格关系：微服务解决 “如何拆”，服务网格解决 “拆完怎么管”。

二、核心配置：关键能力与配置模型

1. 微服务架构核心配置

1）服务注册与发现

  • 服务启动时注册自己
  • 调用方通过注册中心找到地址
  • 工具：Nacos、Eureka、Consul、etcd

2）配置中心

  • 统一管理环境变量、开关、阈值
  • 动态生效不重启

3）服务治理（SDK 时代）

  • 熔断、降级、限流、超时、重试
  • 工具：Sentinel、Resilience4j、Hystrix

4）API 网关

  • 统一入口、路由、认证、限流、日志
  • 工具：Spring Cloud Gateway、Kong、APISIX
2. 服务网格核心配置（以 Istio 为例）

服务网格不再侵入代码，全部用 K8s YAML 声明式配置。

核心资源：

  • Gateway：入口网关（代替传统 API 网关）
  • VirtualService：流量路由、权重、重试、超时、重写
  • DestinationRule：子集、连接池、熔断、负载均衡
  • PeerAuthentication：服务间 mTLS 加密
  • AuthorizationPolicy：服务访问权限
  • Sidecar：限制服务访问范围，缩小爆炸半径

典型配置能力：

  • 流量切分（金丝雀、蓝绿）
  • 超时、重试、熔断
  • 全链路 mTLS
  • 细粒度权限控制
  • 监控、 tracing、日志自动注入

三、实操场景：落地最常用的真实场景

场景 1：微服务典型调用链（业务层）

plaintext

前端 → API网关 → 用户服务 → 订单服务 → 支付服务 → 库存服务

痛点：

  • 每个服务都要写：超时、重试、日志、监控、安全
  • 多语言项目很难统一治理
场景 2：服务网格接管所有通信（无侵入）

所有流量自动经过 Sidecar：

plaintext

服务A → Sidecar → 网络 → Sidecar → 服务B

1）金丝雀发布（最常用）

yaml

# 90% 到 v1，10% 到 v2
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
spec:
  http:
  - route:
    - destination:
        host: order
        subset: v1
      weight: 90
    - destination:
        host: order
        subset: v2
      weight: 10

2）服务熔断（防止级联故障）

yaml

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
spec:
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 100
    outlierDetection:
      consecutiveErrors: 5
      interval: 10s

3）全站加密 mTLS

yaml

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
spec:
  mtls:
    mode: STRICT

4）权限控制：只允许订单服务调用支付

yaml

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
spec:
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/default/sa/order"]
    to:
    - operation:
        methods: ["POST"]
场景 3：可观测性（开箱即用）
  • 服务间调用拓扑图
  • 成功率、延迟、流量 QPS
  • 分布式追踪（Jaeger/Zipkin）
  • 日志自动统一格式业务代码 0 改造

四、进阶扩展：架构深度 & 生产级认知

1. 微服务架构进阶

1）康威定律

  • 系统设计 = 组织沟通结构
  • 微服务边界应和团队边界对齐

2）CAP 定理

  • 分布式只能三选二：一致性、可用性、分区容错
  • 微服务通常选 AP（可用性 + 分区容错）

3）数据一致性

  • 无分布式事务
  • 用：最终一致、Saga、事务消息、事件驱动

4）DDD 是微服务的最佳拆分方法论

  • 限界上下文 → 微服务边界
  • 聚合根 → 服务对外能力
2. 服务网格进阶

1）Sidecar 模式本质

  • 代理容器与业务容器同 Pod
  • 通过 iptables 劫持流量，对业务透明

2）数据面 vs 控制面

  • 数据面：高性能转发、执行规则
  • 控制面：证书、服务发现、配置推送、遥测

3）服务网格 vs Spring Cloud 类 SDK

  • SDK：代码侵入、语言绑定、升级难
  • 服务网格：无侵入、多语言统一、治理标准化

4）性能与成本

  • Sidecar 会增加 1~3ms 延迟
  • 换来：安全、可观测、全链路治理、多语言统一

5）下一代：Ambient Mesh（无 Sidecar）

  • 无需注入 Sidecar
  • 节点级代理，更轻量、更易落地

极简总结（可直接背诵）

  • 微服务：按业务拆小，独立部署，解决复杂应用迭代问题
  • 服务网格：通过 Sidecar 接管流量，统一做路由、限流、熔断、安全、可观测
  • 关系：微服务解决拆分，服务网格解决治理
  • 模式：业务代码只干业务，通信治理下沉到基础设施

2. Kubernetes 核心原理与实战

  • 集群架构、etcd、调度、控制器

一、基础认知：它们是什么、关系是什么

1. Kubernetes 集群架构

K8s 是容器编排平台，负责：自动化部署、扩缩容、自愈、管理容器生命周期。

两大角色：

  • Master（控制平面 Control Plane）：大脑
    • kube-apiserver：统一入口、认证授权
    • etcd：唯一存储
    • kube-scheduler：调度
    • kube-controller-manager：控制器
  • Node（工作节点）：干活
    • kubelet：管理本机 Pod
    • kube-proxy：网络、Service
    • 容器 runtime（containerd）：运行容器

一句话：用户 → apiserver → etcd → 调度 / 控制器 → kubelet → 容器运行。

2. etcd
  • 分布式 键值存储，K8s 唯一数据源
  • 强一致、高可用、基于 Raft 协议
  • 存：Pod、Service、ConfigMap、Secret、节点信息等

一句话：etcd = K8s 的 “数据库 + 真理源”。

3. 调度（Scheduler）
  • watching apiserver 中 待调度 Pod
  • 按一系列规则选最优 Node
  • 把 Pod 绑定到 Node，写入 etcd

一句话：Scheduler = K8s 的 “人事安排官”，决定 Pod 去哪台机器。

4. 控制器（Controller）
  • 控制平面的 “自动化工人”
  • 监听实际状态 → 与期望状态对比 → 调协
  • 保证系统始终符合你写的 YAML

常见控制器：

  • Deployment：保证副本数、滚动更新
  • StatefulSet：有状态应用
  • DaemonSet：每节点一个
  • Job/CronJob：一次性 / 定时任务
  • ReplicaSet：管理 Pod 副本

一句话：控制器 = 让集群 “自动干活、自动自愈”。

二、核心配置：关键组件 & 配置模型

1. 集群架构核心组件与职责

kube-apiserver

  • 提供 REST 接口
  • 认证、授权、准入控制
  • 唯一和 etcd 交互的组件

etcd

  • --data-dir 数据目录
  • --listen-client-urls 监听地址
  • --initial-cluster 集群节点

kube-scheduler

  • 预选策略（过滤）
  • 优选策略（打分）
  • 可扩展调度器

kube-controller-manager

  • 所有控制器的合集
  • --controllers 启用哪些控制器
  • 保证 “最终一致性”

kubelet

  • 向 apiserver 注册节点
  • 管理本机 Pod 生命周期
  • 上报状态
2. 调度核心配置
  • nodeSelector：简单节点选择
  • nodeAffinity / podAffinity / podAntiAffinity：亲和性
  • taint（污点） + toleration（容忍）：排斥 / 允许
  • resources.requests / limits：资源调度依据
  • topologySpreadConstraints：跨域分散
3. 控制器核心配置（以 Deployment 为例）

yaml

apiVersion: apps/v1
kind: Deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - image: nginx
  • replicas：期望副本数
  • selector：关联 Pod
  • template：Pod 模板

控制器会无限循环保证运行副本 = replicas。

三、实操场景：最常用真实流程

场景 1：创建 Pod 的完整流程（面试必考）
  1. kubectl create → apiserver
  2. 鉴权、校验，写入 etcd
  3. Scheduler 发现未调度 Pod
  4. 过滤 + 打分，选择 Node
  5. 绑定 Pod 到 Node，更新 etcd
  6. kubelet 看到本机被分配 Pod
  7. 调用 runtime 创建容器
  8. 上报状态 → apiserver → etcd
场景 2：Deployment 自动扩缩容 & 自愈
  • 删除一个 Pod
  • ReplicaSet Controller 发现少副本
  • 立即创建新 Pod
  • Scheduler 调度
  • 最终恢复期望数量

这就是自愈。

场景 3：调度规则实战
  • 只让 Pod 跑在 SSD 节点：

    yaml

    nodeSelector:
  disktype: ssd
  • 节点打污点，不让随便调度：

    yaml

    kubectl taint nodes node1 key=value:NoSchedule
  • Pod 必须加容忍才能上去。
场景 4：etcd 日常运维
  • 备份：

    bash

    运行

    etcdctl snapshot save
  • 查看成员：

    bash

    运行

    etcdctl member list
  • 查看键：

    bash

    运行

    etcdctl get /registry/namespaces/default

四、进阶扩展：深度原理 & 生产级

1. 集群架构进阶
  • 所有组件无状态，只依赖 etcd
  • apiserver 可水平扩展
  • 高可用：多 master + 多 etcd 节点
  • 所有协调通过 list-watch 实现（高效异步）
2. etcd 进阶
  • Raft 保证强一致
  • 读：leader / follower
  • 写：必须走 leader 同步多数节点
  • K8s 只使用 key + revision 版本机制
  • 性能瓶颈往往在 etcd
3. 调度进阶

调度两阶段：

  1. Predicates 预选：过滤不能跑的节点（资源、污点、亲和）
  2. Priorities 优选：打分选最优（资源均衡、分布、亲和）

扩展：

  • 自定义调度器
  • 调度插件框架
  • 容量调度、拓扑打散、GPU 调度
4. 控制器进阶
  • 设计模式：控制循环（Reconciliation Loop）
  • 思想：声明式 API + 最终一致性
  • 不需要消息队列，不需要分布式锁
  • 自己写 Operator 就是自定义控制器

核心哲学：不关注过程，只保证结果和 YAML 一致。

极简背诵版（可直接面试用）

  • K8s 架构：Master(apiserver/etcd/scheduler/controller) + Node(kubelet)
  • etcd：K8s 唯一高可用键值存储，存所有状态
  • 调度：过滤 + 打分，把 Pod 安排到合适节点
  • 控制器：循环保证实际状态 = 期望状态，实现自愈、扩缩容、更新

  • Pod / Service / Ingress / ConfigMap / Secret

Kubernetes 中的 API 资源对象（Resource Object），是用来声明、定义、管理应用的核心载体。

更直白一点：

  • Pod：最小运行单元（真正跑容器的地方）

  • Service：服务发现与负载均衡（给 Pod 提供固定访问入口）

  • Ingress：集群外部入口（域名 + HTTP/HTTPS 路由）

  • ConfigMap：普通配置（存放无敏感的配置信息）

  • Secret：敏感配置（存放密码、密钥、证书等）

下面这个链接会涉及相关介绍：

https://blog.csdn.net/weixin_49109647/article/details/158460491?fromshare=blogdetail&sharetype=blogdetail&sharerId=158460491&sharerefer=PC&sharesource=weixin_49109647&sharefrom=from_link

  • 存储、网络插件（Calico、Flannel）

一、基础认知：是什么、作用、相互关系

1. 存储（K8s 存储体系）

K8s 存储用来给容器提供持久化数据，不让数据跟着容器删没了。

核心三层抽象：

  • Volume：容器目录的挂载卷（临时 / 持久）
  • PV：PersistentVolume，集群级存储空间
  • PVC：PersistentVolumeClaim，Pod 对存储的 “申请”

一句话：Pod 用 PVC 申请存储，PV 提供存储，实现数据持久化。

2. 容器网络基础

K8s 网络三大基础规则：

  • 每个 Pod 独立 IP
  • Pod 之间可直接通信
  • 节点之间可互通
3. Flannel
  • 简单的二层 / 三层网络插件
  • 只做：Pod 互通
  • 不自带网络策略
  • 适合：测试、简单集群
4. Calico
  • 高性能 三层网络 + 网络策略
  • 支持：BGP、IPIP、VXLAN
  • 自带：NetworkPolicy 访问控制
  • 生产主流

一句话：Flannel 只管通；Calico 通 + 安全隔离。

二、核心配置

1. 存储核心配置
  • emptyDir：临时目录，Pod 删除即丢
  • hostPath：挂载宿主机目录
  • nfs：网络共享存储
  • StorageClass：动态供给 PV
  • accessModes：
    • ReadWriteOnce
    • ReadOnlyMany
    • ReadWriteMany

PVC 必配字段：

yaml

resources:
  requests:
    storage: 10Gi
accessModes:
  - ReadWriteOnce
storageClassName: standard
2. Flannel 核心模式
  • VXLAN（默认）隧道封装，跨节点互通，配置最简单。
  • Host-Gateway路由转发，性能比 VXLAN 好，但要求二层互通。
3. Calico 核心配置
  • IPIP 模式：跨云 / 弱二层环境
  • VXLAN 模式：通用、兼容好
  • BGP 模式：高性能、无隧道、物理机环境
  • Felix：负责策略、路由、ACLs

三、实操场景

场景 1：Pod 挂载持久存储（NFS / 云盘）
  1. 创建 PV 或用 StorageClass
  2. 创建 PVC 申请
  3. Pod 中挂载

yaml

volumes:
- name: data
  persistentVolumeClaim:
    claimName: mypvc
场景 2：配置文件挂载（ConfigMap/Secret）

把配置文件当作存储挂载进容器，不重建镜像改配置。

场景 3：Flannel 快速搭建集群
  • 只需部署 Flannel YAML
  • 自动给节点分配子网
  • 所有 Pod 直接互通
场景 4：Calico 实现 Pod 访问限制（NetworkPolicy）

示例：只允许同命名空间访问

yaml

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector: {}

四、进阶扩展

1. 存储进阶
  • CSI：存储插件标准，对接各种存储
  • 动态 PV：自动创建 / 删除，无需手动建 PV
  • 扩容：在线扩容 PVC
  • 快照 & 克隆：数据备份恢复
2. 网络进阶对比（面试高频）

表格

特性 Flannel Calico
功能 仅 Pod 互通 互通 + 网络策略
性能 一般（VXLAN） 更好（BGP 无隧道）
策略支持 无 有
复杂度 低 中高
生产推荐 简单业务 主流生产环境
3. 网络性能进阶
  • IPIP / VXLAN 有封装损耗
  • BGP 无隧道，性能最高
  • Calico 可做：限流、黑名单、流量监控
4. 架构总结
  • 存储：PV/PVC/CSI → 数据持久化
  • 网络：Flannel/Calico → Pod 互通
  • 网络策略：Calico 提供 → 安全隔离
极简一句话总结
  • 存储：让容器数据不丢失
  • Flannel：简单打通容器网络
  • Calico：高性能网络 + 安全访问控制

  • 高可用、升级、备份、故障排查

一、基础认知

1. 高可用（HA）

保证 K8s 控制平面不宕机，业务不中断。

  • 多 Master 节点：apiserver、scheduler、controller-manager
  • 多 etcd 节点（Raft 分布式强一致）
  • 外部负载均衡（LB）统一入口
  • 核心：无单点
2. 升级

安全、平滑更新 K8s 版本，不影响业务。

  • 先升级控制平面，再升级节点
  • 小版本跨 1 个，大版本逐阶段升
  • 核心：先备份、分批升、不跳版
3. 备份

防止数据丢失，只需要备份 etcd。

  • K8s 所有状态都存在 etcd
  • 备份 = 快照
  • 恢复 = 用快照重建集群
  • 核心：etcd 就是全部
4. 故障排查

按固定路径定位：集群健康 → 控制平面 → 网络 → 存储 → Pod 日志 → 事件

二、核心配置

1. 高可用配置
  • Master ≥ 3 节点（奇数）
  • etcd ≥ 3 节点
  • kube-apiserver 前置 LB（四层）
  • scheduler、controller-manager 多实例自动抢占
  • 组件以 static pod / 系统服务 运行
2. 升级配置
  • 工具：kubeadm
  • 版本规则：
    • 小版本：1.28 → 1.29 → 1.30
    • 不可跨大版本跳升
  • 节点分批升级，先驱逐再升级
3. 备份配置
  • etcd 快照：

    bash

    运行

    etcdctl snapshot save
  • 定期自动备份
  • 备份文件离线存储
4. 排查常用命令

bash

运行

kubectl get nodes
kubectl get pods -n kube-system
kubectl describe pod <pod>
kubectl logs <pod>
journalctl -u kubelet
etcdctl endpoint health

三、实操场景

场景 1：搭建高可用集群（kubeadm）
  1. 准备 LB → 多 Master、多 etcd
  2. 初始化第一个 Master
  3. 加入其他 Master 节点
  4. 加入 Node 节点
  5. 验证组件全正常
场景 2：安全升级集群
  1. 备份 etcd
  2. 升级 kubeadm
  3. 升级控制平面
  4. 升级 kubectl、kubelet
  5. 逐节点升级、重启 kubelet
场景 3：灾难恢复（etcd 恢复）
  1. 停掉所有控制平面组件
  2. 用快照恢复 etcd
  3. 重启组件
  4. 检查集群状态
  5. 恢复业务
场景 4：Pod 无法启动标准排查
  1. Pod 状态：Pending / Running / Crash
  2. describe 看事件
  3. 看日志：配置 / 依赖 / 端口
  4. 检查网络、存储是否正常
  5. 检查节点资源、kubelet 状态

四、进阶扩展

1. 高可用进阶
  • etcd 必须奇数节点：3、5、7
  • Raft 协议：半数以上在线即可用
  • apiserver 无状态可水平扩展
  • 生产必须：多 AZ + 异地容灾
2. 升级进阶
  • 升级前检查：
    • 弃用 API
    • 插件兼容性（CNI、CSI、Ingress）
  • 核心原则：先测试环境，再生产；先节点，再控制面
3. 备份进阶
  • 只备份 etcd 就够恢复整个集群
  • 建议：
    • 每日自动快照
    • 跨机器 / 跨区域存储
  • 不备份节点本地数据，只备份状态
4. 故障排查进阶（黄金流程）
  1. 集群是否健康？
  2. 控制平面是否全活？
  3. 网络插件是否正常？
  4. Pod 是否调度成功？
  5. 容器是否启动？
  6. 服务 / Service/Ingress 是否通？

极简一句话总结

  • 高可用：多 Master + 多 etcd+LB，无单点
  • 升级：先备份、逐版本、分批升
  • 备份：只备份 etcd，快照即可恢复
  • 排查：从集群→组件→网络→存储→Pod 逐级查

3. K8s 高级架构与运维体系

  • 集群规划、多租户、RBAC、安全策略

一、基础认知

1. 集群规划

根据业务规模、环境、安全、成本，提前设计：

  • 节点规模、角色划分（Master/Node/ 监控 / 存储）
  • 网络、存储、组件版本
  • 高可用、容灾、扩容方案

一句话：集群怎么建、怎么分、怎么用最稳。

2. 多租户

让多个团队 / 业务 / 项目共用同一套 K8s 集群，互不干扰。核心手段：Namespace + 资源配额 + RBAC + 网络隔离。

一句话：一套集群，多团队安全共用。

3. RBAC（基于角色的访问控制）

K8s 内置的权限体系，控制 “谁能对什么资源做什么操作”。核心四件套：

  • User/ServiceAccount：谁
  • Role：权限集合
  • RoleBinding：把权限绑给人
  • ClusterRole / ClusterRoleBinding：集群级权限

一句话：最小权限，只给需要的。

4. 安全策略

通过各种机制加固集群，防止越权、逃逸、漏洞利用：

  • Pod 安全标准
  • 网络策略
  • 镜像安全
  • 特权禁止、只读文件系统、非 root 运行

一句话：把容器 “关在笼子里”。

二、核心配置

1. 集群规划核心
  • 节点角色：
    • Master：3 节点奇数高可用
    • Worker：按业务分组（网关、应用、大数据、GPU）
  • 网络：Pod 网段、Service 网段、不与主机冲突
  • 资源规划：
    • CPU / 内存 request/limit 规范
    • 节点数量、弹性扩容
  • 版本：稳定版，不追新
2. 多租户核心
  • 以 Namespace 为租户边界
  • ResourceQuota：限制 CPU / 内存 / PVC 数量
  • LimitRange：限制单个 Pod 资源上下限
  • NetworkPolicy：租户间网络隔离
3. RBAC 核心

yaml

# 1. 角色：只能读 pod
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

# 2. 绑定给 sa
kind: RoleBinding
subjects:
- kind: ServiceAccount
  name: reader
roleRef:
  kind: Role
  name: pod-reader
  • 常用 verbs：get list watch create delete
  • 最小权限：只给业务需要的
4. 安全策略核心
  • Pod 安全标准（PSA）：
    • Privileged（宽松）
    • Baseline（默认）
    • Restricted（最严格）
  • 安全上下文：
    • runAsNonRoot: true
    • readOnlyRootFilesystem: true
    • capabilities: drop: ["ALL"]
  • 禁止 latest 标签、禁止特权容器

三、实操场景

场景 1：按团队做集群规划 + 多租户
  • team-a、team-b 各一个 Namespace
  • 各配 ResourceQuota：

    yaml

    resourcequotas:
  requests.cpu: 10
  requests.memory: 20Gi
  • 互相 NetworkPolicy 不通
  • 各自 RBAC 只能操作自己空间
场景 2：给开发配置 “只看权限”
  • 创建 ServiceAccount
  • 创建只读 Role（pod、svc、log）
  • RoleBinding 绑定
  • 开发只能查看、不能删改
场景 3：给 CI/CD 配置有限部署权限
  • 只允许操作 Deployment、Service、Ingress
  • 不能操作 Node、Secret、RBAC
  • 限制在单个 Namespace
场景 4：强制安全策略
  • 命名空间开启 Restricted 模式
  • 禁止特权启动
  • 强制非 root、只读根文件系统
  • 不符合策略的 Pod 直接拒绝创建

四、进阶扩展

1. 集群规划进阶
  • 多 AZ 高可用：节点跨可用区，Pod 打散
  • 节点亲和 / 污点：按业务类型隔离部署
  • 集群伸缩：Cluster Autoscaler / Karpenter
  • 生产禁忌：控制平面与业务混部
2. 多租户进阶
  • 企业级多租户：
    • 物理集群隔离（最高安全）
    • 虚拟集群（vCluster）轻量隔离
  • 资源超卖与保证
  • 租户监控、计费、审计
3. RBAC 进阶
  • 聚合角色：把多个小权限拼成一个角色
  • 禁止直接使用 cluster-admin
  • 所有账号使用 ServiceAccount 而非证书用户
  • 权限定期审计，清理无用权限
4. 安全策略进阶
  • 安全全链路：
    • 镜像签名与验证
    • 镜像漏洞扫描
    • seccomp / apparmor
    • 审计日志审计
  • 零信任：默认拒绝所有流量，按需放行
  • 防止：容器逃逸、挂载 docker.sock、提权

极简总结（可直接背诵）

  • 集群规划：定规模、分角色、划网络、做高可用
  • 多租户：Namespace + 配额 + 网络隔离，多团队共用
  • RBAC：人 - 角色 - 权限绑定，最小权限原则
  • 安全策略：限制 Pod 权限、禁止越权、加固运行环境

  • 监控（Prometheus）、日志（ELK/Loki）、链路追踪

一、基础认知

1. 监控（Prometheus 栈）

监控 = 看指标（Metrics）：CPU、内存、QPS、延迟、连接数等

  • Prometheus：拉取、存储、查询时序指标
  • Exporter：暴露指标（node-exporter、kube-state-metrics）
  • Grafana：可视化仪表盘
  • AlertManager：告警、去重、分发

一句话：看集群和应用 “现在 / 过去运行得怎么样”

2. 日志（ELK / Loki）

日志 = 看文本记录：程序 stdout、错误、访问日志

  • ELK：Elasticsearch 存储 + Logstash 采集 + Kibana 展示
  • Loki：轻量日志，只索引标签，日志内容存对象存储
  • Filebeat/fluent-bit：在节点采集容器日志

一句话：出问题时查 “发生了什么、为什么错”

3. 链路追踪（分布式追踪）

追踪 = 看一次请求全流程：经过哪些服务、哪一步慢 / 错

  • 工具：Jaeger、Zipkin、SkyWalking
  • 核心：TraceID 贯穿整个调用链
  • 展示：拓扑、耗时分布、异常节点

一句话：微服务下 “定位谁慢、谁错、卡在哪”

二、核心配置

1. Prometheus 监控核心
  • 任务拉取：scrape_configs 抓指标
  • 服务发现：
    • kubernetes_sd_configs（自动发现 Pod/Node/Service）
  • 告警规则：expr 表达式判断异常
  • 存储：本地磁盘 / 远程存储（Thanos/Mimir）
  • 常用指标：
    • 节点：node_load1、node_memory_usage
    • 容器：container_cpu_usage_seconds_total
    • 服务：kube_pod_status_ready
2. 日志核心配置

Fluent-Bit + Loki（轻量）

  • 采集：DaemonSet 每节点跑一个
  • 采集目标：/var/log/containers/*.log
  • 标签：namespace、pod、app、container
  • 查询：LogQL 过滤日志
  • 展示：Grafana

ELK

  • 采集：Filebeat → Kafka → Logstash → ES
  • 索引按天分割
  • Kibana 搜索 / 可视化 / 告警
3. 链路追踪核心
  • 接入方式：
    • 代码埋点（SDK）
    • 服务网格自动注入（Istio）
  • 数据模型：
    • Trace：一次完整请求
    • Span：一个环节 / 调用
    • Span 包含：耗时、标签、日志、错误
  • 存储：ES / 内存 / Cassandra

三、实操场景

场景 1：集群 & 业务监控
  • node-exporter 看节点负载
  • kube-state-metrics 看 Pod 状态
  • 业务暴露 /actuator/prometheus 或 /metrics
  • Grafana 做面板：
    • 节点资源
    • Pod 运行状态
    • API 耗时、错误率
  • AlertManager 发到企业微信 / 钉钉 / 邮件
场景 2：容器日志统一检索
  • 所有容器 stdout 自动采集
  • 按 namespace、pod、app 过滤
  • 搜索关键词：error、exception、panic
  • 搭配告警：日志出现 ERROR 就报警
场景 3：微服务调用链定位
  • 前端 → 网关 → 用户服务 → 订单服务
  • 一个 TraceID 串起全程
  • 定位：
    • 哪个服务耗时最长
    • 哪次 DB/Redis 慢
    • 哪段返回 500/4xx

四、进阶扩展

1. 监控进阶
  • 高可用 Prometheus：双副本 + Thanos/Mimir
  • 自动发现：基于 annotation 自动抓取
  • 自定义业务指标：订单量、支付成功率
  • 成本监控：按 namespace / 团队 统计资源消耗
2. 日志进阶
  • 日志结构化：JSON 格式，方便检索
  • 日志分级：info/warn/error 分开告警
  • 日志裁剪：避免大日志占存储
  • 冷热存储：近期存高速，历史归档
3. 链路追踪进阶
  • 采样率：高并发只采部分，减少开销
  • 服务网格无侵入：Istio 自动生成 Span
  • 和监控 / 日志联动：
    • 从 Grafana 面板 → 跳追踪
    • 从日志 TraceID → 跳调用链

极简总结（可直接背诵）

  • 监控（Prometheus）：看指标、看状态、做告警
  • 日志（ELK/Loki）：查文本、查错误、查现场
  • 链路追踪：看调用、看耗时、定位微服务瓶颈
  • 三者合一 = K8s 可观测性

  • CI/CD 流水线：GitLab CI / Jenkins / ArgoCD

一、基础认知

1. 什么是 K8s CI/CD
  • CI（持续集成）：代码提交 → 编译 → 测试 → 构建镜像 → 推仓库
  • CD（持续部署）：把镜像自动 / 半自动发布到 K8s
  • 目标：代码一提交，自动上线到 K8s
2. 三个工具定位
  • Jenkins：老牌通用 CI/CD 引擎，插件极多，功能最强但重
  • GitLab CI：内置在 GitLab 里，配置简单、开箱即用，现代主流
  • ArgoCD：K8s 原生 CD 工具，专注 “把配置发布到集群”，属于声明式 GitOps

一句话区分：Jenkins / GitLab CI 负责 “造镜像”，ArgoCD 负责 “把应用发布到 K8s”。

3. GitOps 核心思想
  • 一切配置存在 Git（Deployment/Service/ConfigMap…）
  • Git 是唯一真实来源
  • ArgoCD 自动同步 Git → K8s
  • 可回溯、可审计、可回滚

二、核心配置

1. Jenkins 核心（CI+CD）
核心组件
  • Master + Agent（K8s 动态弹性 Agent）
  • Pipeline：Jenkinsfile
  • 插件：Git、Maven、Nodejs、Docker、K8s
典型流水线阶段
  1. 拉代码
  2. 编译 / 单元测试
  3. 构建镜像
  4. Push 镜像仓库
  5. 更新 K8s YAML 镜像版本
  6. 调用 kubectl 或 ArgoCD 发布
关键配置
  • agent { kubernetes {} } 动态调度构建机
  • 凭证管理（Git、Docker 仓库、K8s）
  • 触发方式：Webhook / 定时 / 手动
2. GitLab CI 核心（CI+CD）
核心配置文件
  • 项目根目录：.gitlab-ci.yml
核心概念
  • Stage：阶段（build → test → deploy）
  • Job：具体任务
  • Runner：执行器（可部署在 K8s 里）
  • Artifact：构建产物
  • Cache：依赖缓存
典型流程
  1. build：编译打包
  2. test：自动化测试
  3. build-image：构建 Docker 镜像
  4. push：推送到镜像仓库
  5. deploy：更新 K8s
关键配置

yaml

stages:
  - build
  - test
  - build_image
  - deploy

build_image:
  stage: build_image
  image: docker:24-dind
  script:
    - docker build -t xxx .
    - docker push xxx
3. ArgoCD 核心（纯 CD，GitOps）
核心概念
  • Application：一个 K8s 应用（对应 Git 目录）
  • Project：分组、权限隔离
  • Repo：Git 仓库地址
  • Sync：把 Git 同步到 K8s
  • Revision：版本、回滚依据
工作模式
  • Watch Git 仓库
  • 对比 Git 与 K8s 实际状态
  • 自动 / 手动同步
  • 可视化、健康检查、自动回滚
关键配置（Application YAML）

yaml

apiVersion: argoproj.io/v1alpha1
kind: Application
spec:
  project: default
  source:
    repoURL: https://gitlab.com/xxx/xxx.git
    targetRevision: main
    path: k8s/overlays/prod
  destination:
    server: https://kubernetes.default.svc
    namespace: prod
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

三、实操场景（最真实企业流水线）

场景 1：传统 Jenkins CI/CD 发布到 K8s
  1. 开发者提交代码
  2. Jenkins 触发构建
  3. 编译 → 构建镜像 → Push
  4. Jenkins 直接执行 kubectl set image 发布
  5. 查看发布结果

优点：灵活缺点：发布逻辑在 Jenkins，无统一状态、难回滚、难审计

场景 2：GitLab CI 全流程（中小团队最爱）
  1. 代码放 GitLab
  2. .gitlab-ci.yml 定义全流程
  3. 自动构建、测试、打包镜像
  4. CI 里直接用 kubectl / helm 部署到 K8s
  5. 内置看板、日志、状态

优点：不用额外部署 Jenkins，开箱即用缺点：复杂 CD 能力弱

场景 3：GitLab CI + ArgoCD（现代云原生标准）

CI 做构建，CD 做发布，职责分离

  1. GitLab CI：
    • 拉代码
    • 编译测试
    • build & push 镜像
    • 修改 K8s YAML 里的镜像标签，提交回 Git
  2. ArgoCD：
    • 检测到 Git 变化
    • 自动同步到 K8s
    • 展示发布进度、健康状态
    • 一键回滚

这是目前生产最标准架构。

场景 4：多环境发布（dev/test/prod）
  • Git 目录结构：

    plaintext

    k8s/
  base/
  overlays/
    dev/
    test/
    prod/
  • ArgoCD 创建 3 个 Application
  • 代码合并到不同分支 → 更新对应 overlay → 自动发布对应环境
  • 权限、资源、网络完全隔离

四、进阶扩展

1. Jenkins 进阶
  • K8s 动态 Agent：按需创建构建机，用完销毁
  • 流水线作为代码（Pipeline as Code）
  • 共享库（Shared Library）统一公司所有项目模板
  • 与 SonarQube、漏洞扫描、制品库集成
  • 缺点：重、耗资源、配置复杂
2. GitLab CI 进阶
  • 配合 GitLab Runner on K8s
  • 缓存加速（node_modules、m2 仓库）
  • 触发规则：only/except/rules
  • 内置容器扫描、依赖扫描、安全门禁
  • 适合：云原生、中小团队、Java/Go/ 前端
3. ArgoCD 进阶（GitOps 高级）
  • SyncWindow：发布时间窗口控制
  • PreSync / Sync / PostSync 发布钩子
  • 多集群管理：一个 ArgoCD 管 N 个 K8s
  • Helm / Kustomize / Jsonnet 全支持
  • SSO 集成 + RBAC 多租户
  • 自动回滚：健康检查失败自动复原
4. 整体架构对比
  • Jenkins：全能、重、适合复杂企业场景
  • GitLab CI：简单、轻量、一体化、中小团队首选
  • ArgoCD：K8s 原生 CD、GitOps、必须搭配 CI 使用
5. 企业级最佳实践
  1. CI：GitLab CI / Jenkins
  2. 镜像仓库：Harbor
  3. 配置存储：Git（GitOps）
  4. CD：ArgoCD
  5. 环境：dev/test/prod 多套 K8s
  6. 安全：镜像扫描、权限最小、发布审核

极简总结（可直接背诵）

  • Jenkins：老牌全能 CI/CD，重但插件生态极强
  • GitLab CI：内置在 GitLab，简单轻量，现代主流 CI
  • ArgoCD：K8s 原生 GitOps CD，专注同步 Git → 集群
  • 最佳组合：GitLab CI 做构建 + ArgoCD 做发布

  • 运维自动化、Helm、Operator

一、基础认知

1. 运维自动化（K8s 自动化体系）

把重复、人工、易错的运维操作变成自动执行的标准化流程。

在 K8s 里，自动化主要包括：

  • 集群自动化部署（kubeadm、kubespray、sealos）
  • 节点自动扩缩容（Cluster Autoscaler、Karpenter）
  • 应用自动发布、回滚、自愈
  • 配置自动下发、更新
  • 监控、告警、故障自愈
  • 备份、恢复、升级自动化

一句话：人少干活，系统多干活，一切可重复、可回溯、可批量。

2. Helm —— K8s 包管理器

Helm = K8s 里的 apt /yum/npm。

作用：

  • 把一堆 YAML（Deployment、Service、Ingress、ConfigMap…）打包成 Chart
  • 统一安装、升级、卸载、配置管理
  • 支持多环境、多版本、依赖管理

三大概念：

  • Chart：应用包（模板 + 配置）
  • Values：给模板传参
  • Release：安装后的实例

一句话：用一条命令，部署一套完整应用。

3. Operator —— K8s 业务自动化框架

Operator = 运行在 K8s 里的 “自动化运维专家”。

核心思想：把人类运维经验，变成代码，交给 K8s 自己执行。

能力：

  • 自动化部署有状态应用（MySQL、Redis、ES、Kafka）
  • 自动主从切换、扩容、缩容、备份、修复
  • 深度感知应用状态，做 K8s 原生做不了的事

本质：

  • CRD + Controller
  • 自定义 API + 自定义控制逻辑

一句话：Operator 让 K8s 会 “懂业务、会运维”。

二、核心配置

1. 运维自动化核心

自动化对象

  • 集群生命周期：安装、扩容、升级、证书轮换
  • 节点：上下线、污点、调度、重启
  • 应用：发布、扩缩容、重启、回滚
  • 配置：ConfigMap/Secret 热更新
  • 存储：PVC 自动扩容、备份、清理

常用工具

  • Ansible：配置管理、批量运维
  • kubeadm：集群安装、升级
  • Kustomize/Helm：应用批量管理
  • ArgoCD：GitOps 自动发布
  • Prometheus+AlertManager+Webhook：告警自愈

自动化原则

  • 声明式，不面向过程
  • 幂等：执行多少次结果一样
  • 可审计、可回滚
  • 最小权限

2. Helm 核心配置

Chart 目录结构

plaintext

mychart/
  Chart.yaml          # 版本、描述
  values.yaml         # 默认配置
  templates/
    deployment.yaml   # 模板
    service.yaml
    ingress.yaml
    _helpers.tpl      # 工具函数

模板语法（Go Template）

yaml

image: {{ .Values.image.repository }}:{{ .Values.image.tag }}

常用命令

bash

运行

helm install  releaseName ./chart   # 安装
helm upgrade releaseName ./chart    # 升级
helm rollback  releaseName revision # 回滚
helm uninstall releaseName          # 卸载
helm repo add                       # 添加仓库

核心能力

  • Values 覆盖：不同环境用不同 value
  • 依赖管理：自动安装依赖 Chart
  • Hook：安装前 / 后执行任务
  • 模板函数：变量、判断、循环

3. Operator 核心配置

基础组件

  • CRD：自定义资源类型

    yaml

    kind: CustomResourceDefinition
name: mysqls.database.example.com
  • CR：自定义资源实例

    yaml

    apiVersion: database.example.com/v1
kind: MySQL
metadata:
  name: my-db
spec:
  replicas: 3
  passwordSecret: mysql-secret
  • Controller：监听 CR，执行业务逻辑

开发框架

  • OperatorSDK（RedHat）
  • Kubebuilder（K8s 官方）

典型能力配置

  • 自动集群化（主从 / 主备）
  • 自动备份
  • 自动故障切换
  • 扩缩容、配置滚动更新
  • 监控、告警规则自动生成

三、实操场景

场景 1：用 Helm 一键部署中间件

一条命令部署 Redis / MySQL / ES / Kafka

bash

运行

helm install redis bitnami/redis
helm install mysql bitnami/mysql
  • 开发环境秒起中间件
  • 测试 / 生产通过 values.yaml 定制：
    • 资源限制
    • 副本数
    • 存储、密码、端口
    • 亲和性、安全策略

场景价值：标准化、可复用、少写 YAML。

场景 2：多环境应用发布（dev/test/prod）
  • 一套 Chart，多套 Values

    plaintext

    env/
  values-dev.yaml
  values-test.yaml
  values-prod.yaml
  • 部署命令：

    bash

    运行

    helm install myapp ./chart -f values-prod.yaml
  • 统一模板，环境差异化配置
场景 3：用 Operator 运维有状态应用

以 MySQL Operator 为例：

  1. 部署 CRD + Operator
  2. 创建一个 MySQL CR：

    yaml

    apiVersion: mysql.example.com/v1
kind: MySQL
spec:
  replicas: 3
  storage: 10Gi
  3. Operator 自动：
    • 创建 StatefulSet、Service、Secret
    • 配置主从复制
    • 自动故障切换
    • 自动备份
    • 自动扩缩容

人只需要声明 “我要什么”，Operator 负责 “怎么做到”。

场景 4：企业级运维自动化平台
  • Ansible 批量初始化节点、部署 K8s
  • Helm 统一管理所有应用包
  • ArgoCD 自动同步 Git → 集群
  • Operator 管理数据库、消息队列、缓存
  • Prometheus 告警触发自愈：
    • 节点宕机 → 自动驱逐 Pod
    • 服务异常 → 自动重启
    • 资源不足 → 自动扩容

四、进阶扩展

1. 运维自动化进阶

自愈自动化（Auto-Repair）

  • 节点不健康 → 自动隔离、重建

  • Pod 反复崩溃 → 自动重启、迁移

  • 存储异常 → 自动重挂载

弹性自动化

  • Cluster Autoscaler：节点自动扩缩容

  • HPA：Pod 自动扩缩容

  • VPA：自动调整资源 request/limit

零停机升级

  • 控制平面平滑升级

  • 业务滚动更新 + 健康检查

  • 自动回滚机制

合规与安全自动化

  • 镜像扫描、准入控制

  • 权限自动审计、违规自动修复

  • 配置基线自动检查

2. Helm 进阶

企业级最佳实践

  • Chart 仓库：使用 ChartMuseum / Harbor

  • CI/CD 集成：自动打包、测试、推送 Chart

  • Chart 测试：安装后自动验证服务可用性

  • Chart 签名：防止篡改

高级特性

  • Library Chart：公共模板抽离，复用逻辑

  • PostRender：结合 Kustomize 二次修改

  • Lookup：运行时查询集群资源

与 GitOps 结合

  • Chart 放在 Git

  • ArgoCD 监听 Git，自动同步

  • 版本、回滚、审计全部托管

3. Operator 进阶

Operator 成熟度模型

  1. 基本安装 → 2. 自动化生命周期 → 3. 全生命周期管理 → 4. 自动洞察 / 优化

有状态服务核心

  • 稳定网络、稳定存储、有序部署

  • 主从选举、数据同步、备份恢复

  • 不丢失数据、不脑裂

Operator vs Helm

  • Helm：安装、升级、卸载（静态打包）

  • Operator：7×24 小时自动化运维（动态运行）

生态

  • Strimzi：Kafka Operator

  • Prometheus Operator

  • Elasticsearch Operator

  • Redis Operator

  • Rook：Ceph 存储 Operator

极简总结（可直接背诵）

  • 运维自动化：把人工运维变成 K8s 可执行的标准化流程，包括部署、发布、自愈、扩缩容。
  • Helm：K8s 包管理器，打包 YAML，一键安装 / 升级 / 卸载，多环境统一管理。
  • Operator：CRD + Controller，把运维经验代码化，实现有状态应用全自动生命周期管理。

4. 云原生网络与存储架构

  • CNI 网络模型、Service Mesh（Istio/Linkerd）

一、基础认知

1. K8s CNI 网络模型

CNI（Container Network Interface）是K8s 容器网络标准，负责给 Pod 分配 IP、实现通信。

K8s 网络三大基本原则（面试必考）
  1. 每个 Pod 拥有独立 IP（不与容器共享）
  2. Pod 之间可以直接通信，不管在不在同一节点
  3. 节点与 Pod 之间可以直接通信
CNI 解决什么
  • 节点之间 Pod 互通
  • 网络隔离、策略控制
  • 集群内外流量转发
  • 性能、隧道、路由策略
常见 CNI
  • Flannel：简单、只负责互通
  • Calico：生产主流，三层路由 + NetworkPolicy
  • Canal：Flannel + Calico 策略
  • Weave：轻量、自动组网
  • Cilium：基于 eBPF，高性能、安全、可观测

一句话：CNI 是 K8s 的 “网络底盘”，决定 Pod 怎么通、快不快、安不安全。

2. Service Mesh（服务网格）
服务网格 = 微服务之间的通信治理基础设施。

解决微服务落地后的一堆问题：

  • 流量控制：路由、灰度、重试、超时、熔断
  • 安全：mTLS 加密、权限、身份
  • 可观测： metrics、日志、追踪
  • 无侵入：不用改业务代码、不绑定语言
核心架构
  • 数据面（Data Plane）：Sidecar 代理（Envoy/Linkerd2 Proxy）
  • 控制面（Control Plane）：统一配置、证书、服务发现
主流产品
  • Istio：功能最全、生态最强、企业标准
  • Linkerd：轻量、高性能、简单、性能损耗低

一句话：Service Mesh 让微服务 “通信、治理、安全、可观测” 全部下沉到基础设施。

二、核心配置

1. CNI 网络模型核心
1）网络组成
  • Pod 网络：Pod 所在网段
  • Service 网络：虚拟 IP，仅集群内部访问
  • 节点网络：宿主机所在物理网络
2）Flannel 核心模式
  • VXLAN：隧道封装，配置最简单，通用
  • Host-Gateway：直接路由，性能更高，要求二层互通
3）Calico 核心模式
  • VXLAN：通用、跨云
  • IPIP：简单跨节点
  • BGP：无隧道、性能最高，物理机 / IDC 首选
4）NetworkPolicy（网络策略）

通过 CNI 实现：

  • 允许 / 禁止 Pod 之间访问
  • 按命名空间、标签、端口控制
  • 生产环境安全基础

示例：

yaml

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: frontend
2. Service Mesh 核心（以 Istio 为例）
1）核心资源
  • Gateway：集群入口网关（替代 Ingress）
  • VirtualService：流量路由、超时、重试、重写
  • DestinationRule：熔断、连接池、版本子集
  • PeerAuthentication：mTLS 全局加密
  • AuthorizationPolicy：服务访问权限
  • Sidecar：限制服务访问范围
2）流量治理配置
  • 灰度发布：权重路由
  • 超时重试：避免级联故障
  • 熔断：异常节点隔离
  • 流量镜像：复制流量做测试
3）安全配置
  • 自动 mTLS
  • 服务身份与证书
  • 细粒度权限：谁能调用谁
4）可观测
  • 指标：成功率、延迟、流量
  • 分布式追踪
  • 访问日志

三、实操场景

场景 1：生产 CNI 选型与部署
  • 测试 / 简单集群：Flannel
  • 生产通用：Calico（VXLAN/BGP）
  • 高性能 / 云原生新架构：Cilium（eBPF）

部署后验证：

bash

运行

# 节点间 Pod 互通
kubectl run test --image=busybox --rm -it -- ping <podIP>
场景 2：开启 NetworkPolicy 实现租户隔离
  • 不同命名空间不能互相访问
  • 数据库只允许业务 Pod 访问
  • 只开放指定端口

效果：Pod 默认不通，按需放行，零信任基础。

场景 3：Istio 实现无侵入灰度发布

yaml

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
spec:
  http:
  - route:
    - destination:
        host: order
        subset: v1
      weight: 90
    - destination:
        host: order
        subset: v2
      weight: 10
  • 业务代码0 改动
  • 10% 流量到新版本
  • 监控异常一键回滚
场景 4：全站自动 mTLS 加密

yaml

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
spec:
  mtls:
    mode: STRICT
  • 服务间流量自动加密
  • 防止抓包、窃听、伪造
  • 证书自动签发、轮换
场景 5：全链路可观测
  • 服务拓扑图
  • 实时成功率、延迟、QPS
  • 分布式追踪定位慢调用业务 0 代码侵入

四、进阶扩展

1. CNI 网络进阶

1）性能对比

  • BGP > VXLAN/IPIP（无隧道损耗）

  • Cilium eBPF：比 iptables 更高性能

2）K8s Service 实现

  • kube-proxy iptables：通用

  • ipvs：高并发 Service

  • eBPF：Cilium 替代 kube-proxy

3）网络排障核心

  • 查路由：ip route

  • 查策略：calicoctl get networkpolicy

  • 查连通性：traceroute、tcpdump

  • 查 DNS：nslookup

4）双栈、IPv6、跨集群网络

  • CNI 支持 IPv4/IPv6

  • 跨集群通信：Submariner、Istio Multi-Cluster

2. Service Mesh 进阶

1）Istio vs Linkerd

  • Istio：功能全、灵活、重、学习成本高

  • Linkerd：轻、快、简单、资源占用极低

2）Sidecar 注入原理

  • 通过 Mutating Webhook 自动注入

  • iptables 劫持流量

  • 对业务完全透明

3）性能与损耗

  • 延迟增加 1~3ms

  • 换取：治理、安全、可观测

  • 高并发场景可调：并发、超时、缓存

4）生产最佳实践

  • 先开启监控 + 日志

  • 再开启mTLS

  • 灰度发布先小流量验证

  • 网络策略默认拒绝 + 按需放开

5）下一代服务网格

  • Ambient Mesh：无 Sidecar，节点级代理

  • eBPF 网格：更低损耗、更高性能

极简总结（可直接背诵）

  • CNI：K8s 网络底盘，负责 Pod IP、互通、策略，主流 Calico/Cilium。
  • Service Mesh：微服务通信治理层，通过 Sidecar 做路由、安全、可观测。
  • Istio：功能最全，企业生产标准。
  • Linkerd：轻量高性能，简单场景首选。
  • 关系：CNI 保证 “能通”，Service Mesh 保证 “通得安全、通得可控”。

  • 存储架构：CSI、LocalPV、分布式存储

一、基础认知

1. K8s 存储整体架构

K8s 要解决：容器数据持久化、共享、动态供给、迁移安全。

核心三层抽象：

  • Volume：容器内挂载目录
  • PersistentVolume (PV)：集群中的一块存储空间
  • PersistentVolumeClaim (PVC)：Pod 对存储的 “申请单”

上层使用统一接口，底层对接各种存储实现。

2. CSI（Container Storage Interface）

CSI = K8s 存储插件标准接口。

作用：

  • 让各家存储厂商（云厂商、分布式存储、本地存储）独立开发插件
  • 不侵入 K8s 核心代码
  • 支持：挂载、卸载、扩容、快照、克隆、拓扑感知

一句话：CSI 是 K8s 存储的 “驱动标准”，所有现代存储都基于 CSI。

3. LocalPV（本地存储）

LocalPV = 直接使用节点本地磁盘 / 目录的 PV。

特点：

  • 数据在当前节点本地
  • 低延迟、高吞吐
  • 不支持 Pod 漂移到其他节点
  • 适合：数据库、ES、Kafka、MinIO 等有高 IO 需求的有状态应用

一句话：LocalPV = 本地盘直通 Pod，性能最好，但不漂移。

4. 分布式存储

多台节点组成统一存储池，提供块存储 / 文件存储 / 对象存储。

K8s 常用：

  • 块存储（RBD、EBS、云盘）：PVC 单 Pod 独占
  • 文件存储（NFS、CephFS、 JuiceFS）：多 Pod 共享读写
  • 对象存储（S3、MinIO）：通过 CSI 或 SDK 使用

特点：

  • 数据多副本、高可靠
  • 支持 Pod 跨节点漂移
  • 生产环境标准持久化方案

一句话：分布式存储 = 共享、高可用、可漂移，生产标配。

二、核心配置

1. CSI 存储架构核心
组件
  • CSI Driver：厂商提供的存储驱动
  • External Provisioner：负责创建 PV
  • External Attacher：负责挂载磁盘到节点
  • External Resizer：负责在线扩容
  • External Snapshotter：负责快照
核心流程
  1. 用户创建 PVC
  2. CSI Provisioner 自动创建 PV
  3. 调度后，CSI Attacher 挂载磁盘到节点
  4. kubelet 挂载到 Pod
StorageClass（动态供给）

yaml

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: csi-sc
provisioner: rook-ceph.rbd.csi.ceph.com
parameters:
  clusterID: default
  pool: replicapool
reclaimPolicy: Delete
allowVolumeExpansion: true  # 允许扩容
2. LocalPV 核心
特点
  • 必须手动创建 PV 或用 LocalPV Provisioner
  • 调度器会把 Pod 固定在对应节点
  • 只能被同一节点的 Pod 使用
PV 示例

yaml

apiVersion: v1
kind: PersistentVolume
metadata:
  name: local-pv-1
spec:
  capacity:
    storage: 50Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: local-storage
  local:
    path: /dev/sdb1  # 本地磁盘
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: kubernetes.io/hostname
          operator: In
          values:
          - node-1
3. 分布式存储核心（以 Ceph 为例）
三种提供方式
  1. RBD 块存储：ReadWriteOnce（MySQL、PostgreSQL）
  2. CephFS 文件存储：ReadWriteMany（多 Pod 共享）
  3. 对象存储：S3 接口
生产关键配置
  • 副本数：3 副本
  • 自动扩容
  • 快照与备份
  • 存储策略：SSD/HDD 分层
  • 故障域：按机架 / 节点 / 机柜

三、实操场景

场景 1：动态供给 PVC（最常用）
  1. 创建 StorageClass
  2. 创建 PVC 不指定 PV
  3. CSI 自动创建 PV 并绑定
  4. Pod 直接使用 PVC

yaml

apiVersion: v1
kind: PersistentVolumeClaim
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 20Gi
  storageClassName: csi-sc
场景 2：数据库使用 LocalPV 高性能
  • MySQL / PostgreSQL / Kafka
  • 高 IO、低延迟需求
  • 用 Operator + LocalPV
  • 数据不跨节点，但性能接近物理机

适合：对性能敏感、自身有高可用机制的中间件。

场景 3：多副本、可迁移用分布式存储
  • 应用不保证同节点启动
  • 需要跨节点漂移
  • 数据必须高可用

使用：

  • Ceph RBD
  • 云厂商 EBS / 云盘
  • CSI 自动挂载 / 卸载
场景 4：多 Pod 共享文件存储
  • 上传附件、日志、静态资源
  • 多副本同时读写

使用：

  • NFS
  • CephFS
  • JuiceFS

yaml

accessModes:
  - ReadWriteMany
场景 5：PVC 在线扩容（CSI 必备）
  1. StorageClass 开启 allowVolumeExpansion: true
  2. 修改 PVC storage: 30Gi
  3. CSI 自动扩容文件系统
  4. 无需重启 Pod

四、进阶扩展

1. CSI 进阶

高级能力

  • 卷快照 / 恢复

  • 卷克隆

  • 存储拓扑调度（同可用区 / 同机架）

  • 存储容量监控

  • 加密存储

生产规范

  • 所有存储必须使用 CSI

  • 弃用 in-tree 旧存储插件

  • 统一使用 StorageClass 管理

2. LocalPV 进阶

优势

  • 性能最高、无网络损耗

  • 无分布式存储开销

  • 适合高 IO 中间件

限制

  • 不支持 Pod 漂移

  • 磁盘故障影响数据

  • 必须依赖应用自身高可用

企业方案

  • LocalPV Provisioner 自动发现本地盘

  • 配合 Operator 实现主从切换

  • 按拓扑策略调度

3. 分布式存储进阶（生产级）

Ceph / Rook 最佳实践

  • 独立集群，不与 K8s 混部

  • 三副本、故障域隔离

  • 独立网卡、SSD 作为元数据 / 缓存

  • 自动均衡、自动修复

  • 监控 + 告警 + 容量规划

存储选型口诀

  • 高性能、自身有 HA → LocalPV

  • 通用持久化、要漂移 → 分布式块存储

  • 共享读写 → 文件存储

  • 静态文件、归档 → 对象存储

4. 整体架构总结
  • CSI：统一存储接口，所有现代存储底座
  • LocalPV：本地高性能，不漂移
  • 分布式存储：共享、高可用、可迁移
  • PVC/PV/SC：统一使用方式，对业务透明

极简背诵版（面试直接用）

  • CSI：K8s 存储插件标准，支持动态供给、扩容、快照。
  • LocalPV：节点本地存储，性能最高，Pod 不漂移。
  • 分布式存储：多节点统一存储池，高可用、支持漂移。
  • 生产标配：CSI + 分布式存储，高性能业务用 LocalPV。

  • 网关、负载均衡、南北 / 东西向流量

一、基础认知

1. 南北流量 vs 东西流量（最核心概念）
南北向流量（North-South）
  • 方向：集群外部 ↔ 集群内部
  • 场景：用户 / 外部系统 → 访问 K8s 里的服务
  • 负责组件：LoadBalancer、NodePort、Ingress、Gateway API、云厂商 LB
  • 关键词：入口、网关、外网、域名、SSL 卸载
东西向流量（East-West）
  • 方向：集群内部服务 ↔ 集群内部服务
  • 场景：订单服务 → 用户服务、商品服务 → 库存服务
  • 负责组件：Service、Service Mesh（Istio/Linkerd）、CNI 网络
  • 关键词：服务调用、内部通信、服务发现、灰度、熔断

一句话记忆：进出集群 = 南北；内部互相调用 = 东西。

2. 负载均衡（Load Balancing）

K8s 里有三层负载均衡：

  1. 外部 LB：云厂商 SLB/ELB（南北流量入口）
  2. Service LB：kube-proxy 实现（内部服务 → Pod）
  3. 应用网关 LB：Ingress / Gateway / Service Mesh（七层路由）

作用：

  • 流量分发
  • 故障剔除
  • 扩容无感
3. 网关（Gateway）

Ingress

  • 七层 HTTP/HTTPS 网关

  • 统一入口、域名路由、证书、重写、限流

  • 实现：Nginx Ingress、Traefik、APISIX

Gateway API（下一代）

  • 更强大、更标准化、角色分离

  • 支持 HTTP、TCP、TLS、gRPC

  • 更适合多团队、多租户

Service Mesh Gateway（Istio Gateway）

  • 网格入口网关

  • 统一治理入口流量：路由、限流、mTLS、监控

二、核心配置

1. Service 负载均衡（四层）

类型

  • ClusterIP：默认，仅内部访问

  • NodePort：节点端口暴露

  • LoadBalancer：云厂商负载均衡器

  • ExternalName：外部域名映射

核心原理

  • kube-proxy 使用 iptables/IPVS/eBPF

  • 维护 Service IP → Pod IP 列表

  • 自动负载均衡 & 健康检查

示例

yaml

apiVersion: v1
kind: Service
spec:
  type: ClusterIP
  selector:
    app: myapp
  ports:
  - port: 80
    targetPort: 8080
2. Ingress 网关（七层）

核心能力

  • 基于 host + path 路由

  • SSL 证书卸载

  • 重写、重定向

  • 限流、超时、白名单

示例

yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
spec:
  rules:
  - host: api.xxx.com
    http:
      paths:
      - path: /order
        pathType: Prefix
        backend:
          service:
            name: order
            port:
              number: 80
3. 南北流量入口链路

plaintext

用户 → 云厂商 LB → NodePort/Ingress → Service → Pod
4. 东西流量内部链路

plaintext

Pod A → Service → kube-proxy 负载均衡 → Pod B

使用 Service Mesh 后：

plaintext

Pod A → Sidecar → Sidecar → Pod B

三、实操场景

场景 1：对外提供 HTTPS 域名服务（南北流量）
  1. 部署 Nginx Ingress
  2. 申请证书（cert-manager）
  3. 创建 Ingress 配置域名 + 路由
  4. 域名解析到云厂商 LB
  5. 外部通过 https://api.xxx.com 访问

这是生产最标准入口。

场景 2：内部服务互相调用（东西流量）
  • order-service 调用 user-service
  • 直接使用：

    plaintext

    http://user-service.default.svc.cluster.local
  • K8s DNS 解析
  • Service 自动负载均衡

无需 IP、无需感知副本位置。

场景 3：灰度发布（东西流量）

使用 Istio VirtualService：

yaml

http:
- route:
  - destination:
      host: order
      subset: v1
    weight: 90
  - destination:
      host: order
      subset: v2
    weight: 10
  • 内部流量 10% 到新版本
  • 无感知、不中断业务
场景 4：网关统一限流、白名单（南北）

在 Ingress 上配置：

  • 单 IP 限流
  • 路径限流
  • 内部 / 企业 IP 白名单
  • WAF 防护

保护后端服务不被刷爆。

场景 5：gRPC 入口网关（南北）
  • 使用 Ingress 支持 HTTP/2
  • 或使用 Istio Gateway
  • 支持长连接、流式 gRPC 对外暴露

四、进阶扩展

1. 四层 vs 七层负载均衡
  • 四层（Service）：TCP/UDP，转发快，不解析内容
  • 七层（Ingress/ServiceMesh）：HTTP/gRPC，可路由、重写、限流、监控

南北用七层网关，东西用四层 + 七层治理。

2. kube-proxy 模式对比
  • iptables：通用，默认
  • IPVS：高并发、大规模集群
  • eBPF（Cilium）：高性能、可观测、安全
3. Ingress vs Gateway API vs Istio Gateway
  • Ingress：简单 HTTP 入口，够用但弱
  • Gateway API：K8s 官方下一代，强大标准
  • Istio Gateway：治理能力最强，适合微服务
4. 东西向流量高级治理（Service Mesh）
  • 全链路 mTLS 加密
  • 超时、重试、熔断
  • 流量镜像、染色、故障注入
  • 细粒度权限控制（AuthorizationPolicy）
5. 生产最佳实践
  • 南北流量
    • 云厂商 LB → Ingress / Gateway → Service → Pod
    • 统一 HTTPS、域名、证书、限流、WAF
  • 东西流量
    • 服务名 + Service 访问
    • 大规模微服务使用 Service Mesh 统一治理
    • 零信任：默认拒绝，按需放行

极简背诵版（面试直接用）

  • 南北流量：外部 ↔ 集群，由 LB、Ingress、Gateway 负责。
  • 东西流量：服务 ↔ 服务，由 Service、Service Mesh 负责。
  • Service：四层负载均衡，内部服务发现。
  • Ingress/Gateway：七层入口网关，域名、路由、HTTPS。
  • 负载均衡：外部 LB → Service → 应用网关，三级转发保证高可用。

  • 安全网络策略、零信任

一、基础认知

1. NetworkPolicy（网络策略）

NetworkPolicy 是 K8s 官方标准的 Pod 网络访问控制规则。

作用：

  • 控制谁能访问我（Ingress 入站）
  • 控制我能访问谁（Egress 出站）
  • 按 Namespace、Pod 标签、IP 段、端口 进行过滤
  • 默认：所有 Pod 互通、无限制

一句话：NetworkPolicy = K8s 里的 “分布式防火墙”。

2. 零信任安全（Zero Trust）

零信任：永不信任，始终验证。

在 K8s 里的核心思想：

  • 默认拒绝所有流量
  • 没有 “内部可信区域”
  • 服务之间必须显式授权才能通信
  • 身份、权限、加密、审计全覆盖

零信任落地三件套：

  1. 网络策略（连通性控制）
  2. mTLS 加密（身份 + 加密）
  3. RBAC + 权限最小化（操作控制）

一句话：零信任 = 默认拒绝 + 显式放行 + 身份认证 + 全链路加密。

3. 两者关系
  • NetworkPolicy 是零信任的流量隔离基础
  • 零信任是安全模型，NetworkPolicy 是实现工具
  • 配合 Service Mesh（Istio）可实现应用层零信任

二、核心配置

1. NetworkPolicy 核心字段

yaml

apiVersion: networking.k8s.k8s.io/v1
kind: NetworkPolicy
metadata:
  namespace: default
spec:
  # 对哪些 Pod 生效
  podSelector:
    matchLabels:
      app: mysql

  # 控制入站/出站
  policyTypes:
    - Ingress
    - Egress

  # 入站规则：谁能访问我
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: backend

  # 出站规则：我能访问谁
  egress:
  - to:
    - ipBlock:
        cidr: 10.0.0.0/24

关键匹配方式

  • podSelector：匹配 Pod 标签
  • namespaceSelector：匹配命名空间
  • ipBlock：匹配集群外 IP
  • ports：限制端口（TCP/UDP）

两条铁律

  1. 没有策略 = 全部允许
  2. 有策略但无规则 = 全部拒绝
2. 零信任核心配置原则
  1. 默认拒绝所有流量
  2. 按业务链路最小放行
  3. 服务间启用 mTLS 加密
  4. 禁止 Pod 访问公网不必要地址
  5. 命名空间之间默认隔离
3. 必须的 CNI 支持

NetworkPolicy 必须 CNI 实现才能生效：

  • ✅ Calico
  • ✅ Cilium
  • ✅ Antrea
  • ❌ Flannel（默认不支持）

三、实操场景（生产最常用）

场景 1：命名空间间完全隔离（多租户必备）

目标：ns-a 和 ns-b 完全不能互通。

yaml

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  namespace: ns-a
  name: deny-all
spec:
  podSelector: {}
  policyTypes: [Ingress, Egress]
  # 空规则 = 全部拒绝

ns-b 同样配置一条。

效果：命名空间变成 “安全孤岛”。

场景 2：数据库只允许业务 Pod 访问

目标：MySQL 只允许 backend 访问，拒绝其他所有。

yaml

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  namespace: prod
  name: mysql-allow-backend
spec:
  podSelector:
    matchLabels:
      app: mysql
  policyTypes: [Ingress]
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: backend
    ports:
    - port: 3306
场景 3：只允许从网关 / Ingress 进入（南北流量）

目标：外部只能通过网关访问，禁止直接访问 Pod。

yaml

ingress:
- from:
  - namespaceSelector:
      matchLabels:
        kubernetes.io/metadata.name: ingress-nginx
场景 4：零信任 – 全站默认拒绝 + 按需放行

标准零信任起步配置：

  1. 每个命名空间放一条 deny-all
  2. 再给需要通信的服务加允许策略

结构：

plaintext

deny-all（默认拒绝）
→ allow-api-from-gateway
→ allow-db-from-backend
→ allow-egress-to-dns
场景 5：限制 Pod 访问公网（Egress 出站控制）

yaml

egress:
- to:
  - namespaceSelector:
      matchLabels:
        kubernetes.io/metadata.name: kube-system
  ports:
  - port: 53
    protocol: UDP

只允许访问 DNS，禁止其他外部访问。

四、进阶扩展

1. 零信任完整架构（企业级）
  1. 网络隔离：NetworkPolicy
  2. 身份认证：Service Account / mTLS
  3. 传输加密：Istio 自动 mTLS
  4. 细粒度权限：AuthorizationPolicy
  5. 审计与观测：网络日志、访问记录
  6. 安全准入：禁止特权容器、镜像校验
2. NetworkPolicy 高级用法
  • 多维度组合：标签 + 命名空间 + IP
  • 默认拒绝 + 白名单（零信任标准模型）
  • Egress 防火墙：限制外访地址
  • Cilium 扩展：基于 DNS / 域名 / HTTP 层控制
3. Service Mesh 增强零信任（Istio）
  • 网络策略控制连通性
  • Istio 控制应用层权限
  • 自动 mTLS 加密
  • 基于服务身份，而非 IP
  • 支持：限流、熔断、灰度、授权

零信任能力更强：身份 + 加密 + 七层治理。

4. 生产最佳实践
  1. 所有命名空间都放 默认拒绝策略
  2. 按业务域放通最小权限
  3. 中间件（DB/Redis/MQ）只允许业务访问
  4. 严格限制 Pod 出口公网
  5. 使用 Calico / Cilium
  6. 配合 Istio 实现零信任闭环

极简背诵版（面试直接用）

  • NetworkPolicy：K8s 分布式防火墙，控制 Pod 间通信。
  • 零信任：默认拒绝、始终验证、最小权限、永不信任内网。
  • 核心：先全拒，再按需放行。
  • 生效前提：CNI 必须支持（Calico/Cilium）。
  • 最佳实践：NetworkPolicy + mTLS + RBAC = 完整零信任。

5. AI 基础设施与算力调度

  • GPU / NPU 虚拟化、共享、调度

一、基础认知：先搞懂「为什么要做这件事」

1. 核心背景

AI 训练 / 推理高度依赖 GPU / NPU 等加速卡，但它们有两个天然问题：

  • 单卡算力强，但利用率极低（传统方式一台机器一张卡一个任务，经常空转）
  • 成本极高，不能随便独占

所以行业要做三件事：

  1. 虚拟化：让一张物理卡 “变成” 多张虚拟卡，给多个容器 / VM 用
  2. 共享：让多个任务同时用同一块卡，互不干扰
  3. 调度：在集群里自动分配卡，谁需要给谁，用完回收
2. 关键概念区分
  • 虚拟化：把硬件抽象成虚拟设备（vGPU/mdev）
  • 共享：多任务分时 / 分片使用同一块卡（时间片 / 显存切分）
  • 调度：集群层面的资源编排（谁用哪张卡、用多久、优先级）
3. 为什么用 GPU/NPU 而不是 CPU
  • 并行计算单元多 → 矩阵 / 张量运算极快
  • 专为 AI 算子优化（CUDA、Tensor Core、NPU 专用指令）
  • 训练 / 推理必须靠它，否则速度差几十～上千倍

二、核心配置：虚拟化、共享、调度的主流实现

1. GPU 虚拟化主流方案
（1）SR-IOV
  • 把物理 GPU 虚拟成多个 PCIe 虚拟功能（VF）
  • 接近原生性能，几乎无损耗
  • 适合：推理、高性能场景
  • 缺点：不支持超分，只能按固定数量切

（2）NVIDIA vGPU / MIG

  • vGPU：传统虚拟化，支持多虚拟机共享
  • MIG（Multi-Instance GPU）：A100/H100 硬件级切分
    • 把一张卡切成 1/2/4/7 个独立实例
    • 显存、算力、缓存硬件隔离
  • 适合：训练、大模型、严格隔离场景

（3）时间分片虚拟化（如 vCUDA、gVisor 类）

  • 不修改硬件，驱动层拦截 + 时间片轮转
  • 支持超配（1 卡给 10+ 容器用）
  • 适合：推理、小模型、低延迟不敏感业务
  • 缺点：有性能损耗，不适合强训练
2. NPU 虚拟化 & 共享（国产加速卡）

NPU 更偏向推理 + 端云一体，虚拟化路线和 GPU 略有不同：

  • 厂商自研虚拟化方案（华为昇腾、寒武纪、壁仞等）
  • 常见：
    • 设备切片：硬件级切分（像 MIG）
    • 进程级共享：多进程共用 NPU，由驱动 / 框架管理
    • 容器化透传 + 配额限制：限制显存 / 算力占用
  • 特点：
    • 隔离性不如 GPU 成熟
    • 性价比高，大规模推理首选
3. 核心共享机制（底层原理）

共享本质是三类：

  1. 时间共享：任务轮流用卡（毫秒级切换）
  2. 空间共享：硬件切分显存 / 计算单元（MIG/SR-IOV）
  3. 软件配额：框架层限制使用率（如限制 30% GPU 利用率）

隔离等级从高到低：硬件切片 > SR-IOV > vGPU > 软件时间分片

4. 算力调度核心架构

标准云原生 AI 基础设施：

plaintext

上层：AI 平台 / Job 管理（Kubeflow、Volcano、自研平台）
中间：容器编排（K8s）
下层：GPU/NPU 设备插件 + 调度器 + 运营商

关键组件

  • Device Plugin：K8s 发现 GPU/NPU 设备

  • Scheduler：调度器（默认调度器 / Volcano / YARN-CS）

  • GPU-Manager：集中管理卡状态、使用率、健康

  • Monitoring：显存、算力、温度、报错

调度策略（最常用）

  1. binpack：尽量塞满一台机器，节省机器

  2. spread：打散任务，提高可用性

  3. 拓扑感知：优先同机、同 NUMA、同 Switch

  4. 优先级 / 抢占：训练 > 推理 > 离线任务

  5. 配额 / 租户隔离：部门 A 只能用 20 张卡

三、实操场景：你在企业里真正会遇到的用法

场景 1：开发 / 测试环境（低成本高密）
  • 方案：时间分片虚拟化 + 超配
  • 一张卡跑 10～20 个开发容器
  • 目标：利用率拉满、成本最低
  • 不要求强隔离
场景 2：在线推理服务（高稳定、低延迟）
  • 方案：SR-IOV 或 硬件切片
  • 隔离好、延迟稳定
  • 适合：API 服务、流式推理
场景 3：大模型训练（强隔离、高性能）
  • 方案：MIG / 整卡直通 + 专属队列
  • 不共享、不超配
  • 调度：高优先级、独占、抢占保护
场景 4：混合集群（训练 + 推理 + 离线）
  • 训练用整卡 / 大切片
  • 推理用小切片 / SR-IOV
  • 离线任务用空闲碎片算力
  • 靠调度器 + 队列 + 优先级自动切换
场景 5：国产化 NPU 集群
  • 以推理为主
  • 用厂商提供的 K8s 插件 + 切片能力
  • 常见：多模型共享单 NPU，提高密度

四、进阶扩展：走向生产级高可用、自动化、智能化

1. 进阶虚拟化能力
  • 热迁移：虚机 / 容器不中断迁移到另一张卡
  • 热插拔：在线添加 / 移除虚拟卡
  • 故障自愈：卡坏了自动驱逐任务，重调度
2. 智能调度（AI 调度 AI）
  • 预测式调度：根据历史负载预测任务时长
  • 弹性扩缩容：
    • 推理高峰：自动加卡
    • 空闲：自动释放给训练
  • 混部优化：训练与推理互不干扰（QoS）
3. 多卡多机分布式场景
  • 调度要考虑：
    • RDMA / NVLink 组网
    • 同机 / 同机架优先
    • 分布式训练任务亲和性
  • 工具：Volcano、KubeRay、TorchElastic
4. 可观测性与运维
  • 必须监控：
    • 单卡利用率、显存
    • 虚拟化损耗
    • 任务排队时间、调度成功率
    • 硬件报错、降频、温度
  • 用于：容量规划、成本核算、故障定位
5. 商业化 / 平台化方向
  • 算力池化：把全机房 GPU/NPU 打成一个资源池
  • 算力售卖 / 租赁：按显存、按小时、按任务计费
  • 多云 / 混合云调度：统一调度不同厂商 / 云厂商的加速卡

极简总结（方便你复述 / 做 PPT）

  • 基础认知：GPU/NPU 贵且利用率低，必须虚拟化、共享、调度
  • 核心配置：SR-IOV/MIG/ 时间分片 + K8s+DevicePlugin + 调度器
  • 实操场景：开发超配、推理隔离、训练独占、混合集群
  • 进阶扩展：智能调度、混部、分布式、自愈、算力池化

  • Kubernetes 调度 AI 任务： volcano /kubeflow/kueue

一、基础认知：先搞懂这三个东西到底干嘛的

1. 为什么 Kubernetes 原生调度不够用？

K8s 默认调度器只擅长：

  • 无状态服务（Deployment、Service）
  • 简单资源调度（CPU/mem）

AI 任务有特殊需求：

  • 批量任务、分布式训练（TensorFlow/PyTorch 多机多卡）
  • 队列、优先级、抢占、排队
  • 多角色：PS/Worker/Chief
  • 异构资源：GPU/NPU 批量调度
  • 生命周期：排队→调度→运行→失败重试→扩缩容

所以需要 AI 专属调度 / 作业管理组件。

2. 三者定位一句话分清
  • Volcano：K8s 上的批量调度引擎，专门解决 AI / 大数据 / 高性能计算的调度问题。
  • Kubeflow：AI 全生命周期平台，把训练、部署、流水线串起来，调度只是其中一环。
  • Kueue：K8s 官方轻量队列管理器，负责 “排队 + 配额 + 限流”，不负责底层调度。
3. 核心关系
  • Kueue：管排队、配额、优先级。
  • Volcano：管真正的 Pod 调度、 Gang Scheduling、拓扑、抢占。
  • Kubeflow：管AI 作业定义（TFJob/PyTorchJob），可以用 Volcano/Kueue 做底层调度。

二、核心配置：各自负责什么、怎么配合

1. Volcano：AI 批量调度核心

核心能力

  • Gang Scheduling（团伙调度）要么一起调度成功，要么一个不调度（避免分布式任务死锁）。

  • 批队列 + 优先级 + 抢占

  • GPU/NPU 拓扑感知调度

  • 多机多卡分布式训练友好

  • 任务重试、容错、弹性

关键配置对象

  • Queue：队列

  • PodGroup：把一批 Pod 绑定成一个任务组

  • Volcano Scheduler：替换 / 增强 K8s 调度器

典型工作模式

  1. 提交 AI 作业 → 生成 PodGroup

  2. Volcano 检查资源是否满足整组调度

  3. 满足则一起调度，不满足则排队或抢占

2. Kubeflow：AI 作业定义与生命周期

核心能力

  • 定义各种 AI 定制作业：

    • TFJob

    • PyTorchJob

    • XGBoostJob

    • MPIJob

  • 提供：SDK、Pipeline、模型服务、Notebook

  • 不做底层调度，依赖 Volcano 或 K8s 原生调度

关键配置

  • Operator：监听作业 CRD，管理 Pod 生命周期

  • 分布式角色：Worker/PS/Chief

  • 检查点、重启策略、弹性策略

定位

Kubeflow = AI 作业的 “业务层”告诉 K8s：这是一个 PyTorch 分布式训练，要 1 主 4 工。

3. Kueue：K8s 官方轻量队列管理器

核心能力

  • 队列 + 多租户配额

  • 控制并发数、资源限额

  • 不调度 Pod，只放行作业到调度器

  • 轻量、无侵入、官方推荐

关键配置

  • ResourceFlavor：资源类型（CPU/GPU/NPU）

  • ClusterQueue：集群级队列 & 配额

  • LocalQueue：namespace 队列

  • 配合：Job、MPIJob、TFJob、PyTorchJob

定位

Kueue = 看门人 + 排队机谁能进、进多少、按什么顺序，由它决定。

4. 三者配合的标准架构

plaintext

用户提交 AI 作业
↓
Kubeflow Operator（TFJob/PyTorchJob）
↓
Kueue（队列、配额、排队、放行）
↓
Volcano（真正调度：Gang、拓扑、GPU/NPU、抢占）
↓
K8s 运行 Pod

三、实操场景：企业里真实怎么用

场景 1：单队列小团队 AI 训练
  • 组件：Volcano
  • 用途：
    • 简单多机多卡训练
    • 防止任务 “饿死”
    • 保证分布式任务 Gang 调度
  • 适合：算法团队内部小集群
场景 2：多团队、多租户、资源配额
  • 组件：Kueue + Volcano
  • Kueue：
    • 给每个部门设配额
    • 控制同时运行作业数
  • Volcano：
    • 底层调度、Gang、GPU 拓扑
  • 适合：中大型公司 AI 平台
场景 3：完整 AI 平台化
  • 组件：Kubeflow + Kueue + Volcano
  • Kubeflow：
    • 统一提交训练、管理实验、模型上线
  • Kueue：
    • 租户、队列、限流
  • Volcano：
    • 高性能、高稳定调度
  • 适合：云厂商 / 大型 AI 平台 / 自研 AI 平台
场景 4：国产化 NPU 集群
  • 用 Kubeflow Operator 定义作业
  • Kueue 做队列与配额
  • Volcano 做 NPU 拓扑、多卡调度这是目前国内 AI 基础设施最主流落地架构。

四、进阶扩展：生产级高可用与优化

1. 调度策略进阶
  • Gang Scheduling + 最小运行数
  • Binpack/Spread 调度策略
  • 拓扑感知：NUMA、GPU 直连、RDMA
  • 优先级抢占：在线推理 > 训练 > 离线
2. 弹性与容错
  • 训练任务弹性扩缩 Worker
  • 节点异常自动驱逐 & 重调度
  • 结合 Pod 亲和 / 反亲和 提高分布式性能
3. 可观测性
  • 队列长度、等待时间
  • 调度成功率、调度时延
  • GPU/NPU 利用率、任务排队瓶颈
  • 用于：自动扩缩容、容量规划
4. 与 AI infra 整合
  • 配合 GPU/NPU 虚拟化 / 共享
  • 配合 CSI 存储（数据集、 checkpoint）
  • 配合 网络策略、RDMA、IP 固定
5. 未来趋势
  • K8s 原生 AI 调度走向：Kueue（队列） + 增强调度器（Volcano 类）
  • Kubeflow 慢慢变成标准作业规范层
  • 调度越来越智能化、资源池化、算力统一编排

极简总结（方便背诵 / 汇报）

  • Volcano：AI 批量调度核心，Gang、GPU、分布式、抢占。
  • Kubeflow：AI 作业定义，TFJob/PyTorchJob，全生命周期。
  • Kueue：轻量队列 + 配额，多租户、限流、官方标准。
  • 生产标配：Kubeflow → Kueue → Volcano → K8s

  • 分布式训练、推理架构

一、基础认知：先把概念彻底说清

1. 为什么要分布式？
  • 单卡 / 单机装不下大模型、大数据
  • 训练太慢、推理扛不住高并发
  • 必须把计算、数据、模型拆到多机多卡协同

一句话：分布式训练 = 把训练摊到多机多卡；分布式推理 = 把推理服务扩成高并发集群。

2. 核心两个方向
  1. 分布式训练
    • 目标：更快收敛、训更大模型
    • 关键词：数据并行、模型并行、张量并行、流水线并行、AllReduce、Ring-Reduce
  2. 分布式推理
    • 目标：低延迟、高吞吐、高可用
    • 关键词：多实例、多副本、动态批处理、模型分片、服务网格
3. 与普通分布式的区别
  • AI 任务：强算力依赖、大通信量、多角色协同
  • 训练：PS/Worker/Chief/Rank 等角色
  • 推理：在线流量、弹性、灰度、熔断
4. 基础术语扫盲
  • DP（Data Parallel）：数据并行，最常用
  • MP（Model Parallel）：模型并行，超大模型用
  • TP（Tensor Parallel）：张量并行，卡内 / 卡间切层
  • PP（Pipeline Parallel）：流水线并行，多层接力
  • AllReduce：多卡梯度聚合核心操作
  • Inference Batching：推理动态批处理，提高吞吐

二、核心配置：训练 & 推理架构的标准组成

（一）分布式训练架构（核心配置）
1. 架构分层

plaintext

训练框架层：PyTorch / TensorFlow / MindSpore
并行策略层：DP / TP / PP / ZeRO
通信层：NCCL / RCCL / Gloo
编排层：K8s + Volcano / Kubeflow
资源层：GPU / NPU + RDMA + NVLink
2. 三种主流并行模式

  1. 数据并行 DP（最常用）

    • 每张卡完整模型，只分数据
    • 梯度 AllReduce
    • 适合：大部分模型训练

  2. 张量并行 TP

    • 单层矩阵切多卡
    • 卡间通信极高
    • 适合：大模型单层太大

  3. 流水线并行 PP

    • 模型按层切到不同机器
    • 接力式前向 / 反向
    • 适合：超深大模型

  4. 3D 并行（企业级标配）DP + TP + PP 一起上

3. 训练架构核心组件
  • 训练节点角色
    • Worker 0：Rank 0，主节点，日志、保存 checkpoint
    • 其他 Worker：计算节点
  • 通信引擎
    • GPU：NCCL
    • NPU：厂商自研（如 HCCL）
  • 分布式启动
    • torchrun
    • mpirun
    • K8s Operator（TFJob/PyTorchJob）
（二）分布式推理架构（核心配置）
1. 推理架构目标
  • 低延迟
  • 高吞吐
  • 高可用
  • 弹性扩缩容
2. 推理部署分层

plaintext

流量入口：LB / Nginx / Ingress / API Gateway
服务框架：Triton / TensorRT / TFServing / TorchServe
推理 runtime：TensorRT / ONNX Runtime / NPU 加速引擎
服务编排：K8s Deployment / HPA
资源：GPU/NPU 多实例 / 多副本
3. 分布式推理三种模式

  1. 多副本水平扩展

    • 模型完全复制，流量负载均衡
    • 最简单、最常用

  2. 模型分片推理（模型并行推理）

    • 大模型切多层，分到多机
    • 单卡放不下时用

  3. 动态批处理 + 流式推理

    • 把多个请求攒一起推理
    • 提高吞吐，适合高 QPS
4. 推理关键技术
  • 模型优化：量化、剪枝、蒸馏、ONNX、TensorRT
  • 服务治理：限流、熔断、降级、灰度
  • 弹性：HPA 基于 QPS/GPU 利用率扩缩容

三、实操场景：企业里真实怎么搭

场景 1：中小模型训练（BERT、ResNet、常规大模型）

架构：K8s + PyTorch + 数据并行 DP + Volcano

  • 多机多卡，每张卡跑完整模型
  • NCCL 通信
  • 固定资源队列适用：绝大多数算法团队日常训练
场景 2：千亿参数大模型训练

架构：3D 并行（DP+TP+PP）+ ZeRO + RDMA + 高速存储

  • 模型切分到多机
  • 流水线并行
  • Checkpoint 定时保存到分布式存储适用：LLM、多模态大模型
场景 3：在线 API 推理服务（高并发低延迟）

架构：LB + Triton/TensorRT + K8s + HPA + GPU/NPU

  • 多副本负载均衡
  • 动态批处理
  • 监控告警 + 自动扩缩容适用：对话机器人、质检、OCR、推荐接口
场景 4：离线批量推理

架构：Volcano 批量调度 + 任务队列 + 共享存储

  • 大量文件批量预测
  • 不追求低延迟，追求吞吐适用：数据标注、批量特征提取、离线评测
场景 5：国产化 NPU 集群架构

架构：Kubeflow + Volcano + 厂商 NPU 插件 + HCCL 类通信

  • 训练：PyTorch 适配 + 数据并行
  • 推理：模型转 NPU 格式 + 多副本部署适用：国内政务、金融、能源等国产化要求场景

四、进阶扩展：生产级高可用 & 性能优化

1. 训练架构进阶
  • 通信优化
    • RDMA、RoCE、NVLink
    • 拓扑感知调度（同机 / 同机架优先）
  • 容错与断点续训
    • Checkpoint 分布式存储
    • 节点异常自动重启、重调度
  • 混合精度 + ZeRO
    • 降低显存，放大 Batch
  • 弹性训练
    • 动态增删 Worker
    • 训练不中断
2. 推理架构进阶
  • 推理加速链量化 → ONNX → TensorRT/NPU 加速 → 多实例
  • 流量治理
    • 灰度发布、A/B 测试
    • 多版本共存
  • 异构推理混部
    • 高优流量：GPU/NPU 低延迟
    • 离线流量：CPU 共享池
  • 可观测
    • P99/P95 延迟
    • QPS、错误率、GPU 利用率
    • 排队长度、扩容延迟
3. 云原生一体化架构（未来标配）

plaintext

AI 平台层
↑
Kubeflow（作业）→ Kueue（队列）→ Volcano（调度）
↑
分布式训练 / 推理集群
↑
GPU/NPU + 高速网络 + 分布式存储
4. 成本与效率优化
  • 训练 / 推理混部，错峰用算力
  • 推理按需弹性，闲时缩容
  • 调度优先级抢占
  • 算力池化 & 虚拟化共享

极简总结（方便背诵）

  • 基础认知：分布式 = 多机多卡协同，分训练（训得快、训得大）和推理（高并发、低延迟）。
  • 核心配置：
    • 训练：DP/TP/PP + NCCL/RDMA + K8s+Volcano
    • 推理：多副本 + 模型优化 + 动态批处理 + 服务治理
  • 实操场景：中小模型用 DP，大模型用 3D 并行，线上用 Triton+K8s。
  • 进阶扩展：通信优化、容错、弹性、混部、可观测、国产化适配。

  • 大模型训练环境：数据集、缓存、加速

一、基础认知：先搞懂三件事的定位

大模型训练，90% 的时间不是在算，而是在 “等数据”。所以整套环境围绕一件事：让 GPU/NPU 永远吃饱数据，不空闲、不等待。

1. 三者关系
  • 数据集：原料（文本、图片、音频、视频、Token）
  • 缓存：中转站（把冷数据变热，减少重复加载）
  • 加速：全链路提速（IO、读取、预处理、通信、计算）

一句话总结：数据集负责 “有什么”，缓存负责 “快不快”，加速负责 “满不满载”。

2. 大模型训练数据特点
  • 体量极大：TB～PB 级
  • 读多写少：一遍训练读无数次
  • 随机读取多：不能顺序读
  • 强依赖预处理：tokenize、aug、filter、shuffle
  • 瓶颈往往在 存储 / IO/CPU 预处理，不在 GPU
3. 核心目标
  1. 数据吞吐 > 显卡吞吐
  2. 单机 / 多机 读取不打架
  3. 预处理 不拖训练后腿
  4. 断点续训、容错、可复现

二、核心配置：数据集 / 缓存 / 加速 到底怎么配

（一）数据集：格式、存储、组织
1. 数据集格式（工业界标配）
  • 原始数据：jsonl、txt、parquet、csv
  • 预处理后数据：
    • WebDataset：适合海量小文件
    • LMDB / LevelDB：K-V 存储，随机读快
    • Parquet/ORC：列存，压缩率高
    • HF Dataset / TFRecord：框架友好
2. 存储层级
  • 远端冷存储：S3、OSS、MinIO、HDFS
  • 集群热存储：Beegfs、Lustre、JuiceFS、CephFS
  • 本地热数据：节点本地 NVMe SSD
3. 数据集管理关键能力
  • 去重、清洗、过滤、长度筛选、质量打分
  • 多数据源混合、采样比例控制
  • 全局 shuffle、分片、分布式加载
  • 版本管理：DVC、Git LFS、Weights & Biases
（二）缓存：大模型训练的 “隐形心脏”

缓存目标：把远端 / 慢存储的数据，搬到靠近 GPU 的地方。

1. 三级缓存架构（标准生产配置）
  1. L0：CPU 内存缓存已加载、预处理好的样本，内存里直接读。
  2. L1：本地 NVMe 缓存单节点常用数据，本地 SSD 缓存。
  3. L2：分布式缓存 / 热池全集群共享热数据（JuiceFS 缓存、Distributed Cache）
2. 缓存策略
  • 全量缓存：训前把整个数据集拉到本地
  • 惰性缓存：读一次就缓存，下次直接用
  • LRU 淘汰：自动清冷数据，留热数据
  • 分片缓存：不同节点缓存不同分片，减少重复拉取
3. 常见缓存工具
  • JuiceFS / GooseFS
  • Beegfs/Lustre 客户端缓存
  • DeepSpeed 数据集缓存
  • HF Dataset 自带缓存机制
（三）全链路加速：从磁盘到 GPU 的每一步
1. 存储 IO 加速
  • 用 高性能分布式文件系统：Lustre、BeeGFS、GPFS
  • 对象存储 + 缓存：JuiceFS/MinIO + 本地 NVMe
  • 大文件、少小文件：减少元数据压力
2. 数据加载加速
  • 多进程加载：dataloader worker
  • 异步加载：训练的同时预读下一批
  • 预取 Prefetch：GPU 算第 N 批，CPU 读第 N+1 批
3. 数据预处理加速
  • 离线预处理：训前全部做好，不占训练时间
  • GPU 预处理：利用 CUDA 核做 augment /tokenize
  • 向量化处理：Numba、Vectorized Pipeline
4. 计算与通信加速
  • 混合精度 FP16/BF16
  • 分布式优化：ZeRO、AllReduce、NCCL/RCCL
  • 拓扑感知：同机、同机架、RDMA 优先
  • 加速库：TensorRT、FlashAttention、 Apex
5. 框架级加速配置
  • DDP / FSDP / DeepSpeed / Megatron
  • 异步 checkpoint、懒加载
  • 动态 Padding、Bucket 通信

三、实操场景：真实环境怎么搭

场景 1：中小规模 LLM 训练（10B 以内）
  • 数据集：Parquet + HF Dataset
  • 存储：NAS / 高性能对象存储 + 本地 SSD
  • 缓存：框架自带缓存 + 内存预取
  • 加速：DDP + 混合精度 + 异步加载特点：简单、稳定、够用。
场景 2：千亿参数大模型训练（生产标配）
  • 数据集：WebDataset / LMDB
  • 存储：Lustre / BeeGFS / 高性能分布式存储
  • 缓存：三级缓存 + 全量缓存到本地 NVMe
  • 加速：
    • 异步 IO + 后台预取
    • ZeRO 3 + 张量 / 流水线并行
    • RDMA + NVLink
    • FlashAttention、算子融合
场景 3：多机多卡、海量小样本（图文多模态）
  • 问题：小文件多、元数据爆炸、随机读慢
  • 方案：
    • 打包成 tar/webdataset
    • 分布式缓存 + 本地缓存
    • 全局 shuffle + 分块读取
场景 4：云端 / 私有化环境（S3/OSS 做数据源）
  • 方案：
    • JuiceFS/GooseFS 挂载对象存储
    • 开启强缓存，缓存落本地 NVMe
    • 离线预处理 → 上传 → 缓存 → 训练
  • 优点：成本低、弹性好、易维护
场景 5：国产化 NPU 集群
  • 数据集：统一 标准化格式（Parquet/TFRecord）
  • 缓存：本地 NVMe + 分布式缓存
  • 加速：
    • 厂商 HCCL 类通信库
    • 图编译、算子优化、并行策略

四、进阶扩展：生产级高可用与极致优化

1. 数据集进阶
  • 数据编排系统：数据流、清洗、采样、混合一站式
  • 数据质量监控：长度分布、语言分布、重复率、多样性
  • 数据热点调度：高频数据优先进缓存
  • 数据脱敏与合规：去隐私、水印、溯源
2. 缓存进阶
  • 智能缓存：按访问频率自动分层
  • 分布式协同缓存：节点之间不重复拉取
  • 缓存预热：训前后台异步把数据读满
  • 缓存淘汰策略：保证热数据常驻
3. 全链路加速极致优化
  • CPU 绑定：Dataloader 绑核，减少上下文切换
  • IO 与计算重叠：让 GPU 永远不等待
  • Checkpoint 加速：异步存、增量存、多线程上传
  • 弹性 & 容错：
    • 节点挂掉不重新读数据
    • 断点续训从最近状态恢复
4. 可观测与调优
  • 监控：
    • 数据加载等待时间
    • IO 使用率、网卡流量
    • GPU 空闲率、显存利用率
  • 调优目标：GPU 利用率 > 90%
5. 云原生一体化
  • K8s + Volcano 调度
  • 存储 / 缓存 / 数据集编排
  • 弹性训练 + 数据缓存自动扩缩

极简总结（方便背诵 / 汇报）

  • 基础认知：大模型训练瓶颈在数据不在卡，数据集 = 原料，缓存 = 提速，加速 = 满载。
  • 核心配置：
    • 数据集：标准格式 + 分布式存储 + 版本管理
    • 缓存：三级缓存 + 预热 + 异步加载
    • 加速：IO、加载、预处理、通信、计算全链路优化
  • 实操场景：中小模型用简易方案，大模型用分布式存储 + 全量缓存 + 深度并行。
  • 进阶扩展：智能缓存、数据治理、GPU 满载、弹性容错、可观测。

6. MLOps / AIOps 工程化

  • ML 全流程：数据 → 训练 → 验证 → 部署

一、基础认知：ML 全流程到底在干嘛

1. 一句话定义

机器学习全流程 = 从原始数据到线上可用模型的完整工程链路四阶段闭环：

  • 数据：喂什么
  • 训练：怎么学
  • 验证：学得好不好
  • 部署：怎么用起来
2. 核心目标
  • 可复现
  • 可迭代
  • 可监控
  • 可规模化
3. 与传统开发区别
  • 代码不变，数据 / 参数决定效果
  • 训练 ≠ 上线，部署与监控同样关键
  • 全链路必须自动化、流水线化

二、核心配置：每一步做什么、用什么工具

1. 数据阶段（最决定上限）

目标

干净、合规、均衡、可复用。

核心环节

  • 采集：日志、业务库、爬取、标注

  • 清洗：去重、去噪、补缺、过滤

  • 标注：分类、检测、分割、NLP 标注

  • 预处理：归一化、增强、Tokenize、编码

  • 划分：训练集 / 验证集 / 测试集

  • 版本与管理：数据血缘、可复现

常用工具

Pandas、Spark、Dask、HF Datasets、LabelStudio、DVC、Airflow

2. 训练阶段（算力与算法核心）

目标

快速收敛、稳定、资源高效、可复现。

核心环节

  • 网络 / 结构设计

  • 超参配置

  • 分布式训练（DP/TP/PP/ZeRO）

  • 混合精度、梯度累积

  • 日志、可视化、Checkpoint

  • 实验管理

常用框架

PyTorch、TensorFlow、JAX、DeepSpeed、Megatron

编排

K8s、Volcano、Kubeflow、PyTorchJob

3. 验证阶段（模型质量守门人）

目标

客观评估、防止过拟合、保证上线质量。

核心环节

  • 离线指标计算

    • 分类：Acc、Precision、Recall、F1、AUC

    • 检测：mAP

    • 分割：mIoU

    • 生成：BLEU、ROUGE、PPL、人工评估

  • 过拟合检查：训练 vs 验证曲线

  • 鲁棒性、对抗性、偏见检查

  • 模型对比与选择

工具

TensorBoard、Weights & Biases、MLflow、Evidently AI

4. 部署阶段（工程化最后一公里）

目标

低延迟、高吞吐、高可用、可扩缩容。

核心环节

  • 模型优化：量化、剪枝、蒸馏、ONNX、TensorRT

  • 打包：容器化

  • 服务化：API + 负载均衡

  • 弹性扩缩容

  • 灰度、熔断、限流

  • 监控与回滚

常用框架

Triton、TorchServe、TFServing、FastAPI

云原生

K8s、Docker、HPA、Ingress、Prometheus

三、实操场景：真实业务长什么样

场景 1：传统机器学习（表格数据）

数据（ETL / 特征工程）→ 训练（XGBoost/LightGBM）→ 验证（AUC/KS）→ 部署（API / 定时任务）用于：风控、推荐、预测、用户画像

场景 2：CV 模型（图像 / 视频）

数据（采集 / 清洗 / 标注 / 增强）→ 训练（YOLO/ResNet）→ 验证（mAP）→ 部署（TensorRT / 边缘设备）用于：质检、人脸识别、OCR、监控

场景 3：NLP / 大模型

数据（去重 / 清洗 / Tokenize）→ 训练（分布式 + ZeRO）→ 验证（PPL / 人工）→ 部署（Triton + 多副本）用于：对话、摘要、分类、搜索

场景 4：云原生自动化流水线

Git 提交数据 / 代码 → 自动触发训练 → 自动验证 → 自动部署 / 灰度企业级标配：MLOps

四、进阶扩展：生产级 ML 体系

1. 全链路进阶能力
  • 特征平台：特征统一、复用、在线离线一致
  • 模型版本管理：模型注册、流转、回滚
  • 流水线自动化：CI/CD for ML
  • 数据 / 模型监控：数据漂移、概念漂移
2. 分布式与规模化
  • 分布式训练 & 分布式数据加载
  • 多模型并行、混部调度
  • 训练 / 推理弹性扩缩容
3. 可靠性与安全
  • 模型加密、水印、防篡改
  • 访问权限、审计日志
  • 高可用、多可用区
4. MLOps 完整体系

数据 → 特征 → 实验 → 训练 → 验证 → 打包 → 部署 → 监控 → 迭代真正的 端到端闭环

极简总结（可直接背）

  • 数据：源头，决定上限
  • 训练：核心，学出模型
  • 验证：把关，保证质量
  • 部署：落地，产生价值
  • 进阶：MLOps 全链路自动化、可观测、可扩展

  • Kubeflow、Pytorch/TensorFlow on K8s

        

一、基础认知：先搞懂核心定位与价值

1. 核心背景：为什么要把 PyTorch/TensorFlow 跑在 K8s 上？
  • 单机痛点：
    • 算力不够（大模型 / 分布式训练）
    • 资源孤岛（GPU/NPU 利用率低）
    • 环境不一致（开发≠生产）
    • 无弹性、无容错、难规模化
  • K8s 解决的核心问题：
    • 算力池化：统一管理 GPU/NPU/CPU 集群
    • 弹性调度：按需分配、用完回收
    • 环境一致：容器化打包，开发 / 训练 / 部署环境统一
    • 高可用：节点故障自动重调度、任务容错
    • 规模化：一键扩缩多机多卡训练 / 推理
2. Kubeflow 的定位：K8s 上的 AI 全生命周期平台
  • 不是替代 PyTorch/TensorFlow，而是赋能它们在 K8s 上落地
  • 核心价值：
    • 标准化 AI 作业定义（PyTorchJob/TFJob）
    • 封装分布式训练逻辑，无需手写 K8s 配置
    • 提供一站式 AI 工具链（Notebook、Pipeline、模型服务）
    • 兼容云原生生态（Volcano/Kueue 调度、监控、存储）
  • 一句话总结：Kubeflow = K8s 上的 PyTorch/TensorFlow 作业管理器 + AI 工具集
3. 核心关系梳理

plaintext

用户 → Kubeflow（定义作业、管理生命周期）→ K8s（调度、运行容器）→ PyTorch/TensorFlow（执行训练/推理）

二、核心配置：组件、架构、关键配置

（一）核心架构：Kubeflow + PyTorch/TensorFlow on K8s

plaintext

┌─────────────────────────────────────────────────────────┐
│ 上层：Kubeflow 控制台/SDK/Notebook（用户交互层）        │
├─────────────────────────────────────────────────────────┤
│ 中层：Kubeflow Operators（作业控制层）                  │
│       - PyTorchOperator（管理 PyTorchJob）              │
│       - TFJobOperator（管理 TFJob）                     │
├─────────────────────────────────────────────────────────┤
│ 下层：K8s 核心组件（资源调度层）                        │
│       - 调度器（默认/Volcano/Kueue）                    │
│       - Device Plugin（GPU/NPU 设备发现）               │
│       - 容器运行时（Docker/Containerd）                │
├─────────────────────────────────────────────────────────┤
│ 底层：算力资源（GPU/NPU/CPU + 存储/网络）               │
└─────────────────────────────────────────────────────────┘
（二）关键组件详解
1. Kubeflow 核心组件（针对 PyTorch/TensorFlow）

表格

组件 核心作用
PyTorchOperator 监听 PyTorchJob CRD，自动创建 / 管理 Worker/PS/Chief 等角色的 Pod
TFJobOperator 监听 TFJob CRD，管理 TensorFlow 分布式训练的 PS/Worker 角色
Kubeflow Notebook 交互式开发环境，直接在 K8s 里写代码、提交 PyTorchJob/TFJob
Kubeflow Pipeline 把数据处理→训练→验证→部署串成自动化流水线
KServe 模型服务化，支持 PyTorch/TensorFlow 模型一键部署为 HTTP/gRPC 服务
2. PyTorchJob/TFJob 核心配置（最关键）
（1）PyTorchJob 示例（分布式训练）

yaml

apiVersion: kubeflow.org/v1
kind: PyTorchJob
metadata:
  name: pytorch-distributed-train
  namespace: kubeflow
spec:
  # 作业重启策略：Never/OnFailure/Always
  restartPolicy: OnFailure
  # 主节点（Chief）：负责日志、保存 checkpoint、控制训练流程
  chief:
    replicas: 1
    template:
      spec:
        containers:
        - name: pytorch
          image: pytorch/pytorch:2.1.0-cuda12.1-cudnn8-runtime
          command: ["python", "train.py", "--epochs", "10", "--batch-size", "64"]
          resources:
            limits:
              nvidia.com/gpu: 1  # 单卡
  # 工作节点（Worker）：执行实际训练计算
  worker:
    replicas: 3  # 3 个 Worker，总计 1+3=4 卡
    template:
      spec:
        containers:
        - name: pytorch
          image: pytorch/pytorch:2.1.0-cuda12.1-cudnn8-runtime
          command: ["python", "train.py", "--epochs", "10", "--batch-size", "64"]
          resources:
            limits:
              nvidia.com/gpu: 1
（2）TFJob 示例（分布式训练）

yaml

apiVersion: kubeflow.org/v1
kind: TFJob
metadata:
  name: tf-distributed-train
  namespace: kubeflow
spec:
  tfReplicaSpecs:
    # 参数服务器（PS）：管理模型参数
    PS:
      replicas: 2
      template:
        spec:
          containers:
          - name: tensorflow
            image: tensorflow/tensorflow:2.15.0-gpu
            command: ["python", "train.py"]
            resources:
              limits:
                cpu: "4"
                memory: "8Gi"
    # 工作节点（Worker）：执行训练
    Worker:
      replicas: 4
      template:
        spec:
          containers:
          - name: tensorflow
            image: tensorflow/tensorflow:2.15.0-gpu
            command: ["python", "train.py"]
            resources:
              limits:
                nvidia.com/gpu: 1  # 每个 Worker 1 卡
（3）核心配置说明
  • 角色定义：
    • PyTorch：Chief（主节点）、Worker（计算节点）、PS（参数服务器）
    • TensorFlow：PS（参数服务器）、Worker（计算节点）、Evaluator（验证节点）
  • 资源限制：nvidia.com/gpu 声明 GPU 卡数，K8s 通过 Device Plugin 调度
  • 重启策略：
    • Never：失败不重启（适合一次性训练）
    • OnFailure：失败重启（生产级常用）
    • Always：总是重启（适合常驻服务）
3. K8s 侧关键配置（支撑 PyTorch/TensorFlow 运行）
（1）GPU Device Plugin

必须部署 NVIDIA Device Plugin（或国产 NPU 插件），让 K8s 识别 GPU：

bash

运行

# 部署 NVIDIA Device Plugin
kubectl apply -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/v0.14.0/nvidia-device-plugin.yml
（2）调度器增强（可选，推荐）
  • 部署 Volcano 调度器，支持 Gang Scheduling（分布式任务整组调度）：

    bash

    运行

    kubectl apply -f https://raw.githubusercontent.com/volcano-sh/volcano/v1.8.0/installer/volcano-deploy.yaml
  • 在 PyTorchJob/TFJob 中指定调度器：

    yaml

    spec:
  jobSpec:
    schedulerName: volcano  # 指定 Volcano 调度
（三）核心依赖与环境准备
1. 前置条件
  • K8s 集群（1.24+ 版本，推荐 1.26+）
  • GPU 节点（NVIDIA GPU + CUDA 11.8+，或国产 NPU）
  • 容器运行时支持 GPU（Docker/Containerd 配置 NVIDIA 运行时）
  • Kubeflow 部署（推荐 v1.8+，聚焦 PyTorchOperator/TFJobOperator 即可）
2. 关键镜像准备
  • PyTorch 镜像：官方镜像（pytorch/pytorch）或自定义打包业务代码的镜像
  • TensorFlow 镜像：官方镜像（tensorflow/tensorflow）或自定义镜像
  • 镜像需包含：训练代码、依赖库、CUDA/NPU 驱动

三、实操场景：企业级落地案例

场景 1：单节点 PyTorch 训练（开发 / 测试）

目标

在 K8s 上快速跑单卡 PyTorch 训练，验证环境与代码

步骤

  1. 编写 PyTorchJob 配置（仅 Chief，replicas=1）

  2. 提交作业：kubectl apply -f pytorch-single-job.yaml

  3. 查看日志：kubectl logs -f pytorch-distributed-train-chief-0

  4. 查看结果：训练完成后，通过 PVC 挂载的存储获取模型 /checkpoint

核心特点

  • 简单易上手，适合算法工程师调试代码

  • 无需关注分布式逻辑，聚焦模型本身

场景 2：多机多卡 PyTorch 分布式训练（生产级）

目标

用 4 机 8 卡训练大模型，保证任务整组调度、容错

关键配置

  • PyTorchJob 中 Worker 设为 7，Chief 设为 1（总计 8 卡）

  • 指定 Volcano 调度器，开启 Gang Scheduling

  • 挂载分布式存储（如 JuiceFS/Ceph）保存 checkpoint

  • 配置资源限制：每个 Pod 1 卡，CPU/memory 按需分配

核心命令

bash

运行

# 提交作业
kubectl apply -f pytorch-distributed-8gpu.yaml

# 查看作业状态
kubectl get pytorchjob -n kubeflow

# 查看所有 Worker Pod
kubectl get pods -n kubeflow -l job-name=pytorch-distributed-train

核心特点

  • 分布式训练逻辑由 Kubeflow 封装，代码无需大幅修改

  • Volcano 保证 “要么 8 卡都调度成功，要么都不调度”，避免死锁

  • 节点故障时，K8s 自动重启 Pod，训练可从 checkpoint 续跑

场景 3：TensorFlow 推理服务部署（线上 API）

目标

将训练好的 TF 模型部署为 HTTP 服务，支持高并发、弹性扩缩容

步骤

  1. 用 Kubeflow KServe 定义模型服务：

    yaml

    apiVersion: serving.kubeflow.org/v1beta1
kind: InferenceService
metadata:
  name: tf-inference-service
  namespace: kubeflow
spec:
  predictor:
    tensorflow:
      storageUri: s3://model-bucket/tf-model/
      resources:
        limits:
          cpu: "4"
          memory: "8Gi"

  2. 提交服务：kubectl apply -f tf-inference-service.yaml

  3. 暴露服务：通过 Ingress/Nginx 暴露 HTTP 端口

  4. 配置 HPA：基于 QPS 自动扩缩副本数

核心特点

  • 模型服务化标准化，支持 REST/gRPC 接口

  • 弹性扩缩容，应对流量波动

  • 内置健康检查、熔断、灰度发布能力

场景 4：Kubeflow Pipeline 自动化训练 + 部署

目标

串起 “数据预处理 → PyTorch 训练 → 模型验证 → KServe 部署” 全流程

核心流程

  1. 用 Kubeflow Pipeline SDK 编写流水线脚本，定义 4 个步骤

  2. 打包流水线为容器镜像，提交到 Kubeflow

  3. 一键触发流水线，自动执行所有步骤

  4. 查看流水线进度、日志，监控每一步指标

核心特点

  • 全流程自动化，减少人工操作

  • 可复现、可追溯，每一步结果都有记录

  • 支持参数化，可批量执行不同超参的实验

四、进阶扩展：生产级优化与最佳实践

1. 性能优化
  • GPU 拓扑感知调度：优先调度同机架 / 同 NUMA 节点，减少跨节点通信延迟
  • RDMA 网络配置：多机分布式训练时，开启 RDMA 加速数据传输
  • 模型优化：训练时用混合精度（FP16/BF16），推理时用 TensorRT 量化
  • 数据加载优化：通过 Kubeflow 挂载分布式缓存，减少数据读取延迟
2. 容错与高可用
  • Checkpoint 策略：异步保存 checkpoint，避免阻塞训练
  • Pod 反亲和性：将 Worker 分散到不同节点，避免单点故障
  • 多可用区部署：跨可用区调度 Pod，提升集群容灾能力
  • 作业优先级：给核心训练任务设置高优先级，支持抢占低优先级任务资源
3. 可观测性
  • 部署 Prometheus + Grafana，监控：
    • GPU/NPU 利用率、显存占用
    • 训练 / 推理任务的 QPS、延迟、错误率
    • PyTorchJob/TFJob 的状态、排队时间、调度成功率
  • 日志收集：用 ELK/ Loki 收集 Pod 日志，便于问题排查
4. 多租户与资源管控
  • 部署 Kueue，为不同团队 / 业务设置资源配额
  • 通过 Namespace 隔离不同租户的 PyTorchJob/TFJob
  • 配置资源限制，防止单任务占用全部集群资源
5. 国产化适配（国内企业重点）
  • 替换 NVIDIA GPU 为国产 NPU（昇腾 / 寒武纪），部署对应的 Device Plugin
  • 适配国产 PyTorch/TensorFlow 分支（如昇腾 PyTorch）
  • 替换 Kubeflow 部分组件为国产化版本，兼容国产 K8s 发行版

总结

  1. 核心价值：Kubeflow 封装了 PyTorch/TensorFlow 在 K8s 上的分布式训练 / 推理逻辑，实现算力池化、弹性调度、规模化落地。
  2. 关键配置：通过 PyTorchJob/TFJob 定义 AI 作业，指定 GPU 资源、重启策略、调度器，是落地核心。
  3. 生产级重点：结合 Volcano 做 Gang 调度、分布式存储做 checkpoint、监控做可观测，是保证稳定性的关键。
  4. 进阶方向：自动化流水线、国产化适配、多租户管控，是企业规模化落地的必经之路。

  • 模型版本管理、实验跟踪

一、基础认知：为什么必须做「模型版本 + 实验跟踪」

1. 核心痛点
  • 模型越训越多：model.pt、model_new.pt、model_final.pt…
  • 不知道哪个超参对应哪个效果
  • 不知道模型用了哪批数据、哪段代码
  • 上线出问题，回滚都不知道滚到哪
2. 两个东西的定位
  • 实验跟踪：记过程记录：代码、参数、指标、日志、曲线…
  • 模型版本管理：管产物管理：模型文件、权重、格式、状态、生命周期…
3. 一句话总结

实验跟踪 = 训练过程黑盒变透明模型版本管理 = 模型文件像代码一样可追溯、可回滚

4. 和前面知识的关系

plaintext

数据版本 → 实验跟踪 → 模型版本 → 部署/回滚
（DVC）   （MLflow/W&B）（MLflow/Model Registry） （KServe/Triton）

二、核心配置：工具、能力、关键字段

（一）实验跟踪 Experiment Tracking
1. 核心目标
  • 每一次训练都可复现、可对比、可排查
2. 必须跟踪的内容
  • 超参：lr、batch size、epoch、优化器、正则
  • 环境：框架版本、CUDA、镜像 ID、代码 commit
  • 数据：数据集版本、路径、采样比例
  • 指标：loss、acc、AUC、F1、PPL…
  • 日志：loss 曲线、学习率曲线
  • 输出：checkpoint、模型文件
3. 主流工具
  • MLflow（开源、企业最常用）
  • Weights & Biases (W&B)（云服务、好用、可视化强）
  • Neptune、ClearML
  • Kubeflow + MLflow（云原生 AI 平台标配）
4. 最简代码示例（PyTorch + MLflow）

python

运行

import mlflow
import mlflow.pytorch

mlflow.set_experiment("bert-classify")

with mlflow.start_run(run_name="train_0315_lr2e5"):
    # 记录超参
    mlflow.log_param("lr", 2e-5)
    mlflow.log_param("batch_size", 64)
    mlflow.log_param("model_name", "bert-base")

    for epoch in range(10):
        loss = train_one_epoch()
        acc = eval_model()
        # 记录指标
        mlflow.log_metric("loss", loss, step=epoch)
        mlflow.log_metric("acc", acc, step=epoch)

    # 保存模型
    mlflow.pytorch.log_model(model, "model")
（二）模型版本管理 Model Version Management
1. 核心目标
  • 模型文件可存储、可版本、可 stage、可部署
2. 模型注册表核心能力
  • 版本号：v1、v2、v3…
  • 状态：
    • None → Staging（测试）→ Production（上线）→ Archived（归档）
  • 元数据：数据集、实验 ID、指标、提交人
  • lineage 血缘：数据 → 实验 → 模型 → 部署
3. 主流方案
  1. MLflow Model Registry（企业标配、开源、稳定）
  2. Kubeflow Model Registry（云原生、K8s 原生）
  3. BentoML / TorchServe（模型打包 + 版本一体）
  4. MinIO/S3 + 索引表（简易方案）
4. 模型版本核心字段
  • version：1/2/3…
  • run_id：关联实验跟踪
  • source：模型路径（s3://…）
  • status：Staging / Production / Archived
  • metrics：acc/auc/f1
  • tags：任务、模型结构、用途
（三）三者组合标准架构（你前面学的全串起来）

plaintext

数据（DVC/对象存储）
↓
实验跟踪（MLflow/W&B）
↓
模型版本（Model Registry）
↓
部署（KServe/Triton on K8s）

三、实操场景：真实工作怎么用

场景 1：算法调试 + 实验对比
  • 开一个 Experiment：yolov8-det
  • 每次训练一个 Run：
    • lr=1e-3 vs 2e-5
    • 不同数据增强
  • 直接看曲线对比，选出最优

工具：MLflow / W&B

场景 2：多团队、多任务、模型混乱
  • 每个模型进 Model Registry
  • 命名规范：
    • cv/det/yolov8
    • nlp/bert/intent-classify
  • 版本自动递增，不乱命名
场景 3：上线、灰度、回滚（最关键）
  1. 训练好 → 版本 v10 → 标记 Staging
  2. 测试通过 → 改为 Production
  3. 部署到 K8s（KServe/Triton）
  4. 出问题 → 一键回滚到 v9这就是 MLOps 最标准的上线流程
场景 4：Kubeflow + MLflow 一体化
  • Kubeflow 提交 PyTorchJob
  • 训练日志自动同步到 MLflow
  • 训练完自动注册模型版本
  • 一键部署到 KServe

四、进阶扩展：生产级能力

1. 实验跟踪进阶
  • 自动化日志：不用写代码，自动捕获参数、指标、硬件
  • 分布式训练多机日志聚合
  • 可视化 dashboard：对比、排序、筛选
  • 告警：loss 不下降、NAN、训练卡住
2. 模型版本进阶
  • 模型生命周期：自动清理旧版本、保留最佳
  • 模型格式统一：PyTorch → ONNX → TensorRT → 版本管理
  • 模型大小 / 加载速度 / 显存占用也做版本对比
  • 模型血缘：一键查到用了哪批数据、哪次实验
3. 云原生进阶（K8s + AI）
  • MLflow 部署在 K8s
  • 存储用 S3/MinIO/JuiceFS
  • 模型一键部署成 KServe 服务
  • 配合 Kubeflow Pipeline 全自动：数据 → 训练 → 实验 → 版本 → 部署
4. 企业级必备
  • 权限控制：谁能改 Production
  • 审计日志：谁上线、谁回滚、什么时候
  • 多环境：dev/test/prod 隔离
  • 与 CI/CD 打通：Git 提交自动训练、自动版本

极简总结（可直接背）

  • 实验跟踪：管过程，记录参数、指标、曲线，保证可复现。
  • 模型版本：管产物，版本号、状态、血缘、可上线可回滚。
  • 标配工具：
    • 开源：MLflow（实验 + 模型一体）
    • 云原生：Kubeflow + MLflow
  • 核心流程：实验 → 版本 → 部署 → 回滚

  • AIOps：智能监控、异常检测

一、基础认知：AIOps、智能监控、异常检测到底是什么

1. 一句话定位
  • AIOps：用 AI/ML 做 IT 运维自动化、智能化。
  • 智能监控：不只采集指标，还自动理解系统状态。
  • 异常检测：自动发现偏离正常的行为，提前预警故障。
2. 传统监控 vs 智能监控
  • 传统监控：设固定阈值（CPU>90%、延迟 > 500ms）→ 告警痛点：阈值难调、漏报、误报、不会自适应。
  • 智能监控（AIOps）：用算法学习正常模式 → 自动识别异常 → 根因定位 → 自愈。
3. 核心解决三大痛点
  1. 告警风暴：一堆报警，不知道看哪个。
  2. 阈值失效：流量一变、版本一更，阈值全乱。
  3. 排障慢：出问题要人一层层查，耗时久。
4. 适用数据类型（运维三大利器）
  • Metrics：指标（CPU、GPU、QPS、延迟、流量…）
  • Logs：日志（错误码、关键字、模式、异常栈）
  • Traces：链路（调用耗时、依赖、异常节点）

二、核心配置：架构、算法、流程、工具

1. 标准 AIOps 智能监控架构

plaintext

采集层：
  Prometheus / Telegraf / Filebeat / SkyWalking / 自研Agent
↓
存储层：
  Prometheus、Elasticsearch、ClickHouse、InfluxDB
↓
计算&特征层：
  时序预处理、归一化、滑动窗口、关联指标
↓
AI算法层：
  异常检测、根因分析、故障预测
↓
应用层：
  告警、降噪、排障、自愈、大屏
2. 异常检测核心算法（工程常用）
（1）静态 / 简单策略（基础）
  • 静态阈值、同比 / 环比、突升突降
  • 优点：快、稳定
  • 缺点：不智能
（2）时序预测类（最常用）
  • 算法：ARIMA、Prophet、LSTM、Temporal Fusion Transformer
  • 思路：学习历史规律 → 预测未来 → 偏离即异常
  • 适合：QPS、流量、延迟、CPU、GPU 利用率
（3）无监督异常检测
  • 算法：Isolation Forest、One-Class SVM、DBSCAN、AutoEncoder
  • 思路：正常样本很多，异常很少，自动找异类
  • 适合：日志异常、接口调用异常、未知模式
（4）指标关联 & 多维度异常
  • 思路：单指标正常，组合起来异常例：QPS 下降、延迟上升、错误率上升 → 一定是故障
  • 用于：根因定位、告警聚类
3. 智能监控核心能力
  1. 动态阈值自动学习业务波动，不用手动改。
  2. 异常识别突增、突降、周期性消失、毛刺、持续飘高。
  3. 告警降噪 / 聚合把 100 条报警合成 1 条，标出根因。
  4. 根因分析 RCA自动定位：哪个服务、哪个节点、哪个指标最先异常。
  5. 自愈重启、扩缩容、流量切走、限流。
4. 主流开源工具栈
  • 监控采集：Prometheus、Grafana、SkyWalking、ELK
  • AIOps 引擎：
    • Prometheus + 自定义 AI 规则
    • Elastic AIOps
    • Grafana Anomaly Detection
    • OpenSearch Anomaly Detection
    • M3DB、Chronosphere
  • 自研：Python + Prophet + LSTM + ClickHouse

三、实操场景：企业里真正怎么用

场景 1：K8s 容器 & 微服务智能监控
  • 监控对象：Pod、Node、GPU、Service、API
  • 智能能力：
    • 自动学习 CPU / 内存 / GPU 负载曲线
    • 自动识别：突死、重启风暴、负载异常、网络抖动
  • 输出：只报真实故障，不误报。
场景 2：AI 训练集群异常检测（你最相关）
  • 对象：GPU 利用率、NPU 温度、显存、网卡、训练进程
  • 异常类型：
    • GPU 利用率突然掉 0 → 卡死 / 死循环
    • 显存持续上涨 → 泄漏
    • 网络流量异常 → NCCL 断连
  • AIOps 动作：自动重调度、重启任务、告警。
场景 3：业务指标异常（QPS、订单、在线人数）
  • 传统：设死阈值，大促 / 活动全炸告警。
  • AIOps：
    • 学习周期（天 / 周 / 月）
    • 识别：突跌、流量异常、峰值消失
  • 作用：早发现宕机、被攻击、业务逻辑出错。
场景 4：日志异常检测（不用再 grep）

  • 做法：

    • 向量化日志 → 无监督学习 → 识别新异常模式
  • 场景：
    • 突然出现新错误码
    • 错误日志暴增
    • 关键日志消失（服务假活）
场景 5：告警聚合 & 根因定位（救命功能）
  • 故障发生 → 100+ 告警
  • AIOps 做：
    1. 按时间、拓扑、指标关联
    2. 找出最先异常的那个指标 / 服务
    3. 只推一条：根因 + 影响范围 + 建议操作

四、进阶扩展：生产级 AIOps 能力

1. 时序预测 & 故障预测
  • 不只发现已发生异常
  • 预测：
    • 磁盘几天后满
    • CPU/GPU 未来负载
    • 流量未来峰值
  • 动作：提前扩容、清理、迁移。
2. 知识图谱 & 故障拓扑
  • 把：服务→容器→节点→GPU→存储→网络 画成依赖图
  • 异常传播自动追踪：A 异常 → B 异常 → C 异常直接定位源头 A。
3. 自愈闭环（AIOps 最高阶）

plaintext

异常检测 → 根因定位 → 自动执行预案 → 验证恢复

例：API 延迟异常 → 定位某 Pod → 自动重启 / 扩容 → 恢复后关闭告警

4. 大模型 AIOps（最新方向）
  • LLM 做：
    • 自然语言查监控：“昨天下午系统为什么抖动”
    • 自动分析日志、指标、链路
    • 自动生成排障报告
  • 趋势：LLM + 传统异常检测 = 下一代运维
5. 落地难点（面试 / 架构必说）
  • 标注数据少：故障少，无标签
  • 方案：无监督、弱监督、迁移学习
  • 业务多变：活动、版本、促销
  • 方案：在线学习、短期模型、滑动窗口
  • 误报代价高
  • 方案：多模型投票、人工确认闭环

极简总结（可直接背）

  • AIOps：AI 做运维，核心是智能监控 + 异常检测。
  • 智能监控：动态阈值、自动学习、不依赖人工配置。
  • 异常检测：时序预测、无监督、多维度关联，识别故障。
  • 架构：采集 → 存储 → AI 算法 → 告警 / 降噪 / 自愈。
  • 价值：减少误报、缩短排障时间、提高稳定性。

7. 大模型云原生部署架构

  • LLM 推理服务：vLLM、TGI、TensorRT-LLM

一、基础认知：定位与核心差异

1. vLLM
  • 定位：伯克利开源的高并发、高吞吐推理引擎，主打显存极致利用与大规模并发服务，是开源社区最流行的推理框架之一。
  • 核心技术：
    • PagedAttention：借鉴操作系统分页机制，将 KV 缓存拆分为固定大小块，动态分配显存，利用率从传统 60% 提升至95%+，碎片率 < 4%。
    • Continuous Batching：连续批处理，实时接纳新请求、复用空闲显存，GPU 空闲时间减少 70%，吞吐量为原生 Transformers 的10–24 倍。
  • 核心优势：模型兼容性极强（支持 Llama、Mistral、Qwen 等 30 + 主流模型）、API 兼容 OpenAI、支持多 GPU 张量并行、社区活跃。
  • 适用画像：高并发 API 服务、企业级聊天机器人、批量内容生成，追求吞吐优先、快速部署。
2. TGI（Text Generation Inference）
  • 定位：HuggingFace 官方出品的生产级推理服务，主打稳定性、生态兼容性、开箱即用，是 HF 生态的标准推理方案。
  • 核心技术：
    • 基于transformers与accelerate深度优化，原生支持 HF 模型格式。
    • 内置动态批处理、流式输出、请求排队、优雅降级，适配企业级运维。
    • 支持量化（INT4/INT8）、张量并行、模型热加载与 A/B 测试。
  • 核心优势：与 HF 生态无缝集成、部署简单、监控完善、商业支持成熟，适合快速落地 HF 模型。
  • 适用画像：依赖 HF 生态的企业、标准 API 服务、快速验证模型、需要稳定运维的场景。
3. TensorRT-LLM（TRT-LLM）
  • 定位：NVIDIA 官方推出的极致低延迟推理引擎，主打硬件级优化，专为 NVIDIA GPU（A100/H100）打造，追求单请求最低延迟。
  • 核心技术：
    • 基于 TensorRT 编译器，对 LLM 算子（Attention、FFN）做图优化、算子融合、量化（FP8/INT4/INT8）， latency 较通用框架降低30%–50%。
    • 支持多 GPU 流水线并行、张量并行、专家并行，适配超大模型（70B+）。
    • 提供 C++/Python API，支持自定义插件与算子优化。
  • 核心优势：NVIDIA GPU 上延迟最低、硬件利用率最高、适合实时性要求极高的场景。
  • 适用画像：金融实时风控、自动驾驶交互、工业级低延迟服务，延迟优先、NVIDIA 专属。
三者核心对比表

表格

维度 vLLM TGI TensorRT-LLM
开发主体 伯克利 HuggingFace NVIDIA
核心目标 高吞吐、高并发 稳定、生态兼容 极致低延迟、硬件优化
显存管理 PagedAttention（95%+ 利用率） 标准动态批处理 TensorRT 显存优化
硬件支持 NVIDIA/AMD（ROCm） NVIDIA/TPU/Gaudi 仅 NVIDIA（A100/H100 最优）
部署难度 中（Python 为主） 低（开箱即用） 高（需编译、CUDA 深度优化）
生态 开源活跃、OpenAI 兼容 HF 原生、商业支持 NVIDIA 生态、企业级定制
典型性能 吞吐最高 均衡稳定 延迟最低

二、核心配置：环境、参数与部署

1. vLLM 核心配置
（1）环境要求
  • 硬件：NVIDIA GPU（算力≥7.0，推荐 A100/H100）；7B 模型≥16GB 显存，70B≥80GB 显存。
  • 软件：Python 3.8–3.12、CUDA 11.8+、PyTorch 2.1+。
（2）关键部署参数

bash

运行

# 启动OpenAI兼容API服务（核心参数）
python -m vllm.entrypoints.openai.api_server \
  --model meta-llama/Meta-Llama-3-8B \  # 模型路径
  --tensor-parallel-size 2 \            # 多GPU张量并行
  --dtype float16 \                     # 精度（fp16/bf16/int4）
  --max-model-len 4096 \                 # 最大上下文长度
  --quantization awq \                   # 量化（awq/gptq/int8）
  --port 8000 \                          # 服务端口
  --gpu-memory-utilization 0.95          # GPU显存利用率上限
（3）核心 API 与调用
  • 支持Python 离线调用与OpenAI 兼容 HTTP API，可直接用 OpenAI 客户端对接。
  • 示例调用：

python

运行

from openai import OpenAI
client = OpenAI(base_url="http://localhost:8000/v1", api_key="dummy")
response = client.chat.completions.create(
  model="Meta-Llama-3-8B",
  messages=[{"role": "user", "content": "讲个笑话"}]
)
2. TGI 核心配置
（1）环境要求
  • 硬件：NVIDIA GPU/TPU/Gaudi；7B 模型≥12GB 显存。
  • 软件：Python 3.9+、CUDA 11.7+、text-generation-inference包。
（2）关键部署参数（Docker 推荐）

bash

运行

# Docker启动TGI服务
docker run -d --gpus all \
  -p 8080:80 \
  ghcr.io/huggingface/text-generation-inference:latest \
  --model-id meta-llama/Meta-Llama-3-8B \
  --num-shard 2 \          # 多GPU分片
  --quantize bitsandbytes-nf4 \  # 4bit量化
  --max-batch-size 128 \   # 最大批处理大小
  --max-total-tokens 8192  # 总令牌上限
（3）核心特性
  • 内置监控（Prometheus）、日志、健康检查、优雅重启，企业级运维友好。
  • 支持流式输出、批量推理、模型热切换，适配 HF 生态全流程。
3. TensorRT-LLM 核心配置
（1）环境要求
  • 硬件：仅 NVIDIA GPU（A100/H100/L40S 最优）；7B 模型≥16GB 显存，70B≥80GB 显存。
  • 软件：CUDA 12.0+、TensorRT 8.6+、Python 3.9+、tensorrt_llm包。
（2）核心流程：模型编译 + 部署

TRT-LLM 需先将 HF 模型编译为 TensorRT 引擎（耗时但性能最优），再部署服务。

bash

运行

# 1. 编译Llama 3 8B为TRT引擎
python examples/llama/build.py \
  --model_dir meta-llama/Meta-Llama-3-8B \
  --dtype float16 \
  --use_gpt_attention_plugin \
  --output_dir ./trt_engines/llama-8b

# 2. 启动TRT-LLM服务
python examples/llama/run.py \
  --engine_dir ./trt_engines/llama-8b \
  --max_batch_size 64 \
  --port 9000
（3）核心优势
  • 编译后推理延迟最低，单请求首 token 可低至50ms 内（H100）。
  • 支持FP8 量化、专家并行、流水线并行，超大模型推理效率最高。

三、实操场景：选型与落地案例

1. vLLM 核心场景
（1）高并发 API 服务（电商 / 金融客服）
  • 需求：每秒处理数百–数千用户请求，支持多轮对话，显存高效利用。
  • 落地：用 vLLM 部署 Llama 3 70B，2×A100 张量并行，支持500 + 并发，吞吐达2000+ tokens/sec，首字延迟 < 200ms。
  • 优势：PagedAttention 大幅降低显存成本，相同硬件支撑更多用户。
（2）批量内容生成（文案 / 代码 / 翻译）
  • 需求：批量处理数千条文本生成，追求总处理速度。
  • 落地：离线模式批量调用 vLLM，设置大 batch size，利用连续批处理，吞吐较原生提升 15 倍，单日处理 10 万 + 请求。
（3）多模型 A/B 测试
  • 需求：同时部署多个模型（如 Llama 3、Qwen、Mistral），对比效果。
  • 落地：vLLM 支持多模型并行，通过 API 路由切换，快速验证模型优劣。
2. TGI 核心场景
（1）HF 生态快速落地（创业公司 / 研究团队）
  • 需求：快速部署 HF 开源模型，无需复杂优化，稳定提供 API 服务。
  • 落地：Docker 一键启动 TGI，对接 Llama 3、Qwen 等，内置监控与日志，1 小时内上线生产服务。
（2）企业级标准推理服务
  • 需求：稳定、可观测、易运维，支持灰度发布与 A/B 测试。
  • 落地：TGI 配合 HF Hub，实现模型版本管理、热加载，对接 Prometheus 监控，满足企业 SLA 要求。
（3）跨硬件兼容部署
  • 需求：在 NVIDIA/TPU/Gaudi 上统一部署，降低迁移成本。
  • 落地：TGI 原生支持多硬件，相同配置适配不同芯片，无需修改代码。
3. TensorRT-LLM 核心场景
（1）极致低延迟实时交互（金融 / 自动驾驶）
  • 需求：单请求首字延迟 < 100ms，支持实时决策（如风控、语音交互）。
  • 落地：TRT-LLM 编译 Llama 3 8B，H100 单卡，首 token 延迟 **<60ms**，满足实时性要求。
（2）超大模型推理（70B+）
  • 需求：部署 70B/400B 模型，在有限 GPU 下实现低延迟。
  • 落地：TRT-LLM + 张量 / 流水线并行，4×H100 部署 Llama 3 70B，延迟较 vLLM 降低 40%，适合核心业务场景。
（3）硬件级定制优化（工业 / 军工）
  • 需求：深度优化算子，适配专用硬件，追求极致性能。
  • 落地：基于 TRT-LLM 开发自定义插件，融合行业专属算子，性能较通用方案提升50%+。

四、进阶扩展：性能调优与生态集成

1. vLLM 进阶玩法
（1）性能调优
  • 显存优化：开启--gpu-memory-utilization 0.95，配合--quantization awq/gptq，7B 模型可在 12GB 显存运行。
  • 多 GPU 扩展：--tensor-parallel-size N实现张量并行，--pipeline-parallel-size M实现流水线并行，适配超大模型。
  • 超长上下文：设置--max-model-len 16384，支持长文档理解与生成。
（2）生态集成
  • 对接Ray Serve实现分布式服务与负载均衡，支撑万级并发。
  • 兼容LangChain/LlamaIndex，快速构建 RAG、Agent 应用。
2. TGI 进阶玩法
（1）企业级运维
  • 开启Prometheus 监控，采集延迟、吞吐、错误率，对接 Grafana 可视化。
  • 配置请求限流、排队、优雅降级，保障高并发下服务稳定。
（2）模型优化
  • 结合HF Transformers的bitsandbytes/auto-gptq量化，在低显存硬件部署大模型。
  • 支持LoRA 加载，快速微调并部署定制化模型。
3. TensorRT-LLM 进阶玩法
（1）极致性能优化
  • FP8 量化：在 H100 上开启 FP8，性能提升 2 倍，显存减半，延迟进一步降低。
  • 算子融合：自定义 Attention/FFN 算子，减少内存访问， latency 降低30%+。
（2）分布式部署
  • 结合NVIDIA Triton Inference Server，实现模型编排、动态批处理、多模型服务，适配企业级生产环境。
  • 支持K8s 部署，弹性扩缩容，适配云原生场景。

总结

一、核心定位与差异化优势

三款工具的核心差异源于开发主体与目标场景的不同，形成 “吞吐、稳定、延迟” 三大核心方向：

  • vLLM（伯克利开源）：以 “高吞吐、高并发” 为核心，凭借 PagedAttention 显存优化技术（利用率 95%+）和连续批处理，成为开源场景下性价比首选，兼容 30 + 主流模型与 OpenAI API，适配高并发 API 服务、批量内容生成等场景。
  • TGI（HuggingFace 官方）：主打 “稳定兼容、开箱即用”，深度集成 HF 生态，支持多硬件（NVIDIA/TPU/Gaudi），内置监控、日志、热加载等企业级运维特性，适合依赖 HF 模型的快速落地、标准 API 服务与稳定运维场景。
  • TensorRT-LLM（NVIDIA 官方）：聚焦 “极致低延迟、硬件优化”，通过 TensorRT 编译器的算子融合、量化（FP8/INT4）等硬件级优化，成为 NVIDIA GPU（A100/H100 最优）上的性能天花板，适配实时风控、自动驾驶交互等低延迟核心场景。
二、核心配置与部署关键
  • vLLM：中等部署难度，依赖 NVIDIA GPU（算力≥7.0），支持张量并行与多量化方案，通过 Python API 或 OpenAI 兼容接口启动，核心参数聚焦显存利用率、上下文长度与并行规模，兼顾灵活性与高性能。
  • TGI：低部署难度，推荐 Docker 一键启动，支持模型分片、量化与流式输出，原生对接 HF Hub 与 Prometheus 监控，无需复杂优化即可满足企业级 SLA 要求。
  • TensorRT-LLM：高部署难度，仅支持 NVIDIA GPU，需先将模型编译为 TensorRT 引擎，支持张量 / 流水线 / 专家并行，适合具备 CUDA 优化能力的团队，追求硬件极致利用率。
三、实操场景与选型逻辑
  • 选vLLM：高并发 API、批量生成、多模型 A/B 测试，追求 “吞吐优先 + 开源灵活”，硬件成本可控。
  • 选TGI：HF 生态模型快速落地、企业级稳定运维、跨硬件部署，追求 “省心高效 + 生态兼容”。
  • 选TensorRT-LLM：实时性核心业务、超大模型（70B+）部署、NVIDIA 硬件专属场景，追求 “延迟最低 + 性能极致”。
四、核心结论

三款工具覆盖了 LLM 推理的主流场景需求：vLLM 是 “通用高性价比” 首选，TGI 是 “生态兼容稳定” 首选，TensorRT-LLM 是 “NVIDIA 硬件低延迟” 首选。选型核心需围绕 “并发规模、延迟要求、硬件环境、生态依赖” 四大维度，结合自身技术实力与业务场景决策；进阶阶段可通过量化、分布式并行、生态集成（Ray/K8s/Triton）进一步提升性能与可用性。

五、选型建议
  1. 高并发、吞吐优先、开源生态 → 选vLLM（最通用、性价比最高）。
  2. HF 生态、快速落地、稳定运维 → 选TGI（开箱即用、商业支持完善）。
  3. NVIDIA 专属、极致低延迟、超大模型 → 选TensorRT-LLM（性能天花板）。

  • 模型服务化、流式输出、多模型编排

一、基础认知：核心概念与价值

1. 模型服务化
  • 定义：将本地离线运行的 LLM 转化为可网络访问、高可用、可监控、可扩展的标准化 API 服务，是 LLM 从实验室走向生产环境的核心环节。
  • 核心价值：
    • 解耦模型推理与业务逻辑，支持多端（前端 / 后端 / APP）统一调用；
    • 提供高并发、容错、限流等生产级能力，保障服务稳定性；
    • 标准化 API 接口（OpenAI/HF 规范），降低业务集成成本。
  • 各引擎定位：
    • vLLM：OpenAI 兼容 API 为主，灵活适配现有生态；
    • TGI：企业级标准化 API，内置运维能力；
    • TensorRT-LLM：需集成 Triton 实现服务化，追求极致性能。
2. 流式输出
  • 定义：模型生成文本时逐 token 实时返回结果（而非等待完整生成），是优化用户交互体验的核心特性。
  • 核心价值：
    • 降低用户感知延迟（如聊天场景 “边打边显”），提升交互流畅度；
    • 减少长文本生成的等待时间，适配实时对话、语音交互等场景；
    • 支持中途终止生成，节省算力资源。
  • 各引擎定位：
    • vLLM/TGI：原生支持，API 参数一键开启；
    • TensorRT-LLM：需手动实现，但首 token 延迟最低（NVIDIA GPU 优势）。
3. 多模型编排
  • 定义：在一套推理服务中统一管理多个 LLM（如 Llama 3、Qwen、Mistral），实现动态路由、A/B 测试、热切换、负载均衡。
  • 核心价值：
    • 适配多业务场景（不同用户 / 任务用不同模型）；
    • 支持模型迭代验证（灰度发布、A/B 测试）；
    • 提高硬件利用率（统一调度多模型算力）。
  • 各引擎定位：
    • vLLM：轻量多模型支持，适合简单场景；
    • TGI：内置模型版本管理，适配企业级 A/B 测试；
    • TensorRT-LLM+Triton：高性能多模型调度，适合复杂生产场景。
核心对比表

表格

能力维度 核心目标 vLLM 特性 TGI 特性 TensorRT-LLM 特性
模型服务化 标准化、高可用 API OpenAI 兼容，中等部署难度 开箱即用，运维友好 需 Triton 集成，性能极致
流式输出 降低感知延迟 原生支持，首 token~100ms 原生支持，首 token~150ms 手动实现，首 token~50ms
多模型编排 统一调度、灵活切换 单服务多模型，基础路由 模型热加载、灰度发布 Triton 集成，高性能调度

二、核心配置：环境、参数与实现

1. 模型服务化 核心配置
（1）环境要求

表格

引擎 硬件要求 软件依赖 部署核心工具
vLLM NVIDIA GPU（算力≥7.0） Python 3.8+、CUDA 11.8+ Python API、Prometheus（可选）
TGI NVIDIA/TPU/Gaudi Docker、CUDA 11.7+ Docker、HF SDK、Prometheus
TensorRT-LLM NVIDIA GPU（A100/H100 最优） CUDA 12.0+、TensorRT 8.6+ Triton Inference Server、TRT 引擎编译器
（2）关键配置示例
▶ vLLM 服务化配置（OpenAI 兼容）

bash

运行

# 核心启动命令（带监控+限流）
python -m vllm.entrypoints.openai.api_server \
  --model meta-llama/Meta-Llama-3-8B \
  --tensor-parallel-size 2 \          # 多GPU并行
  --port 8000 \                        # API端口
  --enable-metrics \                   # 开启监控指标
  --metrics-port 9090 \                # 监控端口
  --max-num-batched-tokens 8192 \      # 批处理令牌上限（限流）
  --served-model-name llama3-8b        # 自定义模型别名
▶ TGI 服务化配置（企业级）

bash

运行

# Docker启动（含监控+限流+日志）
docker run -d --gpus all \
  -p 8080:80 -p 9090:9090 \
  -v ./tgi-logs:/var/log/tgi \        # 日志挂载
  ghcr.io/huggingface/text-generation-inference:latest \
  --model-id meta-llama/Meta-Llama-3-8B \
  --num-shard 2 \                      # 多GPU分片
  --max-batch-size 64 \                # 最大批处理数
  --max-requests 1000 \                # 最大并发请求数
  --enable-prometheus-metrics \        # 内置监控
  --timeout 30                         # 请求超时时间
▶ TensorRT-LLM 服务化配置（Triton 集成）

bash

运行

# 1. 编译TRT引擎（前置步骤）
python examples/llama/build.py \
  --model_dir ./llama-3-8b \
  --dtype float16 \
  --output_dir ./trt-engine

# 2. 启动Triton服务（多模型支持）
tritonserver \
  --model-repository ./triton-models \  # 模型仓库（含多个TRT引擎）
  --grpc-port 8001 \                    # gRPC端口
  --http-port 8000 \                    # HTTP端口
  --metrics-port 8002                   # 监控端口
2. 流式输出 核心配置
（1）核心参数

表格

引擎 流式开启参数 关键调优参数 实现方式
vLLM stream=True（API 调用时） max_tokens（生成长度）、temperature OpenAI 兼容 SDK
TGI stream=True（SDK 调用时） max_new_tokens、top_p HF text-generation SDK
TensorRT-LLM 手动循环生成 max_new_tokens、stop_token TRT-LLM Python API 逐 token 生成
（2）关键配置示例
▶ vLLM 流式输出配置（Python 调用）

python

运行

from openai import OpenAI
client = OpenAI(base_url="http://localhost:8000/v1", api_key="dummy")

# 流式调用核心配置
stream = client.chat.completions.create(
  model="llama3-8b",
  messages=[{"role": "user", "content": "写一段关于AI的短文"}],
  stream=True,          # 开启流式
  max_tokens=512,       # 最大生成长度
  temperature=0.7,      # 随机性
  stream_options={"include_usage": True}  # 流式返回用量信息
)
▶ TGI 流式输出配置（Python 调用）

python

运行

from text_generation import Client
client = Client("http://localhost:8080")

# 流式调用核心配置
stream = client.generate_stream(
  prompt="写一段关于AI的短文",
  model="meta-llama/Meta-Llama-3-8B",
  stream=True,            # 开启流式
  max_new_tokens=512,     # 最大生成长度
  do_sample=True,         # 采样生成
  top_k=50                # 采样参数
)
3. 多模型编排 核心配置
（1）核心参数

表格

引擎 多模型加载参数 路由方式 热切换支持
vLLM --model 模型1 模型2 API 调用时指定model参数 不支持（需重启）
TGI --model-id 模型路径 + 模型仓库 API 指定model参数 / 版本号 支持（热加载）
TensorRT-LLM Triton 模型仓库配置 Triton API 指定model_name 支持（动态加载）
（2）关键配置示例
▶ vLLM 多模型编排配置

bash

运行

# 启动多模型API服务
python -m vllm.entrypoints.openai.api_server \
  --model meta-llama/Meta-Llama-3-8B qwen/Qwen-7B-Chat \  # 加载2个模型
  --tensor-parallel-size 2 \
  --port 8000 \
  --served-model-name llama3-8b qwen-7b  # 模型别名（调用时使用）
▶ TGI 多模型编排配置（热加载）

bash

运行

# 启动支持多模型的TGI服务
docker run -d --gpus all \
  -p 8080:80 \
  -v ./models:/models \  # 本地模型仓库（存放llama3-8b、qwen-7b）
  ghcr.io/huggingface/text-generation-inference:latest \
  --model-id /models/llama3-8b \  # 默认模型
  --allow-concurrent-downloads \  # 支持动态下载新模型
  --model-revision main \         # 模型版本管理
  --max-model-length 4096

三、实操场景：落地案例与选型

1. 模型服务化 实操场景
（1）高并发 API 服务（电商客服）
  • 需求：支撑每秒 500 + 用户咨询，要求 99.9% 可用性，可监控延迟 / 吞吐。
  • 选型：vLLM（OpenAI 兼容 + 高吞吐）。
  • 落地：2×A100 部署 vLLM，开启连续批处理 + Prometheus 监控，对接企业网关实现限流 / 熔断，吞吐达 2000+ tokens/sec，错误率 < 0.1%。
（2）企业级稳定推理服务（金融）
  • 需求：合规可审计、支持灰度发布、完善的日志 / 监控。
  • 选型：TGI（开箱即用 + 运维友好）。
  • 落地：Docker 部署 TGI，对接企业日志系统（ELK）、监控平台（Grafana），支持模型版本灰度切换，满足金融行业 SLA 要求。
（3）低延迟实时推理服务（自动驾驶）
  • 需求：单请求首 token 延迟 < 100ms，支持实时语音交互。
  • 选型：TensorRT-LLM+Triton（极致低延迟）。
  • 落地：H100 部署 TRT-LLM 编译后的引擎，Triton 提供服务化能力，首 token 延迟 < 60ms，满足自动驾驶实时交互要求。
2. 流式输出 实操场景
（1）聊天机器人（C 端产品）
  • 需求：用户提问后实时返回回答，边生成边显示，提升体验。
  • 选型：vLLM/TGI（实现成本低）。
  • 落地：前端通过 WebSocket 对接 vLLM 流式 API，逐 token 渲染文本，用户感知延迟降低 70%。
（2）实时语音转写 + 生成（智能音箱）
  • 需求：语音输入后实时生成回答，同步语音合成输出。
  • 选型：TensorRT-LLM（低延迟）。
  • 落地：TRT-LLM 流式生成 + 语音合成引擎联动，端到端延迟 <200ms，实现 “说完即答”。
3. 多模型编排 实操场景
（1）多模型 A/B 测试（产品迭代）
  • 需求：同时部署 Llama 3 v1 和 v2 版本，5% 流量切到 v2，验证效果。
  • 选型：TGI（模型版本管理 + 灰度发布）。
  • 落地：TGI 加载两个版本模型，通过 API 路由实现流量切分，实时统计两个版本的响应质量 / 延迟。
（2）多任务多模型调度（内容创作平台）
  • 需求：写文案用 Qwen，写代码用 CodeLlama，用户按需切换。
  • 选型：vLLM（轻量多模型 + OpenAI 兼容）。
  • 落地：vLLM 同时加载两个模型，前端选择模型类型，API 调用时指定model参数切换，无需多服务部署。
（3）高性能多模型调度（云服务商）
  • 需求：支撑上万并发，多模型动态调度，最大化 GPU 利用率。
  • 选型：TensorRT-LLM+Triton。
  • 落地：Triton 管理多个 TRT 引擎，基于硬件负载动态调度模型，GPU 利用率提升至 90%+。

四、进阶扩展：性能调优与生态集成

1. 模型服务化 进阶扩展
（1）性能调优
  • vLLM：调整gpu-memory-utilization（显存利用率）至 0.95，开启quantization awq量化，相同硬件支撑 2 倍并发。
  • TGI：开启quantize bitsandbytes-nf4 4bit 量化，调整max-batch-size至硬件最优值（如 A100 设为 128）。
  • TensorRT-LLM：开启 FP8 量化，自定义算子融合，延迟再降低 30%。
（2）生态集成
  • 对接K8s：实现服务弹性扩缩容，根据并发量自动增减 GPU 节点。
  • 对接API 网关（如 Kong/APISIX）：实现鉴权、限流、熔断、日志审计。
  • 对接分布式追踪（如 Jaeger）：定位请求全链路延迟瓶颈。
2. 流式输出 进阶扩展
（1）体验优化
  • 实现首 token 加速：vLLM 开启--enable-prefix-caching，缓存常用前缀，首 token 延迟降低 50%。
  • 支持中途终止：前端发送终止请求，后端停止生成并释放资源。
  • 优化渲染体验：前端对流式文本做断句处理，避免乱码 / 重复。
（2）性能调优
  • 调整prefetch-size（预取 token 数），平衡延迟与吞吐量。
  • 开启批量流式：多个流式请求合并批处理，提升 GPU 利用率。
3. 多模型编排 进阶扩展
（1）智能路由
  • 基于用户特征 / 任务类型自动选择模型（如付费用户用大模型，免费用户用轻量模型）。
  • 基于模型负载动态路由：将请求分配到负载较低的模型实例。
（2）资源调度
  • 模型预热：提前加载高频模型到 GPU 显存，避免冷启动延迟。
  • 显存共享：vLLM 开启--swap-space，低频模型自动换出到内存，节省显存。
  • Triton 动态批处理：多模型共享批处理队列，最大化 GPU 利用率。
（3）高级特性
  • 模型热更新：TGI/Triton 支持不重启服务更新模型版本，零停机迭代。
  • 多模型融合：将多个模型的输出融合（如 CodeLlama 生成代码 + Qwen 优化注释）。

总结

核心关键点
  1. 模型服务化：vLLM 胜在 OpenAI 兼容与灵活性，TGI 胜在开箱即用与运维友好，TensorRT-LLM+Triton 是 NVIDIA 硬件下的性能最优解，选型需结合生态依赖与运维能力。
  2. 流式输出：vLLM/TGI 实现成本极低，适合快速落地；TensorRT-LLM 需手动实现但延迟最低，适合实时性要求高的场景，核心价值是降低用户感知延迟。
  3. 多模型编排：vLLM 适合轻量场景，TGI 适配企业级 A/B 测试，TensorRT-LLM+Triton 是高性能多模型调度的首选，核心是统一算力调度与灵活路由。
落地建议
  • 快速验证、兼容 OpenAI 生态 → 优先选 vLLM；
  • 企业级稳定运维、依赖 HF 生态 → 优先选 TGI；
  • 极致性能、NVIDIA 硬件、复杂多模型调度 → 优先选 TensorRT-LLM+Triton；
  • 进阶阶段可通过量化、K8s 集成、智能路由进一步提升服务的性能与可用性。

  • 弹性扩缩容、流量调度、成本优化

一、基础认知：是什么、为什么重要

1. 弹性扩缩容
  • 是什么根据实时流量、排队长度、GPU 利用率，自动增加 / 减少推理实例（Pod / 容器 / 机器）。
  • 核心价值流量高峰不崩、流量低谷不浪费，保证SLA + 成本可控。
  • 和推理引擎关系vLLM / TGI / TRT-LLM 都是可扩容单元，真正做弹性的是 K8s + 监控 + 调度器。
2. 流量调度
  • 是什么把用户请求智能、公平、低延迟地分给不同模型 / 版本 / 实例 / 机器。
  • 核心能力负载均衡、灰度 / 金丝雀、A/B 测试、多模型路由、过载保护。
  • 和推理引擎关系引擎提供健康检查、队列长度、并发指标，网关 / 服务网格做流量分发。
3. 成本优化
  • 是什么在满足延迟 / 吞吐前提下，把 GPU 时费、显存占用、流量费用降到最低。
  • 核心手段量化、批处理优化、实例规格选择、闲置缩容、抢占式实例。
  • 和推理引擎关系vLLM（PagedAttention）、TGI（动态批处理）、TRT-LLM（编译优化）本身就是成本优化工具。

二、核心配置：怎么配、关键指标

1. 弹性扩缩容（核心配置）

底座：K8s + HPA / KEDA + Prometheus

  • 扩容触发指标
    • 请求排队长度
    • GPU 利用率
    • 单实例并发连接数
    • 平均首 token 延迟
  • 缩容策略
    • 冷却时间（避免抖动）
    • 最小实例数（保证保底能力）
  • 各引擎适配
    • vLLM / TGI：无状态，秒级扩缩容
    • TensorRT-LLM：引擎编译慢，更适合提前预热 + 固定副本 + 内扩并发
2. 流量调度（核心配置）

组件：API 网关 / Ingress / Service Mesh / 内部负载均衡

  • 路由规则
    • 按 model 字段路由（多模型）
    • 按用户等级 / 灰度比例路由
    • 按区域 / 机器就近路由
  • 限流 / 熔断
    • 最大并发请求数
    • 超时时间
    • 排队丢弃策略
  • 健康检查
    • /health /ready
    • 模型加载状态
    • GPU 健康状态
3. 成本优化（核心配置）

直接和三个引擎强绑定：

  • vLLM
    • --gpu-memory-utilization 0.95
    • --quantization awq/gptq
    • 连续批处理 + PagedAttention
  • TGI
    • --quantize bitsandbytes-nf4
    • --max-batch-size 动态调优
  • TensorRT-LLM
    • FP8 / INT4 量化
    • 算子融合
    • 多 GPU 并行效率最大化

通用成本配置：

  • 闲置实例自动缩为 0
  • 非核心服务用抢占式 GPU
  • 按错峰调度（离线任务夜间跑）

三、实操场景：落地长什么样

1. 弹性扩缩容
场景 1：客服机器人早晚上班高峰流量翻倍
  • 白天自动扩到 4 个 vLLM 实例
  • 深夜自动缩到 1 个实例
  • 突发流量 10s 内完成扩容
场景 2：ToB 企业服务，保证 SLA
  • TGI + K8s HPA
  • 以 队列长度 > 10 为扩容线
  • 延迟超过 200ms 自动扩容
场景 3：超大模型（70B）
  • TRT-LLM 不适合频繁扩缩容
  • 用固定副本 + 动态批处理提升内部弹性
2. 流量调度
场景 1：多模型统一入口
  • 用户传 model: qwen → 路由到 Qwen 实例
  • 用户传 model: llama3 → 路由到 Llama3 实例
  • 用 vLLM / TGI 统一部署，网关做分发
场景 2：灰度发布
  • 10% 流量到新版本模型
  • 90% 流量到稳定版
  • TGI 天然支持模型版本管理
场景 3：过载保护
  • 网关层直接拒绝超量请求
  • 避免把推理引擎打垮
3. 成本优化
场景 1：高并发对话服务
  • vLLM + AWQ 4bit 量化
  • 显存占用减半，吞吐提升 2～3 倍
  • 同样 GPU，成本直接砍半
场景 2：创业公司 / 小流量服务
  • TGI + 缩 0 策略
  • 白天 1 实例，夜间 0 实例
  • 节省 60%+ 云 GPU 费用
场景 3：核心低延迟服务
  • TRT-LLM + FP8
  • 性能提升，显存减半
  • 更少卡跑更高性能

四、进阶扩展：生产级高阶玩法

1. 弹性扩缩容 进阶
  • KEDA 基于事件扩容（排队长度、MQ 堆积）
  • Cluster Autoscaler 自动扩节点
  • 混合弹性：
    • 核心服务：固定副本
    • 突发流量：弹性副本
  • 预测式扩容：根据历史流量提前扩容
2. 流量调度 进阶
  • 全局负载均衡：多可用区 / 多地域
  • 权重路由 + 实时效果反馈效果好的模型自动加大流量
  • 请求优先级付费用户高优先级，免费用户排队
  • 请求合并 / 批处理：网关层做请求攒批
3. 成本优化 进阶
  • 模型分时复用白天服务，晚上做离线批量生成
  • 多模型共享 GPUvLLM 多模型同进程，显存更省
  • 存算分离 / 模型缓存避免重复下载、重复加载
  • 自动规格推荐根据延迟 / 吞吐自动选最合适的 GPU 型号

极简总结（方便你直接用）

  • 弹性扩缩容流量自动扩、闲置自动缩，靠 K8s + 监控，vLLM/TGI 最友好，TRT-LLM 偏预热固定副本。

  • 流量调度统一入口、按模型路由、灰度、限流、熔断，靠 网关 / 服务网格。

  • 成本优化引擎层：vLLM 省显存、TGI 易运维、TRT-LLM 极致效率调度层：量化 + 缩 0 + 抢占实例 + 错峰，整体成本可降 50%–90%

  • 私有化大模型平台架构

一、基础认知：什么是私有化大模型平台

1. 定义

私有化大模型平台 = 本地 / 内网部署 + 全链路可控 + 生产级服务把 LLM 从 “单个模型” 变成企业内部的AI 基础设施，所有数据、流量、权限、日志都不出内网。

2. 核心目标
  • 数据安全：不进公网、合规
  • 稳定可用：高并发、低延迟、可监控、可扩容
  • 统一入口：多模型、多任务、多业务共用一套平台
  • 成本可控：GPU 利用率最大化、弹性调度
3. 整体架构分层（标准企业级）

从上到下共 6 层：

  1. 接入层：网关、鉴权、限流、流量调度
  2. API 服务层：模型服务化、流式输出、OpenAI 兼容
  3. 推理引擎层：vLLM / TGI / TensorRT-LLM
  4. 模型管理层：多模型、版本、权重、量化
  5. 调度与弹性层：K8s、弹性扩缩容、负载均衡
  6. 数据与安全层：数据集、向量库、审计、权限

二、核心配置：完整架构组件清单

1. 接入层（入口）
  • 作用：统一入口、安全、流量控制
  • 核心组件
    • API 网关（Kong / Nginx / APISIX）
    • 鉴权（OAuth2 / LDAP / 内部账号）
    • 限流、熔断、重试
    • 日志与审计
  • 关键能力
    • 多模型统一路由
    • 灰度发布
    • 流量染色、优先级调度
2. API 服务层（服务化）
  • 作用：把推理引擎变成企业服务
  • 核心组件
    • OpenAI 兼容接口（/v1/chat/completions）
    • 流式输出 Server-Sent Events / WebSocket
    • 异步任务、批量生成
  • 必带能力
    • 多模型统一调用
    • 多轮对话管理
    • 日志、计费、限流、异常捕获
3. 推理引擎层（核心算力）

你前面学的三个全部用上：

  • vLLM：高吞吐、高并发、通用场景首选
  • TGI：HF 生态、稳定、运维简单
  • TensorRT-LLM：极低延迟、NVIDIA 极致性能
  • 统一提供：
    • 动态批处理
    • 流式输出
    • 多 GPU 并行
    • 量化（INT4/INT8/FP8）
4. 模型管理层（模型仓库）
  • 模型存储：本地硬盘 / 私有对象存储
  • 模型格式：
    • HF 格式
    • GGUF
    • TensorRT 引擎
  • 管理能力：
    • 版本管理（v1 → v2 → v3）
    • 量化自动转换
    • 模型预热、加载策略
5. 调度与弹性层（运维核心）
  • 底座：Kubernetes
  • 核心能力：
    • 多实例副本
    • HPA / KEDA 弹性扩缩容
    • GPU 调度、亲和性、隔离
  • 配套：
    • Prometheus + Grafana 监控
    • 日志（ELK / Loki）
    • 告警（邮件 / 企业微信 / 钉钉）
6. 数据与安全层（私有化灵魂）
  • 私有向量库：Milvus / Chroma / FAISS
  • 私有数据处理：文档解析、分块、入库
  • 安全：
    • 所有请求内网审计
    • 敏感词过滤
    • 输出审核
    • 权限分级（业务线 / 部门 / 用户）

三、实操场景：企业真正怎么用

场景 1：内部智能助手（聊天机器人）
  • 架构：网关 → API 服务 → vLLM → 内网模型
  • 特点：
    • 高并发
    • 流式输出
    • 多部门权限隔离
    • 日志可审计
场景 2：私有化 RAG 知识库（文档问答）
  • 架构：文档解析 → 向量库 → RAG 服务 → 推理引擎
  • 特点：
    • 数据 100% 不出内网
    • 支持 PDF/Word/Excel/ 网页
    • 支持多知识库隔离
场景 3：代码生成 / 代码审查
  • 架构：API 服务 → TGI /vLLM
  • 特点：
    • 长上下文
    • 高吞吐
    • 权限 + 代码安全审计
场景 4：核心业务低延迟交互（金融 / 工业）
  • 架构：TensorRT-LLM + Triton + K8s
  • 特点：
    • 首 Token < 100ms
    • 高可用
    • 无公网依赖
场景 5：多模型统一平台
  • 模型 A：对话
  • 模型 B：翻译
  • 模型 C：摘要
  • 模型 D：代码
  • 统一入口、统一权限、统一监控、统一计费

四、进阶扩展：生产级高阶能力

1. 弹性与高可用
  • 按排队长度自动扩缩容
  • 按流量潮汐自动调度
  • 多可用区部署，防止单点故障
  • 模型热更新，不停服升级
2. 流量调度高级版
  • 按用户等级路由（付费 / 免费 / 内部）
  • 按模型负载自动路由
  • 灰度、金丝雀、A/B 测试
  • 过载自动熔断、排队、降级
3. 成本优化（私有化最关键）
  • 量化：INT4/AWQ/GPTQ/FP8
  • 模型分时复用：白天服务、晚上训练 / 微调
  • 多模型共享 GPU
  • 闲置自动缩容 / 关机
  • 相同 GPU 下，vLLM 可提升吞吐 5–20 倍
4. 安全与合规
  • 全链路审计日志
  • 输入 / 内容过滤
  • 部门数据隔离
  • 不联网、不回传、不收集
5. 上层应用生态（可直接扩展）
  • 私有化 Agent 调度
  • 私有化工作流（Flow）
  • 私有化提示词管理
  • 私有化模型微调平台

总结

私有化大模型平台 = 内网部署 + 6 层企业级架构（接入→API→推理→模型→调度→安全），统一管理多模型、多业务、多权限，实现数据安全、高可用、弹性扩缩容、流量调度、成本最优，是企业 AI 能力的基础设施。

8. 架构设计与落地能力

  • 高可用、可扩展、灾备、成本优化

一、基础认知（先把概念讲透）

1. 高可用（HA）
  • 目标：减少 downtime，让服务尽量不挂
  • 衡量：可用性 = uptime / 总时间（99.9% / 99.99% / 99.999%）
  • 本质：消除单点故障（SPOF）
2. 可扩展（Scalability）
  • 目标：扛住流量 / 数据增长
  • 两类：
    • 垂直扩展：加配置（CPU / 内存 / 磁盘）
    • 水平扩展：加机器 / 加节点
  • 本质：架构能 “线性扩容”
3. 灾备（DR）
  • 目标：灾难后能恢复（机房炸、云区挂、数据丢）
  • 关键指标：
    • RPO：恢复点目标 = 最多丢多少数据
    • RTO：恢复时间目标 = 最多停多久
4. 成本优化
  • 目标：在不影响前三者的前提下省钱
  • 不是砍功能，是资源利用率 + 架构选型 + 付费模式优化

二、核心配置（落地必备项）

1. 高可用核心配置
  • 无状态应用：多实例 + 负载均衡（LB）
  • 有状态服务：主从 / 主主 / 集群（MySQL、Redis、MQ）
  • 入口层：多可用区（AZ）部署
  • 兜底：健康检查 + 自动重启 / 替换
2. 可扩展核心配置
  • 应用层：无状态化，支持水平扩容
  • 数据层：分库分表、读写分离、索引优化
  • 中间件：消息队列削峰、缓存抗热点
  • 弹性：自动扩缩容（HPA）
3. 灾备核心配置
  • 数据：定时全量 + 增量备份
  • 跨区域：跨可用区 / 跨地域同步
  • 恢复：演练脚本、一键切换、权限隔离
  • 分级：
    • 同城灾备（低 RTO/RPO）
    • 异地灾备（极端灾难）
4. 成本优化核心配置
  • 资源：规格匹配、闲置资源释放
  • 存储：冷热数据分层、压缩、归档
  • 计费：包年包月 + 按量 + 竞价实例组合
  • 监控：成本看板 + 资源利用率看板

三、实操场景（最实用的组合打法）

场景 1：普通业务（稳定优先）
  • HA：多 AZ + 主从
  • 扩展：手动扩容 + 缓存
  • 灾备：每日备份 + 跨 AZ
  • 成本：按量为主，核心资源包年
场景 2：电商 / 活动秒杀（流量突增）
  • HA：全链路无状态 + 多 AZ
  • 扩展：HPA 自动扩容 + 消息队列削峰 + 多级缓存
  • 灾备：实时同步 + 快速回切
  • 成本：活动期弹性扩容，平时缩容
场景 3：金融 / 核心数据（强安全）
  • HA：集群强一致、双活
  • 扩展：分库分表、读写分离
  • 灾备：同城双活 + 异地灾备，极低 RPO/RTO
  • 成本：优先可靠性，再做资源精细化
场景 4：中小团队 / 初创（省钱 + 够用）
  • HA：关键服务多实例
  • 扩展：垂直扩容为主 + 轻量水平
  • 灾备：定时备份 + 云厂商快照
  • 成本：闲置关停、低峰缩容、存储分层

四、进阶扩展（架构升级方向）

1. 高可用进阶
  • 服务治理：熔断、降级、限流、隔离
  • 混沌工程：主动注入故障，验证韧性
  • 自愈体系：自动故障转移、自动修复
2. 可扩展进阶
  • 微服务 / 服务网格
  • 云原生：K8s + 无服务器（Serverless）
  • 全局流量调度：多地域接入
3. 灾备进阶
  • 双活 / 多活架构（Active-Active）
  • 自动化灾备演练平台
  • 数据一致性校验、防勒索、防误删
4. 成本优化进阶
  • FinOps 成本责任制
  • 智能调度：低峰缩容、离线任务错峰
  • 资源超配回收、Spot 实例混部

极简总结（一句话版）

  • 高可用：不挂
  • 可扩展：能扛
  • 灾备：能救
  • 成本优化：不贵

  • 混合云 / 多云架构

一、基础认知：先把定义、区别、价值讲清楚

1. 混合云（Hybrid Cloud）

定义

  • 企业同时使用：
    • 私有云 / 自建 IDC（本地机房、VMware、OpenStack、物理机）
    • 公有云（阿里云、腾讯云、华为云、AWS、Azure 等）
  • 两者通过专线 / VPN打通，统一调度、统一管理。

核心特点

  • 云之间网络打通、资源协同、数据可流动
  • 不是 “本地一套、云上一套各玩各的”，而是一体架构

典型诉求

  • 核心数据、核心系统不敢上公有云（合规、安全、延迟）
  • 但需要公有云的弹性、算力、AI、大数据服务
2. 多云（Multi-Cloud）

定义

  • 同时使用两家及以上公有云
    • 例：阿里云 + 华为云
    • 例：AWS + Azure + 阿里云
  • 不一定有本地机房，纯多云也叫多云

核心目的

  • 避免厂商锁定（Vendor Lock-In）
  • 提升可用性：一家云挂了不影响全局
  • 价格、区域、服务能力择优使用
3. 混合云 vs 多云 一句话区别
  • 混合云：本地 + 公有云
  • 多云：A 公有云 + B 公有云
  • 混合多云：本地 + A 云 + B 云（企业最常见）
4. 为什么企业一定要上混合 / 多云？
  1. 合规与安全
    • 金融、政务、医疗：敏感数据必须留在本地
  2. 性能与延迟
    • 工业控制、实时交易：必须就近部署，低延迟
  3. 弹性削峰
    • 本地资源不够，用公有云临时扩容
  4. 避免被单一云厂商绑定
    • 议价权、迁移权、架构自主权
  5. 业务连续性 & 灾备
    • 单云故障，业务不中断
  6. 成本优化
    • 哪家便宜、哪家活动好用谁

二、核心配置：混合 / 多云真正落地的关键组件

1. 网络层（最核心，没有之一）
  • 专线：IDC ↔ 公有云（高稳定、低延迟、高安全）
  • VPN/IPsec：低成本打通
  • 云间互联：云 A ↔ 云 B 高速通道
  • 统一网段规划：不冲突、可路由
  • 统一 DNS：内部域名无论在本地还是云上都能解析

目标：所有云看起来像 “一个大局域网”

2. 统一身份与权限（IAM）
  • 一套账号密码，能管：
    • 本地 VM
    • 容器 K8s
    • 公有云 ECS / 数据库 / 对象存储
  • 统一权限、统一审计、统一操作日志
3. 统一资源管理层（云管平台 CMP）
  • 能在一个页面看到：
    • 本地有多少台机器
    • 阿里云多少台
    • 华为云多少台
  • 支持：
    • 统一创建 / 删除 / 重启
    • 统一监控告警
    • 统一成本展示
4. 数据层架构
  • 热数据：本地 / 核心云
  • 温数据：跨云同步
  • 冷数据 / 归档：对象存储（便宜云）
  • 数据库：
    • 主库本地 / 主云
    • 从库跨云做灾备 / 读负载
5. 应用与容器层（云原生标配）

以 Kubernetes 为核心：

  • 本地 K8s + 阿里云 ACK + 华为云 CCE 等
  • 统一容器镜像仓库
  • 统一发布、统一弹性、统一调度

这是多云最标准、最成熟的路径。

6. 安全层
  • 统一 WAF、防火墙、入侵检测
  • 统一漏洞扫描、合规检查
  • 统一日志中心（SIEM）
  • 密钥管理、加密统一

三、实操场景：企业真实怎么用？

场景 1：传统企业核心系统上云（混合云标配）
  • 本地：核心交易、ERP、数据库
  • 公有云：官网、电商、小程序、营销活动
  • 打通：订单、库存、用户数据实时同步
  • 价值：核心不动，前端灵活
场景 2：流量突增弹性扩容（混合云经典）
  • 平时：本地机房足够
  • 大促 / 秒杀 / 突发流量：
    • 应用瞬间扩容到公有云
    • 负载均衡自动分发流量
  • 价值：不用为峰值买一堆闲置服务器
场景 3：多云高可用（防单云挂掉）
  • 前端：多云 DNS / 全局流量调度
  • 应用：同时部署在 云 A + 云 B
  • 数据库：一主多从跨云
  • 任一云区域故障：自动切流量
  • 价值：极高可用，适合金融、电商核心
场景 4：成本最优多云
  • 计算：哪家便宜 / 有代金券用哪家
  • 存储：冷数据放最便宜的对象存储
  • 大数据 / AI：用算力性价比最高的云
  • 价值：同样性能，成本下降 20%~50%
场景 5：跨地域 / 出海业务
  • 国内：阿里云 / 腾讯云
  • 海外：AWS/Azure
  • 统一管理、统一数据同步
  • 价值：全球就近访问，合规当地数据要求

四、进阶扩展：高阶架构与未来方向

1. 云原生多云进阶
  • K8s + 服务网格（Istio）统一流量、灰度、熔断、限流，跨云透明
  • Serverless 多云不用管服务器，直接函数跨云运行
2. 混合云灾备与双活
  • 同城双活：本地 + 同城云节点
  • 异地灾备：本地 + 异地云
  • RPO 接近 0，RTO 分钟级
3. 多云成本治理（FinOps + 多云）
  • 统一看所有云的账单
  • 自动关机闲置资源
  • 自动选择最便宜的区域 / 机型
  • 预算、告警、分摊到部门
4. 安全与合规进阶
  • 等保 2.0、金融合规、数据本地化
  • 统一审计、全链路追溯
  • 防数据泄露、防越权
5. 未来趋势：分布式云 / 边缘云
  • 云厂商把 “云节点” 直接部署到你机房
  • 体验像公有云，物理在本地
  • 混合云变得更简单、更统一

极简总结（可直接背 ）

  • 混合云：本地 IDC + 公有云，稳与弹性兼顾
  • 多云：多公有云组合，防锁定、高可用、省成本
  • 核心能力：统一网络、统一管控、统一数据、统一安全
  • 最终目标：业务不被云绑定，资源按需流动，成本最优，可用性最高

  • 安全合规、等保、镜像安全、运行时防护

一、基础认知（先把四个东西是什么、关系是什么说清）

1. 安全合规

一句话：业务要符合法律、规定、标准。

  • 范围最大，是顶层要求
  • 包含：法律法规、行业规范、企业内控
  • 常见依据：
    • 《网络安全法》《数据安全法》《个人信息保护法》
    • 行业合规：金融合规、医疗合规、政务合规、等保

目标：不违法、不被罚、不泄露、不停业。

2. 等保（网络安全等级保护）

一句话：国家强制的 “网络安全考试”。

  • 中国特色、强制
  • 分 5 级，企业一般是 等保 2 级、等保 3 级
  • 流程：定级 → 备案 → 建设整改 → 测评 → 监督检查

等保不是产品，是一套完整制度 + 技术要求。你后面的镜像安全、运行时防护，都是为了过等保。

3. 镜像安全（容器云原生必备）

一句话：容器启动前，先把 “安装包” 查干净。镜像 = 容器的 “系统盘 + 应用包”

风险：

  • 带病毒、木马
  • 有高危漏洞
  • 有弱密码、后门
  • 用了过时、废弃组件

镜像安全 = 从源头堵死攻击。

4. 运行时防护

一句话：容器 / 主机跑起来之后，实时防入侵、防异常。保护运行中的：

  • 容器
  • 主机
  • 应用进程

防的是：

  • 暴力破解
  • webshell
  • 异常进程
  • 越权访问
  • 挖矿、勒索
  • 未授权外联
四者关系（超级重要，能直接讲架构）

安全合规 = 总目标等保 = 国内最核心的合规落地标准镜像安全 = 入口安全（左移）运行时防护 = 运行中安全（右防）

二、核心配置（实战怎么搭）

1. 安全合规 核心落地项
  • 资产梳理：哪些服务器、域名、数据
  • 权限最小化：账号、RBAC、审批
  • 数据分类分级：公开 / 内部 / 敏感 / 核心
  • 日志审计：全留存、可追溯
  • 漏洞管理：定期扫描、闭环修复
  • 应急响应：预案、演练、复盘
2. 等保 核心技术点（直接背）

等保 2.0 核心 5 个层面：

  1. 物理安全：机房门禁、监控、防火防水
  2. 网络安全：防火墙、WAF、访问控制
  3. 主机安全：杀毒、加固、口令、日志
  4. 应用安全：输入校验、权限、会话
  5. 数据安全：加密、脱敏、备份、防泄露

过等保，不是装个软件就行，是体系达标。

3. 镜像安全 核心配置
  • 镜像漏洞扫描（CVE 漏洞）
  • 恶意代码 / 木马检测
  • 镜像签名与验签（防止被掉包）
  • 禁止使用最新标签 latest（不可控）
  • 基线合规检查（端口、用户、目录权限）
  • 镜像仓库权限控制（私有仓库，禁止公开）
  • 只允许可信镜像启动（白名单）

工具常见：

  • Trivy、Clair、Harbor、阿里云 / 腾讯云镜像安全
4. 运行时防护 核心能力
  • 进程白名单：只允许合法进程跑
  • 文件防篡改：保护关键目录、配置、二进制
  • 网络行为监控：异常外联、异常端口
  • 容器行为基线：不该起的进程 → 拦不该写的目录 → 拦不该连的外网 → 拦
  • 入侵检测（IDS）、防御（IPS）
  • 日志上收 SIEM / SOC 平台

三、实操场景（企业真实怎么用）

场景 1：普通业务要过等保 2 级
  • 主机加固 + 防火墙
  • 日志留存 6 个月以上
  • 漏洞定期扫描
  • 简单运行时防护
场景 2：云原生 K8s 集群（必须全套）
  • CI/CD 阶段：镜像扫描
  • 仓库阶段：镜像签名
  • 部署阶段：白名单校验
  • 运行阶段：运行时防护
  • 全部日志 → 等保审计
场景 3：金融 / 政务 / 医疗（强合规）
  • 等保 3 级起步
  • 数据加密、脱敏、水印
  • 堡垒机、双因子认证
  • 运行时防逃逸、防提权
  • 定期等保测评、渗透测试
场景 4：被攻击后补救（典型）
  • 先切流量、隔离恶意容器
  • 运行时防护查入侵轨迹
  • 镜像仓库全量扫描
  • 整改漏洞、加固权限
  • 补齐合规日志

四、进阶扩展（架构师 / 安全专家视角）

1. 安全左移（DevSecOps）

安全越早越好：代码 → 构建 → 镜像 → 部署 → 运行每一步都做安全，而不是最后查。

2. 零信任架构

默认不信任，始终校验：

  • 身份认证
  • 权限动态判断
  • 环境安全检查
  • 持续信任评估
3. 容器安全全景
  • 镜像安全
  • 编排安全（K8s 加固）
  • 网络策略
  • 运行时防护
  • 主机安全
  • 数据安全
  • 合规审计
4. 安全运营（SOC）
  • 集中日志
  • 威胁情报
  • 实时告警
  • 自动响应
  • 合规报表（给等保用）

精简总结

  • 安全合规：不违法、符合规定。
  • 等保：国家强制的安全标准，必须过。
  • 镜像安全：容器启动前查干净，源头安全。
  • 运行时防护：跑起来后防入侵、防异常。

四件事合起来：从代码到运行，全程安全 + 满足等保 + 满足合规。

  • 真实场景架构方案：训练平台、推理平台、AI PaaS

一、基础认知：三者到底是什么关系？

先把概念一次性说死，不绕弯：

  • 训练平台（Training Platform）负责：喂数据 → 训模型 → 调参 → 出模型文件资源：GPU 密集、耗时久、不稳定、批量执行

  • 推理平台（Inference Platform）负责：把训好的模型 在线提供服务资源：低延迟、高并发、稳定、7×24

  • AI PaaS 平台负责：把训练、推理、数据、镜像、调度、权限、监控整合成 一套给算法 / 业务用的 “AI 操作系统”目标：让业务不用管底层 GPU、K8s、网络、存储

一句话关系

AI PaaS = 壳 + 管理训练平台 + 推理平台 = 核心引擎

二、整体真实架构（企业通用版）

顶层架构（极简）
  1. 接入层
    • 控制台、OpenAPI、SDK
  2. AI PaaS 管理层
    • 项目 / 权限 / 计费 / 镜像 / 数据集 / 任务管理
  3. 核心引擎层
    • 训练平台
    • 推理平台
  4. 底层资源层
    • K8s 容器云
    • GPU 池（NVIDIA A10/A100/H100…）
    • 存储（文件存储、对象存储、分布式存储）
    • 网络（高速 RDMA、VPC、安全组）

三、训练平台（真实架构）

目标
  • 支持算法工程师随便训模型，不用搭环境
  • 支持：单机训练、多机多卡分布式训练（DDP、DeepSpeed、Megatron）
核心模块
  1. 数据集管理
    • 数据上传、标注、版本管理
    • 数据脱敏、权限隔离
  2. 镜像管理
    • PyTorch、TensorFlow、MindSpore 等预置镜像
    • 自定义镜像 + 镜像安全扫描
  3. 任务管理
    • 单机训练任务
    • 分布式训练任务
    • 断点续训、自动重试
  4. 调度引擎（最关键）
    • GPU 队列、优先级、抢占式
    • 资源配额、多租户隔离
  5. 实验管理
    • 超参、指标、日志、模型版本
    • TensorBoard、可视化
  6. 模型仓库
    • 模型存储、版本、审批、发布到推理
真实技术栈（企业都这么用）
  • K8s + volcano / kubeflow / Volcano
  • Docker 镜像
  • 文件存储： JuiceFS、NAS、CPFS
  • 分布式训练：NCCL + RDMA
  • 日志：ELK、Prometheus + Grafana

四、推理平台（真实生产架构）

目标
  • 模型上线 快、稳、便宜、能扩缩容
  • 低延迟、高并发、可监控、可灰度
核心模块
  1. 模型上传 / 转换
    • 支持 TorchScript、ONNX、TensorRT、TRT-LLM
    • 自动优化、量化、加速
  2. 推理服务
    • 在线服务（Long-running）
    • 异步任务
    • 批量推理
  3. 网关 & 调度
    • 自动扩缩容（HPA）
    • 灰度、蓝绿、A/B 测试
    • 多模型路由
  4. 推理引擎
    • Triton、TorchServe、vLLM、TGI
    • 动态 batching、PagedAttention
  5. 监控 & 运维
    • QPS、延迟、错误率、GPU 利用率
    • 告警、日志、调用链
  6. 安全
    • 鉴权、限流、熔断、IP 黑白名单
最真实场景
  • 搜索推荐、CV 识别、OCR、TTS → 低延迟在线推理
  • 大模型对话 → vLLM / TGI + 流式输出
  • 离线批处理 → 异步任务

五、AI PaaS 平台（真正企业级）

定位

把上面所有东西包起来，给业务用的 “AI 工作台”

核心能力
  1. 多租户 & 组织隔离
    • 部门 / 项目 / 环境完全隔离
    • 配额、GPU 池化
  2. 统一控制台
    • 数据 → 训练 → 模型 → 推理 → 监控 → 计费
  3. 镜像 & 环境市场
    • 官方镜像、自定义镜像
    • 安全扫描、准入控制
  4. MLOps 全链路
    • 自动化训练
    • 自动化部署
    • 模型生命周期管理
  5. 监控 & 运维 & 成本
    • GPU 利用率报表
    • 闲置任务自动停止
    • 费用分摊到部门
  6. API 开放平台
    • 给业务系统调用 AI 能力
    • 鉴权、限流、日志审计
AI PaaS 存在的意义
  • 算法不用懂 K8s、存储、网络
  • 运维不用管每个模型
  • 管理层能看到：用了多少卡、花了多少钱、谁在用
  • 安全合规、等保、镜像安全、运行时防护全部集成

六、真实企业落地场景（你能直接讲）

场景 1：中小模型 + 推荐 / CV 类
  • 训练：单机 / 多机多卡
  • 推理：低延迟、高并发、自动扩缩容
  • AI PaaS：多项目隔离、简单运维
场景 2：大模型 LLM 训练 + 推理
  • 训练：千亿参数、分布式、RDMA、CheckPoint 管理
  • 推理：vLLM/TRT-LLM、流式输出、多实例负载均衡
  • AI PaaS：GPU 池化、高优先级调度、成本大盘
场景 3：政企 / 金融 / 政务（强合规）
  • 等保 3 级
  • 镜像安全扫描
  • 运行时防护
  • 数据不出域、权限严格
  • 审计日志全留存→ 全部跑在 AI PaaS 里
场景 4：混合云 / 多云 AI
  • 本地 IDC + 公有云 GPU
  • 统一 AI PaaS 管理
  • 本地训、云上推，或反过来
  • 弹性扩容到云

极简总结（可直接背）

  • 训练平台：负责把模型 “炼出来”重 GPU、分布式、批量、实验性强
  • 推理平台：负责把模型 “用起来”重稳定、低延迟、高并发、7×24
  • AI PaaS：负责把 AI 能力 “管起来、用得爽”多租户、权限、镜像、监控、成本、合规、全生命周期

三者合在一起 = 企业完整 AI 中台架构。

# 云原生 # kubernetes # 人工智能
Logo
开源鸿蒙跨平台开发者社区

开源鸿蒙跨平台开发社区汇聚开发者与厂商，共建“一次开发，多端部署”的开源生态，致力于降低跨端开发门槛，推动万物智联创新。

更多推荐

cover

开源鸿蒙 Flutter 实战｜深色模式切换保姆级教程（鸿蒙兼容 + 可直接运行）

avatar 开源鸿蒙跨平台开发者社区

AI-Agent记忆系统深度实战-3大范式源码对比与鸿蒙端实现

本文从Context Rot现象出发，源码级对比向量检索、压缩摘要、知识图谱三大记忆范式，自研实现混合记忆系统并部署到OpenHarmony设备端，实测Token消耗降低90%、检索准确率提升40%

avatar 开源鸿蒙跨平台开发者社区
cover

Flutter鸿蒙应用开发：文件上传功能集成实战（含兼容性适配）

avatar 开源鸿蒙跨平台开发者社区