Das Problem mit zustandsbehafteten Anwendungen in Kubernetes
Konfiguration, Start und weitere Skalierung von Anwendungen und Diensten sind in Fällen, die als zustandslos, d. h. zustandslos, eingestuft sind, einfach. ohne Daten zu speichern. Es ist bequem, solche Dienste in Kubernetes über die Standard-APIs auszuführen, da alles „out of the box“ geschieht: gemäß Standardkonfigurationen, ohne dass irgendwelche Besonderheiten oder Magie erforderlich sind.
Einfach ausgedrückt: Um fünf weitere Kopien des Backends in PHP/Ruby/Python in einem Cluster von Containern zu starten, müssen Sie nur fünf Mal einen neuen Server einrichten und die Quellen kopieren. Da sich sowohl der Quellcode als auch das Init-Skript im Image befinden, wird die Skalierung einer zustandslosen Anwendung völlig elementar. Wie Fans von Containern und Microservice-Architekturen wissen, beginnt die Schwierigkeit mit Zustandsbehaftete Apps, d.h. mit Datenpersistenz wie Datenbanken und Caches (MySQL, PostgreSQL, Redis, ElasticSearch, Cassandra...). Dies gilt sowohl für Software, die unabhängig einen Quorum-Cluster implementiert (z. B. Percona XtraDB und Cassandra), als auch für Software, die separate Verwaltungsdienstprogramme erfordert (z. B. Redis, MySQL, PostgreSQL usw.).
Es treten Schwierigkeiten auf, weil der Quellcode und das Starten des Dienstes nicht mehr ausreichen – Sie müssen einige weitere Schritte ausführen. Kopieren Sie zumindest die Daten und/oder treten Sie dem Cluster bei. Genauer gesagt erfordern diese Dienste ein Verständnis dafür, wie sie ohne Datenverlust oder vorübergehende Nichtverfügbarkeit richtig skaliert, aktualisiert und neu konfiguriert werden können. Die Berücksichtigung dieser Bedürfnisse wird als „operatives Wissen“ bezeichnet.
CoreOS-Operatoren
Um betriebliches Wissen zu „programmieren“, wurde Ende letzten Jahres das CoreOS-Projekt gestartet „eine neue Klasse von Software“ für die Kubernetes-Plattform – Operators (vom englischen „operation“, d. h. „Operation“).
Betreiber, die die Kernfunktionen von Kubernetes nutzen und erweitern (inkl. StatefulSets, siehe den Unterschied unten) ermöglichen es DevOps-Spezialisten, dem Anwendungscode operatives Wissen hinzuzufügen.
Zweck des Betreibers – Stellen Sie dem Benutzer eine API zur Verfügung, mit der Sie mehrere zustandsbehaftete Anwendungsentitäten in einem Kubernetes-Cluster verwalten können, ohne darüber nachdenken zu müssen, was sich unter der Haube befindet (welche Daten und was damit zu tun ist, welche Befehle noch ausgeführt werden müssen, um den Cluster aufrechtzuerhalten). ). Tatsächlich ist der Operator darauf ausgelegt, die Arbeit mit der Anwendung innerhalb des Clusters so weit wie möglich zu vereinfachen und die Ausführung von Betriebsaufgaben zu automatisieren, die zuvor manuell gelöst werden mussten.
Wie Operatoren arbeiten
Replikationssets Mit Kubernetes können Sie die gewünschte Anzahl laufender Pods angeben, und Controller stellen sicher, dass ihre Anzahl beibehalten wird (durch Erstellen und Löschen von Pods). Ein Operator funktioniert auf ähnliche Weise und fügt einer Standard-Kubernetes-Ressource und einem Kubernetes-Controller eine Reihe von Betriebskenntnissen hinzu, die es Ihnen ermöglichen, zusätzliche Aktionen durchzuführen, um die erforderliche Anzahl von Anwendungsentitäten zu unterstützen.
Wie unterscheidet sich das von StatefulSets, konzipiert für Anwendungen, die den Cluster benötigen, um ihnen zustandsbehaftete Ressourcen wie Datenspeicher oder statische IPs zur Verfügung zu stellen? Für solche Anwendungen können Betreiber verwenden StatefulSets (Anstelle von Replikationssets) als Grundlage, Angebot zusätzliche Automatisierung: Führen Sie bei Abstürzen die erforderlichen Aktionen aus, erstellen Sie Backups, aktualisieren Sie die Konfiguration usw.
somit Wie funktioniert das alles? Der Operator ist ein Manager-Daemon, der:
- abonniert die Event-API in Kubernetes;
- erhält von ihm Daten über das System (über seine Replikationssets, Schoten, Leistungen usw.);
- erhält Daten über Ressourcen von Drittanbietern (siehe Beispiele unten);
- reagiert auf Aussehen/Veränderung Ressourcen von Drittanbietern (z. B. um die Größe zu ändern, die Version zu ändern usw.);
- reagiert auf Änderungen im Zustand des Systems (über seine Replikationssets, Schoten, Leistungen usw.);
- das Wichtigste:
- ruft die Kubernetes-API auf, um alles zu erstellen, was es benötigt (wiederum sein eigenes). Replikationssets, Schoten, Leistungen…),
- führt etwas Magie aus (der Einfachheit halber können Sie sich vorstellen, dass der Operator in die Pods selbst geht und Befehle aufruft, um beispielsweise einem Cluster beizutreten oder das Datenformat zu aktualisieren, wenn eine Version aktualisiert wird).
Tatsächlich wird, wie auf dem Bild zu sehen ist, einfach eine separate Anwendung zu Kubernetes hinzugefügt (eine reguläre). Einsatz с Replikat-Set), der als Operator bezeichnet wird. Es lebt in einer gewöhnlichen Schote (normalerweise nur einer) und ist in der Regel nur für seine eigene verantwortlich Namespace. Diese Betreiberanwendung implementiert ihre API – allerdings nicht direkt, sondern über Ressourcen von Drittanbietern in Kubernetes.
Also, nachdem wir erstellt haben Namespace Betreiber, wir können etwas hinzufügen Ressourcen von Drittanbietern.
Beispiel für etcd (Einzelheiten siehe unten):
apiVersion: etcd.coreos.com/v1beta1
kind: Cluster
metadata:
name: example-etcd-cluster
spec:
size: 3
version: 3.1.0
Beispiel für Elasticsearch:
apiVersion: enterprises.upmc.com/v1
kind: ElasticsearchCluster
metadata:
name: example-es-cluster
spec:
client-node-replicas: 3
master-node-replicas: 2
data-node-replicas: 3
zones:
- us-east-1c
- us-east-1d
- us-east-1e
data-volume-size: 10Gi
java-options: "-Xms1024m -Xmx1024m"
snapshot:
scheduler-enabled: true
bucket-name: elasticsnapshots99
cron-schedule: "@every 2m"
storage:
type: gp2
storage-class-provisioner: kubernetes.io/aws-ebs
Anforderungen an Betreiber
CoreOS hat die Hauptmuster formuliert, die Ingenieure bei der Arbeit an Operatoren erhalten haben. Trotz der Tatsache, dass alle Operatoren individuell sind (für eine bestimmte Anwendung mit eigenen Merkmalen und Bedürfnissen erstellt), muss ihre Erstellung auf einer Art Rahmen basieren, der die folgenden Anforderungen stellt:
- Die Installation muss über eine Single erfolgen Einsatz: kubectl create -f SOME_OPERATOR_URL/deployment.yaml - und erfordern keine zusätzlichen Maßnahmen.
- Bei der Installation eines Operators in Kubernetes muss ein neuer Drittanbietertyp erstellt werden (ThirdPartyResource). Um Anwendungsinstanzen (Clusterinstanzen) zu starten und sie weiter zu verwalten (Versionen aktualisieren, Größenänderung usw.), verwendet der Benutzer diesen Typ.
- Wann immer möglich, sollten Sie die in Kubernetes integrierten Grundelemente verwenden, z Leistungen и Replikationssetsgut getesteten und verständlichen Code zu verwenden.
- Erfordert Abwärtskompatibilität der Operatoren und Unterstützung für ältere Versionen von vom Benutzer erstellten Ressourcen.
- Wenn der Operator entfernt wird, sollte die Anwendung selbst ohne Änderungen weiterhin funktionieren.
- Benutzer sollten in der Lage sein, die gewünschte Anwendungsversion zu definieren und Aktualisierungen der Anwendungsversion zu orchestrieren. Fehlende Software-Updates sind eine häufige Ursache für Betriebs- und Sicherheitsprobleme, daher müssen Betreiber die Benutzer in dieser Angelegenheit unterstützen.
- Betreiber sollten mit einem Tool wie Chaos Monkey getestet werden, das potenzielle Fehler in Pods, Konfigurationen und dem Netzwerk identifiziert.
etcd-Operator
Beispiel für die Implementierung eines Operators - etcd-Betreiber, am Tag der Bekanntgabe dieses Konzepts. Die Konfiguration des etcd-Clusters kann komplex sein, da das Quorum aufrechterhalten werden muss, die Clustermitgliedschaft neu konfiguriert werden muss, Sicherungen erstellt werden müssen usw. Wenn Sie beispielsweise einen etcd-Cluster manuell skalieren, müssen Sie einen DNS-Namen für ein neues Clustermitglied erstellen, eine neue etcd-Entität starten und den Cluster über das neue Mitglied benachrichtigen (etcdctl-Mitglied hinzufügen). Im Falle des Operators muss der Benutzer nur die Clustergröße ändern – alles andere geschieht automatisch.
Und da etcd auch in CoreOS erstellt wurde, war es ganz logisch, dass sein Operator zuerst auftauchte. Wie funktioniert er? Operatorlogik usw wird durch drei Komponenten bestimmt:
- Beobachten. Der Operator überwacht den Status des Clusters mithilfe der Kubernetes-API.
- Analyse. Findet Unterschiede zwischen dem aktuellen Status und dem gewünschten (definiert durch die Benutzerkonfiguration).
- Aktion. Behebt erkannte Unterschiede mithilfe der etcd- und/oder Kubernetes-Dienst-APIs.
Um diese Logik zu implementieren, wurden im Operator Funktionen vorbereitet Erstellen/Zerstören (Erstellen und Löschen von etcd-Clustermitgliedern) und Resize (Änderung der Anzahl der Clustermitglieder). Die korrekte Funktionsweise wurde mit einem Dienstprogramm überprüft, das dem Chaos Monkey von Netflix nachempfunden ist, d. h. etcd-Pods nach dem Zufallsprinzip töten.
Für den vollständigen Betrieb von etcd stellt der Operator zusätzliche Funktionen zur Verfügung: Sicherungskopie (automatische und für Benutzer unsichtbare Erstellung von Sicherungskopien – in der Konfiguration reicht es aus, festzulegen, wie oft sie erstellt und wie viele gespeichert werden sollen – und anschließende Wiederherstellung der Daten daraus) und Upgrade (Aktualisierung von etcd-Installationen ohne Ausfallzeit).
Wie sieht die Zusammenarbeit mit einem Operator aus?
$ kubectl create -f https://coreos.com/operators/etcd/latest/deployment.yaml
$ kubectl create -f https://coreos.com/operators/etcd/latest/example-etcd-cluster.yaml
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
etcd-cluster-0000 1/1 Running 0 23s
etcd-cluster-0001 1/1 Running 0 16s
etcd-cluster-0002 1/1 Running 0 8s
etcd-cluster-backup-tool-rhygq 1/1 Running 0 18s
Der aktuelle Status von etcd Operator ist eine Beta-Version, für deren Ausführung Kubernetes 1.5.3+ und etcd 3.0+ erforderlich sind. Quellcode und Dokumentation (einschließlich Gebrauchsanweisung) sind verfügbar unter .
Eine weitere Beispielimplementierung von CoreOS wurde erstellt - , aber es befindet sich noch in der Alpha-Version (nicht alle geplanten Funktionen wurden implementiert).
Status und Perspektiven
Seit der Ankündigung der Kubernetes-Operatoren sind 5 Monate vergangen. Im offiziellen CoreOS-Repository sind immer noch nur zwei Implementierungen verfügbar (für etcd und Prometheus). Beide haben ihre stabile Version noch nicht erreicht, Commits werden jedoch täglich beobachtet.
Die Entwickler stellen sich „eine Zukunft vor, in der Benutzer Postgres-Operatoren, Cassandra-Operatoren oder Redis-Operatoren auf ihren Kubernetes-Clustern installieren und mit den skalierbaren Einheiten dieser Anwendungen so einfach arbeiten, wie es heute die Bereitstellung von Replikaten zustandsloser Webanwendungen ist.“ Erste Betreiber von Drittentwicklern begann wirklich zu erscheinen:
- von UPMC Enterprises;
- von Crunchy Data (angekündigt Ende März 2017);
- von den Autoren eines verteilten Datenspeichersystems auf Basis von Ceph (Rook befindet sich im Alpha-Status);
- von SAP CCloud.
Auf der größten europäischen Freie-Software-Konferenz FOSDEM, die im Februar 2017 in Brüssel stattfand, kündigte Josh Wood von CoreOS Operators in an (Ein Video ist unter dem Link verfügbar!), was zur wachsenden Popularität dieses Konzepts in der breiteren Open-Source-Community beitragen dürfte.
PS Vielen Dank für Ihr Interesse an dem Artikel! Abonnieren Sie unseren Hub, um neue Materialien und Rezepte zur DevOps- und GNU/Linux-Systemadministration nicht zu verpassen – wir werden sie regelmäßig veröffentlichen!
Source: habr.com