Como distribuir uniformemente os pods nas zonas de disponibilidade?

Usar topologySpreadConstraints no manifesto do pod ou implantação.

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 # Chave que define a zona de distribuição (zona de disponibilidade)
        whenUnsatisfiable: DoNotSchedule # Se a distribuição não for possível, o pod não será agendado
        labelSelector:
          matchLabels:
            app: my-app # A restrição aplica-se aos pods com este rótulo

maxSkew define o número máximo de pods que podem exceder a média em qualquer domínio de topologia (zona de disponibilidade). Neste caso, maxSkew: 1 significa que a diferença no número de pods entre qualquer par de zonas de disponibilidade não excederá 1.

topologyKey: topology.kubernetes.io/zone indica que a distribuição deve ser baseada nas etiquetas de zonas de disponibilidade dos nós.

whenUnsatisfiable: DoNotSchedule significa que, se o agendador não puder satisfazer a restrição topologySpreadConstraints, o pod não será agendado. Outra opção é ScheduleAnyway, que tentará agendar o pod, mas pode violar a restrição.

labelSelector define o conjunto de pods aos quais essa restrição se aplica.

Para distribuir uniformemente os pods em três zonas (por exemplo, us-east-1a, us-east-1b, us-east-1c) com 9 réplicas, cada zona receberá 3 pods.

Esse tipo de distribuição aumenta a resiliência da aplicação, pois a falha de uma zona de disponibilidade não tornará o serviço totalmente inacessível.