spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 2

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: api-reservas
  namespace: rutas-norte-pro
spec:
  maxUnavailable: 25%
  selector:
    matchLabels:
      app: api-reservas

# Esto IGNORA el PDB
kubectl delete pod api-reservas-7c9d4f8b6d-2mk8p -n rutas-norte-pro

# Esto RESPETA el PDB
kubectl drain <nodo> --pod-selector=app=api-reservas

spec:
  minAvailable: 3
  selector:
    matchLabels:
      app: api-reservas

spec:
  maxUnavailable: 1
  selector:
    matchLabels:
      app: api-reservas

Durante el puente: 30 replicas. Alguien pone minAvailable: 25.
  Desalojos permitidos: 5. Razonable.

Tras el puente: el HPA baja a 4 replicas. El PDB sigue diciendo minAvailable: 25.
  Pods disponibles: 4. Minimo exigido: 25.
  YA se esta por debajo del minimo.
  Desalojos permitidos: CERO. Para siempre.

El nodo que aloje cualquier replica de api-reservas queda ANCLADO.
El Cluster Autoscaler no lo puede retirar. El mantenimiento se bloquea.

POST /api/v1/namespaces/rutas-norte-pro/pods/api-reservas-7c9d4f8b6d-2mk8p/eviction

{
  "apiVersion": "policy/v1",
  "kind": "Eviction",
  "metadata": {
    "name": "api-reservas-7c9d4f8b6d-2mk8p",
    "namespace": "rutas-norte-pro"
  }
}

{
  "kind": "Status",
  "status": "Failure",
  "message": "Cannot evict pod as it would violate the pod's disruption budget.",
  "reason": "TooManyRequests",
  "details": {
    "causes": [
      {
        "reason": "DisruptionBudget",
        "message": "The disruption budget api-reservas needs 3 healthy pods and has 3 currently"
      }
    ]
  }
}

kubectl get pdb -n rutas-norte-pro

NAME                    MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
api-reservas            N/A             25%               1                     12d
tienda-web              N/A             1                 1                     12d
postgres-reservas       1               N/A               0                     12d
worker-notificaciones   N/A             50%               3                     12d

kubectl describe pdb api-reservas -n rutas-norte-pro

Name:             api-reservas
Namespace:        rutas-norte-pro
Max unavailable:  25%
Selector:         app=api-reservas
Status:
    Allowed disruptions:  2
    Current:              8
    Desired:              6
    Total:                8

minikube start -p rutas-norte --nodes=3 --cpus=2 --memory=4096

kubectl create namespace rutas-norte-dev

# Un Deployment con 3 replicas
kubectl -n rutas-norte-dev create deployment demo-pdb \
  --image=registry.k8s.io/pause:3.9 --replicas=3

kubectl -n rutas-norte-dev set resources deployment/demo-pdb \
  --requests=cpu=100m,memory=64Mi

# /tmp/pdb-demo.yaml
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: demo-pdb
  namespace: rutas-norte-dev
spec:
  # Con 3 replicas, exigir 3 disponibles significa CERO desalojos permitidos.
  minAvailable: 3
  selector:
    matchLabels:
      app: demo-pdb

kubectl apply -f /tmp/pdb-demo.yaml
kubectl get pdb -n rutas-norte-dev

NAME       MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
demo-pdb   3               N/A               0                     8s

kubectl get pods -n rutas-norte-dev -o wide

NAME                        READY   STATUS    NODE
demo-pdb-6c9f8d7b5-2mkjp    1/1     Running   rutas-norte
demo-pdb-6c9f8d7b5-7wqzx    1/1     Running   rutas-norte-m02
demo-pdb-6c9f8d7b5-9nvtr    1/1     Running   rutas-norte-m03

kubectl drain rutas-norte-m02 --ignore-daemonsets --delete-emptydir-data

node/rutas-norte-m02 cordoned
evicting pod rutas-norte-dev/demo-pdb-6c9f8d7b5-7wqzx
error when evicting pods/"demo-pdb-6c9f8d7b5-7wqzx" -n "rutas-norte-dev"
(will retry after 5s): Cannot evict pod as it would violate the pod's disruption budget.
evicting pod rutas-norte-dev/demo-pdb-6c9f8d7b5-7wqzx
error when evicting pods/"demo-pdb-6c9f8d7b5-7wqzx" -n "rutas-norte-dev"
(will retry after 5s): Cannot evict pod as it would violate the pod's disruption budget.
evicting pod rutas-norte-dev/demo-pdb-6c9f8d7b5-7wqzx
error when evicting pods/"demo-pdb-6c9f8d7b5-7wqzx" -n "rutas-norte-dev"
(will retry after 5s): Cannot evict pod as it would violate the pod's disruption budget.
...

# Opcion A: mas replicas. Con 4 replicas y minAvailable: 3, se permite 1 desalojo.
kubectl -n rutas-norte-dev scale deployment demo-pdb --replicas=4

# Opcion B: corregir el PDB
kubectl -n rutas-norte-dev patch pdb demo-pdb --type merge \
  -p '{"spec":{"minAvailable":null,"maxUnavailable":"25%"}}'

# Opcion C (ULTIMO RECURSO, peligroso): forzar el drenaje
kubectl drain rutas-norte-m02 --ignore-daemonsets --delete-emptydir-data \
  --disable-eviction

kubectl uncordon rutas-norte-m02
kubectl delete -f /tmp/pdb-demo.yaml
kubectl delete deployment demo-pdb -n rutas-norte-dev

spec:
  replicas: 3        # en el Deployment
---
spec:
  minAvailable: 3    # en el PDB

spec:
  replicas: 1
---
spec:
  minAvailable: 1        # Equivalente a maxUnavailable: 0

# Todos los PDB del cluster con sus desalojos permitidos
kubectl get pdb --all-namespaces

NAMESPACE          NAME                    MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS
rutas-norte-pro    api-reservas            N/A             25%               2
rutas-norte-pro    tienda-web              N/A             1                 1
rutas-norte-pro    postgres-reservas       1               N/A               0
rutas-norte-pro    redis-cache             1               N/A               0
rutas-norte-pro    worker-notificaciones   N/A             50%               4
monitorizacion     prometheus              1               N/A               0

# PDB que llevan mas de una hora sin permitir ningun desalojo
kube_poddisruptionbudget_status_pod_disruptions_allowed == 0

Replicas totales: 6
Replicas Ready: 2
Replicas no Ready: 4

PDB: maxUnavailable: 1 -> minimo 5 disponibles.
Disponibles actuales: 2. Ya estamos POR DEBAJO del minimo.
ALLOWED DISRUPTIONS: 0.

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: api-reservas
  namespace: rutas-norte-pro
spec:
  maxUnavailable: 25%
  selector:
    matchLabels:
      app: api-reservas
  # Permite desalojar SIEMPRE los pods que no estan Ready, sin consumir
  # presupuesto de interrupcion.
  unhealthyPodEvictionPolicy: AlwaysAllow

# k8s/entornos/pro/pdb-api-reservas.yaml
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: api-reservas
  namespace: rutas-norte-pro
  labels:
    app: api-reservas
    app.kubernetes.io/part-of: rutas-norte
spec:
  # PORCENTAJE, no numero absoluto. api-reservas tiene KEDA/HPA (09-01, 09-04)
  # y oscila entre 4 y 30 replicas a lo largo del dia. Un minAvailable
  # absoluto quedaria obsoleto en cuanto el HPA se moviera, y con el valle
  # nocturno se convertiria en un PDB IMPOSIBLE que bloquearia el
  # mantenimiento y la reduccion de nodos.
  #
  # Con 25 %:
  #    4 replicas -> permite desalojar 1  (suelo(4 x 0,25) = 1)
  #   12 replicas -> permite desalojar 3
  #   30 replicas -> permite desalojar 7
  # La PROPORCION de servicio protegida es constante: siempre el 75 %.
  maxUnavailable: 25%

  selector:
    matchLabels:
      app: api-reservas

  # Los pods que no pasan la readiness no estan sirviendo trafico: desalojarlos
  # no reduce la disponibilidad y evita el atasco circular de un despliegue
  # defectuoso que impide su propia reparacion.
  unhealthyPodEvictionPolicy: AlwaysAllow

