Im zweiten Beitrag der Blogreihe über Kubernetes wird das Container Orchestrierungstool Kubernetes und dessen Grundkonzepte vorgestellt. Container werden von Entwicklern täglich zum Testen von Anwendungen oder Experimentieren mit neuen Tools eingesetzt. Hat sich ein Unternehmen nun das Ziel gesetzt, große Containerlandschaften automatisiert verwalten zu lassen, kommt in der Regel ein Orchestrierungstool zum Einsatz. Kubernetes ist dabei eines dieser Tools, welches Unternehmen verwenden können und welches sicher großer Beliebtheit erfreut.
Kubernetes
Um ein besseres Verständnis für Kubernetes zu bekommen, sollte man ein Basiswissen über Container haben. Im Blogbeitrag Einführung in Container und Docker werden die Grundkonzepte von Containern vorgestellt. Außerdem werden Unterschiede zu virtuellen Maschinen aufgezeigt, sowie Container lokal gebaut und gestartet werden.
Hier geht es zum ersten Teil der Kubernetes Blogreihe >> Einführung in Container und Docker
Wann wird Kubernetes eingesetzt?
Die Verwaltung großer Containerlandschaften erfordert in den meisten Fällen Orchestrierungstools wie zum Beispiel Kubernetes oder OpenShift. Mit Kubernetes verwaltet unter anderem Google täglich mehrere Milliarden Container. Automatisiert können diese skaliert und hochverfügbar bereitgestellt werden.
Kubernetes ist zudem Open Source und kann auch in Cloud-Infrastrukturen betrieben werden. Alle großen Cloud Service Provider bieten entsprechende Managed Kubernetes Services an
Basisobjekte und Controller
In Kubernetes gibt es eine Menge an Objekten und Controllern, die miteinander interagieren.
Pods
Kubernetes verwaltet Container in Pods, welche eine Kernkomponenten sind. Diese laufen auf einem Arbeitsknoten (beispielsweise ein Server) und gruppieren einen oder mehrere Container als logische Einheit. Außerdem stellen sie ihren Containern Netzwerkschnittstellen und Hardwareressourcen zur Verfügung.
Pods haben dabei einen bestimmten Ressourcentyp. Ressourcentypen sind beispielsweise: ReplicaSet, StatefulSet oder Deployment. Jeder Ressourcentyp verfolgt dabei ein eigenes Ziel.
In Kubernetes werden Anwendungen in Pods deklarativ beschrieben. Dies bedeutet, dass über ein YAML-Manifest der Soll-Zustand für eine Anwendung definiert wird. Darunter kann man sich einen Bauplan (wie ein Dockerfile bei Containern) vorstellen.
Abbildung: Container Pod Netzwerkinterfaces
Controller
Jeder Ressourcentyp in Kubernetes wird von einem spezifischen Controller überwacht. Ein ReplicationController verwaltetet dabei Pods vom Typ ReplicaSet und ein DeploymentController Pods vom Typ Deployment.
Die bekannten Kubernetes Ressourcentypen decken dabei nicht alle Anforderungen von jeder bekannten Anwendung ab. Über CustomRessourceDefinitons (CRD) können neue Ressourcentypen (CR) eingeführt werden. Die Verwaltung dieser Ressourcentypen erfordern jedoch die Einführung neuer Controller, die sich speziell um diesen (für Kubernetes unbekannten Ressourcentyp) kümmern. Diese neuen Controller werden Kubernetes Operators genannt. Ein Beispiel ist der Postgres Operator von Zalando.
Deployment
Deployments bieten die Möglichkeit Anwendungen automatisiert (rolling update) auf eine neue Version zu aktualisieren. Das manuelle Aktualisieren kann auf Dauer sehr mühselig sein und es könnte sich noch der ein oder andere Fehler einschleichen. Mit Deployments wird dieser Prozess automatisiert durchgeführt.
ReplicaSet vs. StatefulSet
Diese zwei Ressourcentypen lassen sich gut mit einer Tierherde (ReplicaSets) und Haustieren (StatefulSets) vergleichen. ReplicaSet Pods haben im Vergleich zu StatefulSet Pods keine vorhersagbaren Namen und können für die Persistenz von Daten nur ein Volume gleichzeitig verwenden. Mit StatefulSets können außerdem zustandsbehaftete Anwendungen bereitgestellt werden. Der Name eines StatefulSet Pods setzt sich folgendermaßen zusammen:
statefulsetname-ordinalindex
Wird beispielsweise ein StatefulSet (3 Instanzen) mit dem Namen testpod erstellt, weiß man sofort, dass die einzelnen Instanzen testpod-0, testpod-1 und testpod-2 heißen werden. Fällt ein StatefulSet Pod aus, versucht Kubernetes einen neuen Pod mit demselben Namen wieder zu starten. Ein hochverfügbares Datenbankcluster ist beispielsweise ein Anwendungsfall, indem StatefulSets zum tragen kommen.
Architektur
Die Kubernetes Architektur setzt sich aus Master- und Arbeitsknoten zusammen. Unter einem Knoten kann man sich einen Server (bspw. virtuelle Maschine) vorstellen, in dem die containerisierten Anwendungen betrieben werden.
Abbildung: Kubernetes Architektur
Masterknoten
Der Masterknoten in Kubernetes wird auch Steuerebene genannt. Auf jedem Masterknoten laufen die folgenden Komponenten:
- etcd
- API-Server
- Controller-Manager
- Scheduler
Diese Komponenten stellen im Zusammenspiel den Betrieb von Anwendungen auf Arbeitsknoten sicher.
etcd
Die etcd-Instanz ist eine key-value Datenbank. In dieser wird der Clusterstatus, die YAML-Manifeste der Anwendungen (Pods) und der Status der Anwendungen gespeichert. Die etcd-Komponente sollte redundant ausgelegt sein, um die Hochverfügbarkeit der Kubernetes Umgebung zu gewährleisten. Für ein Quorum sollte es entweder drei, fünf oder sieben etcd Instanzen in einer Kubernetes Infrastruktur geben.
API-Server
Der API-Server ist die einzige Komponente des Masterknotens, die direkt mit der etcd-Komponente kommuniziert. Der Clusterstatus und die Pod Manifeste können nur über den API-Server bearbeitet und abgefragt werden (REST-Schnittstelle). Der API-Server validiert zudem die Richtigkeit (Syntax) der Operation auf die angefragte Ressource (bspw. YAML-Manifest eines Pods). Außerdem überprüft dieser, ob der Client die angefragte Operation auf der Ressource ausführen darf.
Controller-Manager
Der Controller-Manager verwaltet eine Menge von Controllern (ReplicaSet-, StatefulSetcontroller, etc.) für die Überwachung der Ressourcentypen. Diese gleichen den Ist- mit dem Soll-Zustand eines Pods ab. Um den Zustand eines Pods an den Soll-Zustand anzupassen, wird dessen YAML-Manifest über den API-Server bearbeitet.
Scheduler
Die Einplanung von Pods auf Knoten übernimmt der Scheduler auf dem Masterknoten. Dieser hat einen Überblick über alle verfügbaren Knoten und deren zur Verfügung stehende Menge an Hardwareressourcen (CPU-Zeit und RAM). Ein Algorithmus im Scheduler plant die Pods dann auf die in Frage kommenden Knoten ein. Auch dies erfolgt durch die Bearbeitung des Soll-Zustands eines YAML-Manifests von einem Pod. Wie auch bei den Controllern erfolgt dies über den API-Server.
Arbeitsknoten
Neben dem Masterknoten gibt es in einer Kubernetes Infrastruktur auch Arbeitsknoten. Auf den Arbeitsknoten werden die eigentlichen Anwendungen betrieben. Folgende Komponenten laufen aber neben den Arbeits- aber auch auf den Masteknoten:
- Kubelet
- Container-Laufzeit
- Kubernetes Dienstproxy
Kubelet
Die Kubelet-Komponenete auf einem Knoten registriert diesen beim API-Server des Masterknotens. Zusätzlich werden die Pods auf dem Knoten gestartet, entfernt und überwacht.
Container-Laufzeit
Sie legt die Container Software fest, die auf den Knoten verwendet wird. Neben Docker kann hier auch rkt verwendet werden.
Kubernetes Dienstproxy
Dieser sorgt für die Verbindung der Kubernetes Dienste zum API-Server des Masterknotens.
Kubernetes Commandline-Tool
Kubernetes bietet ein Kommandozeilen-Tool (kubectl) um die Kubernetes Infrastruktur über ein Terminal zu verwalten. Hier sind die gängigsten Befehle aufgelistet:
- Knoten in der Kubernetes Infrastruktur auflisten
- Alle Pods in einem Namespace (Scope) auflisten
- Statusinformationen eines Pods auflisten
- Services (Load Balancer, Ingress, …) in einem Namespace auflisten
- Ein Terminal in einem Pod öffnen, wenn dies möglich ist
- Auf Basis eines Podmanifests einen Pod erstellen
Nächster Blogbeitrag
Da das ganze doch ziemlich theoretisch und wahrscheinlich sehr abstrakt klingt, könnt ihr euch schon auf den nächsten Blogbeitrag freuen. In diesem zeige ich euch, wie ihr ein Multi-Node Kubernetes Cluster lokal auf eurem Rechner (Windows und Linux) aufsetzen könnt.
Literaturempfehlungen zu Kubernetes
Im folgenden findet ihr meine Literaturempfehlungen, wenn ihr mit Kubernetes einsteigen möchtet.
