功能路线图与反馈
这一页如实列出当前还做不到的事，以及它们各自处在什么阶段。我们认为让您提前知道边界，比事后发现功能不存在更有价值。
页面底部有反馈渠道——如果您需要的能力不在下面任何一列，请告诉我们。
状态的含义
┌──────────────┬────────────────────────────────────────────┐
│ 开发中 │ 代码已存在，尚未对外可用 │
├──────────────┼────────────────────────────────────────────┤
│ 规划中 │ 已确认要做，尚未开工 │
├──────────────┼────────────────────────────────────────────┤
│ 评估中 │ 在收集需求，是否做取决于反馈 │
├──────────────┼────────────────────────────────────────────┤
│ 明确不做 │ 有意识的产品决策，附原因 │
└──────────────┴────────────────────────────────────────────┘
本页不承诺具体发布日期。标注「开发中」的功能通常在下一两个版本内交付，但以实际发版为准。需要确切时间请通过下方渠道联系我们。
开发中
容灾演练编排（DRFlow）
把一次完整的容灾演练拆成五个有序阶段自动执行，每个阶段有明确的通过条件，任一阶段失败即停止并记录原因：
待执行 ──▶ 恢复数据库 ──▶ 恢复应用 ──▶ 重新对齐 ──▶ 校验 ──▶ 成功
│ │ │ │
└────────────┴────────────┴──────────┴──▶ 失败（记录阶段与原因）
演练过程会产生活动事件，可在「可观测性」页的活动流里追踪。
当前状态：引擎已完成，但对外接口尚未开放，调用会被权限层拒绝。修复后即可使用。
在此之前，容灾演练请按跨集群灾备的手工步骤执行。
跨存储位置复制（Backup Copy）
把一份已完成的备份从一个存储位置复制到另一个，用于构建异地多副本。
当前状态：预检已可用（能列出哪些备份可以复制），执行环节尚未交付，调用会返回「未实现」。详见已知限制。
规划中
文件级恢复
从一个备份里浏览目录树，只取回其中若干个文件，而不是还原整个卷。适用于误删单个配置文件这类场景。
当前替代方案：把备份还原到一个临时命名空间，从那里取出需要的文件后再删除该命名空间。
报表导出
把备份覆盖率、成功率、容灾评分等汇总成可下载的报表，用于合规审计与管理层汇报。
当前替代方案：通过 REST API 拉取原始数据自行汇总，或抓取 Prometheus 指标。
安全事件外发（SIEM 集成）
把审计事件主动推送到企业的安全信息与事件管理系统。
当前状态：审计事件已按结构化格式写入标准输出，您可以用现有的日志采集链路（如 Loki、EFK、Splunk）收集并配置匹配规则。缺的是产品内置的推送配置界面。
界面里的审计日志基于 Kubernetes 事件，继承集群的事件保留时间（多数集群默认 1 小时）。合规场景请务必通过日志采集链路导出，不要依赖界面。
虚拟机工作负载保护
针对 KubeVirt 等在 Kubernetes 上运行虚拟机的场景做专门适配。
当前状态：虚拟机的卷可以按普通持久卷备份，但缺少虚拟机特有的一致性处理。相关的预检规则已在规划中。
SupKube 自身的配置备份
备份 SupKube 自己的策略、存储位置、集群注册等配置，以便在管理集群损毁后快速重建。
当前替代方案：这些配置以 Kubernetes 资源形式存在，可用常规方式导出：
kubectl -n supkube get clusters.supkube.io,importpolicies.supkube.io -o yaml > supkube-config-backup.yaml
kubectl get backupstoragelocation,schedule -A -o yaml >> supkube-config-backup.yaml
请注意妥善保管——其中可能含有凭据引用。
评估中
按 Kubernetes 发行版的深度适配
目前各平台安装流程一致，仅存储驱动层面有差异（见安装前置条件）。OpenShift 的 SecurityContextConstraints 与 Operator 安装方式尚未验证。
如果您在特定发行版上遇到问题，反馈可以直接影响优先级。
静态加密与密钥管理
当前不可变保护依赖对象存储侧的对象锁。产品内置的加密密钥管理尚在评估。
明确不做
自动修改您的工作负载
SupKube 不会替您给 Pod 打注解、不会替您执行提权命令。涉及应用一致性备份的 hook、Azure 存储的 IAM 授权，产品都只提供可复制的命令文本。
原因：这是安全红线。备份工具持有集群的广泛权限，如果它还能主动改写业务负载或提升自己的权限，一旦被攻破影响面会成倍放大。
需要应用一致性备份时，请按为备份配置 Velero 原生 hook自行施加注解。
内置的数据库备份编排蓝图
不提供把数据库静默流程封装成可执行模板的能力。原因同上——那类模板本质上就是代您在工作负载里执行命令。
产品会识别出运行中的数据库并给出对应引擎的标准命令，执行权留给您。
反馈与需求
文档和产品都在持续迭代，您的反馈会直接影响优先级。
| 想做什么 | 怎么做 |
|---|---|
| 指出文档错误或不清楚的地方 | 每页底部有「编辑此页」，可直接提交修改建议 |
| 报告产品缺陷 | 在 GitLab 仓库提交问题，附上版本号与复现步骤 |
| 提出功能需求 | 同上。请说明您的实际场景，比单纯描述功能更有帮助 |
| 询问某个能力的时间表 | 同上，我们会给出当前的实际进展 |
提交缺陷时，下面这条命令的输出能显著加快定位：
kubectl -n supkube get deploy -o jsonpath='{.items[*].spec.template.spec.containers[0].image}'
kubectl -n supkube logs deploy/supkube-backend --tail=100