Kubernetes Vor- und Nachteile, Architekturbeschreibung

Die freien Zeiten, die wir durch den Corana-Lockdown gewinnen, werden einem nicht so langweilig vorkommen, wenn man versucht etwas Neues zu lernen. Das Thema Kubernetes ist zwar seit Längerem ein Trend in der IT-Welt, war für mich aber aus technologischer Sicht nicht ganz verständlich. Im folgenden Artikel werde ich versuchen die Kubernetes-Technologie zu beschreiben. Hoffentlich können die nachfolgenden Informationen hilfreich für Sie sein und Ihnen das Thema näherbringen.

Was ist Kubernetes und wofür wird es verwendet

Kubernetes ist eine marktführende Orchestrierungsplattform für die Bereitstellung, Skalierung und Verwaltung von Containern in einem oder mehreren Clustern. Kubernetes (auch K8s genannt) wurde als Open-Source-Technologie im Jahr 2014 von Google ins Leben gerufen und wird von Cloud Native Coputing Foundation weiter geführt. Inzwischen ist Kubernetes der De-facto-Standard für die Container-Orchestrierung geworden. 

VM vs. Container oder OS Isolierung vs. Applikation Isolierung

VM vs Container

Zuerst möchte ich ein paar Worte zum Thema Containerisierung verlieren. Im Vergleich zu einer klassischen Applikation, die direkt auf einem Betriebssystem einer VM installiert wird, benötigen die containerisierten Applikationen kein sehr abgespecktes Betriebssystem (z.B. Windows Core) und beinhalten alle erforderlichen Abhängigkeiten in einem Container selbst. Diese Technologie bringt folgende Vorteile:

  • wesentlich weniger Hardware-Ressourcen werden benötigt (massive Kosten-Ersparnisse, besonders in der Cloud interessant)
  • ein Container startet viel schneller als jedes Betriebssystem
  • die Sicherheit wird durch einen kleineren Footprint erhöht
  • die Software-Versionierung wird vereinfacht
  • eine Plattform-Unabhängigkeit wird gewährleistet
  • ein Container ist oft eine Basis für die Microservices-Architektur 

Microservices

Microservices ist ein Begriff aus dem Bereich der Software-Entwicklung. Ganz vereinfacht bedeutet Microservices nichts anderes, als eine Zerlegung einer großen (monolithischen) Anwendung in kleine Einzelteile, welche bestimmte Dienste/Geschäftsfunktionen abbilden können.

In den letzten Jahren hat die Microservices-Architektur an Popularität gewonnen. Dies ist unteranderem auf die Verbreitung der Containerisierung zurückzuführen oder hat Trend zur Microservice Architektur das Thema Containeriseirung vorangetrieben (darüber streiten sich die Gelehrten). Wie jede Technologie hat auch die Microservices-Architektur sowohl Vorteile als auch Nachteile. Eine gemeinsame Verwendung von  Microservices und Kubernetes reduziert die möglichen Nachteile bei der Umstellung auf Microservices Architektur.

Verwendungsszenarien

Je nachdem, mit wem man über Kubernetes spricht, lernt man zwei Meinungen kennen. Ein Software-Entwickler sieht in diese Technologie ein perfektes Tool, um seine Produkte zu testen und auf dieser Art und Weise die Software-Entwicklung zu beschleunigen, bzw. Release-Zyklen zu verkürzen. Aus Management-Sicht lassen sich mittlerweile viele produktive Bereiche containerisieren und auf diese Art und Weise den Weg vom Test in die Produktion beschleunigen. Die Liste von Vorteilen scheint mir dadurch wesentlich länger zu sein als die Liste von Nachteilen.

 

Vorteile

Flexibilität

Kubernetes passt perfekt zu einem weiteren Trend und ermöglicht eine „schmerzfreie“ Migration in der Cloud. Alle führende Cloud-Anbieter (nicht nur AWS, GCP, Azure) bieten mittlerweile eine eigene Kubernetes-Infrastruktur an. Es besteht auch die Möglichkeit mehrere Anbieter miteinander oder mit einer lokalen Infrastruktur zu verbinden.

Skalierbarkeit / Effizienz

Kubernetes automatisiert eine horizontale Skalierung (Scale out) durch Hinzufügen oder Entfernen von Containern, basierend auf aktuellen Auslastungsindikatoren. Die automatische vertikale Skalierung (Scale up) gewährleistet eine effiziente Zuweisung der im Cluster verfügbaren Hardware-Ressourcen. Die Verwendung von CI/CD- Pipeline (Continuous Integration/Continuous Delivery) ist eine sinnvolle Ergänzung zu einer Kubernetes Infrastruktur, die zur Effizienz beiträgt.

