Kubernetes Operators

Kapitel 1. Operatoren bringen Kubernetes neue Tricks bei

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

Ein Operator ist eine Möglichkeit, eine Kubernetes-Anwendung zu verpacken, auszuführen und zu warten. Eine Kubernetes-Anwendung wird nicht nur in Kubernetes eingesetzt, sondern ist so konzipiert, dass sie mit den Kubernetes-Einrichtungen und -Tools zusammenarbeitet.

Ein Operator baut auf den Abstraktionen von Kubernetes auf, um den gesamten Lebenszyklus der Software zu automatisieren, die er verwaltet. Da sie Kubernetes erweitern, bieten Operatoren anwendungsspezifische Automatisierung in Begriffen, die einer großen und wachsenden Gemeinschaft vertraut sind. Für Anwendungsprogrammierer/innen erleichtern Operatoren die Bereitstellung und Ausführung der Basisdienste, von denen ihre Anwendungen abhängen. Für Infrastruktur-Ingenieure und -Anbieter bieten Operatoren eine konsistente Möglichkeit, Software auf Kubernetes-Clustern zu verteilen und den Support-Aufwand zu reduzieren, indem Anwendungsprobleme erkannt und behoben werden, bevor der Pager piept.

Bevor wir beschreiben, wie Operatoren diese Aufträge erledigen, wollen wir ein paar Kubernetes-Begriffe definieren, um den Kontext und eine gemeinsame Sprache für die Beschreibung von Operator-Konzepten und -Komponenten zu schaffen.

Wie Kubernetes funktioniert

Kubernetes automatisiert den Lebenszyklus einer zustandslosen Anwendung, z. B. eines statischen Webservers. Ohne Zustand sind alle Instanzen einer Anwendung austauschbar. Dieser einfache Webserver ruft Dateien ab und sendet sie an den Browser eines Besuchers. Da der Server keinen Status verfolgt und keine Eingaben oder Daten speichert, kann Kubernetes beim Fehlschlagen einer Serverinstanz diese durch eine andere ersetzen. Kubernetes bezeichnet diese Instanzen, die jeweils eine Kopie einer im Cluster laufenden Anwendung sind, als Replikate.

Ein Kubernetes-Cluster ist eine Sammlung von Computern, den sogenannten Nodes. Die gesamte Arbeit des Clusters läuft auf einem, einigen oder allen Knoten eines Clusters. Die Grundeinheit der Arbeit und der Replikation ist der Pod. Ein Pod ist eine Gruppe von einem oder mehreren Linux-Containern mit gemeinsamen Ressourcen wie Netzwerk, Speicherung und Zugriff auf den gemeinsamen Speicher.

Hinweis

Die Kubernetes Pods-Dokumentation ist ein guter Ausgangspunkt für weitere Informationen über die Pod-Abstraktion.

Auf einer hohen Ebene kann ein Kubernetes-Cluster in zwei Ebenen unterteilt werden. Die Steuerungsebene ist, einfach ausgedrückt, Kubernetes selbst. Eine Sammlung von Pods bildet die Steuerungsebene und implementiert die Kubernetes-Programmierschnittstelle (API) und die Logik der Cluster-Orchestrierung.

Die Anwendungsebene, oder Datenebene, ist alles andere. Sie ist die Gruppe von Knoten, auf denen Anwendungs-Pods laufen. Ein oder mehrere Knoten sind in der Regel für die Ausführung von Anwendungen vorgesehen, während ein oder mehrere Knoten oft nur für die Ausführung von Control Plane Pods reserviert sind. Wie bei den Application Pods können mehrere Replikate der Control Plane-Komponenten auf mehreren Controller-Knoten laufen, um Redundanz zu gewährleisten.

Die Controller der Steuerebene implementieren Kontrollschleifen, die den gewünschten Zustand des Clusters immer wieder mit dem tatsächlichen Zustand vergleichen. Wenn die beiden Werte voneinander abweichen, ergreift ein Controller Maßnahmen, um sie anzugleichen. Die Operatoren erweitern dieses Verhalten. Das Schema in Abbildung 1-1 zeigt die wichtigsten Komponenten der Control Plane mit Worker Nodes, auf denen Anwendungsworkloads laufen.

