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

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

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

# Aixo RESPECTA el PDB
kubectl drain <node> --pod-selector=app=api-reserves

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

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

Durant el pont: 30 repliques. Algu posa minAvailable: 25.
  Desallotjaments permesos: 5. Raonable.

Despres del pont: l'HPA baixa a 4 repliques. El PDB continua dient minAvailable: 25.
  Pods disponibles: 4. Minim exigit: 25.
  JA s'esta per sota del minim.
  Desallotjaments permesos: ZERO. Per sempre.

El node que allotgi qualsevol replica d'api-reserves queda ANCORAT.
El Cluster Autoscaler no el pot retirar. El manteniment es bloqueja.

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

{
  "apiVersion": "policy/v1",
  "kind": "Eviction",
  "metadata": {
    "name": "api-reserves-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-reserves needs 3 healthy pods and has 3 currently"
      }
    ]
  }
}

kubectl get pdb -n rutas-norte-pro

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

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

Name:             api-reserves
Namespace:        rutas-norte-pro
Max unavailable:  25%
Selector:         app=api-reserves
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 amb 3 repliques
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:
  # Amb 3 repliques, exigir-ne 3 de disponibles significa ZERO desallotjaments permesos.
  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.
...

# Opcio A: mes repliques. Amb 4 repliques i minAvailable: 3, es permet 1 desallotjament.
kubectl -n rutas-norte-dev scale deployment demo-pdb --replicas=4

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

# Opcio C (ULTIM RECURS, perillos): forcar el drenatge
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        # al Deployment
---
spec:
  minAvailable: 3    # al PDB

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

# Tots els PDB del cluster amb els seus desallotjaments permesos
kubectl get pdb --all-namespaces

NAMESPACE          NAME                   MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS
rutas-norte-pro    api-reserves           N/A             25%               2
rutas-norte-pro    botiga-web             N/A             1                 1
rutas-norte-pro    postgres-reserves      1               N/A               0
rutas-norte-pro    redis-cache            1               N/A               0
rutas-norte-pro    worker-notificacions   N/A             50%               4
monitoratge        prometheus             1               N/A               0

# PDB que porten mes d'una hora sense permetre cap desallotjament
kube_poddisruptionbudget_status_pod_disruptions_allowed == 0

Repliques totals: 6
Repliques Ready: 2
Repliques no Ready: 4

PDB: maxUnavailable: 1 -> minim 5 disponibles.
Disponibles actuals: 2. Ja estem PER SOTA del minim.
ALLOWED DISRUPTIONS: 0.

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: api-reserves
  namespace: rutas-norte-pro
spec:
  maxUnavailable: 25%
  selector:
    matchLabels:
      app: api-reserves
  # Permet desallotjar SEMPRE els pods que no estan Ready, sense consumir
  # pressupost d'interrupcio.
  unhealthyPodEvictionPolicy: AlwaysAllow

# k8s/entorns/pro/pdb-api-reserves.yaml
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: api-reserves
  namespace: rutas-norte-pro
  labels:
    app: api-reserves
    app.kubernetes.io/part-of: rutas-norte
spec:
  # PERCENTATGE, no numero absolut. api-reserves te KEDA/HPA (09-01, 09-04)
  # i oscil·la entre 4 i 30 repliques al llarg del dia. Un minAvailable
  # absolut quedaria obsolet tan bon punt l'HPA es mogues, i amb la vall
  # nocturna es convertiria en un PDB IMPOSSIBLE que bloquejaria el
  # manteniment i la reduccio de nodes.
  #
  # Amb 25 %:
  #    4 repliques -> permet desallotjar-ne 1  (terra(4 x 0,25) = 1)
  #   12 repliques -> permet desallotjar-ne 3
  #   30 repliques -> permet desallotjar-ne 7
  # La PROPORCIO de servei protegida es constant: sempre el 75 %.
  maxUnavailable: 25%

  selector:
    matchLabels:
      app: api-reserves

  # Els pods que no passen la readiness no estan servint transit: desallotjar-los
  # no redueix la disponibilitat i evita l'encallament circular d'un desplegament
  # defectuos que impedeix la seva propia reparacio.
  unhealthyPodEvictionPolicy: AlwaysAllow

# k8s/entorns/pro/pdb-botiga-web.yaml
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: botiga-web
  namespace: rutas-norte-pro
  labels:
    app: botiga-web
    app.kubernetes.io/part-of: rutas-norte
spec:
  # 34 %, mes permissiu que api-reserves. Rao: botiga-web es nginx servint
  # estatic. Arrenca en ~1 segon i no te estat ni cache que escalfar,
  # aixi que una replica desallotjada torna gairebe a l'instant en un altre node.
  # Permetre mes desallotjaments simultanis accelera el manteniment sense risc real.
  #
  # Amb 3 repliques -> permet desallotjar-ne 1  (terra(3 x 0,34) = 1)
  # Amb 15 repliques -> permet desallotjar-ne 5
  maxUnavailable: 34%

  selector:
    matchLabels:
      app: botiga-web

  unhealthyPodEvictionPolicy: AlwaysAllow

# k8s/entorns/pro/pdb-worker-notificacions.yaml
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: worker-notificacions
  namespace: rutas-norte-pro
  labels:
    app: worker-notificacions
    app.kubernetes.io/part-of: rutas-norte
