直接用 Helm 部署 GitLab 到 Kubernetes 可行但默认配置不适用于生产，需解决镜像拉取失败、PVC pending、Ingress/TLS 冲突等问题，推荐使用国内镜像源并调整 storageClass、镜像地址和组件开关。
直接用 Helm 部署 GitLab 到 Kubernetes 是可行的，但默认配置在生产环境几乎不可用——资源吃紧、镜像拉取失败、PVC pending、Ingress/TLS 冲突是高频问题。
helm repo add gitlab 失败或 chart 拉不到
国内直接访问 https://charts.gitlab.io/ 常被阻断或超时，helm repo add 会卡住或报 connection refused。
- 换国内镜像源：用腾讯云维护的镜像仓库
https://tke-charts-1305287947.cos.ap-guangzhou.myqcloud.com/gitlab/（已同步最新 chart） - 或手动下载后本地加载：
helm fetch gitlab/gitlab --untar && helm package gitlab/，再helm install本地包 - 禁用
helm repo update的默认 timeout，加--timeout 300s防止中途退出
部署后 Pod 一直 Pending，尤其是 gitaly、minio、redis
根本原因通常是 PVC 绑定失败，错误日志里常见 waiting for a volume to be created 或 no persistent volumes available。
- 检查 StorageClass 是否设为 default：
kubectl get sc -o wide看DEFAULT列是否为*；不是就加注解：kubectl patch sc <name> -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'</name> - 云厂商（如腾讯云 CBS、阿里云 ACK）要求 PVC 容量必须是特定倍数（如 10Gi），而官方 chart 默认写的是
8Gi，需在values.yaml中全局替换为10Gi、20Gi等合规值 - Gitaly 必须用块存储（而非 NFS），且推荐 SSD 类型；若用 Local PV，需确保 nodeAffinity 和 taints/tolerations 对齐
镜像拉取失败：ErrImagePull / ImagePullBackOff
GitLab chart 默认镜像来自 registry.gitlab.com，国内直连成功率极低，Pod 卡在 ContainerCreating 状态。
- 批量替换镜像地址：在
values.yaml中搜索image:，把所有registry.gitlab.com/开头的镜像，替换成你同步好的国内镜像仓库地址，例如harbor.example.com/gitlab/gitlab-ce - 特别注意
gitlab-runner、gitaly、redis、postgresql这几个组件的镜像都要改，漏一个就会失败 - 如果用私有仓库，别忘了配
imagePullSecrets，且 secret 必须和 GitLab Pod 在同一 namespace
最小化安装时哪些组件可以安全关闭
开箱即用的 chart 启动近 20 个 Pod，内存常超 8Gi，测试或边缘场景下必须裁剪。
- 必关项：
nginx-ingress.enabled=false、certmanager.enabled=false、prometheus.enabled=false、grafana.enabled=false - 可关项（取决于是否需要）：
redis.enabled=false（改用外部 Redis）、postgresql.enabled=false（用外部 PG）、minio.enabled=false（换用 OSS/S3 兼容存储） - Gitaly 不建议关——它是 Git 操作核心，关了会导致 push/pull 失败；如真要轻量，可用
gitaly.external指向已有 Gitaly 实例
真正麻烦的从来不是命令敲几行，而是每个组件背后隐含的存储语义、网络策略依赖和镜像生命周期管理。哪怕只改一个 storageSize 字段，也可能触发 CSI 插件的容量校验逻辑，让 PVC 卡死在 Pending 状态长达数小时。
