Planification de capacité d’Ingress Kubernetes avec exemples pratiques

Intro

Votre Ingress Kubernetes est la porte d’entrée de votre plateforme. S’il est sous-dimensionné ou mal configuré, les symptômes sont douloureux : erreurs 5xx intermittentes, expirations (timeouts) et pannes soudaines lors des pics de trafic. Ce guide propose une approche pratique et reproductible de la planification de capacité d’Ingress. Vous allez inventorier votre environnement, estimer la charge et la marge de sécurité, appliquer des réglages sûrs par défaut, valider par des tests de charge et préparer des étapes de reprise pour les défaillances courantes.

À la fin, vous aurez un canevas exécutable en staging puis en production pour garder un Ingress sain au fil de l’évolution du trafic.

1. Inventaire de l’environnement et des versions

Avant tout réglage, établissez un point de référence.

Exécutez les commandes suivantes pour capturer les versions et l’empreinte actuelle :

kubectl version --short
kubectl get ingressclass
kubectl get pods -A | grep -E "ingress|gateway"
kubectl top nodes
kubectl top pods -A | grep ingress
kubectl get ingress --all-namespaces | wc -l
kubectl get services --all-namespaces | wc -l
kubectl get endpoints --all-namespaces | wc -l

Consignez les résultats dans un tableau simple, versionné :

Pourquoi les endpoints comptent : la plupart des contrôleurs construisent en mémoire une table de routage et un pool d’upstreams. Plus il y a de règles Ingress, d’hôtes et d’endpoints, plus l’empreinte mémoire et le temps de rechargement augmentent.

Astuce : mettez à jour cet inventaire à chaque ajout de service ou mise à niveau du contrôleur.

2. Dimensionner correctement votre base

Partez d’une hypothèse de dimensionnement fondée sur le trafic et les objectifs de latence, puis définissez des requests et limits conservateurs que vous affinerez avec les données.

2.1 Estimer la concurrence et le RPS par pod

Utilisez une estimation rapide basée sur la loi de Little :

• concurrence = RPS × latence moyenne (en secondes)
• RPS par pod cible = RPS cluster souhaité / réplicas prévus

RPS (Requests Per Second) : nombre de requêtes traitées par seconde, indicateur clé de débit.

Exemple :

• Cible en régime établi : 2 000 RPS
• Latence moyenne de bout en bout : 100 ms (0,1 s)
• Concurrence estimée : 2 000 × 0,1 = 200 requêtes simultanées
• Ajoutez 30 % de marge : 260 simultanées
• Démarrer avec 4 pods Ingress : ~65 simultanées par pod

Si la taille moyenne des réponses est élevée ou si la terminaison TLS est activée, anticipez une consommation CPU plus forte par requête et dimensionnez en conséquence. TLS (Transport Layer Security) : protocole de sécurité qui chiffre les connexions réseau, ce qui ajoute du coût CPU.

2.2 Définir les resource requests et limits

Commencez par des requests légèrement au-dessus de votre usage p80 observé, et des limits suffisamment hautes pour absorber de courts pics sans étranglement (throttling) durable.

# Extrait de Deployment pour ingress-nginx
resources:
  requests:
    cpu: 300m
    memory: 512Mi
  limits:
    cpu: "2"
    memory: 2Gi

Après le déploiement, surveillez avec :

kubectl top pod -n ingress-nginx

Ajustez les requests vers votre p80 pour que le HPA réagisse fidèlement à la charge.

2.3 Réglages de performance Ingress-NGINX (points de départ sûrs)

Placez ces clés dans le ConfigMap du contrôleur et affinez ensuite :

# ConfigMap ingress-nginx
worker-processes: "auto"
worker-connections: "16384"
keep-alive: "75"
keep-alive-requests: "1000"
proxy-read-timeout: "60s"
proxy-send-timeout: "60s"
proxy-body-size: "16m"
upstream-keepalive-connections: "64"

Notes :

