Kubernetes 备份平台工具与组合架构
凌晨两点，集群误删后的恢复任务显示绿色，业务却仍然不可用。Deployment、Service 和 Secret 已经重新出现，订单库的 PVC 也处于 Bound，但数据库启动后报告日志位点不一致；负责导出数据的对象仓库凭证只在旧集群中可用；最后一份卷快照仍绑定源区域的存储账号。控制器完成了自己的任务，团队却没有得到一个能够接管流量的业务系统。
问题并不一定是工具失效。更常见的根因是把一个产品名称当成整套恢复架构：对象由谁重建、字节由谁搬运、事务由谁冻结、恢复点由谁索引、凭证由谁保管、目标环境由谁验收，这些责任没有形成闭环。
先问恢复对象在哪里，而不是先问买哪款工具
Kubernetes 应用至少跨越五种状态位置：
| 状态位置 | 典型对象 | 丢失后的表现 | 恢复责任 |
|---|---|---|---|
| Kubernetes API | Namespace、CRD、RBAC、Deployment、StatefulSet | 新集群没有对象，或对象之间 UID、ownerReference 失配 | 对象归档、GitOps、etcd 或平台控制器 |
| 持久卷后端 | 块卷、文件系统、快照、快照引用 | PVC 已创建但数据为空，或 snapshot handle 无法跨账号读取 | CSI 快照、数据移动器、卷复制工具 |
| 应用事务 | checkpoint、WAL/binlog 位点、队列 offset、多卷关系 | 文件可读但数据库回放失败，或多组件水位不一致 | 应用原生备份、hook、Kanister 工作流 |
| 集群外依赖 | KMS、IAM、DNS、镜像仓库、数据库、消息系统 | Pod 存在但无法解密、拉镜像、解析域名或连接依赖 | 平台团队、安全团队与业务 owner |
| 恢复系统自身 | 仓库索引、加密密钥、控制器 CR、许可信息 | 备份任务历史可见，但恢复点无法发现或解密 | 备份平台 owner 与安全 owner |
一款工具可以覆盖其中多层，却很少独立承担全部层。架构设计要先把每个业务对象映射到状态位置，再写下恢复动作、恢复证据和责任人。没有 owner 的状态，就是事故时无人能够解释的状态。
application: checkout
recoveryUnit: orders
state:
kubernetesObjects:
owner: platform
method: object-backup
evidence: manifest-digest
volumeBytes:
owner: storage
method: csi-snapshot-plus-portable-copy
evidence: snapshot-id-and-sha256
transactionPoint:
owner: database
method: native-checkpoint
evidence: database-backup-id
externalIdentity:
owner: security
method: workload-identity-rebind
evidence: short-lived-token-probe
traffic:
owner: sre
method: single-writer-cutover
evidence: business-sli-and-dns-change-id这份恢复单元不保存真实 Secret、内部 endpoint 或生产数据，只保存受控系统中的引用。恢复点索引必须能把对象摘要、卷副本、应用位点、密钥版本和镜像 digest 关联到同一业务时刻。
五层架构决定工具如何组合
平台工具可以沿五层理解，而不是按产品宣传页罗列功能。
保护对象层决定“备份了什么”。仅保存 YAML，不能恢复卷字节；仅复制 PVC，不能恢复 CRD、RBAC 和 Service。产品状态 Completed 只能证明控制器完成了声明动作，不能证明保护对象集合完整。
一致性层决定“恢复点是否有业务意义”。CSI 快照通常提供存储层崩溃一致性；数据库、消息系统和多卷应用还需要 checkpoint、停止写入、flush 或产品支持的备份协议。hook 只是执行通道，不会自动获得事务语义。
数据路径层决定“字节能否到达目标”。原生快照速度快，但经常受账号、区域、CSI driver 和后端生命周期约束；文件级备份或 snapshot data movement 更便于跨环境，却要支付扫描、压缩、加密和网络传输成本；持续复制能缩小数据水位差，却不是历史版本和误删保护的替代品。
恢复仓库层决定“故障域是否独立”。仓库需要独立账号、独立密钥、版本化或不可变策略、受控删除和异地副本。把备份存到与源集群相同的身份、区域和删除权限中，只是把单点换了一个名字。
编排与门禁层决定“何时能够接管”。CRD、Operator、身份、PVC、应用和入口有严格依赖；StorageClass、Namespace、镜像、KMS 和云资源还需要环境映射。恢复必须能暂停、修复、重跑，并在业务断言通过前阻止外部流量和副作用任务启动。
工具不是同类替代品
Velero：以 Kubernetes 对象和卷数据路径为中心
Velero 适合建立 Kubernetes API 对象备份，并通过 provider plugin、CSI、File System Backup 或 snapshot data movement 连接卷数据。它的价值在于把对象选择、调度、恢复与数据路径放进同一套控制面，但应用事务、云外依赖和最终业务校验仍要由其他责任方完成。
当卷保护路径成为瓶颈时，继续进入 Velero CSI、node-agent 与 data mover。那里需要区分原生快照引用、文件系统备份、快照数据移动和旧仓库兼容，不能只看 Backup CR 的阶段。
Kasten K10：以策略、应用目录与恢复点为中心
Veeam Kasten K10 把策略、应用发现、快照、导出和恢复点组织成平台化工作流，适合需要集中治理、可视化操作和支持体系的团队。架构评审仍要验证许可计量、目标平台支持、导出数据的可移植性，以及停止续费或卸载控制器后历史恢复点如何读取。
K8up：以 PVC 文件和 restic 仓库为中心
K8up 用 Kubernetes CR 和 Job 驱动 restic 备份、检查、清理和恢复，适合把 PVC 文件或应用导出物写入独立仓库。它不负责重建完整应用对象，也不会把普通文件复制自动提升为数据库一致性。仓库密码、snapshot ID、目标路径和恢复 PVC 必须进入运行手册。
Kanister：以应用动作和 Artifact 为中心
Kanister 用 Blueprint 描述备份、恢复、删除等应用级动作，适合承载数据库 dump、checkpoint、日志归档和产品原生恢复命令。它提供工作流表达能力，不提供通用的数据格式或整集群目录；Blueprint、工具镜像、Artifact、密钥和目标应用版本必须共同保存。
VolSync：以 PVC 复制和接管水位为中心
VolSync 通过 ReplicationSource、ReplicationDestination 与不同 mover 同步 PVC 数据，适合异地复制、迁移和接管。它不重建应用对象，也不天然保证在线数据库一致；旧写入者隔离、同步水位、目标卷验证和反向回切是不可省略的控制点。
当候选方案看起来都能“备份 Kubernetes”时，使用 备份工具选型与互操作证据 中的统一恢复探针比较保护对象、RPO、RTO、一致性、可移植性、许可和退出能力。共同使用 CSI、restic、Kopia 或对象存储，不等于仓库格式可以互读。
用一套最小实验验证工具组合
实验应在可销毁集群、隔离 Namespace 和专用对象存储前缀中进行。测试数据使用随机 fixture，不使用生产数据库副本；仓库凭证由短期身份签发；目标环境没有生产 DNS、消息订阅和外部写权限。
先记录集群、存储和 API 能力：
kubectl config current-context
kubectl cluster-info
kubectl version
kubectl api-resources | grep -E 'volumesnapshot|backup|restore|replication'
kubectl get storageclass
kubectl get csidrivers.storage.k8s.io
kubectl auth can-i create pods -n backup-platform-lab
kubectl auth can-i get persistentvolumes
kubectl auth can-i get secrets -n backup-platform-lab最后一条不应因为“方便恢复”就默认返回 yes。操作者只获得实验 Namespace 的最小权限；仓库写入、仓库读取、恢复、删除恢复点和修改保留策略使用不同身份。
正向实验按同一条证据链执行：
创建带 PVC 的测试应用，写入随机文件和单调递增业务水位，记录 SHA-256、PVC UID、PV、StorageClass、镜像 digest 和时间戳。触发应用冻结或 checkpoint，记录动作开始、完成和异常解冻证据。由选定工具保存 API 对象与卷数据，记录 Backup/Action/Repository 对象 UID、后端 snapshot ID、仓库对象版本和 KMS key 引用。
删除源测试 Namespace，或改到第二个可销毁集群；不得复用源 PVC、源节点缓存和源 ServiceAccount。映射 Namespace、StorageClass、镜像仓库和身份，在隔离网络中恢复到新 PVC。重新计算校验和与业务水位，运行数据库完整性、schema、只读查询和依赖探针。
记录每阶段耗时、等待队列、传输字节、失败重试与人工步骤，计算实际 RPO/RTO。
预期结果不是“控制器无报错”，而是新目标独立读出相同数据、应用断言通过、恢复点可追溯、凭证可撤销、清理不会删除仍在保留期内的副本。
反向实验要击中真实断点
至少保留四类可重复反例：
撤销仓库凭证：任务应明确失败，不能生成看似完整的索引；恢复权限后以新 run ID 重试。让 StorageClass 或 CSI driver 不匹配：PVC 应保持未就绪，Event 能定位 provisioner、snapshot class 或 topology，而不是直接开放应用入口。跳过应用冻结：卷可能恢复成功，但数据库检查或业务水位应暴露不一致；团队据此确认崩溃一致与应用一致的差异。
只恢复对象、不恢复数据：Deployment 可以 Ready，但业务探针必须失败，证明 Kubernetes 就绪状态不能替代数据验证。
反例执行后先保存状态、Event、控制器日志、仓库索引和业务断言，再清理测试资源。不能为了让演示变绿而手工补数据后仍把这一轮记为成功。
权限、凭证和敏感数据按动作拆开
安装控制器通常需要 CRD、webhook、cluster-scoped RBAC 等高权限；日常备份只应读取获批对象并写入限定仓库；恢复身份需要在隔离目标创建资源；删除身份才能修改保留和销毁恢复点。四种动作不能长期共用 cluster-admin 与对象存储管理员凭证。
凭证优先使用 workload identity、短期令牌或外部密钥系统注入，限制 bucket、prefix、KMS key 和 API 动作。Secret 不进入 Git、文章、工单截图和普通日志。etcd 快照、Secret 归档、数据库 dump、仓库索引和恢复日志都可能包含个人信息、Token、证书、内部地址或客户数据，应按最高敏感级别加密、审计和脱敏。
安全基线至少证明：
kubectl auth can-i --list -n backup-platform-lab
kubectl get rolebinding,clusterrolebinding -A -o wide | grep -E 'backup|restore'
kubectl get serviceaccount -A | grep -E 'backup|restore'
kubectl get events -A --sort-by=.lastTimestamp | tail -n 100命令输出进入受控证据库前要移除 Token、Secret data、内部 endpoint 和生产对象名称。审计记录关联操作者、请求 UID、恢复点 ID、目标 Namespace、密钥版本、删除动作和审批单，不保存密钥本体。
容量和成本从恢复吞吐反推
容量模型不能只统计源数据大小。CSI 快照有写时复制、快照链和后端保留成本；文件级备份受文件数量、压缩率、去重索引、加密 CPU 和对象请求数影响；跨区域副本产生传输和读取费用；演练需要同时容纳源卷、恢复卷、临时缓存、日志和失败重试。
用一次完整恢复测量这些量：
有效数据字节 / 实际传输字节 / 对象数量
快照创建延迟 / 仓库排队时间 / 平均与 P95 吞吐
PVC 供应时间 / 数据导入时间 / 应用校验时间
恢复并发 / CSI 限流 / 云 API throttling / 节点临时空间峰值
每个恢复点月成本 / 跨区成本 / 演练资源与人工时间RPO 缩短会提高调度频率、仓库对象数和失败噪声；RTO 缩短通常需要预热目标集群、增加恢复并发和保留快速层副本。并发过高又会争用 CSI controller、云 API 配额、对象仓库、节点网络和 CPU。架构师要找到吞吐拐点，而不是把并发参数调到最大。
升级和退出时保护可读性
控制器升级前冻结一组黄金恢复点，在隔离集群分别验证旧恢复点、新恢复点、删除策略和回滚路径。需要核对 CRD 的 served/storage version、conversion webhook、provider plugin、CSI sidecar、仓库格式、加密方式和工具镜像 digest。Pod Ready 不足以证明旧索引和旧数据仍可读。
退出某款工具时，先停止新调度，再盘点所有恢复点、后端快照、仓库对象、KMS key、ServiceAccount、RoleBinding、CRD/finalizer、许可和账单。双轨期用新旧工具恢复同一 fixture，比较业务水位、数据摘要、RPO/RTO 和删除行为。旧系统只有在保留期结束或历史数据完成受控转换后才能下线；直接卸载 Helm release 会留下无法读取的恢复点或持续计费的孤儿资产。
平台交付检查
每个应用都有状态位置、恢复动作、证据、owner 和失败升级路径。对象、卷、事务位点、外部身份和流量切换绑定到同一恢复点索引。仓库与源集群使用不同故障域、身份和删除权限，并启用受控保留。
正向实验能在隔离目标完成业务校验，反向实验能稳定暴露凭证、一致性和映射错误。安装、备份、恢复、删除和审计身份相互分离，所有临时权限有到期时间。容量模型包含快照、仓库、缓存、跨区、演练和失败重试，不只包含源数据。
升级能够读取旧恢复点，退出能够导出资产、撤销凭证、清理孤儿资源并停止计费。平台状态和业务恢复状态分别监控；只有业务断言通过才允许进入接管流程。