© Natali Snailcat/Shutterstock.com
Teil 4: Deep-dive in die Containerorchestrierung und Kubernetes

Tief hinab!


In den vergangenen Jahren haben wir unsere Anwendungen in Container verpackt, um diese zu isolieren und einfach auslieferbar zu machen. Nun kämpfen wir damit, Anwendungen mit persistenten Daten in Containern zu betreiben, um sie fehlertoleranter und skalierbarer zu machen. Daher betreiben wir Datenbanken meist in separaten Clustern, weil es noch relativ schwer ist, sie sinnvoll in Containern zu orchestrieren. Das bedeutet allerdings, dass wir unsere gesamte Infrastruktur nicht optimal ausnutzen und Skalierungseffekte zwischen zustandslosen und zustandsbehafteten Anwendungen verschenken. Aber was bedeutet es eigentlich, eine Datenbank in einen Container zu stecken?

Artikelserie

Teil 1: Motivation, Fehler und Beefy Server

Teil 2: Speicheroptionen und Back-ups

Teil 3: CPU, Multiplexing, Netzwerk, Service Discovery und mehr

Teil 4: Deep-dive in die Containerorchestrierung und Kubernetes

Im vorherigen Teil haben wir verschiedene Technologien und ihre Auswirkung auf die Performanz untersucht. Abschließend haben wir diskutiert, dass ein einfacher Befehl wie docker run oder docker-compose up nicht ausreicht, um eine Produktionsumgebung zu betreiben. Wir müssen uns Gedanken über die Orchestrierung unserer Anwendung machen, uns also mit Container-Scheduling befassen. Dabei geht es darum, wann und wo ein Container aus welchem Grund gestartet wird. Weiterhin müssen wir uns mit dem Ressourcenmanagement beschäftigen, also den Zugriff unserer Container auf Ressourcen einschränken. Abschließend müssen wir uns noch um das Service-Management kümmern, also dafür sorgen, dass sich unsere Container gegenseitig finden, wir Abhängigkeiten auflösen und so weiter. Eine Lösung für all diese Herausforderungen bietet zum Beispiel Kubernetes, das Framework für die Containerorchestrierung. Wir werden Kubernetes in diesem Teil der Reihe intensiv betrachten.

Die diesjährige europäische Version der Kubernetes-Konferenz KubeCon fand in Barcelona statt und hatte über 8 000 Besucher. In einer der Keynotes wurde von Cheryl Hung berichtet, dass Kubernetes zum damaligen Zeitpunkt über 2,66 Millionen Kontributionen von über 50 000 Helfern hatte. Dabei wurden nicht nur Codekontributionen gezählt, sondern auch Code-Reviews, Dokumentationen oder das Erstellen von Issues auf GitHub. Damit zählt Kubernetes wohl zu den aktuell aktivsten und größten Open-Source-Projekten und hat sich in den letzten Jahren zu der am weitesten verbreiteten Orchestrierungslösung für Container etabliert. Der Vorteil dieser Popularität ist ganz klar, dass nicht nur viel Software innerhalb von Kubernetes geschrieben wird, sondern auch viel Software drum herum. So gibt es viele Projekte, die sich um persistenten Speicher drehen oder um Netzwerke, Service Discovery, Sicherheit und so weiter. Weiterhin ist von sehr großem Vorteil, dass es auch gehostete Kubernetes-Angebote gibt und auch Installation und Betrieb im eigenen Rechenzentrum immer einfacher werden.

Wie funktioniert Kubernetes eigentlich?

Ich möchte an dieser Stelle nur eine sehr vereinfachte Erläuterung geben, was Kubernetes ist und wie einige Aspekte innerhalb von Kubernetes funktionieren, damit wir darauf aufbauend besprechen können, wie wir eine Datenbank in Kubernetes starten können. Sollte Interesse an mehr Informationen bestehen, ist die offizielle Webseite von Kubernetes [1] eine großartige Quelle für Anleitungen und weiterführende Dokumentationen.

Wichtige Komponenten in Kubernetes

In Kubernetes gibt es zwei Arten von Servern: Master und Agenten. Generell laufen auf den Master-Servern administrative Komponenten, und auf den Agenten werden die eigentlichen Container ausgeführt. Zu den Komponenten des Masters gehören unter anderem etcd, in dem alle Ressourcen gespeichert werden, die Benutzer anlegen.

Weiterhin gibt es den API-Server, der es den Benutzern ermöglicht, Ressourcen anzulegen. Dabei hat man die Wahl, ob man in einem JSON-Format oder in YAML mit dem API-Server kommunizieren möchte. Weiterhin laufen die Kubernetes-eigenen Controller auf den Mastern. Ein Controller ist dabei ein Programm, das sich um eine Ressource in Kubernetes kümmert. Zum Beispiel kann man eine Pod-Ressource mit Hilfe des API-Servers anlegen und in etcd speichern, und es gibt den PodController, der sich um diese Ressource kümmert. Ein Pod ist eine Gruppe von Containern, die zusammen definiert und gestartet werden und sich Netzwerk und Speicher teilen können.

Datenmodell von Kubernetes und Controller

Es gibt aber nicht nur Pods im Datenmodell von Kubernetes. Abbildung 1 beschreibt einen kleinen Ausschnitt des gesamten Datenmodells. Es gibt ReplicaSets, die auf Pods aufbauen und beschreiben, wie sich Replikationen von einzelnen Pods verhalten sollen. In einem ReplicaSet wird beschrieben, welche Pods benötigt werden, aber auch, wie die Regeln für die Replikation sind und wie im Fehlerfall damit umgegangen wird.

Pods können aber auch in einem StatefulSet zusammengefasst werden. Zusätzlich werden in einem StatefulSet auch persistente Volumes (PV) und die Ansprüche von Containern auf diese Volumes (PVC: Persistent Volume Claim) beschrieben. Weiterhin ist die Implementierung und Konfiguration von StatefulSets besonders für Datenbanken optimiert und respektiert generische Anforderungen von Datenbanken zum Beispiel bei der Fehlerbehandlung oder bei ...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang