Kubernetes & Helm Fundamentals

Hallo, hier ist Alex von DEV STORIES DOT EU. Kubernetes & Helm Fundamentals, Folge 1 von 10. Jahrelang betrieb Google seine globale Search- und E-Mail-Infrastruktur mit einem streng geheimen System, benannt nach den furchterregendsten Schurken aus Star Trek. Sie mussten es erfinden, weil das bestehende Server Management bei ihrer Skalierung einfach zusammenbrach. Heute schauen wir uns die Ursprünge von Borg bis Kubernetes an und warum moderne Enterprises darauf setzen. Um zu verstehen, warum es Kubernetes gibt, musst du dir anschauen, wie sich das Application Deployment entwickelt hat. In der traditionellen Deployment-Ära hast du Applications auf physischen Servern laufen lassen. Es gab keine Möglichkeit, Resource Boundaries zu definieren. Wenn eine Application den Großteil des Memorys beanspruchte, litten die anderen Applications auf diesem physischen Server. Du konntest zwar für jede App eine eigene physische Maschine kaufen, aber das führte zu teurer, schlecht ausgelasteter Hardware. Als Nächstes kam die virtualisierte Deployment-Ära. Du hast mehrere Virtual Machines auf der CPU eines einzigen physischen Servers ausgeführt. VMs isolierten die Applications und boten ein gewisses Maß an Security, aber jede VM brauchte trotzdem ein vollständiges, schwerfälliges Operating System. Schließlich sind wir in der Container-Deployment-Ära angekommen. Container sind ähnlich wie VMs, aber sie teilen sich das zugrundeliegende Operating System zwischen den Applications. Weil sie von der zugrundeliegenden Hardware entkoppelt sind, sind sie lightweight, starten schnell und sind portabel über verschiedene Clouds und Operating-System-Distributionen hinweg. Aber Container brachten ein neues Problem mit sich. Wenn du eine globale Enterprise-Application betreibst, hast du nicht nur einen Container. Du hast Tausende. Wenn ein Container down geht, muss sofort ein neuer starten. Wenn der Traffic ansteigt, musst du mehr Container hochfahren und den Network Load gleichmäßig verteilen. Das kannst du nicht manuell über Hunderte von Maschinen hinweg managen. Google stand vor genau diesem Problem, lange vor dem Rest der Industrie. Sie bauten einen internen Container Cluster Manager namens Borg, um die Orchestration von Hunderttausenden von Jobs zu automatisieren. Als klar wurde, dass der Rest der Softwarewelt dieselbe Capability brauchte, starteten Google-Engineers ein Open-Source-Projekt, basierend auf den Lessons Learned von Borg. Sie gaben ihm eine Star-Trek-Referenz und nannten es ursprünglich Project Seven of Nine, eine Anspielung auf eine Borg-Drohne, die dem Kollektiv entkommen war. Dieses Projekt wurde schließlich als Kubernetes gelauncht. Das Steuerrad-Logo, das du heute siehst, hat sieben Speichen als kleines Tribute an diesen ursprünglichen Projektnamen. Das ist der Teil, auf den es ankommt. Kubernetes bietet dir ein Framework, um Distributed Systems resilient auszuführen. Es kümmert sich um Scaling und Failover für deine Application. Wenn ein Container crasht, ersetzt Kubernetes ihn. Wenn ein Node ausfällt, rescheduled es die Container auf gesunde Nodes. Es übernimmt die Service Discovery, was bedeutet, dass ein Container über einen DNS-Namen oder seine eigene IP-Adresse gefunden werden kann, und es balanced den Load, sodass kein einzelner Container überlastet wird. Es managt auch die Storage Orchestration, wodurch du lokalen Storage oder Cloud Provider automatisch mounten kannst, und es automatisiert Rollouts und Rollbacks. Du beschreibst den Desired State deiner deployed Container, und Kubernetes ändert den Actual State in den Desired State mit einer kontrollierten Rate. Du schreibst keine Scripts, um den Server State zu managen; du deklarierst, was du willst, und das System setzt es um. Das Core Takeaway hier ist, dass Kubernetes nicht nur ein Hosting Environment ist, es ist ein Control Loop, der ständig die Realität mit deinen Erwartungen abgleicht und die Differenz korrigiert. Bevor wir zum Schluss kommen: Wenn du uns helfen willst, weiterhin diese Episoden zu machen, such nach DevStoriesEU auf Patreon – wir schätzen den Support. Das war's für diese Folge. Danke fürs Zuhören und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. Kubernetes & Helm Fundamentals, Folge 2 von 10. Du hast Dutzende Server, auf denen Hunderte von Containern laufen. Wenn eine Maschine plötzlich ausfällt, muss irgendetwas entscheiden, wo diese verwaisten Workloads als Nächstes landen. Ein Orchester ohne Dirigent ist nur Lärm, und eine Flotte von Containern ohne ein zentrales Gehirn ist unkontrollierbares Chaos. Dieses zentrale Gehirn bildet zusammen mit den Maschinen, die die eigentliche Arbeit verrichten, die Kubernetes Cluster Architecture. Ein Kubernetes-Cluster ist in zwei klare Hälften unterteilt. Du hast die Control Plane, die als Gehirn fungiert, und du hast die Worker Nodes, die die Muskeln spielen lassen. Die Control Plane trifft alle globalen Entscheidungen, wie das Scheduling von Workloads, und sie erkennt und reagiert auf Cluster-Events. Die Worker Nodes hosten deine Applications und führen die Anweisungen aus, die von der Control Plane gesendet werden. Jeder Cluster muss mindestens eine Worker Node haben, um Applications auszuführen. Schauen wir uns zuerst die Control Plane an. Ihre wichtigste Komponente ist der kube-apiserver. Zuhörer hören manchmal API-Server und stellen sich einen normalen Webserver vor, der HTTP-Requests für eine Application verarbeitet. Aber genau das ist er nicht. Der kube-apiserver ist das zentrale Nervensystem des gesamten Clusters. Er ist das Frontend der Control Plane. Jede einzelne Kommunikation, egal ob sie von einem menschlichen Operator, einer Worker Node oder einer internen Komponente kommt, wird über diesen API-Server geroutet. Weil der API-Server komplett stateless ist, braucht der Cluster ein Gedächtnis. Das ist etcd. Das ist ein konsistenter, hochverfügbarer Key-Value-Store, der alle Cluster-Daten enthält. Wann immer eine Konfiguration erstellt wird oder sich ein System State ändert, liegt der wahre Record dieser Änderung in etcd. Als Nächstes kommt der kube-scheduler. Wenn du den Cluster anweist, einen neuen Container-Workload auszuführen, ist dieser Workload anfangs noch keiner Maschine zugewiesen. Der Scheduler entdeckt diesen nicht zugewiesenen Workload. Er evaluiert Resource Requirements, Hardware Constraints und Policy Rules und weist den Workload dann der am besten geeigneten Worker Node zu. Zu guter Letzt hast du den kube-controller-manager. Diese Komponente führt kontinuierliche Background-Loops aus, die Controller genannt werden. Diese Controller beobachten über den API-Server ständig den Current State des Clusters und arbeiten aktiv daran, diesen Current State in Richtung deines Desired States zu pushen. Wenn eine Worker Node abstürzt, bemerkt der Controller Manager die fehlende Maschine und triggert die Response, um die verlorenen Workloads zu ersetzen. So viel zum Gehirn. Schauen wir uns nun die Worker Nodes an, die die Tasks ausführen. Node-Komponenten laufen auf jeder einzelnen Worker-Maschine, um das Runtime Environment aufrechtzuerhalten. Die kritischste Komponente hier ist das kubelet. Das ist ein Agent, der auf jeder Node läuft und direkt mit der Control Plane kommuniziert. Das kubelet nimmt Anweisungen vom API-Server entgegen und stellt sicher, dass die erforderlichen Container auf seiner spezifischen Maschine auch wirklich laufen und healthy sind. Das kubelet startet die Container nicht selbst. Es delegiert diesen Task an die Container Runtime. Die Runtime ist die eigentliche Software, wie containerd, die dafür verantwortlich ist, Container Images aus einer Registry zu pullen und die Prozesse auf dem Betriebssystem zu starten. Zu guter Letzt gibt es noch den kube-proxy. Das ist ein Network Proxy, der auf jeder Node läuft. Er verwaltet die lokalen Netzwerkregeln, die es der Netzwerkkommunikation erlauben, deine Container von innerhalb oder außerhalb des Clusters zu erreichen. Hier ist die wichtigste Erkenntnis. Die Control Plane diktiert, was passieren soll, aber sie führt niemals den Application Code aus. Die Worker Nodes führen den Application Code aus, aber sie verlassen sich komplett auf die Control Plane, um ihnen zu sagen, was sie ausführen sollen. Diese strikte Trennung von Entscheidungsfindung und Ausführung ist es, was es Kubernetes erlaubt, horizontal zu skalieren und sich automatisch von Hardware-Ausfällen zu erholen. Das war's für diese Folge. Danke fürs Zuhören und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. Kubernetes & Helm Fundamentals, Folge 3 von 10. Du baust einen Container, testest ihn lokal und übergibst ihn an Kubernetes zum Ausführen. Aber Kubernetes weigert sich strikt, direkt mit deinem Container zu arbeiten. Stattdessen verlangt es, dass du ihn zuerst in eine völlig andere Abstraktion wrappst. Wir entmystifizieren Pods, die eigentliche Unit of Work in diesem Ökosystem. Wenn Container die einsamen Wale der traditionellen Container-Welt sind, dann sind Pods die zusammenhängenden Gruppen, in denen sie gemeinsam schwimmen. Ein Pod ist das kleinste, grundlegendste deploybare Objekt, das du in Kubernetes erstellen und verwalten kannst. Er repräsentiert eine einzelne Instanz eines laufenden Prozesses in deinem Cluster. Du fragst dich vielleicht, warum Kubernetes diesen extra Layer einführt, anstatt Container einfach direkt zu verwalten. Die Antwort liegt in der Abstraktion und dem Shared Context. Kubernetes braucht einen einheitlichen Weg, um Networking, Storage und Scheduling zu handhaben, unabhängig davon, welche spezifische Container Runtime du darunter verwendest. Indem du Container in einen Pod wrappst, behandelt Kubernetes den Pod als logischen Host. Hier ist die wichtigste Erkenntnis: Ein Pod wrappt nicht einfach nur einen einzelnen Container; er etabliert ein Shared Execution Environment. Während ein Pod oft nur einen Container enthält, kann er mehrere Container aufnehmen, die eng zusammenarbeiten müssen. Wenn mehrere Container im selben Pod platziert werden, ist garantiert, dass sie auf exakt derselben physischen oder virtuellen Maschine gescheduled werden. Noch wichtiger ist, dass diese Container denselben Network Namespace teilen. Jeder Container innerhalb eines einzelnen Pods teilt sich eine einzige IP-Adresse und einen einzigen Port Space. Weil sie im selben Network Context existieren, können sie einfach über localhost miteinander kommunizieren. Es gibt keinen Bedarf für interne DNS Lookups oder komplexes Service Routing, nur damit zwei lokale Prozesse miteinander reden können. Wenn Container A an Port 8000 bindet, kann Container B im selben Pod ihn unter localhost Port 8000 erreichen. Dieser Shared Context erstreckt sich auch auf Storage. Du kannst Shared Storage Volumes auf Pod-Ebene definieren. Sobald sie definiert sind, kann jeder Container in diesem Pod diese Shared Volumes in sein eigenes File System mounten. Das erlaubt es tightly coupled Containern, nahtlos exakt dieselben Dateien zu lesen und zu schreiben. Stell dir einen primären Webserver-Container vor. Sein Job ist es, HTTP Traffic zu serven, aber er schreibt auch raw Access Logs in ein lokales Directory. Du willst diese Logs an ein zentrales Monitoring-System shippen, aber du willst dein Webserver-Image nicht mit Logging Agents und Config-Files aufblähen. Stattdessen erstellst du einen zweiten Container, ein leichtgewichtiges Logging Utility. Du deployst sowohl den Webserver als auch den Logging-Container in exakt denselben Pod. Der Webserver schreibt seine Logs in ein Shared Storage Volume. Der Logging-Container, der als Sidecar agiert, mountet dasselbe Volume, liest die eingehenden Log-Files und streamt sie an dein Monitoring-System. Sie arbeiten als eine integrierte Einheit und teilen sich Ressourcen, ohne ihre individuellen Verantwortlichkeiten zu vermischen. Wenn du entscheidest, ob zwei Container in denselben Pod gehören, frag dich, ob sie zwingend auf exakt derselben Maschine landen und einen identischen Lifecycle teilen müssen. Wenn sie nicht absolut zwingend zusammen deployt werden, starten und sterben müssen, gehören sie in separate Pods. Das war's für diese Folge. Danke fürs Zuhören und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. Kubernetes & Helm Grundlagen, Folge 4 von 10. Du schläfst. Um drei Uhr morgens legt ein Memory Leak deinen Main Application Server lahm. In einem traditionellen Setup wird ein Alert ausgelöst, und du wachst auf, um den Prozess manuell neu zu starten. In Kubernetes übernimmt das System diese Nachtschicht für dich. Das ist die Power von State-Management mit Deployments. Ein Deployment bietet deklarative Updates für deine Applications. Anstatt Skripte zu schreiben, die dem System Schritt für Schritt vorgeben, wie deine Software laufen soll, beschreibst du exakt, wie das Endergebnis aussehen soll. Du übergibst diesen Desired State an den Deployment Controller, und er passt den Actual State kontrolliert daran an. Um zu verstehen, wie das funktioniert, musst du die Hierarchie kennen. Du erstellst selten einzelne Pods direkt. Stattdessen erstellst du ein Deployment. Das Deployment erstellt dann ein sekundäres Objekt, ein sogenanntes ReplicaSet. Das ReplicaSet ist der Mechanismus, der strikt dafür verantwortlich ist, dass zu jedem Zeitpunkt genau die festgelegte Anzahl an Pod Replicas läuft. Wenn eine Server Node ausfällt oder ein Pod wegen dieses Memory Leaks crasht, merkt das ReplicaSet, dass die Anzahl unter deinen Desired State gefallen ist. Es startet sofort einen neuen Pod, um den verlorenen zu ersetzen. Das ist dein Self-Healing-Mechanismus. Du greifst nie ein. Dieselbe Logik gilt fürs Scaling. Wenn der Traffic ansteigt, updatest du deine Deployment-Datei und forderst fünf statt drei Replicas an. Der Controller sieht die Diskrepanz zwischen deinem Request und der Realität und weist das ReplicaSet an, zwei weitere Pods zu starten. Dieser deklarative Ansatz ist besonders bei Application Updates extrem wichtig. Sagen wir, du hast drei Pods am Laufen, mit einem Nginx-Image auf Version 1.14. Du musst auf Version 1.16 upgraden, ohne User Traffic zu droppen. Du updatest einfach die Image-Version in deiner Deployment-Konfiguration. Das Deployment terminiert nicht alle deine alten Pods auf einmal. Stattdessen erstellt es ein brandneues ReplicaSet speziell für Version 1.16. Dann beginnt es ein Rolling Update. Es startet einen neuen Pod im neuen ReplicaSet. Sobald dieser neue Pod healthy ist, skaliert es das alte ReplicaSet herunter, indem es einen Version 1.14 Pod terminiert. Es wiederholt diesen vorsichtigen, gestaffelten Prozess, bis alle drei alten Pods weg sind und drei neue Pods laufen. Die Transition ist komplett nahtlos. Was passiert nun, wenn das Update broken ist? Hier ist die entscheidende Erkenntnis. Weil der Deployment Controller diese ReplicaSets orchestriert, gibt er dir ein eingebautes Sicherheitsnetz. Wenn du den Image-Namen versehentlich als Nginx 1.16-typo eintippst, crashen die neuen Pods beim Startup. Das Deployment erkennt den Fehler und stoppt den Rollout sofort. Es lässt deine verbleibenden alten Pods weiterlaufen, sodass deine Application online bleibt. Sobald du den Fehler bemerkst, kannst du einen Rollback-Befehl ausführen. Das Deployment skaliert das alte, known-good ReplicaSet einfach wieder hoch und skaliert das broken ReplicaSet auf null herunter. Die wahre Stärke eines Deployments ist nicht nur das Launchen von Containern, sondern sein unermüdlicher Continuous Loop, der vergleicht, was du angefordert hast, mit dem, was tatsächlich existiert, und die Realität zwingt, sich daran anzupassen. Ich möchte mir kurz einen Moment nehmen, um dir fürs Zuhören zu danken – das hilft uns sehr. Mach's gut!