Die strikte Trennung zwischen Kontroll- und Anwendungsebene ist zwar ein praktisches mentales Modell und ein gängiger Weg, einen Kubernetes-Cluster einzusetzen, um die Arbeitslasten zu trennen, aber die Komponenten der Kontrollebene sind eine Sammlung von Pods, die wie jede andere Anwendung auf Knoten laufen. In kleinen Clustern teilen sich die Komponenten der Steuerebene oft einen oder zwei Knoten mit den Anwendungsworkloads.

Das konzeptionelle Modell einer abgesperrten Kontrollebene ist auch nicht ganz so ordentlich. Der Kube-Let-Agent, der auf jedem Knoten läuft, ist zum Beispiel Teil der Steuerungsebene. Ebenso ist ein Operator eine Art Controller, der in der Regel als Komponente der Steuerungsebene betrachtet wird. Operatoren können diese klare Grenze zwischen den Ebenen jedoch verwischen. Die Kontroll- und Anwendungsebene als isolierte Bereiche zu betrachten, ist eine hilfreiche, vereinfachende Abstraktion, aber keine absolute Wahrheit.

Abbildung 1-1. Kubernetes-Kontrollebene und Worker-Knoten

Beispiel: Zustandsloser Webserver

Da du noch keinen Cluster eingerichtet hast, sind die Beispiele in diesem Kapitel eher ein Terminal Auszug "Screenshots", die zeigen, wie grundlegende Interaktionen zwischen Kubernetes und einer Anwendung aussehen. Es wird nicht erwartet, dass du diese Befehle ausführst, wie du es im Rest des Buches tust. In diesem ersten Beispiel verwaltet Kubernetes eine relativ einfache Anwendung und es sind keine Operatoren beteiligt.

Stell dir einen Cluster vor, in dem ein einziges Replikat eines statischen Webservers läuft:

$ kubectl get pods>
NAME                        READY     STATUS    RESTARTS   AGE

staticweb-69ccd6d6c-9mr8l   1/1       Running   0          23s

Nachdem deklariert wurde, dass es drei Replikate geben soll, weicht der tatsächliche Zustand des Clusters vom gewünschten Zustand ab, und Kubernetes startet zwei neue Instanzen des Webservers, um die beiden auszugleichen und die Webserverbereitstellung zu skalieren:

$ kubectl scale deployment staticweb --replicas=3
$ kubectl get pods
NAME                        READY   STATUS    RESTARTS   AGE
staticweb-69ccd6d6c-4tdhk   1/1     Running   0          6s
staticweb-69ccd6d6c-9mr8l   1/1     Running   0          100s
staticweb-69ccd6d6c-m9qc7   1/1     Running   0          6s

Das Löschen eines der Webserver-Pods löst Arbeiten in der Steuerebene aus, um den gewünschten Zustand der drei Replikate wiederherzustellen. Kubernetes startet einen neuen Pod, der den gelöschten Pod ersetzt. In diesem Auszug zeigt der Ersatz-Pod eine STATUS von ContainerCreating an:

$ kubectl delete pod staticweb-69ccd6d6c-9mr8l
$ kubectl get pods
NAME                        READY   STATUS                RESTARTS   AGE
staticweb-69ccd6d6c-4tdhk   1/1     Running               0          2m8s
staticweb-69ccd6d6c-bk27p   0/1     ContainerCreating     0          14s
staticweb-69ccd6d6c-m9qc7   1/1     Running               0          2m8s

Der Webserver dieser statischen Website ist mit jedem anderen Replikat oder mit einem neuen Pod, der eines der Replikate ersetzt, austauschbar. Er speichert keine Daten und verwaltet keinen Status. Kubernetes muss keine besonderen Vorkehrungen treffen, um einen fehlgeschlagenen Pod zu ersetzen oder die Anwendung zu skalieren, indem Replikate des Servers hinzugefügt oder entfernt werden.

Stateful ist schwer

Die meisten Anwendungen haben einen Zustand. Sie haben auch Besonderheiten beim Start, bei der Abhängigkeit der Komponenten untereinander und bei der Konfiguration. Sie haben oft ihre eigene Vorstellung davon, was "Cluster" bedeutet. Sie müssen kritische und manchmal sehr umfangreiche Daten zuverlässig speichern. Das sind nur drei der Dimensionen, in denen reale Anwendungen ihren Zustand aufrechterhalten müssen. Es wäre ideal, diese Anwendungen mit einheitlichen Mechanismen zu verwalten und gleichzeitig ihre komplexen Anforderungen an Speicherung, Netzwerke und Clusterverbindungen zu automatisieren.

Kubernetes kann nicht alles über jede zustandsabhängige, komplexe, geclusterte Anwendung wissen und gleichzeitig allgemein, anpassungsfähig und einfach bleiben. Stattdessen soll Kubernetes eine Reihe flexibler Abstraktionen bereitstellen, die die grundlegenden Anwendungskonzepte wie Scheduling, Replikation und Failover-Automatisierung abdecken und gleichzeitig einen sauberen Erweiterungsmechanismus für fortgeschrittene oder anwendungsspezifische Operationen bieten. Kubernetes allein kann und sollte die Konfigurationswerte eines PostgreSQL-Datenbankclusters mit seinen geordneten Mitgliedschaften und seiner zustandsabhängigen, persistenten Speicherung nicht kennen.

Betreiber sind Software SREs

Site Reliability Engineering (SRE) ist eine Reihe von Mustern und Prinzipien für den Betrieb großer Systeme. SRE hat seinen Ursprung bei Google und hat die Praxis in der Branche stark beeinflusst. Die Praktiker müssen die SRE-Philosophie auf die jeweiligen Umstände auslegen und anwenden, aber ein zentraler Grundsatz ist die Automatisierung der Systemadministration durch das Schreiben von Software für den Betrieb deiner Software. Teams, die von der routinemäßigen Wartungsarbeit befreit sind, haben mehr Zeit, neue Funktionen zu entwickeln, Fehler zu beheben und ihre Produkte generell zu verbessern.

Ein Operator ist wie ein automatisierter Site Reliability Engineer für seine Anwendung. Er kodiert die Fähigkeiten eines erfahrenen Administrators in Software. Ein Operator kann z. B. einen Cluster von Datenbankservern verwalten. Er kennt die Details der Konfiguration und Verwaltung seiner Anwendung und kann einen Datenbank-Cluster mit einer bestimmten Softwareversion und Anzahl von Mitgliedern installieren. Ein Betreiber überwacht seine Anwendung während des Betriebs und kann Daten sichern, Fehler beheben und die Anwendung im Laufe der Zeit automatisch aktualisieren. Cluster-Nutzer verwenden kubectl und andere Standard-Tools, um mit Operatoren und den von ihnen verwalteten Anwendungen zu arbeiten, denn Operatoren erweitern Kubernetes.

Wie Operatoren arbeiten

Operatoren erweitern die Kubernetes Control Plane und die API. In seiner einfachsten Form fügt ein Operator der Kubernetes-API einen Endpunkt hinzu, eine benutzerdefinierte Ressource (CR), zusammen mit einer Control-Plane-Komponente, die Ressourcen des neuen Typs überwacht und verwaltet. Der Operator kann dann auf der Grundlage des Zustands der Ressource Maßnahmen ergreifen. Dies wird in Abbildung 1-2 dargestellt.

Abbildung 1-2. Operatoren sind benutzerdefinierte Kontrolleure, die eine benutzerdefinierte Ressource beobachten

Kubernetes CRs

CRs sind der API-Erweiterungsmechanismus in Kubernetes. Eine benutzerdefinierte Ressourcendefinition (Custom Resource Definition, CRD) definiert eine CR; sie ist vergleichbar mit einem Schema für die CR-Daten. Im Gegensatz zu den Mitgliedern der offiziellen API gibt es eine CRD nicht in jedem Kubernetes-Cluster. CRDs erweitern die API des jeweiligen Clusters, in dem sie definiert sind. CRs bieten Endpunkte zum Lesen und Schreiben strukturierter Daten. Ein Cluster-Benutzer kann mit CRs über kubectl oder einen anderen Kubernetes-Client interagieren, genau wie mit jeder anderen API-Ressource.

Wie Operatoren hergestellt werden

Kubernetes vergleicht eine Reihe von Ressourcen mit der Realität, d.h. dem laufenden Zustand des Clusters. Sie ergreift Maßnahmen, damit die Realität mit dem gewünschten Zustand übereinstimmt, der durch diese Ressourcen beschrieben wird. Operatoren erweitern dieses Muster auf bestimmte Anwendungen in bestimmten Clustern. Ein Operator ist ein benutzerdefinierter Kubernetes-Controller, der einen CR-Typ überwacht und anwendungsspezifische Maßnahmen ergreift, damit die Realität mit der spec in dieser Ressource übereinstimmt.

Einen Operator zu erstellen bedeutet, ein CRD zu erstellen und ein Programm bereitzustellen, das in einer Schleife läuft und CRs dieser Art überwacht. Was der Operator als Reaktion auf Änderungen in der CR tut, hängt von der Anwendung ab, die der Operator verwaltet. Die Aktionen, die ein Operator durchführt, können fast alles sein: Skalierung einer komplexen Anwendung, Aktualisierung von Anwendungsversionen oder sogar die Verwaltung von Kernelmodulen für Knoten in einem Rechencluster mit spezieller Hardware.

Beispiel: Der etcd-Operator

etcd ist ein verteilter Key-Value-Store. Mit anderen Worten, es ist eine Art leichtgewichtiger Datenbank-Cluster. Für die Verwaltung eines etcd-Clusters ist normalerweise ein erfahrener Administrator erforderlich. Ein etcd-Administrator muss wissen, wie man:

• Beitritt eines neuen Knotens zu einem etcd-Cluster, einschließlich der Konfiguration seiner Endpunkte, der Herstellung von Verbindungen zur persistenten Speicherung und der Benachrichtigung der bestehenden Mitglieder.

• Sichern Sie die Daten und die Konfiguration des etcd-Clusters.

• Aktualisiere den etcd-Cluster auf neue etcd-Versionen.

Der etcd Operator weiß, wie er diese Aufgaben ausführen kann. Ein Operator kennt den internen Zustand seiner Anwendung und ergreift regelmäßig Maßnahmen, um diesen Zustand mit dem gewünschten Zustand abzugleichen, der in der Spezifikation einer oder mehrerer benutzerdefinierter Ressourcen angegeben ist.

Wie im vorherigen Beispiel dienen die folgenden Shell-Auszüge der Veranschaulichung und du kannst sie ohne vorherige Einrichtung nicht ausführen. Du wirst diese Einstellungen vornehmen und einen Operator in Kapitel 2 ausführen.

Der Fall des vermissten Mitglieds

Da der etcd Operator den Zustand von etcd kennt, kann er den Ausfall eines etcd-Clustermitglieds auf die gleiche Weise wiederherstellen, wie Kubernetes den gelöschten zustandslosen Webserver-Pod in unserem früheren Beispiel ersetzt hat. Angenommen, es gibt einen etcd-Cluster mit drei Mitgliedern, der vom etcd Operator verwaltet wird. Der Operator selbst und die Mitglieder des etcd-Clusters laufen als Pods:

$ kubectl get pods
NAME                              READY     STATUS    RESTARTS   AGE
etcd-operator-6f44498865-lv7b9    1/1       Running   0          1h
example-etcd-cluster-cpnwr62qgl   1/1       Running   0          1h
example-etcd-cluster-fff78tmpxr   1/1       Running   0          1h
example-etcd-cluster-lrlk7xwb2k   1/1       Running   0          1h

Das Löschen eines etcd-Pods löst einen Abgleich aus, und der etcd-Operator weiß, wie er den gewünschten Zustand von drei Replikaten wiederherstellen kann - etwas, das Kubernetes allein nicht leisten kann. Aber anders als beim Neustart eines zustandslosen Webservers muss der Operator die Clustermitgliedschaft des neuen etcd-Pods arrangieren, indem er ihn für die vorhandenen Endpunkte konfiguriert und mit den übrigen etcd-Mitgliedern verbindet:

