300+ Kubernetes Cluster in Produktion auf vier Clouds, ohne Lärm.

Fall 1 · Hydrolix · 2024 bis heute

10×

schnellere Deployments

Von kubectl edit zu GitOps mit ArgoCD

Problem

Jeder Cluster wurde von Hand mit kubectl edit geändert. Nichts war nachvollziehbar, ein Fix in einer Region konnte in einer anderen unbemerkt überschrieben werden, und der Infrastrukturcode war mit den Anwendungsmanifesten verflochten.

Mein Beitrag

Ich schlug vor, beides zu trennen und auf GitOps mit ArgoCD umzustellen. Das Team war ausgelastet, also vereinbarten wir, dass ich ausserhalb des Bereitschaftsdienstes etwa 30 % meiner Zeit darauf verwende. Ich baute einen Proof of Concept, zeigte, dass er funktioniert, und bekam die Freigabe.

Ergebnis

Das Onboarding eines Kunden sank von etwa zwei Stunden auf 15 bis 20 Minuten, jede Änderung ist nachvollziehbar, und es wurde die Basis für spätere Automatisierung wie selbstheilende Runbooks.

• ArgoCD
• Kubernetes
• Kustomize
• Pulumi
• GitHub Actions

Fall 2 · Hydrolix · 2024 bis heute

Flottenweit

durch Health Checks gesteuerte Rollouts

Progressive Delivery Plattform

Problem

Upgrades über die ganze Flotte brauchten Wochen manueller Abstimmung, ohne sicheren Weg, in Batches zu arbeiten, zu wiederholen oder zurückzurollen.

Mein Beitrag

Ich habe gemeinsam eine Plattform auf Argo Workflows gebaut, mit regionaler Steuerung, automatischen Health Checks vor und nach jedem Batch, einer Live Ansicht des Workflows und geplanten Rollouts.

Ergebnis

Rollouts werden durch Health Checks gesteuert und lassen sich mit einem Klick zurückrollen. Es wurde zum Standardweg für Upgrades der Flotte.

• Go
• React
• Argo Workflows
• ArgoCD
• Prometheus

Fall 3 · Hydrolix · 2024 bis heute

20 bis 30

Vorfälle pro Monat beseitigt

Automatisierte OOM Behebung

Problem

Dieselben Out of Memory Alarme weckten jeden Monat den Bereitschaftsingenieur, und der Fix war immer dieselbe manuelle Änderung.

Mein Beitrag

Ich entwarf ein System, das die Signale liest und die passende Änderung über GitOps vorschlägt.

Ergebnis

Über 20 Stunden Routinearbeit und 20 bis 30 Vorfälle pro Monat verschwanden aus der Rotation.

• Kubernetes
• Prometheus
• ArgoCD
• Go
• Pulumi

Fall 4 · Hydrolix · 2024 bis heute

30+

neu überwachte Umgebungen

Ein langsames Grafana, das eine Monitoring Lücke zeigte

Problem

Die Grafana Dashboards eines Kunden wurden sehr langsam. Seine Abfragen sahen normal aus, und alle Dashboards waren betroffen. df -h im Datenbank Pod zeigte das Volume zu 95 % voll. Es zeigte auch eine grössere Lücke: Diese kundennahen Grafana Instanzen waren nicht Teil unseres Monitorings.

Mein Beitrag

Ich vergrösserte das Volume mit dem Postgres Operator, setzte dann Knoten einzeln auf cordon und startete die Pods neu, damit es in der richtigen Grösse zurückkam. Danach erweiterte ich unser ArgoCD Setup mit dem App of Apps Muster auf die Grafana Instanzen, fügte Alarme für Speicherplatz und Instanzzustand hinzu und schrieb die RCA und eine Anleitung, wie Prometheus in ihren Infrastrukturcode kommt.

Ergebnis

In einer Bereitschaftsschicht behoben. Prometheus deckt jetzt über 30 Umgebungen ab, die kein Monitoring hatten, sodass uns solche Probleme alarmieren, bevor ein Kunde sie bemerkt.

• Grafana
• Prometheus
• PostgreSQL
• ArgoCD
• Kubernetes

Fall 5 · Hydrolix · 2024 bis heute

Automatisiert

Erweiterung der Bucket Kapazität

Black Friday Kapazität, danach automatisiert

Problem

An einem Black Friday erreichten Kunden Buckets und der Datenbankkatalog ihre Lese und Schreibgrenzen. Ingenieure in jeder Region hatten Bereitschaft und erweiterten den ganzen Tag von Hand die Kapazität, damit der Katalog nicht aufblähte.

Mein Beitrag

Danach schlug ich eine Pipeline und Änderungen am Infrastrukturcode vor, um diese Erweiterung zu automatisieren, baute einen Proof of Concept und stellte ihn vor.

Ergebnis

Das Team genehmigte die Migration, sodass ein Spitzentag nicht mehr von manueller Arbeit der Ingenieure in jeder Region abhängt.

• Infrastructure as Code
• CI Pipelines
• Kapazitätsplanung
• Bereitschaftsdienst

Fall 6 · Triggle Spain · 2023 bis 2024

27%

niedrigere AWS Plattformkosten

AWS Kostenoptimierung und das EKS Upgrade

Problem

Ressourcen waren überdimensioniert, und Cluster liefen auf einer alten Version im kostenpflichtigen erweiterten Support, zum sechsfachen Standardpreis.

Mein Beitrag

Ich führte ein Team von 3 durch Autoscaling Richtlinien, Cleanup Jobs und Right Sizing und aktualisierte dann 4 Cluster von 1.24 auf 1.29, mit Terraform und Velero Backups.

Ergebnis

Die Plattformkosten sanken um 27 % und die Kosten für erweiterten Support um 82,5 %, und die Plattform skaliert besser.

• AWS
• EKS
• Terraform
• Velero
• CAST AI

Fall 7 · Triggle Spain · 2023 bis 2024

1 Wochenende

um die Produktions CI wiederherzustellen

Produktions Jenkins nach einem fehlgeschlagenen Upgrade wiederhergestellt

Problem

Beim Testen des EKS Upgrades auf Clustern mit dem Label dev stellte ich fest, dass dort die Produktions Pipeline von Jenkins lief. Das Upgrade zerstörte Jenkins und löschte sein Volume, und Produktions Deployments standen still.

Mein Beitrag

Ich verbrachte das Wochenende damit, das Volume aus dem Velero Backup wiederherzustellen und Jenkins zu retten. Ausserdem verschob ich es auf den Management Cluster der Produktion, wo es hingehörte.

Ergebnis

Die Produktions CI lief nach dem Wochenende wieder. Seitdem prüfe ich, was wirklich auf einem Cluster läuft, egal was das Label sagt, und mache vor jeder zerstörenden Änderung ein frisches Backup.

• Jenkins
• EKS
• Velero
• AWS
• Kubernetes