© Liashko/Shutterstock.com
Eine Einführung in das Operator Framework

Automatisierung mit Kubernetes Operators


In der Kubernetes-Sprache ist ein Operator ein Stück Software, das operatives Wissen (daher der Name) über Betrieb und Installation eines bestimmten Programms oder einer Systemkomponente seinerseits in Software abbildet und damit automatisieren kann. Lernen Sie, wie Sie einen solchen Operator mit Hilfe des Operator SDKs selbst in Go programmieren können.

Kubernetes erfreut sich in der DevOps-Szene aktuell größter Beliebtheit; das liegt nicht zuletzt daran, dass Kubernetes – im Zusammenspiel mit der jeweils gewählten Containertechnologie – von Haus aus zahlreiche Möglichkeiten liefert, wiederkehrende Vorgänge einfach zu automatisieren. Dazu zählt beispielsweise das Ausführen von Rolling Updates für Applikationen, die in der Regel ohne Downtime ausgeführt werden können. Bei aller Automatisierung stoßen jedoch auch irgendwann die Kubernetes-Bordmittel an ihre Grenzen. Insbesondere bei Einrichtung und Betrieb besonders komplexer Softwarekomponenten ist immer noch Spezialwissen des Administrators gefragt. Klassische Beispiele für solche Komponenten sind komplexe, zustandsbehaftete und schlimmstenfalls noch geclusterte Anwendungen, wie beispielsweise Datenbanksysteme.

Operators sind ein Ansatz, das Wissen über Set-up und Betrieb solcher Anwendungen in Software zu gießen, um einen noch höheren Automatisierungsgrad zu erreichen. Anfang März startete Red Hat OperatorHub. io [1] – ein Projekt mit dem Ziel, ein zentrales Verzeichnis für solche Operators zu schaffen. Zum aktuellen Zeitpunkt finden sich hier bereits zahlreiche Operators für den Betrieb verschiedenster zustandsbehafteter Anwendungen, wie beispielsweise Apache Kafka, Prometheus, Percona MySQL und andere. Eine Suche auf GitHub [2] offenbart zahlreiche weitere Operators.

Operators und Custom Resources

Eines der Kernprinzipien von Kubernetes besteht darin, dass verschiedene Objekttypen genutzt werden können, um den gewünschten Zustand des Systems zu beschreiben. Kubernetes (genauer gesagt, der Controller Manager [3]) sorgt dann dafür, dass der Ist-Zustand des Systems mit dem gewünschten Zustand übereinstimmt. Erstellt ein Nutzer also ein Deployment-Objekt, sorgt der Controller Manager dafür, dass für dieses Deployment ein ReplicaSet erstellt wird (und für das ReplicaSet wiederum die gewünschte Anzahl Pods).

Die meisten Operators funktionieren nach demselben Prinzip – der Nutzer agiert mit ihnen über Objekte des Kubernetes API – entweder direkt über das API oder beispielsweise kubectl. Statt der Standardtypen bieten zahlreiche Operators sogenannte Custom Resources an. Mit ihnen kann das Kubernetes API um eigene benutzerdefinierte Datentypen erweitert werden. Die Definition eines solchen Datentyps erfolgt ebenfalls wieder über das Kubernetes API in Form einer CustomResourceDefinition (CRD). Listing 1 zeigt, wie solch eine Definition aussehen könnte.

Listing 1

apiVersion: apiextensions.k8s.io/v1beta1 kind: CustomResourceDefinition metadata: name: example.stable.helmich.me spec: group: stable.helmich.me versions: - name: v1alpha1 served: true storage: true scope: Namespaced names: plural: examples singular: example kind: Example shortNames: - ex

Eine genaue Beschreibung, mit welchen Eigenschaften eine CRD spezifiziert werden kann, findet sich unter [4]. Nachdem eine solche Definition erstellt wurde (beispielsweise mit dem Befehl kubectl create), können nun Instanzen dieser Custom Resource erstellt werden. Listing 2 zeigt ein Beispiel für die oben definierte Example-Ressource.

Listing 2

apiVersion: stable.helmich.me/v1alpha1 kind: Example metadata: name: first-example namespace: default spec: foo: bar

Auch solch ein Objekt kann ganz normal etwa über kubectl create erstellt werden. Existierende Objekte können im Anschluss mit dem Befehl kubectl get examples (hier kommt die spec.names-Eigenschaft aus Listing 1 ins Spiel) wieder aufgelistet werden. Mit solchen Custom Resources eröffnen sich vielfältige Möglichkeiten, die ein Kubernetes Operator nutzen kann. Der übliche Arbeitsablauf eines Operators sieht dabei aus wie folgt:

  1. Der Operator erstellt (üblicherweise bei der Installation) eine CustomResourceDefinition.

  2. Der Nutzer kann nun über die üblichen Kubernetes-Bordmittel (wie etwa kubectl) Instanzen dieser CRD erstellen.

  3. Der Operator beobachtet die Instanzen der von ihm verwalteten CRDs (in aller Regel über die WATCH-Funktion des Kubernetes API), und erstellt anhand der in der Custom Resource gespeicherten Informationen weitere Kubernetes-Objekte, wie etwa Deployments, StatefulSets und andere. Wird die Custom Resource bearbeitet, propagiert der Operator diese Änderungen an die erstellten Unterobjekte weiter.

  4. Wenn der Nutzer die Instanz der Custom Resource entfernt (z. B. per kubectl delete), löscht ein Operator üblicherweise auch die erstellten Unterobjekte.

Das Beispielprojekt

Die Funktionsweise eines Operators sowie die Verwendung des Operator SDKs (mehr dazu in den nächsten Abschnitten) lassen sich am besten anhand eines Beispiels [5] erläutern. Für diesen Artikel möchten wir daher einen Beispiel-Operator schreiben, der eine einfache Webapplikation verwaltet – genauer gesagt, Instanzen des Image martinhelmich/helloworld, eine Anwendung, die (wer hätte es gedacht?) HTTP-Anfragen mit „Hello World“ beantwortet. Die Applikation soll über CRDs des Namens „HelloWorld“ verwaltet werden. Für jede Instanz soll der Operator ein Deployment-, sowie ein Service- und ein Ingress-Objekt erstellen. Über die Custom Resource sollen Nutzer konfigurieren können, wie viele Instanzen der Applikation laufen sollen, wer genau gegrüßt werden (statt immer nur „World“) und über welchen Hostnamen die Applikation erreichbar sein soll.

Das Operator Framework

Ein Kubernetes-Operator ist selbst ein relativ komplexes Stück Software – und dabei machen viele der Operators, die es bis...

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