GKE多可用区场景下区域持久化磁盘的适配问题问询

针对你遇到的Regional PD在3+可用区GKE集群里的调度问题，以下是几种可行的解决思路：

一、优化Regional PD的调度约束（补全遗漏配置） #

Regional PD仅支持2个可用区同步，要避免Pod调度到未覆盖的AZ导致挂起，可以通过以下配置限制调度范围：

• 给PVC添加拓扑约束：在StorageClass中指定allowedTopologies，限定PD只能在指定的2个AZ中创建，同时让Pod的调度范围匹配这两个AZ。示例配置：

  apiVersion: storage.k8s.io/v1
  kind: StorageClass
  metadata:
    name: regional-pd-sc
  provisioner: pd.csi.storage.gke.io
  parameters:
    type: pd-standard
    replication-type: regional-pd
    zones: us-central1-a,us-central1-b
  allowedTopologies:
  - matchLabelExpressions:
    - key: topology.gke.io/zone
      values:
      - us-central1-a
      - us-central1-b
  volumeBindingMode: WaitForFirstConsumer
  

• 给Pod添加节点亲和性：直接限制Pod只能调度到PD覆盖的两个AZ节点上，确保调度匹配：

  spec:
    affinity:
      nodeAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
          nodeSelectorTerms:
          - matchExpressions:
            - key: topology.gke.io/zone
              operator: In
              values:
              - us-central1-a
              - us-central1-b
  

二、使用全局/区域级托管存储（无AZ限制） #

如果需要Pod能在集群所有AZ自由调度，无需约束范围，推荐以下更适配的方案：

• GCS + GCSFuse：完全适配低频读写场景，GCS是全局存储，不受AZ限制，通过GCSFuse将GCS bucket挂载为Pod内的文件系统。单配置文件的场景下，无需管理存储集群，成本低，运维简单。
• FileStore：区域级NFS存储，覆盖整个GCP区域内的所有可用区，Pod在任意AZ都能挂载访问。适合需要多Pod共享配置的场景，但对于单个小配置文件来说，资源开销略大。
• ConfigMap（只读场景优先）：如果配置文件以读为主、修改频率极低且无需应用直接写入，K8s原生ConfigMap是最优选择。将配置内容存入ConfigMap后挂载到Pod，天然支持跨AZ调度，修改配置只需更新ConfigMap并滚动重启Pod即可。

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