Lokal<\/li>\n<\/ul>\n<\/p>\n
Schauen wir uns an, wie sie sich unterscheiden und was sie gemeinsam haben. <\/p>\n
<\/p>\n
Zun\u00e4chst einmal haben wir in allen drei Ans\u00e4tzen Speicher \u2013 das sind lokale Festplatten, die sich auf demselben physikalischen K8s-Knoten befinden. Aber es gibt einige Unterschiede.<\/p>\n
<\/p>\n
<\/p>\n
Beginnen wir mit dem einfachsten, d.h. mit emptyDir. Was ist das praktisch? Hierbei bitten wir in unserer Spezifikation das Containerisierungssystem (meistens Docker), uns Zugriff auf einen Ordner auf der lokalen Festplatte zu gew\u00e4hren.<\/p>\n
<\/p>\n
In der Praxis erstellt Docker irgendwo intern einen tempor\u00e4ren Ordner, nennt ihn mit einem langen Hash und gew\u00e4hrt Zugriff auf ihn. <\/p>\n
<\/p>\n
Wie wird das hinsichtlich der Leistung funktionieren? Es wird mit der Geschwindigkeit der lokalen Festplatte arbeiten, d.h. es gibt vollen Zugriff auf die eigene Festplatte. <\/p>\n
<\/p>\n
Allerdings hat diese L\u00f6sung einen Nachteil. Persistent ist in diesem Fall ziemlich fragw\u00fcrdig. Bei der ersten Bewegung von Docker mit Containern geht Persistent verloren. Wenn Kubernetes aus irgendeinem Grund dieses Pod auf eine andere Festplatte verschieben m\u00f6chte, gehen die Daten verloren. <\/p>\n
<\/p>\n
Dieser Ansatz eignet sich gut f\u00fcr Tests, da er bereits eine akzeptable Geschwindigkeit zeigt, jedoch ist diese Option f\u00fcr etwas Ernsthaftes nicht geeignet. <\/p>\n
<\/p>\n
<\/p>\n
Daher gibt es einen zweiten Ansatz: hostPath. Wenn wir die vorherige Folie und diese betrachten, sehen wir nur einen Unterschied. Der Ordner ist direkt von Docker auf den Kubernetes-Knoten verschoben. Hier ist es etwas einfacher. Wir geben direkt den Pfad im lokalen Dateisystem an, wo wir unsere Daten speichern m\u00f6chten. <\/p>\n
<\/p>\n
Dieser Ansatz hat seine Vorteile. Es handelt sich bereits um ein echtes Persistent, und zwar das 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 der Verwaltung. Unser Kubernetes k\u00f6nnte Pods auf einen anderen physischen Knoten verschieben wollen. Hier kommt DevOps ins Spiel. Er muss dem gesamten System klar machen, dass diese Pods nur auf Knoten verschoben werden k\u00f6nnen, auf denen du \u00fcber diese Pfade etwas montiert hast, und nicht mehr als einen Knoten auf einmal. Das ist ziemlich kompliziert. <\/p>\n
<\/p>\n
Speziell f\u00fcr diese Zwecke haben wir in unserem Unternehmen Vorlagen erstellt, um diese Komplexit\u00e4t zu verbergen. So k\u00f6nnte man einfach sagen: \"Ich m\u00f6chte, dass auf jedem physischen Knoten ein ClickHouse-Instanz und auf diesem bestimmten Pfad besteht.\" <\/p>\n
<\/p>\n
<\/p>\n
Aber dieses Bed\u00fcrfnis haben nicht nur wir, daher verstehen die Herren von Kubernetes auch, dass die Menschen Zugriff auf physische Datentr\u00e4ger w\u00fcnschen, weshalb sie eine dritte Ebene bieten.<\/p>\n
<\/p>\n
Es wird lokal genannt. Der Unterschied zum vorherigen Slide ist praktisch keiner. Eher musste man fr\u00fcher manuell eingreifen, da wir diese Pods nicht von Knoten zu Knoten verschieben konnten, weil sie auf einem bestimmten Pfad mit der lokalen physikalischen Festplatte verbunden sein mussten. Jetzt sind all dieses Wissen im Kubernetes selbst inkapsuliert. So wird die Konfiguration viel einfacher.<\/p>\n
<\/p>\n
<\/p>\n
Wenden wir uns nun unserer praktischen Aufgabe zu. Wir kehren zum YAML-Template zur\u00fcck. Hier haben wir echten Storage. Wir sind zu diesem Thema zur\u00fcckgekehrt. Wir definieren das klassische VolumeClaim-Template wie in k8s und beschreiben, welchen Storage wir ben\u00f6tigen.<\/p>\n
<\/p>\n
Nach diesem Schritt wird k8s Storage anfordern und es uns im StatefulSet zuweisen. Am Ende steht es ClickHouse zur Verf\u00fcgung.<\/p>\n
<\/p>\n
<\/p>\n
Wir hatten so ein Schema. Unser Persistent Storage war rot, was andeutete, dass wir es verbessern 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 echten Persistent Storage, der auf die eine oder andere Weise implementiert ist. Das Schema ist bereits vollst\u00e4ndig funktionsf\u00e4hig. <\/p>\n
<\/p>\n
<\/p>\n
Wir leben weiter. Unser Cluster entwickelt sich. Und Alexey gibt sich M\u00fche und bringt eine neue Version von ClickHouse heraus.<\/p>\n
<\/p>\n
Wir stehen vor einer praktischen Herausforderung: Die neue Version von ClickHouse auf unserem Cluster zu testen. Nat\u00fcrlich m\u00f6chten wir nicht das gesamte Cluster darauf aktualisieren, sondern irgendwo in einer Ecke eine einzelne Replik mit der neuen Version versehen, und vielleicht sogar mit zwei neuen Versionen gleichzeitig, da diese recht h\u00e4ufig ver\u00f6ffentlicht werden. <\/p>\n
<\/p>\n
Was k\u00f6nnen wir dazu sagen?<\/p>\n
<\/p>\n
<\/p>\n
Hier haben wir genau diese M\u00f6glichkeit. Es handelt sich um Pod-Vorlagen. Unser Operator erm\u00f6glicht es uns, einen heterogenen Cluster aufzubauen. Das hei\u00dft, wir k\u00f6nnen konfigurieren, angefangen bei einer Gruppe aller Replikate bis hin zu jeder einzelnen Replik, welche Version von ClickHouse und welche Storage-Version wir m\u00f6chten. Wir k\u00f6nnen den Cluster nach unseren Bed\u00fcrfnissen vollst\u00e4ndig konfigurieren. <\/p>\n
<\/p>\n
<\/p>\n
Ein wenig werden wir jetzt tiefer einsteigen. Zuvor haben wir dar\u00fcber gesprochen, wie der ClickHouse-Operator im Kontext von ClickHouse funktioniert.<\/p>\n
<\/p>\n
Jetzt m\u00f6chte ich ein paar Worte dazu sagen, wie generell jeder Operator funktioniert und wie er mit K8s interagiert.<\/p>\n
<\/p>\n
<\/p>\n
Lassen Sie uns zun\u00e4chst die Interaktion mit K8s betrachten. Was passiert, wenn wir kubectl apply ausf\u00fchren? Unsere Objekte erscheinen \u00fcber die API in etcd. <\/p>\n
<\/p>\n
<\/p>\n
Beispielsweise die grundlegenden Objekte von Kubernetes: Pod, StatefulSet, Service und so weiter. <\/p>\n
<\/p>\n
Zun\u00e4chst passiert jedoch nichts Physisches. Diese Objekte m\u00fcssen im Cluster materialisiert werden. <\/p>\n
<\/p>\n
<\/p>\n
Daf\u00fcr kommt der Controller ins Spiel. Der Controller ist eine spezielle Komponente von k8s, die diese Beschreibungen materialisieren kann. Er wei\u00df, was physisch getan werden muss. Er wei\u00df, wie Container gestartet werden und was konfiguriert werden muss, damit der Server l\u00e4uft. <\/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 wollen eine ClickHouseInstallation erstellen, d. h. ein Objekt vom Typ ClickHouse, um es als Einheit zu verwalten. Momentan gibt es daf\u00fcr jedoch keine M\u00f6glichkeit. <\/p>\n
<\/p>\n
<\/p>\n
Aber k8s hat noch eine weitere n\u00fctzliche Funktion. Wir m\u00f6chten, dass wir irgendwo eine komplexe Entit\u00e4t haben, die aus Pods und StatefulSets unseren Cluster zusammenstellt. <\/p>\n
<\/p>\n
<\/p>\n
Was m\u00fcssen wir daf\u00fcr tun? Zun\u00e4chst 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 Pods und StatefulSets ein benutzerdefiniertes Ressourcen hinzuf\u00fcgen m\u00f6chten, das komplexe Informationen enth\u00e4lt. Das ist die Beschreibung der Datenstruktur. <\/p>\n
<\/p>\n
<\/p>\n
Wir senden ihn ebenfalls \u00fcber kubectl apply dorthin. Kubernetes hat ihn begeistert \u00fcbernommen. <\/p>\n
<\/p>\n
Jetzt haben wir im Speicher die M\u00f6glichkeit, ein benutzerdefiniertes Objekt mit dem Namen ClickHouseInstallation in etcd zu hinterlegen.<\/p>\n
<\/p>\n
Aber bis jetzt wird nichts weiter geschehen. Das hei\u00dft, wenn wir jetzt eine YAML-Datei erstellen, die wir mit der Beschreibung von Shards, Replikaten usw. betrachtet haben, und sagen \u201ekubectl apply\u201c, dann wird Kubernetes sie akzeptieren, in etcd ablegen und sagen: \u201eGut, aber ich wei\u00df nicht, was ich damit machen soll. Ich wei\u00df nicht, wie ich ClickHouseInstallation verwalten soll.\u201c <\/p>\n
<\/p>\n
<\/p>\n
Deshalb brauchen wir jemanden, der Kubernetes hilft, diesen neuen Datentyp zu verwalten. Links haben wir den integrierten Kubernetes-Controller, der mit den Standard-Datentypen arbeitet. Rechts sollte ein benutzerdefinierter Controller erscheinen, der mit benutzerdefinierten Datentypen arbeiten kann. <\/p>\n
<\/p>\n
Und anders genannt wird er Operator. Ich habe ihn hier absichtlich au\u00dferhalb von Kubernetes dargestellt, weil er auch au\u00dferhalb von K8s betrieben werden kann. In der Regel werden die meisten Operatoren nat\u00fcrlich innerhalb von Kubernetes ausgef\u00fchrt, aber nichts hindert ihn daran, drau\u00dfen zu stehen, weshalb er hier speziell nach au\u00dfen ger\u00fcckt ist. <\/p>\n
<\/p>\n
<\/p>\n
Der benutzerdefinierte Controller, auch Operator genannt, interagiert \u00fcber die API mit Kubernetes. Er kann bereits mit der API kommunizieren und wei\u00df, wie er aus einer benutzerdefinierten Ressource ein komplexes Schema erstellen kann, das wir anstreben. Genau das ist die Aufgabe des Operators. <\/p>\n
<\/p>\n
<\/p>\n
Wie funktioniert der Operator? Werfen wir einen Blick auf die rechte Seite, um zu erfahren, wie er das macht. Lassen Sie uns entdecken, wie der Operator alles materialisiert und wie die Interaktion mit K8s anschlie\u00dfend verl\u00e4uft.<\/p>\n
<\/p>\n
<\/p>\n
Der Operator ist ein Programm, das ereignisorientiert arbeitet. Mithilfe der Kubernetes API abonniert der Operator Ereignisse. In der Kubernetes API gibt es Einstiegspunkte, an denen man sich auf Ereignisse abonnieren kann. Wenn sich etwas in K8s \u00e4ndert, sendet Kubernetes Ereignisse an alle Abonnenten, d.h. jeder, der auf diesen API-Punkt abonniert ist, erh\u00e4lt Benachrichtigungen.<\/p>\n
<\/p>\n
Der Operator abonniert Ereignisse und muss darauf reagieren. Seine Aufgabe besteht darin, auf die auftretenden Ereignisse zu reagieren. <\/p>\n
<\/p>\n
<\/p>\n
Ereignisse werden durch bestimmte Updates generiert. Unser YAML-Dokument mit der Beschreibung ClickHouseInstallation wird \u00fcber kubectl apply in etcd \u00fcbertragen. Dort wird ein Ereignis ausgel\u00f6st, das schlie\u00dflich beim ClickHouse-Operator ankommt. Der Operator erh\u00e4lt diese Beschreibung und muss entsprechend handeln. Wenn ein Update f\u00fcr das Objekt ClickHouseInstallation kommt, ist es seine Aufgabe, das Cluster zu aktualisieren. <\/p>\n
<\/p>\n
<\/p>\n
Was macht er? Zun\u00e4chst einmal muss ein Aktionsplan erstellt werden, was wir mit diesem Update tun werden. Updates k\u00f6nnen sehr klein sein, d.h. in YAML geringf\u00fcgig, aber sie k\u00f6nnen erhebliche \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, die Struktur intern zu entwickeln, um Pods und Dienste zu materialisieren, d.h. das zu tun, was seine Hauptaufgabe ist. Es ist wie der Aufbau eines ClickHouse-Clusters in Kubernetes.<\/p>\n
<\/p>\n
<\/p>\n
Nun lassen Sie uns auf eine interessante Sache eingehen. Es handelt sich um die Aufteilung der Verantwortung zwischen Kubernetes und dem Operator, d.h. was Kubernetes tut, was der Operator tut und wie sie miteinander interagieren. <\/p>\n
<\/p>\n
Kubernetes k\u00fcmmert sich um systemrelevante Aufgaben, also um den grundlegenden Satz von Objekten, die als systemisch interpretiert werden k\u00f6nnen. Kubernetes wei\u00df, wie man Pods startet, Container neustartet, Volumes einbindet und mit ConfigMaps umgeht \u2013 alles, was man als systemisch bezeichnen kann. <\/p>\n
<\/p>\n
Operatoren agieren in spezifischen Anwendungsbereichen. Jeder Operator wird f\u00fcr seinen spezifischen Anwendungsbereich erstellt. Wir haben einen f\u00fcr ClickHouse entwickelt.<\/p>\n
<\/p>\n
Der Operator interagiert genau in den Begriffen des Anwendungsbereichs, wie zum Beispiel eine Replik hinzuf\u00fcgen, ein Schema erstellen oder Monitoring einrichten. So entsteht eine klare Trennung.<\/p>\n
<\/p>\n
<\/p>\n
Betrachten wir ein praktisches Beispiel, wie diese Trennung von Verantwortlichkeiten stattfindet, wenn wir die Aktion \u201eReplik hinzuf\u00fcgen\u201c ausf\u00fchren. <\/p>\n
<\/p>\n
Der Operator erh\u00e4lt die Aufgabe \u2013 eine Replik hinzuzuf\u00fcgen. Was macht der Operator? Der Operator berechnet, dass ein neues StatefulSet erstellt werden muss, in dem bestimmte Vorlagen und Volume-Claims beschrieben sind. <\/p>\n
<\/p>\n
<\/p>\n
Er bereitet alles vor und leitet es an K8s weiter. Er erkl\u00e4rt, dass er eine ConfigMap, ein StatefulSet und ein Volume ben\u00f6tigt. Kubernetes f\u00fchrt dann die erforderlichen Schritte aus. Es materialisiert die grundlegenden Einheiten, mit denen es arbeitet. <\/p>\n
<\/p>\n
<\/p>\n
Und hier kommt erneut der ClickHouse-Operator ins Spiel. Er verf\u00fcgt bereits \u00fcber ein physisches Pod, auf dem etwas durchgef\u00fchrt werden kann. Der ClickHouse-Operator arbeitet erneut in Fachbegriffen. Das hei\u00dft, um eine Replik in den Cluster einzuf\u00fcgen, muss zun\u00e4chst das Datenschema, das in diesem Cluster vorhanden ist, konfiguriert werden. Zweitens muss diese Replik in die \u00dcberwachung aufgenommen werden, damit sie gut nachvollziehbar ist. Das richtet bereits der Operator ein. <\/p>\n
<\/p>\n
<\/p>\n
Erst danach kommt der ClickHouse selbst ins Spiel, also eine weitere hochrangige Entit\u00e4t. Das ist die Datenbank. Sie hat ihre eigene Instanz und eine konfigurierte Replik, die bereit ist, in den Cluster aufgenommen zu werden.<\/p>\n
<\/p>\n
Das ergibt eine lange Kette von Ausf\u00fchrungen und eine Verantwortungsteilung bei der Hinzuf\u00fcgung einer Replik.<\/p>\n
<\/p>\n
<\/p>\n
Wir setzen unsere praktischen Aufgaben fort. Wenn der Cluster bereits besteht, kann die Konfiguration migriert werden. <\/p>\n
<\/p>\n
<\/p>\n
Wir haben es so eingerichtet, dass bestehende XML, das ClickHouse versteht, nahtlos durchgereicht werden kann.<\/p>\n
<\/p>\n
<\/p>\n
Es ist m\u00f6glich, ClickHouse fein abzustimmen. Wie gerade gesagt, ist zoned deployment genau das, wor\u00fcber ich bei der Erkl\u00e4rung von hostPath und Local Storage gesprochen habe. Es geht darum, zoned deployment richtig umzusetzen.<\/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, muss das Monitoring regelm\u00e4\u00dfig angepasst werden. <\/p>\n
<\/p>\n
Lassen Sie uns das Schema betrachten. Die gr\u00fcnen Pfeile haben wir bereits besprochen. Nun sehen wir uns die roten Pfeile an. So m\u00f6chten wir unser Cluster \u00fcberwachen. Wie die Metriken aus dem ClickHouse-Cluster in Prometheus und dann in Grafana gelangen.<\/p>\n
<\/p>\n
<\/p>\n
Was ist die Herausforderung beim Monitoring? Warum wird es als eine Art Errungenschaft bezeichnet? Die Schwierigkeit liegt in der Dynamik. Wenn wir einen statischen Cluster haben, kann das Monitoring einmalig eingerichtet werden und man muss sich nicht weiter darum k\u00fcmmern.<\/p>\n
<\/p>\n
Aber wenn wir viele Cluster haben oder sich st\u00e4ndig etwas \u00e4ndert, ist der Prozess dynamisch. Sich st\u00e4ndig um die Neuanpassung des Monitorings zu k\u00fcmmern, verbraucht Ressourcen und Zeit \u2013 einfach gesagt, es ist sogar m\u00fchsam. Das muss automatisiert werden. Die Komplexit\u00e4t liegt also in der Dynamik des Prozesses. Und der Operator automatisiert das sehr gut. <\/p>\n
<\/p>\n
<\/p>\n
Wie hat sich unser Cluster entwickelt? Zu Beginn sah es so aus.<\/p>\n
<\/p>\n
<\/p>\n
Dann sah es so aus.<\/p>\n
<\/p>\n
<\/p>\n
Am Ende hat es sich zu diesem entwickelt. <\/p>\n
<\/p>\n
Das Monitoring wird automatisch vom Operator durchgef\u00fchrt. Eine zentrale Anlaufstelle. <\/p>\n
<\/p>\n
<\/p>\n
Wir werfen nur einen Blick auf das Grafana-Dashboard, um zu sehen, wie lebhaft das Innenleben unseres Clusters ist. <\/p>\n
<\/p>\n
\u00dcbrigens wird das Grafana-Dashboard ebenfalls mit unserem Operator in den Quellcodes bereitgestellt. Man kann es einfach anschlie\u00dfen und nutzen. Dieses Screenshot haben unsere DevOps zur Verf\u00fcgung gestellt.<\/p>\n
<\/p>\n
<\/p>\n
Wohin m\u00f6chten wir als N\u00e4chstes gehen? Das ist:<\/p>\n
<\/p>\n
\nDie Automatisierung der Testverfahren vorantreiben. Die Hauptaufgabe besteht in der automatisierten Pr\u00fcfung neuer Versionen. <\/li>\n Au\u00dferdem m\u00f6chten wir die Integration mit ZooKeeper automatisieren. Geplant ist, sich mit dem ZooKeeper-Operator zu integrieren. Das bedeutet, dass ein Operator f\u00fcr ZooKeeper geschrieben wurde, und es w\u00e4re nur logisch, dass zwei Operatoren zur Schaffung einer benutzerfreundlicheren L\u00f6sung zusammenarbeiten. <\/li>\n Wir m\u00f6chten komplexere Lebenszeichenpr\u00fcfungen implementieren. <\/li>\n Ich habe in Gr\u00fcn hervorgehoben, dass wir beim Erben von Templates auf dem richtigen Weg sind \u2013 FERTIG, d. h. mit der n\u00e4chsten Ver\u00f6ffentlichung des Operators wird das Template-Erben verf\u00fcgbar sein. Dies ist ein leistungsstarkes Werkzeug, das es erm\u00f6glicht, komplexe Konfigurationen aus verschiedenen Teilen zusammenzustellen. <\/li>\n Und wir streben die Automatisierung komplexer Aufgaben an. Eine der Hauptaufgaben ist das Re-Sharding. <\/li>\n<\/ul>\n<\/p>\n
<\/p>\n
Lassen Sie uns eine Zwischenbilanz ziehen. <\/p>\n
<\/p>\n
<\/p>\n
Was erhalten wir am Ende? Und ist es sinnvoll oder nicht? Sollte man \u00fcberhaupt versuchen, eine Datenbank in Kubernetes zu integrieren und den Operator insgesamt sowie den Alitnity-Operator im Besonderen anzuwenden?<\/p>\n
<\/p>\n
Am Ende erhalten wir:<\/p>\n
<\/p>\n
\nEine signifikante Vereinfachung und Automatisierung der Konfiguration, Bereitstellung und Wartung. <\/li>\n Sofort integriertes Monitoring. <\/li>\n Und sofort einsatzbereite, kodifizierte Vorlagen f\u00fcr komplexe Situationen. Aktionen wie das Hinzuf\u00fcgen einer Replik sind nicht mehr manuell erforderlich. Das \u00fcbernimmt der Operator. <\/li>\n<\/ul>\n<\/p>\n
<\/p>\n
Bleibt nur noch die letzte Frage. Wir haben bereits eine Datenbank in Kubernetes, Virtualisierung. Wie steht es um die Leistung dieser L\u00f6sung, insbesondere in Anbetracht der Tatsache, dass ClickHouse auf Leistung optimiert ist?<\/p>\n
<\/p>\n
Die Antwort \u2013 alles in Ordnung! Ich werde nicht ins Detail gehen, das ist ein Thema f\u00fcr einen separaten Vortrag. <\/p>\n
<\/p>\n
<\/p>\n
Aber es gibt ein Projekt namens TSBS. Was ist sein Hauptziel? Es ist ein Test f\u00fcr Datenbanken auf Leistung. Es versucht, \u00c4pfel mit \u00c4pfeln und Birnen mit Birnen zu vergleichen. <\/p>\n
<\/p>\n
Wie funktioniert es? Es wird ein Datensatz generiert. Dieser Datensatz wird dann mit dem gleichen Test-Set auf verschiedenen Datenbanken durchlaufen. Jede Datenbank l\u00f6st eine Aufgabe auf ihre eigene Weise. Anschlie\u00dfend k\u00f6nnen die Ergebnisse verglichen werden. <\/p>\n
<\/p>\n
Es unterst\u00fctzt bereits eine Vielzahl von Datenbanken. Ich habe drei Hauptdatenbanken hervorgehoben. Diese 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, und zwar mit RedShift. Der Vergleich fand bei Amazon statt. ClickHouse \u00fcbertrifft auch in dieser Hinsicht alle anderen. <\/p>\n
<\/p>\n
<\/p>\n
Welche Schlussfolgerungen kann ich aus dem, was ich erz\u00e4hlt habe, ziehen?<\/p>\n
<\/p>\n
\nDB in Kubernetes ist m\u00f6glich. Wahrscheinlich kann man jede Datenbank verwenden, aber insgesamt sieht es so aus, als w\u00e4re es machbar. ClickHouse kann definitiv im Kubernetes-Umfeld unseres Operators betrieben werden. <\/li>\n Der Operator hilft dabei, Prozesse zu automatisieren und vereinfacht das Leben erheblich.<\/li>\n Die Leistung ist angemessen.<\/li>\n Und wir glauben, dass es sinnvoll ist, dies zu verwenden. <\/li>\n<\/ul>\n<\/p>\n
Open Source \u2013 schlie\u00dfen Sie sich uns an!<\/p>\n
<\/p>\n
Wie bereits erw\u00e4hnt, ist der Operator ein vollst\u00e4ndig Open-Source-Produkt, daher w\u00e4re es gro\u00dfartig, wenn m\u00f6glichst viele Menschen ihn nutzen w\u00fcrden. Schlie\u00dfen Sie sich uns an! Wir freuen uns auf Sie alle!<\/p>\n
<\/p>\n
Vielen Dank an alle!<\/p>\n
<\/p>\n
Fragen<\/p>\n
<\/p>\n
<\/p>\n
Vielen Dank f\u00fcr den Vortrag! Ich hei\u00dfe Anton und komme von SEMrush. Mich interessiert das Thema Logging. \u00dcber Monitoring h\u00f6rt man viel, aber \u00fcber Logging, wenn man den gesamten Cluster betrachtet, nicht so viel. Bei uns zum Beispiel haben wir einen Cluster auf Hardware hochgezogen. Wir nutzen zentrales Logging und sammeln die Daten mit Standardmitteln in einem gemeinsamen Repository. Von dort aus extrahieren wir die f\u00fcr uns interessanten Daten.<\/em> <\/p>\n<\/p>\n
Eine gute Frage, das hei\u00dft, Logging steht auf der To-Do-Liste. Unser Operator automatisiert das derzeit noch nicht. Das Projekt entwickelt sich noch, es ist noch recht jung. Wir erkennen die Notwendigkeit des Loggings. Dies ist ebenfalls ein sehr wichtiges Thema, das wahrscheinlich nicht weniger wichtig ist als Monitoring. Aber zuallererst stand Monitoring auf der Implementierungsliste. Logging wird kommen. Wir versuchen nat\u00fcrlich, alle Aspekte der Betriebsf\u00fchrung des Clusters zu automatisieren. Daher ist die Antwort: Leider kann der Operator dies aktuell nicht, aber es steht auf unserer Liste, wir werden das umsetzen. Wenn Sie Interesse haben, sich anzuschlie\u00dfen, dann senden Sie bitte einen Pull Request.<\/p>\n
<\/p>\n
Hallo! Vielen Dank f\u00fcr den Bericht! Ich habe eine Standardfrage zu den Persistent Volumes. Wie bestimmt der Operator, auf welchem Knoten ein bestimmtes Laufwerk oder ein Verzeichnis gemountet ist, wenn wir mit diesem Operator eine Konfiguration erstellen? M\u00fcssen wir ihm im Voraus erkl\u00e4ren, dass unser ClickHouse bitte auf den Knoten platziert werden soll, auf denen sich das Laufwerk befindet?<\/em><\/p>\n<\/p>\n
Soweit ich das verstehe, ist diese Frage eine Fortsetzung des lokalen Speichers, insbesondere des Teils \u00fcber hostPath. Es geht darum, dem gesamten System zu erkl\u00e4ren, dass der Pod genau auf diesem Knoten ausgef\u00fchrt werden soll, auf dem wir ein physisch verbundenes Laufwerk haben, das an einem bestimmten Pfad gemountet ist. Das ist ein ganzes Thema, das ich nur sehr oberfl\u00e4chlich angeschnitten habe, da die Antwort recht umfangreich ist. <\/p>\n
<\/p>\n
Kurz gesagt, das sieht so aus: Wir m\u00fcssen nat\u00fcrlich die Bereitstellung dieser Volumes vornehmen. Momentan gibt es im lokalen Speicher keine dynamische Bereitstellung, daher m\u00fcssen die DevOps die Festplatten, also diese Volumes, manuell partitionieren. Sie m\u00fcssen Kubernetes erkl\u00e4ren, dass es Persistent Volumes einer bestimmten Klasse geben wird, die sich auf bestimmten Knoten befinden. Anschlie\u00dfend muss Kubernetes erkl\u00e4rt werden, dass Pods, die eine bestimmte Klasse von lokalem Speicher ben\u00f6tigen, nur auf solchen Knoten geplant werden sollen. F\u00fcr diese Zwecke erm\u00f6glicht der Operator, einen bestimmten Label und eine Instanz pro Host zuzuweisen. Dadurch werden die Pods von Kubernetes nur auf Knoten gestartet, die den Anforderungen der Labels entsprechen, einfach gesagt. Die Administratoren weisen Labels zu und f\u00fchren die Bereitstellung der Festplatten manuell durch. So wird die Skalierung erm\u00f6glicht.<\/p>\n
<\/p>\n
Der dritte Ansatz mit lokalem Speicher erleichtert dies ein wenig. Wie ich bereits betont habe, ist es eine m\u00fchsame Aufgabe, die jedoch letztendlich dazu beitr\u00e4gt, die maximale Leistung zu erzielen.<\/p>\n
<\/p>\n
Ich habe eine zweite Frage dazu. Kubernetes wurde so konzipiert, dass es uns egal ist, ob wir einen Knoten verlieren oder nicht. Was sollten wir in diesem Fall tun, wenn wir den Knoten verloren haben, auf dem unser Shard l\u00e4uft?<\/em><\/p>\n<\/p>\n
Ja, Kubernetes wurde urspr\u00fcnglich so positioniert, dass unsere Pods wie Vieh behandelt werden, aber hier wird jede Festplatte wie ein Haustier betrachtet. Es gibt das Problem, dass wir diese nicht einfach wegwerfen k\u00f6nnen. Die Entwicklung von Kubernetes geht dahin, dass wir nicht vollst\u00e4ndig philosophisch damit umgehen k\u00f6nnen, als w\u00e4ren es Ressourcen, die wir jederzeit entsorgen k\u00f6nnen.<\/p>\n
<\/p>\n
Nun zur praktischen Frage. Was tun, wenn ein Knoten verloren geht, auf dem die Festplatte war? Hier wird die Aufgabe auf einer h\u00f6heren Ebene gel\u00f6st. Bei ClickHouse haben wir Replikate, die auf einer h\u00f6heren Ebene arbeiten, also auf der Ebene von ClickHouse.<\/p>\n
<\/p>\n
Wie sieht dieDisposition aus? DevOps ist daf\u00fcr verantwortlich, dass keine Daten verloren gehen. Er muss die Replikation richtig einstellen und darauf achten, dass die Replikation erfolgt. In der Replikation auf der Ebene von ClickHouse sollten die Daten dupliziert sein. Das ist nicht die Aufgabe des Betreibers. Und nicht die Aufgabe, die Kubernetes selbst l\u00f6st. Das geschieht auf der Ebene von ClickHouse.<\/p>\n
<\/p>\n
Was tun, wenn Ihr Hardware-Knoten ausf\u00e4llt? In diesem Fall m\u00fcssen Sie einen zweiten Knoten aufbauen, richtig die Festplatte provisionieren und Labels anbringen. Danach erf\u00fcllt dieser Knoten die Anforderungen, sodass Kubernetes ein Pod-Instance darauf starten kann. Kubernetes wird ihn starten. Ihnen fehlen ja Pod-Kapazit\u00e4ten, um die definierte Anzahl zu erreichen. Der Knoten wird den Zyklus durchlaufen, den ich gezeigt habe. Auf der obersten Ebene wird ClickHouse erkennen, dass ein Replikat hinzugef\u00fcgt wurde, das noch leer ist, und die Daten beginnen m\u00fcssen, darauf \u00fcbertragen zu werden. Dieser Prozess ist noch unzureichend automatisiert. <\/p>\n
<\/p>\n
Danke f\u00fcr den Vortrag! Wenn inkonsistente Ereignisse eintreten, der Operator abst\u00fcrzt und neu gestartet wird, w\u00e4hrend in diesem Moment Ereignisse eintreffen, wie gehen Sie damit um?<\/em><\/p>\n<\/p>\n
Was passiert, wenn der Operator abgest\u00fcrzt ist und neu gestartet wurde? <\/p>\n
<\/p>\n
Ja. Und in diesem Moment sind Ereignisse eingetroffen.<\/em> <\/p>\n<\/p>\n
Die Aufgabe, was in diesem Fall zu tun ist, wird teilweise zwischen dem Operator und Kubernetes aufgeteilt. Kubernetes hat die F\u00e4higkeit, das aufgetretene Ereignis erneut abzuspielen. Es spielt es erneut ab. Die Aufgabe des Operators besteht jedoch darin, sicherzustellen, dass, wenn das Ereignisprotokoll wiederholt wird, diese Ereignisse idempotent sind. Und dass ein erneutes Eintreten des gleichen Ereignisses unser System nicht st\u00f6rt. Und unser Operator bew\u00e4ltigt diese Aufgabe. <\/p>\n
<\/p>\n
Guten Tag! Vielen Dank f\u00fcr den Vortrag! Dmitry Zavyalov, Unternehmen<\/em> Smedenova. Ist eine Anpassung des Operators mit haproxy geplant? Gibt es Interesse an einem anderen Load Balancer neben dem Standard, der intelligent ist und erkennt, dass dort tats\u00e4chlich ClickHouse l\u00e4uft.<\/em> <\/p>\n<\/p>\n
Sprechen Sie von Ingress?<\/p>\n
<\/p>\n
Ja, Ingress durch haproxy ersetzen. In haproxy kann die Cluster-Topologie angegeben werden, wo sich die Replikate befinden.<\/em><\/p>\n<\/p>\n
Bisher haben wir dar\u00fcber noch nicht nachgedacht. Wenn Sie es ben\u00f6tigen und erkl\u00e4ren k\u00f6nnen, warum es notwendig ist, k\u00f6nnten wir es umsetzen, insbesondere wenn Sie teilnehmen m\u00f6chten. Wir w\u00fcrden das gerne in Betracht ziehen. Kurz gesagt \u2013 nein, derzeit haben wir diese Funktionalit\u00e4t nicht. Vielen Dank f\u00fcr den Hinweis, wir werden uns damit besch\u00e4ftigen. Und wenn Sie auch den Anwendungsfall erkl\u00e4ren und z.B. Issues auf GitHub erstellen, w\u00e4re das gro\u00dfartig.<\/p>\n
<\/p>\n
Ist bereits vorhanden.<\/em><\/p>\n<\/p>\n
Gut. Wir sind offen f\u00fcr alle Vorschl\u00e4ge. Und haproxy wird auf die To-Do-Liste gesetzt. Die To-Do-Liste w\u00e4chst im Moment, statt sich zu verringern. Aber das ist gut, das zeigt, dass das Produkt nachgefragt wird.<\/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
![\"Operator](\"\/wp-content\/uploads\/2020\/10\/56e002c7408c4708e39ece867f84171e.jpeg\")
<\/p>\n