• worker-processes en auto permet à NGINX d’exploiter tous les cœurs CPU.
• worker-connections fixe le maximum de connexions concurrentes par worker. Combiné aux limites de descripteurs de fichiers, cela borne la concurrence totale.
• keep-alive réduit le coût des handshakes TLS et TCP pour les appels répétés.

Appliquez et observez les journaux du contrôleur pour confirmer un rechargement propre.

2.4 Mise à l’échelle horizontale des pods (CPU et mémoire)

Privilégiez autoscaling/v2 pour utiliser plusieurs métriques. HPA (Horizontal Pod Autoscaler) : mécanisme Kubernetes qui ajuste automatiquement le nombre de pods en fonction de métriques (CPU, mémoire, etc.).

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: ingress-nginx-controller
  namespace: ingress-nginx
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: ingress-nginx-controller
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  - type: Resource
    resource:
      name: memory
      target:
        type: Utilization
        averageUtilization: 75

Ajoutez un PodDisruptionBudget (PDB) pour maintenir la disponibilité pendant la maintenance :

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: ingress-nginx-pdb
  namespace: ingress-nginx
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app.kubernetes.io/name: ingress-nginx

Augmentez la résilience en répartissant les réplicas :

# À ajouter dans le spec du Deployment
spec:
  template:
    spec:
      topologySpreadConstraints:
      - maxSkew: 1
        topologyKey: topology.kubernetes.io/zone
        whenUnsatisfiable: ScheduleAnyway
        labelSelector:
          matchLabels:
            app.kubernetes.io/name: ingress-nginx
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchLabels:
                app.kubernetes.io/name: ingress-nginx
            topologyKey: kubernetes.io/hostname

3. Valider par la charge et observer

Prouvez votre configuration dans des conditions réalistes avant de lui faire confiance en production.

3.1 Exécuter un test de charge ciblé

Choisissez un chemin représentatif qui exerce le comportement amont typique (taux de cache hit, auth, taille de payload). Utilisez hey pour un test rapide :

# 10 000 requêtes avec 100 connexions concurrentes
hey -n 10000 -c 100 https://ingress.example.com/

Pour aligner la concurrence avec votre estimation, reprenez le calcul de la section 2.1. Pour les tests de pic, augmentez la concurrence progressivement sur 1 à 3 minutes et observez la mise à l’échelle.

Outils possibles :

• hey : benchmark HTTP simple
• vegeta : tests pilotés par taux et attaques
• k6 : scénarios scriptés et assertions de seuils

3.2 Observer le système pendant le test

Exécutez en parallèle :

watch -n 2 kubectl top pods -n ingress-nginx
watch -n 2 kubectl get hpa -n ingress-nginx
kubectl logs -n ingress-nginx deploy/ingress-nginx-controller -f

Signaux clés à suivre :

• Taux d’erreurs : 5xx depuis Ingress, 499 (annulées client) et 5xx amont
• Latence : p50, p95, p99 ; un p99 soutenu > 500 ms déclenche souvent un scale-out
• Étranglement CPU et événements OOM sur les pods du contrôleur
• Décisions HPA et comportement de stabilisation
• Métriques de connexion : active, accepted, handled (si vous scrappez les métriques NGINX)

Définissez des alertes sur les valeurs extrêmes, pas seulement les moyennes. Par exemple, alertez si le taux d’erreurs > 1 % pendant 5 minutes ou si la p99 > 500 ms pendant 5 minutes.

4. Pannes courantes et reprise rapide

Utilisez ces schémas pour détecter et corriger rapidement.

1. Affamement de ressources (CPU throttling ou OOMKilled)

• Symptômes : latence élevée, pics de 5xx, CrashLoopBackOff, journaux avec throttling.
• Vérifier : kubectl describe pod ... | grep -i -E "throttling|oom".
• Corriger : augmenter les limits, aligner les requests sur le p80, augmenter les réplicas. Exemple :
• Augmenter temporairement la limite CPU à 3 cœurs et la mémoire à 3 GiB.
• En cas d’OOM, réduire le nombre de routes par contrôleur (sharder par ingressClass ou namespace) ou augmenter la mémoire.

1. HPA mal configuré (yoyo ou lenteur de scaling)