Hallo, hier ist Alex von DEV STORIES DOT EU. Kubernetes & Helm Grundlagen, Folge 5 von 10. Pods sind sterblich. Sie stürzen ab, skalieren runter, werden evicted, und wenn sie ersetzt werden, bekommen sie eine komplett neue IP-Adresse. Wenn deine Anwendung versucht, mit ihnen zu kommunizieren, schießt du ständig auf ein bewegliches Ziel. Kubernetes Services lösen genau dieses Problem. Stell dir eine typische Webanwendung vor. Du hast ein Frontend-Deployment und eine Backend-Datenbank. Wenn dein Datenbank-Pod neu startet, fährt die Cluster Control Plane einen neuen Pod als Ersatz hoch. Diesem neuen Pod wird eine völlig andere IP-Adresse im Cluster-Netzwerk zugewiesen. Wenn dein Frontend so konfiguriert war, dass es direkt mit der alten IP kommuniziert, bricht die Verbindung ab und deine Anwendung bricht zusammen. Du kannst dich für nichts Dauerhaftes auf einzelne Pod-IPs verlassen. Ein Kubernetes Service ist eine Abstraktion, die einer dynamischen Gruppe von Pods eine stabile, langlebige Netzwerkidentität bietet. Wenn du einen Service erstellst, wird ihm eine IP-Adresse zugewiesen, die sich nie ändert, solange der Service existiert. Deine Frontend-Anwendung muss nicht in jeder Sekunde genau tracken, welche Datenbank-Pods gerade am Leben sind. Sie sendet den Traffic einfach an die Service-IP. Außerdem weist der Cluster dem Service einen stabilen DNS-Namen zu. Dein Frontend-Code kann sich einfach mit einem simplen Hostnamen verbinden, und der Cluster löst das automatisch in die richtige IP-Adresse auf. Im Hintergrund fungiert der Service als interner Load Balancer. Er verlässt sich auf eine Komponente namens kube-proxy, die auf jedem Node läuft, um die eigentlichen Routing-Regeln zu implementieren. Wenn Traffic beim Service ankommt, wird er an einen der healthy Pods weitergeleitet, die dahinterstehen. Um einen Service mit den richtigen Pods zu verknüpfen, benutzt du Labels und Selectors. Du könntest den Service mit einem Selector konfigurieren, der nach dem Label sucht, das eine Datenbankanwendung kennzeichnet. Der Service überwacht den Cluster ständig. Wenn ein Datenbank-Pod stirbt, wird seine IP aus dem aktiven Pool entfernt. Wenn der Ersatz-Pod hochfährt, wird seine neue IP hinzugefügt. Die Frontend-Anwendung bekommt überhaupt nicht mit, dass sich die zugrunde liegende Netzwerktopologie gerade verändert hat. Es gibt ein paar Wege, einen Service zu exposen, je nachdem, woher der Traffic kommt. Der Standardtyp ist ClusterIP. Ein ClusterIP Service bekommt eine interne IP-Adresse, die nur von innerhalb des Clusters erreichbar ist. Das ist die richtige Wahl für deine Backend-Datenbank, um sie sicher von der Außenwelt isoliert zu halten. Aber dein Frontend muss Traffic von externen Usern empfangen. Dafür änderst du den Service-Typ auf LoadBalancer. Wenn du einen LoadBalancer Service erstellst, kommuniziert Kubernetes mit deinem Cloud-Provider, um einen standardmäßigen externen Load Balancer zu provisionieren. Externer Internet-Traffic trifft auf diese Cloud-Ressource, welche die Verbindung in deinen Cluster weiterleitet, sie durch den Service und schließlich zu deinen Frontend-Pods leitet. Hier ist die wichtigste Erkenntnis. Services entkoppeln die adressierbare Identität deiner Anwendung von den physischen Workloads, die die Logik tatsächlich ausführen. Du hörst auf, an spezifische, fragile Instanzen zu routen, und fängst an, an ein robustes, persistentes Konzept zu routen. Das war's für diese Folge. Danke fürs Zuhören, und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. Kubernetes & Helm Fundamentals, Folge 6 von 10. Du willst eine einzelne Anwendung deployen, musst aber am Ende hunderte Zeilen statisches YAML über verschiedene Deployments, Services und Ingresses hinweg managen. Wenn du dieselbe Anwendung in eine Staging-Umgebung pushen musst, kopierst du diese Dateien in ein neues Verzeichnis und ersetzt manuell Image-Tags und Hostnames. Das ist fehleranfällig, extrem repetitiv und unmöglich zu maintainen, wenn deine Infrastruktur wächst. Genau dieses Problem löst Helm. Helm ist der Package Manager für Kubernetes. Du kannst ihn dir wie apt, yum oder Homebrew vorstellen, aber speziell für Kubernetes-Ressourcen designt. Anstatt deine Anwendung als lose Sammlung unabhängiger YAML-Manifests zu behandeln, bündelt Helm sie zu einer einzigen, zusammenhängenden Einheit. Dieses Packaging-Format wird Chart genannt. Ein Chart ist im Wesentlichen ein Verzeichnis mit Dateien, die ein zusammengehöriges Set von Kubernetes-Ressourcen beschreiben. Es enthält alle Definitionen, die deine Anwendung zum Laufen braucht. Der primäre Mechanismus, der ein Chart so nützlich macht, ist Templating. Rohe Kubernetes-Manifests sind komplett statisch. Ein Helm-Chart hingegen ersetzt hardcodierte Infrastruktur-Details durch Template-Variablen. Anstatt einen spezifischen Replica Count, ein festes Container-Image-Tag oder eine bestimmte Environment Variable direkt in ein Deployment-File zu schreiben, definierst du Platzhalter. Wenn es Zeit für das Deployment ist, mergt Helm diese Templates mit einem separaten File, das deine spezifischen Values enthält. Diese Architektur bedeutet, dass du immer nur ein einziges Chart für deine Anwendung maintainst. Du übergibst ihm einfach unterschiedliche Konfigurationsparameter, je nachdem, ob du lokal, nach Staging oder in Production deployst. Wenn du ein Chart nimmst, es mit deinen spezifischen Configuration Values kombinierst und in einem Kubernetes-Cluster deployst, erstellst du das, was Helm ein Release nennt. Hier wird es interessant. Ein Chart ist nur der generische Blueprint. Ein Release ist die tatsächlich deployte Instanz, die in deinem Cluster läuft. Wegen dieser strikten Trennung zwischen Blueprint und Instanz kannst du exakt dasselbe Chart mehrmals in exakt demselben Cluster installieren. Wenn du drei separate Instanzen eines Caching-Servers brauchst, duplizierst du nicht das YAML. Du installierst das Caching-Chart dreimal. Helm trackt jede Installation als eigenständiges Release mit seinem eigenen, eindeutigen Namen, seinen eigenen Configuration Values und seinem eigenen, isolierten Lifecycle. Helm trackt außerdem den State und die History dieser Releases innerhalb des Clusters. Wenn du eine Anwendung updatest, indem du ein neues Image-Tag übergibst oder ein Setting änderst, evaluiert Helm die Unterschiede und erstellt eine neue Revision von genau diesem Release. Es wendet nur die notwendigen Änderungen auf die zugrundeliegenden Kubernetes-Ressourcen an. Wenn ein Update fehlschlägt oder eine Anwendung anfängt, sich seltsam zu verhalten, weist du Helm an, einen Rollback auf eine vorherige Revision zu machen. Helm weiß genau, welche Kubernetes-Ressourcen zu welcher Version deiner Anwendung gehören, und behandelt das Erstellen, Ändern und Löschen dieser Ressourcen als eine einzige Operation. Der entscheidende Shift bei Helm ist Abstraktion. Du hörst auf, unabhängige Textdateien zu managen, die unzusammenhängende Pods, Services und Volumes repräsentieren, und fängst an, komplette Anwendungen zu deployen, zu konfigurieren und upzugraden. Danke fürs Zuhören, Happy Coding zusammen!