# k8s/entornos/pro/pdb-tienda-web.yaml
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: tienda-web
  namespace: rutas-norte-pro
  labels:
    app: tienda-web
    app.kubernetes.io/part-of: rutas-norte
spec:
  # 34 %, mas permisivo que api-reservas. Razon: tienda-web es nginx sirviendo
  # estatico. Arranca en ~1 segundo y no tiene estado ni cache que calentar,
  # asi que una replica desalojada vuelve casi al instante en otro nodo.
  # Permitir mas desalojos simultaneos acelera el mantenimiento sin riesgo real.
  #
  # Con 3 replicas -> permite desalojar 1  (suelo(3 x 0,34) = 1)
  # Con 15 replicas -> permite desalojar 5
  maxUnavailable: 34%

  selector:
    matchLabels:
      app: tienda-web

  unhealthyPodEvictionPolicy: AlwaysAllow

# k8s/entornos/pro/pdb-worker-notificaciones.yaml
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: worker-notificaciones
  namespace: rutas-norte-pro
  labels:
    app: worker-notificaciones
    app.kubernetes.io/part-of: rutas-norte
spec:
  # 50 %, el mas permisivo de la plataforma. Justificacion:
  #
  # 1. NADIE ESPERA. Un correo de confirmacion enviado 30 segundos mas tarde
  #    no tiene consecuencia alguna para el usuario.
  # 2. LA COLA ES EL AMORTIGUADOR. Si se desaloja la mitad de los workers, el
  #    trabajo no se pierde: se acumula en la cola y se procesa despues.
  #    El mensaje en vuelo se reentrega automaticamente.
  # 3. KEDA REACCIONA. Si la cola crece porque hay menos workers, KEDA (09-04)
  #    escalara para compensar.
  #
  # Con escalado a CERO (minReplicaCount: 0) hay un matiz: cuando hay 0
  # replicas, el PDB no cubre ningun pod y ALLOWED DISRUPTIONS sera 0, pero
  # eso es irrelevante porque no hay nada que desalojar.
  maxUnavailable: 50%

  selector:
    matchLabels:
      app: worker-notificaciones

  unhealthyPodEvictionPolicy: AlwaysAllow

# k8s/entornos/pro/pdb-redis-cache.yaml
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: redis-cache
  namespace: rutas-norte-pro
  labels:
    app: redis-cache
    app.kubernetes.io/part-of: rutas-norte
  annotations:
    # Anotacion para excluir este PDB de la alerta de "PDB imposible":
    # su ALLOWED DISRUPTIONS es 0 de forma DELIBERADA.
    rutasnorte.example/pdb-bloqueo-intencionado: >
      redis-cache es un StatefulSet de una replica. Desalojarlo vacia la cache
      y descarga toda la carga de consultas de disponibilidad sobre
      postgres-reservas. Requiere intervencion manual y ventana de mantenimiento.
spec:
  # minAvailable: 1 con UNA replica = CERO desalojos permitidos.
  # Es DELIBERADO. Consecuencias asumidas:
  #   - El Cluster Autoscaler no retirara el nodo que aloje a redis-cache.
  #   - kubectl drain sobre ese nodo se quedara esperando.
  #   - El mantenimiento de ese nodo requiere decision humana explicita.
  #
  # Es un compromiso ACEPTADO: preferimos que el mantenimiento sea manual a
  # que un mecanismo automatico vacie la cache en el peor momento posible.
  minAvailable: 1

  selector:
    matchLabels:
      app: redis-cache

  # IfHealthyBudget (el defecto). No ponemos AlwaysAllow: si redis-cache no
  # esta Ready, puede estar cargando datos o recuperandose. Desalojarlo
  # empeoraria las cosas.
  unhealthyPodEvictionPolicy: IfHealthyBudget

# k8s/entornos/pro/pdb-postgres-reservas.yaml
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: postgres-reservas
  namespace: rutas-norte-pro
  labels:
    app: postgres-reservas
    app.kubernetes.io/part-of: rutas-norte
  annotations:
    rutasnorte.example/pdb-bloqueo-intencionado: >
      postgres-reservas es la base de datos primaria de la plataforma con una
      unica replica. NINGUN mecanismo automatico debe moverla. El mantenimiento
      del nodo que la aloje requiere una ventana planificada, con parada
      controlada de la aplicacion y copia de seguridad previa. Ver 05-06.
      La solucion definitiva es un operador de PostgreSQL: ver 06-07.
spec:
  # CERO desalojos. Es la proteccion mas fuerte posible, y es intencionada.
  #
  # Un desalojo automatico de postgres-reservas significaria:
  #   - Corte de TODAS las conexiones de api-reservas.
  #   - Perdida de la cache de paginas de PostgreSQL (minutos de latencia mala).
  #   - Riesgo de inconsistencia si hay transacciones en vuelo.
  #   - La plataforma entera caida durante el arranque.
  #
  # Guarda datos personales de clientes: cualquier riesgo es inaceptable.
  minAvailable: 1

  selector:
    matchLabels:
      app: postgres-reservas

  unhealthyPodEvictionPolicy: IfHealthyBudget

nodo-1 (zona A):  api-reservas x4, tienda-web x2
nodo-2 (zona A):  postgres-reservas
nodo-3 (zona B):  redis-cache, worker x2
nodo-4 (zona B):  (casi vacio)

Se cae nodo-1  ->  CERO replicas de api-reservas. Plataforma caida.
Se cae la zona A -> CERO replicas de api-reservas Y la base de datos.

spec:
  template:
    spec:
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: topology.kubernetes.io/zone
          whenUnsatisfiable: DoNotSchedule
          labelSelector:
            matchLabels:
              app: api-reservas
          minDomains: 3
          nodeAffinityPolicy: Honor
          nodeTaintsPolicy: Honor
          matchLabelKeys:
            - pod-template-hash

sesgo = (pods en el dominio con MAS) - (pods en el dominio con MENOS)

Sin minDomains, con 3 replicas y solo 1 zona con nodos disponibles:
  Zona A: 3 pods. Zona B: no hay nodos. Zona C: no hay nodos.
  Dominios EXISTENTES: 1
  Sesgo: 3 - 3 = 0  ->  la restriccion SE CUMPLE.
  Resultado: las 3 replicas en la misma zona. NO es lo que querias.

Con minDomains: 3:
  El planificador considera que hay 3 dominios, dos de ellos con 0 pods.
  Sesgo: 3 - 0 = 3 > maxSkew 1  ->  NO se cumple.
  Con DoNotSchedule: los pods quedan Pending hasta que haya nodos en otras zonas.

Actualizacion de api-reservas de v1.14 a v1.15. 6 replicas.

Estado intermedio:
  zona A: 2 pods v1.14 + 1 pod v1.15 = 3 pods
  zona B: 2 pods v1.14 = 2 pods
  zona C: 1 pod v1.14 = 1 pod

Sesgo calculado sobre TODOS: 3 - 1 = 2 > maxSkew 1
-> El planificador NO puede colocar mas pods v1.15 en la zona A.
-> La actualizacion se atasca o se distribuye mal.

Con matchLabelKeys: ["pod-template-hash"]:
  Para colocar un pod v1.15, solo cuenta los pods v1.15:
    zona A: 1, zona B: 0, zona C: 0
  Sesgo: 1 - 0 = 1 <= maxSkew 1  ->  se puede colocar en B o C.

La nueva version se distribuye correctamente por su cuenta.

