GKE集群中克服GCEPersistentDisk限制使用NFS的最佳实践咨询

现有调研方案疑问解答 #

• 关于nfs-server-provisioner弃用：该项目弃用属于官方维护方向转移，原维护团队将迭代重心迁移到了nfs-subdir-external-provisioner项目，旧版本本身没有致命缺陷，但后续不会提供安全漏洞修复和功能更新，不建议生产环境长期使用。
• 关于nfs-subdir-external-provisioner：该方案的前置NFS服务器可以低成本实现，在GKE环境中可直接部署单Pod NFS服务，挂载一块普通GCE PersistentDisk作为后端存储即可，具体部署逻辑仅需要配置NFS服务端口放行、集群内部访问权限即可。该方案的公开缺陷主要是单NFS节点存在单点故障风险、整体IO性能受限于后端PD和NFS Pod的资源配置，适合可用性要求不高的场景。
• 关于Google Filestore：作为谷歌托管的NFS服务，Filestore原生适配GKE，支持CSI驱动动态provisioning，稳定性和SLA有官方保障，唯一的劣势是最小1TB的容量门槛，适合容量需求匹配的生产场景。
• 关于GlusterFS：当前GlusterFS社区活跃度低，GKE环境无官方集成支持，部署、排障、运维复杂度极高，非特殊需求不建议采用。

分场景推荐方案 #

场景1：开发测试环境、非核心生产业务，成本敏感度高 #

推荐采用自托管NFS + nfs-subdir-external-provisioner方案，实现成本最低的RWX支持：

• 按需创建一块普通GCE PD（最小可到10GB），部署StatefulSet运行NFS服务挂载该PD，开放NFS端口给集群内部访问
• 安装nfs-subdir-external-provisioner Helm Chart，配置为对接上述NFS服务地址，创建对应StorageClass即可实现RWX卷的动态创建
• 补充配置：给NFS Pod设置节点亲和性固定调度节点、配置健康探针实现故障自动重启、定期对后端PD做快照备份，最大化降低单点故障风险

场景2：核心生产业务，容量需求≥1TB，对可用性要求高 #

推荐直接采用Google Filestore + 官方Filestore CSI驱动方案：

• 完全托管的NFS服务，官方提供99.9% SLA，无需自行维护存储服务
• 原生支持GKE动态PV provisioning，性能稳定，IO吞吐能力远高于自托管NFS方案

场景3：核心/非核心业务，容量需求小，对IO延迟要求不高 #

推荐采用Cloud Storage FUSE CSI驱动方案：

• 谷歌官方托管的CSI驱动，直接将GCS存储桶挂载为PV，原生支持RWX访问模式
• 按实际使用容量付费，无最小容量限制，远低于Filestore的使用成本
• 缺陷是IO性能远低于块存储和Filestore，适合存放静态资源、日志、备份数据等对延迟不敏感的文件

通用注意事项 #

• 所有RWX访问模式的卷都需要应用层处理并发写冲突，多个Pod同时写入同一文件时要自行实现文件锁、分片写入等逻辑，避免数据损坏
• 自托管存储方案要提前制定数据备份、故障恢复预案，避免单点故障导致数据丢失

内容的提问来源于stack exchange，提问作者NI6