Hallo, hier ist Alex von DEV STORIES DOT EU. Kubernetes & Helm Fundamentals, Folge 7 von 10. Du musst ein Datenbankpasswort aktualisieren, aber die Credentials sind in fünfzehn verschiedenen YAML-Files hardcoded. Ein File vergessen, und das komplette Deployment schlägt fehl. Konfigurationen direkt in deine Deployment-Struktur zu hardcoden, ist fehleranfällig. Die Lösung ist, die Anatomie eines Helm Charts zu verstehen. Ein Helm Chart ist ein standardisiertes Package, das alle Resource Definitions enthält, die nötig sind, um eine Application, ein Tool oder einen Service in einem Kubernetes Cluster auszuführen. Das gesamte System basiert auf einer zentralen Philosophie: einer strikten Trennung zwischen struktureller Definition und umgebungsspezifischer Konfiguration. Du definierst die Struktur deines Deployments einmalig und injizierst die spezifischen Details, wenn es Zeit für das Deployment ist. Wenn du in ein Helm Chart schaust, findest du ein spezifisches Directory Layout. Der Top-Level-Folder ist immer nach dem Chart selbst benannt. In diesem Folder befinden sich drei Kernkomponenten, die das Packaging-System steuern. Die erste ist ein File namens Chart Punkt yaml. Das ist der Metadata Hub. Es sagt Helm ganz genau, was das Package ist. Es enthält die API Version für den Chart-Standard, den Chart-Namen, eine Description und Versionsnummern. Ganz wichtig: Es trackt sowohl die Version des Charts selbst als auch die App Version, also die Version der tatsächlichen Software, die deployed wird. Vielleicht findest du daneben auch ein charts Directory, das alle Subcharts enthält, von denen deine Application abhängt, aber das Metadata-File ist der primäre Identifier. Die zweite Kernkomponente ist das templates Directory. Hier lebt die strukturelle Definition. Darin platzierst du deine Standard Kubernetes Manifest Files, wie Deployments und Services. Aber anstatt statisches YAML zu schreiben, enthalten diese Files Go Template Logic. Anstatt einen Replica Count von drei zu hardcoden oder ein spezifisches Datenbankpasswort reinzukopieren, schreibst du eine Template Directive. Diese Directive weist Helm an, den benötigten Value während des Deployments dynamisch nachzuschlagen. Die dritte Komponente beantwortet diese dynamischen Lookups. Es ist ein File namens values Punkt yaml, das im Root des Chart Directorys neben dem Metadata-File liegt. Dieses File enthält die Default Configuration Settings. Wenn ein Template nach einem Image Repository, einer Portnummer oder einem Passwort fragt, liefert das Values File die Baseline-Antwort. Hier ist die wichtigste Erkenntnis: Die Templates diktieren die Architektur deiner Application, während die Values diktieren, wie sich diese Architektur in einer spezifischen Umgebung verhält. Wenn du einen Install Command ausführst, nimmt Helm die rohen Templates, führt sie mit dem Values File zusammen und rendert finale, valide Kubernetes Manifests. Dann sendet es diese gerenderten Manifests an die Kubernetes API. Diese Trennung ist es, was Charts hochgradig wiederverwendbar macht. Stell dir ein Szenario vor, in dem du exakt dieselbe Application sowohl in eine Staging Environment als auch in eine Production Environment deployen musst. Du kopierst und veränderst das Chart nicht. Du nutzt exakt dieselbe Directory-Struktur und exakt dieselben Templates. Für das Staging Deployment übergibst du Helm während des Install Commands ein Custom Values File. Dieses File überschreibt die Defaults und spezifiziert ein Pod Replica, eine lokale Test-Datenbank-URL und Debug-Level Logging. Wenn du auf Production deployest, übergibst du ein komplett anderes Values File. Dieses Production File spezifiziert zehn Replicas, eine Managed Database URL und strikte Resource Constraints. Helm führt das einzelne Set an Templates mit den jeweiligen Custom Values Files zusammen und produziert so zwei komplett unterschiedliche Deployment Profiles. Die Power eines Helm Charts liegt nicht im YAML, das es enthält, sondern in den Grenzen, die es zieht. Es fixiert die Infrastructure Architecture in den Templates, während es die Operational Details in den Values komplett fluide hält. Das war's für diese Folge. Danke fürs Zuhören und keep building!

