Comment répartir uniformément les pods dans les zones de disponibilité?

Utiliser topologySpreadConstraints dans le manifeste du pod ou du déploiement.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 9
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app-container
        image: my-app:latest
      topologySpreadConstraints:
      - maxSkew: 1
        topologyKey: topology.kubernetes.io/zone # Clé définissant la zone de distribution (zone de disponibilité)
        whenUnsatisfiable: DoNotSchedule # Si la distribution n'est pas possible, le pod ne sera pas planifié
        labelSelector:
          matchLabels:
            app: my-app # La contrainte s'applique aux pods avec cette étiquette

maxSkew définit le nombre maximum de pods qui peuvent dépasser la moyenne dans n'importe quel domaine de topologie (zone de disponibilité). Ici, maxSkew: 1 signifie que la différence de nombre de pods entre toute paire de zones ne dépassera pas 1.

topologyKey: topology.kubernetes.io/zone indique que la distribution doit être basée sur les étiquettes de zones de disponibilité des nœuds.

whenUnsatisfiable: DoNotSchedule indique que si le planificateur ne peut pas respecter la contrainte topologySpreadConstraints, le pod ne sera pas planifié. Une autre option est ScheduleAnyway, qui tentera de planifier le pod mais peut violer la contrainte.

labelSelector définit l'ensemble des pods auxquels cette contrainte s'applique.

Pour une distribution uniforme des pods sur trois zones (par exemple, us-east-1a, us-east-1b, us-east-1c) avec 9 réplicas, chaque zone recevra 3 pods.

Ce type de distribution augmente la résilience de l'application, car la défaillance d'une zone de disponibilité ne rendra pas le service totalement inaccessible.