EKS中Redis（Bitnami Helm）PVC配置最佳实践问询

一、PVC配置方式选择：Helm自动配置 vs 手动创建 #

• Helm自动配置：Bitnami的Redis Helm Chart内置成熟的PVC模板，支持动态Provisioning（前提是集群已配置AWS EBS StorageClass）。优势是省心，Chart会自动为主节点和每个从节点创建独立PVC，默认配置符合Redis存储需求（如ReadWriteOnce访问模式、存储类关联等），适合快速部署、维护需求低的场景。
• 手动创建PV+PVC：适合需要精确控制存储参数的场景（比如指定EBS卷类型、IOPS、快照恢复等）。需注意：Bitnami Chart允许指定已存在的PVC名称，你需要为主节点和每个从节点分别创建对应PVC，确保PVC的storageClassName、访问模式与集群匹配，且名称要和Chart中master.existingClaim/slave.existingClaim参数对应。

二、多可用区（AZ）场景下手动创建EBS+PV+PVC的处理 #

AWS EBS卷是AZ专属资源，只能挂载到同一AZ内的K8s节点，手动配置时需遵循以下规则：

• 为每个AZ的Redis Pod（主/从）创建对应AZ的EBS卷：创建PV时，通过nodeAffinity指定PV所属AZ，比如在PV的spec.nodeAffinity.required.nodeSelectorTerms中添加topology.kubernetes.io/zone: us-west-2a这类标签，确保PV只绑定到该AZ的节点。
• 为每个从节点分配对应AZ的PVC：若部署多AZ从节点，需为每个从节点单独创建PVC并关联对应AZ的PV，同时在Helm Chart中配置slave.replicaCount，通过slave.existingClaim指定每个从节点的PVC名称。

三、是否需要将Redis Pod绑定到特定节点？ #

• 主节点：建议通过**节点亲和性（Node Affinity）**绑定到目标AZ的节点，确保主Pod和其PVC（关联的EBS卷）在同一AZ。因为EBS卷无法跨AZ挂载，若Pod调度到其他AZ，会因无法挂载PVC启动失败。
• 从节点：同理，每个从节点的Pod必须和对应PVC在同一AZ。可通过Pod的topologySpreadConstraints配合节点亲和性，实现从节点在多个AZ均匀分布，同时保证每个Pod与自身PVC同AZ。
• 不绑定的风险：无亲和性约束时，调度器可能将Pod调度到其他AZ，导致PVC挂载失败，Pod处于Pending状态，直接影响Redis集群可用性。

四、Redis Pod与PVC不在同一AZ的影响 #

肯定无法正常工作。AWS EBS卷是AZ专属资源，跨AZ无法挂载，Pod会一直处于ContainerCreating或Pending状态，直到调度到PVC所属AZ的节点，或PVC被删除重建到对应AZ，这种情况会直接导致Redis实例无法启动、集群服务中断。

五、最佳实践总结 #

1. 优先使用Helm动态Provisioning：Bitnami Chart默认支持通过AWS EBS StorageClass动态创建PVC，只需确保集群中存在对应AZ的StorageClass（可配置allowedTopologies限制StorageClass在指定AZ创建卷）。这种方式无需手动管理PV/PVC，且自动适配多AZ场景。
2. 手动配置PV/PVC规范：
   • 为主/每个从节点创建独立PVC，每个PVC关联对应AZ的PV。
   • 在PV中配置nodeAffinity指定AZ，确保PV只能被该AZ的节点绑定。
   • 在Redis Pod中配置nodeAffinity，匹配PV所在的AZ标签，保证Pod调度到正确AZ。
3. 多AZ部署拓扑约束：
   • 使用topologySpreadConstraints让Redis从节点均匀分布在多个AZ，提升集群可用性。
   • 配合StorageClass的allowedTopologies，确保动态创建的EBS卷分布在目标AZ。
4. 存储参数优化：
   • Redis对低延迟存储敏感，优先选择gp3或io2类型的EBS卷，避免低性能的gp2。
   • 配置合适的存储大小，避免因空间不足导致Redis故障。
   • 开启EBS卷快照功能，定期备份Redis数据。

内容的提问来源于stack exchange，提问作者prosto.vint