Ausfallsicherheit

Kubernetes beinhaltet einige Mechanismen, um die Hochverfügbarkeit sowohl für die Infrastruktur selbst als auch für die darin laufenden Applikationen zu gewährleisten. An dieser Stelle wäre noch anzumerken, dass die Applikation in der Lage sein muss, mit dem plötzlichen Ausfall von Containern umzugehen. Es wird zwar automatisch ein neuer Container gestartet, aber der „State“ bleibt nicht erhalten. Auch ein „VMotion“ von Containern ist nicht vorgesehen – es wird immer ein neuer Container gestartet. Darüber hinaus überwacht Kubernetes kontinuierlich den aktuellen Zustand des Clusters. Hinzu kommt das effiziente Traffic-Routing und der Lastausgleich.

Deklarative Konfiguration

Eine deklarative Beschreibung bzw. Konfiguration der Infrastruktur trägt ebenfalls zur Stabilität der Kubernetes Infrastruktur bei. Im Gegensatz zu einer imperativen Konfiguration, die in Form der klaren Anweisungen agiert (wie z.B. erstelle Instanz A, erstelle Instanz B, erstelle Instanz C), definiert eine deklarative Konfiguration nur die Anzahl der benötigten Instanzen (z.B. Anzahl laufenden Instanzen = 3). Diese Methode macht auch das Rollback auf eine vorherige Version sehr einfach. Kubernetes wird immer versuchen den in der deklarativen Beschreibung definierten Zustand herzustellen, aber eine Garantie für das Erreichen dieses Zustands gibt es nicht.

Self-Healing

Selbstheilungsfähigkeit gehört zweifelsohne zu den besten Features von Kubernetes. Wenn eine containerisierte App oder ein Pod (die in dem Container platziert sind) abstürzt, wird Kubernetes die abgestürzten Komponenten erneut starten (solange genügend Ressourcen verfügbar sind und die Applikation der Ausfall „abgefangen“ kann).

Ökosystems 

Ein Vorteil einer populären Open-Source Lösung ist ein breites Ökosystem (Monitoring-, Reporting- und Visualisierungs-Tools wie z.B. ElasticSearch + Kibana). Das hilft die Nutzbarkeit des Produktes zu verbessern. Auch in diesem Fall würden die hilfreichen Erweiterungen (wie z.B. Prometheus) in der Regel keine Zusatzkosten verursachen.

 

Nachteile

Die Beschreibung von Nachteilen sollte sich normalerweise auf Erfahrungswerte stützen. Stand heute fehlen mir diese Erfahrungswerte aus der Praxis.

Der Übergang zu Kubernetes könnte teuer und umständlich werden. Selten können wir auf einer grünen Wiese starten. Meist soll die bereits vorhandene Software dementsprechend angepasst werden, dass diese reibungslos auf Kubernetes läuft. In erster Linie muss man abschätzen können, mit welchem finanziellen und zeitlichen Aufwand dabei zu rechnen ist, um die Software anzupassen. Hierfür werden Experten mit tieferen K8s-Kenntnissen sowie Software-Entwickler mit Erfahrung in der Entwicklung von containerisierten Applikationen benötigt.

Nicht für jede vorhandene monolithische Anwendung ist es wirtschaftlich und/oder technisch sinnvoll, diese zu containerisieren. Auch die betrieblichen und organisatorischen Anpassungen können für manche Unternehmen und IT-Abteilungen eine größere Herausforderung sein.

 

Fazit

Da ich persönlich keine produktive Erfahrung mit dem Produkt habe, fällt es mir schwer die Technologie vollumfänglich einzuschätzen und eine Antwort zu geben, ob die Einführung von Kubernetes die richtige Wahl für Sie wäre. Die richtige Antwort wird in erster Linie von Ihren spezifischen Bedürfnissen und Prioritäten beeinflusst.

Ich bin mir sicher, dass der strategische Einsatz von Microservices bzw. Serverless-Architektur auf Basis von Kubernetes im Gegensatz zu den klassischen Methoden nicht nur ein massives Einsparpotential mit sich bringt, sondern auch mehr Flexibilität, Leistung und Skalierbarkeit bedeutet.

 

Architekturbeschreibung

Im weiteren Abschnitt möchte ich Ihnen einen allgemeinen Überblick über die Architektur geben.

Kubernetes Architecture Components

