- Kubernetes hat in den vergangenen zehn Jahren die Revolution der Container-Orchestrierung angeführt
- Beim aktuellen Stand zeigen sich in YAML-Konfiguration, etcd-Abhängigkeit, Helm-Paketverwaltung und anderen Bereichen verschiedene Grenzen und Verbesserungsbedarfe
- Die Einführung von HCL, ein Plug-in-fähiger Speicher, ein neuer Paketmanager (KubePkg), IPv6 als Standard und weitere Punkte werden als mögliche Änderungen für Kubernetes 2.0 diskutiert
- Die heutige offene Struktur ist wichtig, doch Standardeinstellungen und eine offizielle Richtungsvorgabe haben entscheidenden Einfluss auf Innovationen im Ökosystem
- Es wird deutlich, dass Kubernetes durch kontinuierliche disruptive Verbesserungen für eine breitere Nutzerbasis und mehr Organisationen geeignet werden muss
Zehn Jahre Kubernetes: Erfolg und Grenzen
Anfang und Wachstum
- 2012 bis 2013 begannen in der Sysadmin-Community Gerüchte über Borg, Googles internes Linux-Containersystem, die Runde zu machen
- 2014 wurde Kubernetes veröffentlicht, und anfangs war schon der Name schwer auszusprechen
- Große Unternehmen wie Microsoft, RedHat, IBM und Docker schlossen sich schnell an, und Kubernetes begann sich als Standard des Ökosystems zu etablieren
- Mit der Veröffentlichung von v1.0 im Jahr 2015 und dem Start der CNCF entstand ein wirklich offenes Ökosystem
Zentrale Innovationspunkte
Verwaltung von Containern im großen Maßstab
- Kubernetes bietet Skalierbarkeit für containerbasierte Softwareentwicklung und -bereitstellung
- Es ermöglicht großflächige Deployments identischer Umgebungen – von einfachen Entwicklungsumgebungen bis hin zu Tausenden von Servern
- Organisationen konnten dadurch den Übergang von monolithischen Architekturen zu verteilten Microservices einleiten
Geringere Betriebskosten und Self-Healing
- Das Servermanagement wechselte rasant vom Zeitalter der "Simpsons" (jeder Server mit Spitznamen, manuell betrieben) zum Zeitalter der "UUIDs" (vollständiger Austausch, Automatisierung, zustandslos)
- Die Konzepte Maschinenlebensdauer und OS-Supportzeitraum sind fast verschwunden; bei Ausfällen wird durch „Neuerstellung des Nodes“ automatisch neu aufgebaut
- Viele Linux-Kenntnisse sind heute nicht mehr zwingend erforderlich, sondern eher ein „nice to have“
Batch-Jobs und Job-Management
- Batch-Verarbeitung, die früher auf dedizierte „cron-only boxes“ angewiesen war, wurde durch queuebasierte Automatisierungsjobs mit Retry-Mechanismen ersetzt
- Automatische Neustarts bei Fehlschlägen und flexible Verarbeitung steigern sowohl die betriebliche Effizienz als auch die Zufriedenheit der Entwickler deutlich
Service Discovery und Load Balancing
- Statt hart kodierter IP-Adressen wurde ein internes DNS-basiertes Benennungssystem für Services eingeführt
- Über API, feste IPs und Hostnamen wurde die Verbindung zwischen Services vereinfacht, und auch externe Services lassen sich wie interne behandeln
Kubernetes 2.0: zentrale Verbesserungsvorschläge
Von YAML zu HCL: Austausch der Konfigurationssprache
Grenzen von YAML
- YAML ist leicht lesbar und wirkt besser als JSON oder XML, hat aber gravierende Probleme wie Fehleranfälligkeit, fehlende Typsicherheit und schwieriges Debugging
- Beispiele: das Norwegen-Problem ("NO" wird als false interpretiert), Einrückungsfehler oder Verwechslungen zwischen Strings und Zahlen – alles potenzielle Ursachen für Störungen
Alternative: Einführung von HCL
- HCL (HashiCorp Configuration Language) ist das Standardformat von Terraform und bietet starke Funktionen wie starke Typisierung, Validierung, Funktionen und bedingte Verzweigungen
- Bereits heute nutzen viele Kubernetes-Cluster HCL zusammen mit Terraform
- HCL bietet im Vergleich zu YAML leistungsfähigere Funktionen wie Typsicherheit, weniger Duplikate, dynamische Konfiguration, Wiederholungen, bedingte Logik, hervorragende Kommentarunterstützung, Modularität und Validierung
- Das Open-Source-Lizenzthema (MPL 2.0 → Kompatibilität mit Apache 2.0) bleibt zwar bestehen, doch der Nutzen für bessere Qualität ist groß genug
Beispiel: HCL vs YAML
- Durch Vorteile wie Typen, Variablen, Funktionen, Bedingungen und Schleifen hilft HCL dabei, Konfigurationsfehler im Vorfeld zu vermeiden, die Wartbarkeit zu verbessern und auch in komplexen Umgebungen Konsistenz sicherzustellen
Unterstützung für Alternativen zu etcd
- etcd ist leistungsfähig, verursacht in kleinen Clustern oder ressourcenschwachen Umgebungen jedoch oft einen übermäßigen Ressourcenverbrauch
- Über offiziellen Support für Plug-in-fähige Backends wie Kine wird die Notwendigkeit größerer Flexibilität beim Standardspeicher betont
- Beispiel: k8s-dqlite bietet mit verteiltem SQLite+Raft eine leichte und flexible Datenschicht
Jenseits von Helm: ein nativer Paketmanager
Grenzen von Helm
- Helm ist ein Fall, in dem sich eine provisorische Hack-Lösung zum Standard entwickelt hat; Probleme gibt es unter anderem bei Template-Komplexität, schwierigem Debugging, Abhängigkeits- und Versionskonflikten sowie mangelnder Validierung
- In der Praxis treten viele Schwierigkeiten auf, etwa doppelte Charts, Versionsinkonsistenzen, komplizierte Installationen über Namespaces hinweg, fehlende Chart-Suche und Metadaten, Missachtung von Semantic Versioning sowie unsicheres CRD-Management
Vorschlag für ein neues Paketsystem: KubePkg
- Umfassende Verwaltung von Paketen, Abhängigkeiten, Semantic Versioning, Security, Lifecycle und Metadaten in Form von Kubernetes-Ressourcen
- Mit ausgefeilten Lifecycle-Hooks, Status- sowie Backup-/Recovery-Strategien, deklarativer Konfiguration, überprüfbaren Signaturprozessen, Audit-Protokollen und organisatorischer Policy-Kontrolle
- Ziel ist es, die Vorteile von Linux-Paketmanagern zu übernehmen und damit starke Zuverlässigkeit und Konsistenz für das reale Infrastrukturmanagement bereitzustellen
Zentrale Anforderungen
- Vollständig Kubernetes-native Ressourcenstruktur
- Eingebaute Unterstützung für zustandsbehaftete Anwendungen
- Stärkere Prozesse für Signierung/Verifizierung/Security-Scanning
- Strukturierte deklarative Konfiguration plus Schema-Validierung
- Kontrolle über den gesamten Lifecycle und einfache Unterstützung für Upgrades/Hooks
- Linux-artige Auflösung von Abhängigkeiten und Versionen
- Änderungsverlauf und Audit-Trail
- Durchsetzbarkeit organisationsspezifischer Policies
- Vertraute UX nach dem Vorbild von Linux-Paketverwaltung
IPv6 als Standard
- Zwar werden IPv6 und Dual-Stack bereits unterstützt, der Standard ist aber weiterhin IPv4
- Damit lassen sich clusterübergreifende Kommunikation, NAT-Probleme und IP-Knappheit besser lösen; außerdem bietet es Vorteile wie einfachere Netzwerkstrukturen und integriertes IPSec
- In Umgebungen mit hohem IP-Bedarf (Beispiel: /20-Bereich, 40 Nodes, 30 Pods pro Node) stößt IPv4 schnell an seine Grenzen
- Praktische Vorteile sind klar erkennbar: einfacherer Betrieb in öffentlichen IPv6-Umgebungen, Gewinnung von Cloud-Nutzern und weniger Aufwand bei der Verwaltung privater Adressräume
Fazit: Warum Veränderung nötig ist – und wie mächtig Defaults sind
- Zwar gibt es die Ansicht, bei einer „offenen Plattform“ könne sich die Community selbst darum kümmern, doch Standardeinstellungen prägen das Verhalten der Branche
- Für Kubernetes 2.0 ist jetzt der Zeitpunkt gekommen, an dem es offizielle Überzeugungen, gutes Design und starke Defaults braucht
- Als Industriestandard und dominierende Grundlage für den Betrieb globaler Rechenzentren ist jetzt ein frischer Sprung nach vorn wichtig
- In vielen Technologiebereichen wie Mobile und Web haben mutige Veränderungen wiederholt das gesamte Ökosystem erneuert
- Auch Kubernetes ist nun an dem Punkt, mit einem wegweisenden 2.0 den nächsten Schritt zu durchdenken
2 Kommentare
Ich glaube, dass es auch künftig nur eine kleine Minderheit von Engineers geben wird, die Vanilla-Kubernetes aus zusammengefügten Open-Source-Komponenten aufbauen und betreiben können.
So wie es auch nur eine verschwindend kleine Zahl von Engineers gab, die das Vanilla-Hadoop-Ökosystem betreiben konnten, statt einen Hadoop-Cluster als gebündelte Cloudera-Plattform zu kaufen.
Hacker-News-Kommentare
Ich würde sagen, das größte Problem von Kubernetes ist, dass es kein System ist, das „einfach funktioniert“. In der Praxis gibt es nur wenige Engineers, die einen Service in Produktion reibungslos betreiben können, und ein Kubernetes-Cluster direkt auf VMs aufzubauen und zu pflegen, ist noch einmal deutlich schwieriger. Deshalb gewinnen derzeit Serverless-Startups an Aufmerksamkeit, weil sich die Wahrnehmung verbreitet hat, dass Kubernetes (1) viel Zeit kostet, (2) sehr fehleranfällig ist und (3) in Produktionsumgebungen mit hoher Wahrscheinlichkeit scheitert. Für Kubernetes 2.0 sollte man meiner Meinung nach darüber nachdenken, in eine Richtung zu gehen, in der jeder problemlos eine Deployment-Plattform selbst hosten und mit Vertrauen nutzen kann, während ein kleiner, leistungsfähiger Orchestrator-Kern erhalten bleibt. Ich entwickle selbst einen Orchestrator und eine Deployment-Plattform namens Rivet und stelle sie als Rivet Open-Source-Serverless-Plattform vor, frage mich dabei aber oft selbst: „Wie könnte Kubernetes 2.0 aussehen?“ Es gibt auch immer mehr Fälle, in denen Leute Rivet für Szenarien einsetzen, die über die Erwartungen hinausgehen. Die größte Stärke von Rivet ist, dass sich Funktionen auf dem Niveau von Kubernetes-Controllern sehr leicht entwickeln lassen. Dadurch ist es in verschiedensten Szenarien einsetzbar, etwa für Game-Server, tenant-spezifische Deployments, fortgeschrittene Workload-Orchestrierung, Multi-Tenancy, tenant-spezifisches Billing oder den Entwurf leistungsfähiger Operatoren.
Diese Sichtweise stößt bei mir ehrlich gesagt auf Ablehnung. Vielleicht liegt es daran, dass ich älter und ein wenig zynisch geworden bin, aber das ist ein Muster, das ich ständig sehe. Eine Technologie X ist zu schwergewichtig, also baut jemand Technologie Y mit dem Gedanken: „Ich will das einfach ohne diesen ganzen Kram auf meinem Laptop laufen lassen.“ Dann wird Y populär, muss skaliert werden, weil es nicht mehr nur auf Laptops läuft, und bekommt allerlei Features dazu, bis es selbst schwergewichtig wird. Dann kommt wieder jemand und sagt: „Jetzt ist auch Y zu schwer.“ Das ist wie das Rad der Zeit – eine Geschichte ohne Anfang und Ende, die sich endlos wiederholt.
In Wirklichkeit ist k3s (leichtgewichtiges k8s) sehr einfach zu warten. Mit automatischen k3s-Updates und vernünftigen Eviction-Regeln muss man fast nie eingreifen, und wenn Storage wie Ceph zu kompliziert ist, kann man „Zero-Management“-Alternativen wie Lemon oder Longhorn wählen. Es gibt Tausende Helm-Charts, sodass sich selbst komplexe Datenbanken in einer Minute deployen lassen. Auch Service-Deployments sind sehr einfach, wenn man nur häufig genutzte Helm-Templates verwendet. Helm ist nicht perfekt, aber wenn man es passend einrichtet, bekommt man auch Dinge wie Value-Autocompletion. Die Einstiegshürde ist etwas höher als bei Serverless, aber eine Woche Lernen, um in echter Produktion Millionen Won zu sparen, ist absolut lohnenswert.
Das Problem, das Kubernetes löst, lautet: „Wie deploye ich das?“ In den Rivet-Dokumenten sehe ich nur Single-Container, Docker Compose und manuelle Deployments (Docker-Befehle). Realistisch betrachtet bezweifle ich, dass sich so eine Serverless-Infrastruktur in echter Größenordnung deployen lässt. Meine erste Frage ist: „Ab diesem Punkt, warum kann man Rivet nicht einfach auf Kubernetes laufen lassen (Container, kube-virt usw.)?“ Ich sehe nicht, wie Docker Compose robuster oder besser skalierbar sein sollte als Kubernetes. Wenn das nicht so ist und man stattdessen einen Cloud-Service verkauft, passt das auch nicht zum Konzept Kubernetes 2.0. Wenn ich Rivet selbst hosten würde, würde ich die Dokumentation so ändern, dass man es auf Kubernetes betreiben kann.
Wenn man „k8s as a Service“ nutzt, also Cluster-Management an den Cloud-Anbieter auslagert, frage ich mich, was genau sich dann noch so kompliziert anfühlt. Der Konfigurationsumfang ist groß, aber um einen Service tatsächlich in Produktion zu bringen, muss man nur eine kleine Zahl von Einstellungen kennen. Ein Maß an Konfiguration, das nur etwas komplexer ist als Docker Compose, reicht völlig aus, um auf k8s zu deployen. Für die meisten Apps könnte selbst dieses „ein bisschen mehr“ aber unnötig sein. Eigentlich war Docker Compose genau auf diesen Massenbedarf ausgerichtet, und ich finde es schade, dass es nicht dauerhaft mehr Aufmerksamkeit bekommen hat.
Meine Erfahrung im Infrastruktur-Betrieb ist, dass es „einfach funktioniert“ niemals geben wird. Selbst Heroku hat beim Skalieren Probleme. Wenn man eine Deployment-Plattform will, die alle leicht übernehmen können, ist es realistischer, Kubernetes als grundlegendes Primitive unter einer bestimmten PaaS zu verstehen. Rivet ist interessant, weil es eigenständig ist und einige Ideen aus dem BEAM-Ökosystem zeigt. Mich persönlich interessieren Stabilität und ein Local-First-Ansatz mehr als großflächige Deployments.
„Low maintenance“ also ... Ich nutze häufig EKS (verwaltetes k8s), und um den Cluster-Zustand selbst muss ich mich nicht kümmern (abgesehen davon, auf welch kreative Weise ich Nodes kaputtmachen kann). Kubernetes tut wirklich so, als bräuchte es „möglichst wenig Wartung“, ist in Wahrheit aber ein einziger Wartungsblock. Dass man mit etwas yaml Software direkt in die Welt deployen kann, ist wirklich beeindruckend. Der Preis dafür ist aber komplexe Wartung. Cluster-Setup, ArgoCD initialisieren, andere Cluster in einem Hub-and-Spoke-Modell registrieren – das ist alles nur eine Zirkusnummer. Dazu kommen brauchbare Operatoren aus dem CNCF-Landscape-Tooling und allerlei ancillary Tools (physisch vielleicht nicht First-Order, aber unverzichtbar), sodass am Ende gut 30 Zusatzkomponenten laufen. Schon das Einrichten von
values.yamldauert nicht nur ein oder zwei Stunden, und der Großteil davon ist ArgoCD- und Template-Arbeit. Secrets Manager -> External Secrets -> ArgoCD ApplicationSet -> wieder einevalues.yaml– oft geht eine Menge Zeit allein dafür drauf, einen einzigen Boolean-Wert durchzureichen. Dazu kommt der schnelle Update-Zyklus bei Clustern und Operatoren, also ein permanentes Wartungsthema. Wenn man mit Karpenter autoskaliert, wird der Austausch von Nodes bei gleichzeitigem Zero-Downtime-Betrieb zur nächsten Artistennummer (und zustandsbehaftete Apps machen auf k8s doppelt so viel „Spaß“). Kurz gesagt: Wirklich „Low maintenance“ ist eher ironisch gemeint.„Low Maintenance“ ist letztlich ein relativer Begriff gegenüber den Alternativen. Nach meiner Erfahrung war beim Einsatz von k8s der Wartungsaufwand insgesamt deutlich geringer, um dieselbe Servicequalität bei Skalierung, Failover, Rollbacks, Disaster Recovery, DevOps und dem Hochziehen unabhängiger Cluster zu erreichen. Das mag je nach Situation anders sein, aber so war es bei mir.
Ich nutze seit zwei Jahren k3s bei Hetzner und hatte 100 % Uptime. Der Wartungsaufwand ist so gering, dass ich sogar einmal den SSH-Key des Master-Nodes verloren habe, und das komplette Reprovisioning des Clusters hat inklusive Doku-Update nur 90 Minuten gedauert. Wenn es wirklich dringend gewesen wäre, hätten 15 Minuten gereicht. Ich betreibe für 20 Euro im Monat ein k8s-Cluster mit 3 ARM-Nodes und 1 Master, etwas Storage und automatischem DNS zusammen mit Cloudflare.
Tatsächlich verwaltest du aber nicht Kubernetes selbst, sondern Begleitsysteme wie CI/CD, Secret Management oder Automatisierung für den Datenbankbetrieb. Früher hätte man das statt mit yaml eben mit Cronjobs, ansible, systemd oder Bash-Skripten gemacht.
Das klingt, als hättest du dir deine eigene Manege gebaut. Man sollte nicht so viele Dinge installieren. Jedes zusätzliche Teil bringt technischen Schuldenstand und Wartungskosten mit sich, auch wenn das Tool kostenlos ist. Wenn Autoscaling mehr Schulden und Wartung verursacht, als es spart, sollte man es einfach abschalten.
Würde man eine ähnliche Menge an Services einzeln zusammenbauen und betreiben, wäre der Wartungsaufwand viel höher. Kubernetes ist aber so pflegeleicht, dass man es nach dem Anzünden gewissermaßen stehen lassen kann. Voraussetzung ist nur, dass man weiß, was man tut, und nicht in Versuchung gerät, irgendwelche „cool aussehenden Tools“ zu installieren.
K8S erzwingt auch nicht yaml. Es mag idiomatisch sein, aber verpflichtend ist es nicht.
kubectl applyunterstützt von Anfang an auch json, und die Endpoints sind json und grpc. Man kann Konfiguration auch aus verschiedenen Sprachen wie jsonnet generieren. Zweitens frage ich mich, warum Dependency und Dependency Ordering in Helm-Charts überhaupt ein Thema sind. Das zentrale Idiom von Kubernetes ist die Schleife: Wenn eine Abhängigkeit fehlt, behandelt die App das als recoverable error und versucht es wiederholt, bis es klappt. Oder sie crasht und der ReplicaSet-Controller startet sie automatisch neu. Wenn das Chart keine Abhängigkeiten hat, gibt es auch keine Konflikte bei Abhängigkeiten. Wenn eine App wirklich von etwas anderem abhängt, sollte man die abhängige App bzw. den Service direkt im Helm-Chart mit enthalten.(Zitat der Hauptmeinung) > Dass der ReplicaSet-Controller bei einem Crash die App neu startet, reicht nicht aus. Wenn zum Beispiel Keycloak eine Minute zum Starten braucht, crasht der abhängige Service sofort ohne Keycloak und wird dann so lange neu versucht, bis Throttling greift; selbst nachdem Keycloak läuft, wartet man dann oft noch 5 bis 10 Minuten unnötig weiter. Wenn die Abhängigkeit klar ist, ist es sinnvoller, vor dem Start des Main-Containers im Init-Container zu prüfen, ob der abhängige Service verfügbar ist. Ich fände es gut, wenn Kubernetes eine explizite Deklaration von Start-Abhängigkeiten hätte. Abstürzen, ein paarmal neu versuchen und dann ins Throttling laufen ist keine gute Lösung. Abhängigkeiten sind einfach Realität.
Ich denke, Fehler bei Abhängigkeiten sollten unbedingt recoverable sein. Ich habe schon einmal einen Ausfall erlebt, weil etwas fail-closed reagiert hat wegen einer Abhängigkeit, die in Wirklichkeit gar nicht genutzt wurde. Abhängigkeiten zwischen Servern sind fast immer Soft Dependencies. Wenn eine Downstream-Abhängigkeit nicht verfügbar ist, sollte man einfach einen 500 zurückgeben, und der Load Balancer meidet dann den ungesunden Server.
Man sagt zwar, es „sollte so sein“, aber das passt nur gut zu Fällen, in denen man einen Inhouse-Software-Stack aufbaut. Es gibt viele ältere, bereits existierende Softwarepakete, die ursprünglich nur Docker unterstützt haben und später irgendwie auf Kubernetes lauffähig gemacht wurden. Wenn Entwickler Tools nach ihrer eigenen Philosophie bauen, verwenden Menschen sie am Ende doch auf die Art, die sie wollten – und dann entsteht Chaos. Letztlich muss man den Leuten verschiedene Funktionen und Wahlmöglichkeiten geben, und der Markt nutzt sie dann so, wie er will.
Der Satz „Das zentrale Architekturmerkmal von Kubernetes ist die Reconciliation Loop“ trifft es für mich sehr genau. Den aktuellen Zustand beobachten, den Unterschied zum gewünschten Zustand bestimmen und dann genau diese Differenz anwenden. Das endlos wiederholen. Nicht Erfolg oder Misserfolg, sondern nur die iterative Auflösung der Differenz zwischen Ist- und Soll-Zustand. Dieses Muster ähnelt für mich auch „good enough technology“ aus maschinellen Regelungssystemen wie PID-Reglern.
Den Beitrag mit dem Hinweis zu kritisieren, dass man statt yaml auch json nutzen kann, geht am eigentlichen Punkt vorbei. Dafür interessiert sich in Wahrheit niemand. Das wirkt wie unnötige Rechthaberei.
Ich bin entschieden dagegen, yaml durch HCL zu ersetzen. HCL ist für Entwickler schwer zu lesen und unangenehm anzuschauen. Bei Dingen wie Import-Unterstützung oder Debugging habe ich viele Beschwerden zur Usability. Ich verstehe nicht, warum man nicht lieber eine Interface-Definition-Sprache wie protobuf in den Mittelpunkt stellt und den Nutzern dann die gewünschte Form daraus ableiten lässt.
HCL ist furchtbar. Mir hat bei k8s yaml nie etwas gefehlt. Wenn die Konfiguration zu komplex wird, liegt das eher am App-Design als an ConfigMaps.
Eigentlich ist es egal, ob HCL, JSON oder YAML – der Client kann das ohnehin serialisieren und deserialisieren. Das ist also kein Kubernetes-Problem, sondern nur eine äußere Transformationsschicht.
Die Interface-Definitionen von Kubernetes basieren ohnehin schon auf protobuf (mit Ausnahme von CRDs).
Mein Hauptproblem mit HCL ist die Syntax von
for-Schleifen. Wirklich grauenhaft.Wenn jemand sagt, „HCL ist für Entwickler schwer und Linting oder Debugging ist mühsam“, klingt das für mich eher danach, dass man einfach nichts Neues lernen will. Das Problem wirkt eher wie eine Verwechslung mit der Komplexität der Domäne selbst als mit dem Erlernen von HCL.
Ich arbeite an einem nebulous-Projekt im Stil von „Kubernetes 2.0“ (noch im Pre-Alpha-Stadium). Ziel ist globale Verteilung und geringes Gewicht, ein einzelnes Binary, das auf dem Laptop läuft, aber in der Cloud auf Tausende Nodes skaliert, dazu Tailnet-Netzwerke, BitTorrent-Storage, Multi-Tenancy, Live-Migration usw. Die meisten Anforderungen kamen aus dem ML-Betrieb, insbesondere wegen GPU-Knappheit, und wenn ML künftig alltäglich wird, könnte so etwas vielleicht zum Standard werden.
Live-Migration ist interessant. Wir fahren aktuell eine Preisstrategie auf Basis von Autoscaling über mehrere Cluster und Clouds hinweg, und Live-Migration ist noch einmal eine ganz andere Herausforderung.
Das ist nicht Kubernetes, sondern ein separates System, das auf den Betrieb von GPUs spezialisiert ist.
„Globale Verteilung“ könnte eher eine Non-Requirement sein. Wenn Tailnet das Standardnetzwerk ist, wäre das für mich eher eine Funktion, die ich sofort entfernen würde. Dass Kubernetes von einer einzelnen NIC ausgeht, ist ein frustrierendes Erbe seiner Cloud-Zentrierung (mehrere CNIs und neuere Projekte wie Multus sind da willkommen; siehe: Red-Hat-Blog). Mich würde interessieren, worin sich das Multi-Tenant-Design praktisch von k8s unterscheidet. Wenn Storage über BitTorrent läuft und sogar öffentliche Container-Images mitverteilt werden, dürften die Egress-Kosten enorm sein.
Auf GitHub sehe ich
Chart.yaml, und sogar Template-Dateien wieprovider_aws.yaml– ehrlich gesagt genau die Art von Code-Muster, die ich lieber nicht sehen würde.Für mich ist Kubernetes auch heute noch wirklich komplex. Es wirkt nur weniger so, weil es sich verbreitet hat. Bei Kubernetes 2.0 würde ich mir wünschen, dass die User Experience einfacher wird, besonders bei häufigen Operationen wie App-Deployment, Service-Exposure oder dem Ändern von Service-Accounts und Images. Aber weil gerade alles von LLMs dominiert wird, dürfte eine solche Weiterentwicklung schwer werden.
Kubernetes hat zu viele Abstraktionsebenen. Pods sind ein starkes Kernkonzept, aber mit Deployments, ReplicaSets, Namespaces usw. denke ich oft, wie schön es wäre, wenn es so simpel wie Docker Swarm wäre. Auch Terraform hatte nur eine einzige Schicht und war leicht zu lernen. Ich merke gerade sehr deutlich, wie steil die Lernkurve von k8s wirklich ist.
Das ist so ein Thema, bei dem man daran denken muss, dass „die Typunterscheidungen in Computerprogrammen ein Ergebnis menschlicher Wahrnehmung sind“. Operatoren und Controller sind wie früher COM/CORBA übermäßig abstrahiert – zugleich Stärke und Schwäche. Für einfache Implementierungen wirkt ein stärker eingeschränktes k8s-lite oft passender. In komplexen Umgebungen wiederum reichen selbst die bestehenden Abstraktionen von k8s oft nicht aus. Ich bin unsicher, ob ein einziges System – ob Kubernetes 2.0 oder etwas anderes – jemals alle realen Probleme so kapseln kann, dass menschliche Entwickler und Architekten damit vollständig zurechtkommen.
Ich will ein System mit „sane defaults“, also mit vernünftigen Standardwerten, die auch ohne besondere Auswahl für Netzwerk, Storage, Load Balancer usw. ausreichend gut sind. Weder yaml noch HCL gefallen mir. Es braucht einen besseren Weg für Konfiguration, und ein bloßer Sprachwechsel wird das Problem nicht lösen. IPv6 halte ich für zwingend notwendig. Docker, Container und Kubernetes hätten intern alle IPv6-only sein sollen, und IPv4 sollte nur im Ingress-Controller als Ausnahme behandelt werden.
Zwischen „sane defaults“ und „Conversion für Managed-Service-Kunden“ gibt es einen grundlegenden Konflikt. Je länger ich k8s beobachte, desto stärker wird die Philosophie „batteries not included“ bei Dingen wie Storage und Netzwerk, und AWS/GCP verkaufen genau das dann als teure Integrationsservices. In der Praxis wirkt k8s dadurch fast nicht mehr wie Open Source, sondern auch wie ein Verkaufswerkzeug, um Lücken im Cloud-Angebot zu monetarisieren.
(Persönliche Erfahrung) Terraform/HCL ist gegenüber YAML insofern besser, als es nicht von unsichtbaren Zeichen abhängt und dadurch leichter zu lesen ist.
Gerade wegen der „sane defaults“ mag ich k3s viel lieber.
Für einen 2.0-Release ist das für mich eine eher bescheidene Wunschliste. Alle in meinem Umfeld beklagen die Komplexität von Produktions-k8s. Die eigentliche Kernfrage ist, wie man Backward Compatibility und Einfachheit gleichzeitig hinbekommt. Meistens explodiert die Komplexität gerade wegen der Backward Compatibility, weil ein neues System sowohl alte als auch neue Funktionen mittragen muss.
Ich habe das Gefühl, schon jetzt in einer „Kubernetes-2.0-Welt“ zu leben, weil ich Cluster und Apps bereits mit Terraform verwalte.
tf applyrichte ich Cluster, Nodes, Cloud-Integrationen (S3 usw.) und Services im Cluster in einem Schritt eincloudflaredim Cluster + Tunnel-Konfiguration über die Cloudflare-API)Als jemand mit Frontend-Hintergrund fand ich Kubernetes überraschend intuitiv. Früher habe ich Daten genommen und daraus reaktiv UI aufgebaut; jetzt fühlt es sich so an, als würde ich Code schreiben, der Ressourcen und Konfiguration an eine Control Plane angleicht.