Ende letzten Jahres fand eine weitere Live-Übertragung der russischen PostgreSQL-Community
#RuPostgres statt , bei der der Mitbegründer Nikolai Samokhvalov im Rahmen von Kubernetes mit dem technischen Direktor von Flanta, Dmitry Stolyarov, über dieses DBMS sprach.
Wir veröffentlichen eine Abschrift des Hauptteils dieser Diskussion. Ein vollständiges Video wurde
auf dem YouTube-Kanal der Community veröffentlicht :
Datenbanken und Kubernetes
NS : Wir werden heute nicht über VACUUM und CHECKPOINTs sprechen. Wir wollen über Kubernetes sprechen. Ich weiß, dass Sie langjährige Erfahrung haben. Ich habe mir deine Videos angesehen und sogar einige davon angesehen ... Lass uns gleich zum Steinbruch gehen: Warum ist Postgres oder MySQL überhaupt in K8s?DS : Es gibt keine einzige Antwort auf diese Frage und es kann auch nicht sein. Aber im Allgemeinen ist es Einfachheit und Bequemlichkeit ... Potenzial. Schließlich möchte jeder Managed Services.
NS : RDS nur zu Hause mögen?DS : Ja, um RDS zu mögen, nur überall.
NS : "Überall" ist ein guter Punkt. In großen Unternehmen befindet sich alles an verschiedenen Orten. Und warum dann, wenn dies ein großes Unternehmen ist, keine fertige Lösung nehmen? Zum Beispiel hat Nutanix eigene Entwicklungen, andere Unternehmen (VMware ...) haben das gleiche "RDS, nur zu Hause".DS : Es handelt sich jedoch um eine einzelne Implementierung, die nur unter bestimmten Bedingungen funktioniert. Und wenn wir über Kubernetes sprechen, dann gibt es eine Vielzahl von Infrastrukturen (die in K8s vorhanden sein können). Dies ist im Wesentlichen der Standard für die API zur Cloud ...
NS : Es ist auch kostenlos!DS : Das ist nicht so wichtig. Kostenlos ist für ein sehr großes Marktsegment nicht wichtig. Eine andere Sache ist wichtig ... Sie erinnern sich wahrscheinlich an den Bericht "
Datenbanken und Kubernetes "?
NS : Ja.DS : Mir wurde klar, dass er sehr vieldeutig wahrgenommen wurde. Einige Leute dachten, dass ich sagte: "Leute, alle Datenbanken gingen an Kubernetes!", Während andere entschieden, dass sie alle schreckliche Fahrräder waren. Und ich wollte noch etwas ganz anderes sagen: „Schau, was passiert, was sind die Probleme und wie können sie gelöst werden. Gehen jetzt Stützpunkte in Kubernetes? Produktion? Nun, nur wenn du es liebst ... bestimmte Dinge zu tun. Aber für Entwickler kann ich sagen, dass ich es empfehle. Für Entwickler ist das dynamische Erstellen / Löschen von Umgebungen sehr wichtig. “
NS: Mit dev meinen Sie alle Umgebungen, die nicht prod sind? Inszenierung, QA ...DS : Wenn wir über Perf-Stände sprechen, dann wahrscheinlich nicht schon, weil die Anforderungen dort spezifisch sind. Wenn es sich um spezielle Fälle handelt, in denen Staging eine sehr große Datenbank benötigt, dann wahrscheinlich auch nicht ... Wenn dies eine statische, langlebige Umgebung ist, was ist dann der Vorteil, wenn sich die Basis in K8s befindet?
NS : Keine. Aber wo sehen wir statische Umgebungen? Die statische Umgebung ist morgen veraltet.DS : Staging kann statisch sein. Wir haben Kunden ...
NS : Ja, das habe ich auch. Das große Problem ist, wenn Sie eine Basis von 10 TB und Staging haben - 200 GB ...DS : Ich habe einen sehr coolen Fall! Bei der Inszenierung gibt es eine prod'ovy Basis, in der Änderungen vorgenommen werden. Und ein Knopf steht zur Verfügung: "Roll out to Production". Diese Änderungen - Deltas - werden in der Produktion hinzugefügt (anscheinend werden sie nur durch APIs synchronisiert). Dies ist eine sehr exotische Option.
NS : Ich habe Startups im Tal gesehen, die noch in RDS oder sogar in Heroku sitzen - das sind Geschichten von vor zwei bis drei Jahren - und sie haben den Dump auf ihren Laptop heruntergeladen. Weil die Basis bisher nur 80 GB hat und es einen Platz auf dem Laptop gibt. Dann kaufen sie für jeden Platten, damit sie 3 Basen haben, damit sie unterschiedliche Entwicklungen durchführen können. Das passiert auch. Ich habe auch gesehen, dass sie keine Angst haben, Produkte in die Inszenierung zu kopieren - es hängt sehr stark von der Firma ab. Aber er sah, dass sie große Angst hatten und oft nicht genug Zeit und Hände hatten. Bevor wir jedoch zu diesem Thema übergehen, möchte ich etwas über Kubernetes erfahren. Ich verstehe richtig, dass in prod'e bisher niemand?DS : Wir haben kleine Basen in prod. Wir sprechen von Dutzenden von Gigabyte und nicht kritischen Diensten, für die es zu träge war, Replikate zu erstellen (und es gibt keinen solchen Bedarf). Und sofern es unter Kubernetes einen normalen Speicher gibt. Diese Datenbank arbeitete in einer virtuellen Maschine - bedingt in VMware, zusätzlich zum Speicher. Wir haben es in
PV gelegt und jetzt können wir es von Auto zu Auto übertragen.
NS : Basen dieser Größe, bis zu 100 GB, auf guten Festplatten und mit einem guten Netzwerk können in wenigen Minuten bereitgestellt werden, oder? Eine Geschwindigkeit von 1 GB pro Sekunde ist nicht länger exotisch.DS : Ja, für eine lineare Operation ist dies kein Problem.
NS : Okay, wir sollten nur über Produkte nachdenken. Und wenn wir Kubernetes für Non-Prod-Umgebungen in Betracht ziehen - wie geht das? Ich sehe, dass sie in Zalando einen Operator herstellen , in Crunchy sägen sie , es gibt einige andere Optionen. Und da ist OnGres - das ist unser guter Freund Alvaro aus Spanien: Sie sind im Grunde nicht nur ein Operator , sondern eine ganze Distribution ( StackGres ), in der sie neben Postgres selbst auch beschlossen haben, das Backup, den Envoy-Proxy ...DS : Gesandter für was? Postgres Verkehrsbilanzierung genau?
NS : Ja. Das heißt, sie sehen es als: Wenn Sie die Linux-Distribution und den Kernel nehmen, dann ist der übliche PostgreSQL-Kernel und sie wollen eine Distribution erstellen, die Cloud-freundlich ist und auf Kubernetes läuft. Sie docken Komponenten (Backups usw.) an und debuggen, damit sie gut funktionieren.DS : Sehr cool! Im Wesentlichen ist es eine Software, mit der Sie Ihre verwalteten Postgres erstellen können.
NS : Linux-Distributionen haben ewige Probleme: Wie werden Treiber erstellt, damit die gesamte Hardware unterstützt wird? Und sie haben die Idee, bei Kubernetes zu arbeiten. Ich weiß, dass wir im Zalando-Operator kürzlich die Augäpfel auf AWS gesehen haben und das ist nicht sehr gut. Es sollte keine Bindung an eine bestimmte Infrastruktur geben - worum geht es dann?DS : Ich weiß nicht, in welcher konkreten Situation Zalando involviert war, aber in Kubernetes wird der Speicher nun so erstellt, dass es unmöglich ist, ein Festplatten-Backup auf generische Weise zu entfernen. Kürzlich hat der Standard - in der neuesten Version
der CSI-Spezifikation - die Möglichkeit von Snapshots geschaffen, aber wo ist er implementiert? Ehrlich gesagt, es ist immer noch so rau ... Wir testen CSI auf AWS, GCE, Azure, vSphere, aber wir beginnen, es ein wenig zu verwenden, da Sie sehen, dass es noch nicht fertig ist.
NS : Deshalb muss man sich manchmal an die Infrastruktur binden. Ich denke, dies ist noch ein frühes Stadium - Wachstumsprobleme. Frage: Was würden Sie Anfängern empfehlen, die PgSQL in K8s ausprobieren möchten? Welcher Betreiber vielleicht?DS : Das Problem ist, dass Postgres für uns 3% beträgt. Wir haben immer noch eine sehr große Liste verschiedener Software in Kubernetes, ich werde nicht einmal alles auflisten. Zum Beispiel Elasticsearch. Es gibt viele Betreiber: Einige entwickeln sich aktiv, andere nicht. Für uns selbst haben wir Anforderungen gestellt, die im Betreiber liegen sollten, damit wir ihn ernst nehmen. Der Operator ist speziell für Kubernetes - nicht der "Operator, der unter Amazon-Bedingungen etwas unternimmt ..." Tatsächlich verwenden wir einen einzigen Operator (= für fast alle Clients) -
für Redis (wir werden in Kürze einen Artikel darüber veröffentlichen) .
NS : Aber auch für MySQL? Ich weiß, dass Percona ... da sie jetzt in MySQL, MongoDB und Postgres involviert sind, müssen sie eine Art universelles Problem beheben: für alle Datenbanken, für alle Cloud-Anbieter.DS : Wir hatten keine Zeit, uns die Anweisungen für MySQL anzuschauen. Für uns steht dies derzeit nicht im Vordergrund. MySQL funktioniert gut in Standalone. Warum ein Operator, wenn Sie nur die Datenbank starten können? Sie können den Docker-Container mit Postrges oder auf einfache Weise starten.
NS : Das war auch eine Frage. Kein Operator?DS : Ja, 100% von uns haben PostgreSQL ohne Operator. So weit so. Wir verwenden den Operator aktiv für Prometheus, für Redis. Wir haben vor, einen Operator für Elasticsearch zu finden - er brennt am meisten, weil wir ihn in Kubernetes in 100% der Fälle installieren wollen. So wie wir sicherstellen wollen, dass MongoDB immer auch in Kubernetes installiert ist. Bestimmte Merkzettel erscheinen hier - es besteht das Gefühl, dass in diesen Fällen etwas getan werden kann. Und über Postgres haben wir nicht mal geschaut. Natürlich wissen wir über die Existenz verschiedener Optionen Bescheid, aber in der Tat haben wir Standalone.
Testen der Datenbank in Kubernetes
NS : Kommen wir zum Thema Testen. So rollen Sie Änderungen in der Datenbank aus - aus Sicht von DevOps. Es gibt Microservices, viele Datenbanken, die ganze Zeit ändert sich irgendwo etwas. So stellen Sie sicher, dass die normale CI / CD von der DBMS-Position aus in Ordnung ist. Was ist dein Ansatz?DS : Es kann keine Antwort geben. Es gibt verschiedene Möglichkeiten. Der erste ist die Größe der Basis, die wir ausrollen möchten. Sie selbst haben erwähnt, dass Unternehmen eine andere Einstellung dazu haben, eine Kopie des Produkts auf der Basis von Entwickler und Bühne zu haben.
NS : Und was die DSGVO angeht, denke ich, dass sie immer ordentlicher werden ... Ich kann sagen, dass sie in Europa bereits angefangen haben, in Ordnung zu kommen.DS : Aber Sie können oft Software schreiben, die die Produktion auslagert und verschleiert. Es stellt sich heraus, prod'ovye Daten (Snapshot, Dump, Binärkopie ...), aber sie sind anonym. Stattdessen kann es Generierungsskripte geben: Fixtures oder nur ein Skript, das eine große Datenbank generiert. Das Problem ist, was: Wie lange dauert es, bis das Basisimage erstellt ist? Und wie viel Zeit ist für die Bereitstellung in der richtigen Umgebung erforderlich?
Wir sind zum Schema gekommen: Wenn der Client einen Fixture-Datensatz (minimale Version der Datenbank) hat, dann verwenden wir diese standardmäßig. Wenn es sich um Überprüfungsumgebungen handelt, haben wir beim Erstellen einer Verzweigung eine Anwendungsinstanz implementiert - wir rollen dort eine kleine Datenbank aus. Aber die
Option hat sich als gut erwiesen, wenn wir den Dump einmal täglich (nachts) aus der Produktion entfernen und anhand dieser geladenen Daten einen Docker-Container mit PostgreSQL und MySQL sammeln. Wenn Sie die Basis 50-mal von diesem Image aus bereitstellen müssen, ist dies recht einfach und schnell.
NS : Einfaches Kopieren?DS : Daten werden direkt im Docker-Image gespeichert. Das heißt Wir haben ein fertiges Image, wenn auch 100 GB. Dank der Ebenen in Docker können wir dieses Image so oft wie nötig schnell bereitstellen. Die Methode ist dumm, aber sie funktioniert ziemlich gut.
NS : Außerdem ändert es sich beim Testen direkt im Docker, oder? Copy-on-Write in Docker - werfen Sie es weg und gehen Sie noch einmal, alles ist in Ordnung. Klasse! Und Sie verwenden es bereits mit Macht und Hauptsache?DS : Für eine lange Zeit.
NS : Wir machen sehr ähnliche Dinge. Nur verwenden wir nicht Dockers Copy-on-Write, sondern einige mehr.JS : Er ist nicht generisch. Und Docker'ny arbeitet überall.
NS : Theoretisch ja. Wir haben dort aber auch Module, Sie können verschiedene Module erstellen und mit verschiedenen Dateisystemen arbeiten. Was für ein moment Von Postgres aus sehen wir das alles anders. Jetzt schaute ich von der Seite von Docker und sah, dass alles für Sie funktioniert. Aber wenn die Datenbank riesig ist, zum Beispiel 1 TB, dann ist das alles lang: sowohl Operationen nachts als auch alles in Docker stopfen ... Und wenn 5 TB in Docker stopfen ... Oder ist alles normal?DS : Welchen Unterschied macht es: Es sind Blobs, nur Bits und Bytes.
NS : Der Unterschied ist: Tun Sie dies durch Dump und Restore?DS :
Überhaupt nicht notwendig. Die Methoden zum Generieren dieses Bildes können unterschiedlich sein.
NS : Für einige Kunden haben wir es so gestaltet, dass wir nicht regelmäßig ein Basisimage generieren, sondern es ständig auf dem neuesten Stand halten. Es handelt sich im Wesentlichen um eine Replik, die Daten werden jedoch nicht direkt vom Master, sondern über das Archiv empfangen. Im Binärarchiv, in dem die WALs jeden Tag gerollt werden, werden auch Backups entfernt ... Diese WALs fliegen dann - mit einer leichten Verzögerung (im wahrsten Sinne des Wortes 1-2 Sekunden) - zum Basisimage. Wir klonen es auf irgendeine Weise - jetzt haben wir standardmäßig ZFS.DS : Mit ZFS sind Sie jedoch auf einen Knoten beschränkt.
NS : Ja. ZFS hat aber auch ein magisches Send : Sie können damit einen Schnappschuss senden und sogar (ich habe es noch nicht wirklich getestet, aber ...) ein Delta zwischen zwei PGDATA . Tatsächlich haben wir ein anderes Werkzeug, das wir für solche Aufgaben nicht besonders in Betracht gezogen haben. In PostgreSQL gibt es pg_rewind , das als "intelligentes" rsync funktioniert und viele Dinge überspringt, die Sie nicht beobachten müssen, da sich dort mit Sicherheit nichts geändert hat. Wir können eine schnelle Synchronisation zwischen den beiden Servern durchführen und genauso zurückspulen.Also versuchen wir, mehr DBA'noy als bisher, ein Tool zu entwickeln, mit dem Sie das Gleiche tun können, was Sie gesagt haben: Wir haben eine Basis, aber wir möchten etwas 50 Mal testen, fast zur gleichen Zeit.DS : 50-mal bedeutet, dass Sie 50 Spot-Instanzen bestellen müssen.
NS : Nein, wir machen alles auf einer Maschine.DS : Aber wie können Sie 50-mal bereitstellen, wenn diese eine Basis beispielsweise ein Terabyte ist? Benötigt sie höchstwahrscheinlich bedingt 256 GB RAM?
NS : Ja, manchmal wird viel Speicher benötigt - das ist normal. Aber ein solches Beispiel aus dem Leben. Die Produktionsmaschine hat 96 Kerne und 600 GB. Gleichzeitig werden 32 Kerne für die Datenbank verwendet (manchmal werden jetzt sogar 16 Kerne verwendet) und 100-120 GB Arbeitsspeicher.DS : Und 50 Exemplare kommen da rein?
NS : Also gibt es nur eine Kopie, dann funktioniert Copy-on-Write (ZFS'ny) ... ich erzähle dir mehr.Zum Beispiel haben wir eine Basis von 10 TB. Sie machten eine Scheibe dafür, ZFS drückte immer noch seine prozentuale Größe um 30-40. Da wir keine Lasttests durchführen, spielt die genaue Reaktionszeit für uns keine Rolle: Lassen Sie es bis zu 2-mal langsamer sein - das ist in Ordnung.Wir ermöglichen Programmierern, QA, DBA usw. Führen Sie Tests in 1-2 Threads durch. Zum Beispiel können sie eine Art Migration starten. Es werden nicht 10 Kerne gleichzeitig benötigt - es wird 1 Postgres-Backend und 1 Kern benötigt. Die Migration wird gestartet - möglicherweise startet das automatische Vakuum immer noch, dann wird der zweite Kern aktiviert. Wir haben 16-32 Kerne zugewiesen, so dass 10 Personen gleichzeitig arbeiten können, es gibt keine Probleme.Da PGDATA physikalisch identisch ist, stellt sich heraus, dass wir tatsächlich Postgres zum Narren halten. Der Trick ist folgender: Es werden beispielsweise 10 Postgres gleichzeitig gestartet. Welches Problem ist in der Regel was? Sie setzen shared_buffer auf 25%. Das sind dementsprechend 200 GB. Sie werden nicht mehr als drei davon starten, da die Erinnerung enden wird.Irgendwann stellten wir jedoch fest, dass dies nicht notwendig war: Wir setzten shared_buffer auf 2 GB. PostgreSQL hat effective_cache_size und betrifft in Wirklichkeit nur Pläne . Wir setzen es bei 0,5 Tb. Und es ist nicht einmal wichtig, dass sie nicht wirklich da sind: Er macht Pläne, als ob sie es wären.Wenn wir also eine Art Migration testen, können wir alle Pläne sammeln - wir werden sehen, wie es in der Produktion passieren wird. Die Sekunden dort sind unterschiedlich (langsamer), aber die Daten, die wir tatsächlich lesen, und die Pläne selbst (welche Art von JOINs usw.) werden genauso erhalten wie bei der Produktion. Parallel dazu können Sie viele dieser Überprüfungen auf einem Computer ausführen.DS : Glaubst du, dass es mehrere Probleme gibt? Die erste ist eine Lösung, die nur unter PostgreSQL funktioniert. Dieser Ansatz ist sehr privat, er ist nicht generisch. Das zweite - Kubernetes (und das ist, wohin die Wolke jetzt geht) bezieht viele Knoten mit ein, und diese Knoten sind kurzlebig. Und in Ihrem Fall ist es ein zustandsbehafteter, beständiger Knoten. Diese Dinge widersprechen mir.
NS : Erstens - ich stimme zu, das ist eine reine Postgres-Geschichte. Ich denke, wenn wir irgendeine direkte Eingabe und einen Pufferpool für fast den gesamten Speicher haben, wird dieser Ansatz nicht funktionieren - es wird unterschiedliche Pläne geben. Momentan arbeiten wir jedoch nur mit Postgres, wir denken nicht an andere.Über Kubernetes. Sie selbst sagen immer, dass wir eine beständige Basis haben. Wenn die Instanz abstürzt, müssen Sie zunächst die Festplatte sichern. Hier haben wir auch die gesamte Plattform in Kubernetes, und die Komponente mit Postgres ist separat (obwohl sie eines Tages dort sein wird). Daher ist alles so: Die Instanz ist abgestürzt, aber wir haben die PV gespeichert und nur eine Verbindung zu einer anderen (neuen) Instanz hergestellt, als wäre nichts passiert.DS : Aus meiner Sicht erstellen wir Pods in Kubernetes. K8s - elastisch: Bauteile werden bei Bedarf einzeln bestellt. Die Aufgabe besteht darin, einfach einen Pod zu erstellen und zu sagen, dass er X-Ressourcen benötigt, und dann wird K8s es herausfinden. Die Speicherunterstützung in Kubernetes ist jedoch immer noch instabil: In
1.16 ,
1.17 (diese Version wurde vor
Wochen veröffentlicht), werden diese Funktionen nur als Beta-Versionen angeboten.
Sechs Monate oder ein Jahr vergehen - es wird mehr oder weniger stabil oder zumindest als solches deklariert. Dann löst die Möglichkeit von Snapshots und Resize'a Ihr Problem bereits vollständig. Weil du eine Basis hast. Ja, es ist möglicherweise nicht sehr schnell, aber die Geschwindigkeit hängt davon ab, was sich unter der Haube befindet, da einige Implementierungen auf der Ebene des Festplattensubsystems kopieren und beim Schreiben kopiert werden können.
NS : Es ist auch erforderlich, dass alle Engines (Amazon, Google ...) diese Version unterstützen - es dauert auch einige Zeit.DS : Während wir sie nicht benutzen. Wir benutzen unsere.
Lokale Entwicklung unter Kubernetes
NS : Sind Sie auf eine solche Wunschliste gestoßen, wenn Sie alle Pods auf einer Maschine heben und so ein wenig testen müssen. Um schnell einen Proof of Concept zu erhalten, müssen Sie sicherstellen, dass die Anwendung in Kubernetes ausgeführt wird, ohne eine Reihe von Computern dafür zuzuweisen. Gibt es einen Minikube, richtig?DS : Meiner Meinung nach handelt es sich bei diesem Fall - der Bereitstellung auf einem Knoten - ausschließlich um die lokale Entwicklung. Oder einige Manifestationen eines solchen Musters. Es gibt
Minikube , es gibt
K3s ,
KIND . Wir werden Kubernetes IN Docker verwenden. Jetzt fingen sie an, mit ihm für Tests zu arbeiten.
NS : Früher dachte ich, dass dies ein Versuch ist, alle Pods in ein Docker-Image zu packen. Es stellte sich jedoch heraus, dass es sich um etwas anderes handelt. Wie auch immer, es gibt separate Container, separate Hülsen - nur im Docker.DS : Ja. Und da wird eine ziemlich lustige Nachahmung gemacht, aber der Punkt ist ... Wir haben ein Bereitstellungstool -
werf . Wir wollen einen Modus darin machen - bedingt
werf up : "Raise me a local Kubernetes". Und dann laufen die bedingten
werf follow . Dann kann der Entwickler die IDE bearbeiten, und im System wird ein Prozess gestartet, der die Änderungen erkennt, die Bilder neu zusammensetzt und sie in die lokalen K8s umwandelt. Wir wollen also versuchen, das Problem der lokalen Entwicklung zu lösen.
Snapshots und Datenbankklonen in der Realität von K8s
NS : Wenn Sie zurück zu Copy-on-Write gehen. Mir ist aufgefallen, dass die Wolken auch Schnappschüsse haben. Sie arbeiten anders. Zum Beispiel in GCP: Sie haben eine Multi-Terabyte-Instanz an der Ostküste der USA. Sie machen regelmäßig Schnappschüsse. Sie nehmen eine Kopie der Festplatte an der Westküste aus einem Schnappschuss - in wenigen Minuten ist alles fertig, es funktioniert sehr schnell, nur der Cache muss im Speicher gefüllt werden. Aber diese Klone (Schnappschüsse) - um ein neues Volume "bereitzustellen". Dies ist ideal, wenn Sie viele Instanzen erstellen müssen.Aber für die Tests, so scheint es mir, Schnappschüsse, von denen Sie in Docker sprechen, oder von denen ich in ZFS, BTRFS und sogar in LVM spreche ... - sie ermöglichen es Ihnen, keine wirklich neuen Daten auf demselben Computer zu erstellen. In der Cloud müssen Sie immer noch jedes Mal dafür bezahlen und nicht Minuten, sondern Minuten warten (und im Fall einer langsamen Last sind es wahrscheinlich Stunden).Stattdessen können Sie diese Daten in ein oder zwei Sekunden abrufen, den Test fahren und wegwerfen. Diese Schnappschüsse lösen verschiedene Probleme. Im ersten Fall - um neue Replikate zu skalieren und zu erhalten, und im zweiten Fall - für Tests.DS : Dem stimme ich nicht zu. Das Klonen von Volumes ist normalerweise Aufgabe der Cloud. Ich habe ihre Implementierung nicht beobachtet, aber ich weiß, wie wir es auf Hardware machen. Wir haben Ceph, in dem Sie jedem physischen Volume (
RBD )
anweisen können, innerhalb von zehn Millisekunden zu
klonen und ein zweites Volume mit denselben Eigenschaften,
IOPSs usw.
abzurufen . Sie müssen verstehen, dass es ein kniffliges Copy-on-Write gibt. Warum funktioniert die Cloud nicht genauso? Ich bin mir sicher, dass sie das irgendwie versuchen.
NS : Aber sie werden noch einige Sekunden brauchen, um die Instanz zu erhöhen, Docker dorthin zu bringen usw.DS : Warum muss eine gesamte Instanz ausgelöst werden? Aber wir haben eine Instanz für 32 Kerne, für 16 ... und sie passt irgendwie hinein - zum Beispiel vier. Wenn wir den fünften bestellen, steigt die Instanz und wird dann gelöscht.
NS : Ja, interessanterweise hat Kubernetes eine andere Geschichte. Unsere Datenbank ist nicht in K8s und eine Instanz. Das Klonen einer Multi-Terabyte-Datenbank dauert jedoch nicht länger als zwei Sekunden.DS : Das ist cool. Meine anfängliche Botschaft ist jedoch, dass dies keine generische Lösung ist. Ja, es ist cool, aber nur Postgres ist geeignet und nur auf einem Knoten.
NS : Es ist nicht nur für Postgres geeignet: Diese Pläne werden, wie ich beschrieben habe, nur auf diese Weise funktionieren. Wenn Sie sich jedoch nicht um die Pläne kümmern, sondern nur alle Daten für Funktionstests benötigen, ist dies für jedes DBMS geeignet.DS : Vor vielen Jahren haben wir das mit LVM-Snapshots gemacht. Das ist ein Klassiker. Dieser Ansatz wurde sehr aktiv genutzt. Nur zustandsbehaftete Knoten sind ein Schmerz. Weil sie nicht fallen gelassen werden müssen, denken Sie immer an sie ...
NS : Sehen Sie hier eine hybride Möglichkeit? Nehmen wir an, Stateful ist eine Art Pod, die für mehrere Personen (viele Tester) funktioniert. Wir haben ein Volume, aber dank des Dateisystems sind die Klone lokal. Wenn der Pod herunterfällt, bleibt die Festplatte erhalten - der Pod wird angehoben, es werden die Informationen zu allen Klonen berücksichtigt, alles wird zurückgenommen und es wird gesagt: "Hier sind Ihre Klone an diesen Ports, arbeiten Sie weiter mit ihnen."DS : Technisch bedeutet dies, dass dies innerhalb von Kubernetes ein Pod ist, in dem wir viele Postgres betreiben.
NS : Ja. Er hat eine Grenze: Angenommen, nicht mehr als 10 Personen arbeiten gleichzeitig mit ihm. Wenn Sie 20 brauchen, starten Sie den zweiten solchen Pod. Wenn Sie das zweite vollständige Volume erhalten haben, werden die gleichen 10 "dünnen" Klone erstellt. Sehen Sie eine solche Gelegenheit nicht?DS : Wir müssen hier Sicherheitsprobleme hinzufügen. Eine solche Organisationsoption impliziert, dass dieser Pod über hohe Funktionen verfügt, da er nicht standardmäßige Vorgänge auf dem Dateisystem ausführen kann. Aber ich wiederhole: Ich glaube, dass der Speicher mittelfristig in Kubernetes festgelegt wird, die gesamte Geschichte mit Volumes wird in den Clouds festgelegt - Alles wird "nur funktionieren". Die Größe wird geändert, geklont ... Es gibt ein Volume - wir sagen: "Erstellen Sie ein neues auf dieser Grundlage" - und nach eineinhalb Sekunden erhalten wir, was wir brauchen.
NS : Ich glaube nicht an eineinhalb Sekunden für viele Terabyte. Bei Ceph machst du es selbst und redest über Wolken. Gehen Sie auf EC2 in die Cloud, machen Sie einen Klon des EBS-Volumens von vielen Terabyte und sehen Sie, wie hoch die Leistung sein wird. Es dauert nicht einige Sekunden. Ich bin sehr interessiert, wenn sie einen solchen Indikator erreichen. Ich verstehe, wovon Sie sprechen, aber lassen Sie mich nicht zustimmen.DS : Ok, aber das habe ich mittelfristig gesagt, nicht kurzfristig. Seit mehreren Jahren.
Pro Operator für PostgreSQL von Zalando
Während dieses Treffens kam auch Alexey Klyukin, ein ehemaliger Entwickler von Zalando, der über die Geschichte des PostgreSQL-Betreibers sprach, zu ihr:
Es ist großartig, dass dieses Thema allgemein angesprochen wurde: sowohl Postgres als auch Kubernetes. Als wir 2017 in Zalando damit begannen, war es ein Thema, das jeder wollte, aber niemand tat es. Jeder hatte bereits Kubernetes, aber auf die Frage, was mit den Datenbanken geschehen soll, sagten sogar Leute wie Kelsey Hightower , die K8 predigten, etwas in der Art:
Gehen Sie zu verwalteten Diensten und verwenden Sie sie. Starten Sie die Datenbank nicht in Kubernetes. Andernfalls entscheidet sich Ihr K8 beispielsweise für ein Upgrade, löscht alle Knoten und Ihre Daten fliegen weit, weit weg. "
Wir haben uns für einen Betreiber entschieden, der entgegen dieser Empfehlung die Postgres-Datenbank in Kubernetes einrichtet. Und wir hatten eine gute Grundlage - Patroni . Dies ist ein automatisches Failover für PostgreSQL, das korrekt durchgeführt wurde, d. H. Verwendung von etcd, consul oder ZooKeeper als Repository für Clusterinformationen. Ein solches Repository wird jedem gegeben, der zum Beispiel fragt, welcher Anführer jetzt die gleichen Informationen hat - trotz der Tatsache, dass wir alles verteilt haben - damit es kein gespaltenes Gehirn gibt. Außerdem hatten wir ein Docker-Image für ihn.
Im Allgemeinen trat die Notwendigkeit eines automatischen Failovers im Unternehmen nach der Migration vom internen Eisendatenzentrum in die Cloud auf. Die Cloud basierte auf einer proprietären PaaS-Lösung (Platform-as-a-Service). Es ist Open Source, aber um es zu erhöhen, musste man hart arbeiten. Es hieß STUPS .
Anfangs gab es keine Kubernetes. Genauer gesagt, als die eigene Lösung eingesetzt wurde, war K8s bereits so grob, dass es nicht für die Produktion geeignet war. Meiner Meinung nach war es 2015 oder 2016. Bis 2017 waren Kubernetes mehr oder weniger ausgereift - es bestand die Notwendigkeit, dorthin zu migrieren.
Und wir hatten bereits einen Hafencontainer. Es gab PaaS, das Docker verwendete. Warum nicht K8s ausprobieren? Warum schreibst du nicht deine eigene Aussage? Murat Kabilov, der von Avito zu uns kam, startete dies aus eigener Initiative - „spielen“ - und das Projekt „startete“.
Aber im Allgemeinen wollte ich über AWS sprechen. Warum gab es in der Vergangenheit AWS-bezogenen Code?
Wenn Sie etwas in Kubernetes ausführen, müssen Sie verstehen, dass K8s gerade in Arbeit ist. Es wird ständig weiterentwickelt, verbessert und regelmäßig ausgeglichen. Sie müssen alle Änderungen in Kubernetes sorgfältig überwachen, Sie müssen bereit sein, sich darauf einzulassen und herauszufinden, wie es im Detail funktioniert - vielleicht mehr, als Sie möchten. Dies ist im Prinzip jede Plattform, auf der Sie Ihre Datenbanken ausführen ...
Als wir die Aussage machten, hatten wir Postgres, das mit einem externen Volume arbeitete (in diesem Fall EBS, da wir in AWS arbeiteten). Die Datenbank wuchs, irgendwann musste die Größe geändert werden: Beispielsweise beträgt die ursprüngliche Größe von EBS 100 TB, die Datenbank ist darauf angewachsen, jetzt möchten wir EBS auf 200 TB erweitern. Wie? Angenommen, Sie können eine neue Instanz sichern / wiederherstellen, dies ist jedoch lang und mit Ausfallzeiten verbunden.
Aus diesem Grund wollte ich eine Größenänderung, mit der die EBS-Partition erweitert und das Dateisystem angewiesen wird, den neuen Speicherplatz zu verwenden. Und wir haben es geschafft, aber damals hatte Kubernetes keine API für die Größenänderung. Da wir an AWS gearbeitet haben, haben wir Code für dessen API geschrieben.
Niemand möchte dasselbe für andere Plattformen tun. Die Aussage, dass es nur auf AWS ausgeführt werden kann, ist unkompliziert und funktioniert nicht auf allen anderen Systemen. Im Allgemeinen handelt es sich um ein Open Source-Projekt: Wenn jemand die Verwendung der neuen API beschleunigen möchte, sind wir herzlich willkommen. Es gibt GitHub , Pull-Requests - das Zalando-Team versucht, schnell auf sie zu reagieren und den Operator zu promoten. Soweit mir bekannt ist, hat das Projekt an Google Summer of Code und anderen ähnlichen Initiativen teilgenommen . Zalando ist sehr aktiv dabei.
PS Bonus!
Wenn Sie sich für das Thema PostgreSQL und Kubernetes interessieren, dann weisen wir auch darauf hin, dass letzte Woche das nächste Postgres stattgefunden hat, bei dem
Alexander Kukushkin aus Zalando mit Nikolai gesprochen hat. Ein Video davon gibt es
hier .
PPS
Lesen Sie auch in unserem Blog: