Local<\/li>\n<\/ul>\n<\/p>\n
Lassen Sie uns betrachten, wie sie sich unterscheiden und \u00e4hnlich sind. <\/p>\n
<\/p>\n
Zun\u00e4chst haben wir in allen drei Ans\u00e4tzen den Speicher \u2013 das sind lokale Festplatten, die sich auf demselben physischen k8s-Knoten befinden. Aber es gibt einige Unterschiede.<\/p>\n
<\/p>\n
<\/p>\n
Beginnen wir mit dem einfachsten, n\u00e4mlich emptyDir. Was ist das in der Praxis? Wir bitten unser Spezifikationssystem (meistens ist das Docker), uns Zugriff auf einen Ordner auf der lokalen Festplatte zu gew\u00e4hren.<\/p>\n
<\/p>\n
In der Praxis erstellt Docker irgendwo auf seinen eigenen Pfaden einen tempor\u00e4ren Ordner, nennt ihn mit einem langen Hash und gew\u00e4hrt Zugang zu ihm. <\/p>\n
<\/p>\n
Wie wird das in Bezug auf die Leistung funktionieren? Es wird mit der Geschwindigkeit der lokalen Festplatte arbeiten, d.h. es ist ein vollst\u00e4ndiger Zugriff auf das eigene Laufwerk. <\/p>\n
<\/p>\n
Aber diese Methode hat ihren Nachteil. Persistent in diesem Fall ist ziemlich fraglich. Bei der ersten Bewegung von Docker mit Containern geht die Persistenz verloren. Wenn Kubernetes aus irgendeinem Grund diesen Pod auf eine andere Festplatte verschieben m\u00f6chte, gehen die Daten verloren. <\/p>\n
<\/p>\n
Dieser Ansatz eignet sich gut f\u00fcr Tests, weil er bereits eine angemessene Geschwindigkeit zeigt, aber f\u00fcr etwas Ernsthaftes ist diese Option nicht geeignet. <\/p>\n
<\/p>\n
<\/p>\n
Deshalb gibt es den zweiten Ansatz. Das ist hostPath. Wenn man sich die vorherige Folie und diese ansieht, sieht man nur einen Unterschied. Unser Ordner ist aus Docker direkt auf den Kubernetes-Knoten gewandert. Hier ist es etwas einfacher. Wir geben den Pfad im lokalen Dateisystem an, an dem wir unsere Daten speichern m\u00f6chten. <\/p>\n
<\/p>\n
Die Vorteile dieser Methode sind vorhanden. Es handelt sich bereits um echte Persistenz, und zwar eine klassische. Unsere Daten werden an einer bestimmten Adresse auf der Festplatte gespeichert. <\/p>\n
<\/p>\n
Es gibt auch Nachteile. Dazu geh\u00f6rt die Komplexit\u00e4t des Managements. Unser Kubernetes k\u00f6nnte sich entscheiden, einen Pod auf einen anderen physischen Knoten zu verschieben. Und hier kommt DevOps ins Spiel. Er muss der gesamten Architektur richtig erkl\u00e4ren, dass diese Pods nur auf solche Knoten verschoben werden d\u00fcrfen, auf denen etwas unter diesen Pfaden montiert ist, und niemals mehr als einen Knoten auf einmal. Das ist ziemlich kompliziert. <\/p>\n
<\/p>\n
Speziell f\u00fcr diese Zwecke haben wir in unserem Operator Vorlagen entwickelt, um all diese Komplexit\u00e4t zu verbergen. Und man k\u00f6nnte einfach sagen: \u201eIch m\u00f6chte, dass ich einen ClickHouse-Instanz auf jedem physischen Knoten und auf diesem bestimmten Pfad habe.\u201c <\/p>\n
<\/p>\n
<\/p>\n
Aber dieses Bed\u00fcrfnis besteht nicht nur f\u00fcr uns, daher verstehen auch die Herren vom Kubernetes, dass die Menschen Zugang zu physischen Festplatten haben m\u00f6chten, weshalb sie eine dritte Ebene bereitstellen.<\/p>\n
<\/p>\n
Sie wird local genannt. Der Unterschied zum vorherigen Slide ist praktisch nicht vorhanden. Fr\u00fcher musste man manuell daf\u00fcr sorgen, dass wir diese Pods nicht von Knoten zu Knoten verschieben konnten, weil sie an einem bestimmten Pfad an die lokale physische Festplatte angeschlossen sein mussten. Jetzt werden all diese Kenntnisse in Kubernetes selbst gekapselt. Es wird deutlich einfacher zu konfigurieren.<\/p>\n
<\/p>\n
<\/p>\n
Kehren wir zu unserer praktischen Aufgabe zur\u00fcck. Wir wenden uns der YAML-Vorlage zu. Hier haben wir echten Speicher. Wir sind zur\u00fcckgekehrt zu diesem Punkt. Wir definieren eine klassische VolumeClaim-Vorlage wie in k8s. Und wir beschreiben, welchen Speicher wir m\u00f6chten.<\/p>\n
<\/p>\n
Danach wird k8s Speicher anfordern. Er wird uns diesen im StatefulSet zuweisen. Und letztendlich wird dies ClickHouse zur Verf\u00fcgung stehen.<\/p>\n
<\/p>\n
<\/p>\n
Wir hatten ein solches Schema. Unser Persistent Storage war rot, was andeutet, dass wir ihn erstellen sollten. <\/p>\n
<\/p>\n
<\/p>\n
Und er wird gr\u00fcn. Jetzt ist das Schema des ClickHouse-Clusters auf k8s vollst\u00e4ndig finalisiert. Wir haben Shards, Replikate, ZooKeeper, und es gibt einen echten Persistent Storage, der auf die eine oder andere Weise realisiert ist. Das Schema ist bereits vollst\u00e4ndig funktionsf\u00e4hig. <\/p>\n
<\/p>\n
<\/p>\n
Wir machen weiter. Unser Cluster entwickelt sich weiter. Und Alexey gibt sich M\u00fche und ver\u00f6ffentlicht eine neue Version von ClickHouse.<\/p>\n
<\/p>\n
Es entsteht die praktische Aufgabe, die neue Version von ClickHouse in unserem Cluster zu testen. Und nat\u00fcrlich m\u00f6chte man nicht alles darauf zu aktualisieren, sondern lieber in einer abgelegenen Ecke eine Replik mit der neuen Version betreiben, oder vielleicht sogar nicht nur eine neue Version, sondern gleich zwei, weil sie ziemlich h\u00e4ufig erscheinen. <\/p>\n
<\/p>\n
Was k\u00f6nnen wir dazu sagen?<\/p>\n
<\/p>\n
<\/p>\n
Hier haben wir genau die M\u00f6glichkeit. Das sind die Vorlagen von Pods. Man kann festlegen, unser Operator erlaubt es vollst\u00e4ndig, einen heterogenen Cluster aufzubauen. D.h. konfiguriert von allen Replikaten in einer Gruppe bis hin zu jeder einzelnen Replik, welche Version von ClickHouse und welche Version von Storage wir haben m\u00f6chten. Wir k\u00f6nnen den Cluster in der ben\u00f6tigten Konfiguration komplett einrichten. <\/p>\n
<\/p>\n
<\/p>\n
Wir werden jetzt etwas tiefer eintauchen. Zuvor haben wir dar\u00fcber gesprochen, wie der ClickHouse-Operator im Hinblick auf die spezifischen Eigenschaften von ClickHouse funktioniert.<\/p>\n
<\/p>\n
Jetzt m\u00f6chte ich ein paar Worte dar\u00fcber sagen, wie jeder Operator im Allgemeinen funktioniert und wie er mit K8s interagiert.<\/p>\n
<\/p>\n
<\/p>\n
Lassen Sie uns zuerst die Interaktion mit K8s betrachten. Was passiert, wenn wir kubectl apply ausf\u00fchren? Durch die API erscheinen unsere Objekte in etcd. <\/p>\n
<\/p>\n
<\/p>\n
Beispielsweise die grundlegenden Kubernetes-Objekte: Pod, StatefulSet, Service und so weiter. <\/p>\n
<\/p>\n
Dabei passiert physisch noch nichts. Diese Objekte m\u00fcssen im Cluster materialisiert werden. <\/p>\n
<\/p>\n
<\/p>\n
Daf\u00fcr kommt ein Controller ins Spiel. Der Controller ist eine spezielle K8s-Komponente, die diese Beschreibungen materialisieren kann. Er wei\u00df, was physisch zu tun ist. Er wei\u00df, wie man Container startet und was eingestellt werden muss, damit der Server funktioniert. <\/p>\n
<\/p>\n
<\/p>\n
Und er materialisiert unsere Objekte in K8s.<\/p>\n
<\/p>\n
Aber wir m\u00f6chten nicht nur mit Pods und StatefulSets arbeiten, wir m\u00f6chten eine ClickHouseInstallation erstellen, d.h. ein Objekt vom Typ ClickHouse, um damit als Einheit zu arbeiten. Bisher gibt es diese M\u00f6glichkeit nicht. <\/p>\n
<\/p>\n
<\/p>\n
Aber K8s hat eine weitere angenehme Eigenschaft. Wir m\u00f6chten, dass irgendwo eine so komplexe Entit\u00e4t entsteht, in der unser Cluster aus Pods und StatefulSets zusammengefasst ist. <\/p>\n
<\/p>\n
<\/p>\n
Was muss also daf\u00fcr getan werden? Zuerst tritt die Custom Resource Definition auf den Plan. Was ist das? Es ist eine Beschreibung f\u00fcr K8s, dass es einen weiteren Datentyp geben wird, dass wir zu Pod, StatefulSet eine benutzerdefinierte Ressource hinzuf\u00fcgen m\u00f6chten, die komplex ist. Dies ist eine Beschreibung der Datenstruktur. <\/p>\n
<\/p>\n
<\/p>\n
Wir senden es ebenfalls \u00fcber kubectl apply dorthin. Kubernetes hat es erfreut aufgenommen. <\/p>\n
<\/p>\n
Und jetzt haben wir im Speicher, beim Objekt in etcd die M\u00f6glichkeit, eine benutzerdefinierte Ressource mit dem Namen ClickHouseInstallation zu registrieren.<\/p>\n
<\/p>\n
Aber bisher wird nichts weiter passieren. D. h., wenn wir jetzt die YAML-Datei erstellen, die wir mit der Beschreibung der Shards, Replikate und sagen \u201ekubectl apply\u201c betrachtet haben, wird Kubernetes sie akzeptieren, in etcd ablegen und sagen: \u201eSuper, aber was damit zu tun ist, wei\u00df ich nicht. Wie man ClickHouseInstallation verwaltet, wei\u00df ich nicht.\u201c <\/p>\n
<\/p>\n
<\/p>\n
Das hei\u00dft, wir brauchen jemanden, der Kubernetes hilft, den neuen Datentyp zu verwalten. Links haben wir einen nativen Kubernetes-Controller, der mit den nativen Datentypen arbeitet. Rechts sollte ein benutzerdefinierter Controller erscheinen, der mit benutzerdefinierten Datentypen arbeiten kann. <\/p>\n
<\/p>\n
Und er wird anders als Operator bezeichnet. Ich habe ihn hier absichtlich au\u00dferhalb von Kubernetes platziert, weil er auch au\u00dferhalb von K8s ausgef\u00fchrt werden kann. Die meisten Operatoren laufen nat\u00fcrlich in Kubernetes, aber nichts hindert ihn daran, au\u00dfen zu stehen, deshalb ist er hier speziell nach au\u00dfen verschoben. <\/p>\n
<\/p>\n
<\/p>\n
Der benutzerdefinierte Controller, auch Operator genannt, interagiert \u00fcber die API mit Kubernetes. Er kann bereits mit der API interagieren. Und er wei\u00df bereits, wie man aus einer benutzerdefinierten Ressource ein komplexes Schema materialisiert, das wir erstellen m\u00f6chten. Genau das tut der Operator. <\/p>\n
<\/p>\n
<\/p>\n
Wie funktioniert der Operator? Lassen Sie uns in den rechten Teil schauen, um zu erfahren, wie er das macht. Wir erfahren, wie der Operator all dies materialisiert und wie die Interaktion mit K8s weitergeht.<\/p>\n
<\/p>\n
<\/p>\n
Der Operator ist ein Programm. Es ist ereignisorientiert. Der Operator meldet sich mit Hilfe der Kubernetes API auf Ereignisse an. In der Kubernetes API gibt es Einstiegspunkte, an denen man sich auf Ereignisse anmelden kann. Und wenn sich etwas in K8s \u00e4ndert, sendet Kubernetes Ereignisse an alle Interessierten, d. h. wer sich an diesen API-Punkt angemeldet hat, erh\u00e4lt die Benachrichtigungen.<\/p>\n
<\/p>\n
Der Operator meldet sich auf Ereignisse, und er muss darauf reagieren. Seine Aufgabe ist es, auf die auftretenden Ereignisse zu reagieren. <\/p>\n
<\/p>\n
<\/p>\n
Ereignisse werden durch bestimmte Updates erzeugt. Unsere YAML-Datei mit der Beschreibung der ClickHouseInstallation kommt an. Sie geht \u00fcber kubectl apply nach etcd. Dort trat ein Ereignis ein, das letztendlich dieses Ereignis an den ClickHouse-Operator gesendet hat. Der Operator hat diese Beschreibung erhalten. Und er muss etwas tun. Wenn ein Update des Objekts ClickHouseInstallation eintrifft, muss der Cluster aktualisiert werden. Und die Aufgabe des Operators besteht darin, den Cluster zu aktualisieren. <\/p>\n
<\/p>\n
<\/p>\n
Was macht er? Zun\u00e4chst einmal m\u00fcssen wir einen Aktionsplan erstellen, was wir mit diesem Update machen werden. Updates k\u00f6nnen sehr klein sein, also klein in der YAML-Implementierung, k\u00f6nnen aber sehr gro\u00dfe \u00c4nderungen im Cluster nach sich ziehen. Daher erstellt der Operator einen Plan und h\u00e4lt sich dann daran.<\/p>\n
<\/p>\n
<\/p>\n
Er beginnt gem\u00e4\u00df diesem Plan, diese Struktur intern zu erstellen, um Pods und Dienste zu materialisieren, also das zu tun, was seine Hauptaufgabe ist. Es ist, als w\u00fcrde man ein ClickHouse-Cluster in Kubernetes aufbauen.<\/p>\n
<\/p>\n
<\/p>\n
Jetzt lassen Sie uns ein interessantes Thema ansprechen. Das ist die Aufteilung der Verantwortlichkeiten zwischen Kubernetes und dem Operator, d.h. was Kubernetes tut, was der Operator tut und wie sie untereinander interagieren. <\/p>\n
<\/p>\n
Kubernetes ist f\u00fcr systematische Dinge zust\u00e4ndig, also f\u00fcr eine grundlegende Sammlung von Objekten, die man als systemscope interpretieren kann. Kubernetes wei\u00df, wie man Pods startet, wie man Container neu startet, wie man Volumes anbindet, wie man mit ConfigMaps arbeitet, also alles, was man als System bezeichnen kann. <\/p>\n
<\/p>\n
Operatoren betreiben in Fachbereichen. Jeder Operator ist f\u00fcr seinen eigenen Fachbereich konzipiert. Wir haben einen f\u00fcr ClickHouse erstellt.<\/p>\n
<\/p>\n
Der Operator interagiert genau in den Begriffen des Fachbereichs, wie beispielsweise eine Replikation hinzuf\u00fcgen, ein Schema erstellen, Monitoring einrichten. So ergibt sich eine solche Teilung.<\/p>\n
<\/p>\n
<\/p>\n
Lassen Sie uns am praktischen Beispiel betrachten, wie diese Aufteilung der Verantwortlichkeiten erfolgt, wenn wir die Aktion \"Replik hinzuf\u00fcgen\" durchf\u00fchren. <\/p>\n
<\/p>\n
Im Operator kommt die Aufgabe \u2013 eine Replik hinzuzuf\u00fcgen. Was macht der Operator? Der Operator berechnet, dass ein neuer StatefulSet erstellt werden muss, in dem bestimmte Vorlagen und Volume-Claims beschrieben werden m\u00fcssen. <\/p>\n
<\/p>\n
<\/p>\n
Er hat alles vorbereitet und \u00fcbergibt es weiter an K8s. Er sagt, dass er eine ConfigMap, einen StatefulSet, ein Volume ben\u00f6tigt. Kubernetes bearbeitet es. Es materialisiert die grundlegenden Einheiten, mit denen es arbeitet. <\/p>\n
<\/p>\n
<\/p>\n
Und dann tritt erneut der ClickHouse-Operator in Aktion. Er hat bereits einen physischen Pod, auf dem er etwas tun kann. Und der ClickHouse-Operator arbeitet erneut in den Begriffen des Fachbereichs. Das hei\u00dft, um eine Replik in das Cluster einzuf\u00fcgen, muss man zun\u00e4chst das Datenschema, das in diesem Cluster existiert, einrichten. Und zweitens muss diese Replik in das Monitoring aufgenommen werden, damit sie gut nachverfolgt werden kann. Dies richtet der Operator ein. <\/p>\n
<\/p>\n
<\/p>\n
Und erst dann kommt ClickHouse selbst ins Spiel, d.h. eine weitere, h\u00f6herstufige Entit\u00e4t. Das ist bereits eine Datenbank. Sie hat ihre eigene Instanz, eine konfigurierte Replik, die bereit ist, einem Cluster beizutreten.<\/p>\n
<\/p>\n
Es ergibt sich eine recht lange Kette von Ausf\u00fchrungen und der Verteilung der Verantwortlichkeiten bei der Hinzuf\u00fcgung einer Replik.<\/p>\n
<\/p>\n
<\/p>\n
Behalten wir unsere praktischen Aufgaben im Auge. Wenn ein Cluster bereits existiert, kann die Konfiguration migriert werden. <\/p>\n
<\/p>\n
<\/p>\n
Wir haben es so gemacht, dass in die bestehende XML, die ClickHouse versteht, hindurchgeschoben werden kann.<\/p>\n
<\/p>\n
<\/p>\n
Man kann ClickHouse fein abstimmen. Gerade zonierte Bereitstellungen sind das, was ich bei der Erkl\u00e4rung von hostPath und lokalem Speicher erl\u00e4utert habe. So wird eine zonierte Bereitstellung korrekt gemacht.<\/p>\n
<\/p>\n
<\/p>\n
Die n\u00e4chste praktische Aufgabe ist das Monitoring.<\/p>\n
<\/p>\n
<\/p>\n
Wenn sich unser Cluster \u00e4ndert, m\u00fcssen wir das Monitoring regelm\u00e4\u00dfig einstellen. <\/p>\n
<\/p>\n
Lassen Sie uns das Schema betrachten. Die gr\u00fcnen Pfeile haben wir bereits betrachtet. Jetzt schauen wir uns die roten Pfeile an. So wollen wir unser Cluster \u00fcberwachen. Wie die Metriken aus dem ClickHouse-Cluster in Prometheus gelangen und dann in Grafana.<\/p>\n
<\/p>\n
<\/p>\n
Und was ist die Schwierigkeit beim Monitoring? Warum wird das als eine Art Errungenschaft angesehen? Die Schwierigkeit liegt genau in der Dynamik. Wenn wir einen Cluster haben und dieser statisch ist, kann das Monitoring einmalig eingerichtet werden und dann k\u00fcmmert man sich nicht mehr darum.<\/p>\n
<\/p>\n
Aber wenn wir viele Cluster haben oder sich st\u00e4ndig etwas \u00e4ndert, dann ist der Prozess dynamisch. Und st\u00e4ndig das Monitoring umzustellen, ist ein Ressourcen- und Zeitaufwand, d.h. auch einfach Faulheit. Das muss automatisiert werden. Die Schwierigkeit liegt genau in der Dynamik des Prozesses. Und der Operator automatisiert das sehr gut. <\/p>\n
<\/p>\n
<\/p>\n
Wie hat sich unser Cluster entwickelt? Am Anfang war er so.<\/p>\n
<\/p>\n
<\/p>\n
Dann war er so.<\/p>\n
<\/p>\n
<\/p>\n
Schlie\u00dflich wurde er so. <\/p>\n
<\/p>\n
Und das Monitoring wird automatisch vom Operator durchgef\u00fchrt. Ein einziger Zugangspunkt. <\/p>\n
<\/p>\n
<\/p>\n
Und wir schauen nur am Ausgang in das Grafana-Dashboard, wie das Leben in unserem Cluster pulsiert. <\/p>\n
<\/p>\n
\u00dcbrigens wird das Grafana-Dashboard auch zusammen mit unserem Operator direkt im Quellcode bereitgestellt. Es kann angeschlossen und genutzt werden. Dieses Screenshot haben mir unsere DevOps gegeben.<\/p>\n
<\/p>\n
<\/p>\n
Wohin m\u00f6chten wir als n\u00e4chstes gehen? Das ist:<\/p>\n
<\/p>\n
\nDie Automatisierung von Tests weiterentwickeln. Die Hauptaufgabe besteht in der automatisierten Testung neuer Versionen. <\/li>\n Wir m\u00f6chten auch die Integration mit ZooKeeper automatisieren. Wir planen, uns mit dem ZooKeeper-Operator zu integrieren. Das bedeutet, dass ein Operator f\u00fcr ZooKeeper geschrieben wurde, und es ist logisch, dass zwei Operatoren beginnen, sich zu integrieren, um eine benutzerfreundlichere L\u00f6sung zu entwickeln. <\/li>\n Wir wollen komplexere Gesundheitspr\u00fcfungen durchf\u00fchren. <\/li>\n Ich habe in Gr\u00fcn hervorgehoben, dass wir mit der Vererbung von Templates \u2013 DONE \u2013 kurz davor stehen, d. h. mit der n\u00e4chsten Version des Operators wird die Vererbung von Vorlagen verf\u00fcgbar sein. Das ist ein leistungsstarkes Werkzeug, das es erm\u00f6glicht, komplexe Konfigurationen aus Einzelteilen zu erstellen. <\/li>\n Und wir wollen die Automatisierung komplexer Aufgaben. Die Hauptaufgabe ist das Re-Sharding. <\/li>\n<\/ul>\n<\/p>\n
<\/p>\n
Lassen Sie uns ein Zwischenfazit ziehen. <\/p>\n
<\/p>\n
<\/p>\n
Was erhalten wir am Ende? Und sollten wir uns damit besch\u00e4ftigen oder nicht? Ist es notwendig, die Datenbank in Kubernetes zu integrieren und den Operator im Allgemeinen sowie den Alitnity-Operator im Besonderen einzusetzen?<\/p>\n
<\/p>\n
Am Ende erhalten wir:<\/p>\n
<\/p>\n
\nEine wesentliche Vereinfachung und Automatisierung der Konfiguration, Bereitstellung sowie Wartung. <\/li>\n Sofort integrierte \u00dcberwachung. <\/li>\n Und einsatzbereite, kodifizierte Vorlagen f\u00fcr komplexe Situationen. Aktionen wie das Hinzuf\u00fcgen eines Replikats m\u00fcssen nicht mehr manuell durchgef\u00fchrt werden. Das \u00fcbernimmt der Operator. <\/li>\n<\/ul>\n<\/p>\n
<\/p>\n
Es bleibt nur noch eine letzte Frage. Wir haben bereits die Datenbank in Kubernetes und Virtualisierung. Wie steht es um die Leistung einer solchen L\u00f6sung, insbesondere im Hinblick darauf, dass ClickHouse f\u00fcr Leistung optimiert ist?<\/p>\n
<\/p>\n
Die Antwort lautet: alles in Ordnung! Ich werde das nicht im Detail ausf\u00fchren, das w\u00e4re das Thema eines separaten Vortrags. <\/p>\n
<\/p>\n
<\/p>\n
Es gibt jedoch ein Projekt namens TSBS. Was ist dessen Hauptaufgabe? Es ist ein Leistungstest f\u00fcr Datenbanken. Es ist ein Versuch, \u00e4hnliches zu vergleichen. <\/p>\n
<\/p>\n
Wie funktioniert es? Ein Datensatz wird generiert. Dann wird dieser Datensatz auf einem identischen Testset in verschiedenen Datenbanken getestet. Und jede Datenbank l\u00f6st die gleiche Aufgabe auf ihre Weise. Anschlie\u00dfend k\u00f6nnen die Ergebnisse verglichen werden. <\/p>\n
<\/p>\n
Es werden bereits viele Datenbanken unterst\u00fctzt. Ich habe drei Hauptdatenbanken hervorgehoben. Das sind:<\/p>\n
<\/p>\n
\nTimescaleDB.<\/li>\n InfluxDB.<\/li>\n ClickHouse.<\/li>\n<\/ul>\n<\/p>\n
<\/p>\n
Es wurde auch ein Vergleich mit einer \u00e4hnlichen L\u00f6sung durchgef\u00fchrt. Ein Vergleich mit RedShift. Dieser Vergleich fand auf Amazon statt. ClickHouse \u00fcbertrifft in diesem Bereich ebenfalls alle. <\/p>\n
<\/p>\n
<\/p>\n
Welche Schlussfolgerungen k\u00f6nnen aus dem, was ich erz\u00e4hlt habe, gezogen werden?<\/p>\n
<\/p>\n
\nDB in Kubernetes ist m\u00f6glich. Wahrscheinlich kann man alles M\u00f6gliche verwenden, aber insgesamt sieht es so aus, als ob es funktioniert. ClickHouse in Kubernetes kann auf jeden Fall mit Hilfe unseres Operators betrieben werden. <\/li>\n Der Operator hilft, Prozesse zu automatisieren und erleichtert das Leben wirklich.<\/li>\n Die Leistung ist normal.<\/li>\n Und wir glauben, dass es m\u00f6glich ist und genutzt werden sollte. <\/li>\n<\/ul>\n<\/p>\n
Open Source \u2013 schlie\u00dfen Sie sich uns an!<\/p>\n
<\/p>\n
Wie ich bereits gesagt habe, ist der Operator ein vollst\u00e4ndig Open Source Produkt, daher w\u00e4re es sehr gut, wenn m\u00f6glichst viele Menschen ihn verwenden. Schlie\u00dfen Sie sich uns an! Wir freuen uns auf euch alle!<\/p>\n
<\/p>\n
Vielen Dank an alle!<\/p>\n
<\/p>\n
Fragen<\/p>\n
<\/p>\n
<\/p>\n
Danke f\u00fcr den Vortrag! Mein Name ist Anton. Ich bin von der Firma SEMrush. Mich interessiert das Thema Logging. \u00dcber das Monitoring h\u00f6rt man viel, aber \u00fcber das Logging wei\u00df man nichts, wenn man \u00fcber den gesamten Cluster spricht. Bei uns beispielsweise l\u00e4uft der Cluster auf Hardware. Wir nutzen zentrales Logging und sammeln mit den standardm\u00e4\u00dfigen Mitteln in einem gemeinsamen Pool. Und dann holen wir dort die f\u00fcr uns interessanten Daten heraus.<\/em> <\/p>\n<\/p>\n
Gute Frage, das hei\u00dft, Logging steht auf der To-Do-Liste. Unser Operator automatisiert das derzeit noch nicht. Er entwickelt sich noch, das Projekt ist noch recht jung. Wir verstehen die Notwendigkeit des Loggings. Es ist auch ein sehr wichtiges Thema. Und es ist wahrscheinlich nicht weniger wichtig als das Monitoring. Aber das Monitoring stand zuerst auf der Liste zur Umsetzung. Logging wird es geben. Wir bem\u00fchen uns nat\u00fcrlich, alle Aspekte des Clusterlebens zu automatisieren. Daher die Antwort \u2013 momentan kann der Operator das leider noch nicht, aber es ist in den Pl\u00e4nen, wir werden das umsetzen. Wenn jemand Lust hat mitzumachen, dann bitte Pull Request.<\/p>\n
<\/p>\n
Hallo! Vielen Dank f\u00fcr den Vortrag! Ich habe eine Standardfrage zu den Persistent Volumes. Wenn wir mit diesem Operator eine Konfiguration erstellen, wie bestimmt der Operator, auf welchem Knoten eine Festplatte oder ein Ordner gemountet ist? M\u00fcssen wir ihm vorher erkl\u00e4ren, dass er bitte unser ClickHouse genau auf diesen Knoten platzieren soll, auf denen eine Festplatte vorhanden ist?<\/em><\/p>\n<\/p>\n
Soweit ich das verstehe, ist diese Frage eine Fortsetzung des lokalen Speichers, insbesondere des Teils \u00fcber den hostPath. Es geht darum, der gesamten Systemarchitektur zu erkl\u00e4ren, dass der Pod genau auf diesem Knoten gestartet werden muss, an dem wir eine physisch angeschlossene Festplatte haben, die an einem bestimmten Pfad gemountet ist. Das ist ein ganz gro\u00dfer Abschnitt, den ich hier nur sehr oberfl\u00e4chlich angesprochen habe, da die Antwort ziemlich umfangreich ist. <\/p>\n
<\/p>\n
Kurz gesagt sieht es so aus. Wir m\u00fcssen nat\u00fcrlich das Provisioning dieser Volumes durchf\u00fchren. Momentan gibt es im lokalen Speicher kein dynamisches Provisioning, weshalb die DevOps-Teams die Festplatten selbst erstellen m\u00fcssen, also diese Volumes. Sie m\u00fcssen Kubernetes das Provisioning erkl\u00e4ren, dass es Persistent Volumes dieser Klasse gibt, die auf bestimmten Nodes liegen. Dann muss kubernetes erkl\u00e4rt werden, dass Pods, die einen bestimmten Typ von local storage ben\u00f6tigen, nur auf bestimmten Nodes anhand von Labels geplant werden sollen. Zu diesem Zweck gibt es im Operator die M\u00f6glichkeit, einen bestimmten Label und einen pro Host-Instanz zuzuweisen. Das f\u00fchrt dazu, dass die Pods von Kubernetes ausschlie\u00dflich auf Nodes gestartet werden, die den Anforderungen entsprechen, vereinfacht gesagt. Die Administratoren vergeben Labels und f\u00fchren das Provisioning der Festplatten manuell durch. Und dann skaliert es.<\/p>\n
<\/p>\n
Und genau die dritte Variante von local hilft, dies ein wenig zu vereinfachen. Wie ich bereits betont habe, ist es eine m\u00fchsame Arbeit, die bei der Umsetzung hilft, die maximale Leistung zu erzielen.<\/p>\n
<\/p>\n
Ich habe eine zweite Frage, die damit zusammenh\u00e4ngt. Kubernetes wurde so konzipiert, dass es uns egal ist, ob wir einen Node verlieren oder nicht. Was sollen wir in diesem Fall tun, wenn wir den Node verloren haben, an dem unsere Shard h\u00e4ngt?<\/em><\/p>\n<\/p>\n
Ja, Kubernetes wurde urspr\u00fcnglich so positioniert, dass unsere Beziehung zu unseren Pods wie zu Vieh ist, und hier wird jede Festplatte zu einer Art Haustier. Es gibt dieses Problem, dass wir sie nicht einfach wegwerfen k\u00f6nnen. Die Entwicklung von Kubernetes geht in die Richtung, dass man nicht vollst\u00e4ndig solidarisch mit diesem philosophisch umgehen kann, wie mit vollst\u00e4ndig wegwerfbaren Ressourcen.<\/p>\n
<\/p>\n
Jetzt zur praktischen Frage. Was tun, wenn Sie einen Node verloren haben, auf dem die Festplatte war? Hier wird das Problem auf einer h\u00f6heren Ebene gel\u00f6st. Im Falle von ClickHouse haben wir Replikate, die auf einer h\u00f6heren Ebene arbeiten, d.h. auf der ClickHouse-Ebene.<\/p>\n
<\/p>\n
Was ergibt sich daraus? F\u00fcr den Verlust von Daten ist DevOps verantwortlich. Er muss die Replikation richtig konfigurieren und sicherstellen, dass die Replikation durchgef\u00fchrt wird. In der Replik auf der ClickHouse-Ebene m\u00fcssen die Daten dupliziert sein. Das ist nicht die Aufgabe, die der Operator l\u00f6st. Und das ist nicht die Aufgabe, die Kubernetes selbst l\u00f6st. Das liegt auf der ClickHouse-Ebene.<\/p>\n
<\/p>\n
Was tun, wenn Ihnen ein Eisenknoten abgerissen ist? Man muss also einen zweiten setzen, richtig den Disk provisionieren, Labels anbringen. Und danach wird sie die Anforderungen erf\u00fcllen, damit Kubernetes darauf ein Pod-Instance starten kann. Kubernetes wird es starten. Ihnen fehlen ja die Anzahl an Pods bis zur festgelegten Anzahl. Es wird durch den Zyklus gehen, den ich gezeigt habe. Und auf der obersten Ebene wird ClickHouse verstehen, dass uns eine Replica eingegangen ist, sie ist noch leer und man muss anfangen, Daten dorthin zu \u00fcbertragen. Das hei\u00dft, dieser Prozess ist noch schlecht automatisiert. <\/p>\n
<\/p>\n
Danke f\u00fcr den Vortrag! Wenn verschiedene Probleme auftreten, der Operator abst\u00fcrzt und neu gestartet wird, w\u00e4hrend in diesem Moment Ereignisse eintreffen, verarbeiten Sie das irgendwie?<\/em><\/p>\n<\/p>\n
Was passiert, wenn der Operator abgest\u00fcrzt ist und neu gestartet wurde, ja? <\/p>\n
<\/p>\n
Ja. Und in diesem Moment sind Ereignisse eingegangen.<\/em> <\/p>\n<\/p>\n
Die Aufgabe, was in diesem Fall zu tun ist, teilt sich teilweise zwischen dem Operator und Kubernetes auf. Kubernetes hat die M\u00f6glichkeit, das eingetretene Ereignis zu wiederholen. Er spielt es nach. Die Aufgabe des Operators besteht darin, sicherzustellen, dass, wenn ihm die Ereignisprotokolle erneut abgespielt werden, diese Ereignisse idempotent sind. Und dass das wiederholte Eintreffen desselben Ereignisses unser System nicht kaputt macht. Und unser Operator bew\u00e4ltigt diese Aufgabe. <\/p>\n
<\/p>\n
Hallo! Danke f\u00fcr den Vortrag! Dmitrij Sawjalow, Unternehmen<\/em> Smedova. Ist die M\u00f6glichkeit, die Konfiguration mit Haproxy in den Operator aufzunehmen, geplant? Interessiert mich ein anderer Load Balancer als der Standard, damit er intelligent ist und versteht, dass dort wirklich ClickHouse ist.<\/em> <\/p>\n<\/p>\n
Sprechen Sie von Ingress?<\/p>\n
<\/p>\n
Ja, Ingress durch Haproxy ersetzen. In Haproxy kann man die Cluster-Topologie angeben, wo seine Replikas sind.<\/em><\/p>\n<\/p>\n
Bisher haben wir noch nicht dar\u00fcber nachgedacht. Wenn Sie das brauchen und erkl\u00e4ren k\u00f6nnen, warum das notwendig ist, k\u00f6nnte es umgesetzt werden, insbesondere, wenn Sie teilnehmen m\u00f6chten. Wir betrachten gerne die Option. Kurze Antwort \u2013 nein, wir haben momentan diese Funktionalit\u00e4t nicht. Danke f\u00fcr den Hinweis, wir werden uns das ansehen. Und wenn Sie uns noch den Anwendungsfall erkl\u00e4ren und warum es in der Praxis notwendig ist, zum Beispiel, wenn Sie Issues auf GitHub erstellen, w\u00e4re das wundervoll.<\/p>\n
<\/p>\n
Gibt es bereits.<\/em><\/p>\n<\/p>\n
Gut. Wir sind offen f\u00fcr alle Vorschl\u00e4ge. Und Haproxy steht auf der To-Do-Liste. Die To-Do-Liste w\u00e4chst zurzeit, sie verringert sich nicht. Aber das ist gut, das hei\u00dft, dass das Produkt gefragt ist.<\/p>\n
Quelle: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u0414\u043e\u043a\u043b\u0430\u0434 \u043f\u043e\u0441\u0432\u044f\u0449\u0435\u043d \u043f\u0440\u0430\u043a\u0442\u0438\u0447\u0435\u0441\u043a\u0438\u043c \u0432\u043e\u043f\u0440\u043e\u0441\u0430\u043c \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0438 \u043e\u043f\u0435\u0440\u0430\u0442\u043e\u0440\u0430 \u0432 Kubernetes, \u043f\u0440\u043e\u0435\u043a\u0442\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044e \u0435\u0433\u043e \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u044b \u0438 \u043e\u0441\u043d\u043e\u0432\u043d\u044b\u0445 \u043f\u0440\u0438\u043d\u0446\u0438\u043f\u043e\u0432 \u0444\u0443\u043d\u043a\u0446\u0438\u043e\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f. \u0412 \u043f\u0435\u0440\u0432\u043e\u0439 \u0447\u0430\u0441\u0442\u0438 \u0434\u043e\u043a\u043b\u0430\u0434\u0430 \u0440\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0438\u043c: \u0447\u0442\u043e \u0442\u0430\u043a\u043e\u0435 \u043e\u043f\u0435\u0440\u0430\u0442\u043e\u0440 \u0432 Kubernetes \u0438 \u0437\u0430\u0447\u0435\u043c \u043e\u043d \u043d\u0443\u0436\u0435\u043d; \u043a\u0430\u043a \u0438\u043c\u0435\u043d\u043d\u043e \u043e\u043f\u0435\u0440\u0430\u0442\u043e\u0440 \u0443\u043f\u0440\u043e\u0449\u0430\u0435\u0442 \u0443\u043f\u0440\u0430\u0432\u043b\u0435\u043d\u0438\u0435 \u0441\u043b\u043e\u0436\u043d\u044b\u043c\u0438 \u0441\u0438\u0441\u0442\u0435\u043c\u0430\u043c\u0438; \u0447\u0442\u043e \u043e\u043f\u0435\u0440\u0430\u0442\u043e\u0440 \u043c\u043e\u0436\u0435\u0442, \u0430 \u0447\u0442\u043e \u043e\u043f\u0435\u0440\u0430\u0442\u043e\u0440 \u043d\u0435 \u043c\u043e\u0436\u0435\u0442. \u0414\u0430\u043b\u0435\u0435, \u043f\u0435\u0440\u0435\u0439\u0434\u0451\u043c \u043a \u043e\u0431\u0441\u0443\u0436\u0434\u0435\u043d\u0438\u044e \u0432\u043d\u0443\u0442\u0440\u0435\u043d\u043d\u0435\u0433\u043e \u0443\u0441\u0442\u0440\u043e\u0439\u0441\u0442\u0432\u0430 \u043e\u043f\u0435\u0440\u0430\u0442\u043e\u0440\u0430. \u0420\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0438\u043c \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u0443 \u0438 \u0444\u0443\u043d\u043a\u0446\u0438\u043e\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":96966,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-96965","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"Ein](\"\/wp-content\/uploads\/2020\/10\/56e002c7408c4708e39ece867f84171e.jpeg\")
<\/p>\n