© svetabelaya/Shutterstock.com
Tutorial: CrateDB-Cluster mit Kubernetes aufsetzen

Schritt für Schritt


Dank ihrer horizontal skalierbaren Shared-Nothing-Architektur eignet sich die Datenbank CrateDB sehr gut, um mit Containertechnologien wie Docker zu arbeiten. Im praktischen Leben erweist es sich zumeist als sinnvoll, Docker um eine Containerorchestrierungslösung zu ergänzen – einfach weil die Anzahl der Container schnell wächst und Runtime-Abhängigkeiten untereinander entstehen, die aufeinander abgestimmt werden müssen. Eine dieser Lösungen ist Kubernetes.

Kubernetes ist ein Open-Source-Werkzeug mit großer, aktiver Community und namhaften Unterstützern. Einen CrateDB-Cluster mit Kubernetes aufzusetzen, ist in wenigen Schritten machbar. Scale-out und Scale-in sind unkompliziert, was den Cluster besonders flexibel macht.

Kubernetes: von Pods, Controllern und Services

Hinter dem Begriff Containerorchestrierung stecken das Management, das Deployment und die Skalierung von containerisierten Systemen. Im Prinzip ist Kubernetes ein System von Prozessen, die verteilt über alle zum Kubernetes-Cluster gehörenden Nodes laufen. Mindestens ein Knoten muss dabei als Master fungieren, die Anzahl der Slaves ist beliebig. Die Container, die die zu deployende Software zum Laufen bringen, werden dann intelligent auf alle Kubernetes Nodes verteilt. Je nach Funktion des jeweiligen Servers laufen unterschiedliche Komponenten von Kubernetes [1] darauf. So entstehen praktisch diverse Instanzen dieser Komponenten, die sich über mehrere Maschinen hinweg koordinieren. Um den Zustand eines Kubernetes-Clusters zu definieren, sind vor allem drei Konzepte von Bedeutung: Pods, Controller und Services.

Ein Pod repräsentiert eine einzelne Recheneinheit und damit den grundlegenden Baustein jedes Systems. Das kann ein einzelner Container sein oder mehrere eng miteinander verbundene. Wird beispielsweise eine Webapplikation deployt, führt ein Pod eine einzelne Instanz der Anwendung aus. Pods lassen sich horizontal skalieren, indem zum Beispiel Replica Pods hinzugefügt oder – bei einem Scale-in – entsprechend entfernt werden. Komplexere Anwendungen benötigen oft mehr als einen Container. Alle Container in einem Pod teilen sich eine gemeinsame Netzwerkschnittstelle, und jeder Container hat Zugriff auf die dem Pod zugeordneten Speichervolumen. Das offizielle CrateDB Docker Image [2] eignet sich sehr gut als Single-Container-Pod, aus einer Kombination von mehreren kann ein CrateDB-Cluster beliebiger Größe entstehen.

Pods werden normalerweise nicht von Hand erstellt, sondern Controller kreieren sie. Controller managen ein Set von Pods gemäß einer vorgegebenen Spezifikation. Kubernetes stellt von Haus aus mehrere Controller für unterschiedliche Zwecke bereit. Ein Beispiel: Idealerweise sollten Container stateless sein, damit es keine negativen Auswirkungen hat, wenn etwa ein Container zerstört, neu gebaut oder auf einen anderen Server verschoben wird. Aber: Zustandslose Container eignen sich zwar für Webanwendungen, die den Zustand gegenüber einer externen Datenbank aufrechterhalten. Die Datenbanken selbst erfordern jedoch eine persistente Speicherung: Die Daten sollen nicht verloren gehen, nur weil ein Container neu geschedult wurde. Kubernetes stellt den StatefulSet Controller [3] bereit, der jedem Pod eine feste Identität und einen festen Speicherplatz zuweist, die bei Neustarts und Rescheduling erhalten bleiben. Der Controller erstellt dabei alle Pods innerhalb eines StatefulSet aus derselben Vorlage, dennoch sind sie nicht austauschbar.

Da die Pods gestoppt, gestartet und auf jeden beliebigen Kubernetes-Knoten neu verplant werden können, ändern sich die zugewiesenen IP-Adressen im Laufe der Zeit. Clientanwendungen sollen jedoch nicht mit wechselnden IP-Adressen zurechtkommen müssen. Dafür gibt es die Kubernetes Services: statische Interfaces, um Zugang zu einem oder mehreren Pods zu erhalten. Ein typischer Service ist ein Load Balancer, der die ankommenden Queries auf den gesamten Cluster verteilt. Das Verständnis für die beschriebenen Kubernetes-Konzepte ist notwendig, um die Konfigurationen für den CrateDB-Cluster nachvollziehen zu können.

Den Kubernetes-Cluster aufsetzen

Für einen unkomplizierten und trotzdem leistungsfähigen Start eignet sich Minikube [4], mit dem Kubernetes einfach lokal ausgeführt werden kann. Minikube ist in der Lage, mit verschiedenen Hypervisoren als VM-Laufzeit zu arbeiten, standardmäßig ist aber alles für die Arbeit mit VirtualBox [5] – einer populären Cross-Plattform-Virtualisierungslösung – vorbereitet. Wenn ein kompatibler Hypervisor wie VirtualBox auf dem System installiert ist, erkennt Minikube diesen und setzt die VM automatisch auf. Darüber hinaus wird das Standardkommandozeilentool kubectl [6] benötigt, mit dem sich Kubernetes-Cluster Anweisungen geben lassen.

Sind alle drei Komponenten installiert, kann das System gestartet werden. Per Default weist Minikube der VM 1 GB Speicher zu. Das kann nach Bedarf angepasst werden, wie im in Listing 1 gezeigten Beispiel mit --memory 4096.

Listing 1

$ minikube start --memory 4096 Starting local Kubernetes v1.10.0 cluster... Starting VM... Downloading Minikube ISO 160.27 MB / 160.27 MB [======================================] 100.00% 0s Getting VM IP address... Moving files into cluster... Setting up certs... Connecting to cluster... Setting up kubeconfig... Starting cluster components... Kubectl is now configured to use the cluster. Loading cached images from config file.

Um den neu geschaffenen Kubernetes-Cluster verwenden zu können, konfiguriert Minikube nun automatisch kubectl. Mit folgendem Befehl lässt sich das überprüfen:

$ kubectl get nodes NAME STATUS ROLES AGE VERSION minikube Ready master 4m v1.10.0

Mit Hilfe von Namespaces [7] unterteilt Kubernetes den physischen Cluster in mehrere Bereiche. Technisch gesehen muss für den CrateDB-Cluster kein extra Namensraum angelegt werden, es empfiehlt sich aber, um den Überblick über die Ressourcen zu bewahren. Mit dem folgenden Kommando wird ein neuer Namespace kreiert:

$ kubectl create namespace crate namespace/crate created

Fragt man die vorhandenen Namespaces nun ab, taucht der neu geschaffene (crate) unter den üblichen Namespaces auf. Während der Namespace default immer dann genutzt wird, wenn kein anderer spezifiziert wurde, steht kube-public für alle Ressourcen, die öffentlich verfügbar sind und kube-system für die intern von Kubernetes genutzten Ressourcen.

$ kubectl get namespaces NAME STATUS AGE default Active 32m kube-public Active 31m kube-system Active 32m crate Active 59s

Die CrateDB Services einrichten

Damit CrateDB arbeiten kann, muss jed...

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