生产部署检查清单

把 SupKube 从"能跑起来"推到"可以交付生产"需要逐项确认的事。本文按会造成的后果严重程度排序，不是按操作顺序——越靠前的项，漏掉的代价越大。

前置条件

已完成一次成功安装，参见在线安装或离线安装。
您有权限修改 Helm values 并重新执行 helm upgrade。

总览

   ┌────────────────────────────────────────────────────────┐
   │  一、安全           漏掉 = 任何人可登录 / 数据可被篡改    │
   ├────────────────────────────────────────────────────────┤
   │  二、可恢复性        漏掉 = 灾难发生时恢复不了            │
   ├────────────────────────────────────────────────────────┤
   │  三、容量与资源      漏掉 = 跑一段时间后爆掉              │
   ├────────────────────────────────────────────────────────┤
   │  四、可观测性        漏掉 = 出事了不知道                  │
   └────────────────────────────────────────────────────────┘

一、安全

处理默认演示账号（最高优先级）

Chart 默认启用内置 Dex 并附带演示账号 admin@supkube.local / admin。任何新装的 SupKube 默认都能用它登录。

三选一：

# 方案 A：接入真实 IdP 后清空静态账号（推荐）
--set auth.dex.staticPasswords=null

# 方案 B：改掉密码哈希
--set auth.dex.staticPasswords[0].hash='<bcrypt 哈希>'

# 方案 C：完全关闭内置 Dex，改用外部 OIDC
--set auth.dex.enabled=false

确认已生效：

kubectl -n supkube get cm -l app.kubernetes.io/component=dex -o yaml | grep -c 'admin@supkube.local'

返回 0 才算处理完。

打开 RBAC（影响面比演示账号更大）

auth.rbac.enabled 默认是 false。这意味着：任何通过认证的用户都是 admin，可以删除任意还原点。

改掉演示账号密码、接上企业 IdP 之后，如果 RBAC 仍然关着，全公司能登录的人依然人人都是管理员——这正是它比演示账号更危险的地方：前者看起来已经"做了安全加固"，实际权限完全没有分层。

--set auth.rbac.enabled=true \
--set auth.rbac.defaultRole=viewer

核对已生效：

kubectl -n supkube exec deploy/supkube-backend -- \
  wget -qO- http://127.0.0.1:8080/api/v1/auth/rbac/bindings

界面侧在「系统设置 → 我的权限」。RBAC 关闭时这一页会直接显示警告——产品自己在喊，不要忽略它。

确认安装在 `supkube` 命名空间

许可证、多集群注册表、审计三个子系统的命名空间硬编码为 supkube。装到别处它们会静默失效。

helm list -A | grep supkube

NAMESPACE 一列必须是 supkube。详见已知限制。

评估 ClusterRole 权限范围

SupKube 后端的 ClusterRole 是集群范围的，除 Velero 资源外还持有对核心 API 组 configmaps 与 secrets 的集群范围完整增删改查权限。这是 Chart 自身注释标注的已知技术债。

安全评审时请把它纳入威胁模型：

kubectl get clusterrole supkube -o yaml

收紧 editor 的命名空间范围

命名空间范围只约束 editor。viewer 能看到全集群所有命名空间的备份数据——如果您的场景要求读取也隔离，当前角色模型无法满足，需要用多实例部署来隔离。

访问地址三处必须逐字符一致

子路径部署时，下面三者不一致会让登录在 OIDC 回调环节静默失败——页面没有报错，只是登录不进去：

   用户实际访问的地址        https://example.com/supkube/
            │
            ├── auth.dex.publicURL      必须 = https://example.com/supkube
            └── frontend.basePath       必须 = /supkube

这是真实发生过的故障。部署后请逐字符核对，注意结尾斜杠与大小写：

kubectl -n supkube get cm -l app.kubernetes.io/component=dex \
  -o jsonpath='{.items[0].data}' | grep -o 'issuer.*'

静态令牌走带外分发

用于 CI 的静态令牌明文只在生成时出现一次，Helm values 里存的是哈希。确认明文没有进版本库：

git log -p --all -S 'staticTokens' | head -40

二、可恢复性

至少有一个云端存储位置

只做本地快照的策略在集群整体损坏时无法恢复。每条关键策略都必须打开导出开关并指向云端存储位置。

kubectl get backupstoragelocation -A \
  -o custom-columns='NS:.metadata.namespace,NAME:.metadata.name,PROVIDER:.spec.provider,PHASE:.status.phase'

至少一个 PHASE=Available 且不是集群内 MinIO。

为什么用 -A 而不是 -n velero

Chart 已经把 Velero 收口进 release 命名空间（默认 supkube），BSL 不在 velero 命名空间下。历史上这两者曾经漂移（Velero 在 release ns、后端却硬编码查 velero），结果是每个 BSL 都显示 Unknown。用 -A 可以绕开这个坑。

开启对象锁

不可变存储是勒索软件防护的最后一道防线。若用 JDC Vault 备份库，不可变天数由 Vault 侧强制；若用自备 S3，需在桶上开启对象锁。

做一次真实的恢复演练

备份没有被验证过，就等于没有备份。 把生产还原点恢复到备用集群的新建命名空间，确认应用真的起得来。

kubectl -n supkube get restores --sort-by=.metadata.creationTimestamp

「可观测性」页的 DR 健康评分会把长期未验证的情况标出来。

跨集群场景：统一指纹密钥并设为强制

所有参与集群必须使用同一个 fingerprint.sharedSecret，且导入策略的指纹校验设为强制。

留空时的行为容易产生误解：Chart 会用 lookup 保证同一集群多次升级时该值保持不变——所以单集群场景下"留空也没出问题"。但不同集群各自生成的是不同的随机值，因此跨集群场景必须显式传同一个值，否则永远无法互相信任。

记录许可证来源

许可证状态为 missing 时无法新建备份与策略。确认许可证 Secret 存在且状态正常：

kubectl -n supkube get secret supkube-license

三、容量与资源

默认资源配额是否够用

Chart 的默认值按小规模集群设定，大集群需要上调：

组件	requests	limits	何时需要上调
backend	`100m` / `128Mi`	`500m` / `256Mi`	命名空间多、并发备份多时优先加内存
frontend	`50m` / `64Mi`	`200m` / `128Mi`	基本不需要调
内置 MinIO	`100m` / `256Mi`	`1000m` / `1Gi`	本地备份库承载写入压力时

本地备份库容量规划

localStore.size 默认 100Gi，该默认值对应的假设是「5–10 个工作负载命名空间、每日备份、保留 30 天」。

超出这个规模请在安装前调大——PVC 扩容取决于 StorageClass 是否支持在线扩容，事后调整未必可行。

kubectl -n supkube get pvc supkube-local-store-data

确认保留期与实际容量匹配

本地高频短保留 + 云端低频长保留是推荐组合。保留期设得比容量能支撑的更长，结果是备份因空间不足而失败。

四、可观测性

接入 Prometheus

指标暴露在根路径 /metrics，不在 /api/v1 前缀下——配置抓取目标时容易搞错。

kubectl -n supkube exec deploy/supkube-backend -- \
  wget -qO- http://localhost:8080/metrics | head

审计日志不要依赖界面

界面里的审计日志基于 Kubernetes 事件，继承集群的事件 TTL（多数集群默认 1 小时）。需要长期留存合规记录时必须导出到外部系统。

给备份失败配告警

DR 评分把「近 7 天是否有失败备份」作为评分项之一，但它不会主动通知您。请在 Prometheus 侧配置告警规则。

一次性核对

安装前跑一遍环境检查：

curl -fsSL https://charts.supkube.com/preflight.sh | bash

该脚本覆盖 API 连通性、Helm 版本、RBAC 权限、StorageClass、CSI 快照能力、已有 Velero 检测与节点资源评估。

退出码的含义容易误读，在 CI 里尤其要注意：

退出码	含义
`0`	所有关键检查通过。只有警告也返回 `0`
`1`	至少一项关键检查失败
`2`	预检工具自身出错（例如找不到 `kubectl`），不是"存在警告"

不要把 2 当成"有警告"

把退出码 2 理解成"通过但有警告"会让 CI 在工具环境损坏时误判为可继续。警告不会改变退出码——有警告仍然是 0。

验证方法

按本文逐项确认后，用下面这组命令做最终核对：

# 安装位置与版本
helm list -n supkube

# 三个组件就绪
kubectl -n supkube get deploy

# 存储位置可用（注意用 -A，BSL 不在 velero 命名空间）
kubectl get backupstoragelocation -A

# 演示账号已清除（应返回 0）
kubectl -n supkube get cm -l app.kubernetes.io/component=dex -o yaml \
  | grep -c 'admin@supkube.local'

# RBAC 已打开（不应看到"所有已认证用户都是 admin"的警告）
kubectl -n supkube exec deploy/supkube-backend -- \
  wget -qO- http://127.0.0.1:8080/api/v1/auth/rbac/bindings

# 至少有过一次成功的还原（演练记录）
kubectl -n supkube get restores

前置条件​

总览​

一、安全​

处理默认演示账号（最高优先级）​

打开 RBAC（影响面比演示账号更大）​

确认安装在 supkube 命名空间​

评估 ClusterRole 权限范围​

收紧 editor 的命名空间范围​

访问地址三处必须逐字符一致​

静态令牌走带外分发​

二、可恢复性​

至少有一个云端存储位置​

开启对象锁​

做一次真实的恢复演练​

跨集群场景：统一指纹密钥并设为强制​

记录许可证来源​

三、容量与资源​

默认资源配额是否够用​

本地备份库容量规划​

确认保留期与实际容量匹配​

四、可观测性​

接入 Prometheus​

审计日志不要依赖界面​

给备份失败配告警​

一次性核对​

验证方法​

相关文档​