Unter diesem Link finden Sie das obere Architektur-Diagramm, sowie weitere Bilder im Visio-Format:  Kubernetes_Architecture_Diagramm_Visio.vsdx 

Die Kubernetes-Architektur besteht im Groben aus zwei Schichten. Die erste Schicht könnte man als physikalische Schicht bezeichnen. Auf dieser Ebene befinden sich zwei Komponenten: ein oder mehrere Master Nodes sowie ein oder mehrere Worker Nodes.

Kubernetes Layers

Die weiteren Schichten sind zwei logische Abstraktionen:

  • der Kubernetes Cluster selbst, welcher alle Komponenten beinhaltet
  • die Pods, in denen einer oder mehrere Container Instanzen ausgeführt werden

Die Abbildung auf der rechten Seite verdeutlich die logische Gliederung der Komponenten: Cluster beinhaltet Nodes, Nodes beinhalten Pods, Pods beinhalten einzelnen Containers.

 

Pod

Eine Gruppe von einem oder mehreren Containern wird Pod genannt. Ein Pod ist die kleinste Einheit der Kubernetes-Architektur mit dem der Cluster interagieren kann. Alle Container verfügen über dieselbe IP-Adresse, Ports und der Hostname.

Master-Node

Wie Sie sich vorstellen können, ist der Master-Knoten (auch Control Plane Node genannt) für die Verwaltung und Überwachung des Kubernetes-Clusters und deren Komponenten zuständig. Um eine Hochverfügbarkeit des Management-Layer zu gewährleisten, wird die Installation von mehr als zwei Master Nodes empfohlen.

Master Node besteht aus vier Komponenten:

  • API Server
  • Scheduler
  • Controll Manager
  • etcd

API Server

Der API-Server ist der zentralere Anlaufpunkt für alle Befehle, die zur Steuerung des Clusters verwendet werden. API-Server ist eine Art Vermittler zwischen den Komponenten von Kubernetes. Die Kubernetes Administratoren interagieren ebenso mit dem API-Server mittels kubectl (Command Line Utility) oder REST-API.

Scheduler

Scheduler - ist der Ressourcenmanager von Kubernetes. Der Scheduler überwacht ständig den Zustand von erstellten Pods und Nodes und bewertet anhand dieser Information auf welchen Knoten die Pods ausgeführt werden können.

Controll Manager

Die Hauptaufgabe des Control Managers ist die kontinuierende Überwachung des Cluster-Zustandes. Im Falle eines Absturzes versucht der Control Manager den Cluster-Zustand so schnell wie möglich wiederherzustellen.

etcd

etcd ist ein Key-Value-Storage basierend auf CoreOS. Hier befindet sich die komplette Information (Metadaten) über dem Cluster, deren Einstellungen sowie den aktuellen Status. Alle Änderungen werden sofort in etcd gespeichert.

 

Worker Node

Ein Worker Node kann eine physikalische oder virtuelle Instanz sein und kann einen oder mehreren Pods enthalten.  Ein Worker Node beinhaltet drei folgende Komponenten:

  • kubelet
  • kube-proxy
  • Container Runtime

Kubelet

Ein kubelet ist ein Agent, der auf jedem Node im Cluster ausgeführt wird. Die Hauptaufgabe des kubelets sicherzustellen, dass die Container in einem Pod ausgeführt (gestartet, gestoppt) werden. Wenn z.B. ein Container nicht mehr läuft, sorgt der kubelet-Agent für den Neustart auf dem gleichen Node.

kube-proxy

kube-proxy agiert als Netzwerk-Proxy mit integrierter Lastausgleichsfunktion und leitet TCP- und UDP-Stream weiter.

Container runtime

Container runtime ist die Software, die für das Ausführen von Containern verantwortlich ist. Container runtime überstürzt eine Reihe von Container-Technologien: Dockercontainerdcri-orktlet und Kubernetes Container Runtime Interface.

 


Nützliche Informationen

Hier finden Sie einige Links, die Ihren einen tieferen Überblick über die Technologie geben können:

Folgenden Kubernets Visio Stencils in vssx-Format finden Sie unter diesem Link.

Kubernetes Visio Stencil

 

 

 

 

 

 

 

 

 

 

 

Wir nutzen Cookies auf unserer Website. Einige von ihnen sind essenziell für den Betrieb der Seite, während andere uns helfen, diese Website und die Nutzererfahrung zu verbessern (Tracking Cookies). Sie können selbst entscheiden, ob Sie die Cookies zulassen möchten. Bitte beachten Sie, dass bei einer Ablehnung womöglich nicht mehr alle Funktionalitäten der Seite zur Verfügung stehen.