场景判断

无状态优先；有状态才上卷。PVC 声明容量与访问模式，PV 是库存，StorageClass 让动态 provisioner 自动开卷。本地 kind 若未装 local-path-provisioner 等，apply 后 PVC 可能长期 Pending——这不是 YAML 写错，而是「货架上没有默认供应商」。

真实案例骨架：单副本库改成 Deployment replicas=3 并共用一块 RWO PVC——第二、三个 Pod 卡在 ContainerCreating/Pending，Events 写 Multi-Attach。订单（PVC data）只有一份货，有状态负载应评估 StatefulSet 或每副本独立卷，而不是假设共享一块盘就能水平扩展。

复现步骤

本机勾选备忘（localStorage），不代表你已在集群里跑过，也不连接任何 API。只是帮你对照步骤，别当成「学会了」的勋章。

— / 5本机勾选

01盘点：kubectl get sc,pvc,pv — 是否有默认 StorageClass（(default)）。
02读 examples/storage/pvc.yaml：name=data、accessModes=ReadWriteOnce、storage=1Gi。
03apply -f examples/storage/pvc.yaml；get pvc data — 记录 Bound 或 Pending。
04若 Pending：describe pvc data，在 Events 中找 provisioner / 默认 SC / 权限类原因（本地常见：无默认 SC）。
05口述：多副本 Deployment + 单 RWO 的风险；清理 kubectl delete -f examples/storage/pvc.yaml（注意 reclaimPolicy）。

关键配置

YAMLyaml

# examples/storage/pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: data
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
  # storageClassName: standard  # 省略则用默认 SC

SHELLbash

# 盘点供应能力
kubectl get sc,pvc,pv

# 下单
kubectl apply -f examples/storage/pvc.yaml
kubectl get pvc data
kubectl describe pvc data

# 读访问模式（RWO ≠ 多副本共享）
kubectl explain persistentvolumeclaim.spec.accessModes

kubectl delete -f examples/storage/pvc.yaml

Bound 只证明订单配货成功——不证明你的三副本库都能安全共用同一块盘。

验收：能用订单/库存/货架类比 PVC/PV/SC；Pending 时第一条命令是 describe pvc 不是 delete；能向同事说明 Multi-Attach 风险。

现场记录

先写自己的证据，再看参考答案。输入只留在当前页面，本站不会读取或验证你的集群。

存储订单：PVC Pending 与 RWO

Evidence Receipt · 执行凭证

Kubernetes 版本验证日期版本 / 产物引用

只填写你实际运行过的环境；stdout / Events 请脱敏后写入下方证据句。

现象

第一条命令

证据句

判断

动作与回滚

这是你的手动确认，不代表本站已检测命令执行结果。

关联命令

跳转图鉴并展开对应条目（可复制示例）。

kubectl get pvc kubectl apply -f kubectl explain kubectl delete

对应路径课节

路径 · 存储一条业务故事