Scaling et haute disponibilité

Un replica unique suffit pour développer ; en production, on veut absorber les pics de charge (HPA) et survivre aux opérations de maintenance (PDB). Les deux objets sont disponibles en CRUD complet sur Kontainers.

Prérequis : des probes et des requests

L’autoscaling et la haute dispo reposent sur deux fondations :

containers:
  - name: web
    image: mon-app:1.4
    resources:
      requests:              # l'HPA calcule en % de la request CPU
        cpu: 250m
        memory: 512Mi
    readinessProbe:          # un pod non prêt ne reçoit pas de trafic
      httpGet: {path: /health, port: 8080}
      initialDelaySeconds: 5

Sans requests.cpu, un HPA basé CPU n’a pas de référence ; sans readinessProbe, vos rollouts envoient du trafic vers des pods pas encore prêts.

HorizontalPodAutoscaler

Testé sur la plateforme — ajuste le nombre de replicas selon la charge CPU :

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web
  minReplicas: 2
  maxReplicas: 6
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 80    # % de la request CPU

kubectl get hpa -n <namespace>
# NAME   REFERENCE        TARGETS       MINPODS   MAXPODS   REPLICAS
# web    Deployment/web   cpu: 12%/80%  2         6         2

À savoir :

Le plafond réel est votre quota namespace : la somme des requests de tous vos pods ne peut dépasser 10 vCPU / 20 Gi (et 20 pods). Dimensionnez maxReplicas en conséquence : 6 replicas × 250 m = 1,5 vCPU, très à l’aise ;
Scaler = payer : chaque replica supplémentaire réserve ses requests (facturation) — c’est le but (absorber la charge), mais bornez maxReplicas à ce que vous êtes prêt à dépenser ;
La CPU n’ayant pas de limite, vos pods bursteront déjà au-delà de leur request avant même que l’HPA n’ajoute des replicas : l’HPA gère les charges soutenues, pas les micro-pics ;
L’HPA sait aussi cibler la mémoire (name: memory) — attention toutefois : la mémoire redescend rarement, ce qui peut maintenir des replicas inutiles.

PodDisruptionBudget

Le cluster est régulièrement mis à jour (nœud par nœud). Un PDB garantit qu’un minimum de vos pods reste disponible pendant ces opérations :

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: web
spec:
  minAvailable: 1
  selector:
    matchLabels:
      app: web

Règles pratiques :

PDB sans replicas multiples = piège : avec replicas: 1 et minAvailable: 1, votre unique pod bloque la maintenance — et sera ultimement déplacé quand même. Un PDB accompagne toujours replicas: 2+ ;
minAvailable: 1 avec 2 replicas est le réglage simple et sain pour la plupart des applications web.

La checklist prod

	Objet	Effet
✅	`replicas: 2` minimum	Survit à la perte d’un pod ou d’un nœud
✅	`readinessProbe`	Pas de trafic vers un pod pas prêt
✅	HPA `min 2 / max N`	Absorbe les pics de charge
✅	PDB `minAvailable: 1`	Toujours au moins un pod pendant les maintenances
✅	Requests dimensionnées sur le monitoring	Ni gaspillage, ni OOMKill

L’exemple stack web complète assemble tout ça sur une application réelle.