1. 目标

• 将 GitLab 从原 nfs-client 方案迁移，将 nfs 的 GitLab 数据目录直接上传到minio，使用 MinIO gitlab 桶承载对象类数据。

• 保证 GitLab 服务稳定启动。

2. 过程中的问题与现象

2.1 直接把 GitLab PVC 全切到 csi-s3

• 将 gitlab-logs、gitlab-config、gitlab-data 的 storageClassName 从 nfs-client 改为 gitlab-csi-s3。

• Pod 出现反复重启，日志报错：

  Errno::ENOTSUP: Operation not supported @ apply2files - /etc/gitlab

2.2 csi-s3 端点问题

• 初始使用 https://minio.apotos.com 时，遇到证书信任问题（自签证书）。

• 进一步排查发现该域名是控制台入口，S3 API 需走 http://minio.apotos.com:9000。

3. 根因分析

• GitLab 核心目录（/etc/gitlab、/var/opt/gitlab、/var/log/gitlab）依赖 POSIX 文件系统语义（权限、锁、原子操作等）。

• csi-s3 挂载的是对象存储语义，不适合作为 GitLab 核心目录盘。

• MinIO 更适合承载对象类数据（artifacts/lfs/uploads/packages 等）。

4. 最终可用方案（当前生效）

4.1 存储分层

• NFS（PVC）承载：

  • /etc/gitlab

  • /var/opt/gitlab

  • /var/log/gitlab

• MinIO gitlab 桶承载：

  • artifacts

  • external_diffs

  • lfs

  • uploads

  • packages

  • dependency_proxy

  • terraform_state

  • ci_secure_files

4.2 清单改动

• gitlab-pvc.yaml

  • 3 个 PVC 统一改回 storageClassName: nfs-client

• gitlab-minio-secret.yaml（新增）

  • 保存 MinIO 连接信息（AK/SK/endpoint）

• gitlab-deploy.yaml

  • 注入环境变量：MINIO_ACCESS_KEY、MINIO_SECRET_KEY、MINIO_ENDPOINT

• gitlab-config-cm.yaml

  • 配置 gitlab_rails['object_store']，对象桶统一为 gitlab

5. 操作步骤（复现用）

1. 应用 MinIO Secret 与 GitLab ConfigMap

   kubectl apply -f gitlab-minio-secret.yaml
   kubectl apply -f gitlab-config-cm.yaml

2. 停止 GitLab，避免重建 PVC 期间写入

   kubectl scale deploy/gitlab -n gitlab --replicas=0
   kubectl wait --for=delete pod -l app=gitlab -n gitlab --timeout=180s

3. 删除旧 PVC 并按 NFS 重新创建

   kubectl delete pvc -n gitlab gitlab-logs gitlab-config gitlab-data
   kubectl apply -f gitlab-pvc.yaml

4. 应用 Deployment 并启动

   kubectl apply -f gitlab-deploy.yaml
   kubectl scale deploy/gitlab -n gitlab --replicas=1

6. 验证

kubectl get pod -n gitlab -l app=gitlab -o wide
kubectl get pvc -n gitlab gitlab-logs gitlab-config gitlab-data -o wide
kubectl logs -n gitlab -l app=gitlab --tail=120

预期结果：

• Pod Running 且不再出现 ENOTSUP

• 三个核心 PVC 为 Bound，STORAGECLASS=nfs-client

• 对象类数据进入 MinIO gitlab 桶

7. 经验结论

• 不要把 GitLab 核心目录直接落在 S3-FUSE 存储上。

• 正确做法是“块/文件存储 + 对象存储”混合：

  • 核心数据走 NFS/块存储

  • 大文件与附件走 MinIO 对象存储