Как в Kubernetes Persistent Volume (PV) распределяются по разным зонам доступности?

Распределение Persistent Volume по зонам доступности (Availability Zones) управляется через механизм топологии хранилища (Storage Topology), который координируется между StorageClass, CSI-драйвером и планировщиком Kubernetes.

Основной механизм:

1. StorageClass с ограничением по зонам: В StorageClass через параметр allowedTopologies указывается, в каких зонах можно создавать тома.
2. Отложенная привязка (WaitForFirstConsumer): Ключевой параметр volumeBindingMode: WaitForFirstConsumer в StorageClass. Он откладывает создание и привязку PV до тех пор, пока не будет запланирован Pod, который будет использовать этот том. Планировщик учитывает зону, в которой планируется Pod, и CSI-драйвер создает PV именно в этой зоне.

Пример StorageClass для регионального диска в GKE:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: regional-ssd
provisioner: pd.csi.storage.gke.io
parameters:
  type: pd-ssd
  replication-type: regional-pd
volumeBindingMode: WaitForFirstConsumer
allowedTopologies:
- matchLabelExpressions:
  - key: topology.gke.io/zone
    values:
    - europe-west3-a
    - europe-west3-b
    - europe-west3-c

Практические аспекты:

• Для статически созданных PV администратор вручную создает том в конкретной зоне и указывает соответствующую метку topology.kubernetes.io/zone в манифесте PV.
• Этот подход предотвращает ситуацию, когда Pod запланирован в зоне us-east-1a, а его том находится в us-east-1b, что привело бы к ошибке подключения и задержкам.
• Разные облачные провайдеры (AWS, GCP, Azure) используют свои CSI-драйверы и названия меток топологии, но общий принцип остается одинаковым.