spec:
  # 50 %, el mes permissiu de la plataforma. Justificacio:
  #
  # 1. NINGU ESPERA. Un correu de confirmacio enviat 30 segons mes tard
  #    no te cap consequencia per a l'usuari.
  # 2. LA CUA ES L'AMORTIDOR. Si es desallotja la meitat dels workers, la
  #    feina no es perd: s'acumula a la cua i es processa despres.
  #    El missatge en vol es reentrega automaticament.
  # 3. KEDA REACCIONA. Si la cua creix perque hi ha menys workers, KEDA (09-04)
  #    escalara per compensar.
  #
  # Amb escalat a ZERO (minReplicaCount: 0) hi ha un matis: quan hi ha 0
  # repliques, el PDB no cobreix cap pod i ALLOWED DISRUPTIONS sera 0, pero
  # aixo es irrellevant perque no hi ha res a desallotjar.
  maxUnavailable: 50%

  selector:
    matchLabels:
      app: worker-notificacions

  unhealthyPodEvictionPolicy: AlwaysAllow

# k8s/entorns/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:
    # Anotacio per excloure aquest PDB de l'alerta de "PDB impossible":
    # el seu ALLOWED DISRUPTIONS es 0 de forma DELIBERADA.
    rutasnorte.example/pdb-bloqueig-intencionat: >
      redis-cache es un StatefulSet d'una replica. Desallotjar-lo buida la cache
      i descarrega tota la carrega de consultes de disponibilitat sobre
      postgres-reserves. Requereix intervencio manual i finestra de manteniment.
spec:
  # minAvailable: 1 amb UNA replica = ZERO desallotjaments permesos.
  # Es DELIBERAT. Consequencies assumides:
  #   - El Cluster Autoscaler no retirara el node que allotgi redis-cache.
  #   - kubectl drain sobre aquest node es quedara esperant.
  #   - El manteniment d'aquest node requereix decisio humana explicita.
  #
  # Es un compromis ACCEPTAT: preferim que el manteniment sigui manual a
  # que un mecanisme automatic buidi la cache en el pitjor moment possible.
  minAvailable: 1

  selector:
    matchLabels:
      app: redis-cache

  # IfHealthyBudget (el defecte). No hi posem AlwaysAllow: si redis-cache no
  # esta Ready, pot estar carregant dades o recuperant-se. Desallotjar-lo
  # empitjoraria les coses.
  unhealthyPodEvictionPolicy: IfHealthyBudget

# k8s/entorns/pro/pdb-postgres-reserves.yaml
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: postgres-reserves
  namespace: rutas-norte-pro
  labels:
    app: postgres-reserves
    app.kubernetes.io/part-of: rutas-norte
  annotations:
    rutasnorte.example/pdb-bloqueig-intencionat: >
      postgres-reserves es la base de dades primaria de la plataforma amb una
      unica replica. CAP mecanisme automatic no l'ha de moure. El manteniment
      del node que l'allotgi requereix una finestra planificada, amb parada
      controlada de l'aplicacio i copia de seguretat previa. Veure 05-06.
      La solucio definitiva es un operador de PostgreSQL: veure 06-07.
spec:
  # ZERO desallotjaments. Es la proteccio mes forta possible, i es intencionada.
  #
  # Un desallotjament automatic de postgres-reserves significaria:
  #   - Tall de TOTES les connexions d'api-reserves.
  #   - Perdua de la cache de pagines de PostgreSQL (minuts de latencia dolenta).
  #   - Risc d'inconsistencia si hi ha transaccions en vol.
  #   - La plataforma sencera caiguda durant l'arrencada.
  #
  # Guarda dades personals de clients: qualsevol risc es inacceptable.
  minAvailable: 1

  selector:
    matchLabels:
      app: postgres-reserves

  unhealthyPodEvictionPolicy: IfHealthyBudget

node-1 (zona A):  api-reserves x4, botiga-web x2
node-2 (zona A):  postgres-reserves
node-3 (zona B):  redis-cache, worker x2
node-4 (zona B):  (gairebe buit)

Cau node-1  ->  ZERO repliques d'api-reserves. Plataforma caiguda.
Cau la zona A -> ZERO repliques d'api-reserves I la base de dades.

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

biaix = (pods al domini amb MES) - (pods al domini amb MENYS)

Sense minDomains, amb 3 repliques i nomes 1 zona amb nodes disponibles:
  Zona A: 3 pods. Zona B: no hi ha nodes. Zona C: no hi ha nodes.
  Dominis EXISTENTS: 1
  Biaix: 3 - 3 = 0  ->  la restriccio ES COMPLEIX.
  Resultat: les 3 repliques a la mateixa zona. NO es el que volies.

Amb minDomains: 3:
  El planificador considera que hi ha 3 dominis, dos d'ells amb 0 pods.
  Biaix: 3 - 0 = 3 > maxSkew 1  ->  NO es compleix.
  Amb DoNotSchedule: els pods queden Pending fins que hi hagi nodes en altres zones.

Actualitzacio d'api-reserves de v1.14 a v1.15. 6 repliques.

Estat intermedi:
  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

Biaix calculat sobre TOTS: 3 - 1 = 2 > maxSkew 1
-> El planificador NO pot col·locar mes pods v1.15 a la zona A.
-> L'actualitzacio s'encalla o es distribueix malament.

Amb matchLabelKeys: ["pod-template-hash"]:
  Per col·locar un pod v1.15, nomes compten els pods v1.15:
    zona A: 1, zona B: 0, zona C: 0
  Biaix: 1 - 0 = 1 <= maxSkew 1  ->  es pot col·locar a B o C.

La nova versio es distribueix correctament pel seu compte.

Col·locacio de la replica 1:
  A: 0, B: 0, C: 0. Qualsevol zona val. -> A
  Estat: A:1, B:0, C:0

Col·locacio de la replica 2:
  Si va a A: A:2, B:0, C:0. Biaix = 2-0 = 2 > 1. NO PERMES.
  Si va a B: A:1, B:1, C:0. Biaix = 1-0 = 1 <= 1. PERMES.
  -> B (o C)
  Estat: A:1, B:1, C:0

