Ich brauchte Kubernetes nicht – und Sie wahrscheinlich auch nicht

Warum ich Kubernetes verlassen und mich für Google Cloud Run entschieden habe

Hintergrund zur Einführung von Kubernetes

• Bei der 2013 gestarteten Online-3D-Editing-Plattform Clara.io wurde die Infrastruktur mit Bare-Metal-Servern optimiert, doch die Verwaltung und Überwachung der Hardware erforderte übermäßig viel Aufwand.
• 2018 fiel beim Projekt Threekit.com die Wahl auf Kubernetes. Damals etablierten Azure, AWS und Docker Kubernetes als Standard, wodurch es zum Mainstream wurde.

Die Grenzen von Kubernetes

1. Kostenproblem:

   • Die Grundkosten für den Aufbau eines Clusters sind hoch, etwa durch Management-Nodes und redundante Cluster-Konfigurationen.
   • Wegen langsamer Auto-Scaling-Reaktionen ist ein Overprovisioning der Services nötig, wodurch Kosten für ungenutzte Ressourcen entstehen.

2. Schwierige Verwaltung von Workloads:

   • Das Scheduling von Jobs ist komplex, und auch der eingebaute Scheduler sowie Argo sind bei großen Job-Mengen ineffizient.

3. Überlastung durch Komplexität:

   • Der große Funktionsumfang macht selbst einfache Aufgaben unnötig kompliziert.
   • Für den Betrieb von Kubernetes wird dediziertes DevOps-Personal benötigt, was die Kosten weiter erhöht.

Wechsel zu Google Cloud Run

Cloud Run ersetzt die Komplexität von Kubernetes und bietet eine vereinfachte, kosteneffiziente Umgebung.

Neues Setup

• Docker-Container-basierte Infrastruktur:
  • Einschließlich automatisch skalierender Services und Containern für lang laufende Jobs.
  • Cloud Run automatisiert Container-Deployment, Skalierung, Ausfallmanagement und die Ausführung von Jobs.

Vorteile von Cloud Run

1. Kosteneffizienz:

   • Abgerechnet wird nach CPU- und Speichernutzungszeit.
   • Für inaktive Services fallen keine Kosten an.
   • Beispiel: Die Website Web3D Survey kann mit 500.000 Zugriffen pro Monat für 4 US-Dollar pro Monat betrieben werden.

2. Schnelles und stabiles Auto-Scaling:

   • Die Skalierung erfolgt innerhalb weniger Sekunden und damit schneller als bei Kubernetes.
   • Lastspitzen können zügig bewältigt werden.

3. Kein Verwaltungsaufwand für Kubernetes:

   • Cloud Run basiert auf Googles Borg, sodass kein Kubernetes-Cluster verwaltet werden muss.

4. Einfache asynchrone Jobs:

   • Mit Cloud Run Tasks lassen sich automatische Wiederholungen und die Ausführung großer Job-Mengen unkompliziert umsetzen.

Potenzielles Problem von Kubernetes: Cluster-Lock-in

• Wenn man sich auf Kubernetes-Funktionen verlässt, werden die Integration oder Erweiterung externer Ressourcen außerhalb des Clusters schwieriger.
• Dadurch entsteht eine Abhängigkeit von einer bestimmten Infrastruktur, was Skalierung und Migration komplexer und teurer macht.

Häufige Fragen zur Nutzung von Cloud Run

„Macht Ihnen die Abhängigkeit von GCP keine Sorgen?“

• Mit einem Docker-basierten Setup ist eine Migration in eine andere Cloud wie AWS in etwa einer Woche möglich.
• Realistisch gesehen wird der Cloud-Anbieter außerhalb politischer Faktoren nur selten gewechselt.

„Ist Cloud Run am Ende nicht auch nur Managed Kubernetes?“

• Cloud Run nutzt die Knative-Schnittstelle, läuft aber nicht auf Kubernetes, sondern auf Googles Borg.
• Es beseitigt die Komplexität von Kubernetes und bietet eine vereinfachte Schnittstelle.

Nachteile des aktuellen Workflows

1. Unbequeme Verwaltung von Service-Namen:

   • Für konsistentes Konfigurationsmanagement lokal und auf dem Server ist eine Abstraktionsschicht nötig.
   • Die Namensverwaltungsfunktionen von Kubernetes fehlen.

2. Fehlende Emulation für Cloud Run Task:

   • Für die lokale Entwicklung von Jobs fehlt eine einfache Emulationsumgebung, einschließlich Erfassung und Nachverfolgung der Log-Ausgabe.

Fazit

• Cloud Run ist die optimale Lösung in Bezug auf Kosten, Geschwindigkeit, Skalierbarkeit und Vereinfachung
• Für Großunternehmen oder bei komplexen Anforderungen kann Kubernetes sinnvoll sein,
• bei Projekten, bei denen Einfachheit und Effizienz entscheidend sind, ist Cloud Run jedoch deutlich praxisnäher
• PS: Man könnte die Probleme vielleicht durch zusätzliche Erweiterungen für Kubernetes lösen, doch das würde die Komplexität nur weiter erhöhen, und ich möchte nicht von einer Kubernetes-Umgebung abhängig sein, die über einfache Anforderungen hinausgeht.

[blurblah]