Hallo, hier ist Alex von DEV STORIES DOT EU. Kubernetes & Helm Fundamentals, Folge 8 von 10. Nur weil du jede einzelne Zeile eines Kubernetes Manifests templaten kannst, heißt das nicht, dass du es auch tun solltest. Wenn du versuchst, jedes Feld konfigurierbar zu machen, endest du mit einem Chart, das niemand mehr lesen, geschweige denn maintainen kann. In dieser Folge geht es um Helm Chart Best Practices – die Regeln, die verhindern, dass deine Configurations unter ihrem eigenen Gewicht zusammenbrechen. Die größte Falle bei der Chart-Erstellung ist Over-Templating. Viele Developer behandeln Helm Templates wie ein einfaches Text Replacement Script. Das ist ein häufiges Missverständnis. Helm führt eine Go Template Engine aus, um strukturiertes, valides YAML zu erzeugen. Wenn du eine Variable in ein File packst, ohne Einrückung und Datentypen sorgfältig zu managen, wird das generierte YAML komplett kaputtgehen. Deswegen solltest du nur die Values templaten, die sich zwischen den Environments wirklich ändern. Denk an Image Tags, Replicas, Resource Limits oder Ingress Rules. Lass die grundlegenden strukturellen Felder hardcoded. Wenn ein User einen bestimmten Security Context oder Volume Mount nie ändern muss, expose ihn nicht als Variable. Das values punkt yaml File dient als Public API für dein Chart. Wenn du dieses File organisierst, musst du die Balance zwischen Struktur und Usability finden. Die offizielle Empfehlung ist, die Hierarchie so flach wie möglich zu halten. Auch wenn du zusammengehörige Parameter gruppieren solltest, vermeide Deep Nesting. Denk an den User, der Overrides über die Command Line übergibt. Ihn zu zwingen, einen durch Punkte getrennten Pfad fünf Level tief einzutippen, nur um eine Portnummer zu ändern, sorgt für unnötige Friction. Wenn du eine Webserver-Konfiguration hast, pack die Properties unter einen einzigen Server Key, aber halte die internen Properties flach. Wenn du diese Variablen benennst, nutze immer Camel Case. Starte mit einem Kleinbuchstaben und schreibe den ersten Buchstaben jedes folgenden Wortes groß. Verwende keine Dashes oder Underscores in deinem Values File. Du könntest eine Variable namens externalPort erstellen, anstatt external dash port. Konsistentes Camel Case verhindert Parsing Errors während des Template Renderings und entspricht den Standards des Kubernetes Ecosystems. Achte außerdem auf strikte Type Consistency. Wenn ein Parameter in Kubernetes ein Integer ist, wie eine Portnummer, lass ihn in deinem Values File als Integer. Pack ihn nicht in Quotes und mach ihn zu einem String. Diese Konsistenz gilt direkt dafür, wie du die Resources taggst, die dein Chart generiert. Jedes Object braucht Standard Labels. Helm Best Practices schreiben die Nutzung der offiziellen Kubernetes App Labels vor. Nutze im Speziellen das app punkt kubernetes punkt io Prefix. Das name Label sollte auf den Chart Name mappen, während das instance Label auf den Release Name mappen sollte. Du fügst auch das version Label hinzu und merkst an, dass die Resource von Helm gemanagt wird. Wenn du genau diese Labels auf jedes Deployment, jeden Pod, jeden Service und jede Config Map anwendest, stellst du sicher, dass externe Monitoring Tools und Service Meshes deine Application Components automatisch und ohne manuelle Configuration discovern und gruppieren können. Hier ist die entscheidende Erkenntnis. Das beste Helm Chart ist nicht das mit den meisten Configuration Options. Es ist das, das die wenigsten Overrides braucht, um out of the box erfolgreich zu laufen. Wenn du helfen willst, die Show am Laufen zu halten, such nach DevStoriesEU auf Patreon – wir schätzen den Support wirklich sehr. Danke, dass du ein paar Minuten mit mir verbracht hast. Bis zum nächsten Mal, mach's gut.

