Heute sprechen wir über etwas, von dem fast jeder schon einmal gehört hat, das aber niemand erklären kann. Kubernetes. Es ist verwirrend, weil es ein Problem löst, das die meisten erst bemerken, wenn sie mitten darin stecken. Jeder weiß, dass es wichtig ist, aber fragt man nach dem Nutzen, erntet man nur ratlose Blicke. Es ist kein Ersatz für Docker oder ein Cloud-Betriebssystem, auch wenn viele das vermuten. Die Verwirrung ist verständlich, denn Kubernetes löst ein Problem, von dem man nichts weiß, bis man selbst damit konfrontiert wird. Es ist ein Werkzeug, das unverzichtbar wird, sobald man mehr als eine Handvoll Container verwalten muss. Am Ende dieser Folge wirst du verstehen, was Kubernetes eigentlich ist, wie es mit Containern zusammenarbeitet und warum der Azure Kubernetes Service es für Teams praktisch macht, die nicht alles von Grund auf neu aufbauen wollen. Schnapp dir deinen Kaffee und lass uns losleben.

Das Problem vor dem Container. Irgendwann zurück zum Ursprünglichen. Stell dein Softwareunternehmen vor zehn Jahren vor. Man hat ein paar Anwendungen, kauft also Server, installiert Betriebssysteme und stellt alles manuell bereit. Jede App bekommt ihre eigene Maschine und man kann Ressourcen nicht zwischen ihnen teilen. Wenn eine App viel Arbeitsspeicher benötigt und eine andere kaum etwas, bekommt trotzdem jeder einen eigenen Server. Die Verschwendung war enorm. Server liefen vielleicht bei 20% Auslastung, aber man konnte sie nicht zusammenlegen, weil die Anwendungen um Abhängigkeiten konkurrierten. Am Ende hatte man ein Raum voller Server, von dem jeder kaum etwas leistete, aber Strom und Kühlung verbrauchte und ständig gewartet werden musste, musste. Eine App braucht Python 3.7, eine andere braucht Python 3.7. Die eine benötigt eine ältere Bibliothek, die andere die neueste. Man kann sie nicht auf derselben Maschine betreiben, ohne App was kaputt zu machen, also kauft man weitere Server und zahlt für Hardware, die meistens ungenutzt bleiben.

Virtuelle Maschinen halfen ein wenig, indem sie einen physischen Server in kleinere Teile zerlegten, von denen jedes sein eigenes Betriebssystem ausführte, aber jede VM ist schwerfällig, verbraucht Festplattenspeicher und Arbeitsspeicher und Arbeitsspeicher und braucht Minuten zum Start. Außerdem musste man jede einzeln konfigurieren, was viel Arbeit bedeutete. Man verwaltet nach wie vor all diese Betriebssysteme, installiert Patches, aktualisiert und sichert sie. Teams brauchten etwas leichteres und portableres, eine Möglichkeit, eine Anwendung mit allem, was sie zum Ausführen benötigt, zu verpacken, ohne den Overhead einer kompletten virtuellen Maschine und das sich einfach zwischen Maschinen verschieben lässt. Genau hier kam Containerspiel. Was Container eigentlich sind? Ein Container ist ein kleines Paket, das deine Anwendung und alles, was sie zum Ausführen benötigt, enthält. Das bedeutet, dass der Code, die Laufzeitumgebung, die Bibliotheken und die Konfigurationsdateien alle in einer Einheit gebündelt sind.

Stell es dir wie ein Seekontainer für Software vor. Ein Seekontainer kann per LKW-Bahn oder Schiff transportiert werden und der Container selbst bleibt dabei immer dasselbe. Der Software-Container funktioniert nach dem gleichen Prinzip. Sie bauen ihn einmal und er läuft auf ihrem Laptop, ihrem Testserver und ihrer Produktionsumgebung identisch. Identisch. Der Hauptunterschied zwischen Containern und virtuellen Maschinen liegt in ihrer Effizienz. Eine virtuelle Maschine führt ihr eigenes vollständiges Betriebssystem aus, hat also einen eigenen Kernel, Systemdateien und alles weitere. Ein Container hingegen nutzt das Betriebssystem des Hosts mit. Er ist lediglich ein Prozess mit einer eigenen isolierten Sicht auf die Welt. Das bedeutet, Container starten in Sekunden statt in Minuten. Sie verbrauchen weniger Arbeitsspeicher und man kann deutlich mehr davon auf einer Maschine unterkommen. Docker machte Container populär, indem es Entwicklern eine einfache Möglichkeit bot, diese mit nur einem Befehl zu erstellen und auszuführen.

