3. Velero 准入场景定义
3.1 什么是准入场景
在 Kubernetes 生态中，准入场景（Admission Scenario）是指资源对象在持久化到 etcd 之前，由准入控制器（Admission Controller）拦截并执行校验、修改或策略强制的阶段。该场景位于 API 请求经过认证与授权之后、etcd 写入之前，是集群安全与合规的最后一道防线。
核心特征：准入场景是同步、阻塞的——控制器必须返回允许或拒绝的决策，API Server 才会继续处理请求。
准入场景分为两类：
| 类型 | 执行时机 | 典型用途 |
|---|---|---|
| Mutating（变更） | 先执行 | 注入 Sidecar、设置默认值、修正资源字段 |
| Validating（验证） | 后执行 | 检查资源合规性、禁止高危配置、验证灾备标签 |
Velero 在备份与恢复流程中，会主动与这两个阶段交互，确保备份数据的一致性与恢复后的集群合规性。
3.2 为何需要准入控制
没有准入控制的集群，任何具有 API 访问权限的客户端都可以直接创建或修改资源，导致以下风险：
- 配置漂移：关键资源（如 PVC、Namespace）缺少灾备标签，备份策略无法匹配。
- 安全漏洞：特权容器、hostPath 挂载等危险配置绕过审计。
- 数据不一致：备份前未执行预钩子（Pre-hook），导致文件系统快照处于脏状态。
- 恢复失败：恢复后的资源与集群现有策略冲突（如 Pod 安全标准、网络策略）。
灾备视角：准入控制确保每个被备份的资源都携带正确的
velero.io/backup-name 标签，且恢复时自动注入 velero.io/exclude-from-backup=true 避免循环备份。
准入控制带来的核心价值：
| 价值维度 | 说明 | Velero 关联 |
|---|---|---|
| 策略强制 | 确保所有资源符合组织灾备规范 | 强制备份标签、禁止未标记 Namespace 的创建 |
| 数据完整性 | 在备份前执行数据冻结操作 | 通过 Mutating Webhook 注入 Pre/Post-hook |
| 恢复一致性 | 恢复时自动调整资源以适配目标集群 | Validating Webhook 校验恢复后的资源合规性 |
| 审计与追溯 | 记录所有准入决策日志 | Velero 插件可输出准入审计事件 |
3.3 Velero 在准入场景中的角色
Velero 在准入场景中扮演双向适配器的角色：既作为准入 Webhook 的消费者（备份/恢复时触发），也作为准入策略的提供者（通过 Velero 插件扩展）。
关键定位：Velero 本身不实现完整的准入控制器，而是通过
Velero 插件（Plugin） 与 备份/恢复钩子（Hook） 机制，将准入能力嵌入到灾备工作流中。
具体角色分解：
- 备份准入角色：
- 在备份开始前，通过 Pre-backup Hook 执行数据冻结（如 Flush MySQL、冻结文件系统）。
- 在备份过程中，通过 Mutating Webhook 自动为资源添加
velero.io/backup-name标签。 - 在备份完成后，通过 Post-backup Hook 恢复数据写入（如 Unfreeze）。
- 恢复准入角色：
- 在恢复资源创建前，通过 Validating Webhook 检查目标集群是否满足资源依赖（如 StorageClass 是否存在）。
- 在恢复过程中，通过 Mutating Webhook 自动替换 Namespace、调整资源配额。
- 在恢复完成后，通过 Post-restore Hook 执行数据校验或服务重启。
- 策略注入角色：
- 通过 Velero 自定义插件，实现企业级准入策略（如禁止备份包含 Secret 的 Namespace）。
- 与 Kyverno / OPA Gatekeeper 等外部准入引擎集成，统一灾备策略管理。
常见误区：Velero 的准入角色不是默认启用的。需要显式配置
--use-volume-snapshots=false 或安装对应的 Velero Plugin for Admission。未配置准入场景时，备份可能包含不一致数据，恢复可能因资源冲突而失败。
总结：Velero 在准入场景中通过钩子机制和插件扩展，将灾备能力嵌入到 Kubernetes 资源生命周期的关键节点。理解这一角色，是后续排查准入相关故障（如备份钩子超时、恢复资源校验失败）的基础。