Ein Leitfaden für alle, die Kubernetes nicht mögen

Ein kritischer Leitfaden zu Kubernetes

• Kubernetes hat unter manchen Entwicklerinnen und Entwicklern den Ruf, unnötig komplex und eine Zeitverschwendung zu sein; sein Einsatz in kleinen Teams gilt oft als Overengineering.
• Bei Jamsocket wird Kubernetes seit mehreren Jahren in Produktionsumgebungen betrieben, wobei ein effizienter Umgang gefunden wurde: Man nutzt nur die benötigten Funktionen und ignoriert den Rest.

Warum Kubernetes verwenden

• Kubernetes ist der am besten ausgetretene Weg, wenn man alle drei der folgenden Dinge gleichzeitig will:
  • Wenn man mehrere Prozesse/Server/geplante Jobs ausführen möchte.
  • Wenn man diese redundant betreiben und die Last verteilen möchte.
  • Wenn man ihre Konfiguration und ihre Beziehungen untereinander als Code definieren möchte.
• Kubernetes ist eine Abstraktionsschicht, mit der sich ein Pool von Computern wie ein einziger kopfloser Computer behandeln lässt.
• Jamsocket deployt mehrmals täglich, und wenn es Probleme mit dem Produkt gibt, sind auch die Produkte der Kunden betroffen; Rolling Deployments geben daher die nötige Sicherheit, häufig auszurollen.

Wie Kubernetes verwendet wird

• Jamsocket ist ein Dienst, der dynamische Prozesse erzeugt, die mit Web-Apps kommunizieren können, ähnlich wie AWS Lambda, nur dass die Lebensdauer der Prozesse nicht an eine einzelne Anfrage/Antwort, sondern an eine WebSocket-Verbindung gebunden ist.
• Kubernetes wird genutzt, um langlebige Prozesse wie API-Server, Container-Registry, Controller, Log-Sammler, einige DNS-Dienste und Metrik-Erfassung zu betreiben.
• Dinge, für die Kubernetes nicht verwendet wird: kurzlebige Prozesse, statische/Marketing-Websites, Dinge, die Daten direkt speichern.
• Mit Google Kubernetes Engine wird das Kubernetes-Management nach außen ausgelagert; ein Wechsel zu Amazon EKS ist bei Bedarf vergleichsweise einfach.

Aktiv genutzte Kubernetes-Ressourcen

• Deployments: Die meisten Pods werden über Deployments erzeugt.
• Services: Verwendet werden ClusterIP für interne Dienste und LoadBalancer für externe Dienste.
• CronJobs: Werden für Bereinigungsskripte und Ähnliches genutzt.
• ConfigMaps und Secrets: Werden verwendet, um die oben genannten Ressourcen mit Daten zu versorgen.

Dinge, die mit Vorsicht verwendet werden

• StatefulSet und PersistentVolumeClaim werden zwar genutzt, wichtige Daten werden aber bevorzugt in verwalteten Diensten außerhalb von Kubernetes gespeichert.
• RBAC wird möglichst vermieden, da es zusätzliche Komplexität einführt.

Dinge, die aktiv vermieden werden

• YAML von Hand schreiben: Stattdessen werden TypeScript und Pulumi verwendet, um Definitionen für Kubernetes-Ressourcen zu erzeugen.
• Nicht standardisierte Ressourcen und Operatoren: Sie ermöglichen Drittanbieter-Software zwar die Nutzung der Kubernetes-Infrastruktur, sind in der Praxis aber schwer handhabbar.
• Helm: Wird wegen Operatoren und YAML-Konventionen nicht verwendet.
• Alles, was „mesh“ im Namen trägt: Wird als unnötig angesehen.
• Ingress-Ressourcen: Werden vermieden, um keine unnötige zusätzliche Indirektion einzuführen.
• Den kompletten k8s-Stack lokal nachzubauen: Stattdessen werden mit Docker Compose oder eigenen Skripten nur die tatsächlich benötigten Teile des Systems gestartet.