Plötzlich begann das Problem, auf meinem Rechner läuft es aber zu verschwinden. Wenn Ihre Anwendung in einem Container auf Ihrem Laptop läuft, läuft sie auf dem Server genauso. Die Umgebung ist überall konsistent. Doch Container lösen ein Problem und schaffen gleichzeitig ein Neues. Bei einer Handvoll Container funktioniert die manuelle Verwaltung problemlos. Sie können sie selbst starten, stoppen und den Überblick behalten. Aber was passiert, wenn Sie hunderte davon haben? Sie müssen entscheiden, welcher Server welchen Container ausführt, ausgefallene Neustarten sie miteinander verbinden und bei Lastspitzen skalieren. Das sind neue Herausforderungen und genau hier kommt Kubernetes ins Spiel. Das Orchestrierungsproblem. Sie haben also funktionierende Container, verpacken Ihre Anwendung, sie läuft überall konsistent und das Leben ist gut. Aber nur für eine Weile. Mit 10 oder 20 Containern lässt sich alles noch manuell verwalten.

Sie wissen, welcher Server welchen Container ausführt, können bei einem Absturz neu starten und hier und da ein paar Updates durchführen. Das ist machbar. Doch dann wächst Ihre Anwendung. Sie steigen auf Microservices um. Statt einer großen Anwendung haben Sie nun 20 kleinere. Jede benötigt zur Zuverlässigkeit mehrere Kopien und plötzlich haben Sie es mit 200 Containern zu tun. Manuelle Verwaltung funktioniert so nicht mehr. Sie müssen entscheiden, welcher Server welchen Container ausführt. Container bei Fehlern neu starten und Sie so verbinden, dass Sie kommunizieren können. Sie müssen bei Lastspitzen skalieren etwa, während eines Verkaufs oder einer Produktneueinführung und wieder herunterskalieren, wenn es ruhiger wird. Außerdem müssen Sie Updates ohne Ausfallzeiten bereitstellen, was bedeutet, alte Container einzeln und vorsichtig durch neu zu ersetzen, ohne etwas zu beschädigen. Das sind Orchestrierungsprobleme und genau diese wurde Kubernetes gebaut, um sie zu lösen.

Kubernetes ist eine Open-Source-Plattform, die das Bereitstellen, Skalieren und Verwalten containerisierter Anwendungen automatisiert. Betrachten Sie es als das Betriebssystem für Ihr Rechenzentrum. So wie Windows oder Linux die Ressourcen eines einzelnen Computers wie CPU, Arbeitsspeicher und Festplatte verwaltet, verwaltet Kubernetes die Reserver hinweg. Es behandelt alle Ihre Maschinen als einen großen Pool an Rechenleistung. Sie sagen ihm, was Sie ausführen möchten und es bestimmt, wohin es gehört, wie es am Laufen gehalten wird und wie es mit einem anderen verbunden wird. Kernkonzepte, Pods, Nodes und Cluster. Schauen wir uns an, wie Kubernetes tatsächlich funktioniert. Die kleinste Einheit in Kubernetes nennt man Pod. Ein Podumschließ ein oder mehrere Container. Container im selben Pod teilen sich Speicher und Netzwerk, sodass Sie über Localhost miteinander kommunizieren können. Man kann sich ein Pod als eine einzelne Bereitstellungseinheit vorstellen.

In Kubernetes stellt man Container nicht direkt bereit, man stellt Pods bereit. Pods laufen nicht eigenständig, sie laufen auf Nodes. Ein Node ist ein Server. Physisch oder virtuell der Teil Ihres Kubernetes-Clusters ist. Jeder Node führt die Software aus, die zum Betrieb von Pots nötig ist, plus ein paar weitere Dinge, zu denen wir gleich kommen. Ein Cluster ist die Ansammlung aller Nodes, die als einheitliches System verwaltet werden. Einfach ausgedrückt, ein Pod ist ihre Anwendung, ein Node ist der Ort, an dem sie läuft und der Cluster ist die gesamte Umgebung. Pods sind vergänglich. Sie können jederzeit erstellt, zerstört oder verschoben werden. Es ist so beabsichtigt. Wenn ein Node ausfällt, verschiebt Kubernetes die Pods auf einen anderen. Zum Skalieren werden neue Pods erstellt und wenn ein Pod abstürzt, wird er automatisch ersetzt. Das Ganze betrachtet Pods als temporär. Doch wenn Pods kommen und gehen, braucht man die Möglichkeit, sie zu erreichen.

