本地minikube部署StatefulSet类型mysql报错：pod mysql-0未分配宿主

排查步骤 #

• 第一步：验证StorageClass配置有效性
  执行kubectl get sc test-sc -o yaml检查两个核心参数：

  1. provisioner字段是否和日志里的docker.io/hostpath一致？minikube默认的hostpath provisioner为k8s.io/minikube-hostpath，自定义的test-sc如果配错provisioner会无法自动创建PV
  2. volumeBindingMode字段是否为Immediate？如果是WaitForFirstConsumer需要额外确认pod调度无资源限制问题

• 第二步：校验现有PV与PVC的匹配项
  执行kubectl get pv -o wide，逐一核对提前创建的PV是否满足所有以下条件：

  • 存储类名称storageClassName是否为test-sc，和volumeClaimTemplates里的配置完全一致
  • 容量是否≥1Gi，满足PVC的存储请求
  • 访问模式包含ReadWriteOnce
  • 没有被其他PVC绑定，状态为Available
  • 如果PV设置了nodeAffinity，需要确认和minikube节点的标签匹配

• 第三步：检查资源配额问题
  执行kubectl describe node minikube查看节点剩余可分配资源，确认是否满足mysql的cpu:500m、memory:1Gi的请求阈值，minikube默认启动的节点资源如果分配过低也会导致PVC绑定失败连带调度失败。

解决方案 #

方案1：修复自定义StorageClass自动供应PV（推荐） #

将test-sc配置修改为minikube适配的版本：

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: test-sc
provisioner: k8s.io/minikube-hostpath
reclaimPolicy: Delete
volumeBindingMode: Immediate

应用配置后删除旧的处于pending状态的PVC，StatefulSet会自动重新发起PVC创建请求，PV会被自动供应。

方案2：手动创建匹配的PV绑定 #

如果不想使用自动供应，直接创建符合要求的PV即可：

apiVersion: v1
kind: PersistentVolume
metadata:
  name: mysql-pv
  labels:
    type: local
spec:
  storageClassName: test-sc
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: "/mnt/data/mysql"

应用配置后PVC会自动绑定到该PV，重新启动StatefulSet即可恢复。

快速验证方案 #

如果要快速定位是否是存储配置问题，可以将volumeClaimTemplates里的storageClassName改为minikube默认的standard存储类，直接测试是否能正常启动。

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