$ kubectl delete pod example-etcd-cluster-cpnwr62qgl
$ kubectl get pods
NAME                              READY     STATUS            RESTARTS  AGE
etcd-operator-6f44498865-lv7b9    1/1       Running           0         1h
example-etcd-cluster-fff78tmpxr   1/1       Running           0         1h
example-etcd-cluster-lrlk7xwb2k   1/1       Running           0         1h
example-etcd-cluster-r6cb8g2qqw   0/1       PodInitializing   0         4s  

Der Ersatz-Pods befindet sich im PodInitializing Zustand.

Die etcd-API bleibt für Clients verfügbar, während der Operator den etcd-Cluster repariert. In Kapitel 2 wirst du den etcd Operator einsetzen und ihn auf Herz und Nieren prüfen, während du die etcd-API zum Lesen und Schreiben von Daten nutzt. Bis dahin solltest du dich daran erinnern, dass das Hinzufügen eines Mitglieds zu einem laufenden etcd-Cluster nicht so einfach ist wie das Ausführen eines neuen etcd-Pods. Der etcd Operator verbirgt diese Komplexität und heilt den etcd-Cluster automatisch.

Für wen sind Operatoren?

Das Operator-Muster entstand als Reaktion auf den Wunsch von Infrastrukturingenieuren und Entwicklern, Kubernetes um Funktionen zu erweitern, die speziell auf ihre Standorte und Software zugeschnitten sind. Operatoren erleichtern es Cluster-Administratoren und Entwicklern, grundlegende Softwarekomponenten wie Datenbanken und Speicherungen mit weniger Verwaltungsaufwand zu nutzen. Wenn der "killernewdb"-Datenbankserver, der perfekt für das Backend deiner Anwendung geeignet ist, von einem Operator verwaltet wird, kannst du killernewdb einsetzen, ohne ein erfahrener killernewdb-DBA zu werden.

Anwendungsentwickler erstellen Operatoren, um die Anwendungen zu verwalten, die sie bereitstellen, und vereinfachen so die Bereitstellung und Verwaltung in den Kubernetes-Clustern ihrer Kunden. Infrastrukturingenieure erstellen Operatoren, um die bereitgestellten Dienste und Systeme zu kontrollieren.

Operator Adoption

Eine Vielzahl von Entwicklern und Unternehmen hat sich das Operator-Muster zu eigen gemacht, und es gibt bereits viele Operatoren, die es einfacher machen, wichtige Dienste als Komponenten deiner Anwendungen zu nutzen. CrunchyData hat einen Operator entwickelt, der PostgreSQL-Datenbankcluster verwaltet. Es gibt beliebte Operatoren für MongoDB und Redis. Rook verwaltet Ceph-Speicherung auf Kubernetes-Clustern, während andere Operatoren die Verwaltung externer Speicherdienste wie Amazon S3 im Cluster ermöglichen.

Darüber hinaus nutzen Kubernetes-basierte Distributionen wie OpenShift von Red Hat Operators, um Funktionen auf dem Kubernetes-Kern aufzubauen und so zum Beispiel die OpenShift-Webkonsole verfügbar und aktuell zu halten. Auf der Benutzerseite hat OpenShift Mechanismen für die Point-and-Click-Installation von Operatoren und deren Verwendung in der Webkonsole sowie für Operator-Entwickler zur Einbindung in OperatorHub.io eingeführt, die in Kapitel 8 und Kapitel 10 beschrieben werden.

Los geht's!

Betreiber brauchen einen Kubernetes-Cluster, auf dem sie laufen können. Im nächsten Kapitel zeigen wir dir verschiedene Möglichkeiten, wie du Zugang zu einem Cluster bekommst, sei es ein lokales virtuelles Kubernetes auf deinem Laptop, eine komplette Installation auf einer bestimmten Anzahl von Knoten oder ein externer Dienst. Sobald du Admin-Zugang zu einem Kubernetes-Cluster hast, wirst du den etcd Operator einsetzen und sehen, wie er einen etcd-Cluster in deinem Namen verwaltet.