存储 — NFS 动态 Provisioning

K8s 存储模型

应用声明需求（PVC）→ StorageClass 匹配 → Provisioner 自动创建 PV → Pod 挂载使用

三个核心概念

概念	类比	说明
PV (PersistentVolume)	磁盘	一块实际的存储空间
PVC (PersistentVolumeClaim)	购买请求	"我要 10Gi 的 ReadWriteOnce 存储"
StorageClass	磁盘类型目录	"NFS 动态/本地 SSD/云盘"

静态 vs 动态 Provisioning

方式	流程	场景
静态	管理员手动创建 PV → PVC 绑定现有 PV	遗留存储、特殊硬件
动态	PVC 引用 StorageClass → Provisioner 自动创建 PV	生产首选，自动化

我们的 NFS 存储架构

Worker-4 (154.219.104.66, 150G 磁盘)
  └── /srv/nfs/k8s          ← NFS 导出目录
        ├── pvc-xxx-prometheus/  ← 自动创建的子目录
        ├── pvc-xxx-grafana/
        ├── pvc-xxx-loki/
        └── pvc-xxx-harbor/

NFS Server 配置

# Worker-4 上
apt-get install -y nfs-kernel-server
mkdir -p /srv/nfs/k8s
echo '/srv/nfs/k8s *(rw,sync,no_subtree_check,no_root_squash)' > /etc/exports
exportfs -ra

参数解释：

* — 允许所有客户端挂载
rw — 读写
sync — 写操作同步到磁盘后才返回（数据安全）
no_subtree_check — 不检查父目录权限（性能优化）
no_root_squash — 允许客户端 root 权限（容器需要）

NFS CSI Provisioner

helm install nfs-provisioner nfs-subdir-external-provisioner/nfs-subdir-external-provisioner \
  --set nfs.server=10.10.0.5 \
  --set nfs.path=/srv/nfs/k8s \
  --set storageClass.name=nfs-dynamic \
  --set storageClass.defaultClass=true    # 设为默认 StorageClass

安装后，任何 PVC 不指定 storageClassName 就会使用 nfs-dynamic。

当前 PVC 使用情况

Prometheus:    10Gi  (monitoring/prometheus-xxx)
Alertmanager:   2Gi  (monitoring/alertmanager-xxx)
Grafana:        5Gi  (monitoring/monitoring-grafana)
Loki:          10Gi  (monitoring/loki)
Harbor:        20Gi+ (harbor/多个组件)
Gitea:          5Gi  (gitea/postgresql + gitea-storage)
共计约 16 个 PVC，全部自动分配

Access Modes

Mode	含义	适用存储
`ReadWriteOnce` (RWO)	单节点读写	云盘、本地磁盘
`ReadWriteMany` (RWX)	多节点读写	NFS、CephFS
`ReadOnlyMany` (ROX)	多节点只读	静态内容分发

NFS 支持 RWX，这是它的优势——多个 Pod 可以同时挂载同一个 PVC。

Reclaim Policy

PVC 删除后 PV 怎么办？

Policy	行为
`Delete`	PV 和底层存储一起删除（我们的默认）
`Retain`	PV 保留，数据不删，需要手动清理

面试题：为什么 StatefulSet 的 PVC 缩容后不删？

StatefulSet 缩容（3→2）时，web-2 的 PVC 保留。这是数据安全设计——万一是误操作，扩回来后 PVC 自动重新绑定，数据不丢。要真删需要手动 kubectl delete pvc。

→ 03-ingress-networkpolicy.md