1. 灾备准入概述
1.1 灾备准入的定义
灾备准入（Disaster Recovery Admission）是指在 Kubernetes 集群中，通过准入控制器（Admission Controller）对资源对象的创建、更新、删除操作进行拦截和校验，确保只有满足灾备策略要求的资源才能被持久化到 etcd 中。其核心目标是：在资源进入集群之前，强制附加灾备元数据、校验备份策略合规性、防止无保护资源上线。
关键定义：灾备准入 = 准入控制机制 + 灾备策略规则 + 备份资源模型校验。三者缺一不可。
灾备准入并非传统意义上的“备份执行”，而是备份策略的预检与强制注入层。它工作在资源创建/更新的 API 请求路径上，在对象被持久化之前完成以下三类检查：
- 元数据完整性检查：资源是否携带了必要的备份标签（如
velero.io/backup-policy）和注解（如velero.io/schedule-name）。 - 备份策略合规性检查：资源所属命名空间、资源类型、标签选择器是否匹配已定义的备份计划（Schedule）。
- 资源模型一致性检查：资源是否属于灾备资源模型中的“受保护资源类型”（如 PVC、Deployment、ConfigMap 等），且未包含被排除的敏感字段。
1.2 灾备准入在 Kubernetes 中的重要性
在 Kubernetes 原生架构中，准入控制器是 API Server 请求链路的最后一道防线。灾备准入将这一防线与备份策略深度绑定，解决了以下四个关键问题：
| 问题域 | 无灾备准入时的风险 | 有灾备准入后的收益 |
|---|---|---|
| 备份覆盖率 | 开发人员创建资源后忘记添加备份标签，导致资源“裸奔” | 强制注入备份标签，确保 100% 新资源纳入备份范围 |
| 策略一致性 | 不同团队使用不同的备份频率、保留期，恢复时策略混乱 | 统一校验备份计划是否存在、参数是否合规 |
| 资源模型冲突 | 备份了临时卷（EmptyDir）或挂载了 NFS 的 Pod，恢复后数据丢失 | 拒绝备份不支持的资源类型，提前暴露模型冲突 |
| 安全合规 | Secret 中的敏感数据被明文备份到对象存储 | 准入阶段标记敏感字段，触发 Velero 的加密或排除规则 |
实践建议：在集群初始化阶段就部署灾备准入 Webhook，配合 Velero 的 BackupStorageLocation 和 VolumeSnapshotLocation 一起配置，形成“先准入、后备份”的防御性架构。
下图展示了灾备准入在 Kubernetes API 请求链路中的位置及其与 Velero 备份引擎的交互关系：
1.3 灾备准入与备份恢复的关系
灾备准入与 Velero 备份恢复流程并非串行关系，而是策略层与执行层的协同关系。下表从五个维度对比两者的职责边界：
| 维度 | 灾备准入（策略层） | Velero 备份恢复（执行层） |
|---|---|---|
| 触发时机 | 资源创建/更新时（实时） | 按 Schedule 定时或手动触发（异步） |
| 作用对象 | 单个资源对象的 API 请求 | 一批资源对象的快照与持久化 |
| 核心操作 | 校验、注入、拒绝 | 备份、恢复、删除 |
| 数据流 | 仅操作元数据（不接触数据平面） | 操作数据平面（PVC 快照、对象存储） |
| 失败影响 | 资源无法创建，集群状态不变 | 备份失败，可能产生残留数据 |
常见误区：灾备准入不能替代 Velero 的备份执行。即使资源通过了准入校验，Velero 仍然可能因为存储后端不可用、快照配额不足等原因导致备份失败。准入只保证“策略合规”，不保证“备份成功”。
两者的协同工作流可以概括为以下四个步骤：
- 策略定义：运维团队在集群中创建 Velero Schedule 和 BackupStorageLocation，同时配置灾备准入 Webhook 的规则（如强制标签、允许的资源类型列表）。
- 准入校验：开发人员创建 Deployment 或 PVC 时，API Server 调用灾备准入 Webhook，校验资源是否满足策略要求。若不满足，返回拒绝信息并提示修复建议。
- 元数据注入：准入通过后，Webhook 自动为资源添加备份相关的标签和注解（如
velero.io/backup-policy: default），确保资源被 Velero 的标签选择器捕获。 - 备份执行：Velero 根据 Schedule 定时扫描集群，通过标签选择器匹配已注入元数据的资源，执行备份操作并将数据写入对象存储。
下图展示了灾备准入与 Velero 备份恢复的协同工作流：
核心结论：灾备准入是 Velero 备份策略的“守门员”，它确保只有符合策略的资源进入集群并被备份；Velero 是备份执行的“运动员”，负责将资源数据安全地持久化到远端。两者协同设计，才能构建完整的 Kubernetes 灾备体系。