Col·locacio de la replica 3:
  Nomes C mante el biaix en 1 o menys.  -> C
  Estat: A:1, B:1, C:1  (biaix 0)

Repliques 4, 5, 6: es reparteixen una per zona.
  Estat: A:2, B:2, C:2  (biaix 0)

Col·locacio de la replica 7:
  Qualsevol zona: el biaix passaria a 1. Permes a les tres.
  -> A (arbitrari)
  Estat FINAL: A:3, B:2, C:2  (biaix 1)

Cau la zona A: queden 4 de 7 repliques (57 %).
Cau la zona B: queden 5 de 7 repliques (71 %).

Sense topologySpreadConstraints, en el pitjor cas les 7 podrien ser en una zona:
Cau aquesta zona: queden 0 de 7 (0 %). Plataforma caiguda.

affinity:
  podAntiAffinity:
    # Versio DURA: no es pot violar
    requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchLabels:
            app: api-reserves
        topologyKey: kubernetes.io/hostname

Regla: com a molt 1 replica d'api-reserves per node.
Nodes: 9.
Repliques maximes col·locables: 9.

L'HPA demana 30 repliques.
Se'n col·loquen 9. Les altres 21 queden en Pending PER SEMPRE.

El Cluster Autoscaler veu pods pendents i arrenca nodes... i amb cada node
nou hi cap UNA replica mes. Per a 30 repliques calarien 30 NODES.
Cost: absurd.

Regla: maxSkew 1 entre nodes.
Nodes: 9. Repliques: 30.

Repartiment: 30 / 9 = 3,33
Resultat: 3 nodes amb 4 repliques, 6 nodes amb 3 repliques.
Biaix: 4 - 3 = 1. Compleix.

Les 30 repliques es col·loquen. Cap Pending.

# api-reserves NO ha de compartir node amb el CronJob d'informes, que consumeix
# 4 nuclis de cop i estrangularia l'API durant 40 minuts.
affinity:
  podAntiAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchLabels:
            app: informes-ocupacio       # UNA ALTRA aplicacio, no la mateixa
        topologyKey: kubernetes.io/hostname

spec:
  template:
    spec:
      # 1. Repartiment equilibrat entre zones i nodes (disponibilitat)
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: topology.kubernetes.io/zone
          whenUnsatisfiable: DoNotSchedule
          labelSelector:
            matchLabels:
              app: api-reserves
          matchLabelKeys: ["pod-template-hash"]
        - maxSkew: 2
          topologyKey: kubernetes.io/hostname
          whenUnsatisfiable: ScheduleAnyway
          labelSelector:
            matchLabels:
              app: api-reserves
          matchLabelKeys: ["pod-template-hash"]

      # 2. Antiafinitat amb UNA ALTRA aplicacio (aillament de recursos)
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                matchLabels:
                  app: informes-ocupacio
              topologyKey: kubernetes.io/hostname

# k8s/base/deployment-api-reserves.yaml (fragment)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-reserves
  namespace: rutas-norte-pro
spec:
  # Sense replicas: ho governa KEDA/HPA (09-01, 09-04)
  selector:
    matchLabels:
      app: api-reserves
  template:
    metadata:
      labels:
        app: api-reserves
        app.kubernetes.io/part-of: rutas-norte
    spec:
      topologySpreadConstraints:
        # NIVELL 1: entre ZONES DE DISPONIBILITAT. Restriccio DURA.
        #
        # Aquest es el domini de fallada gran: si cau una zona sencera, cal
        # garantir que sobrevisquin repliques a les altres dues. Es una
        # garantia que NO estem disposats a negociar, aixi que DoNotSchedule:
        # preferim un pod Pending a un repartiment desequilibrat.
        - maxSkew: 1
          topologyKey: topology.kubernetes.io/zone
          whenUnsatisfiable: DoNotSchedule
          labelSelector:
            matchLabels:
              app: api-reserves
          # 3 zones sempre, encara que una no tingui nodes ara mateix. Sense aixo,
          # si el Cluster Autoscaler nomes te nodes en 2 zones, el repartiment
          # "equilibrat" entre aquestes 2 compliria la restriccio i perdriem
          # la garantia de les 3 zones.
          minDomains: 3
          matchLabelKeys: ["pod-template-hash"]

        # NIVELL 2: entre NODES. Restriccio TOVA.
        #
        # Repartir entre nodes es desitjable pero NO al preu de deixar pods
        # Pending. Durant el pont de maig, amb 30 repliques i el Cluster
        # Autoscaler arrencant nodes, un DoNotSchedule aqui bloquejaria
        # l'escalat justament quan mes falta fa.
        #
        # maxSkew 2 (no 1): amb 30 repliques i 9 nodes, exigir maxSkew 1 seria
        # innecessariament rigid. Un 4-3-3-4-3-3-4-3-3 es perfectament sa.
        - maxSkew: 2
          topologyKey: kubernetes.io/hostname
          whenUnsatisfiable: ScheduleAnyway
          labelSelector:
            matchLabels:
              app: api-reserves
          matchLabelKeys: ["pod-template-hash"]

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

3 zones, maxSkew 1, minDomains 3.

Repartiment: 4 / 3 = 1,33
Resultat: A:2, B:1, C:1. Biaix = 2-1 = 1. Compleix.

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

Amb maxUnavailable: 25% al PDB, 4 repliques permeten 1 desallotjament.
La caiguda d'una zona (2 repliques) es INVOLUNTARIA: el PDB no aplica.
Sobreviuen 2 repliques -> el servei continua, degradat.
KEDA/HPA detectara la carrega per replica duplicada i escalara.

Nivell ZONA (maxSkew 1, DoNotSchedule):
  30 / 3 = 10 exactes.
  Resultat: A:10, B:10, C:10. Biaix 0. Perfecte.