Menschen sollten nicht auf Pods warten müssen

• Kubernetes wurde mit Fokus auf Robustheit und Modularität statt auf Container-Startzeiten entworfen und eignet sich daher nicht für Fälle, in denen Menschen auf den Start eines Pods warten.
• Jamsocket verwendet Plane, einen Rust-Orchestrator unter MIT-Lizenz, um Prozesse für interaktive Workloads schnell zu planen und auszuführen.

Abstraktionen auf höherer Ebene

• Einige Alternativen zu Kubernetes sind sehr gut, besonders dann, wenn die Infrastruktur nicht als Code beschrieben werden muss.
• Statt Kubernetes kann man sich auch für andere Lösungen entscheiden, etwa Dienste wie Railway, Render oder Flight Control.
• Wenn man den eigenen Umgang mit Kubernetes systematisch steuert, kann niemand sagen, es sei zu früh dafür.

Meinung von GN⁺

• Kubernetes ist trotz seiner Stärke bei der Verwaltung von Komplexität und Automatisierung, besonders in großen Systemen, für kleinere Projekte oder Startups wegen dieser Komplexität durchaus belastend.
• Dieser Artikel zeigt Wege auf, übermäßige Komplexität beim Einsatz von Kubernetes zu vermeiden, und hilft so auch Einsteigerinnen, Einsteigern und kleinen Teams, die Vorteile von Kubernetes zu nutzen.
• Vor dem Einsatz von Kubernetes sollte man sorgfältig abwägen, welche Funktionen tatsächlich benötigt werden und welche technischen Fähigkeiten das Team mitbringt, um Nutzen, Verwaltungsaufwand und Kosten gegeneinander abzuwägen.
• Statt Kubernetes kann es besser sein, einfachere und leichter zu verwaltende Dienste zu verwenden. Beispiele sind Docker Swarm, Apache Mesos und Nomad, die jeweils eigene Vor- und Nachteile haben.
• Bei der Einführung von Kubernetes sollten die Integration in die bestehende Infrastruktur, Sicherheit, Verwaltungskosten und die Lernkurve berücksichtigt werden.
• Zu den Vorteilen von Kubernetes zählen Skalierbarkeit, hohe Verfügbarkeit und eine konsistente Deployment-Erfahrung über verschiedene Cloud-Umgebungen hinweg. Dafür ist jedoch ein Verständnis von Ressourcenmanagement und Orchestrierung erforderlich.

[GN⁺]

Hacker-News-Kommentare

• Zusammenfassung des ersten Kommentars:

  • Wenn man komplexe Systeme wie Kubernetes einführt, wächst diese Komplexität immer weiter, sodass verschiedene Komponenten sich gegenseitig verstärken und als unverzichtbar angesehen werden.
  • Als die Cloud erstmals aufkam, fanden Menschen es attraktiv, die Komplexität von Load Balancern und Datenbankverwaltung zu reduzieren.
  • Zustandslose (stateless) App-Server waren kein großes Wartungsproblem, aber durch die Evangelisierung von Microservices wurden Probleme geschaffen, die zuvor nicht existierten.
  • Inzwischen hat sich diese Kultur so etabliert, dass es schwerfällt, Behauptungen zuzustimmen, Microservices seien zwingend erforderlich.

• Zusammenfassung des zweiten Kommentars:

  • Als jemand, der Kubernetes in kleinen und mittelständischen Unternehmen einführt, gab es zwar unzufriedene Engineers, doch die meisten gaben an, zufrieden zu sein.
  • Kubernetes ist komplex, aber es ist das richtige Werkzeug für komplexe Probleme.
  • Standards zu haben ist besser als undokumentiertes, simples Chaos, und kubectl explain X sei deutlich besser als die AWS-Dokumentation.
  • Kubernetes ist zwar komplex, funktioniert für Entwickler aber genauso wie in ihren früheren Jobs, und Geschwindigkeit ist wichtig.