Colocacion de la replica 1:
  A: 0, B: 0, C: 0. Cualquier zona vale. -> A
  Estado: A:1, B:0, C:0

Colocacion de la replica 2:
  Si va a A: A:2, B:0, C:0. Sesgo = 2-0 = 2 > 1. NO PERMITIDO.
  Si va a B: A:1, B:1, C:0. Sesgo = 1-0 = 1 <= 1. PERMITIDO.
  -> B (o C)
  Estado: A:1, B:1, C:0

Colocacion de la replica 3:
  Solo C mantiene el sesgo en 1 o menos.  -> C
  Estado: A:1, B:1, C:1  (sesgo 0)

Replicas 4, 5, 6: se reparten una por zona.
  Estado: A:2, B:2, C:2  (sesgo 0)

Colocacion de la replica 7:
  Cualquier zona: sesgo pasaria a 1. Permitido en las tres.
  -> A (arbitrario)
  Estado FINAL: A:3, B:2, C:2  (sesgo 1)

Se cae la zona A: quedan 4 de 7 replicas (57 %).
Se cae la zona B: quedan 5 de 7 replicas (71 %).

Sin topologySpreadConstraints, en el peor caso las 7 podrian estar en una zona:
Se cae esa zona: quedan 0 de 7 (0 %). Plataforma caida.

affinity:
  podAntiAffinity:
    # Version DURA: no se puede violar
    requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchLabels:
            app: api-reservas
        topologyKey: kubernetes.io/hostname

Regla: como mucho 1 replica de api-reservas por nodo.
Nodos: 9.
Replicas maximas colocables: 9.

El HPA pide 30 replicas.
Se colocan 9. Las otras 21 quedan en Pending PARA SIEMPRE.

El Cluster Autoscaler ve pods pendientes y arranca nodos... y con cada nodo
nuevo cabe UNA replica mas. Para 30 replicas harian falta 30 NODOS.
Coste: absurdo.

Regla: maxSkew 1 entre nodos.
Nodos: 9. Replicas: 30.

Reparto: 30 / 9 = 3,33
Resultado: 3 nodos con 4 replicas, 6 nodos con 3 replicas.
Sesgo: 4 - 3 = 1. Cumple.

Las 30 replicas se colocan. Ningun Pending.

# api-reservas NO debe compartir nodo con el CronJob de informes, que consume
# 4 nucleos de golpe y estrangularia a la API durante 40 minutos.
affinity:
  podAntiAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchLabels:
            app: informes-ocupacion       # OTRA aplicacion, no la misma
        topologyKey: kubernetes.io/hostname

spec:
  template:
    spec:
      # 1. Reparto equilibrado entre zonas y nodos (disponibilidad)
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: topology.kubernetes.io/zone
          whenUnsatisfiable: DoNotSchedule
          labelSelector:
            matchLabels:
              app: api-reservas
          matchLabelKeys: ["pod-template-hash"]
        - maxSkew: 2
          topologyKey: kubernetes.io/hostname
          whenUnsatisfiable: ScheduleAnyway
          labelSelector:
            matchLabels:
              app: api-reservas
          matchLabelKeys: ["pod-template-hash"]

      # 2. Antiafinidad con OTRA aplicacion (aislamiento de recursos)
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                matchLabels:
                  app: informes-ocupacion
              topologyKey: kubernetes.io/hostname

# k8s/base/deployment-api-reservas.yaml (fragmento)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-reservas
  namespace: rutas-norte-pro
spec:
  # Sin replicas: lo gobierna KEDA/HPA (09-01, 09-04)
  selector:
    matchLabels:
      app: api-reservas
  template:
    metadata:
      labels:
        app: api-reservas
        app.kubernetes.io/part-of: rutas-norte
    spec:
      topologySpreadConstraints:
        # NIVEL 1: entre ZONAS DE DISPONIBILIDAD. Restriccion DURA.
        #
        # Este es el dominio de fallo grande: si se cae una zona entera, hay
        # que garantizar que sobrevivan replicas en las otras dos. Es una
        # garantia que NO estamos dispuestos a negociar, asi que DoNotSchedule:
        # preferimos un pod Pending a un reparto desequilibrado.
        - maxSkew: 1
          topologyKey: topology.kubernetes.io/zone
          whenUnsatisfiable: DoNotSchedule
          labelSelector:
            matchLabels:
              app: api-reservas
          # 3 zonas siempre, aunque una no tenga nodos ahora mismo. Sin esto,
          # si el Cluster Autoscaler solo tiene nodos en 2 zonas, el reparto
          # "equilibrado" entre esas 2 cumpliria la restriccion y perderiamos
          # la garantia de las 3 zonas.
          minDomains: 3
          matchLabelKeys: ["pod-template-hash"]

        # NIVEL 2: entre NODOS. Restriccion BLANDA.
        #
        # Repartir entre nodos es deseable pero NO al precio de dejar pods
        # Pending. Durante el puente de mayo, con 30 replicas y el Cluster
        # Autoscaler arrancando nodos, un DoNotSchedule aqui bloquearia el
        # escalado justo cuando mas falta hace.
        #
        # maxSkew 2 (no 1): con 30 replicas y 9 nodos, exigir maxSkew 1 seria
        # innecesariamente rigido. Un 4-3-3-4-3-3-4-3-3 es perfectamente sano.
        - maxSkew: 2
          topologyKey: kubernetes.io/hostname
          whenUnsatisfiable: ScheduleAnyway
          labelSelector:
            matchLabels:
              app: api-reservas
          matchLabelKeys: ["pod-template-hash"]

      containers:
        - name: api
          image: registry.rutasnorte.example/api-reservas:1.14.2
          resources:
            requests: {cpu: 412m, memory: 800Mi}
            limits: {cpu: "1", memory: 1600Mi}

3 zonas, maxSkew 1, minDomains 3.

Reparto: 4 / 3 = 1,33
Resultado: A:2, B:1, C:1. Sesgo = 2-1 = 1. Cumple.

Caida de la zona A: quedan 2 de 4 (50 %).
Caida de la zona B o C: quedan 3 de 4 (75 %).

Con maxUnavailable: 25% en el PDB, 4 replicas permiten 1 desalojo.
La caida de una zona (2 replicas) es INVOLUNTARIA: el PDB no aplica.
Sobreviven 2 replicas -> el servicio sigue, degradado.
KEDA/HPA detectara la carga por replica duplicada y escalara.

Nivel ZONA (maxSkew 1, DoNotSchedule):
  30 / 3 = 10 exactas.
  Resultado: A:10, B:10, C:10. Sesgo 0. Perfecto.

Nivel NODO (maxSkew 2, ScheduleAnyway), con 9 nodos (3 por zona):
  Dentro de cada zona, 10 replicas entre 3 nodos: 4-3-3.
  Sesgo global entre nodos: 4 - 3 = 1 <= 2. Cumple.

  Reparto final:
    zona A: nodo-a1:4, nodo-a2:3, nodo-a3:3
    zona B: nodo-b1:4, nodo-b2:3, nodo-b3:3
    zona C: nodo-c1:4, nodo-c2:3, nodo-c3:3

Caida de un NODO: se pierden 3 o 4 replicas de 30 (10-13 %). Imperceptible.
Caida de una ZONA: se pierden 10 de 30 (33 %). El servicio aguanta con 20.

      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: topology.kubernetes.io/zone
          whenUnsatisfiable: DoNotSchedule
          labelSelector:
            matchLabels:
              app: tienda-web
          minDomains: 3
          matchLabelKeys: ["pod-template-hash"]
        - maxSkew: 1
          topologyKey: kubernetes.io/hostname
          # maxSkew 1 y ScheduleAnyway: con solo 3-15 replicas, un reparto
          # de 1 por nodo es alcanzable y deseable. Pero seguimos sin
          # bloquear el escalado.
          whenUnsatisfiable: ScheduleAnyway
          labelSelector:
            matchLabels:
              app: tienda-web
          matchLabelKeys: ["pod-template-hash"]