Nivell NODE (maxSkew 2, ScheduleAnyway), amb 9 nodes (3 per zona):
  Dins de cada zona, 10 repliques entre 3 nodes: 4-3-3.
  Biaix global entre nodes: 4 - 3 = 1 <= 2. Compleix.

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

Caiguda d'un NODE: es perden 3 o 4 repliques de 30 (10-13 %). Imperceptible.
Caiguda d'una ZONA: es perden 10 de 30 (33 %). El servei aguanta amb 20.

      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: topology.kubernetes.io/zone
          whenUnsatisfiable: DoNotSchedule
          labelSelector:
            matchLabels:
              app: botiga-web
          minDomains: 3
          matchLabelKeys: ["pod-template-hash"]
        - maxSkew: 1
          topologyKey: kubernetes.io/hostname
          # maxSkew 1 i ScheduleAnyway: amb nomes 3-15 repliques, un repartiment
          # d'1 per node es assolible i desitjable. Pero continuem sense
          # bloquejar l'escalat.
          whenUnsatisfiable: ScheduleAnyway
          labelSelector:
            matchLabels:
              app: botiga-web
          matchLabelKeys: ["pod-template-hash"]

# k8s/base/statefulset-postgres-reserves.yaml (fragment)
spec:
  template:
    spec:
      # Viu al grup de nodes de dades (09-03), amb el seu taint i la seva afinitat.
      tolerations:
        - key: rol
          operator: Equal
          value: dades
          effect: NoSchedule
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
              - matchExpressions:
                  - key: rol
                    operator: In
                    values: ["dades"]
        # NO compartir node amb redis-cache: si cau aquest node, no volem
        # perdre la base de dades I la cache alhora, perque l'arrencada de
        # la base de dades amb la cache buida es el pitjor escenari possible.
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                matchLabels:
                  app: redis-cache
              topologyKey: kubernetes.io/hostname

Cluster de 3 membres d'etcd. En cauen 2.
Quorum necessari: 2. Membres vius: 1. NO HI HA QUORUM.

Consequencies:
  - etcd passa a NOMES LECTURA. No accepta escriptures.
  - El servidor d'API no pot persistir canvis.
  - kubectl apply falla. No es poden crear, modificar ni esborrar objectes.
  - L'HPA no pot canviar repliques.
  - El Cluster Autoscaler no pot fer res.

PERO, i aixo es l'important:
  - Els pods que JA estaven corrent CONTINUEN CORRENT.
  - Els kubelets continuen executant els seus contenidors.
  - Els Services continuen enrutant (kube-proxy te el seu estat local).
  - LA PLATAFORMA CONTINUA ATENENT TRANSIT.

3 nodes de pla de control, un per zona de disponibilitat:
  zona A: control-1 (etcd, api-server, scheduler, controller-manager)
  zona B: control-2
  zona C: control-3

Caiguda d'una zona: queden 2 de 3. Quorum = 2. ES MANTE.

# k8s/entorns/pro/deployment-ingress-nginx.yaml (fragment)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: ingress-nginx-controller
  namespace: ingress-nginx
spec:
  replicas: 4              # Mai 1. Mai 2 al mateix domini de fallada.
  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 que es dur
          labelSelector:
            matchLabels:
              app.kubernetes.io/name: ingress-nginx
---
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: ingress-nginx
  namespace: ingress-nginx
spec:
  minAvailable: 2          # Numero absolut: les repliques de l'Ingress son FIXES
  selector:
    matchLabels:
      app.kubernetes.io/name: ingress-nginx
  unhealthyPodEvictionPolicy: AlwaysAllow

# Fragment del Deployment de CoreDNS a 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

# Exemple amb CloudNativePG
apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: postgres-reserves
  namespace: rutas-norte-pro
spec:
  instances: 3                    # 1 primaria + 2 repliques
  primaryUpdateStrategy: unsupervised

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

  # L'operador reparteix les instancies entre zones automaticament
  affinity:
    enablePodAntiAffinity: true
    topologyKey: topology.kubernetes.io/zone
    podAntiAffinityType: required

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

  monitoring:
    enablePodMonitor: true         # S'integra amb Prometheus (07-03)

# Tots els PDB permeten almenys un desallotjament?
kubectl get pdb --all-namespaces

NAMESPACE          NAME                   MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS
rutas-norte-pro    api-reserves           N/A             25%               1
rutas-norte-pro    botiga-web             N/A             34%               1
rutas-norte-pro    postgres-reserves      1               N/A               0     <- ATENCIO
rutas-norte-pro    redis-cache            1               N/A               0     <- ATENCIO
rutas-norte-pro    worker-notificacions   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-reserves,redis-cache)'

NAME                  READY   STATUS    NODE            ZONA
postgres-reserves-0   2/2     Running   node-dades-1    eu-west-1a
redis-cache-0         1/1     Running   node-dades-2    eu-west-1b

# Que hi ha al node que drenarem?
kubectl get pods --all-namespaces -o wide --field-selector spec.nodeName=node-a2

NAMESPACE         NAME                            READY   STATUS    AGE
rutas-norte-pro   api-reserves-7c9d4f8b6d-2mkjp   2/2     Running   4h
rutas-norte-pro   api-reserves-7c9d4f8b6d-9nvtr   2/2     Running   4h
rutas-norte-pro   botiga-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

# Hi ha alguna alerta activa? No es fa manteniment amb incidents oberts.
kubectl get events --all-namespaces --field-selector type=Warning \
  --sort-by=.lastTimestamp | tail -20

kubectl cordon node-a2

node/node-a2 cordoned

kubectl get nodes

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

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