Anstatt direkt mit einem Pod zu sprechen, kommuniziert man mit einem Service. Ein Service bietet eine stabile Netzwerkadresse, die den Datenverkehr an die richtigen Pods leitet, auch wenn sich Pods ändern. Stellen Sie sich ein Hotel vor. Die Telefonnummer des Hotels ist der Service. In den Zimmern wechseln ständig die Gäste, aber die Telefonnummer bleibt gleich. Sie rufen die Rezeption an und diese leitet ihren Anruf an das richtige Zimmer. Genau das macht ein Service in Kubernetes. Er gibt Ihnen eine feste Adresse, die immer auf die Pods zeigt, die aktuell Ihre Anwendung ausführen. Die Control Plane, das Gehirn des Clusters. Sie haben also Pods, Nodes und einen Cluster. Die Frage ist, wer entscheidet, was wo läuft. Das ist die Aufgabe der Control Plane. Jeder Kubernetes-Cluster hat eine, sie ist das Gehirn des gesamten Betriebs. Hier werden alle Entscheidungen getroffen. Die Control Plane besteht aus mehreren Kunden.

Die erste ist der API-Server, der als Eingangstur zu Ihrem Cluster fungiert. Jeder Befehl, den Sie an Kubernetes senden, sei es über die Befehlszeile, ein Dashboard oder ein automatisiertes Skript, läuft über den API-Server. Er authentifiziert Ihre Anfrage, prüft, ob Sie dazu berechtigt sind und leitet Sie dann an die richtige Stelle weiter. In Kubernetes geschieht nichts, ohne dass es zuvor den API-Server passiert. Als nächstes kommt der Scheduler, der entscheidet, welcher Knoten welchen Pod ausführt. Wenn Sie sagen, ich möchte, dass diese Anwendung läuft, prüft der Scheduler alle verfügbaren Knoten, kontrolliert die Ressourcen wie CPU, Arbeitsspeicher und Festplattenplatz und wählt den besten für die Aufgabe aus. Und wählt den besten für die Aufgabe aus. Es ist wie ein Hotelmanager, der Zimmer basierend auf den Bedürfnissen der Gäste zuweist. Ein Gast mit viel Gepäck bekommt ein größeres Zimmer, während eine leichte Anwendung einen kleineren Knoten mit freier Kapazität erhält.

Dann gibt es noch den Controller Manager. Diese Komponente behält den Cluster im Auge und stellt sicher, dass der Ist-Zustand dem entspricht, was Sie deklariert haben. Sie haben angegeben, dass drei Kopien Ihrer Web-App laufen sollen. Der Controller Manager prüft, ob tatsächlich drei Kopien aktiv sind. Wenn einer Absturz, bemerkt er das und startet einen Ersatz. Wenn jemand versehentlich einen Pod löscht, erstellt er einen neuen. Er ist die Komponente, die Ihren Cluster diszipliniert hält. Und schließlich gibt es ECTD, die Datenbank des Clusters. Sie speichert alles, was läuft, wo es läuft und wie es konfiguriert ist. Sie ist die zentrale Quelle der Wahrheit für den gesamten Cluster. Wenn der API-Server das Eingangstor ist, dann ist ECTD der Aktenschrank im Büro, in dem alle Aufzeichnungen aufbewahrt werden. Das Schöne an diesem Design ist, dass Sie beschreiben, was Sie wollen und Kubernetes herausfindet, wie es dies umsetzt.

