single.php
< Beitrag von Frank Oltmanns-Mack

Container on Azure 3: Kubernetes-Architektur

Im Mittelpunkt des letzten Blogbeitrag in der Reihe „Container on Azure“ standen die Grundsätze von Kubernetes und einer genauere Betrachtung fundamentaler Ansätze wie Unveränderlichkeit, Deklarative Konfiguration und Selbstheilende Online-Systeme. In diesem Beitrag gebe ich nun einen Überblick über die Kubernetes-Architektur, wobei ich ein paar essentielle Bausteine definieren und deren Funktionalität näher erläutere. 

Bei diesem Vorhaben muss ich mich allerdings auf  die wichtigsten Elemente beschränken, da eine vollständige Liste den Umfang dieses Beitrag sprengen würde. Aber zum Einstieg schauen wir erstmal, wie die Kubernetes-Architektur generell aussieht.

Kubernetes-Architektur

Kubernetes-Architektur

Kubernetes Master und API-Server

Das zentrale Element von Kubernetes ist der Kubernetes Master. Dort sitzt ein API-Server, gegen den alle Client Anfragen laufen. Der generelle Zustand des Clusters hält die Umgebung in einem etcd Key Value Store. Etcd ist ein hierarchischer, verteilter Open-Source Key-Value-Store, geschrieben in der Programmiersprache Go. Alle anderen Elemente des Clusters sind zustandslos und lassen sich mehrfach ausgeführen. Diese Möglichkeit der mehrfachen Ausführbarkeit ist besonders wichtig, um die Ausfallsicherheit für Produktionsumgebungen zu gewährleisten. In solchen Umgebungen empfiehlt sich ein Kubernetes Master, der aus 3, 5, 7 oder 9 Instanzen besteht, da beim Ausfall eines Nodes wieder ein Leader etcd ermittelt werden muss.

Kubelets und Pods

Die kleinste Einheit in einem Kubernetes Cluster ist ein sogenanntes Kubelet, das dafür verantwortlich ist, was auf jeder Maschine ausgeführt wird. Die Kubelets laufen auf den sogenannten Worker Nodes. Container fasst man auf den Worker Nodes in sogenannten Pods zusammen.

Pods sind eine Gruppierung von Containern,  die die gleiche Lebensdauer haben. In einem Pod teilen sich alle Container ein gemeinsames Netz, werden gleichzeitig erzeugt und auch gemeinsam gestoppt. Sollte ein Container in einem Pod beendet werden, so werden auch alle anderen Container beendet.

cAdvisor und Scheduler

Zusätzlich gibt es einen sogenannten cAdvisor, der die CPU-Leistung und den Speicherverbrauch auf den Nodes misst und an den Master weitergibt. Ein Scheduler kümmert sich um die Verteilung der Pods, so dass die zur Verfügung stehenden Ressourcen möglichst optimal genutzt werden. All diese Dienste laufen auch selber in Containern. Die Container können dabei entweder aus einer öffentlichen oder auch einer privaten Image Registry bezogen werden.

Kubernetes Cluster

Kubernetes Cluster abstrahieren soviel Komplexität wie möglich von den Nutzern, so dass das System maximal robust ist. Der Aufwand für die Konfiguration und Verwaltung ist möglichst gering, und es kann auf das Deployment der Applikationen fokussiert werden. Dies vermeidet risikoreiche Konfigurationsfehler und erhöht generell die Sicherheit des kompletten Systems.

Kubernetes arbeitet mit vielen Public-Cloud-Umgebungen zusammen, so dass in den meisten Fällen nur wenige Minuten zur Erzeugung eines kompletten Clusters notwendig sind, da auf die nativen Dienste des jeweiligen Cloud-Anbieters zugegriffen wird. Wie sich ein Kubernetes Cluster in Microsoft Azure erzeugen lässt, erläutere ich in einem späteren Blogbeitrag.

Begriffe aus der Welt von Kubernetes

Nach dieser Erläuterung der Kubernetes-Architektur sollten wir noch eine paar Grundbegriffe klären, bevor wir in einem der nächsten Beiträge in die Praxis einsteigen.

Pods

Pods sind die kleinsten Objekte in Kubernetes. Sie beschreiben eine Gruppierung von laufenden Containern in einem Kubernetes Cluster. Üblicherweise bestehen Pods nur aus einem einzigen Container, können aber auch aus mehreren bestehen. Man verwaltet Pods generell in einem Deployment.

Deployments

Ein Deployment ist ein API-Objekt, das eine replizierte Applikation verwaltet. Jede Replik wird durch ein Pod dargestellt. Die Pods eines Replik-Sets verteilen sich gleichmässig über die Worker Nodes des Clusters.

Services

Pods kommunizieren durch Services mit der Außenwelt. Außenwelt bedeutet in diesem Kontext entweder innerhalb des Clusters oder auch außerhalb, wie z. B. über das Internet. Wenn man Services erzeugen will, gibt man die Kommunikationsports und entsprechenden Load Balancer an.

Volume

In einem Pod stehen auch sogenannte Volumes zur Verfügung. Normalerweise gehen die Daten eines Containers bei einem Neustart verloren. Da Volumes aber die gleiche Lebensdauer wie der umschließende Pod haben, lassen sich Daten persistieren und stehen auch nach Container-Neustarts noch zur Verfügung.

Fazit

Kubernetes Cluster sind durch möglichst einfache Konfiguration und redundante Funktionalitäten auf Ausfallsicherheit ausgelegt. Gerade im Zusammenspiel mit einem Public-Cloud-Anbieter entfaltet Kubernetes seine Stärken, da innerhalb von Minuten komplette Umgebungen zur Verfügung stehen.

Cluster können aber auch sehr schnell den Umfang eines kompletten Rechenzentrums erreichen. Deswegen ist ein sauberes Design unerlässlich beim Entwurf neuer Cluster. Besonders im Bezug auf Sicherheit muss der Anwender bestimmte Aspekte berücksichtigen, die ich im nächsten Blogbeitrag dieser Serie genauer betrachten möchte. Die Weiterentwicklung von Kubernetes schreitet stetig voran, und im Hinblick auf Sicherheit sind in den letzten Versionen sehr viele neue Funktionalitäten hinzugekommen. Ich würde mich freuen, wenn Sie auch im nächsten Teil wieder mit dabei sind.

Bisherige Teile der Serie „Container on Azure“:

  1. Was sind Container?
  2. Was ist Kubernetes?
  3. Architektur von Kubernetes
Folgen
X

Folgen

E-mail : *
Kategorie: Cloud | Schlagwörter: , , , | Kommentare: 0

Beitrag kommentieren

CAPTCHA * Time limit is exhausted. Please reload CAPTCHA.