Ingress Controller als Single Point of Failure

Wir hatten HA für jeden Service. Außer für das eine Ding, das den Traffic zu allen routet.

Das Setup:

• 20 Services mit je 3+ Replicas
• Multi-AZ-Deployment
• Pod Disruption Budgets
• NGINX Ingress Controller: 1 Replica

Der Incident:

• Ingress-Controller-Pod OOMKilled
• 30 Sekunden bis zur Neuplanung
• Ohne laufenden NGINX-Pod hatte der Cloud-Load-Balancer keine gesunden Targets — Clients bekamen Verbindungsfehler und 503er vom LB, nicht einmal einen sauberen 502
• Jeder Service dahinter war auf einen Schlag unerreichbar

Warum nur 1 Replica?

• „Das ist nur Infrastruktur, die fällt nie aus“
• Default-Wert im Helm-Chart: 1
• Niemand hat ihn geändert

Der Fix:

controller:
  replicaCount: 3
  affinity:
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        - labelSelector:
            matchLabels:
              app.kubernetes.io/name: ingress-nginx
          topologyKey: kubernetes.io/hostname

Außerdem:

• PodDisruptionBudget mit minAvailable: 2
• Saubere Resource Requests/Limits
• HPA für Traffic-Spitzen

Es ist derselbe blinde Fleck wie bei Replicas, die alle in einer Availability Zone landeten: Redundanz, die Sie nicht verifiziert haben, ist keine Redundanz.

Lektion: Ihr Ingress Controller IST Ihre Verfügbarkeit. Behandeln Sie ihn so.

---

Incidents wie dieser sind vermeidbar. Unser AWS Managed Services-Team überwacht Kundenumgebungen 24/7 mit KI-gestütztem Monitoring und Senior Engineers am Pager — damit Geschichten wie diese im Archiv bleiben.