Sie sagen ihm nicht, wie es etwas tun soll, sondern wie das Endergebnis aussehen soll. Das ist das deklarative Modell und es ist das Grundkonzept hinter allem, was Kubernetes tut. Workloads, Deployments, Services und Skalierungen. Sprechen wir also darüber, wie Sie Anwendungen tatsächlich auf Kubernetes ausführen. Sie werden Pots nicht direkt erstellen. Stattdessen verwenden Sie ein übergeordnetes Objekt, das als Deployment bezeichnet. Betrachten Sie ein Deployment als Manager, der Kubernetes mitteilt, wie viele Kopien Ihres Pots laufen sollen, welches Container-Image zu verwenden ist und wie diese bei einer neuen Version zu aktualisieren sind. Es ist der Standardweg, um zustandslose Anwendungen auszuhören. Wenn Sie ein Deployment aktualisieren, also eine neue Version Ihrer App bereitstellen, führt Kubernetes ein Rolling-Update durch. Es ersetzt Pots nacheinander und stellt sicher, dass immer mindestens eine Kopie läuft.

Das bedeutet keine Ausfallzeiten und keine plötzlichen Unterbrechungen für Ihre Nutzer. Und falls mit der neuen Version etwas schief geht, können Sie mit einem Befehl zur vorherigen zurückkehren. Es ist ein starkes Sicherheitsnetz. Aber Ihre Pots müssen trotzdem erreichbar sein. Hier kommen Services ins Spiel. Ein Service bietet eine stabile Netzwerkadresse, die den Datenverkehr in die richtigen Pots leitet. Er kann diese Pots auch für andere Teile Ihrer Anwendung oder für die Außenwelt zugänglich machen. Ein Service kann intern sein, nur innerhalb des Clusters erreichbar oder extern mit einer öffentlichen IP-Adresse für Nutzer aus dem Internet. Nun zum Thema Skalierung. Kubernetes kann Ihre Anwendung basierend auf dem Bedarf automatisch vergrößern und verkleinern. Sie legen ein Ziel fest zum... B 70% CPU-Auslastung und Kubernetes fügt Pots hinzu, wenn der Wert steigt und entfernt sie, wenn er sinkt.

Ihre Anwendung skaliert bei Verkehrsspitzen nach oben und bei weniger Last wieder nach unten. Kein manuelles Eingreifen erforderlich. Doch diese Leistung bringt auch Komplexität mit. Wer ein eigenes Kubernetes-Cluster betreibt, ist für die Control-Plane, Upgrades, Sicherheitspatches und Backups verantwortlich. Man braucht tiefgreifendes Fachwissen für Knotenausfälle, Netzwerkkonfiguration und Cluster-Skalierung. Viele Teams verbringen mehr Zeit mit der Cluster-Verwaltung als mit der Anwendungsentwicklung. Genau hier setzen Managed Kubernetes-Dienste an. Selbstverwaltetes versus Managed Kubernetes. Sprechen wir also über die Realität beim eigenständigen Betrieb von Kubernetes. Beim Aufbau eines eigenen Clusters sind Sie für alles verantwortlich. Control-Plane, Upgrades, Sicherheitspatches und ETCD-Backups. Wenn der IPI-Server ausfällt, ist das Ihr Problem. Wenn eine Sicherheitslücke in der verwendeten Version entdeckt wird, müssen Sie diese patchen.

Wenn ETCD beschädigt wird, müssen Sie es aus einem Backup wiederherstellen. All dies erfordert tiefgreifendes Fachwissen. Sie müssen verstehen, wie Knoten ausfallen, wie Netzwerke auf Clusterebene funktionieren und wie man skaliert, ohne das System zu beschädigen. Das ist der Punkt, der viele Teams überrascht. Viele Organisationen verbringen mehr Zeit mit der Verwaltung ihres Kubernetes-Clusters als mit der Entwicklung der darauf laufenden Anwendung. Sie kämpfen ständig mit Upgrades, beheben Netzwerkprobleme und bewältigen Knotenausfälle. Das Cluster wird zu einem Vollzeitjob. Das ist nicht der Grund, warum Sie Kubernetes ursprünglich eingeführt haben. Hier kommen Managed Kubernetes-Dienste ins Spiel. Dienste wie der Azure Kubernetes Service, kurz AKS, übernehmen die Control-Plane für Sie. Azure verwaltet den API-Server, ETCD, den Scheduler und den Controller-Manager. Sie müssen sich keine Sorgen um deren Patching oder Betrieb machen.