Hallo, hier ist Alex von DEV STORIES DOT EU. Kubernetes & Helm Fundamentals, Folge 9 von 10. Einen Cluster von Grund auf aufzubauen, ist eine super Lernübung. Aber wenn du auf Hunderte von Microservices skalierst, willst du die Control Plane nicht selbst verwalten. Du willst, dass der Cloud-Provider die schwere Arbeit übernimmt, damit sich deine Entwickler darauf konzentrieren können, Code zu shippen. Genau so sieht eine Enterprise-Azure-Implementierung von Kubernetes und Helm aus. In einer Standard-Kubernetes-Architektur hast du eine Control Plane, die globale Entscheidungen trifft, und Worker Nodes, die diese ausführen. Diese Control Plane hochverfügbar zu halten, ist bekanntermaßen schwierig. Ein Enterprise-Kunde, der auf Azure deployt, nutzt typischerweise den Azure Kubernetes Service, oder kurz AKS. AKS abstrahiert die Control Plane. Azure managt den API-Server, den Scheduler und den Key-Value Data Store. Dein Ops-Team ist nur für die Worker Nodes verantwortlich, auf denen deine Anwendungen tatsächlich laufen. Wie kommt also eine Anwendung vom Rechner eines Entwicklers auf diese Worker Nodes? Hier kommt Helm in den Workflow. Eine Enterprise-Anwendung besteht selten aus einem einzigen Container. Meistens ist sie eine Sammlung von Microservices, von denen jeder seine eigenen Deployments, Services und Konfigurationen braucht. Anstatt Dutzende statischer YAML-Files zu managen, packen Entwickler diese Ressourcen in ein Helm Chart. Ein Chart dient als zentraler, versionierter Blueprint für einen Microservice. Weil Helm Templates nutzt, können Entwickler die Strukturlogik einmal schreiben und unterschiedliche Konfigurationswerte einsetzen, je nachdem, ob sie auf einen Development-, Staging- oder Production-Cluster deployen. Bevor irgendetwas läuft, wird der Application Code in Container Images gebaut. Diese Images werden an einen sicheren Speicherort gepusht, wie eine Container Registry. Auch Helm Charts selbst können gepackt und in eine Registry gepusht werden. Dadurch können Enterprise-Teams ihre Infrastructure Definitions genau wie ihren kompilierten Application Code behandeln. Hier ist die wichtigste Erkenntnis: Wenn eine Release Pipeline ein Deployment triggert, evaluiert Helm seine Templates mit den umgebungsspezifischen Values und sendet die finalen Manifests an den AKS API-Server. Die AKS Control Plane liest diesen Desired State und beginnt damit, Pods auf deine Worker Nodes zu schedulen. Die Nodes verbinden sich mit der Container Registry, authentifizieren sich sicher, pullen die spezifischen Image-Versionen und starten die Container. Kubernetes überwacht diesen State kontinuierlich. Wenn eine Worker Node abstürzt, rescheduled die Control Plane ihre Pods sofort auf gesunde Nodes, um den im Helm Chart definierten Replica Count aufrechtzuerhalten. Sobald die Pods laufen, müssen sie Traffic empfangen. Ein Helm Chart enthält typischerweise eine Service-Definition, um die Anwendung zu exposen. Wenn das auf AKS deployt wird, spricht Kubernetes direkt mit der zugrunde liegenden Azure-Infrastruktur. Wenn der Service einen Public Entry Point anfordert, provisioniert AKS automatisch einen Azure Load Balancer. Dieser Load Balancer nimmt eingehenden externen Traffic entgegen und routet ihn sicher in den Cluster, wo er auf die gesunden Pods verteilt wird. Deine Entwickler mussten nie das Azure Portal anfassen oder spezifische Cloud Routing Rules schreiben. Sie haben einfach einen Standard-Kubernetes-Service in ihrem Helm Chart definiert, und die Managed Platform hat das physische Network Provisioning übernommen. Die wahre Stärke dieser Enterprise-Architektur ist die saubere Separation of Concerns. Helm standardisiert, wie die Anwendung über verschiedene Umgebungen hinweg definiert wird, die Registry sichert die versionierten Artefakte, und die Managed Cloud Platform stellt sicher, dass die zugrunde liegende Infrastruktur auch wirklich am Leben bleibt, um sie auszuführen. Danke, dass du ein paar Minuten mit mir verbracht hast. Bis zum nächsten Mal, mach's gut.

Hallo, hier ist Alex von DEV STORIES DOT EU. Kubernetes & Helm Fundamentals, Folge 10 von 10. Du hast die Theorie und die Tools. Aber wenn du auf ein leeres Terminal starrst, fühlt sich die Kluft zwischen massiver Cloud-Infrastruktur und deinem Laptop unglaublich groß an. Genau diese Kluft zu schließen, ist das Ziel, wenn du mit Minikube loslegst. Ein Production Kubernetes Cluster besteht aus mehreren Maschinen, die als Control Planes und Worker Nodes fungieren. Das in der Cloud zu provisionieren, kostet Geld, braucht Zeit und erfordert eine komplexe Netzwerk-Konfiguration. Als Solo-Developer oder kleines Team, das eine Day-One-Architektur entwirft, brauchst du eine lokale Umgebung, die sich exakt wie Production verhält – ohne den ganzen Overhead. Minikube ist eine leichtgewichtige Kubernetes-Implementierung, die eine Virtual Machine oder einen Container direkt auf deinem Laptop erstellt. In dieser isolierten Umgebung deployed es einen simplen Single-Node Cluster. Normalerweise trennt Kubernetes die Control Plane, die den State des Clusters managed, von den Worker Nodes, auf denen deine Application Container laufen. Minikube kombiniert sie. Auf deiner lokalen Maschine läuft ein Node, der sowohl die Management-Logik als auch die eigentlichen Application Workloads übernimmt. Er ist nicht dafür gedacht, Production Traffic zu bedienen. Er existiert nur, damit du deine Container Orchestration sicher testen kannst. Hier ist die wichtigste Erkenntnis. Das Interface, das du benutzt, um mit Minikube zu interagieren, ist identisch mit dem für einen riesigen Cloud Cluster. Du benutzt das Command-Line Tool namens kubectl. Wenn du einen kubectl Command ausführst, kommuniziert dieser direkt über seine API mit der Minikube Control Plane. Es gibt keine spezielle Syntax, die du für die lokale Entwicklung lernen musst. Der Workflow passt perfekt zum offiziellen Kubernetes Basics Tutorial. Du initiierst den Cluster mit einem simplen start Command. Minikube provisioniert die Umgebung und konfiguriert kubectl automatisch so, dass es auf deine neue lokale Instanz zeigt. Von da an benutzt du kubectl, um ein Deployment zu erstellen. Du sagst der Control Plane, dass sie ein bestimmtes Container Image pullen und ausführen soll. Sobald sie deployed ist, läuft deine Application in einem Pod auf diesem Single Node. Sie ist jedoch von deinem Host Network isoliert. Um von deinem Laptop-Browser darauf zuzugreifen, musst du sie exposen, indem du einen Service erstellst. Ein Service routet den Traffic von einem bestimmten Port auf deiner lokalen Maschine zum richtigen Port auf dem Pod, der in Minikube läuft. Ab diesem Punkt kannst du jede Core-Funktion von Kubernetes üben. Du kannst deine Application skalieren, indem du kubectl sagst, den Replica Count zu erhöhen. Minikube wird dann zusätzliche Pods neben dem ersten hochfahren. Du kannst Rolling Updates üben, indem du die Container Image Version in deinem Deployment änderst. Minikube wird die alten Pods gracefully terminieren und neue starten, was ein Zero-Downtime Deployment simuliert. Weil Minikube eine Standard Kubernetes API exposed, integriert sich dein externes Tooling nahtlos. Helm funktioniert sofort. Du kannst komplexe Datenbanken, Ingress Controller oder Message Queues mithilfe von Helm Charts exakt so installieren, wie du es in einer Live-Umgebung tun würdest. Minikube enthält sogar integrierte Addons, wie ein lokales Web Dashboard, mit dem du deinen Cluster State visuell inspizieren, Logs lesen und die Resource Usage monitoren kannst. Die wahre Stärke eines lokalen Clusters ist Parity. Wenn du eine Deployment Configuration oder ein Helm Chart schreibst, das erfolgreich auf Minikube läuft, hast du bereits die exakte Configuration geschrieben, die in der Cloud laufen wird. Nimm dir die Zeit, die offizielle Kubernetes Documentation zu erkunden und diese Commands hands-on auszuprobieren. Wenn du Vorschläge für Themen hast, die wir in unserer nächsten Serie behandeln sollen, besuche devstories dot eu und lass es uns wissen. Das war's für heute. Danke fürs Zuhören, geh und bau etwas Cooles.