首页 / 资讯中心 / 文章详情

PV/PVC 一直 Pending:StorageClass 与绑定条件的 4 个检查点

PV/PVC 一直 Pending:StorageClass 与绑定条件的 4 个检查点 ★ FEATURED ARTICLE
我不会起名字322· 后端 / 算法 / 数据库 技术栈 力扣 Hot100 Go 项目 Redis MySQL文章目录PV/PVC 一直 PendingStorageClass 与绑定条件的 4 个检查点一、先看 PVC 的 Events二、检查点 1StorageClass 名字对不对三、检查点 2VolumeBindingMode 与 WaitForFirstConsumer四、检查点 3CSI 驱动活着吗五、检查点 4静态 PV 的匹配条件六、还有一个坑扩容七、带走物PV/PVC 一直 PendingStorageClass 与绑定条件的 4 个检查点一、先看 PVC 的 EventsPVC Pending 时原因通常直接写在 Events 里kubectl describe pvc>-nnsEvents: Type Reason Message ---- ------ ------- Normal WaitForFirstConsumer waiting for first consumer to be created before binding或者Warning ProvisioningFailed storageclass.storage.k8s.io fast-ssd not found看一眼 Events一半的问题就有答案了。下面四个检查点按概率排序。二、检查点 1StorageClass 名字对不对这是最高频的原因。# 集群里有哪些 StorageClasskubectl get storageclass# NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE# standard (default) kubernetes.io/gce-pd Delete Immediate# fast-ssd ebs.csi.aws.com Delete WaitForFirstConsumer# PVC 里写的是哪个kubectl get pvc>-ojsonpath{.spec.storageClassName}两个常见错误名字拼错fast-ssd写成fastssd→ 报storageclass not found没写storageClassName→ 会尝试用默认StorageClass如果集群没设默认PVC 就一直 Pending。# 看有没有默认 SCannotations 里有那个标记kubectl get storageclass-ojson|jq-r.items[] | select(.metadata.annotations[storageclass.kubernetes.io/is-default-class]true) | .metadata.name没有默认 SC 时要么显式写storageClassName要么给某个 SC 打默认标记kubectl patch storageclass standard-p{metadata:{annotations:{storageclass.kubernetes.io/is-default-class:true}}}还有一个坑storageClassName: 空字符串表示明确不用动态供给只会去匹配预先创建好的、没有 class 的 PV。写错了就会 Pending。三、检查点 2VolumeBindingMode 与WaitForFirstConsumer如果 Events 里是WaitingForFirstConsumer: waiting for first consumer to be created before binding这不是错误这是设计。volumeBindingMode: WaitForFirstConsumer的含义是先不急着创建卷等第一个真正用它的 Pod 被调度时再根据 Pod 所在的节点/可用区来创建。这么设计是为了避免跨可用区如果在不知道 Pod 会调度到哪个可用区的情况下就创建 EBS 卷很可能创建在错误的可用区导致 Pod 无法挂载。所以PVC Pending WaitForFirstConsumer 正常等 Pod 创建就会绑定但如果 Pod 已经创建了PVC 还是 Pending那就要往下查——通常是 Pod 本身因为别的原因没调度成功回到 Pending 那篇的排查或者 CSI 驱动有问题。四、检查点 3CSI 驱动活着吗动态供给Dynamic Provisioning依赖 CSI 驱动# 看 CSI 相关的 Podkubectl get pod-nkube-system|grep-iEcsi|ebs|gce|nfs# 以 aws-ebs-csi 为例kubectl logs-nkube-system deploy/ebs-csi-controller--tail50常见的失败CSI 驱动没装CSI controller CrashLoop通常是 IAM 权限问题CSI node plugin 在目标节点上没跑导致卷建好了但挂不上。# 看 PVC 相关的事件CSI 的错误会写在这里kubectl get events-nns--sort-by.lastTimestamp|grep-ipvc典型错误Failed to provision volume with StorageClass fast-ssd: rpc error: code Unauthenticated desc ...→ 权限问题去查 CSI 用的 ServiceAccount / IAM role。五、检查点 4静态 PV 的匹配条件如果你用的是预先创建的 PV静态供给那么 PV 和 PVC 必须满足所有匹配条件否则永远绑不上条件说明storageClassName必须一致或都为 “”accessModesPVC 要求的模式必须是 PV 支持的子集capacityPV 的容量 ≥ PVC 的请求volumeMode必须一致Filesystem / Blockselector如果 PVC 有PV 的 label 必须匹配nodeAffinity某些本地卷有节点亲和性约束# 看 PV 的状态和条件kubectl getpvkubectl describepvpv-name# 对比 PVC 的要求kubectl get pvcpvc-name-oyaml|grep-A5-EaccessModes|resources|storageClassName|selector最常见的两个不匹配1.accessModes不匹配。RWO (ReadWriteOnce) 单节点读写 ROX (ReadOnlyMany) 多节点只读 RWX (ReadWriteMany) 多节点读写 ← 很多存储类型不支持比如 NFS 支持 RWX但 EBS / 本地盘只支持 RWO。如果你的 PVC 要 RWX 但只有 RWO 的 PV就永远 Pending。2. 容量不够。PV 是 10GiPVC 要 20Gi → 不匹配。还有一个陷阱PV 已经被别的 PVC 绑定了CLAIM列显示已被占用那它就不能再被你用。kubectl getpv# NAME CAPACITY CLAIM STATUS# pv-001 10Gi default/data-mysql-0 Bound ← 已被占用# pv-002 10Gi Available ← 可用六、还有一个坑扩容K8s 支持 PVC 扩容但有条件# 1. StorageClass 必须允许扩容kubectl get storageclass fast-ssd-ojsonpath{.allowVolumeExpansion}# 必须是 true# 2. 有些存储类型只支持扩容不支持缩容# 3. 某些文件系统如 ext4扩容后需要 Pod 重启才能识别allowVolumeExpansion:true如果allowVolumeExpansion: false改 PVC 的resources.requests.storage会被拒绝。七、带走物排查顺序# 1. 看 Events最重要kubectl describe pvcpvc-nns# 2. 检查点 1StorageClass 名字kubectl get storageclass kubectl get pvcpvc-ojsonpath{.spec.storageClassName}# 3. 检查点 2是不是正常的 WaitForFirstConsumer# 是 → 等 Pod 创建不是错误# 4. 检查点 3CSI 驱动kubectl get pod-nkube-system|grep-icsi kubectl logs-nkube-system deploy/csi-controller--tail50# 5. 检查点 4静态 PV 的匹配条件kubectl getpvkubectl describepvpv# accessModes / capacity / claim一句话定位表Events原因动作storageclass xxx not found名字写错或没装改名字 / 装驱动waiting for first consumer正常行为等 Pod 创建或 Pod 自己 Pending去查 Podfailed to provision volume rpc errorCSI 驱动/权限问题查 CSI Pod 和日志静态 PV无 Events 但一直 Pending匹配条件不满足对比 class/accessModes/capacity改容量被拒allowVolumeExpansion: false改 SC但已有 SC 不可改要重建一句话结论PVC Pending 先看describe的 Events——waiting for first consumer是正常的storageclass not found是名字错了failed to provision是 CSI 的问题用静态 PV 的话还要逐条对比 class、accessModes 和容量。
阅读完成 · 觉得有帮助?
咨询建站