GKE部署Redis StatefulSet报卷节点亲和冲突解决方法

• 3个节点不匹配Pod节点选择器属于正常现象：你配置的nodeSelector仅匹配redis-pool节点池的节点，其余不属于该池的节点会被直接过滤，符合预期。
• 剩余1个节点报卷节点亲和性冲突的核心原因：你当前使用的standard存储类默认采用*Immediate（立即）*卷绑定模式，PVC创建后会立即自动制备PV，不会等待Pod调度结果；GKE的区域级持久磁盘制备时会随机选择集群所在区域的任意可用区，如果PV被分配到了和单AZ部署的redis-pool不同的可用区，就会触发亲和性冲突，Pod无法调度。

二选一即可，推荐优先用方案1，无需硬编码可用区。

方案1：更换为延迟绑定的存储类（推荐） #

GKE 1.22及以上版本默认提供standard-rwo、premium-rwo存储类，这类存储类的volumeBindingMode为WaitForFirstConsumer（等待消费者），会等Pod完成调度决策、确定落脚节点后，再在节点所在可用区制备对应PV，从根源避免跨AZ亲和冲突。

1. 先清理残留的错误资源：

   kubectl delete statefulset redis -n redis
   kubectl delete pvc -l app=redis -n redis
   

2. 修改StatefulSet的volumeClaimTemplates段，将存储类替换为延迟绑定的类型：

   volumeClaimTemplates:
   - metadata:
       name: data
     spec:
       accessModes: [ "ReadWriteOnce" ]
       # 替换为WaitForFirstConsumer模式的存储类，可通过kubectl get sc查看集群内可用的存储类
       storageClassName: "standard-rwo"
       resources:
         requests:
           storage: 50Mi
   

3. 重新应用资源清单即可。

方案2：给现有存储类的PVC显式指定可用区 #

如果需要继续使用standard存储类，可以在PVC模板中强制约束所有PV只能创建在redis-pool所在的可用区。

1. 先查询redis-pool内节点所属的可用区：

   # 替换node-name为redis-pool内的节点名，可通过kubectl get node -l cloud.google.com/gke-nodepool=redis-pool获取
   kubectl get node <node-name> -o jsonpath='{.metadata.labels.topology\.kubernetes\.io/zone}'
   

2. 清理残留的错误资源（同方案1的清理命令）。
3. 修改volumeClaimTemplates段，增加allowedTopologies约束：

   volumeClaimTemplates:
   - metadata:
       name: data
     spec:
       accessModes: [ "ReadWriteOnce" ]
       storageClassName: "standard"
       resources:
         requests:
           storage: 50Mi
       # 新增以下配置，强制PV创建在指定可用区
       allowedTopologies:
       - matchLabelExpressions:
         - key: topology.kubernetes.io/zone
           values:
           # 替换为上一步查询到的实际可用区，例如us-central1-a
           - <your-node-pool-zone>
   

4. 重新应用资源清单即可。

额外说明 #

你当前的清单已经通过nodeSelector将Pod调度范围限制在redis-pool节点池，且未配置跨节点的Pod反亲和规则，只要PV可用区匹配节点所在可用区，3个Redis副本会自动调度到该池的单节点上，无需额外添加调度配置。由于3个副本使用各自独立的RWO卷，只要卷和节点同属一个可用区，就可以同时挂载到该节点，不会产生卷挂载冲突。

资源应用后执行以下命令检查状态：

• 执行kubectl get pvc -n redis，确认所有3个data-redis-*的PVC均为Bound状态
• 执行kubectl get pod -n redis -o wide，确认3个Redis副本均运行在redis-pool的同一个节点上

注意：由于你将3个副本全部部署在单节点上，节点故障会导致所有Redis副本同时离线，请提前评估业务可用性风险。

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