Helm部署GitLab至Kubernetes时PVC Pending问题求助

问题分析 #

从你提供的信息来看，核心矛盾很明确：你已经在values.yaml里指定了gluster-heketi作为存储类，但GitLab生成的PVC却仍然带着volume.alpha.kubernetes.io/storage-class: default的旧注解，而且PVC的StorageClass字段是空的。这就导致Kubernetes找不到对应存储类去绑定PV，最终抛出no persistent volumes available for this claim and no storage class is set的错误。

这种情况大概率是Helm GitLab chart的模板逻辑没正确读取你配置的存储类值，或者你的Kubernetes版本已经不再兼容旧的alpha存储类注解，转而使用标准的storageClassName字段了。

解决步骤 #

1. 先确认存储类本身没问题

第一步先排查存储类状态，确保gluster-heketi是正常可用的：

kubectl get storageclass

如果输出里能看到gluster-heketi且状态为Available，说明存储集群本身没问题，问题出在PVC的配置生成环节。

2. 修正values.yaml的存储类配置

很多旧版GitLab Helm chart会用volume.alpha.kubernetes.io/storage-class这个过时注解，而新版Kubernetes推荐直接用spec.storageClassName字段。你可以调整values.yaml，优先通过全局配置统一指定存储类，避免逐个组件配置遗漏：

## Storage Class Options
gitlabConfigStorageClass: gluster-heketi
gitlabDataStorageClass: gluster-heketi
gitlabRegistryStorageClass: gluster-heketi
postgresStorageClass: gluster-heketi
redisStorageClass: gluster-heketi
# 新增全局存储类配置，覆盖默认逻辑
global:
  storageClass: gluster-heketi

3. 清理现有无效的PVC

先把已经处于Pending状态的PVC删掉，避免后续部署复用旧配置：

kubectl delete pvc gitlab1-gitlab-data gitlab1-gitlab-etc gitlab1-postgresql gitlab1-redis

4. 重新部署GitLab

用修正后的配置重新部署Helm release：

# 如果是升级现有release
helm upgrade --install gitlab1 gitlab/gitlab -f values.yaml
# 如果是首次部署
helm install gitlab1 gitlab/gitlab -f values.yaml

5. 验证PVC绑定状态

部署完成后，再次查看PVC状态：

kubectl get pvc

正常情况下，这些PVC应该会快速绑定到GlusterFS提供的PV上，状态变为Bound。

额外排查点 #

如果还是不行，检查新生成的PVC YAML是否正确设置了storageClassName：

kubectl get pvc gitlab1-gitlab-data -o yaml

查看spec部分是否存在：

spec:
  storageClassName: gluster-heketi

如果仍然没有，可能需要手动修改chart的PVC模板，把旧的注解逻辑替换成标准字段。比如找到模板里类似这样的代码：

annotations:
  volume.alpha.kubernetes.io/storage-class: {{ .Values.gitlabDataStorageClass | default "default" }}

替换为：

storageClassName: {{ .Values.gitlabDataStorageClass | default "default" }}

重新打包chart后再部署即可。

内容的提问来源于stack exchange，提问作者Ivan