• Symptômes : montées/descentes fréquentes en quelques minutes, ou ajout lent de pods lors des pics.
• Vérifier : kubectl describe hpa pour des événements comme "FailedGetResourceMetric".
• Corriger : ajouter stabilisation et limites de taux :

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
spec:
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 60
      policies:
      - type: Percent
        value: 100
        periodSeconds: 60
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
      - type: Percent
        value: 50
        periodSeconds: 60

1. Problèmes TLS et certificats

• Symptômes : échecs de handshake, erreurs type 495/525, pic CPU.
• Vérifier : kubectl get secrets -n ingress-nginx pour les secrets TLS ; openssl s_client -connect host:443 pour inspecter le cert.
• Corriger : confirmer les renouvellements cert-manager ; activer la réutilisation et les caches de session via ConfigMap ; revenir au secret précédent fonctionnel si besoin.

1. Épuisement des connexions (nœud ou NGINX)

• Symptômes : timeouts lors des pics, chutes de SYN backlog, conntrack nœud saturé ou worker_connections NGINX dépassé.
• Vérifier : journaux du contrôleur ; métriques conntrack du nœud ; limites de connexion du load balancer cloud.
• Corriger : augmenter worker-connections NGINX, augmenter les réplicas, ou répartir le trafic sur plusieurs IngressClass. Si les limites au niveau nœud sont atteintes, répartissez les pods sur plus de nœuds.

1. Régressions de configuration ou de version

• Symptômes : échec de readiness du contrôleur, 404 sur routes valides, redirections inattendues.
• Vérifier : kubectl rollout status deploy/ingress-nginx-controller -n ingress-nginx et journaux pour erreurs de config.
• Corriger : rollback rapide :

kubectl rollout undo deployment/ingress-nginx-controller -n ingress-nginx

Pour une régression de ConfigMap, revenez au commit IaC précédent et réappliquez.

Conservez toujours vos manifestes en gestion de versions et exportez un instantané des Ingress, Services et ConfigMaps avant les changements majeurs.

5. Liste d’opérations et seuils d’alerte

Exécutez cette boucle légère pour garder une capacité saine et prévisible.

• Hebdomadaire : passez en revue kubectl top pods -n ingress-nginx et comparez aux cibles HPA.
• Mensuel : validez les bornes HPA (minReplicas, maxReplicas) par rapport aux tendances de trafic.
• Après chaque changement de config ou de version : lancez un court test de charge et confirmez les SLO d’erreurs et de latence.
• Certificats : surveillez l’expiration et l’auto-renouvellement.
• Chaos et bascule : drainez un nœud une fois par trimestre pour vérifier le PDB et les règles de répartition.
• Documentation : mettez à jour votre feuille de capacité avec les requests/limits, réplicas et derniers résultats de test.

Seuils d’alerte suggérés et actions :

Mise en pratique : un chemin rapide

1. Inventoriez vos versions, contrôleur, nœuds et usage actuel.
2. Estimez concurrence et RPS par pod ; ajoutez 30 % de marge.
3. Appliquez des requests/limits conservateurs et des valeurs par défaut dans le ConfigMap NGINX.
4. Activez le HPA avec CPU et mémoire, plus un comportement de stabilisation.
5. Ajoutez un PDB et répartissez les réplicas entre nœuds et zones.
6. Exécutez un test de charge représentatif et suivez erreurs, latence et ressources.
7. Itérez les réglages et documentez le nouveau point de référence.

Conclusion

La planification de capacité d’Ingress n’est pas un exercice ponctuel. Traitez-la comme une petite boucle opératoire : mesurer, formuler une hypothèse, changer, vérifier. Démarrez par un inventaire explicite, traduisez les objectifs de trafic en concurrence et RPS, appliquez des réglages sûrs et validez sous charge. Ajoutez des garde-fous avec HPA, PDB et répartition des réplicas, et gardez un chemin de retour clair pour les mises à niveau et changements de configuration. Avec ce playbook, vous pouvez monter en charge en confiance, éviter les goulets d’étranglement surprises et garder la porte d’entrée de votre cluster rapide et fiable.