Kubernetes NFS Client Provisioner高可用及多副本工作机制咨询

单副本与多副本的工作逻辑 #

• 单副本部署：唯一的Pod会持续监听Kubernetes API Server中对应StorageClass关联的PVC创建/删除事件。当有PVC请求到达时，该Pod会直接在绑定的NFS根目录下创建专属子目录，再自动生成对应PV完成绑定，全量存储供给请求都由这一个Pod处理。
• 多副本部署：所有副本都会监听API Server的PVC事件，但该组件默认启用*Kubernetes 领导选举（Leader Election）*机制，同一时间只会有一个副本处于leader状态处理请求，其余副本处于待机状态，不执行任何操作。

多副本是否会实现负载分发？ #

不会。
多副本部署仅实现高可用容灾能力，不存在负载分发逻辑：所有PVC处理请求只会由当前的leader副本执行，其余副本仅作为冗余备份。当leader副本因为节点故障、网络中断等原因异常退出时，其余副本会在几秒内完成新一轮选举，产生新的leader接管所有工作，避免存储供给服务中断。 #

单NFS挂载点场景下多副本的协同逻辑 #

你当前使用单个NFS挂载点的场景，多副本完全基于领导选举机制协同，不会出现操作冲突：

• 所有副本都会挂载同一个NFS根路径，但只有leader副本会执行子目录创建、PV生命周期管理的操作，备用副本不会对NFS路径做任何写入操作，不会出现多副本并发修改目录导致的一致性问题。
• 单挂载点场景下多副本部署不会提升存储供给性能，也无法分担请求压力，仅用于降低单点故障导致的服务中断风险。如果你的集群规模较小、PVC创建/删除的并发请求量不高，单副本完全可以满足使用需求。

内容的提问来源于stack exchange，提问作者Arunachalam .A