linux 本身不安装 kubernetes 存储卷，pv/pvc 是集群级 api 对象，需在运行中的 k8s 集群内配置；所谓“linux 中安装”，实为准备底层存储（如目录、nfs、云盘）并确保节点可访问，所有 pv/pvc yaml 均提交给 kube-apiserver 管理。
直接说结论：Linux 本身不“安装 Kubernetes 存储卷”，Kubernetes 存储卷（PV/PVC）是集群级抽象，必须在运行中的 k8s 集群内配置；所谓“Linux 中安装”，实际是指在 Linux 节点上准备底层存储介质，并在 k8s 中声明 PV。
为什么不能直接在 Linux 上“安装”PV？
PV（PersistentVolume）不是 Linux 软件包，也不是可执行二进制文件。它是 Kubernetes API 对象，由 kube-apiserver 管理、kubelet 在节点侧挂载。你在 Linux 上能做的只有两件事：提供物理/网络存储（如 /mnt/data 目录、NFS 服务、云盘设备），以及确保节点能访问它（比如装 nfs-utils、加载 iscsi_tcp 模块）。所有 YAML 定义（PersistentVolume、PersistentVolumeClaim）都提交给集群，不由 Linux 系统直接解析。
HostPath 类型 PV 在单节点集群（如 Minikube）怎么配？
这是最常被误当成“Linux 安装存储卷”的场景——其实只是用宿主机目录模拟 PV，仅限开发测试。
- 先在 Linux 节点上创建目录并写测试文件：
sudo mkdir -p /mnt/data && echo "test" | sudo tee /mnt/data/index.html - 确认目录权限：确保
kubelet进程（通常以root或systemd用户运行）有读写权，避免Permission denied错误 - 定义 PV 时
spec.hostPath.path必须是绝对路径，且type: DirectoryOrCreate比空字符串更安全（自动建目录，防 Pod 启动失败） - 注意
accessModes：HostPath 只支持ReadWriteOnce，如果 PVC 写了ReadWriteMany，会永远处于Pending状态
生产环境该用什么替代 HostPath？
HostPath 绑定具体节点，不可跨节点调度，也不支持高可用——生产中必须换掉。
- NFS 是入门首选：部署一个 NFS 服务端（
apt install nfs-kernel-server），导出目录，然后在 PV 中填spec.nfs.server和spec.nfs.path；但要注意 NFS 服务器单点故障，且性能受网络抖动影响明显 - 云厂商存储（如阿里云云盘）：依赖
StorageClass+provisioner（如alicloud/disk），PVC 提交后自动创建云盘并绑定 PV；关键参数是reclaimPolicy：设为Retain才能在删 PVC 后保留数据，否则Delete会连云盘一起销毁 - CSI 插件（如 Ceph CSI、Rook）：需要额外部署控制器和节点插件，但提供真正的分布式持久化，支持快照、克隆、拓扑感知等高级功能；配置复杂，
volumeHandle和nodeStageSecretRef字段容易填错导致挂载失败
挂载失败常见原因和检查点
Pod 一直卡在 ContainerCreating，大概率是存储挂载环节出问题。
- 看事件：
kubectl describe pod <pod-name></pod-name>，重点找Events区域的FailedMount或FailedAttachVolume - 查节点日志：
journalctl -u kubelet -n 100 --no-pager | grep -i volume，常暴露 NFS 超时、认证失败、设备 busy 等底层错误 - 确认插件就绪：运行
kubectl get csinodes和kubectl get pods -n kube-system | grep csi，缺失 CSI 控制器或节点驱动会导致 PVC 无法绑定 - 注意 SELinux：CentOS/RHEL 默认开启，可能阻止
kubelet挂载，临时关闭验证：setenforce 0；长期方案是打 SELinux 策略或改容器securityContext
真正麻烦的从来不是写几行 YAML，而是搞清存储路径谁负责创建、权限归谁、网络通不通、插件版本对不对——这些细节不验清楚，PV 就只是个挂在 API server 里的空对象。
