© Liashko/Shutterstock.com
Natives Elasticsearch auf Kubernetes

ECK macht es einfach


Vor nicht langer Zeit war es undenkbar, persistente Daten auf Kubernetes zu stellen. Kluge Ops-Teams hätten eher auf einen vergleichbaren Cloud-Service gesetzt und die Funktionalität für Simplizität und ein ruhiges Gewissen geopfert. In den letzten Jahren ist Kubernetes aber gereift und in Bereiche vorgestoßen, die zuvor nicht annähernd als geeignet für die Containerorchestrierung angesehen wurden.

Kubernetes hat an Stabilität und Funktionsumfang zugenommen und sich von einem Tool zu einer richtigen Plattform entwickelt. Eines der mächtigsten Features der letzten Releases ist die Kombination von Custom Resource Definitions (CRDs) und dem Operator Pattern.

Das Operator Pattern (oder einfach Operators) stellt ein sehr mächtiges Konzept dar, mit dem Softwareanbieter Betriebsmuster in Kubernetes abstrahieren können. Der Einsatz des Operator Patterns kann die notwendige Menge an Tools, Skripten und manueller Arbeit zum Betreiben komplexer Software massiv reduzieren. Operators erlauben es, innerhalb eines Dokuments – in einem sogenannten Kubernetes-Manifest – das gesamte Deployment zu beschreiben, nicht nur die Artefakte, die deployt werden. Auch wenn man eine Datenbank sehr schnell auf Kubernetes deployen kann, wenn man Helm oder ein Kubernetes-Manifest verwendet, ist es doch meist Aufgabe des Endnutzers, für Sicherheit, Back-ups und Nutzerverwaltung zu sorgen.

Im Gegensatz dazu können viele dieser Aufgaben in einem System, das via CRDs und Operators deployt wird, automatisiert und mit der Kubernetes Configuration Language definiert werden. Diese Herangehensweise macht es leichter, bestehende Cluster und deren Zustand bzw. Verhalten zu durchblicken, die Konfiguration zu zentralisieren und Best Practices bestimmter Anbieter anzuwenden. Obwohl das Operator Pattern noch relativ neu ist, wird es bereits bei vielen Anbietern (inkl. Elastic) eingesetzt, um einen Betrieb der eigenen Programme auf Kubernetes zu ermöglichen.

Für Fans von Elasticsearch und dem wachsenden Elastic Stack bietet sich so die Möglichkeit, die Vorteile der Standarddistribution nativ auf Kubernetes zu nutzen. Elastic hat hierfür kürzlich Elastic Cloud on Kubernetes (ECK) veröffentlicht, es soll zum offiziellen Weg werden, Elastic Cloud auf Kubernetes auszuführen. Ein recht großer Funktionsumfang ist im Operator bereits enthalten (Kasten: „Fünf Vorteile des nativen Betreibens von Elasticsearch auf Kubernetes via ECK“).

Fünf Vorteile des nativen Betreibens von Elasticsearch auf Kubernetes via ECK

  • Sicherheit von Beginn an: ECK [1] konfiguriert die Sicherheitseinstellungen, Node to Node TLS, Zertifikate und einen Defaultuser für jeden Cluster automatisch.

  • Kubernetes-native Elasticsearch-Ressourcen: Elasticsearch kann genau wie jede andere Kubernetes-Ressource genutzt werden. Es gibt keine Notwendigkeit, endlose Kubernetes Pods, Services und Secrets zu konfigurieren.

  • Best Practices von Elastic: ECK funktioniert im täglichen Elasticsearch-Betrieb nach den etablierten Prinzipien – von der Skalierung bis zum Versionswechsel.

  • Exklusive Elastic-Features: Zugang zu allen Funktionen von Elastic, inklusive Elastic SIEM [2], Observability [3], Logs [4], Infrastruktur [5] und mehr.

  • Fortschrittliche Topologie: Nutzer können die Vielseitigkeit der eigenen Kubernetes-Infrastruktur auf das Elasticsearch Deployment anwenden. So können etwa auch Hot-Warm-Cold-Architekturen [6] genutzt werden, um die Kosten zu reduzieren.

Bis vor Kurzem lief die Installation eines produktionsfertigen Elastic Stack ziemlich standardmäßig ab. Man erstellt ein Set von Masters, um den Cluster zu managen, dann werden Nodes hinzugefügt und konfiguriert, sie können verschiedene Rollen einnehmen. Je nach Automatisierung war das Management des Elastic Clusters sehr umfangreich, und eine gewisse Orchestrierung wurde nötig, um sicherzugehen, dass der Cluster aktiv und bereit für Traffic ist.

Das Erstellen einer produktionsfertigen Elastic-Umgebung ist nicht annähernd so kompliziert wie das anderer Enterprise-Software. Doch es ist komplex genug, dass ein gewisses Maß an Planung, Wissen, Automatisierung und Ressourcen unabdinglich ist, um dessen Bereitschaft zur Nutzung sicherzustellen. Mit ECK existiert eine gute Alternative für das Deployment von Elastic, mit der die Vorteile von Kubernetes und des Operator Patterns genutzt werden können. Auch wenn dies das generelle Cluster-Management nicht komplett obsolet macht, werden so einige Arbeitsschritte obsolet und einige Aufgaben erleichtert. Elemente wie Cluster-Upgrades, das Absichern des Clusters und dynamische Cluster-Skalierung sind in ECK out of the box verfügbar, Gleiches gilt für eine vereinfachte Automatisierung.

Als Beispiel einer ECK-Installation wollen wir einen produktionsreifen Elastic Stack auf einem existierenden Kubernetes Cluster installieren. Dieser kann entweder lokal via Minikube oder K3s erstellt werden, oder man deployt ihn auf einem verwalteten Cluster in der Cloud (etwa GCP oder EKS). Um zu starten, müssen wir die Custom Resource Definitions und die Operators auf dem Cluster installieren: kubectl apply -f https://download.elastic.co/downloads/eck/1.0.0-beta1/all-in-one.yaml. Der Befehl wendet alle Ressourcen an, aus denen sich die verschiedenen Komponenten-ECK zusammensetzen.

Jetzt haben wir die ECK-Komponenten installiert und können unsere Elastic-Konfiguration erstellen. In diesem Beispiel werden wir ein robustes Layout mit mehreren Mastern, separaten Daten-Nodes und dedizierten Ingress-Servern erstellen. Wir beginnen mit der Erstellung der Master-Nodes. Erstellen Sie eine neue Datei elastic.yaml und fügen den Code aus Listing 1 ein.

Listing 1

apiVersion: elasticsearch.k8s.elastic.co/v1beta1 kind: Elasticsearch metadata: name: monitoring namespace: monitoring spec: version: 7.4.0 nodeSets: - name: master count: 1 config: node.master: true node.data: false node.ingest: false node.store.allow_mmap: false resources: requ...

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