node/node-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-reserves-7c9d4f8b6d-2mkjp
evicting pod rutas-norte-pro/botiga-web-6f7d9c4b58-4kjnx
evicting pod rutas-norte-pro/api-reserves-7c9d4f8b6d-9nvtr
error when evicting pods/"api-reserves-7c9d4f8b6d-9nvtr" -n "rutas-norte-pro"
(will retry after 5s): Cannot evict pod as it would violate the pod's disruption budget.
pod/botiga-web-6f7d9c4b58-4kjnx evicted
pod/api-reserves-7c9d4f8b6d-2mkjp evicted
evicting pod rutas-norte-pro/api-reserves-7c9d4f8b6d-9nvtr
pod/api-reserves-7c9d4f8b6d-9nvtr evicted
node/node-a2 drained

# El node ha d'estar buit de pods d'aplicacio
kubectl get pods --all-namespaces -o wide --field-selector spec.nodeName=node-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

# I el SERVEI ha d'estar sa: aixo es el que de debo importa
kubectl get pods -n rutas-norte-pro -l app=api-reserves
kubectl get pdb -n rutas-norte-pro

# Exemple: actualitzar el kubelet en un cluster amb kubeadm (10-02)
ssh node-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 node-a2

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

# Comprovar que no hi ha condicions d'error
kubectl describe node node-a2 | grep -A10 Conditions

kubectl uncordon node-a2

node/node-a2 uncordoned

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

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

      2 node-a1
      1 node-a3
      2 node-b1
      1 node-b2

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

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

api-reserves tenia 4 repliques: 2 a node-a2, 1 a node-a1, 1 a node-b1.
Despres del drenatge: 2 repliques vives, 2 arrencant (25-30 segons).

Durant 30 segons: LA MEITAT de la capacitat de l'API.
Cada replica viva rep el DOBLE de carrega.
Latencia p95: de 180 ms a 900 ms.
Algunes peticions: timeout.

I si haguessin estat 3 de les 4 repliques en aquest node: 25 % de capacitat.
La replica supervivent se satura i cau. CAIGUDA TOTAL.

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: farciment-capacitat
  namespace: rutas-norte-pro
spec:
  # 100 % d'indisponibilitat permesa: aquests pods hi son PER ser desallotjats.
  # Documenta la intencio millor que l'absencia de PDB.
  maxUnavailable: 100%
  selector:
    matchLabels:
      app: farciment-capacitat

# Al Deployment: governa l'ACTUALITZACIO
spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 25%     # Coherent amb el PDB
      maxSurge: 25%
---
# Al PDB: governa els DESALLOTJAMENTS (drain, CA, VPA)
spec:
  maxUnavailable: 25%

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

# Etiquetar els nodes amb zones ficticies
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 transit continu i comptar errors
kubectl -n rutas-norte-dev run client --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 drenatge
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 una fallada de maquinari: apagar el node bruscament
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     <- als ~40 segons

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
...
(passen ~5 minuts)
...
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      <- comencen els errors
OK=1218 ERR=11
...
OK=1301 ERR=68     <- ~40 segons d'errors
OK=1409 ERR=68     <- s'aturen: el Service ja va excloure el node mort
OK=1520 ERR=68

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

# PDB sense desallotjaments permesos, excloent els intencionats
kube_poddisruptionbudget_status_pod_disruptions_allowed == 0
  unless on(namespace, poddisruptionbudget)
  kube_poddisruptionbudget_annotations{annotation_rutasnorte_example_pdb_bloqueig_intencionat!=""}

# Repliques per zona
kubectl get pods -n rutas-norte-pro -l app=api-reserves \
  -o custom-columns=NODE:.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 node-b1 --ignore-daemonsets --delete-emptydir-data

node/node-b1 already cordoned
Warning: ignoring DaemonSet-managed Pods: kube-system/fluentd-2wxkp, kube-system/falco-x7kqp
evicting pod monitoratge/prometheus-server-0
evicting pod rutas-norte-pro/api-reserves-7c9d4f8b6d-mn2vp
evicting pod rutas-norte-pro/worker-notificacions-5f8d9c-4kjnx
pod/worker-notificacions-5f8d9c-4kjnx evicted
error when evicting pods/"prometheus-server-0" -n "monitoratge"
(will retry after 5s): Cannot evict pod as it would violate the pod's disruption budget.
error when evicting pods/"api-reserves-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-reserves           8               N/A               0
rutas-norte-pro    botiga-web             N/A             34%               1
rutas-norte-pro    worker-notificacions   N/A             50%               1
monitoratge        prometheus             1               N/A               0

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

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

# PDB
spec:
  maxUnavailable: 25%

Repliques totals d'api-reserves: 5
  - 4 amb READY 2/2 (sanes)
  - 1 amb READY 1/2 (el pod x2klm: un contenidor no esta llest)

Repliques DISPONIBLES (Ready): 4
El PDB exigeix: minAvailable: 8

4 < 8  ->  JA estem per sota del minim.
ALLOWED DISRUPTIONS: 0. I continuara sent 0 passi el que passi.

kubectl describe pod api-reserves-7c9d4f8b6d-x2klm -n rutas-norte-pro
kubectl logs api-reserves-7c9d4f8b6d-x2klm -n rutas-norte-pro -c exportador-metriques

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

Repliques desitjades: 5
maxUnavailable: 25% -> terra(5 x 0,25) = 1
Minim disponible: 5 - 1 = 4
Disponibles actuals: 4
ALLOWED DISRUPTIONS: 0

...Continua sent 0, per culpa del pod x2klm que no esta Ready.

# Via A: si el pod esta trencat sense remei, esborrar-lo perque es recrei
kubectl delete pod api-reserves-7c9d4f8b6d-x2klm -n rutas-norte-pro
# (kubectl delete NO respecta PDB: aqui ens va be)

