Wenn die Anzahl containerisierter Services schneller wächst als das Plattform-Team, wird nicht Kubernetes selbst, sondern dessen Betrieb zum Engpass. Genau dieses Problem hat Generali gelöst – und den Fokus vom Cluster-Management auf das Applikations-Management verlagert.
Die Hauptgrenze zeigte sich nicht in der Performance, sondern im operativen Bereich. Das Microservices-Portfolio wuchs, Multi-Tenant-Szenarien kamen hinzu und damit auch manuelles Skalieren, uneinheitliche Sicherheitspraktiken und übermäßige Ressourcen-Reserven. Unterschiedliche Teams – unterschiedliche Standards, was zu einer instabilen Sicherheitslage führte und die Einhaltung von Compliance erschwerte. Kubernetes als Plattform funktionierte, aber der Betrieb begann, immer mehr Ingenieurszeit zu beanspruchen.
Die Entscheidung für Amazon EKS war naheliegend: ausgereifte Integration mit AWS und bereits vorhandene Erfahrung im Team. Der entscheidende Schritt war jedoch der Wechsel zum EKS Auto Mode, bei dem AWS das Management von Nodes, Updates, Add-ons und Teilen des Betriebsmodells übernimmt. Das ist ein Trade-off: Weniger Kontrolle über die Infrastruktur zugunsten von Konsistenz und weniger Toil. Im Gegenzug erhält man automatisches Skalieren, vereinheitlichte Umgebungen und integrierte Sicherheitspraktiken.
In der Praxis erforderte dies eine Anpassung der Prozesse. Auto Mode aktualisiert Nodes regelmäßig (inklusive Bottlerocket), was deren Neuerstellung bedeutet. Um Degradationen zu vermeiden, führte das Team Wartungsfenster ein und konfigurierte Pod Disruption Budgets sowie Node Disruption Budgets strikt. Architekturelle Einschränkungen wurden Teil der Strategie: Nur stateless Services, immutable Pods, Deployments via Helm, Skalierung über HPA. Secrets werden im AWS Secrets Manager mit Synchronisation über den External Secrets Operator verwaltet – ohne Einbettung in Manifeste. Das Netzwerkmodell wurde durch AWS Network Firewall mit Egress-Filterung nach SNI verstärkt, was typische Schwachstellen bei ausgehenden Verbindungen schließt. Die Sicherheit wurde durch GuardDuty (inklusive Runtime- und Audit-Signalen) und Inspector ergänzt, der Schwachstellen mit tatsächlich laufenden Containern abgleicht, nicht nur mit Images im Registry.
Ein separater Layer betrifft Observability und Finanzen. Über die Kombination aus CloudWatch und Managed Grafana erhielt das Team Einblicke nach Namespace und Projekten, ohne Grafana selbst betreiben zu müssen. Für die Kostenallokation werden Tags auf EKS-Ebene (Cluster, Namespace, Deployment) genutzt, was die Zuordnung der Ausgaben zu Business Units ermöglicht – kritisch in einer Multi-Tenant-Umgebung.
Das Ergebnis liegt weniger im reinen Performance-Gewinn, sondern in der Umverteilung der Aufwände. Operative Aufgaben (Patches, Upgrades, Skalierung) wurden in die Plattform verlagert, das Team konzentrierte sich auf die Unterstützung der Produktteams. Die Konsistenz der Sicherheit verbesserte sich, der übermäßige Ressourcenverbrauch sank, und die Incident-Untersuchung wurde durch Signal-Korrelation vereinfacht. Metriken werden nicht direkt offengelegt, aber laut Beschreibung handelt es sich um einen klassischen Fall von Toil-Reduktion und erhöhter Vorhersagbarkeit der Plattform durch Managed Kubernetes.