Der Bericht widmet sich den praktischen Fragen der Entwicklung eines Operators in Kubernetes, dem Entwurf seiner Architektur und den Grundprinzipien des Betriebs.
Im ersten Teil des Berichts werden wir Folgendes betrachten:
- Was ist ein Operator in Kubernetes und warum wird er benötigt?
- wie genau der Betreiber die Verwaltung komplexer Systeme vereinfacht;
- was der Bediener kann und was nicht.
Kommen wir als Nächstes zur Diskussion der internen Struktur des Operators. Betrachten Sie die Architektur und den Betrieb des Operators Schritt für Schritt. Lassen Sie uns im Detail analysieren:
- Interaktion zwischen dem Betreiber und Kubernetes;
- welche Funktionen der Operator übernimmt und welche an Kubernetes delegiert.
Erwägen Sie die Verwaltung von Shards und Datenbankreplikaten in Kubernetes.
Als nächstes werden wir Fragen zur Datenspeicherung besprechen:
- wie man mit Persistent Storage aus Sicht eines Betreibers arbeitet;
- Fallstricke bei der Verwendung von Local Storage.
Im letzten Teil des Berichts gehen wir auf praktische Anwendungsbeispiele ein mit Amazon oder Google Cloud Service. Der Bericht basiert am Beispiel der Entwicklungs- und Betriebserfahrungen des Betreibers für ClickHouse.
Video:
Mein Name ist Vladislav Klimenko. Heute wollte ich über unsere Erfahrungen bei der Entwicklung und dem Betrieb eines Operators sprechen, und zwar eines spezialisierten Operators für die Verwaltung von Datenbankclustern. Zum Beispiel um den ClickHouse-Cluster zu verwalten.
Warum haben wir die Möglichkeit, über den Betreiber und ClickHouse zu sprechen?
- Wir unterstützen und entwickeln ClickHouse.
- Im Moment versuchen wir, langsam unseren Beitrag zur Entwicklung von ClickHouse zu leisten. Und was die Anzahl der in ClickHouse vorgenommenen Änderungen angeht, sind wir nach Yandex der zweitgrößte Anbieter.
- Wir versuchen, zusätzliche Projekte für das ClickHouse-Ökosystem zu realisieren.
Ich möchte über eines dieser Projekte sprechen. Hier geht es um den ClickHouse-Operator für Kubernetes.
In meinem Bericht möchte ich zwei Themen ansprechen:
- Das erste Thema ist die Funktionsweise unseres ClickHouse-Datenbankoperators in Kubernetes.
- Das zweite Thema ist die Funktionsweise eines Operators, d. h. wie er mit Kubernetes interagiert.
Allerdings werden sich diese beiden Fragen in meinem gesamten Bericht überschneiden.
Wer würde daran interessiert sein, zu hören, was ich zu sagen versuche?
- Am interessantesten werden diejenigen sein, die die Betreiber ausnutzen.
- Oder für diejenigen, die es selbst erstellen möchten, um zu verstehen, wie es im Inneren funktioniert, wie der Betreiber mit Kubernetes interagiert und welche Fallstricke auftreten können.
Um am besten zu verstehen, worüber wir heute sprechen werden, wäre es schön zu wissen, wie Kubernetes funktioniert, und über grundlegende Kenntnisse im Cloud Computing zu verfügen.
Was ist ClickHouse? Hierbei handelt es sich um eine Spaltendatenbank mit Besonderheiten bei der Online-Verarbeitung analytischer Abfragen. Und es ist vollständig Open Source.
Und wir müssen nur zwei Dinge wissen. Sie müssen wissen, dass es sich um eine Datenbank handelt. Das, was ich Ihnen sage, gilt also für fast jede Datenbank. Und die Tatsache, dass das ClickHouse-DBMS sehr gut skaliert, sorgt für eine nahezu lineare Skalierbarkeit. Und daher ist der Zustand des Clusters für ClickHouse ein natürlicher Zustand. Am meisten interessiert uns die Diskussion darüber, wie ein ClickHouse-Cluster in Kubernetes bereitgestellt werden kann.
Warum wird er dort gebraucht? Warum können wir es nicht weiter selbst betreiben? Und die Antworten sind teils technischer, teils organisatorischer Natur.
- In der Praxis kommt es immer häufiger vor, dass sich in großen Unternehmen fast alle Komponenten bereits in Kubernetes befinden. Datenbanken bleiben draußen.
- Und immer häufiger wird die Frage gestellt: „Kann man das drinnen platzieren?“ Daher versuchen große Unternehmen, die Verwaltung so weit wie möglich zu vereinheitlichen, um ihre Data Warehouses schnell verwalten zu können.
- Und das ist besonders hilfreich, wenn Sie die maximale Möglichkeit benötigen, dasselbe an einem neuen Ort zu wiederholen, also maximale Portabilität.
Wie einfach oder schwierig ist es? Dies kann natürlich auch von Hand erfolgen. Dies ist jedoch nicht so einfach, da wir die Komplexität der Verwaltung von Kubernetes selbst addieren, gleichzeitig aber auch die Besonderheiten von ClickHouse auferlegen. Und es stellt sich eine solche Aggregation heraus.
Und alles in allem ergibt dies einen ziemlich großen Satz an Technologien, der schon jetzt ziemlich schwierig zu verwalten ist, da Kubernetes seine alltäglichen Probleme in den Betrieb bringt und ClickHouse seine Probleme in den alltäglichen Betrieb bringt. Vor allem, wenn wir mehrere ClickHouses haben und ständig etwas damit machen müssen.
ClickHouse mit einer dynamischen Konfiguration weist eine ziemlich große Anzahl von Problemen auf, die eine ständige Belastung für DevOps darstellen:
- Wenn wir etwas in ClickHouse ändern möchten, zum Beispiel ein Replikat oder einen Shard hinzufügen möchten, müssen wir die Konfiguration verwalten.
- Ändern Sie dann das Datenschema, da ClickHouse über eine bestimmte Sharding-Methode verfügt. Dort ist es notwendig, das Datenschema und die Konfigurationen festzulegen.
- Sie müssen eine Überwachung einrichten.
- Sammlung von Protokollen für neue Shards und neue Replikate.
- Sorgen Sie für die Genesung.
- Und neu starten.
Das sind solche Routinearbeiten, die ich im Betrieb sehr gerne erleichtern möchte.
Kubernetes selbst hilft sehr im Betrieb, aber bei grundlegenden Systemdingen.
Kubernetes ist großartig darin, Dinge zu erleichtern und zu automatisieren wie:
- Erholung.
- Neu starten.
- Speicherverwaltung.
Das ist gut, das ist die richtige Richtung, aber er hat überhaupt keinen Bezug dazu, wie man einen Datenbankcluster betreibt.
Ich möchte mehr, ich möchte, dass die gesamte Datenbank in Kubernetes für uns funktioniert.
Ich hätte gerne so etwas wie einen großen magischen roten Knopf, den man drückt und der einen Cluster mit alltäglichen Aufgaben, die gelöst werden müssen, über den gesamten Lebenszyklus verteilt und verwaltet hat. ClickHouse-Cluster in Kubernetes.
Und wir haben versucht, eine Lösung zu finden, die die Arbeit erleichtert. Dies ist der ClickHouse-Operator für Kubernetes von Altinity.
Ein Operator ist ein Programm, dessen Hauptaufgabe darin besteht, andere Programme zu verwalten, also ein Manager.
Und es enthält Verhaltensmuster. Man kann es kodifiziertes Wissen über das Fachgebiet nennen.
Und seine Hauptaufgabe besteht darin, DevOps das Leben zu erleichtern und das Mikromanagement zu reduzieren, sodass er (DevOps) bereits auf hoher Ebene denkt, das heißt, dass er (DevOps) kein Mikromanagement betreibt und nicht alles manuell konfiguriert Einzelheiten.
Und nur der Bediener ist ein Roboterassistent, der sich mit Mikroaufgaben herumschlägt und DevOps hilft.
Warum wird ein Operator benötigt? Er zeichnet sich in zwei Bereichen aus:
- Wenn ein ClickHouse-Spezialist nicht über genügend Erfahrung verfügt, die Bedienung von ClickHouse jedoch bereits erforderlich ist, erleichtert der Bediener die Bedienung und ermöglicht Ihnen die Bedienung eines ClickHouse-Clusters mit einer recht komplexen Konfiguration, ohne dabei zu sehr ins Detail zu gehen, wie alles im Inneren funktioniert . Sie geben ihm einfach hochrangige Aufgaben und es funktioniert.
- Und die zweite Aufgabe, bei der es am besten zur Geltung kommt, ist die Automatisierung einer großen Anzahl typischer Aufgaben. Entfernt Mikrotasks von Systemadministratoren.
Dies wird am meisten von denjenigen benötigt, die gerade erst mit ihrer Reise beginnen, oder von denen, die viel Automatisierung durchführen müssen.
Was ist der Unterschied zwischen dem betreiberbasierten Ansatz und anderen Systemen? Es gibt auch Helm. Es hilft auch, ClickHouse zu installieren. Sie können Steuerdiagramme zeichnen, mit denen sogar ein ganzer ClickHouse-Cluster installiert wird. Was ist dann der Unterschied zwischen dem Operator und demselben, beispielsweise Helm?
Der wesentliche grundlegende Unterschied besteht darin, dass es bei Helm ausschließlich um die Paketverwaltung geht und der Operator noch einen Schritt weiter geht. Dies ist die Unterstützung des gesamten Lebenszyklus. Dabei handelt es sich nicht nur um die Installation, sondern um alltägliche Aufgaben, zu denen Skalierung und Sharding gehören, also alles, was während des Lebenszyklus erledigt werden muss (ggf. auch die Entfernung) – das alles entscheidet der Betreiber. Es versucht, den gesamten Software-Lebenszyklus zu automatisieren und zu bedienen. Dies ist der grundlegende Unterschied zu anderen vorgestellten Lösungen.
Das war der Einführungsteil, lasst uns weitermachen.
Wie bauen wir unseren Betreiber auf? Wir versuchen, das Problem anzugehen, um den ClickHouse-Cluster als eine einzige Ressource zu verwalten.
Hier haben wir die Eingabedaten auf der linken Seite des Bildes. Dabei handelt es sich um YAML mit einer Cluster-Spezifikation, die klassisch über kubectl an Kubernetes übergeben wird. Dort holt unser Operator es ab und zaubert. Und als Ergebnis erhalten wir ein solches Schema. Dies ist die Implementierung von ClickHouse in Kubernetes.
Und dann schauen wir uns langsam an, wie der Operator arbeitet, welche typischen Aufgaben gelöst werden können. Wir werden nur typische Aufgaben berücksichtigen, da wir nur über begrenzte Zeit verfügen. Und es wird nicht alles erzählt, worüber der Betreiber entscheiden kann.
Beginnen wir mit der Praxis. Unser Projekt ist vollständig Open Source, sodass Sie auf GitHub sehen können, wie es funktioniert. Und Sie können von den Überlegungen ausgehen, wenn Sie einfach nur anfangen möchten, dann können Sie mit der Kurzanleitung beginnen.
Wenn Sie es im Detail verstehen wollen, dann versuchen wir, die Dokumentation in einer mehr oder weniger anständigen Form zu halten.
Beginnen wir mit einem praktischen Problem. Die erste Aufgabe, mit der wir alle beginnen möchten, besteht darin, das erste Beispiel irgendwie auszuführen. Wie kann man ClickHouse mithilfe eines Operators starten, ohne überhaupt zu wissen, wie es funktioniert? Wir schreiben ein Manifest, weil Die gesamte Kommunikation mit K8s erfolgt über Manifeste.
Hier ist so ein komplexes Manifest. Was wir rot hervorgehoben haben, ist das, worauf wir uns konzentrieren müssen. Wir bitten den Betreiber, einen Cluster mit dem Namen Demo zu erstellen.
Im Moment sind dies grundlegende Beispiele. Die Lagerung wurde noch nicht beschrieben, aber wir werden etwas später auf die Lagerung zurückkommen. Zunächst werden wir die dynamische Entwicklung des Clusters beobachten.
Wir haben dieses Manifest erstellt. Wir geben es an unseren Betreiber weiter. Er arbeitete, er zauberte.
Wir schauen uns die Konsole an. Drei Komponenten sind von Interesse: Pod, zwei Service-a und StatefulSet.
Der Operator hat gearbeitet und wir können sehen, was genau er erstellt hat.
Er erschafft so etwas. Wir haben ein StatefulSet, einen Pod, eine ConfigMap für jedes Replikat und eine ConfigMap für den gesamten Cluster. Notwendigerweise Dienste als Einstiegspunkte zum Cluster.
Services sind der zentrale Load Balancer Service und sind für jedes Replikat, für jeden Shard möglich.
Hier ist unser Basiscluster, der ungefähr so aussieht. Er stammt von einem einzigen Knoten.
Gehen wir weiter, wir machen es komplizierter. Sie müssen den Cluster teilen.
Unsere Aufgaben wachsen, die Dynamik beginnt. Wir möchten einen Shard hinzufügen. Wir verfolgen die Entwicklung. Wir ändern unsere Spezifikation. Wir geben an, dass wir zwei Shards wollen.
Dabei handelt es sich um dieselbe Datei, die wir mit dem Wachstum des Systems dynamisch weiterentwickeln. Es gibt keinen Speicher, der Speicher wird weiter besprochen, dies ist ein separates Thema.
Wir füttern den YAML-Operator und sehen, was passiert.
Der Betreiber hat sich die folgenden Entitäten ausgedacht und erstellt. Wir haben bereits zwei Pods, drei Services und plötzlich zwei StatefulSets. Warum 2 StatefulSets?
Auf dem Diagramm sah es so aus – das ist unser Ausgangszustand, als wir eine Kapsel hatten.
Es wurde so. Bisher ist alles einfach, es wurde dupliziert.
Und warum wurden aus dem StatefulSet zwei? Hier müssen wir abschweifen und die Frage diskutieren, wie Pods in Kubernetes verwaltet werden.
Es gibt ein solches Objekt namens StatefulSet, mit dem Sie aus einer Vorlage eine Reihe von Pods erstellen können. Der entscheidende Faktor hierbei ist die Vorlage. Und Sie können viele Pods in einem StatefulSet gemäß einer Vorlage ausführen. Und der Schlüsselbegriff hier ist „eine Vorlage, viele Pods“.
Und die Versuchung war groß, den gesamten Cluster zu erstellen und ihn in ein einziges StatefulSet zu packen. Es wird funktionieren, es gibt kein Problem. Aber es gibt eine Einschränkung. Wenn wir einen heterogenen Cluster zusammenstellen wollen, also aus mehreren Versionen von ClickHouse, dann beginnen unsere Fragen. Ja, StatefulSet kann ein rollierendes Update durchführen, aber dort können Sie eine neue Version einführen und erklären, dass Sie nicht mehr als so viele Knoten gleichzeitig ausprobieren müssen.
Aber wenn wir die Aufgabe extrapolieren und sagen, dass wir einen völlig heterogenen Cluster erstellen wollen und nicht mit einem Rolling Update von der alten Version auf eine neue wechseln wollen, sondern einfach einen heterogenen Cluster sowohl im Hinblick auf unterschiedliche Versionen erstellen wollen von ClickHouse und in Bezug auf verschiedene Speichermöglichkeiten. Wir möchten beispielsweise einige Replikate auf separaten Festplatten erstellen, im Allgemeinen auf langsamen, um einen vollständig heterogenen Cluster aufzubauen. Und aufgrund der Tatsache, dass StatefulSet eine standardisierte Lösung aus einer Vorlage erstellt, gibt es keine Möglichkeit, dies zu tun.
Nach einigem Überlegen wurde beschlossen, dass uns das gefällt. Wir haben jedes Replikat in einem eigenen StatefulSet. Diese Lösung weist einige Nachteile auf, aber in der Praxis kapselt sie den Bediener vollständig ein. Und es gibt viele Vorteile. Wir können einen ganz solchen Cluster aufbauen, wie wir wollen, zum Beispiel einen absolut heterogenen. Daher werden wir in einem Cluster, in dem wir zwei Shards mit einem Replikat haben, 2 StatefulSets und 2 Pods haben, gerade weil wir diesen Ansatz aus den oben genannten Gründen für die Fähigkeit zum Aufbau eines heterogenen Clusters gewählt haben.
Kehren wir zu den praktischen Aufgaben zurück. In unserem Cluster müssen wir Benutzer konfigurieren, d.h. Sie müssen ClickHouse in Kubernetes konfigurieren. Der Betreiber stellt hierfür alle Möglichkeiten zur Verfügung.
Wir können direkt in YAML schreiben, was wir wollen. Alle Konfigurationsoptionen werden direkt von dieser YAML in ClickHouse-Konfigurationen abgebildet, die dann im gesamten Cluster bereitgestellt werden.
Sie können auch so schreiben. Dies ist ein Beispiel. Das Passwort kann verschlüsselt werden. Absolut alle ClickHouse-Konfigurationsoptionen werden unterstützt. Hier ist nur ein Beispiel.
Die Clusterkonfiguration wird als ConfigMap verteilt. In der Praxis erfolgt die ConfigMap-Aktualisierung nicht sofort. Wenn also ein großer Cluster vorhanden ist, dauert das Pushen der Konfiguration einige Zeit. Aber das alles ist sehr bequem zu bedienen.
Wir erschweren die Aufgabe. Der Cluster entwickelt sich. Wir wollen Daten replizieren. Das heißt, wir haben bereits zwei Shards, jeweils ein Replikat, und die Benutzer sind konfiguriert. Wir wachsen und wollen uns vervielfältigen.
Was brauchen wir für die Replikation?
Wir brauchen ZooKeeper. In ClickHouse wird die Replikation mit ZooKeeper erstellt. ZooKeeper wird benötigt, damit verschiedene ClickHouse-Replikate einen Konsens darüber haben, welche Datenblöcke sich auf welchem ClickHouse befinden.
ZooKeeper kann von jedem genutzt werden. Wenn ein Unternehmen über einen externen ZooKeeper verfügt, kann dieser verwendet werden. Wenn nicht, können Sie die Installation aus unserem Repository durchführen. Es gibt einen Installer, der das Ganze einfacher macht.
Und das Interaktionsschema des gesamten Systems sieht so aus. Wir haben Kubernetes als Plattform. Es führt die ClickHouse-Anweisung aus. ZooKeeper, den ich hier abgebildet habe. Und der Betreiber interagiert sowohl mit ClickHouse als auch mit ZooKeeper. Das heißt, es entsteht eine Interaktion.
Und all dies ist notwendig, damit ClickHouse Daten erfolgreich auf k8s replizieren kann.
Schauen wir uns nun die Aufgabe selbst an, wie das Manifest für die Replikation aussehen wird.
Wir fügen unserem Manifest zwei Abschnitte hinzu. Der erste ist, wo man ZooKeeper erhält, der entweder innerhalb von Kubernetes oder extern sein kann. Dies ist nur eine Beschreibung. Und wir bestellen Repliken. Diese. Wir wollen zwei Replikate. Insgesamt sollten wir am Ausgang 4 Pods haben. Wir erinnern uns an die Lagerung, es wird etwas weiter zurückkommen. Lagerung ist ein separates Lied.
Es war so.
Es wird so. Repliken werden hinzugefügt. Der vierte passte nicht, wir glauben, dass es viele davon geben könnte. Und ZooKeeper wird an der Seite hinzugefügt. Die Muster werden komplexer.
Und es ist Zeit, die nächste Aufgabe hinzuzufügen. Wir werden persistenten Speicher hinzufügen.
Für den persistenten Speicher haben wir eine Vielzahl von Optionen.
Wenn wir einen Cloud-Anbieter nutzen, zum Beispiel Amazon oder Google, dann ist die Versuchung groß, Cloud-Speicher zu nutzen. Es ist sehr praktisch, es ist gut.
Und es gibt noch eine zweite Möglichkeit. Dies ist für die lokale Speicherung gedacht, wenn wir auf jedem Knoten lokale Festplatten haben. Diese Option ist deutlich schwieriger umzusetzen, aber gleichzeitig produktiver.
Mal sehen, was wir zum Thema Cloud-Speicher haben.
Es gibt Vorzüge. Es ist sehr einfach zu konfigurieren. Wir bestellen einfach bei einem Cloud-Anbieter, der uns bitte Speicher dieser und jener Kapazität, dieser und jener Klasse zur Verfügung stellt. Die Kurse werden von den Anbietern unabhängig voneinander gestaltet.
Und es gibt einen Nachteil. Für manche ist das ein unkritisches Manko. Natürlich wird es einige Leistungsüberlagerungen geben. Es ist sehr benutzerfreundlich und zuverlässig, es gibt jedoch einige potenzielle Leistungseinbußen.
Und da ClickHouse konzentriert sich auf Leistung, man kann sogar sagen, dass es alles Mögliche herausholt, weshalb viele Kunden versuchen, die maximale Leistung herauszuholen.
Und um das Beste daraus zu machen, brauchen wir lokalen Speicher.
Kubernetes bietet drei Abstraktionen für die Verwendung von lokalem Speicher in Kubernetes. Das:
- EmptyDir
- HostPath.
- Lokale
Überlegen Sie, wie sie sich unterscheiden und wie ähnlich sie sind.
Erstens verfügen wir bei allen drei Ansätzen über Speicher – das sind lokale Festplatten, die sich auf demselben physischen k8s-Knoten befinden. Aber sie haben einige Unterschiede.
Beginnen wir mit dem einfachsten, nämlich emptyDir. Was ist das in der Praxis? Wir sind es, die das Containerisierungssystem (meistens Docker) aus unserer Spezifikation bitten, uns Zugriff auf einen Ordner auf einer lokalen Festplatte zu gewähren.
In der Praxis erstellt der Docker irgendwo in seinen eigenen Pfaden einen temporären Ordner und nennt ihn einen langen Hash. Und stellt eine Schnittstelle für den Zugriff bereit.
Wie wird es in Bezug auf die Leistung abschneiden? Dies läuft mit der Geschwindigkeit der lokalen Festplatte, d. h. Dadurch haben Sie vollen Zugriff auf Ihre Schraube.
Aber dieser Fall hat seinen Nachteil. Persistent ist in diesem Fall eher zweifelhaft. Bei der ersten Bewegung des Dockers mit Containern geht Persistent verloren. Wenn Kubernetes diesen Pod aus irgendeinem Grund auf eine andere Festplatte verschieben möchte, gehen die Daten verloren.
Für Tests ist dieser Ansatz gut, da er bereits die normale Geschwindigkeit anzeigt, für etwas Ernstes ist diese Option jedoch nicht geeignet.
Daher gibt es einen zweiten Ansatz. Dies ist hostPath. Wenn Sie sich die vorherige und diese Folie ansehen, können Sie nur einen Unterschied erkennen. Unser Ordner hat den Docker direkt zum Kubernetes-Knoten verlassen. Hier geht es etwas schneller. Wir schreiben den Pfad direkt auf das lokale Dateisystem, wo wir unsere Daten speichern möchten.
Diese Methode hat Vorteile. Das ist schon ein echter Persistent, und zwar ein Klassiker. Auf unserer Festplatte werden Daten an eine bestimmte Adresse geschrieben.
Es gibt auch Nachteile. Darin besteht die Komplexität des Managements. Unser Kubernetes möchte den Pod möglicherweise auf einen anderen physischen Knoten verschieben. Hier kommt DevOps ins Spiel. Es muss dem gesamten System korrekt erklären, dass Sie diese Pods nur zu solchen Knoten verschieben können, auf denen Sie entlang dieser Pfade etwas gemountet haben, und nicht mehr als einen Knoten gleichzeitig. Es ist schwierig genug.
Speziell für diese Zwecke haben wir in unserem Operator Vorlagen erstellt, um all diese Komplexität zu verbergen. Und man könnte einfach sagen: „Ich möchte eine Instanz von ClickHouse pro physischem Knoten und auf diesem und jenem Pfad haben.“
Dieses Bedürfnis besteht jedoch nicht nur für uns, daher verstehen auch die Herren von Kubernetes selbst, dass Menschen Zugriff auf physische Festplatten haben möchten, und stellen daher eine dritte Ebene bereit.
Es heißt lokal. Es gibt praktisch keinen Unterschied zur vorherigen Folie. Früher war es nur notwendig, von Hand durchzuführen, dass wir diese Pods nicht von Knoten zu Knoten übertragen können, da sie über diesen oder jenen Pfad an die lokale physische Festplatte angeschlossen werden müssen, und jetzt ist all dieses Wissen in Kubernetes selbst gekapselt. Und es ist viel einfacher zu konfigurieren.
Kehren wir zu unserer praktischen Aufgabe zurück. Kommen wir zurück zur YAML-Vorlage. Hier haben wir einen echten Speicher. Da sind wir wieder da. Wir setzen die klassische VolumeClaim-Vorlage wie in k8s. Und wir beschreiben, welche Art von Speicher wir wünschen.
Danach fordert k8s Speicherplatz an. Ordnen Sie es uns im StatefulSet zu. Und am Ende wird es ClickHouse zur Verfügung stehen.
Wir hatten ein solches Schema. Unser Persistent Storage war rot, was anzudeuten schien, dass dies getan werden sollte.
Und es wird grün. Jetzt ist das ClickHouse-on-k8s-Clusterschema vollständig fertiggestellt. Wir haben Shards, Replikate, ZooKeeper, wir haben echtes Persistent, das auf die eine oder andere Weise implementiert wird. Das Schema ist bereits voll funktionsfähig.
Wir leben weiter. Unser Cluster wächst. Und Aleksey versucht es und veröffentlicht eine neue Version von ClickHouse.
Es stellt sich eine praktische Aufgabe – die neue Version von ClickHouse auf unserem Cluster zu testen. Und natürlich möchte ich nicht alles herausbringen, sondern eine neue Version irgendwo in der hinteren Ecke in einer Replik platzieren, oder vielleicht nicht eine neue Version, sondern zwei auf einmal, weil sie oft herauskommen.
Was können wir dazu sagen?
Hier haben wir genau eine solche Gelegenheit. Dies sind Pod-Vorlagen. Sie können malen, unser Operator ermöglicht Ihnen vollständig den Aufbau eines heterogenen Clusters. Diese. Konfigurieren Sie, beginnend mit allen Replikaten in einem Bündel und endend mit jeder persönlichen Replik, welche Version wir von ClickHouse wünschen und welche Version wir speichern möchten. Wir können den Cluster vollständig in einer Konfiguration konfigurieren, die wir benötigen.
Lass uns etwas tiefer ins Innere gehen. Zuvor haben wir darüber gesprochen, wie der ClickHouse-Operator in Bezug auf die Besonderheiten von ClickHouse funktioniert.
Nun möchte ich ein paar Worte dazu sagen, wie jeder Operator im Allgemeinen funktioniert und wie er mit K8s interagiert.
Erwägen Sie zunächst die Interaktion mit K8s. Was passiert, wenn wir kubectl anwenden? Über die API erscheinen unsere Objekte in etcd.
Beispielsweise die grundlegenden Kubernetes-Objekte: Pod, StatefulSet, Service usw. in der Liste.
Es passiert jedoch noch nichts Physisches. Diese Objekte müssen in einem Cluster materialisiert werden.
Hier kommt der Controller ins Spiel. Der Controller ist eine spezielle k8s-Komponente, die diese Beschreibungen verwirklichen kann. Er weiß, wie und was körperlich zu tun ist. Er weiß, wie man Container betreibt, was dort konfiguriert werden muss, damit der Server funktioniert.
Und es materialisiert unsere Objekte in K8s.
Aber wir wollen nicht nur mit Pods, StatefulSets, operieren, wir wollen eine ClickHouseInstallation, also ein Objekt vom Typ ClickHouse, erstellen, um damit als Ganzes zu operieren. Bisher gibt es keine solche Möglichkeit.
Aber K8s hat noch eine andere schöne Sache. Wir möchten, dass wir irgendwo eine so komplexe Einheit haben, in der unser Cluster aus Pods und StatefulSet zusammengesetzt wird.
Und was ist dafür zu tun? Zunächst betritt die benutzerdefinierte Ressourcendefinition die Szene. Was ist das? Dies ist eine Beschreibung für K8s, dass Sie einen weiteren Datentyp haben werden, den wir dem Pod hinzufügen möchten, StatefulSet, eine benutzerdefinierte Ressource, die im Inneren komplex sein wird. Dies ist eine Beschreibung der Datenstruktur.
Wir senden es auch per kubectl apply dorthin. Kubernetes nahm es gerne an.
Und jetzt hat das Objekt in etcd in unserem Speicher die Möglichkeit, eine benutzerdefinierte Ressource namens ClickHouseInstallation zu schreiben.
Aber vorerst wird nichts anderes passieren. Das heißt, wenn wir jetzt eine von uns betrachtete YAML-Datei mit einer Beschreibung des Shards und Replikaten erstellen und „kubectl apply“ sagen, dann akzeptiert Kubernetes sie, fügt sie in etcd ein und sagt: „Großartig, aber ich weiß es nicht.“ was man damit machen soll. Ich weiß nicht, wie ich ClickHouseInstallation warten soll.
Dementsprechend brauchen wir jemanden, der Kubernetes bei der Bereitstellung des neuen Datentyps unterstützt. Auf der linken Seite sehen wir einen standardmäßigen Kubernetes-Controller, der mit standardmäßigen Datentypen arbeitet. Und auf der rechten Seite sollten wir einen benutzerdefinierten Controller haben, der mit benutzerdefinierten Datentypen arbeiten kann.
Und auf andere Weise wird es als Operator bezeichnet. Ich habe es hier speziell für Kubernetes herausgenommen, da es auch außerhalb von K8s ausgeführt werden kann. Meistens werden natürlich alle Anweisungen in Kubernetes ausgeführt, aber nichts hindert sie daran, draußen zu bleiben, deshalb wird sie hier speziell hervorgehoben.
Und schon interagiert wiederum der benutzerdefinierte Controller, auch Operator genannt, über die API mit Kubernetes. Er weiß bereits, wie man mit der API interagiert. Und er weiß bereits, wie man ein komplexes Schema, das wir aus einer benutzerdefinierten Ressource erstellen möchten, verwirklichen kann. Genau das macht der Betreiber.
Wie funktioniert der Betreiber? Werfen wir einen Blick auf die rechte Seite, um zu sehen, wie er es macht. Wir werden herausfinden, wie der Betreiber all dies umsetzt und wie die weitere Interaktion mit K8s erfolgt.
Der Operator ist das Programm. Sie ist ereignisorientiert. Der Betreiber abonniert Ereignisse mithilfe der Kubernetes-API. Die Kubernetes-API verfügt über Einstiegspunkte, über die Sie Ereignisse abonnieren können. Und wenn sich in K8s etwas ändert, dann sendet Kubernetes Ereignisse an alle, d.h. Wer diesen API-Punkt abonniert hat, erhält Benachrichtigungen.
Der Operator abonniert Ereignisse und muss darauf reagieren. Seine Aufgabe besteht darin, auf sich abzeichnende Ereignisse zu reagieren.
Bei manchen Updates werden Ereignisse generiert. Unsere YAML-Datei kommt mit einer Beschreibung von ClickHouseInstallation. Er ging über kubectl apply zu etcd. Dort funktionierte eine Veranstaltung, dadurch kam diese Veranstaltung zum ClickHouse-Betreiber. Der Betreiber hat diese Beschreibung erhalten. Und er muss etwas tun. Wenn das ClickHouseInstallation-Objekt aktualisiert wurde, müssen Sie den Cluster aktualisieren. Und die Aufgabe des Betreibers besteht darin, den Cluster zu aktualisieren.
Was macht er? Zunächst müssen wir einen Aktionsplan für die Umsetzung dieses Updates erstellen. Aktualisierungen können sehr klein sein, d. h. klein in der YAML-Ausführung, kann aber zu sehr großen Änderungen im Cluster führen. Daher erstellt der Betreiber einen Plan und hält sich dann daran.
Nach diesem Plan beginnt er, diese Struktur im Inneren zum Kochen zu bringen, um Kapseln, Dienste, d.h. zu tun, was seine Hauptaufgabe ist. Es ist, als würde man einen ClickHouse-Cluster in Kubernetes aufbauen.
Kommen wir nun zu einer so interessanten Sache. Dabei handelt es sich um eine Aufteilung der Verantwortung zwischen Kubernetes und dem Betreiber, d.h. was Kubernetes macht, was der Betreiber macht und wie sie miteinander interagieren.
Kubernetes ist für Systemdinge zuständig, d.h. für einen grundlegenden Satz von Objekten, die als Systembereich interpretiert werden können. Kubernetes weiß, wie man Pods startet, wie man Container neu startet, wie man Volumes mountet, wie man mit ConfigMap arbeitet, d. h. alles, was man als System bezeichnen kann.
Betreiber sind in Fachgebieten tätig. Jeder Operator ist für sein Fachgebiet konzipiert. Wir haben für ClickHouse gemacht.
Und der Bediener interagiert genau im Hinblick auf den Themenbereich, z. B. das Hinzufügen einer Replik, das Erstellen eines Schemas oder das Einrichten der Überwachung. Es gibt eine solche Trennung.
Schauen wir uns ein praktisches Beispiel dafür an, wie diese Trennung von Belangen erfolgt, wenn wir eine Aktion zum Hinzufügen von Replikaten ausführen.
Der Bediener hat die Aufgabe, eine Replik hinzuzufügen. Was macht der Betreiber? Der Betreiber berechnet, dass ein neues StatefulSet erstellt werden muss, in dem bestimmte Vorlagen und Volumenansprüche beschrieben werden müssen.
Er hat alles vorbereitet und gibt es an K8s weiter. Er sagt, dass er ConfigMap, StatefulSet, Volume benötigt. Kubernetes funktioniert. Er materialisiert die Grundeinheiten, mit denen er operiert.
Und dann kommt wieder der ClickHouse-Betreiber ins Spiel. Er verfügt bereits über eine physische Kapsel, auf der Sie bereits etwas tun können. Und der ClickHouse-Betreiber arbeitet wieder in Bezug auf den Themenbereich. Diese. Insbesondere ClickHouse: Um ein Replikat in einen Cluster aufzunehmen, müssen Sie zunächst das in diesem Cluster vorhandene Datenschema konfigurieren. Und zweitens muss dieser Hinweis in die Überwachung einbezogen werden, damit er eindeutig nachvollziehbar ist. Der Betreiber hat es bereits eingerichtet.
Und erst danach kommt ClickHouse selbst ins Spiel, d.h. eine andere übergeordnete Entität. Es ist bereits eine Datenbank. Es verfügt über eine eigene Instanz, das nächste konfigurierte Replikat, das bereit ist, dem Cluster beizutreten.
Es stellt sich heraus, dass die Ausführungskette und die Trennung der Verantwortung beim Hinzufügen einer Replik lang genug sind.
Wir setzen unsere praktischen Aufgaben fort. Wenn der Cluster bereits vorhanden ist, können Sie die Konfiguration migrieren.
Wir haben es so gestaltet, dass es möglich ist, in die vorhandene XML-Datei zu gelangen, die ClickHouse versteht.
Sie können ClickHouse optimieren. Bei der Erklärung von hostPath und lokalem Speicher habe ich nur über die Bereitstellung in Zonen gesprochen. So führen Sie die Zonenbereitstellung korrekt durch.
Die nächste praktische Aufgabe ist die Überwachung.
Wenn sich unser Cluster ändert, müssen wir die Überwachung regelmäßig konfigurieren.
Werfen wir einen Blick auf das Diagramm. Die grünen Pfeile haben wir hier bereits berücksichtigt. Schauen wir uns nun die roten Pfeile an. So wollen wir unseren Cluster überwachen. Wie Metriken aus dem ClickHouse-Cluster in Prometheus und dann in Grafana gelangen.
Was ist das Problem mit der Überwachung? Warum wird dies als eine Art Errungenschaft dargestellt? Die Schwierigkeit liegt in der Dynamik. Wenn wir einen Cluster haben und dieser statisch ist, können Sie die Überwachung einmal einrichten und müssen sich nicht mehr darum kümmern.
Aber wenn wir viele Cluster haben oder sich ständig etwas ändert, dann ist der Prozess dynamisch. Und die ständige Neukonfiguration der Überwachung ist eine Verschwendung von Ressourcen und Zeit. sogar einfach nur faul. Dies muss automatisiert werden. Die Schwierigkeit liegt in der Dynamik des Prozesses. Und der Betreiber automatisiert dies sehr gut.
Wie hat sich unser Cluster entwickelt? Am Anfang war er so.
Dann war er so.
Am Ende wurde er so.
Und die Überwachung erfolgt automatisch durch den Bediener. Einziger Einstiegspunkt.
Und wir schauen uns einfach den Ausgang im Grafana-Dashboard an und sehen, wie das Leben unseres Clusters darin brodelt.
Übrigens wird das Grafana-Dashboard auch direkt im Quellcode von unserem Betreiber vertrieben. Sie können eine Verbindung herstellen und verwenden. Dieser Screenshot wurde mir von unserem DevOps zur Verfügung gestellt.
Wohin möchten wir als nächstes gehen? Das:
- Testautomatisierung entwickeln. Die Hauptaufgabe besteht im automatisierten Testen neuer Versionen.
- Wir möchten auch die Integration mit ZooKeeper wirklich automatisieren. Und plant die Integration mit ZooKeeper-Operator. Diese. Für ZooKeeper wurde ein Operator geschrieben, und es ist logisch, dass die beiden Operatoren mit der Integration beginnen, um eine bequemere Lösung zu erstellen.
- Wir wollen komplexere Lebenschecks durchführen.
- Ich habe grün hervorgehoben, dass die Vorlagenvererbung unterwegs ist – FERTIG, d. h. mit der nächsten Veröffentlichung des Operators werden wir bereits über die Vorlagenvererbung verfügen. Dies ist ein leistungsstarkes Tool, mit dem Sie komplexe Konfigurationen aus Teilen erstellen können.
- Und wir wollen komplexe Aufgaben automatisieren. Das wichtigste ist Re-Sharding.
Lassen Sie uns einige Zwischenergebnisse erstellen.
Was bekommen wir als Ergebnis? Und lohnt es sich oder nicht? Muss ich überhaupt versuchen, die Datenbank in Kubernetes zu ziehen und den Operator im Allgemeinen und den Alitnity-Operator im Besonderen anzuwenden?
Als Ausgabe erhalten wir:
- Vereinfachen und automatisieren Sie Konfiguration, Bereitstellung und Wartung erheblich.
- Sofort integrierte Überwachung.
- Und gebrauchsfertige kodifizierte Vorlagen für komplexe Situationen. Bereits die Aktion des Typs zum Hinzufügen einer Replik muss nicht mehr manuell ausgeführt werden. Dies erfolgt durch den Betreiber.
Bleibt nur noch die letzte Frage. Wir haben bereits eine Datenbank in Kubernetes, Virtualisierung. Wie sieht es mit der Leistung einer solchen Lösung aus, insbesondere da ClickHouse auf Leistung optimiert ist?
Die Antwort lautet: Alles ist in Ordnung! Ich werde nicht im Detail darauf eingehen, dies ist das Thema eines separaten Berichts.
Aber es gibt so ein Projekt wie TSBS. Was ist seine Hauptaufgabe? Dies ist ein Datenbankleistungstest. Dies ist ein Versuch, warm mit warm, weich mit weich zu vergleichen.
Wie funktioniert er? Es wird ein Datensatz generiert. Anschließend wird dieser Datensatz desselben Testsatzes in verschiedenen Datenbanken ausgeführt. Und jede Datenbank löst ein Problem auf die Art und Weise, wie sie kann. Und dann können Sie die Ergebnisse vergleichen.
Es unterstützt bereits eine große Anzahl von Datenbanken. Ich habe drei Hauptaspekte identifiziert. Das:
- timescaledb.
- InfluxDB.
- Clickhouse.
Es wurde auch ein Vergleich mit einer anderen ähnlichen Lösung durchgeführt. Vergleich mit RedShift. Der Vergleich wurde auf Amazon durchgeführt. Auch hier ist ClickHouse allen weit voraus.
Welche Schlussfolgerungen können aus dem, was ich gesagt habe, gezogen werden?
- DB in Kubernetes ist möglich. Wahrscheinlich können Sie alles tun, aber im Allgemeinen sieht es so aus, als ob Sie es könnten. ClickHouse in Kubernetes ist mit Hilfe unseres Betreibers definitiv möglich.
- Der Bediener hilft, Prozesse zu automatisieren und macht das Leben wirklich einfacher.
- Die Leistung ist normal.
- Und es scheint uns, dass es genutzt werden kann und sollte.
Open Source – machen Sie mit!
Wie gesagt, der Operator ist ein komplett Open-Source-Produkt, daher wäre es sehr gut, wenn möglichst viele Leute ihn nutzen würden. Jetzt beitreten! Wir warten auf euch alle!
Vielen Dank an alle!
Fragen
Danke für den Bericht! Mein Name ist Anton. Ich komme von SEMrush. Ich frage mich, was mit der Protokollierung los ist. Wir hören von Überwachung, aber nichts von Protokollierung, wenn wir über den gesamten Cluster sprechen. Wir haben zum Beispiel einen Hardware-Cluster. Und wir verwenden eine zentrale Protokollierung, wir sammeln sie mit Standardmitteln in einem gemeinsamen Heap. Und von dort erhalten wir dann Daten, die für uns interessant sind.
Gute Frage, nämlich das Einloggen in die Todo-Liste. Unser Betreiber automatisiert dies noch nicht. Es befindet sich noch in der Entwicklung, das Projekt ist noch recht jung. Wir verstehen die Notwendigkeit der Protokollierung. Auch das ist ein sehr wichtiges Thema. Und es ist wahrscheinlich nicht weniger wichtig als die Überwachung. Doch zunächst stand bei der Umsetzung das Monitoring auf der Liste. Es wird eine Protokollierung geben. Natürlich versuchen wir, alle Aspekte des Clusterlebens zu automatisieren. Daher ist die Antwort, dass der Betreiber im Moment leider nicht weiß, wie das geht, aber es ist in den Plänen, wir werden es tun. Wenn Sie mitmachen möchten, dann ziehen Sie bitte die Anfrage.
Guten Tag! Danke für den Bericht! Ich habe eine Standardfrage zu Persistent Volumes. Wenn wir mit diesem Operator eine Konfiguration erstellen, wie bestimmt der Operator, auf welchem Knoten sich eine Festplatte oder ein Ordner befindet? Wir müssen ihm zunächst erklären, dass wir unser ClickHouse bitte genau auf diesen Knoten platzieren, die über eine Festplatte verfügen.
Soweit ich weiß, handelt es sich bei dieser Frage um eine Fortsetzung des lokalen Speichers, insbesondere des hostPath-Teils. Es ist, als würde man dem gesamten System erklären, dass der Pod genau auf diesem oder jenem Knoten gestartet werden muss, auf dem wir eine physisch verbundene Festplatte haben, die auf diesem oder jenem Pfad gemountet ist. Dies ist ein ganzer Abschnitt, den ich nur sehr oberflächlich berührt habe, da die Antwort dort ziemlich umfangreich ist.
Kurz gesagt sieht es so aus. Natürlich müssen wir diese Volumes bereitstellen. Derzeit gibt es keine dynamische Bereitstellung im lokalen Speicher, daher muss DevOps die Festplatten selbst schneiden, hier sind diese Volumes. Und sie müssen die Kubernetes-Bereitstellung erklären, sodass Sie über persistente Volumes dieser und jener Klasse verfügen, die sich auf diesen und jenen Knoten befinden. Dann muss Kubernetes erklärt werden, dass Pods, die diese und jene lokale Speicherklasse erfordern, nur anhand von Labels für diese und jene Knoten geplant werden müssen. Für diese Zwecke hat der Betreiber die Möglichkeit, eine Art Label zuzuweisen, und zwar eines pro Hostinstanz. Und es stellt sich heraus, dass Pods von Kubernetes so weitergeleitet werden, dass sie nur auf Knoten ausgeführt werden, die den Anforderungen, den Labels, einfach ausgedrückt, entsprechen. Administratoren weisen Labels zu und führen die Bereitstellung von Festplatten manuell durch. Und dann skaliert es.
Und gerade die dritte Option lokal hilft, es ein wenig einfacher zu machen. Wie ich bereits betont habe, handelt es sich dabei um eine aufwändige Abstimmungsarbeit, die letztendlich zur Erzielung maximaler Leistung beiträgt.
Ich habe eine zweite Frage dazu. Kubernetes wurde so konzipiert, dass es für uns keine Rolle spielt, ob wir einen Knoten verlieren oder nicht. Was sollen wir in diesem Fall tun, wenn wir den Knoten verloren haben, auf dem wir einen Shard haben?
Ja, Kubernetes ging ursprünglich davon aus, dass unsere Beziehung zu unseren Pods wie Vieh ist, aber hier wird jede Festplatte zu so etwas wie einem Haustier. Das Problem ist so groß, dass wir sie nicht einfach wegwerfen können. Und die Entwicklung von Kubernetes geht in die Richtung, dass es unmöglich ist, es vollständig philosophisch als völlig verworfene Ressource zu behandeln.
Nun eine praktische Frage. Was tun, wenn Sie den Knoten verloren haben, auf dem sich die Festplatte befand? Hier wird das Problem auf einer höheren Ebene gelöst. Im Fall von ClickHouse haben wir Nachbildungen, die auf einer höheren Ebene funktionieren, d. h. auf ClickHouse-Ebene.
Wie ist die Disposition? DevOps ist dafür verantwortlich, dass Daten nicht verloren gehen. Es muss die Replikation ordnungsgemäß einrichten und sicherstellen, dass die Replikation ausgeführt wird. Im Replikat auf ClickHouse-Ebene müssen die Daten dupliziert werden. Dies ist nicht die Aufgabe, die der Bediener löst. Und nicht die Aufgabe, die Kubernetes selbst löst. Dies geschieht auf ClickHouse-Ebene.
Was tun, wenn Ihr Eisenknoten abgefallen ist? Und es stellt sich heraus, dass es notwendig sein wird, die zweite zu platzieren, die Festplatte richtig darauf zu bewegen und Etiketten anzubringen. Und danach erfüllt es die Anforderungen, dass Kubernetes darauf eine Pod-Instanz ausführen kann. Kubernetes wird es starten. Ihre Anzahl an Pods reicht nicht für die angegebene Anzahl aus. Es wird den Zyklus durchlaufen, den ich gezeigt habe. Und auf höchster Ebene erkennt ClickHouse, dass wir eine Replik eingegeben haben, diese noch leer ist und wir mit der Datenübertragung dorthin beginnen müssen. Diese. Dieser Prozess ist immer noch schlecht automatisiert.
Danke für den Bericht! Wenn alle möglichen schlimmen Dinge passieren, der Operator abstürzt und neu startet und in diesem Moment Ereignisse eintreten, können Sie das irgendwie verarbeiten?
Was passiert, wenn der Operator abstürzt und neu startet, ja?
Ja. Und in diesem Moment kamen Ereignisse.
Die Aufgabe, was in diesem Fall zu tun ist, ist teilweise zwischen dem Betreiber und Kubernetes aufgeteilt. Kubernetes bietet die Möglichkeit, ein aufgetretenes Ereignis wiederzugeben. Er wiederholt. Und die Aufgabe des Bedieners besteht darin, sicherzustellen, dass diese Ereignisse idempotent sind, wenn das Ereignisprotokoll darauf wiedergegeben wird. Und damit das erneute Auftreten desselben Ereignisses unser System nicht für uns kaputt macht. Und unser Betreiber meistert diese Aufgabe.
Guten Tag! Danke für den Bericht! Dmitry Zavialov, Unternehmen Smedow. Ist geplant, dem Betreiber Anpassungsmöglichkeiten mit Haproxy hinzuzufügen? Neben dem Standard-Balancer ist noch ein anderer Balancer interessant, sodass er intelligent ist und versteht, dass ClickHouse dort real ist.
Sprechen Sie über Ingress?
Ja, ersetzen Sie Ingress durch Haproxy. In Haproxy können Sie die Clustertopologie angeben, in der Replikate vorhanden sind.
Bisher haben wir noch nicht darüber nachgedacht. Wenn Sie es brauchen und erklären können, warum es nötig ist, dann wird es möglich sein, es umzusetzen, insbesondere wenn Sie teilnehmen möchten. Gerne prüfen wir die Option. Die kurze Antwort lautet: Nein, wir verfügen derzeit nicht über eine solche Funktionalität. Danke für den Tipp, wir schauen uns das mal an. Und wenn man dann noch den Anwendungsfall erklärt und erklärt, warum es in der Praxis notwendig ist, zum Beispiel Issues auf GitHub zu erstellen, dann ist das super.
Bereits.
Bußgeld. Wir sind für alle Vorschläge offen. Und Haproxy wird auf die Todo-Liste gesetzt. Die To-do-Liste wächst, sie schrumpft noch nicht. Aber das ist gut, es bedeutet, dass das Produkt gefragt ist.
Source: habr.com