# k8s/base/statefulset-postgres-reservas.yaml (fragmento)
spec:
  template:
    spec:
      # Vive en el grupo de nodos de datos (09-03), con su taint y su afinidad.
      tolerations:
        - key: rol
          operator: Equal
          value: datos
          effect: NoSchedule
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
              - matchExpressions:
                  - key: rol
                    operator: In
                    values: ["datos"]
        # NO compartir nodo con redis-cache: si se cae ese nodo, no queremos
        # perder la base de datos Y la cache a la vez, porque el arranque de
        # la base de datos con la cache vacia es el peor escenario posible.
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                matchLabels:
                  app: redis-cache
              topologyKey: kubernetes.io/hostname

Cluster de 3 miembros de etcd. Se caen 2.
Quorum necesario: 2. Miembros vivos: 1. NO HAY QUORUM.

Consecuencias:
  - etcd pasa a SOLO LECTURA. No acepta escrituras.
  - El servidor de API no puede persistir cambios.
  - kubectl apply falla. No se pueden crear, modificar ni borrar objetos.
  - El HPA no puede cambiar replicas.
  - El Cluster Autoscaler no puede hacer nada.

PERO, y esto es lo importante:
  - Los pods que YA estaban corriendo SIGUEN CORRIENDO.
  - Los kubelets siguen ejecutando sus contenedores.
  - Los Services siguen enrutando (kube-proxy tiene su estado local).
  - LA PLATAFORMA SIGUE ATENDIENDO TRAFICO.

3 nodos de plano de control, uno por zona de disponibilidad:
  zona A: control-1 (etcd, api-server, scheduler, controller-manager)
  zona B: control-2
  zona C: control-3

Caida de una zona: quedan 2 de 3. Quorum = 2. SE MANTIENE.

# k8s/entornos/pro/deployment-ingress-nginx.yaml (fragmento)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: ingress-nginx-controller
  namespace: ingress-nginx
spec:
  replicas: 4              # Nunca 1. Nunca 2 en el mismo dominio de fallo.
  template:
    spec:
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: topology.kubernetes.io/zone
          whenUnsatisfiable: DoNotSchedule
          labelSelector:
            matchLabels:
              app.kubernetes.io/name: ingress-nginx
          minDomains: 3
        - maxSkew: 1
          topologyKey: kubernetes.io/hostname
          whenUnsatisfiable: DoNotSchedule    # Aqui SI es duro
          labelSelector:
            matchLabels:
              app.kubernetes.io/name: ingress-nginx
---
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: ingress-nginx
  namespace: ingress-nginx
spec:
  minAvailable: 2          # Numero absoluto: las replicas del Ingress son FIJAS
  selector:
    matchLabels:
      app.kubernetes.io/name: ingress-nginx
  unhealthyPodEvictionPolicy: AlwaysAllow

# Fragmento del Deployment de CoreDNS en kube-system
spec:
  replicas: 3
  template:
    spec:
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: topology.kubernetes.io/zone
          whenUnsatisfiable: ScheduleAnyway
          labelSelector:
            matchLabels:
              k8s-app: kube-dns
      priorityClassName: system-cluster-critical

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: coredns
  namespace: kube-system
spec:
  maxUnavailable: 1
  selector:
    matchLabels:
      k8s-app: kube-dns
  unhealthyPodEvictionPolicy: AlwaysAllow

# Ejemplo con CloudNativePG
apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: postgres-reservas
  namespace: rutas-norte-pro
spec:
  instances: 3                    # 1 primaria + 2 replicas
  primaryUpdateStrategy: unsupervised

  storage:
    size: 100Gi
    storageClass: rutasnorte-rapida    # De 05-04

  # El operador reparte las instancias entre zonas automaticamente
  affinity:
    enablePodAntiAffinity: true
    topologyKey: topology.kubernetes.io/zone
    podAntiAffinityType: required

  postgresql:
    parameters:
      max_connections: "200"
      shared_buffers: "1GB"

  monitoring:
    enablePodMonitor: true         # Se integra con Prometheus (07-03)

# ¿Todos los PDB permiten al menos un desalojo?
kubectl get pdb --all-namespaces

NAMESPACE          NAME                    MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS
rutas-norte-pro    api-reservas            N/A             25%               1
rutas-norte-pro    tienda-web              N/A             34%               1
rutas-norte-pro    postgres-reservas       1               N/A               0     <- ATENCION
rutas-norte-pro    redis-cache             1               N/A               0     <- ATENCION
rutas-norte-pro    worker-notificaciones   N/A             50%               1
ingress-nginx      ingress-nginx           2               N/A               2
kube-system        coredns                 N/A             1                 1

kubectl get pods -n rutas-norte-pro -o wide \
  -l 'app in (postgres-reservas,redis-cache)'

NAME                  READY   STATUS    NODE           ZONA
postgres-reservas-0   2/2     Running   nodo-datos-1   eu-west-1a
redis-cache-0         1/1     Running   nodo-datos-2   eu-west-1b

# ¿Qué hay en el nodo que vamos a drenar?
kubectl get pods --all-namespaces -o wide --field-selector spec.nodeName=nodo-a2

NAMESPACE         NAME                            READY   STATUS    AGE
rutas-norte-pro   api-reservas-7c9d4f8b6d-2mkjp   2/2     Running   4h
rutas-norte-pro   api-reservas-7c9d4f8b6d-9nvtr   2/2     Running   4h
rutas-norte-pro   tienda-web-6f7d9c4b58-4kjnx     1/1     Running   2d
kube-system       fluentd-x7kqp                   1/1     Running   12d   <- DaemonSet
kube-system       falco-2wxkp                     1/1     Running   12d   <- DaemonSet
kube-system       kube-proxy-mn2vp                1/1     Running   12d   <- DaemonSet

# ¿Hay alguna alerta activa? No se hace mantenimiento con incidentes abiertos.
kubectl get events --all-namespaces --field-selector type=Warning \
  --sort-by=.lastTimestamp | tail -20

kubectl cordon nodo-a2

node/nodo-a2 cordoned

kubectl get nodes

NAME      STATUS                     ROLES    AGE   VERSION
nodo-a1   Ready                      <none>   12d   v1.30.2
nodo-a2   Ready,SchedulingDisabled   <none>   12d   v1.30.2
nodo-a3   Ready                      <none>   12d   v1.30.2

kubectl drain nodo-a2 \
  --ignore-daemonsets \
  --delete-emptydir-data \
  --grace-period=60 \
  --timeout=300s

node/nodo-a2 already cordoned
Warning: ignoring DaemonSet-managed Pods: kube-system/fluentd-x7kqp,
         kube-system/falco-2wxkp, kube-system/kube-proxy-mn2vp
evicting pod rutas-norte-pro/api-reservas-7c9d4f8b6d-2mkjp
evicting pod rutas-norte-pro/tienda-web-6f7d9c4b58-4kjnx
evicting pod rutas-norte-pro/api-reservas-7c9d4f8b6d-9nvtr
error when evicting pods/"api-reservas-7c9d4f8b6d-9nvtr" -n "rutas-norte-pro"
(will retry after 5s): Cannot evict pod as it would violate the pod's disruption budget.
pod/tienda-web-6f7d9c4b58-4kjnx evicted
pod/api-reservas-7c9d4f8b6d-2mkjp evicted
evicting pod rutas-norte-pro/api-reservas-7c9d4f8b6d-9nvtr
pod/api-reservas-7c9d4f8b6d-9nvtr evicted
node/nodo-a2 drained

# El nodo debe estar vacio de pods de aplicacion
kubectl get pods --all-namespaces -o wide --field-selector spec.nodeName=nodo-a2

NAMESPACE     NAME                READY   STATUS    AGE
kube-system   fluentd-x7kqp       1/1     Running   12d
kube-system   falco-2wxkp         1/1     Running   12d
kube-system   kube-proxy-mn2vp    1/1     Running   12d

# Y el SERVICIO debe estar sano: esto es lo que de verdad importa
kubectl get pods -n rutas-norte-pro -l app=api-reservas
kubectl get pdb -n rutas-norte-pro

# Ejemplo: actualizar el kubelet en un cluster con kubeadm (10-02)
ssh nodo-a2

sudo apt-get update
sudo apt-get install -y kubeadm=1.30.3-1.1
sudo kubeadm upgrade node
sudo apt-get install -y kubelet=1.30.3-1.1 kubectl=1.30.3-1.1
sudo systemctl daemon-reload
sudo systemctl restart kubelet

exit

kubectl get node nodo-a2

NAME      STATUS                     ROLES    AGE   VERSION
nodo-a2   Ready,SchedulingDisabled   <none>   12d   v1.30.3

# Comprobar que no hay condiciones de error
kubectl describe node nodo-a2 | grep -A10 Conditions

kubectl uncordon nodo-a2

node/nodo-a2 uncordoned

NAME      STATUS   ROLES    AGE   VERSION
nodo-a2   Ready    <none>   12d   v1.30.3

# Verificar la distribucion antes de continuar
kubectl get pods -n rutas-norte-pro -l app=api-reservas -o wide \
  | awk '{print $7}' | sort | uniq -c

      2 nodo-a1
      1 nodo-a3
      2 nodo-b1
      1 nodo-b2

kubectl drain nodo-a2 --ignore-daemonsets --delete-emptydir-data

node/nodo-a2 cordoned
evicting pod rutas-norte-pro/api-reservas-7c9d4f8b6d-2mkjp
evicting pod rutas-norte-pro/api-reservas-7c9d4f8b6d-9nvtr
evicting pod rutas-norte-pro/tienda-web-6f7d9c4b58-4kjnx
pod/api-reservas-7c9d4f8b6d-2mkjp evicted
pod/api-reservas-7c9d4f8b6d-9nvtr evicted
pod/tienda-web-6f7d9c4b58-4kjnx evicted
node/nodo-a2 drained

api-reservas tenia 4 replicas: 2 en nodo-a2, 1 en nodo-a1, 1 en nodo-b1.
Tras el drenaje: 2 replicas vivas, 2 arrancando (25-30 segundos).

Durante 30 segundos: LA MITAD de la capacidad de la API.
Cada replica viva recibe el DOBLE de carga.
Latencia p95: de 180 ms a 900 ms.
Algunas peticiones: timeout.

Y si hubieran sido 3 de las 4 replicas en ese nodo: 25 % de capacidad.
La replica superviviente se satura y cae. CAIDA TOTAL.

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: relleno-capacidad
  namespace: rutas-norte-pro
spec:
  # 100 % de indisponibilidad permitida: estos pods estan PARA ser desalojados.
  # Documenta la intencion mejor que la ausencia de PDB.
  maxUnavailable: 100%
  selector:
    matchLabels:
      app: relleno-capacidad

# En el Deployment: gobierna la ACTUALIZACION
spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 25%     # Coherente con el PDB
      maxSurge: 25%
---
# En el PDB: gobierna los DESALOJOS (drain, CA, VPA)
spec:
  maxUnavailable: 25%

minikube start -p rutas-norte --nodes=4 --cpus=2 --memory=4096

# Etiquetar los nodos con zonas ficticias
kubectl label node rutas-norte     topology.kubernetes.io/zone=zona-a
kubectl label node rutas-norte-m02 topology.kubernetes.io/zone=zona-a
kubectl label node rutas-norte-m03 topology.kubernetes.io/zone=zona-b
kubectl label node rutas-norte-m04 topology.kubernetes.io/zone=zona-b

# /tmp/caos-demo.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: caos-api
  namespace: rutas-norte-dev
spec:
  replicas: 6
  selector:
    matchLabels:
      app: caos-api
  template:
    metadata:
      labels:
        app: caos-api
    spec:
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: topology.kubernetes.io/zone
          whenUnsatisfiable: DoNotSchedule
          labelSelector:
            matchLabels:
              app: caos-api
          matchLabelKeys: ["pod-template-hash"]
        - maxSkew: 1
          topologyKey: kubernetes.io/hostname
          whenUnsatisfiable: ScheduleAnyway
          labelSelector:
            matchLabels:
              app: caos-api
          matchLabelKeys: ["pod-template-hash"]
      containers:
        - name: web
          image: nginx:1.27-alpine
          resources:
            requests: {cpu: 50m, memory: 32Mi}
          readinessProbe:
            httpGet: {path: /, port: 80}
            initialDelaySeconds: 2
            periodSeconds: 3
---
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: caos-api
  namespace: rutas-norte-dev
spec:
  maxUnavailable: 25%
  selector:
    matchLabels:
      app: caos-api
  unhealthyPodEvictionPolicy: AlwaysAllow
---
apiVersion: v1
kind: Service
metadata:
  name: caos-api
  namespace: rutas-norte-dev
spec:
  selector:
    app: caos-api
  ports:
    - port: 80

kubectl apply -f /tmp/caos-demo.yaml
kubectl get pods -n rutas-norte-dev -o wide

NAME                        READY   STATUS    NODE              ZONA
caos-api-7d9c5f8b6b-2mkjp   1/1     Running   rutas-norte       zona-a
caos-api-7d9c5f8b6b-4nqzx   1/1     Running   rutas-norte-m02   zona-a
caos-api-7d9c5f8b6b-7wtrv   1/1     Running   rutas-norte-m02   zona-a
caos-api-7d9c5f8b6b-9hbcx   1/1     Running   rutas-norte-m03   zona-b
caos-api-7d9c5f8b6b-kp3ln   1/1     Running   rutas-norte-m04   zona-b
caos-api-7d9c5f8b6b-tv6ws   1/1     Running   rutas-norte-m03   zona-b

# Terminal 1: generar trafico continuo y contar errores
kubectl -n rutas-norte-dev run cliente --rm -it --restart=Never \
  --image=busybox:1.36 -- /bin/sh -c \
  'ok=0; err=0; while true; do
     if wget -q -T2 -O- http://caos-api > /dev/null 2>&1; then
       ok=$((ok+1)); else err=$((err+1)); fi;
     echo "OK=$ok ERR=$err";
     sleep 0.2;
   done'

# Terminal 2: el drenaje
kubectl drain rutas-norte-m02 --ignore-daemonsets --delete-emptydir-data

OK=847 ERR=0
OK=848 ERR=0
OK=849 ERR=0
...
OK=1204 ERR=0

# Restaurar
kubectl uncordon rutas-norte-m02

# Simular un fallo de hardware: apagar el nodo bruscamente
minikube -p rutas-norte node stop rutas-norte-m03

kubectl get nodes --watch

NAME              STATUS     ROLES    AGE
rutas-norte-m03   Ready      <none>   1h
rutas-norte-m03   NotReady   <none>   1h     <- a los ~40 segundos

kubectl get pods -n rutas-norte-dev -o wide --watch

NAME                        READY   STATUS        NODE
caos-api-7d9c5f8b6b-9hbcx   1/1     Running       rutas-norte-m03
caos-api-7d9c5f8b6b-tv6ws   1/1     Running       rutas-norte-m03
...
(pasan ~5 minutos)
...
caos-api-7d9c5f8b6b-9hbcx   1/1     Terminating   rutas-norte-m03
caos-api-7d9c5f8b6b-tv6ws   1/1     Terminating   rutas-norte-m03
caos-api-7d9c5f8b6b-x2klm   0/1     Pending       <none>
caos-api-7d9c5f8b6b-p9wnz   0/1     Pending       <none>
caos-api-7d9c5f8b6b-x2klm   0/1     ContainerCreating   rutas-norte-m04
caos-api-7d9c5f8b6b-p9wnz   1/1     Running             rutas-norte-m04

