Von Google Cloud zu eigenem Kubernetes: Warum ich umgezogen bin

Es gibt Entscheidungen, die man lange vor sich herschiebt. Die Migration meiner Infrastruktur von Google Cloud Platform zu einem selbst verwalteten Kubernetes-Cluster auf einem Netcup-Server war so eine. Zu viel Aufwand, zu viel Risiko, zu wenig Zeit — die üblichen Ausreden. Jetzt, nachdem ich es durchgezogen habe, kann ich sagen: Es hat sich gelohnt. Aber es war kein Spaziergang.

Wie es angefangen hat

Meine Setup auf GCP war klassisch gewachsen. Ein paar Cloud Run Services hier, eine Cloud SQL Instanz da, Secrets im Secret Manager, alles schön verteilt über verschiedene Google-Dienste. Funktioniert hat es — solange man nicht zu genau auf die Rechnung schaute.

Das eigentliche Problem war nicht der Preis allein. Es war die Fragmentierung. Jede App hatte ihre eigene Konfiguration, jedes Deployment seinen eigenen Workflow. Änderungen wurden manuell angestoßen, Rollbacks waren umständlich, und ein Gesamtüberblick über den Zustand aller laufenden Services? Den gab es nicht wirklich.

Der entscheidende Anstoß: ein Kollege namens Paul

Ehrlich gesagt wäre ich ohne fremde Hilfe vermutlich nie über das Stadium “interessant, aber zu kompliziert” hinausgekommen. Es war Paul, ein Kollege aus einer Firma für die ich aktuell arbeite, der das entscheidende Zünglein an der Waage war.

Paul hatte genau dieses Setup bereits produktiv aufgebaut und betrieben: k3s statt k8s und ArgoCD, der ganze Stack. Als ich ihm von meinem GCP-Frust erzählte, hat er mir gleich die richtigen Fragen gestellt und die entscheidenden Zusammenhänge erklärt, was mich sofort hellhöring gemacht und recht schnell dann auch gepackt haben.

Ich war am Anfang wirklich ein blutiger Anfänger was Kubernetes angeht. Ehrlich gesagt fühle ich mich immer noch so — Kubernetes ist ein Thema, bei dem man merkt wie tief der Kaninchenbau wirklich geht, je weiter man einsteigt. Aber genau das ist auch das Spannende daran.

Was Paul mir vor allem mitgegeben hat: Man muss nicht alles verstehen um produktiv zu gehen. Ein sauber aufgesetztes Setup läuft stabil, auch wenn man nicht jeden internen Mechanismus von etcd oder dem Scheduler kennt. Der Einstieg ist steil, aber die Kurve flacht sich ab und danach ist der Alltag bisher überraschend entspannt.

Was mich zu Kubernetes gebracht hat

Kubernetes hat einen Ruf: kompliziert, überdimensioniert, enterprise-lastig. Und für einen einzelnen Entwickler oder eine kleine Agentur stimmt das — wenn man es falsch angeht.

Was mich überzeugt hat, war k3s in Kombination mit ArgoCD. k3s ist eine abgespeckte Kubernetes-Distribution, die auf einem einzigen Server läuft und trotzdem alle wesentlichen Features mitbringt. ArgoCD ist ein GitOps-Tool, das den Cluster mit einem Git-Repository synchronisiert. Das bedeutet: Der gewünschte Zustand der gesamten Infrastruktur liegt als YAML in einem privaten GitHub-Repository. Was im Repo steht, läuft im Cluster. Punkt.

Dieser Ansatz hat einen Namen: GitOps. Und er hat meine Art zu arbeiten grundlegend verändert.

Der neue Stack im Überblick

Der Umzug hat meine gesamte Infrastruktur auf einem einzigen Netcup-Server konsolidiert:

• k3s als Kubernetes-Distribution
• ArgoCD für automatisches Deployment aus Git
• Traefik als Ingress Controller (bereits in k3s enthalten)
• cert-manager für automatische TLS-Zertifikate via Let’s Encrypt
• GitHub Actions zum Bauen und Pushen der Docker-Images
• GitHub Container Registry als private Image Registry
• Argo CD Image Updater für automatische Updates wenn ein neues Image verfügbar ist

Alle meine Projekte laufen darauf: tobeworks.de, logic-moon.de, eine Flask-API, und weitere Anwendungen.

Die ehrlichen Vorteile

Kosten. Ein Netcup-Server mit 8 vCores, 16 GB RAM und 512 GB NVMe kostet einen Bruchteil dessen, was ich bei GCP für vergleichbare Ressourcen gezahlt habe. Bei GCP zahlt man für jeden einzelnen Dienst separat — Cloud Run, Cloud SQL, Secret Manager, Load Balancer, Egress-Traffic. Das summiert sich schnell.

