Kubernetes Vor- und Nachteile

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. Kubernetes wird oft mit „K8S“ abgekürzt — zwischen dem „K“ und dem „S“ stehen 8 Buchstaben.

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:

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

Einen tiefen Einblick in die Kubernetes Architektur finden SIe in diesem Beitrag: Überblick über die Kubernetes Architektur

 


Kubernetes-Abstraktionsebenen 

Im weiteren Teil des Beitrages möchte ich die Abstraktionsebenen und einige weiteren Komponenten des Kubernetes-Clusters näher beleuchten.

 

ReplicaSet

Wie wir bereits aus dem vorherigen Blogbeitrag wissen, ist ein Pod die kleinste Deployment-Einheit, die die eigentlichen Container beinhaltet.

Der ReplicaSet ist ein weiteres Abstraktionslevel.  Aus Sicht der Aufbau eines yaml-Definition-Files ist der ReplicaSet ein Parent-Objekt und der Pod ein Child-Objekt.

Deployment

Das Deployment ist ein weiteres Level in der Abstraktionshierarchie und steuert sowohl die ReplicaSets als auch die Pods. Man konnte ein Deployment als eine Weiterentwicklung des ReplicaSets bezeichnen.

Je nach Konfiguration verfügt ein Deployment über eine breite Palette an Funktionen:

Es wird von Hersteller ausdrücklich empfohlen, ein Deployment anstelle des ReplicaSets zu verwenden.

Labels / Selectors

Ein Label ist ein Schlüssel-Wertpaar, das dazu dient, die Kubernetes-Objekte zu identifizieren bzw. organisieren. Die Labels können zum Gruppieren und Auswählen von Teilmengen von Objekten verwendet werden. Die Labels können einem Objekt während der Erstellung hinzugefügt und danach jederzeit geändert werden.

Selectors werden verwendet, um eine Reihe von Objekten in Kubernetes zu identifizieren.

Services

Ein Kubernetes Services ist sowohl eine weitere Abstraktion als auch ein REST Objekt.

Insgesamt gibt es vier Service-Typen:

Kubernetes Services explained | ClusterIP vs NodePort vs LoadBalancer vs Headless Service

Namespaces

Namespace bietet die Möglichkeit den Kubernetes-Cluster in kleinere Einheiten (Arbeitsbereiche) aufzuteilen. Auf dieser Art und Weise können Sie z.B. dem Entwickler-Teams einen eigenen Bereich zuweisen, damit die weiteren Bereiche nicht beeinträchtigt werden. Standartmäßig werden alle Ressourcen in einem default-Namespace erstellt.

StatefulSet

Analog zu den Deployments sind die StatefulSets zur Verwaltung der Pods vorgesehen.

Die Verwendung von SatefulSet ist dann notwendig, wenn für die laufende Pods eine bestimmte und eindeutige Konfiguration vorgesehen und notwendig wird.  SatefulSet kann garantieren, dass die Pods z.B. in der richtigen Reihenfolge bereitgestellt werden, den Zugriff auf denselben Speicher beibehalten oder eine gleiche und eindeutige Netzwerkkennung bekommen. Wenn Sie z.B. MySQL bereitstellen möchten, wird Ihnen der StatefulSet garantieren, dass der Master-Server immer der Master-Server bleibt.

DaemonSets

Der DaemonSet eine weitere Control-Funktion in Kubernetes-Cluster. Der DaemonSet sorgt dafür, dass die Pods auf allen oder auf bestimmten (Node Affinity) Nodes ausgeführt werden. Ein DaemonSet erstellt standardmäßig auf jedem Knoten einen Pod.

Ingress

Ein Ingress ein API-Objekt, welcher in den meisten Fällen auf einem separaten Node installiert wird und eine Rolle des externen Load Balancer übernimmt. Der Zugriff von externen Benutzern auf die Cluster-Ressourcen findet immer über den Ingress statt.

 


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