OK=1204 ERR=0
OK=1210 ERR=3      <- empiezan los errores
OK=1218 ERR=11
...
OK=1301 ERR=68     <- ~40 segundos de errores
OK=1409 ERR=68     <- se detienen: el Service ya excluyo el nodo muerto
OK=1520 ERR=68

minikube -p rutas-norte node start rutas-norte-m03
kubectl delete -f /tmp/caos-demo.yaml

# PDB sin desalojos permitidos, excluyendo los intencionados
kube_poddisruptionbudget_status_pod_disruptions_allowed == 0
  unless on(namespace, poddisruptionbudget)
  kube_poddisruptionbudget_annotations{annotation_rutasnorte_example_pdb_bloqueo_intencionado!=""}

# Replicas por zona
kubectl get pods -n rutas-norte-pro -l app=api-reservas \
  -o custom-columns=NODO:.spec.nodeName --no-headers | \
  while read n; do kubectl get node "$n" -o jsonpath='{.metadata.labels.topology\.kubernetes\.io/zone}{"\n"}'; done | \
  sort | uniq -c

      3 eu-west-1a
      3 eu-west-1b
      2 eu-west-1c

kubectl drain nodo-b1 --ignore-daemonsets --delete-emptydir-data

node/nodo-b1 already cordoned
Warning: ignoring DaemonSet-managed Pods: kube-system/fluentd-2wxkp, kube-system/falco-x7kqp
evicting pod monitorizacion/prometheus-server-0
evicting pod rutas-norte-pro/api-reservas-7c9d4f8b6d-mn2vp
evicting pod rutas-norte-pro/worker-notificaciones-5f8d9c-4kjnx
pod/worker-notificaciones-5f8d9c-4kjnx evicted
error when evicting pods/"prometheus-server-0" -n "monitorizacion"
(will retry after 5s): Cannot evict pod as it would violate the pod's disruption budget.
error when evicting pods/"api-reservas-7c9d4f8b6d-mn2vp" -n "rutas-norte-pro"
(will retry after 5s): Cannot evict pod as it would violate the pod's disruption budget.

NAMESPACE          NAME                    MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS
rutas-norte-pro    api-reservas            8               N/A               0
rutas-norte-pro    tienda-web              N/A             34%               1
rutas-norte-pro    worker-notificaciones   N/A             50%               1
monitorizacion     prometheus              1               N/A               0

NAMESPACE          NAME                            READY   STATUS    NODE
rutas-norte-pro    api-reservas-7c9d4f8b6d-2mkjp   2/2     Running   nodo-a1
rutas-norte-pro    api-reservas-7c9d4f8b6d-9nvtr   2/2     Running   nodo-a2
rutas-norte-pro    api-reservas-7c9d4f8b6d-mn2vp   2/2     Running   nodo-b1
rutas-norte-pro    api-reservas-7c9d4f8b6d-tv6ws   2/2     Running   nodo-b2
rutas-norte-pro    api-reservas-7c9d4f8b6d-x2klm   1/2     Running   nodo-a1
monitorizacion     prometheus-server-0             1/1     Running   nodo-b1

topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: topology.kubernetes.io/zone
    whenUnsatisfiable: DoNotSchedule
    minDomains: 3
    labelSelector:
      matchLabels:
        app: api-reservas
  - maxSkew: 2
    topologyKey: kubernetes.io/hostname
    whenUnsatisfiable: ScheduleAnyway
    labelSelector:
      matchLabels:
        app: api-reservas

# PDB
spec:
  maxUnavailable: 25%

Replicas totales de api-reservas: 5
  - 4 con READY 2/2 (sanas)
  - 1 con READY 1/2 (el pod x2klm: un contenedor no esta listo)

Replicas DISPONIBLES (Ready): 4
PDB exige: minAvailable: 8

4 < 8  ->  YA estamos por debajo del minimo.
ALLOWED DISRUPTIONS: 0. Y seguira siendo 0 pase lo que pase.

kubectl describe pod api-reservas-7c9d4f8b6d-x2klm -n rutas-norte-pro
kubectl logs api-reservas-7c9d4f8b6d-x2klm -n rutas-norte-pro -c exportador-metricas

kubectl patch pdb api-reservas -n rutas-norte-pro --type merge \
  -p '{"spec":{"minAvailable":null,"maxUnavailable":"25%"}}'

Replicas deseadas: 5
maxUnavailable: 25% -> suelo(5 x 0,25) = 1
Minimo disponible: 5 - 1 = 4
Disponibles actuales: 4
ALLOWED DISRUPTIONS: 0

...Sigue siendo 0, por culpa del pod x2klm que no esta Ready.

# Via A: si el pod esta roto sin remedio, borrarlo para que se recree
kubectl delete pod api-reservas-7c9d4f8b6d-x2klm -n rutas-norte-pro
# (kubectl delete NO respeta PDB: aqui nos viene bien)

# Via B: anadir unhealthyPodEvictionPolicy para que los pods no sanos
# no consuman presupuesto
kubectl patch pdb api-reservas -n rutas-norte-pro --type merge \
  -p '{"spec":{"unhealthyPodEvictionPolicy":"AlwaysAllow"}}'

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: api-reservas
  namespace: rutas-norte-pro
  annotations:
    rutasnorte.example/nota: >
      PORCENTAJE obligatorio: api-reservas tiene KEDA/HPA y oscila entre
      4 y 30 replicas. Un minAvailable absoluto se vuelve imposible en el
      valle y bloquea todo el mantenimiento. Ver 09-05.
spec:
  maxUnavailable: 25%
  selector:
    matchLabels:
      app: api-reservas
  unhealthyPodEvictionPolicy: AlwaysAllow

prometheus-server-0: 1 replica (es un StatefulSet).
PDB: minAvailable: 1.
Desalojarla dejaria 0 disponibles.
ALLOWED DISRUPTIONS: 0. Permanente y por diseno.

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: prometheus
  namespace: monitorizacion
spec:
  # Una sola replica: permitimos el desalojo. Perdemos unos minutos de
  # metricas durante el mantenimiento, lo cual es aceptable: Prometheus
  # no esta en el camino critico de la venta.
  maxUnavailable: 1
  selector:
    matchLabels:
      app: prometheus

# 1. Corregir el PDB de api-reservas
kubectl patch pdb api-reservas -n rutas-norte-pro --type merge \
  -p '{"spec":{"minAvailable":null,"maxUnavailable":"25%","unhealthyPodEvictionPolicy":"AlwaysAllow"}}'

# 2. Corregir el PDB de prometheus
kubectl patch pdb prometheus -n monitorizacion --type merge \
  -p '{"spec":{"minAvailable":null,"maxUnavailable":1}}'

# 3. Verificar
kubectl get pdb --all-namespaces

NAMESPACE          NAME                    MAX UNAVAILABLE   ALLOWED DISRUPTIONS
rutas-norte-pro    api-reservas            25%               1
monitorizacion     prometheus              1                 1

# 4. Investigar el pod x2klm (no urgente, pero no lo olvides)
kubectl describe pod api-reservas-7c9d4f8b6d-x2klm -n rutas-norte-pro

kubectl get pdb --all-namespaces \
  -o custom-columns='NS:.metadata.namespace,NOMBRE:.metadata.name,PERMITIDOS:.status.disruptionsAllowed' \
  | awk 'NR==1 || $3=="0"'

kube_poddisruptionbudget_status_pod_disruptions_allowed == 0

11 / 3 = 3,67

Reparto mas equilibrado posible:
  eu-west-1a: 4
  eu-west-1b: 4
  eu-west-1c: 3

