跳到主要内容

升级操作

SupKube 通过 helm upgrade 完成版本升级，升级前需要重新构建 Chart 依赖，升级后应通过 buildStamp 确认新镜像已经真正生效。

前置条件​

  • 已有一套通过 Helm 安装的 SupKube。
  • 可以访问目标集群的 kubeconfig，以及新版本的镜像 tag（可通过镜像仓库查询，见下文）。

版本号的两套编号​

SupKube 有两套并行版本号，升级时不要混淆：

  • 产品版本（appVersion）：四段式，如 0.9.1.9-alpha，对应容器镜像 tag。
  • Helm Chart 版本：SemVer 格式，如 0.9.1-alpha.9（因为 Helm 要求严格的 SemVer），对应 Chart 包版本号。

查询当前可用的镜像 tag（以 Azure Container Registry 为例）：

az acr repository show-tags --name supkube --repository backend --orderby time_desc --top 5 -o tsv

升级前：子 Chart 依赖​

SupKube 的 Helm Chart 内置了 Velero 作为子 Chart。首次安装或子 Chart 版本变更后，必须先重新构建依赖，否则 helm upgrade 会因为找不到本地缓存的子 Chart 包而失败：

helm repo add vmware-tanzu https://vmware-tanzu.github.io/helm-charts
helm dependency build supkube-helm/supkube

执行升级​

export KUBECONFIG=/path/to/your-cluster.kubeconfig
export VERSION=<新的镜像 tag>

helm upgrade --install supkube supkube-helm/supkube \
  -n supkube \
  --set backend.image.tag=$VERSION \
  --set frontend.image.tag=$VERSION \
  --wait --timeout 15m --burst-limit 300
生产环境建议加 --atomic

--atomic 会在升级失败时自动回滚到上一个可用 Release，避免半升级状态遗留在集群里。

使用 --reuse-values 时请核对新增字段

如果习惯用 --reuse-values 复用已有配置而不是每次都写全部 --set 参数，请注意：--reuse-values 是对已存储 Release 的 values 做合并，某些版本间新增的嵌套对象类型字段（例如某个新增子模块的默认配置块）在旧 Release 从未设置过时，合并结果可能不是您预期的默认值。升级后建议执行 helm get values supkube -n supkube 核对一遍关键字段，而不是假设"没传参数=用了新默认值"。

验证新版本已生效​

镜像 tag 相同不代表 Pod 已经重启完成，buildStamp（构建时间戳，格式 YYMMDD-HHMM）是真正证明新镜像跑起来的信号：

curl -s http://<your-supkube-host>/api/v1/status
{ "status": "ok", "version": "0.9.1.9-alpha", "buildStamp": "260531-2310" }

升级前后对比 buildStamp，不同即代表新镜像已经生效；如果相同，说明 Pod 可能还在用旧镜像（常见原因：imagePullPolicy 为 IfNotPresent 且 tag 没变、或者 Deployment 没有触发滚动更新）。

验证方法​

  1. helm upgrade 命令返回 STATUS: deployed。
  2. kubectl get pods -n supkube 中 supkube-backend、supkube-frontend 均为 Running 且 RESTARTS 无异常增长。
  3. curl .../api/v1/status 返回的 buildStamp 与升级前不同。

相关文档​