Kubeflow v1.8 离线部署实战：从镜像准备到内网Harbor的全流程指南

1. Kubeflow v1.8离线部署的核心挑战

在企业内网环境中部署Kubeflow v1.8就像在没有超市的荒岛上搭建完整的厨房系统。你需要提前准备好所有食材（容器镜像），建立自己的储物柜（Harbor仓库），还要确保每道菜的配料比例（镜像版本）完全正确。我去年在金融行业客户现场实施时，就遇到过因为漏掉一个关键镜像导致整个训练管道无法启动的情况。

离线环境最头疼的问题就是镜像依赖。Kubeflow v1.8涉及200+个容器镜像，来自docker.io、gcr.io、quay.io等20多个不同仓库。更麻烦的是其中有些镜像是用sha256摘要标识的，比如gcr.io/knative-releases/knative.dev/serving/cmd/webhook@sha256:4305209...这种形式，直接推送到私有Harbor会报格式错误。

2. 离线镜像全量准备工作

2.1 镜像清单生成实战

首先获取官方manifest文件：

wget https://github.com/kubeflow/manifests/archive/refs/tags/v1.8.0.tar.gz tar -zxvf manifests-1.8.0.tar.gz

用这个命令提取全部镜像列表：

cd manifests-1.8.0 kustomize build example | grep 'image: ' | awk '$2 != "" { print $2 }' | sort -u > image-list.txt

这里有个坑要注意：某些组件（如kfp-driver）的镜像是硬编码在代码里的，不会出现在manifest中。建议额外补充这些镜像：

• gcr.io/ml-pipeline/kfp-driver
• gcr.io/ml-pipeline/kfp-launcher
• gcr.io/ml-pipeline/metadata-envoy

2.2 镜像下载与转存技巧

对于无法直接访问的gcr.io镜像，推荐通过第三方镜像仓库中转。比如：

# 先拉取到本地 docker pull gcr.io/ml-pipeline/api-server:2.0.3 # 重新打tag后推送到私有Harbor docker tag gcr.io/ml-pipeline/api-server:2.0.3 192.168.5.200:5000/ml/gcr.io/ml-pipeline/api-server:2.0.3 docker push 192.168.5.200:5000/ml/gcr.io/ml-pipeline/api-server:2.0.3

处理sha256格式镜像的特殊方法：

# 原始格式 name: gcr.io/knative-releases/knative.dev/serving/cmd/webhook@sha256:4305209... # 在kustomization.yaml中需要转换为： images: - name: 192.168.5.200:5000/ml/gcr.io/knative-releases/knative.dev/serving/cmd/webhook@sha256:4305209... newName: 192.168.5.200:5000/ml/gcr.io/knative-releases/knative.dev/serving/cmd/webhook newTag: "sha256"

3. Harbor仓库高级配置

3.1 批量镜像同步方案

建议在Harbor中创建名为ml的独立项目，然后使用脚本批量处理：

#!/bin/bash while read image; do repo=$(echo $image | awk -F/ '{print $NF}' | cut -d: -f1) docker pull $image docker tag $image 192.168.5.200:5000/ml/${image#*/} docker push 192.168.5.200:5000/ml/${image#*/} done < image-list.txt

3.2 访问控制关键配置

在values.yaml中需要设置：

externalURL: https://harbor.example.com harborAdminPassword: "your_secure_password" persistence: persistentVolumeClaim: registry: size: 1Ti chartmuseum: enabled: false notary: enabled: false trivy: enabled: false

4. 部署过程中的典型问题解决

4.1 镜像拉取失败排查流程

当出现ImagePullBackOff错误时：

1. 检查事件详情：

   kubectl describe pod -n kubeflow <pod-name>

2. 确认镜像路径是否正确
3. 检查Harbor网络连通性
4. 验证镜像是否真的存在：

   curl -X GET "https://harbor.example.com/v2/ml/<image-path>/manifests/<tag>" \ -H "Authorization: Basic $(echo -n 'admin:password' | base64)"

4.2 组件特定问题解决方案

Notebook报错403问题：

kubectl edit deployments.apps -n kubeflow jupyter-web-app-deployment # 修改环境变量 - name: APP_SECURE_COOKIES value: "false"

TensorBoard权限问题：

securityContext: runAsNonRoot: true runAsUser: 65532 runAsGroup: 65534

MySQL初始化失败：

rm -rf /nfs/mysql-pv-claim/*

5. 网络隔离下的持续维护

5.1 离线环境下的PyPI管理

建议搭建Devpi私有仓库：

# 服务端配置 devpi-server --start --init --serverdir /var/lib/devpi # 客户端使用 pip install --index-url=http://devpi.example.com:3141/root/pypi/+simple/ \ --trusted-host devpi.example.com kserve

5.2 版本升级策略

1. 在新环境测试完整流程
2. 使用diff工具对比yaml变更：

   diff -r manifests-1.7.0 manifests-1.8.0

3. 特别注意CRD的变化
4. 提前备份关键数据：

   velero backup create kubeflow-backup --include-namespaces kubeflow

6. 性能优化实战建议

6.1 资源分配黄金比例

根据节点数量推荐配置：

• 3节点集群（16C32G）：

  istio: pilot: resources: requests: cpu: 2 memory: 4Gi

• 5节点集群（32C64G）：

  katib: controller: resources: requests: cpu: 4 memory: 8Gi

6.2 存储性能调优

对于训练任务密集的场景：

persistentVolume: accessModes: - ReadWriteMany nfs: server: 192.168.1.100 path: /data/kubeflow mountOptions: - hard - nfsvers=4.1 - noatime