Sesgo = 4 - 3 = 1 <= maxSkew 1. CUMPLE.

Zona a (4 replicas, 3 nodos): 2-1-1
Zona b (4 replicas, 3 nodos): 2-1-1
Zona c (3 replicas, 3 nodos): 1-1-1

Sesgo global entre nodos: max 2 - min 1 = 1 <= maxSkew 2. CUMPLE.

Peor caso: cae un nodo con 2 replicas.
Perdidas: 2 de 11.
Quedan: 9 de 11 = 81,8 % de capacidad.

Peor caso: cae una zona con 4 replicas.
Perdidas: 4 de 11.
Quedan: 7 de 11 = 63,6 % de capacidad.

maxUnavailable: 25% sobre 11 replicas.
suelo(11 x 0,25) = suelo(2,75) = 2

ALLOWED DISRUPTIONS: 2

26 / 3 = 8,67

Reparto:
  eu-west-1a: 9
  eu-west-1b: 9
  eu-west-1c: 8

Sesgo = 9 - 8 = 1 <= maxSkew 1. CUMPLE.

Zona a (9 replicas, 3 nodos): 3-3-3
Zona b (9 replicas, 3 nodos): 3-3-3
Zona c (8 replicas, 3 nodos): 3-3-2

Sesgo global entre nodos: 3 - 2 = 1 <= maxSkew 2. CUMPLE.

Peor caso: cae un nodo con 3 replicas.
Perdidas: 3 de 26.
Quedan: 23 de 26 = 88,5 % de capacidad.

Peor caso: cae una zona con 9 replicas.
Perdidas: 9 de 26.
Quedan: 17 de 26 = 65,4 % de capacidad.

suelo(26 x 0,25) = suelo(6,5) = 6

ALLOWED DISRUPTIONS: 6

Un nodo tiene 3 replicas de api-reservas.
El PDB permite 6 desalojos simultaneos.

3 <= 6  ->  SI, se pueden desalojar las 3 de una vez.

El drenaje NO se serializara por culpa del PDB de api-reservas.
Sera casi instantaneo para este componente.

Con 11 replicas, un nodo tiene 2 replicas y el PDB permite 2 desalojos.
2 <= 2 -> tambien caben de una vez, aunque justo al limite.

Si el nodo tuviera 3 replicas (posible con maxSkew 2), el PDB serializaria:
desaloja 2, espera a que se recreen, desaloja la tercera.

minDomains: 3 significa que el planificador considera 3 dominios,
aunque alguno este vacio.

Colocacion de la replica 1: zona a. Estado: a:1, b:0, c:0.
  Sesgo = 1 - 0 = 1 <= maxSkew 1. Cumple.

Colocacion de la replica 2:
  Si va a la zona a: a:2, b:0, c:0. Sesgo = 2 - 0 = 2 > 1. NO PERMITIDO.
  Si va a la zona b: a:1, b:1, c:0. Sesgo = 1 - 0 = 1 <= 1. PERMITIDO.

Resultado: 1 replica en la zona a, 1 en la zona b, 0 en la c.
La zona c queda vacia, y eso ES CORRECTO: con 2 replicas no se pueden
cubrir 3 zonas.

Escenario: la zona c pierde todos sus nodos (caida completa).
Nodos disponibles: solo en las zonas a y b.

minDomains: 3 hace que el planificador SIGA CONTANDO 3 dominios.

Estado tras la caida: a:1, b:1, c:0 (la zona c no tiene nodos).
Sesgo = 1 - 0 = 1 <= maxSkew 1. CUMPLE. Nada que hacer.

Pero si el HPA quisiera escalar a 4 replicas:
  Colocacion de la replica 3:
    Si va a la zona a: a:2, b:1, c:0. Sesgo = 2 - 0 = 2 > 1. NO PERMITIDO.
    Si va a la zona b: a:1, b:2, c:0. Sesgo = 2 - 0 = 2 > 1. NO PERMITIDO.
    Si va a la zona c: NO HAY NODOS.

  -> La replica 3 se queda en PENDING PARA SIEMPRE.

# PROCEDIMIENTO DE EMERGENCIA: caida de zona
# Relajar la restriccion topologica para permitir escalar en las zonas vivas.
kubectl patch deployment api-reservas -n rutas-norte-pro --type json -p '[
  {"op": "replace", "path": "/spec/template/spec/topologySpreadConstraints/0/whenUnsatisfiable",
   "value": "ScheduleAnyway"}
]'
# REVERTIR cuando la zona vuelva.

El banco permite 50 conexiones simultaneas desde la IP de Rutas Norte.

Si cada replica mantiene un pool de N conexiones:
  Replicas maximas = 50 / N

Con N = 5 conexiones por replica:  10 replicas maximas
Con N = 3 conexiones por replica:  16 replicas maximas
Con N = 2 conexiones por replica:  25 replicas maximas

Cuantas transacciones por segundo sostiene una replica?
  Cada transaccion tarda 2-8 s, media ~5 s.
  Con un pool de N conexiones concurrentes:
    transacciones/s = N / 5

  Con N = 5: 1 transaccion/s por replica
  Con N = 3: 0,6 transacciones/s por replica

Para 300 transacciones/s en el pico:
  Con N = 5: 300 replicas. IMPOSIBLE (excede el limite del banco por 30x).
  Con N = 3: 500 replicas. Peor.

Capacidad TEORICA MAXIMA del sistema:
  50 conexiones concurrentes / 5 segundos por transaccion = 10 transacciones/s

OBJETIVO DEL PICO: 300 transacciones/s

EL SISTEMA NO PUEDE PROCESAR MAS DE 10 TRANSACCIONES POR SEGUNDO.
El limite es el BANCO, no Kubernetes.

1. NEGOCIAR con el banco un limite mayor. 50 conexiones es ridiculo para
   300 transacciones/s. Es la accion mas importante y no es tecnica.

2. Mientras tanto: DESACOPLAR con una cola.
   - api-reservas encola la peticion de cobro y responde al usuario
     "procesando su pago".
   - pasarela-pagos consume de la cola a la velocidad que el banco permite.
   - El usuario recibe la confirmacion por notificacion push o correo.

   Esto convierte una restriccion dura en una latencia aceptable, y encaja
   perfectamente con KEDA (09-04): la cola es la senal de escalado natural.

3. Un POOL COMPARTIDO de conexiones al banco, en lugar de un pool por replica.

# k8s/entornos/pro/deployment-pasarela-pagos.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: pasarela-pagos
  namespace: rutas-norte-pro
  labels:
    app: pasarela-pagos
    app.kubernetes.io/part-of: rutas-norte
