Plattform und Zuverlässigkeit

Kubernetes und Infrastructure as Code

Kubernetes und Terraform sind Werkzeuge. Ihre Komplexität lohnt sich nur, wenn Sie brauchen, was sie können. Wir richten sie ein, räumen sie auf oder sagen Ihnen, dass ein Managed Service besser passt, und warum.

Was wir tun

Klären, ob Kubernetes das richtige Werkzeug ist. Wir schauen auf Ihre Workloads, Ihr Team und Ihr Budget. Wenn ein Managed Service oder ein paar VMs reichen, sagen wir das und helfen Ihnen dorthin. Wenn Kubernetes passt, richten wir es ordentlich ein. Das heißt: gemanagte Control Plane, sinnvolle Node Pools, Network Policies, Workload Identity, Resource Limits und ein klarer Upgrade-Pfad.

Upgrades langweilig machen. Viele Cluster laufen auf alten Versionen, weil sie niemand anfassen will. Wir schreiben eine Upgrade-Strategie, testen sie in einem Staging-Cluster, räumen veraltete APIs ab und bringen Sie in einen festen Rhythmus. Danach ist ein Upgrade eine normale Aufgabe. Es hat eine Checkliste, einen Rollback-Plan und einen Verantwortlichen, und es kostet kein Wochenende.

Terraform schreiben, das man warten kann. Wir entwerfen und prüfen Module, die lesbar bleiben, statt clever zu sein. Sinnvolle Inputs, keine versteckte Magie und Tests, die in der CI laufen. Wir teilen den State so auf, dass Plans schnell bleiben und ein Fehler in einem Bereich keinen anderen kaputt machen kann. Bestehenden Code prüfen wir auch und sagen Ihnen, was bleiben kann. Nicht jedes alte Modul muss neu geschrieben werden, und ein Big-Bang-Refactoring von funktionierendem Terraform ist ein eigenes Risiko.

Die Lücke zwischen Code und Realität schließen. Drift entsteht, wenn jemand Produktion von Hand repariert und das Repository nie nachzieht. Wir finden ihn, holen ihn zurück in den Code und richten eine Erkennung ein, damit er früh auffällt. Wo sich kontinuierlicher Abgleich lohnt, ergänzen wir GitOps mit Argo CD oder Flux, sodass der Cluster immer dem Stand in Git entspricht. Wenn ein nächtlicher Plan und ein Pull-Request-Workflow reichen, hören wir dort auf.

Wie es meistens abläuft

Meist beginnen wir mit einem kurzen Review Ihrer Cluster und Ihres Infrastruktur-Codes. Wir führen Plans aus, lesen Module, prüfen Versionen und suchen nach Drift. Innerhalb von zwei Wochen bekommen Sie einen schriftlichen Bericht, was zu beheben ist, sortiert nach Risiko.

Dann begleiten wir Ihr Team bei der Umsetzung oder machen die erste Runde gemeinsam, meist über vier bis acht Wochen. Wir gehen, sobald Ihre Engineers ein Upgrade durchführen oder ein Modul ändern können, ohne uns zu brauchen.

Passt gut, wenn

  • Ihr terraform plan dauert so lange, dass ihn niemand mehr ausführt.
  • Ihre Cluster stimmen nicht mehr mit dem überein, was im Repository steht.
  • Kubernetes-Upgrades machen Angst, also schieben Sie sie immer wieder auf.
  • Sie wollen Kubernetes einführen und vorher eine zweite Meinung hören.

Häufige Fragen

Brauchen wir Kubernetes?
Viele Teams nicht. Wenn Sie ein paar Services mit gleichmäßigem Traffic betreiben, ist eine Managed-Plattform wie Cloud Run, App Engine, ECS oder schlicht ein paar VMs günstiger im Betrieb, und Sie finden leichter Leute dafür. Kubernetes lohnt sich, wenn Sie viele Services und mehrere Teams haben und Scheduling, Isolation und das Ökosystem wirklich brauchen.
GKE, EKS oder Kubernetes selbst betreiben?
Nehmen Sie eine gemanagte Control Plane, außer Sie haben einen guten Grund dagegen. GKE und EKS kümmern sich um die Control Plane und einen Großteil der Upgrade-Arbeit, und genau dort kosten selbst betriebene Cluster die meiste Zeit. Auf GKE nimmt Ihnen Autopilot auch das Node-Management ab, zum Preis von etwas Flexibilität.
Wie sollte man den Terraform State strukturieren?
Teilen Sie den State nach Umgebung und nach Änderungshäufigkeit auf, damit ein Plan nur anfasst, was er muss. Legen Sie ihn in ein Remote Backend mit Locking, etwa einen GCS- oder S3-Bucket. Vermeiden Sie eine riesige State-Datei, aber auch eine so feine Aufteilung, dass jede Änderung zehn davon betrifft.
Argo CD oder Flux?
Beide machen GitOps gut. Argo CD hat eine starke Web-Oberfläche und passt zu Teams, die den Sync-Status auf einen Blick sehen wollen. Flux ist schlanker und passt gut, wenn alles über Git und die CLI läuft. Die größere Frage ist, ob Sie kontinuierlichen Abgleich überhaupt brauchen, und die beantworten wir zuerst.

Sagen Sie uns, was nicht funktioniert.

Ein paar Sätze reichen. Wir antworten innerhalb eines Werktags, und das erste Gespräch ist kostenlos.