架构概览
SupKube 是一层部署在 Velero 之上的编排与管理面，本身不实现备份/还原的数据搬运逻辑，而是把 Velero 的 CRD 封装成图形化工作流并叠加多租户、多集群、许可证等企业能力。
分层关系
┌─────────────────────────┐
浏览器 ───▶ │ supkube-frontend │ Vue 3 SPA，Nginx 提供静态资源
│ （反向代理 /api、/dex） │
└────────────┬─────────────┘
│ /api/v1/*
┌────────────▼─────────────┐
│ supkube-backend │ Go + Gin REST API
│ （鉴权/RBAC/许可证/ │
│ 多集群/评分引擎） │
└────────────┬─────────────┘
│ client-go / controller-runtime
┌────────────▼─────────────┐
│ Velero（内置子 Chart） │ Backup / Restore / Schedule /
│ │ BackupStorageLocation / …
└────────────┬─────────────┘
│
┌───────────────┼───────────────┐
▼ ▼
对象存储（S3 兼容 / Azure Blob） 卷快照（CSI）/ 文件系统备份
SupKube 后端不直接读写对象存储里的字节——真正的数据搬运始终由 Velero 的服务端与 node-agent 完成；SupKube 负责创建/编辑 Velero 的自定义资源，并把状态、进度、错误信息转译成更友好的图形界面语义（例如把 Velero 的 BackupPhase 翻译成 Kasten 风格的阶段清单）。
数据保护的层次词汇
代码与设计文档里经常出现"L1/L2/L4"这类层次编号，含义如下（均为实际已实现语义，非营销用语）：
数据离集群越远，恢复越慢，但抗灾能力越强
──────────────────────────────────────────────────────▶
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ L1 │ │ L2 │ │ L4 │
│ 快照半区 │ ──▶ │ 导出半区 │ ──▶ │ 跨 BSL 复制 │
├──────────────┤ ├──────────────┤ ├──────────────┤
│ 集群内 │ │ 对象存储 │ │ 另一个 BSL │
│ CSI 快照 │ │ MinIO / 云端 │ │ │
│ │ │ │ │ │
│ 恢复最快 │ │ 保留期更长 │ │ 异地多副本 │
│ 随集群存储 │ │ 适合灾备 │ │ │
│ 一起消失 │ │ │ │ │
│ │ │ │ │ ⚠ 仅预检可用 │
│ ✅ 已实现 │ │ ✅ 已实现 │ │ 501 未交付 │
└──────────────┘ └──────────────┘ └──────────────┘
└──────────┬─────────┘
│
策略的「双模式」一次产出这两个恢复点
- L1（快照半区）：集群内 CSI 快照，恢复速度快，但生命周期绑定在集群本地存储上。
- L2（导出半区）：通过 Data Mover 或文件系统上传把数据写入 BSL（本地内置 MinIO 或云端对象存储），保留期更长、更适合灾备。策略的"双模式"会同时产出 L1 与 L2 两个恢复点。
- L4（跨 BSL 复制）：把一份已完成的备份从一个 BSL 复制到另一个 BSL。目前只有预检（列出哪些备份可复制）已经实现，真正执行复制的接口会返回
501 Not Implemented，规划中但尚未交付。
Dashboard 上的 DR Topology 图目前真实可视化的是"本地 BSL vs 云端 BSL"两类存储位置，以及一个基于 3-2-1-1-0 原则计算的合规评分（是否有 ≥2 份副本、是否跨介质、是否有异地副本、是否有不可变副本、近 7 天是否有失败备份）；更细粒度的分层展示仍在演进中，请以这里的描述为准，不要假设图上出现的每一个层级节点都对应一条独立的实时数据管道。
许可证与 RBAC 是横切关注点
许可证状态只影响"新建备份/策略"这一类写操作（详见许可证管理），RBAC 三角色（viewer/editor/admin）则贯穿几乎所有接口（详见认证配置）——理解这两条横切规则，比记住每个页面的按钮位置更能帮助排查"为什么这个操作被拒绝"。
多集群
SupKube 支持在一个"主"实例上注册多个远端集群（上传 kubeconfig），之后可以切换查看不同集群的仪表盘，或者把某个集群的备份还原到另一个集群。
┌──────────────────────────────────────┐
│ 主实例（装了 SupKube 的集群） │
│ │
│ Cluster CR + kubeconfig Secret │
│ 固定存在命名空间 supkube 下 │
└───┬──────────────┬───────────────┬───┘
│ kubeconfig │ │
┌────────▼──────┐ ┌─────▼────────┐ ┌────▼─────────┐
│ 远端集群 A │ │ 远端集群 B │ │ 远端集群 C │
│ 只读健康巡检 │ │ │ │ │
└───────────────┘ └──────────────┘ └──────────────┘
聚合视图：跨集群仪表盘、健康状态
跨集群恢复：A 的备份 ──▶ 还原到 B（需共享 BSL）
集群注册信息（含 kubeconfig 本身）保存在固定命名空间 supkube 下的 Secret 中——这也是命名空间硬编码约束的来源之一。
验证方法
# 确认三个组件的 Pod 都在运行，且 backend 能读到 Velero 资源
kubectl get pods -n supkube
kubectl get backups.velero.io -n supkube
如果 supkube-backend 能正常返回备份列表，说明它与 Velero 之间的封装关系工作正常。