# Via B: afegir unhealthyPodEvictionPolicy perque els pods no sans
# no consumeixin pressupost
kubectl patch pdb api-reserves -n rutas-norte-pro --type merge \
  -p '{"spec":{"unhealthyPodEvictionPolicy":"AlwaysAllow"}}'

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: api-reserves
  namespace: rutas-norte-pro
  annotations:
    rutasnorte.example/nota: >
      PERCENTATGE obligatori: api-reserves te KEDA/HPA i oscil·la entre
      4 i 30 repliques. Un minAvailable absolut es torna impossible a la
      vall i bloqueja tot el manteniment. Veure 09-05.
spec:
  maxUnavailable: 25%
  selector:
    matchLabels:
      app: api-reserves
  unhealthyPodEvictionPolicy: AlwaysAllow

prometheus-server-0: 1 replica (es un StatefulSet).
PDB: minAvailable: 1.
Desallotjar-la deixaria 0 disponibles.
ALLOWED DISRUPTIONS: 0. Permanent i per disseny.

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: prometheus
  namespace: monitoratge
spec:
  # Una sola replica: permetem el desallotjament. Perdem uns minuts de
  # metriques durant el manteniment, cosa que es acceptable: Prometheus
  # no esta al cami critic de la venda.
  maxUnavailable: 1
  selector:
    matchLabels:
      app: prometheus

# 1. Corregir el PDB d'api-reserves
kubectl patch pdb api-reserves -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 monitoratge --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-reserves           25%               1
monitoratge        prometheus             1                 1

# 4. Investigar el pod x2klm (no urgent, pero no ho oblidis)
kubectl describe pod api-reserves-7c9d4f8b6d-x2klm -n rutas-norte-pro

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

kube_poddisruptionbudget_status_pod_disruptions_allowed == 0

11 / 3 = 3,67

Repartiment mes equilibrat possible:
  eu-west-1a: 4
  eu-west-1b: 4
  eu-west-1c: 3

Biaix = 4 - 3 = 1 <= maxSkew 1. COMPLEIX.

Zona a (4 repliques, 3 nodes): 2-1-1
Zona b (4 repliques, 3 nodes): 2-1-1
Zona c (3 repliques, 3 nodes): 1-1-1

Biaix global entre nodes: max 2 - min 1 = 1 <= maxSkew 2. COMPLEIX.

Pitjor cas: cau un node amb 2 repliques.
Perdues: 2 d'11.
Queden: 9 d'11 = 81,8 % de capacitat.

Pitjor cas: cau una zona amb 4 repliques.
Perdues: 4 d'11.
Queden: 7 d'11 = 63,6 % de capacitat.

maxUnavailable: 25% sobre 11 repliques.
terra(11 x 0,25) = terra(2,75) = 2

ALLOWED DISRUPTIONS: 2

26 / 3 = 8,67

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

Biaix = 9 - 8 = 1 <= maxSkew 1. COMPLEIX.

Zona a (9 repliques, 3 nodes): 3-3-3
Zona b (9 repliques, 3 nodes): 3-3-3
Zona c (8 repliques, 3 nodes): 3-3-2

Biaix global entre nodes: 3 - 2 = 1 <= maxSkew 2. COMPLEIX.

Pitjor cas: cau un node amb 3 repliques.
Perdues: 3 de 26.
Queden: 23 de 26 = 88,5 % de capacitat.

Pitjor cas: cau una zona amb 9 repliques.
Perdues: 9 de 26.
Queden: 17 de 26 = 65,4 % de capacitat.

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

ALLOWED DISRUPTIONS: 6

Un node te 3 repliques d'api-reserves.
El PDB permet 6 desallotjaments simultanis.

3 <= 6  ->  SI, es poden desallotjar les 3 d'una vegada.

El drenatge NO se serialitzara per culpa del PDB d'api-reserves.
Sera gairebe instantani per a aquest component.

Amb 11 repliques, un node te 2 repliques i el PDB permet 2 desallotjaments.
2 <= 2 -> tambe hi caben d'una vegada, encara que just al limit.

Si el node tingues 3 repliques (possible amb maxSkew 2), el PDB serialitzaria:
desallotja 2, espera que es recreïn, desallotja la tercera.

minDomains: 3 significa que el planificador considera 3 dominis,
encara que algun estigui buit.

Col·locacio de la replica 1: zona a. Estat: a:1, b:0, c:0.
  Biaix = 1 - 0 = 1 <= maxSkew 1. Compleix.

Col·locacio de la replica 2:
  Si va a la zona a: a:2, b:0, c:0. Biaix = 2 - 0 = 2 > 1. NO PERMES.
  Si va a la zona b: a:1, b:1, c:0. Biaix = 1 - 0 = 1 <= 1. PERMES.

Resultat: 1 replica a la zona a, 1 a la zona b, 0 a la c.
La zona c queda buida, i aixo ES CORRECTE: amb 2 repliques no es poden
cobrir 3 zones.

Escenari: la zona c perd tots els seus nodes (caiguda completa).
Nodes disponibles: nomes a les zones a i b.

minDomains: 3 fa que el planificador CONTINUI COMPTANT 3 dominis.

Estat despres de la caiguda: a:1, b:1, c:0 (la zona c no te nodes).
Biaix = 1 - 0 = 1 <= maxSkew 1. COMPLEIX. Res a fer.

Pero si l'HPA volgues escalar a 4 repliques:
  Col·locacio de la replica 3:
    Si va a la zona a: a:2, b:1, c:0. Biaix = 2 - 0 = 2 > 1. NO PERMES.
    Si va a la zona b: a:1, b:2, c:0. Biaix = 2 - 0 = 2 > 1. NO PERMES.
    Si va a la zona c: NO HI HA NODES.

  -> La replica 3 es queda en PENDING PER SEMPRE.

