在Kubernetes中配置持久化存储时，网络存储方案的选择往往让人纠结：NFS、iSCSI、CephFS各有拥趸，但到底哪个适合你的场景？本文从实际部署中遇到的性能、可用性和运维复杂度问题出发，逐步解析这三类方案的协议原理、配置要点和取舍，帮助你做出合理决策。
为什么需要网络存储？
Kubernetes中的Pod是临时性的，容器重启或迁移后，本地数据会丢失。为了持久化数据，需要将存储与Pod生命周期解耦。本地存储（如emptyDir、HostPath）虽然简单，但无法跨节点共享，且数据随节点故障丢失。网络存储通过协议（如NFS、iSCSI、CephFS）将远端存储挂载到Pod中，实现数据持久化和跨节点共享，是生产环境的常见选择。
NFS：简单易用的文件级共享
NFS（Network File System）是最常见的网络文件系统之一，基于客户端-服务器模型，通过RPC（远程过程调用）传输文件数据。在Kubernetes中，NFS通常作为PersistentVolume（PV）的存储后端，支持ReadWriteMany（RWX）访问模式，即多个Pod可以同时读写同一个卷，非常适合共享文件场景，如静态文件服务、内容管理。
配置NFS PV的步骤相对简单：首先在NFS服务器上导出目录，然后在Kubernetes中创建PV和PVC。以下是一个NFS PV的YAML示例（注意，实际配置需根据环境调整）：
apiVersion: v1
kind: PersistentVolume
metadata:
name: nfs-pv
spec:
capacity:
storage: 10Gi
accessModes:
- ReadWriteMany
nfs:
server: 192.168.1.100
path: /exports/data
NFS的优点是简单、成熟、兼容性好，几乎所有Linux发行版都支持。但它的性能受限于网络和文件锁机制，在高并发写入场景下可能出现瓶颈。此外，NFS服务器本身是单点，如果服务器宕机，所有依赖它的Pod都会受影响。虽然可以使用HA方案（如Keepalived+DRBD），但配置复杂。
iSCSI：块级存储的稳定之选
iSCSI（Internet Small Computer System Interface）是一种基于IP网络的块级存储协议，它将SCSI命令封装在TCP/IP中传输。与NFS的文件级共享不同，iSCSI提供的是块设备，客户端（initiator）连接到存储服务器（target），将远端磁盘当作本地磁盘使用。在Kubernetes中，iSCSI通常以RWO（ReadWriteOnce）模式挂载，即同一时间只能被一个节点挂载，适合数据库等需要独占磁盘的场景。
配置iSCSI PV需要先配置iSCSI target（如使用tgt或LIO），然后在Kubernetes中指定iSCSI的target IP、IQN和LUN。示例：
apiVersion: v1
kind: PersistentVolume
metadata:
name: iscsi-pv
spec:
capacity:
storage: 10Gi
accessModes:
- ReadWriteOnce
iscsi:
targetPortal: 192.168.1.101:3260
iqn: iqn.2024-01.example:storage
lun: 0
fsType: ext4
iSCSI的性能通常优于NFS，因为它绕过了文件系统层，直接提供块设备，减少了协议开销。但iSCSI的配置相对复杂，需要管理target、IQN和LUN，且不支持多节点同时读写（除非使用集群文件系统如OCFS2）。另外，iSCSI的传输基于TCP，网络延迟和丢包会影响性能，建议使用专用网络或低延迟网络。
CephFS：分布式存储的弹性扩展
CephFS是Ceph分布式存储系统提供的文件系统，它通过Ceph集群的多个节点（MON、MDS、OSD）提供高可用、可扩展的文件存储。CephFS支持POSIX语义，提供RWX访问模式，适合大规模容器集群的共享存储。在Kubernetes中，CephFS通常通过CSI驱动集成，支持动态创建PV。
配置CephFS需要先部署Ceph集群，然后安装Ceph CSI驱动。部署Ceph集群本身较复杂，但一旦就绪，在Kubernetes中使用CephFS非常方便，只需创建StorageClass和PVC。示例StorageClass：
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: cephfs
provisioner: cephfs.csi.ceph.com
parameters:
clusterID: my-ceph-cluster
fsName: myfs
csi.storage.k8s.io/provisioner-secret-name: ceph-secret
csi.storage.k8s.io/provisioner-secret-namespace: default
csi.storage.k8s.io/controller-expand-secret-name: ceph-secret
csi.storage.k8s.io/controller-expand-secret-namespace: default
CephFS的优势在于高可用和可扩展性，数据自动复制，无单点故障。但它也有代价：Ceph集群的部署和运维门槛较高，需要专门的团队管理。此外，CephFS在元数据性能上可能不如本地文件系统，对于小文件密集的负载需要调优。
对比与选型：如何决策？
选择哪种方案，取决于你的应用场景和运维能力。以下是一些判断标准：
- 如果应用需要多Pod共享读写（RWX），且对性能要求不高，NFS是最简单的选择。
- 如果应用是数据库等需要块设备、且单节点独占（RWO）的场景，iSCSI更合适。
- 如果集群规模大、需要高可用和弹性扩展，且运维团队有Ceph经验，CephFS是长期之选。
此外，还需考虑网络环境。NFS和CephFS都基于TCP，但CephFS内部使用CRUSH算法，网络开销更大。iSCSI对网络延迟敏感，建议使用专用存储网络。在性能方面，块级（iSCSI）通常优于文件级（NFS、CephFS），但CephFS经过调优后可接近块级。
常见的误区是认为网络存储都差不多，随意选择。实际上，不同方案在故障处理、备份恢复、监控方面差异很大。例如，NFS服务器挂掉后，Pod可能挂起；iSCSI连接断开后，文件系统可能损坏；CephFS虽然高可用，但MDS故障时会影响元数据操作。
配置与运维要点
无论选择哪种方案，都需要注意以下几点：
- 确保网络稳定，使用低延迟、无丢包的存储网络。
- 定期备份数据，尤其是NFS和iSCSI，它们没有内置复制机制。
- 监控存储性能，如IOPS、吞吐量、延迟，及时调整资源。
- 在Kubernetes中，合理设置PVC的回收策略和存储类，避免数据丢失。
对于NFS，可以配置no_root_squash和fsid=0等选项，但要注意安全性。对于iSCSI，建议使用CHAP认证。对于CephFS，需要管理好密钥和权限。
参考资料
延伸阅读