Sie zahlen nur für die Worker-Nodes, also die virtuellen Maschinen, auf denen Ihre Workloads tatsächlich laufen. Die Steuerungsebene selbst ist kostenlos. Das verändert die Ausgangslage grundlegend. Anstatt Zeit mit der Clusterwartung zu verbringen, kann sich Ihr Team auf das Wesentliche konzentrieren, die Anwendungen, die Sie entwickeln. Für die meisten Teams, besonders für allen Steiger, ist Managed Kubernetes die richtige Wahl. Sie erhalten die volle Leistung von Kubernetes ohne den operativen Aufwand. AKS-Kubernetes ganz einfach auf Azure. Was genau ist also AKS? Es ist der Managed Kubernetes-Dienst von Azure, der Ihnen einen voll ausgestatteten Cluster bietet, ohne dass Sie ihn von Grund auf nur erstellen müssen. Die Steuerungsebene ist, wie erwähnt, kostenlos, sodass Sie nur für die virtuellen Maschinen bezahlen, auf denen Ihre Workloads laufen. Das bedeutet, Sie können klein anfangen, zahlen nur wenig und skalieren bei steigendem Bedarf einfach hoch.

Azure übernimmt die ganze schwere Arbeit. Upgrades, Patching und die Überwachung der Steuerungsebene werden komplett für Sie erledigt. Sie benötigen kein dediziertes Team von Kubernetes-Experten, um den Betrieb aufrechtzuhalten. Und da AKS Teil des Azure-Ökosystems ist, lässt es sich nahtlos mit Tools integrieren, die Sie wahrscheinlich bereits nutzen. Azure Active Directory für die Authentifizierung, Azure Monitor für Protokolle und Metriken, sowie Azure Policy für die Governance. Alles funktioniert sofort nach der Einrichtung zusammen. Kein umständliches Zusammenstück in einzelner Gruppe. Das Einrichten von CICD-Pipelines mit GitHub-Actions oder Azure DevOps dauert nur wenige Minuten. Sie übertragen eine Änderung an Ihr Repository und das System erstellt automatisch ein neues Container-Image, pusht es in die Azure Container Registry und aktualisiert Ihr Deployment auf AKS. Keine manuellen Schritte, kein SSH-Zugriff auf Server erforderlich. Alles läuft vollautomatisch.

Für Einsteiger gibt es den AKS-Automatik-Modus konzipiert für Teams, die nicht jede Entscheidung zur Cluster-Konfiguration selbst treffen möchten. Er bietet sofort einsatzbereite Vorgaben für Skalierung, Netzwerk, Sicherheit und Upgrades. Sie müssen kein Kubernetes-Experte sein, um loszulegen. Beschreiben Sie einfach Ihre Anwendung. Den Rest erledigt AKS. Ein Befehl erstellt den Cluster. Eine Manifestdatei bringt Ihre Anwendung zum Laufen. Die Fähigkeiten, die Sie mit AKS erlernen, sind auf jede Kubernetes-Umgebung übertragbar, da es sich im Kern um Standort Kubernetes handelt. Sie lernen kein proprietäres System, sondern das Original, wobei Azure die operative Komplexität für Sie übernimmt. Damit haben Sie nun den Gesamtüberblick. Container verpacken Ihre Anwendungen so, dass Sie überall konsistent laufen und Kubernetes orchestriert diese Container in großem Maßstab, Deployment, Skalierung und Wiederherstellung erfolgen automatisch.

AKS macht diese Orchestrierung beherrschbar, indem es die Steuerungsebene verwaltet und sich in die Azure-Tools integriert, die Sie bereits kennen. Denn der wichtigste Punkt ist, Kubernetes ist nicht nur etwas für große Tech-Unternehmen mit riesigen Engineering-Teams. Mit Managed-Services wie AKS ist es für jedes Team zugänglich. Deine Hausaufgabe für diese Woche ist einfach. Erstelle ein kostenloses Azure-Konto, starte ein AKS-Cluster und stelle eine einfache Anwendung bereit. Es dauert nur wenige Minuten und du wirst sehen, wie weit die Plattform gekommen ist. Bereit für tiefer Einblick? In der nächsten Folge erfährst du, wie du dein erstes Container-Image erstellst und es in der Azure-Container-Registry ablegst. Abonniere uns auf deiner bevorzugten Podcast-Plattform und teile dies mit jemandem, der gerade erst mit Kubernetes beginnt.