Kontrolle. Alles liegt in meinem Git-Repository. Jede Konfigurationsänderung ist ein Commit. Jedes Deployment ist nachvollziehbar. Wenn etwas schiefgeht, ist ein git revert oft die schnellste Lösung.

Einheitlichkeit. Egal ob es sich um eine Astro-Site, eine Flask-API oder ein WordPress-Projekt handelt — der Deployment-Workflow ist immer gleich. Code schreiben, pushen, GitHub Actions baut das Docker-Image, ArgoCD deployed es automatisch.

Unabhängigkeit. Keine Vendor-Lock-in. Kein proprietäres Deployment-Format, keine Google-spezifischen Konfigurationen. Was heute auf Netcup läuft, kann morgen auf Hetzner, DigitalOcean oder einem eigenen Server laufen.

Die ehrlichen Nachteile

Ich wäre unehrlich, wenn ich nur die Vorteile nennen würde.

Der initiale Aufwand ist erheblich. cert-manager, Traefik, ArgoCD, Image Updater — alles will konfiguriert, verstanden und debuggt sein. Die ersten Tage waren geprägt von YAML-Fehlern, falschen Port-Konfigurationen und der Frage warum ein Zertifikat nicht ausgestellt wird. Wer das erste Mal mit Kubernetes arbeitet, sollte sich Zeit einplanen.

Man ist selbst verantwortlich. Bei GCP kümmert sich Google um Patches, Updates und die Verfügbarkeit der Infrastruktur. Bei einem selbst verwalteten Server liegt das alles bei einem selbst. Backups, Monitoring, Security-Updates — das muss man aktiv angehen.

Build-Zeiten können schmerzhaft lang sein. Der kostenlose GitHub Actions Runner ist praktisch, aber kein Rennpferd. Wer Astro mit Sharp für Bildkomprimierung einsetzt, wird das deutlich merken — ein Build kann je nach Bildmenge mehrere Minuten dauern. Das ist kein Blocker, aber es verändert den Rhythmus: Man pusht, macht sich einen Kaffee, und hofft dass in der Zwischenzeit keine weiteren Änderungen nötig sind. Wer schnellere Build-Zeiten braucht, kann auf selbst gehostete Runner oder bezahlte GitHub-Pläne ausweichen — aber das ist ein weiterer Kostenpunkt den man einkalkulieren sollte.

Kubernetes ist nicht für jeden Use Case sinnvoll. Für eine einzelne statische Website ist das gesamte Setup Overkill. Der Break-Even liegt irgendwo bei mehreren Anwendungen, die kontinuierlich weiterentwickelt werden und von einem einheitlichen Deployment-Workflow profitieren.

Was ich anders machen würde

Den Setup mit Helm von Anfang an angehen, statt Manifeste manuell zu patchen. ArgoCD über Helm zu installieren hat viele Probleme gelöst, die ich mir durch die manuelle Installation eingehandelt hatte.

Außerdem: früher auf kustomization.yaml setzen. Der Argo CD Image Updater unterstützt nur Kustomize oder Helm als Source-Typ — plain YAML-Verzeichnisse werden übersprungen. Das ist eine Einschränkung, die einem erst auffällt wenn man bereits alles aufgebaut hat.

Fazit

Der Umzug war kein einfacher Schritt, aber der richtige. Was ich gewonnen habe: einen klaren, reproduzierbaren Deployment-Workflow, vollständige Kontrolle über meine Infrastruktur, und deutlich niedrigere laufende Kosten.

Was ich investiert habe: Zeit, Nerven, und mehr YAML als mir lieb ist.

Aber hier ist das Ding, das ich vorher nicht erwartet hätte: Wenn das Setup einmal steht, ist der Alltag wirklich einfach. Code schreiben, pushen — fertig. ArgoCD und der Image Updater erledigen den Rest. Keine manuellen Deployment-Schritte, kein Klicken in irgendwelchen Cloud-Konsolen. Das ist der Punkt an dem sich der initiale Aufwand bezahlt macht.

Wer mehrere Projekte betreibt, gerne die Kontrolle über seine Infrastruktur hat, und bereit ist, einmal in den sauren Apfel zu beißen — für den ist ein eigener Kubernetes-Cluster mit k3s und ArgoCD eine ernstzunehmende Alternative zur Public Cloud. Für alle anderen: Cloud Run und Co. sind aus gutem Grund beliebt.

Und falls ihr jemanden kennt der das schon gemacht hat: Fragt ihn. Ein Paul im richtigen Moment ist mehr wert als drei Wochen Dokumentation lesen.