Wo soll es schon eine silver bullet geben. Man muss es eben passend zur jeweiligen Situation gut einsetzen, haha.
Wenn man Kubernetes nur deshalb unkritisch einführt, weil es gerade angesagt ist, kann das sehr anstrengend werden. Trotzdem halte ich es in Umgebungen mit etwas größerem Maßstab für ein gutes Werkzeug.
Selbst wenn man es einführt: Wenn es bei der Einführung bleibt, wird man es am Ende nicht richtig nutzen können.
Und wie bei jedem Werkzeug gilt: Es kann die Bedürfnisse von Entwicklern oder Nutzern nie zu 100 % erfüllen, deshalb scheint mir ein angemessenes Maß an Automatisierung unerlässlich zu sein.

[bungker]

Sobald Kubernetes einmal eingerichtet ist, bleibt nur noch das süße Nichtstun übrig ... seufz

[riki3]

Kubernetes ist mein Broterwerb, und es gab eine Zeit, in der ich glaubte, das sei die richtige Antwort.
Mit der Zeit ertappe ich mich jedoch immer häufiger dabei, wie ich viele Probleme erlebe und Zeit verschwende.

Anderen empfehle ich k8s, aber für meinen eigenen Service würde ich es wohl nicht einsetzen. Nicht nur k8s – ich bin einfach auch Container insgesamt leid.

[joon14]

Wenn man AWS nutzt, kann man dann davon ausgehen, dass es ECS ähnelt?

[tujuc]

Ja, genau das ist es. :)

[eclipsense]

Es ist eher falsch, Kubernetes nicht richtig nutzen zu können; zu sagen, Kubernetes sei deshalb nicht besonders, ist etwas schwierig.

[tujuc]

Ich denke ähnlich wie der Autor.
Unser Unternehmen ist noch nicht groß genug, um kube einzusetzen.

Ich dachte wohl nur selbst, dass alle Entwickler mit Kube arbeiten und es verwalten können würden.
Es hat sich als besser erwiesen, eine Infrastruktur aufzubauen und Leitlinien bereitzustellen, damit auch Entwickler unter dem Durchschnittsniveau des Unternehmens Probleme lösen können...

[doolayer]

???: Ich brauchte keine KI, und ihr wahrscheinlich auch nicht.

[ilbanin00]

Jedes Produkt bringt gewisse Trade-offs mit sich.

[bbulbum]

Wenn man einen managed Service nutzt, hatte ich nicht wirklich das Gefühl, dass die Verwaltung schwierig wäre,,
Jedes Tool ist nützlich, wenn man es in einem angemessenen Rahmen einsetzt, aber bei Kubernetes scheint besonders häufig kritisiert zu werden, dass „komplexe Konfigurationen möglich sind“.

[tujuc]

Da man damit fast alles so bauen kann, wie man es selbst möchte ... :) Wahrscheinlich liegt es daran, dass es oft unnötig komplex eingesetzt wird, hahaha ...

[GN⁺]

Hacker-News-Kommentare

• Es wird Unmut über „Cloud-Technologie“ geäußert und erwähnt, dass bei der Nutzung von Kubernetes viel Zeit dafür draufgeht, YAML-Dateien zu bearbeiten und Fehler zu beheben. Es wird die Ansicht vertreten, Cloud-Integrationen vermeiden und Server lieber direkt selbst einrichten zu wollen.

• Kubernetes verursacht neben DevOps- und Verwaltungsaufwand auch erhebliche Infrastrukturkosten. Es wird vorgeschlagen, dass die Nutzung von Managed Kubernetes eines Cloud-Anbieters effizienter ist.

• Es wird erklärt, dass Kubernetes kein Tool für Container-Orchestrierung, sondern ein Tool zum Aufbau eines Computerclusters ist; wenn man keinen Cluster braucht, muss man Kubernetes nicht verwenden.

• Es wird betont, dass übermäßige Investitionen in DevOps zurückgehen, und ein kritischer Blick auf Kubernetes geteilt. Für kleine Startups kann auch ein einzelner Server ausreichen.

• Als Punkte, auf die man bei der Nutzung von Cloud Run achten sollte, werden Begrenzungen bei TCP-Verbindungen, die Wahl der Laufzeitumgebung und Einstellungen für Autoscaling genannt.

• Cloud Run eignet sich für kleine Startups, allerdings wird darauf hingewiesen, dass grundlegende Elemente einer Sicherheitsarchitektur wie Firewall-Kontrollen fehlen. Es wird erklärt, dass man letztlich eine VPC benötigen wird.

• Es wird argumentiert, dass ein Vergleich von Google Cloud Run und Kubernetes nicht fair sei, und die jeweiligen Vor- und Nachteile werden erläutert. Dabei wird hervorgehoben, dass Kubernetes für komplexe Aufgaben geeignet ist.

• Es wird erklärt, dass Kubernetes eine steile Lernkurve hat, bei angemessenem Einsatz aber ein leistungsstarkes Tool ist.

• Es wird der Kritik an Kubernetes nicht zugestimmt, und es wird betont, dass man beim Deployment komplexer Apps die Kubernetes-API brauchen kann.

• Es wird erklärt, dass die Komplexität von Kubernetes vor allem aus Aufgaben der Systemadministration entsteht, während Kubernetes selbst stabil ist.

• Es wird darauf hingewiesen, dass IaC und CM eigentlich Konfigurationen reduzieren und die Verwaltung erleichtern sollten, in der Praxis aber mehr Aufwand erfordern. In vielen Fällen ist Kubernetes nicht nötig, und wichtiger ist ein guter Systemadministrator.