# PROCEDIMENT D'EMERGENCIA: caiguda de zona
# Relaxar la restriccio topologica per permetre escalar a les zones vives.
kubectl patch deployment api-reserves -n rutas-norte-pro --type json -p '[
  {"op": "replace", "path": "/spec/template/spec/topologySpreadConstraints/0/whenUnsatisfiable",
   "value": "ScheduleAnyway"}
]'
# REVERTIR quan la zona torni.

El banc permet 50 connexions simultanies des de la IP de Rutas Norte.

Si cada replica mante un pool de N connexions:
  Repliques maximes = 50 / N

Amb N = 5 connexions per replica:  10 repliques maximes
Amb N = 3 connexions per replica:  16 repliques maximes
Amb N = 2 connexions per replica:  25 repliques maximes

Quantes transaccions per segon sosté una replica?
  Cada transaccio triga 2-8 s, mitjana ~5 s.
  Amb un pool de N connexions concurrents:
    transaccions/s = N / 5

  Amb N = 5: 1 transaccio/s per replica
  Amb N = 3: 0,6 transaccions/s per replica

Per a 300 transaccions/s al pic:
  Amb N = 5: 300 repliques. IMPOSSIBLE (excedeix el limit del banc per 30x).
  Amb N = 3: 500 repliques. Pitjor.

Capacitat TEORICA MAXIMA del sistema:
  50 connexions concurrents / 5 segons per transaccio = 10 transaccions/s

OBJECTIU DEL PIC: 300 transaccions/s

EL SISTEMA NO POT PROCESSAR MES DE 10 TRANSACCIONS PER SEGON.
El limit es el BANC, no Kubernetes.

1. NEGOCIAR amb el banc un limit mes gran. 50 connexions es ridicul per a
   300 transaccions/s. Es l'accio mes important i no es tecnica.

2. Mentrestant: DESACOBLAR amb una cua.
   - api-reserves encua la peticio de cobrament i respon a l'usuari
     "processant el seu pagament".
   - passarela-pagaments consumeix de la cua a la velocitat que el banc permet.
   - L'usuari rep la confirmacio per notificacio push o correu.

   Aixo converteix una restriccio dura en una latencia acceptable, i encaixa
   perfectament amb KEDA (09-04): la cua es el senyal d'escalat natural.

3. Un POOL COMPARTIT de connexions al banc, en lloc d'un pool per replica.

# k8s/entorns/pro/deployment-passarela-pagaments.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: passarela-pagaments
  namespace: rutas-norte-pro
  labels:
    app: passarela-pagaments
    app.kubernetes.io/part-of: rutas-norte
spec:
  # SENSE camp replicas: ho governa l'HPA/KEDA.
  selector:
    matchLabels:
      app: passarela-pagaments

  strategy:
    type: RollingUpdate
    rollingUpdate:
      # Coherent amb el PDB (veure mes avall). Mai perdre mes d'1 replica.
      maxUnavailable: 1
      # maxSurge 1, no mes: cada replica nova obre connexions al banc i
      # tenim un limit dur de 50. Un maxSurge alt podria esgotar-lo
      # durant el desplegament.
      maxSurge: 1

  template:
    metadata:
      labels:
        app: passarela-pagaments
        app.kubernetes.io/part-of: rutas-norte
    spec:
      # PERIODE DE GRACIA DE 90 SEGONS.
      #
      # Una transaccio triga fins a 8 segons i NO es pot interrompre:
      # tallar-la podria deixar un cobrament sense reserva associada, que es el pitjor
      # error possible en una passarel·la de pagaments.
      #
      # 90 s = 8 s (transaccio mes llarga) + marge ampli per:
      #   - buidar la cua interna de transaccions en curs
      #   - escriure el registre de compliment de cadascuna
      #   - tancar netament les connexions TLS amb el banc
      #
      # El proces HA de gestionar SIGTERM: deixar d'acceptar peticions noves,
      # acabar les en curs, escriure els registres, i sortir.
      terminationGracePeriodSeconds: 90

      topologySpreadConstraints:
        # ZONES: restriccio DURA. El requisit de sobreviure a la caiguda d'una
        # zona es explicit i no negociable.
        - maxSkew: 1
          topologyKey: topology.kubernetes.io/zone
          whenUnsatisfiable: DoNotSchedule
          minDomains: 3
          labelSelector:
            matchLabels:
              app: passarela-pagaments
          matchLabelKeys: ["pod-template-hash"]

        # NODES: restriccio DURA tambe, i aqui SI que ens la podem permetre.
        # Amb un maxim de 9 repliques i 9 nodes, exigir-ne 1 per node es
        # assolible. I dues repliques de la passarel·la al mateix node son
        # dues repliques que es perden juntes: inacceptable al cami
        # critic del pagament.
        - maxSkew: 1
          topologyKey: kubernetes.io/hostname
          whenUnsatisfiable: DoNotSchedule
          labelSelector:
            matchLabels:
              app: passarela-pagaments
          matchLabelKeys: ["pod-template-hash"]

      containers:
        - name: passarela
          image: registry.rutasnorte.example/passarela-pagaments:2.4.1

          # PARADA ORDENADA: el hook preStop dona marge perque el Service
          # tregui aquest pod dels seus endpoints ABANS que comenci a apagar-se.
          # Sense aixo, hi ha una finestra d'1-2 segons en que el pod rep
          # peticions noves mentre ja s'esta apagant.
          lifecycle:
            preStop:
              exec:
                command: ["/bin/sh", "-c", "sleep 10"]

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

          env:
            # POOL PETIT I EXPLICIT: 5 connexions per replica.
            # Amb maxReplicas 9: 9 x 5 = 45 < 50. Deixa marge de 5 connexions
            # per al desplegament (maxSurge 1) i per a reintents.
            # AQUEST NUMERO ES CRITIC: pujar-lo esgota el limit del banc.
            - name: BANC_POOL_MAX
              value: "5"

          readinessProbe:
            httpGet: {path: /preparat, port: 8080}
            initialDelaySeconds: 20        # L'arrencada triga 20 s (TLS mutu)
            periodSeconds: 5
            failureThreshold: 2
          livenessProbe:
            httpGet: {path: /salut, port: 8080}
            initialDelaySeconds: 30
            periodSeconds: 10
            failureThreshold: 3
          # STARTUP PROBE: dona fins a 60 s per a l'arrencada sense que la
          # livenessProbe mati el pod a mitja negociacio TLS.
          startupProbe:
            httpGet: {path: /salut, port: 8080}
            periodSeconds: 5
            failureThreshold: 12

