📚 课程目录第3章生产环境部署规划

3. 生产环境部署规划

Velero 在生产环境中的部署规划，核心不是“把服务跑起来”，而是让备份与恢复能力在集群规模增长、命名空间隔离、资源竞争、节点故障和版本升级等条件下仍然可控。规划时建议先明确三个边界：备份对象边界（哪些命名空间、哪些资源类型）、资源消耗边界（CPU、内存、临时存储、对象存储带宽）、故障恢复边界（RTO/RPO 与可接受的降级状态）。这三个边界决定了后续的副本数、配额、亲和策略和插件选择。

集群规模与 Velero 组件容量估算

Velero 由服务端（velero deployment）、节点代理（node-agent DaemonSet，仅在使用文件系统备份时必需）和可选的维护任务（如 backup、restore、schedule、GC）组成。集群规模对容量的影响主要体现在三处：API 对象数量、备份时并发上传的卷数量、以及恢复时并发创建资源的速率。

一个可参考的估算方法是按“命名空间数 × 每命名空间平均资源数”估算 API 对象总量。例如某生产集群有 120 个命名空间，平均每个命名空间 400 个对象，则总量约 4.8 万对象。Velero 服务端默认内存 512Mi 在中小集群可用，但当对象数超过 5 万、且启用 --default-volumes-to-fs-backup 时，建议将 requests 提升到 1Gi、limits 2Gi，并设置 --client-burst 与 --client-qps 避免对 apiserver 造成压力。node-agent 的内存与并发卷数相关，可按每节点 512Mi～1Gi 预留。

# 示例：velero 服务端资源与并发参数（教学示例，非实测值）
resources:
  requests:
    cpu: 500m
    memory: 1Gi
  limits:
    cpu: "2"
    memory: 2Gi
# 启动参数
--client-qps=50
--client-burst=100
--default-volumes-to-fs-backup=false

命名空间隔离与资源配额

生产环境不建议把 Velero 与业务工作负载混部在同一命名空间。推荐单独创建 velero 命名空间，并通过 ResourceQuota 与 LimitRange 约束其资源上限，防止备份任务在高峰期挤占业务资源。同时，Velero 需要读取集群级资源（如 CRD、PV、StorageClass），因此其 ServiceAccount 需要相应的 ClusterRole 绑定，但应遵循最小权限原则，仅授予备份恢复所需的 API 组。

对于多租户集群，可通过 Velero 的 --namespace 与备份选择器实现逻辑隔离：不同团队的业务命名空间由不同的 Schedule 和 Backup 定义覆盖，避免一次全量备份把所有租户数据混在同一备份中。若需要更强的隔离，可考虑按租户部署独立的 Velero 实例，但会增加运维复杂度，需权衡。

高可用部署与节点亲和/容忍

Velero 服务端本身是无状态控制器，但同一时刻只应有一个活跃实例处理备份任务。生产环境建议将副本数设为 2，并配合 podAntiAffinity 让两个副本分布在不同节点，避免单节点故障导致备份中断。node-agent 是 DaemonSet，天然每节点一个，但应通过 nodeSelector 或 tolerations 控制其调度范围。

# 示例：velero 服务端反亲和与容忍（教学示例）
affinity:
  podAntiAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchLabels:
            app.kubernetes.io/name: velero
        topologyKey: kubernetes.io/hostname
tolerations:
  - key: "dedicated"
    operator: "Equal"
    value: "backup"
    effect: "NoSchedule"

如果集群中有专用备份节点池，可给节点打上 dedicated=backup:NoSchedule 污点，并让 Velero 与 node-agent 容忍该污点，从而把备份流量与业务流量在节点层面分开。对于 node-agent，还需注意其需要访问宿主机路径（如 /var/lib/kubelet/pods），因此通常需要 privileged 或特定 hostPath 挂载，规划时应确认安全策略允许。

插件选择与版本兼容矩阵

Velero 的功能依赖插件：对象存储插件（如 AWS、Azure、GCP、阿里云 OSS）、卷快照插件（如 CSI、AWS EBS）以及文件系统备份（内置 node-agent）。选择插件时，必须核对三组兼容性：Velero 版本 ↔ 插件版本、插件版本 ↔ Kubernetes 版本、插件版本 ↔ 云厂商 API/SDK 版本。例如 Velero 1.13 通常搭配 AWS 插件 1.9+、CSI 插件 1.9+，并支持 Kubernetes 1.25～1.29。升级时应先升级插件，再升级 Velero 服务端，且每次只跨一个次版本。

升级策略与验证要点

生产升级应遵循“先插件、后服务端、再 node-agent”的顺序，并在升级前完成一次完整备份与恢复演练。升级后重点验证：velero backup get 能正常列出历史备份、velero restore create --from-backup 能恢复一个测试命名空间、node-agent 日志无卷挂载错误、以及 Schedule 仍按预期触发。若使用 CSI 快照，还需确认 VolumeSnapshotClass 与插件版本匹配，避免恢复时快照无法回滚为 PVC。

规划阶段建议把“备份成功率、恢复耗时、对象存储用量、node-agent 并发卷数”作为四个核心观测指标，并在上线前用一次真实恢复演练校准 RTO/RPO，而不是仅依赖备份任务成功作为唯一判断依据。

综上，Velero 生产部署规划应围绕集群规模定容量、围绕命名空间定隔离与配额、围绕高可用定副本与调度、围绕插件与版本定兼容与升级路径。四者相互约束，任何一项单独优化都可能在其他维度引入风险，因此建议在变更前形成书面检查项，并在预生产环境完成一次端到端验证后再推广到生产集群。