GKE上Prometheus Operator挂载PVC失败及目录缺失问题排查

1. 权限报错open /prometheus/queries.active: permission denied #

GKE的Persistent Disk挂载后，目录默认属主为root，而Prometheus容器默认以UID=65534（nobody用户）运行，导致无权限写入路径。你用initContainer修复权限的思路是对的，但需确保配置精准：

• 示例initContainer配置：

initContainers:
- name: fix-permissions
  image: busybox:latest
  command: ["chown", "-R", "65534:65534", "/prometheus"]
  volumeMounts:
  - name: prometheus-storage
    mountPath: /prometheus

注意：volumeMounts的名称必须和主容器的存储卷名称完全一致，确保权限修改的是挂载的PD目录。

2. 未找到预期的/prometheus-pvc目录 #

Prometheus Operator的Prometheus CR默认将PVC挂载到/prometheus目录，而非自定义的/prometheus-pvc。你需要：

1. 检查Prometheus CR的存储配置，确认PVC挂载路径为默认的/prometheus：

apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
  name: k8s
  namespace: monitoring
spec:
  # 其他配置略
  storage:
    volumeClaimTemplate:
      spec:
        storageClassName: 你的存储类名称
        accessModes: ["ReadWriteOnce"]
        resources:
          requests:
            storage: 10Gi
  # 其他配置略

2. 进入Pod后直接查看/prometheus目录验证数据：

kubectl exec -n monitoring prometheus-k8s-0 -- ls -l /prometheus

不建议自定义挂载路径，避免破坏Operator的默认运行逻辑。

3. replicas=1却出现2个Pod #

这种情况常见原因及处理方式：

• 滚动更新临时状态：StatefulSet更新Pod时，会先启动新Pod，待其就绪后再删除旧Pod，此阶段会短暂出现2个Pod。等待数分钟，旧Pod会自动进入Terminating状态并被清理。
• 旧Pod未正常终止：若旧Pod长时间停留在Terminating状态，可手动清理：

kubectl delete pod -n monitoring <旧Pod名称> --force --grace-period=0

• CR配置被意外修改：检查Prometheus CR的replicas字段是否确实为1：

kubectl get prometheus -n monitoring k8s -o jsonpath='{.spec.replicas}'

若输出为2，编辑CR改回1即可：

kubectl edit prometheus -n monitoring k8s

• Operator状态异常：若上述排查均正常，重启Prometheus Operator Pod排查：

kubectl delete pod -n monitoring prometheus-operator-xxx-xxx

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