Einführung in Kubernetes

DevOps

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
kubectl get nodes
  • Alle Pods in einem Namespace (Scope) auflisten
kubectl get pods -n <namespace>
  • Statusinformationen eines Pods auflisten
kubectl describe pod <Pod-ID oder Podname> -n <namespace>
  • Services (Load Balancer, Ingress, …) in einem Namespace auflisten
kubectl get services -n <namespace>
  • Ein Terminal in einem Pod öffnen, wenn dies möglich ist
kubectl exec -it <Pod-ID oder Podname> <bash/sh> -n <namespace>
  • Auf Basis eines Podmanifests einen Pod erstellen
kubectl apply -f pod-manifest.yaml -n <namespace>

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

Im folgenden sind meine Literaturempfehlungen, wenn ihr mit Kubernetes einsteigen möchtet.

Yannic Nevado Autor

Yannic Nevado ist ein Datenbank-Consultant bei der Proventa AG. Seine Schwerpunkte liegen beim Open Source und EDB Postgres. Er arbeitet mit Kunden daran neue Datenbanksysteme einzuführen. Des Weiteren unterstützt er Migrationen von Oracle und DB2  zu Postgres. DevOps mit Containern und Kubernetes gehören außerdem zu seinem Alltag. Gerne teilt er sein neu erlangtes Wissen bei der Postgres User Group Frankfurt weiter.

Tags