spec:
  # SIN campo replicas: lo gobierna el HPA/KEDA.
  selector:
    matchLabels:
      app: pasarela-pagos

  strategy:
    type: RollingUpdate
    rollingUpdate:
      # Coherente con el PDB (ver mas abajo). Nunca perder mas de 1 replica.
      maxUnavailable: 1
      # maxSurge 1, no mas: cada replica nueva abre conexiones al banco y
      # tenemos un limite duro de 50. Un maxSurge alto podria agotarlo
      # durante el despliegue.
      maxSurge: 1

  template:
    metadata:
      labels:
        app: pasarela-pagos
        app.kubernetes.io/part-of: rutas-norte
    spec:
      # PERIODO DE GRACIA DE 90 SEGUNDOS.
      #
      # Una transaccion tarda hasta 8 segundos y NO se puede interrumpir:
      # cortarla podria dejar un cobro sin reserva asociada, que es el peor
      # fallo posible en una pasarela de pagos.
      #
      # 90 s = 8 s (transaccion mas larga) + margen amplio para:
      #   - vaciar la cola interna de transacciones en curso
      #   - escribir el registro de cumplimiento de cada una
      #   - cerrar limpiamente las conexiones TLS con el banco
      #
      # El proceso DEBE manejar SIGTERM: dejar de aceptar peticiones nuevas,
      # terminar las en curso, escribir los registros, y salir.
      terminationGracePeriodSeconds: 90

      topologySpreadConstraints:
        # ZONAS: restriccion DURA. El requisito de sobrevivir a la caida de
        # una zona es explicito y no negociable.
        - maxSkew: 1
          topologyKey: topology.kubernetes.io/zone
          whenUnsatisfiable: DoNotSchedule
          minDomains: 3
          labelSelector:
            matchLabels:
              app: pasarela-pagos
          matchLabelKeys: ["pod-template-hash"]

        # NODOS: restriccion DURA tambien, y aqui SI podemos permitirnosla.
        # Con un maximo de 9 replicas y 9 nodos, exigir 1 por nodo es
        # alcanzable. Y dos replicas de la pasarela en el mismo nodo son
        # dos replicas que se pierden juntas: inaceptable en el camino
        # critico del pago.
        - maxSkew: 1
          topologyKey: kubernetes.io/hostname
          whenUnsatisfiable: DoNotSchedule
          labelSelector:
            matchLabels:
              app: pasarela-pagos
          matchLabelKeys: ["pod-template-hash"]

      containers:
        - name: pasarela
          image: registry.rutasnorte.example/pasarela-pagos:2.4.1

          # PARADA ORDENADA: el hook preStop da margen para que el Service
          # saque este pod de sus endpoints ANTES de que empiece a apagarse.
          # Sin esto, hay una ventana de 1-2 segundos en la que el pod recibe
          # peticiones nuevas mientras ya se esta apagando.
          lifecycle:
            preStop:
              exec:
                command: ["/bin/sh", "-c", "sleep 10"]

          resources:
            requests: {cpu: 200m, memory: 256Mi}
            limits: {cpu: 500m, memory: 512Mi}

          env:
            # POOL PEQUENO Y EXPLICITO: 5 conexiones por replica.
            # Con maxReplicas 9: 9 x 5 = 45 < 50. Deja margen de 5 conexiones
            # para el despliegue (maxSurge 1) y para reintentos.
            # ESTE NUMERO ES CRITICO: subirlo agota el limite del banco.
            - name: BANCO_POOL_MAX
              value: "5"

          readinessProbe:
            httpGet: {path: /preparado, port: 8080}
            initialDelaySeconds: 20        # El arranque tarda 20 s (TLS mutuo)
            periodSeconds: 5
            failureThreshold: 2
          livenessProbe:
            httpGet: {path: /salud, port: 8080}
            initialDelaySeconds: 30
            periodSeconds: 10
            failureThreshold: 3
          # STARTUP PROBE: da hasta 60 s para el arranque sin que la
          # livenessProbe mate el pod a mitad de la negociacion TLS.
          startupProbe:
            httpGet: {path: /salud, port: 8080}
            periodSeconds: 5
            failureThreshold: 12

# k8s/entornos/pro/pdb-pasarela-pagos.yaml
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: pasarela-pagos
  namespace: rutas-norte-pro
  labels:
    app: pasarela-pagos
    app.kubernetes.io/part-of: rutas-norte
spec:
  # maxUnavailable: 1 EN NUMERO ABSOLUTO, no en porcentaje.
  #
  # Es la excepcion a la regla general del apartado 3, y es deliberada:
  #
  # 1. El rango de replicas es ESTRECHO (3 a 9), no como api-reservas (4 a 30).
  #    Un porcentaje del 25 % daria: 3 replicas -> 0 desalojos (BLOQUEO), y
  #    9 replicas -> 2 desalojos. El caso de 3 replicas seria un PDB imposible.
  #
  # 2. Cada replica que se cae puede llevarse hasta 5 transacciones en vuelo,
  #    cada una con dinero real de un cliente. Queremos que los desalojos se
  #    SERIALICEN siempre, sea cual sea el numero de replicas.
  #
  # 3. Con el terminationGracePeriodSeconds de 90 s, cada desalojo tarda hasta
  #    minuto y medio. Serializarlos hace el mantenimiento lento pero seguro,
  #    que es exactamente el compromiso que queremos en una pasarela de pagos.
  maxUnavailable: 1

  selector:
    matchLabels:
      app: pasarela-pagos

  # AlwaysAllow: un pod que no pasa la readiness no esta procesando pagos
  # (el Service ya no le manda trafico), asi que desalojarlo no pone en
  # riesgo ninguna transaccion.
  unhealthyPodEvictionPolicy: AlwaysAllow

# k8s/entornos/pro/scaledobject-pasarela-pagos.yaml
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: pasarela-pagos
  namespace: rutas-norte-pro
spec:
  scaleTargetRef:
    name: pasarela-pagos

  pollingInterval: 15
  cooldownPeriod: 600

  # 3 replicas de suelo: UNA POR ZONA. Es el minimo para sobrevivir a la
  # caida de una zona conservando 2 replicas operativas. NUNCA escalar a cero:
  # el arranque de 20 s (negociacion TLS mutua con el banco) es inaceptable
  # con un usuario en la pantalla de pago.
  minReplicaCount: 3

  # 9 REPLICAS MAXIMO. ESTE NUMERO NO SALE DEL TRAFICO, SALE DEL BANCO:
  #   9 replicas x 5 conexiones = 45 conexiones < 50 del limite.
  #   Margen de 5 conexiones para el despliegue (maxSurge 1) y reintentos.
  #
  # ADVERTENCIA CRITICA: subir este numero SIN renegociar el limite con el
  # banco NO aumenta la capacidad. Solo hace que las replicas compitan por
  # las mismas 50 conexiones y empiecen a recibir errores de conexion
  # rechazada. El cuello de botella es el BANCO (ver 09-01).
  maxReplicaCount: 9

  fallback:
    failureThreshold: 3
    replicas: 6

  advanced:
    horizontalPodAutoscalerConfig:
      behavior:
        scaleUp:
          # 30 s de estabilizacion (no 0): cada replica nueva tarda 20 s en
          # estar lista y abre 5 conexiones al banco. No queremos crear
          # replicas a lo loco y agotar el limite de conexiones.
          stabilizationWindowSeconds: 30
          selectPolicy: Max
          policies:
            - type: Pods
              value: 2
              periodSeconds: 60
        scaleDown:
          # 15 minutos. Cada replica que se apaga tarda hasta 90 s en terminar
          # sus transacciones. Bajar despacio es esencial.
          stabilizationWindowSeconds: 900
          selectPolicy: Min
          policies:
            - type: Pods
              value: 1
              periodSeconds: 300

  triggers:
    # Escalado por CONEXIONES ACTIVAS AL BANCO, no por CPU ni por peticiones.
    # Es la metrica que refleja el recurso escaso real.
    - type: prometheus
      metadata:
        serverAddress: http://prometheus-operated.monitorizacion.svc.cluster.local:9090
        metricName: pasarela_conexiones_banco_activas
        query: |
          sum(pasarela_pagos_conexiones_banco_activas{namespace="rutas-norte-pro"})
        # Objetivo: 3,5 conexiones activas por replica (de un pool de 5).
        # Al 70 % de ocupacion del pool, escalamos.
        threshold: "3.5"
        activationThreshold: "1"
      authenticationRef:
        kind: ClusterTriggerAuthentication
        name: prometheus-lectura

    # Red de seguridad: transacciones encoladas esperando una conexion libre.
    - type: prometheus
      metadata:
        serverAddress: http://prometheus-operated.monitorizacion.svc.cluster.local:9090
        metricName: pasarela_transacciones_en_espera
        query: |
          sum(pasarela_pagos_transacciones_en_espera{namespace="rutas-norte-pro"})
        threshold: "3"
        activationThreshold: "1"
      authenticationRef:
        kind: ClusterTriggerAuthentication
        name: prometheus-lectura