# k8s/entorns/pro/pdb-passarela-pagaments.yaml
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: passarela-pagaments
  namespace: rutas-norte-pro
  labels:
    app: passarela-pagaments
    app.kubernetes.io/part-of: rutas-norte
spec:
  # maxUnavailable: 1 EN NUMERO ABSOLUT, no en percentatge.
  #
  # Es l'excepcio a la regla general de l'apartat 3, i es deliberada:
  #
  # 1. El rang de repliques es ESTRET (3 a 9), no com api-reserves (4 a 30).
  #    Un percentatge del 25 % donaria: 3 repliques -> 0 desallotjaments (BLOQUEIG), i
  #    9 repliques -> 2 desallotjaments. El cas de 3 repliques seria un PDB impossible.
  #
  # 2. Cada replica que cau pot endur-se fins a 5 transaccions en vol,
  #    cadascuna amb diners reals d'un client. Volem que els desallotjaments es
  #    SERIALITZIN sempre, sigui quin sigui el nombre de repliques.
  #
  # 3. Amb el terminationGracePeriodSeconds de 90 s, cada desallotjament triga fins a
  #    un minut i mig. Serialitzar-los fa el manteniment lent pero segur,
  #    que es exactament el compromis que volem en una passarel·la de pagaments.
  maxUnavailable: 1

  selector:
    matchLabels:
      app: passarela-pagaments

  # AlwaysAllow: un pod que no passa la readiness no esta processant pagaments
  # (el Service ja no li envia transit), aixi que desallotjar-lo no posa en
  # risc cap transaccio.
  unhealthyPodEvictionPolicy: AlwaysAllow

# k8s/entorns/pro/scaledobject-passarela-pagaments.yaml
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: passarela-pagaments
  namespace: rutas-norte-pro
spec:
  scaleTargetRef:
    name: passarela-pagaments

  pollingInterval: 15
  cooldownPeriod: 600

  # 3 repliques de terra: UNA PER ZONA. Es el minim per sobreviure a la
  # caiguda d'una zona conservant 2 repliques operatives. MAI escalar a zero:
  # l'arrencada de 20 s (negociacio TLS mutua amb el banc) es inacceptable
  # amb un usuari a la pantalla de pagament.
  minReplicaCount: 3

  # 9 REPLIQUES MAXIM. AQUEST NUMERO NO SURT DEL TRANSIT, SURT DEL BANC:
  #   9 repliques x 5 connexions = 45 connexions < 50 del limit.
  #   Marge de 5 connexions per al desplegament (maxSurge 1) i reintents.
  #
  # ADVERTENCIA CRITICA: pujar aquest numero SENSE renegociar el limit amb el
  # banc NO augmenta la capacitat. Nomes fa que les repliques competeixin per
  # les mateixes 50 connexions i comencin a rebre errors de connexio
  # rebutjada. El coll d'ampolla es el BANC (veure 09-01).
  maxReplicaCount: 9

  fallback:
    failureThreshold: 3
    replicas: 6

  advanced:
    horizontalPodAutoscalerConfig:
      behavior:
        scaleUp:
          # 30 s d'estabilitzacio (no 0): cada replica nova triga 20 s a
          # estar llesta i obre 5 connexions al banc. No volem crear
          # repliques a la babala i esgotar el limit de connexions.
          stabilizationWindowSeconds: 30
          selectPolicy: Max
          policies:
            - type: Pods
              value: 2
              periodSeconds: 60
        scaleDown:
          # 15 minuts. Cada replica que s'apaga triga fins a 90 s a acabar
          # les seves transaccions. Baixar a poc a poc es essencial.
          stabilizationWindowSeconds: 900
          selectPolicy: Min
          policies:
            - type: Pods
              value: 1
              periodSeconds: 300

  triggers:
    # Escalat per CONNEXIONS ACTIVES AL BANC, no per CPU ni per peticions.
    # Es la metrica que reflecteix el recurs escas real.
    - type: prometheus
      metadata:
        serverAddress: http://prometheus-operated.monitoratge.svc.cluster.local:9090
        metricName: passarela_connexions_banc_actives
        query: |
          sum(passarela_pagaments_connexions_banc_actives{namespace="rutas-norte-pro"})
        # Objectiu: 3,5 connexions actives per replica (d'un pool de 5).
        # Al 70 % d'ocupacio del pool, escalem.
        threshold: "3.5"
        activationThreshold: "1"
      authenticationRef:
        kind: ClusterTriggerAuthentication
        name: prometheus-lectura

    # Xarxa de seguretat: transaccions encuades esperant una connexio lliure.
    - type: prometheus
      metadata:
        serverAddress: http://prometheus-operated.monitoratge.svc.cluster.local:9090
        metricName: passarela_transaccions_en_espera
        query: |
          sum(passarela_pagaments_transaccions_en_espera{namespace="rutas-norte-pro"})
        threshold: "3"
        activationThreshold: "1"
      authenticationRef:
        kind: ClusterTriggerAuthentication
        name: prometheus-lectura