跳到主要内容

离线安装

无法直接访问公网镜像仓库的集群（Air-gap），需要先把镜像搬运到您自己的内部镜像仓库，再让 Chart 从那里拉取。

前置条件​

  • 一台能同时访问公网与目标内部镜像仓库的中转机器（用于搬运镜像）。
  • 目标集群可以访问您自己的内部镜像仓库（Harbor / Nexus / Quay 等）。

仓库提供两个脚本处理镜像搬运，分别对应两种不同的 Chart 覆盖方式，不要混用：

方式一：airgap-bundle.sh（推荐用于完全离线环境）​

./hack/airgap-bundle.sh output.tar.gz

会读取 integrations/images.yaml 中的镜像清单，逐个 docker pull + docker save，并把整套 supkube-helm/ Chart、集成文档一起打进一个 tar.gz，附带一份 scripts/load-images.sh 用于在离线环境里 docker load + 推送到内部仓库。这种方式产出的安装说明会指导您分别设置：

helm install supkube ./supkube-helm/supkube \
  --set backend.image.repository=<您的内部仓库>/backend \
  --set frontend.image.repository=<您的内部仓库>/frontend \
  ...

即逐个组件分别指定 image.repository，不使用下面的 global.airgapped.repository 整体开关。

方式二：mirror-images.sh + global.airgapped.repository​

./hack/mirror-images.sh <您的内部仓库前缀>

会把镜像清单中的每个镜像原样搬运到 <内部仓库前缀>/<原始镜像完整路径>:<tag>（保留原始路径层级）。

两种覆盖方式的目录层级不一致，请勿混用

Chart 里 global.airgapped.repository 这个总开关期望的镜像布局是"扁平化"的——即 <mirror>/<镜像名 basename>:<tag>（例如 supkube.azurecr.io/backend 被重写为 <mirror>/backend），只取原始路径的最后一段。而 mirror-images.sh 搬运时保留的是完整原始路径。这两者的目录结构不一致，如果您用 mirror-images.sh 搬运镜像，不要直接设置 global.airgapped.repository 期望它自动生效，而应该像方式一那样逐个组件显式设置 image.repository，或者手工调整内部仓库里的路径使其符合扁平化布局。两个脚本都不会替您自动完成这一步。

无论用哪种方式搬运镜像，Velero 子 Chart 的镜像不会被 global.airgapped.repository 覆盖（Helm 子 Chart 默认不继承父 Chart 的 global.* 用于镜像字段），必须额外单独指定：

--set velero.image.repository=<内部仓库>/velero \
--set velero.image.tag=v1.18.0 \
--set 'velero.initContainers[0].image=<内部仓库>/velero-plugin-for-aws:v1.14.1' \
--set 'velero.initContainers[1].image=<内部仓库>/velero-plugin-for-microsoft-azure:v1.14.1'

CRD 安装方式​

默认 velero.installCRDs=true，由 Chart 负责安装 Velero 所需的 CRD，适合全新集群。如果集群里已经单独安装过 Velero 的 CRD，设置 --set velero.installCRDs=false 避免"资源已存在"冲突。

验证方法​

# 确认所有 Pod 使用的镜像地址都指向您的内部仓库，而不是 supkube.azurecr.io
kubectl get pods -n supkube -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.containers[*].image}{"\n"}{end}'

curl -s http://<您的访问地址>/api/v1/status

相关文档​