Lieber Freund, du hast Kubernetes gebaut

• Ein Brief an einen Freund

  • Darin wird erklärt, dass man Kubernetes vermeiden wollte, am Ende aber doch ein ähnliches System gebaut hat.
  • Der Freund entschied sich für „langweilige Technik“ und wollte Container einfach ausführen, stieß am Ende jedoch wegen komplexer Skripte und Konfigurationen auf Probleme.
  • Selbst der Wechsel zu Docker Compose löst nicht alle Probleme, und man erkennt, dass separate Lösungen für Deployments, Rolling Updates, Rollbacks und Skalierung nötig sind.

• Server-Skalierung und Netzwerkkomplexität

  • Man erkennt die Notwendigkeit, auf einen zweiten Server zu erweitern.
  • Es wird versucht, mit Overlay-Netzwerken wie Tailscale Service Discovery umzusetzen.
  • Man bemüht sich, die Netzwerkkomplexität zu lösen, sieht sich am Ende aber mit noch mehr Problemen konfrontiert.

• Wartung und Automatisierung

  • Es stellt sich die Frage, wer die komplexen Setups und undokumentierten Konfigurationsänderungen verwalten soll, wenn die Person, die die Skripte geschrieben hat, Urlaub macht oder das Unternehmen verlässt.
  • Um die Wartungsprobleme von Custom-Skripten zu lösen, werden VMs mit Ansible unveränderlich und versionierbar gemacht.
  • Man geht davon aus, dass sich alles leichter warten lässt, solange man Kubernetes nicht verwendet.

• Container-Erstellung und Sicherheitsprobleme

  • Es entsteht die Anforderung, andere Container programmatisch zu erzeugen.
  • Da es ein Sicherheitsrisiko ist, den Docker-Socket in eine Web-App zu mounten, wird ein separater Service geschrieben, um das Problem zu lösen.
    • Das Problem wird gelöst, indem ein separater Service geschrieben wird, der nur die sicheren Teile der Docker API freigibt.

• Fazit

  • Am Ende erkennt man, dass man ein Kubernetes-ähnliches System aufgebaut hat.
    • Ein komplexes System mit standardisiertem Konfigurationsformat, Deployment-Methode, Overlay-Netzwerk, Service Discovery, unveränderlichen Nodes und API-Server ist fertiggestellt.

• PS

  • Es wird nicht bestritten, dass es möglicherweise bessere Lösungen als Kubernetes gibt.
  • Bevor man Kubernetes jedoch pauschal als komplex abtut, wird empfohlen, die Probleme, die es lösen will, ausreichend zu verstehen.

[savvykang]

Ich kann nicht ganz nachvollziehen, warum man Kubernetes einführt, um die Übergabe von Deployments zu lösen.

[kandk]

Wartung und Automatisierung sind auf Code-Ebene einfach umzusetzen.
Auch Infrastructure as Code ist möglich.

[savvykang]

In Managed-k8s-Service-Umgebungen wie EKS gibt es zwar einen Load Balancer und auch eine mögliche Anbindung an Route 53, aber bei selbst gehostetem k8s gibt es weder eine Load-Balancer-Implementierung noch ist die DNS-Integration besonders flexibel. In Unternehmen mit einem eigenen Team für das k8s-Management könnten die von Ihnen genannten Vorteile tatsächlich zutreffen.

Oberflächlich betrachtet klingt es nach einer brauchbaren Lösung, aber wenn man sie tatsächlich einsetzt, funktioniert sie nicht in jeder Situation.

[kandk]

Es ist auch ohne ein k8s-Administrationsteam einfach zu nutzen. Wenn man EKS verwendet, reicht das.

[savvykang]

Ist das nicht im Grunde dieselbe Behauptung wie: Wenn man nur den Quellcode übergibt, ist die Übergabe abgeschlossen? Ein Arbeitsmanual und die Dokumentation der bisher ausgeführten Arbeit scheinen doch weiterhin nötig zu sein.

[kbumsik]

Infrastructure as Code ist ja im Grunde genau dafür da, dass man nur den Quellcode übergibt und damit alles erledigt ist.
Natürlich gilt aber wie bei jedem Code, dass eine grundlegende Dokumentation vorhanden sein sollte.

[kandk]

Wenn der Quellcode sauber geschrieben ist und die Dokumentation gut ist, ist das möglich.
Es wäre zwar hilfreich, wenn es zusätzlich ein Arbeitsmanual und eine Historie der durchgeführten Aufgaben gäbe, aber das scheint eine andere Geschichte zu sein als dieser Artikel.

[GN⁺]

Hacker-News-Kommentare

• Ich habe in mehreren Unternehmen erlebt, dass Deployments mit Shell-Skripten erfolgreich durchgeführt wurden.

  • Mit zwei PHP-Services wurden über 1 Milliarde Requests pro Tag verarbeitet, und Deployments erfolgten ohne Downtime, indem Dateien auf die Server übertragen und Migrationen ausgeführt wurden.
  • In Branchen wie der Altersvorsorge, die keine Webscale benötigen, wurden Deployments über Jenkins mit Docker-Befehlen durchgeführt.
  • Testumgebungen konnten bei Bedarf innerhalb weniger Minuten bereitgestellt und genutzt werden.
  • Mein derzeitiges Unternehmen versucht, Kubernetes einzuführen, hat aber wegen der Komplexität Schwierigkeiten damit.

• Für Kubernetes braucht man zwei oder drei Vollzeitkräfte nur, um YAML-Dateien zu verwalten.

  • Wenn man einen Cloud-Anbieter wählt, kann dieser die komplizierten Teile lösen, aber das verursacht zusätzliche Kosten.
  • YAML-Dateien sind Konfigurationsdateien, die nicht von Menschen geschrieben, sondern von Tools erzeugt werden sollten.
  • Die meisten Websites und Services brauchen Kubernetes nicht.

• Die Vorstellung, dass einfache Dinge fragil seien, ist falsch.

  • Es ist schwieriger, die Komplexität von YAML-Dateien und Kubernetes zu verstehen und zu debuggen.
  • Eine Alternative zu Kubernetes sind Shell-Skripte.

• Es gibt Fälle, in denen Kubernetes nicht notwendig ist.

  • Mit EC2-Instanzen und einfachen Shell-Skripten lassen sich über 100.000 gleichzeitige Nutzer bewältigen.
  • Wenn es keine Probleme gibt, muss man es nicht unnötig ändern.

• Mit Shell-Skripten lassen sich iptables-Regeln und sysctl-Bearbeitungen leicht verwalten.

  • Statt Container programmatisch mit einer Job-Queue zu erzeugen, kann man Jobs einfach in die Queue schieben.

• Kubernetes zu kritisieren, ist nicht unprofessionell.

  • Wenn es sich nicht um groß angelegte Anwendungen wie bei Google oder Netflix handelt, ist es besser, einfache Skripte zu schreiben.

• Die Annahme, dass alle Einschränkungen eines selbstgebauten Systems Kosten seien, und dass die Flexibilität einer allgemeinen Lösung nur Vorteile bringe, ist falsch.

  • Man möchte, dass die Codebasis ähnlichen Mustern folgt und Services auf dieselbe Weise deployt werden.

• Das Problem von Kubernetes ist, dass zahllose Open-Source-Bibliotheken das System schwer verständlich machen und Bugs verursachen.

• Menschen, die die Lernkurve von Kubernetes überwunden haben, sagen, dass die Komplexität gar nicht so schlimm sei.

  • Ein Kurs, um Entwicklern Kubernetes beizubringen, dauert etwa 30 Minuten und versetzt sie in die Lage, Helm-Charts zu schreiben.