• Zusammenfassung des dritten Kommentars:

  • Kritik an Kubernetes ist zwar in Mode, dennoch ist es weiterhin die beste Lösung.
  • Es definiert Infrastruktur deklarativ und bietet Load Balancing, automatische Wiederherstellung und Skalierung.
  • Es bietet hervorragende Observability über den gesamten Stack, und es gibt viel vorgepackte Software, die genutzt werden kann.
  • Man kann nahezu dieselbe Infrastruktur in der Cloud, auf eigenen Servern und lokal aufbauen und bleibt dadurch nicht an einen bestimmten Cloud-Anbieter gebunden.

• Zusammenfassung des vierten Kommentars:

  • Die großen Vorteile von Kubernetes sind Helm und Operators.
  • Wenn man die Kosten der Komplexität trägt, sollte man auch die Vorteile eines „App Stores“ für Infrastrukturkomponenten und einer programmatischen Verwaltung des Betriebs erhalten.
  • Um zum Beispiel etwas so Komplexes wie Ceph einzurichten, ist Rook ein guter Weg.
  • Helm oder Operators machen Infrastruktur zwar nicht zu gemanagten „Turnkey“-Appliances, aber deklarative Interfaces lassen sich in der Regel besser verwalten.

• Zusammenfassung des fünften Kommentars:

  • Kubernetes ist eine gute Technologie, aber wegen seiner Komplexität neigen Maintainer dazu, zu den Helden des Unternehmens zu werden.
  • Viele Stellschrauben und Einstellmöglichkeiten können vom eigentlichen Ziel eines Projekts ablenken.

• Zusammenfassung des sechsten Kommentars:

  • Das aktuelle Unternehmen ist zwischen Kubernetes und einem maßgeschneiderten, auf Ansible basierenden Deployment-System aufgeteilt.
  • Der Ansible-Ansatz funktioniert gut, aber ein Umstieg auf Kubernetes könnte die Deployment-Zeit von Stunden auf Minuten verkürzen und Auto-Scaling schneller und effizienter machen.
  • Schwierigkeiten dabei, die Ursachen fehlgeschlagener Helm-Deployments zu erkennen, sowie die Notwendigkeit, neue Betriebsweisen zu lernen, seien konsistente Rückmeldungen aus früheren Teams.

• Zusammenfassung des siebten Kommentars:

  • In einem Gespräch mit einem ehemaligen Google Site Reliability Engineer hieß es, dass es nur sehr wenige Unternehmen gibt, die Kubernetes tatsächlich brauchen.
  • Viele Menschen neigen dazu, Trends hinterherzulaufen.

• Zusammenfassung des achten Kommentars:

  • Kubernetes kann das richtige Werkzeug sein, sollte aber als notwendiges Übel akzeptiert werden.
  • Software, die durch das Versagen mehrerer Parteien leicht an Zusammenarbeit scheitern kann, kann häufig Probleme verursachen.

• Zusammenfassung des neunten Kommentars:

  • YAML direkt zu schreiben kann problematisch sein, daher werden stattdessen TypeScript und Pulumi verwendet, um Kubernetes-Ressourcendefinitionen zu erzeugen.
  • Anstatt YAML zu linten, führt man die gesamte Laufzeit einer Programmiersprache und Third-Party-Libraries ein und akzeptiert zusätzliche Komplexität wie Versionspflege und Projekt-Kompilierung.

• Zusammenfassung des zehnten Kommentars:

  • Als jemand, der einmal von Kubernetes begeistert war, seien die guten Teile von Kubernetes die Grundbausteine (Deployments, Services, ConfigMaps), und der Rest sollte nur in besonderen Situationen verwendet werden.
  • Das Team bevorzugt es, rohes YAML zu schreiben und kustomize zu verwenden, um die Konfiguration klar und eindeutig zu halten.