Dieser Artikel beleuchtet die Ansicht aus der Benutzerperspektive, nicht so sehr aus der Perspektive der Systemarchitektur. Jeder Abschnitt enthält eine kurze Zusammenfassung dessen, was du an dieser Stelle verstanden haben solltest. Wenn du etwas nicht verstehst, versuche es noch einmal zu lesen, bevor du fortfährst, oder lese einen der zusätzlichen Informationslinks.
In der Softwareentwicklung wird die Komplexität eines Problems hinter Abstraktionsebenen versteckt. Dies gilt auch für Kubernetes, da es die Komplexität der Orchestrierung von Containern hinter einer weniger komplexen Benutzeroberfläche verbirgt. Der Rest des Artikels bewegt sich auf der Abstraktionsebene nach oben, bis wir die Schnittstelle erreichen, die helm bietet.
Warum wir Container brauchen - Software portabel machen
Ein Entwickler beginnt in der Regel mit der Codierung und Entwicklung seiner Anwendung lokal auf seinem eigenen Rechner. Das bedeutet, dass er nicht nur seinen eigenen Code schreibt, sondern auch Bibliotheken des zugrunde liegenden Systems oder von Dritten verwendet. Er könnte sogar ein System entwickeln, das aus zwei Anwendungen besteht, um das jeweilige Geschäftsproblem zu lösen.
Sobald das System seine erste stabile Version erreicht hat, möchte er es auf einem Server bereitstellen, damit die Leute es tatsächlich testen und benutzen können. Das bedeutet, dass er seine Software mit allen externen Abhängigkeiten verpacken und auf den Server übertragen muss, was oft dazu führt, dass die Software lokal funktioniert, aber auf dem Server nicht.
Die Entwickler müssen debuggen und feststellen, welche Abhängigkeit auf dem Server anders ist als auf ihrem lokalen Rechner. An dieser Stelle kommen Container und Container-Laufzeiten (z. B. Docker) zum Einsatz. Mit Containern können Entwickler ihre Software verpacken und ausliefern, indem sie ein isoliertes Image erstellen, das auf jedem anderen Rechner mit derselben Container-Laufzeit und Architektur ausgeführt werden kann - Container machen Software portabel.
Zusammenfassung: Container ermöglichen es, Software in portablen Einheiten zu verpacken, so dass sie auf jedem Rechner ausgeführt werden kann, der über die gleiche Container-Laufzeit verfügt, so dass ein Entwickler nicht manuell sicherstellen muss, dass alle Hosts die gleichen Fähigkeiten haben.
Warum wir Kubernetes brauchen - Skalierung eines Systems
Während Container das Problem der Portabilität von Software lösen, ergeben sich mehrere Probleme, sobald wir unser System skalieren wollen. Wie bereits erwähnt, kann ein System aus mehreren Anwendungen bestehen - stelle dir z. B. Google vor, mit seiner Suchmaschine, Gmail, Docs, Kalender usw. Das bedeutet, dass du mehrere Container bereitstellen müsstest, und je mehr Verbraucher du hast, desto mehr müsstest du Ihre Anwendungen skalieren.
Du könntest eine Anwendung vertikal oder horizontal skalieren. Vertikal bedeutet, dass du deinen Host mit mehr Rechenleistung ausstatten musst, so dass er eine größere Anzahl von Benutzern verarbeiten kann. Horizontal bedeutet, dass du mehrere Kopien derselben Anwendung auf verschiedenen Hosts laufen lässt, um mehr Verbraucher zu bedienen, was flexibler ist, da du die Anzahl der Hosts an die Anzahl der Verbraucher anpassen kannst.
Das bedeutet, dass du mehrere Container auf vielen Hosts bereitstellen und außerdem sicherstellen müsstest, dass die Anwendungen voneinander Kenntnis haben. Daher müsstest du entweder eine Software schreiben oder die Zuordnung von Containern und Hosts manuell überwachen. Wenn eine neue Version einer Anwendung bereitgestellt wird, müsstest du die Container auf den entsprechenden Hosts aktualisieren. Und wenn ein Container ausfällt, müsstest du den richtigen Host finden und den Container neu starten. Kurz gesagt, du müsstest deinen Container orchestrieren oder verwalten, und genau das tut Kubernetes für dich.
Wie bereits erwähnt, wird in diesem Artikel nicht auf die Systeminterna von Kubernetes eingegangen, sondern es wird kurz eine High-Level-Ansicht dargestellt. Ein Kubernetes-Cluster besteht aus mindestens einem Master-Knoten und mehreren Worker-Knoten. Die Worker-Knoten dienen als Hosts für die Container, während der Master-Knoten als Gehirn des Clusters fungiert und die Container auf die Worker-Knoten verteilt.
Der Masterknoten beherbergt auch den API-Server, der es den Entwicklern ermöglicht, eine Schnittstelle zum Kubernetes-Cluster herzustellen, d. h. Container und Konfigurationen zu übergeben, die auf dem Cluster laufen sollen. Die Konfigurationen sind eine Reihe von yaml-Dateien, die den gewünschten Zustand der Kubernetes-Ressourcen beschreiben. So gibt es beispielsweise eine deployment.yaml-Datei, die beschreibt, welches Container-Image ausgeführt werden soll, wie viele Instanzen ausgeführt werden sollen und wie viel Rechenleistung eine Instanz erhalten soll. Außerdem wird eine service.yaml verwendet, um zu beschreiben, wie andere Dienste auf das Deployment zugreifen können.
Dazu fügst du oft Artefakte wie configmap.yaml oder secrets.yaml hinzu, die Werte enthalten, die beim Start eines Containers als Umgebungsvariablen injiziert werden sollen. Dies ist zwar eine Menge an Konfiguration, aber die Arbeit zahlt sich aus. Kubernetes übernimmt diese Konfigurationen und verteilt Ihre Anwendung im gesamten Cluster, so dass du sie innerhalb von Sekunden nach oben oder unten skalieren kannst. Kubernetes vergleicht ständig den Status des Clusters mit dem angegebenen Sollzustand und versucht, diesen anzugleichen. Das heißt, wenn deine Anwendung gerade nicht mehr funktioniert, versucht Kubernetes, eine neue Instanz deines Dienstes zu starten - es wird zu einem selbstheilenden System.
Rekapitulation: Ein Cluster ist eine Gruppe von Host-Maschinen, wobei ein Kubernetes-Cluster ein selbstheilendes System ist. Es vergleicht ständig den Ist-Zustand mit dem Soll-Zustand und gleicht diesen ab. Daher ermöglicht es die Verwaltung und Wartung von containerisierten Anwendungen über mehrere Hosts hinweg, indem es eine Reihe von Yaml-Dateien bereitstellt, die den gewünschten Zustand beschreiben.
Warum wir Helm brauchen - Erstellung von Einsatzvorlagen
Wie bereits erwähnt, erfordert die Bereitstellung von Anwendungen in Kubernetes mehrere Konfigurationen, die in verschiedenen Dateien gespeichert werden. Dies ist kein großes Problem, wenn du dein System nur einmal bereitstellst, aber sobald du mit dem Aufbau generischer Systeme beginnst, müsstest du das System möglicherweise mehrmals bereitstellen und dabei einige Variablen nur geringfügig ändern. Das bedeutet, dass du in die einzelnen Dateien gehen und diese Werte anpassen müsstest.
Genau an dieser Stelle kommt Helm ins Spiel. Helm ist ein Tool, mit dem Sie Bereitstellungsvorlagen erstellen können. Diese Vorlage wird Helm-Chart genannt und besteht aus yaml-Dateien, die mehr oder weniger wie eine normale Kubernetes-yaml-Datei aussehen, aber einige Variablen enthalten. Diese Variablen können über eine zusätzliche values.yaml-Datei definiert werden.
Anstatt also die Werte direkt zu manipulieren, kannst du sie einfach in der Datei values.yaml festlegen. Helm fügt dann diese Werte in die Dateien ein und erstellt deine Bereitstellungskonfiguration für dich. Mit einer einzigen Datei kannst du also innerhalb von Minuten komplexe Systeme bereitstellen. Die Idee ist, Helm-Diagramme in Repos gemeinsam zu nutzen, genau wie es bei Docker mit Docker Hub geschieht.
Darüber hinaus kannst du mit Helm deine Diagramme verfolgen und zu einer früheren Version deines Diagramms, den so genannten Revisionen, zurückkehren. Dies erleichtert das Rollback, falls ein Einsatz fehlgeschlagen ist.
Zusammenfassung: Helm ist ein Templating-Tool, mit dem du Deployment-Bundles erstellen kannst, die du gemeinsam nutzen und durch Angabe bestimmter Werte anpassen kannst. So kannst du Dienste schnell bereitstellen und Releases reproduzierbar machen, so dass du bei Bedarf ein Rollback durchführen kannst.
