GCP K8s ES8.0.1扩容PVC后Pod CrashLoopBackOff无法启动

核心故障点是持久卷扩容仅完成了Kubernetes资源对象、GCP底层云盘的容量更新，未完成Pod内ext4文件系统的扩容。
从报错日志using data paths, mounts [[/usr/share/elasticsearch/data (/dev/sdb)]], net usable_space [0b], net total_space [975.8mb]可直接验证：Pod内识别到的文件系统总容量仍是扩容前的1GB大小，剩余空间为0，因此Elasticsearch启动时仍会抛出磁盘空间不足错误。
额外说明：GCP持久盘支持在线扩容，但ext4/xfs类文件系统不会随云盘容量提升自动扩展，需要手动触发文件系统resize流程；之前执行的缩容Operator、删除StatefulSet的操作未触发该流程，因此扩容后的空间无法被业务识别使用。

前置校验 #

先确认基础资源状态正常，排除配置错位问题：

• 执行以下命令查看PVC、对应PV的容量，确认已更新为设置的目标值：

kubectl get pvc <es-pvc-name> -n <namespace>
kubectl get pv <corresponding-pv-name>

• 到GCP云盘控制台确认对应持久盘的实际容量与目标值一致，排除云厂商层面扩容未生效问题。
• 确认重建StatefulSet后没有生成新的PVC，避免出现新旧PVC错位、未挂载原数据盘的问题：如果存在新生成的关联PVC，需立即删除，调整StatefulSet的volumeClaimTemplates标签选择器与原PVC匹配。

修复文件系统未扩容问题 #

推荐使用临时调试Pod的方式执行文件系统扩容，操作安全且不损坏原有数据：

1. 将Elasticsearch StatefulSet副本数缩为0，等待关联Pod完全删除：

kubectl scale sts <es-sts-name> -n <namespace> --replicas=0

2. 新建临时调试Pod配置文件fs-resize.yaml，将待修复的PVC挂载到调试Pod中，挂载路径与原Elasticsearch Pod保持一致：

apiVersion: v1
kind: Pod
metadata:
  name: fs-resize-worker
  namespace: <namespace>
spec:
  containers:
  - name: resize
    image: busybox:stable
    command: ["/bin/sh", "-c", "sleep 3600"]
    securityContext:
      privileged: true
    volumeMounts:
    - name: es-data-volume
      mountPath: /usr/share/elasticsearch/data
  volumes:
  - name: es-data-volume
    persistentVolumeClaim:
      claimName: <es-pvc-name>
  restartPolicy: Never

3. 启动调试Pod，进入容器执行文件系统扩容：

kubectl apply -f fs-resize.yaml
# 等待Pod启动后进入容器
kubectl exec -it fs-resize-worker -n <namespace> -- /bin/sh
# 先执行文件系统检查，避免扩容过程损坏数据
fsck -f /dev/sdb
# 执行ext4文件系统扩容，自动匹配块设备新容量
resize2fs /dev/sdb
# 验证扩容结果，查看挂载路径总容量是否为目标值
df -h /usr/share/elasticsearch/data

4. 确认容量生效后，删除调试Pod：

kubectl delete pod fs-resize-worker -n <namespace>

恢复Elasticsearch服务 #

1. 恢复Elasticsearch Operator副本数：

kubectl scale deployment <es-operator-name> -n <namespace> --replicas=1

2. 将Elasticsearch StatefulSet副本数恢复为原有数值，等待Pod启动完成：

kubectl scale sts <es-sts-name> -n <namespace> --replicas=<original-replica-count>

3. 解除索引只读限制：之前磁盘触发洪泛水位线时，ES会自动将所有索引设为只读模式，服务启动后需要手动解除该限制：

# 建立本地端口转发访问ES服务
kubectl port-forward svc/<es-service-name> 9200:9200 -n <namespace>
# 调用API清除只读标记
curl -XPUT -H "Content-Type: application/json" http://localhost:9200/_all/_settings -d '{"index.blocks.read_only_allow_delete": null}'

服务验证 #

执行以下命令查看集群状态，确认集群健康状态从RED恢复为GREEN/YELLOW，读写请求可正常响应：

curl http://localhost:9200/_cluster/health?pretty

• 后续对ES集群做PVC扩容时，无需删除StatefulSet、缩容Operator：只要对应StorageClass开启allowVolumeExpansion: true，直接修改PVC的spec.resources.requests.storage字段即可，扩容完成后重启对应Pod，大部分新版本K8s集群会自动触发文件系统resize。
• 配置ES索引生命周期管理（ILM）规则，自动清理过期历史索引，同时根据业务量合理设置磁盘水位线阈值，避免再次出现磁盘写满故障。
• 建议ES数据盘预留至少20%的剩余空间，不要等磁盘用满再处理，磁盘写满可能导致索引损坏、集群选主失败等连锁问题。

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