{"id":55467,"date":"2020-01-21T00:00:00","date_gmt":"2020-01-20T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/postgres-vtornik-5-postgresql-i-kubernetes-ci-cd-avtomatizatsiya-testirovaniya"},"modified":"2020-02-18T14:03:35","modified_gmt":"2020-02-18T11:03:35","slug":"postgres-vtornik-5-postgresql-i-kubernetes-ci-cd-avtomatizatsiya-testirovaniya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/postgres-vtornik-5-postgresql-i-kubernetes-ci-cd-avtomatizatsiya-testirovaniya","title":{"rendered":"Postgres-Dienstag Nr. 5: \u201ePostgreSQL und Kubernetes. CI\/CD. Automatisierung von Tests\u201c","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Postgres-Dienstag
\n
\nEnde letzten Jahres fand eine weitere Live-\u00dcbertragung der russischen PostgreSQL-Community statt #RuPostgres<\/a><\/noindex>, in deren Rahmen Mitbegr\u00fcnder Nikolai Samokhvalov mit dem technischen Direktor von \u201eFlant\u201c Dmitry Stolyarov \u00fcber diese DBMS im Kontext von Kubernetes sprach.<\/p>\n

Wir ver\u00f6ffentlichen das Transkript des Hauptteils dieser Diskussion, und auf dem YouTube-Kanal der Community<\/a><\/noindex> wurde die vollst\u00e4ndige Videoaufzeichnung ver\u00f6ffentlicht:<\/a><\/noindex><\/p>\n

\r\n \"Video\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

Datenbanken und Kubernetes<\/h2>\n

\nNS<\/b>: Heute werden wir nicht \u00fcber VACUUM und CHECKPOINTS sprechen. Ich m\u00f6chte \u00fcber Kubernetes reden. Ich wei\u00df, dass du bereits viele Jahre Erfahrung hast. Ich habe deine Videos angesehen und einige sogar in kleinen Abschnitten erneut geschaut\u2026 Lass uns gleich zur Sache kommen: Warum \u00fcberhaupt Postgres oder MySQL in K8s?<\/i><\/p>\n

DS<\/b>: Es gibt keine eindeutige Antwort auf diese Frage und kann sie auch nicht geben. Aber grunds\u00e4tzlich liegt es an der Einfachheit und Bequemlichkeit\u2026 das Potenzial. Jeder m\u00f6chte schlie\u00dflich Managed-Services.<\/p>\n

NS<\/b>: Damit wie RDS<\/a><\/noindex>, nur bei sich selbst?<\/i><\/p>\n

DS<\/b>: Ja, damit wie RDS, nur \u00fcberall.<\/p>\n

NS<\/b>: \u201e\u00dcberall\u201c ist ein guter Hinweis. In gro\u00dfen Unternehmen ist alles an verschiedenen Orten angesiedelt. Warum sollte man in einem gro\u00dfen Unternehmen nicht auf eine fertig ausgearbeitete L\u00f6sung zur\u00fcckgreifen? Zum Beispiel hat Nutanix eigene Entwicklungen, und andere Unternehmen (wie VMware\u2026) bieten dasselbe \u201eRDS, nur bei sich selbst\u201c an.<\/i><\/p>\n

DS<\/b>: Aber das ist nur eine spezifische Implementierung, die nur unter bestimmten Bedingungen funktioniert. Wenn es um Kubernetes geht, gibt es eine enorme Vielfalt an Infrastruktur, die in K8s vorhanden sein kann. Im Grunde genommen ist dies der Standard f\u00fcr die API zu Cloud-Diensten\u2026<\/p>\n

NS<\/b>: Und das sogar kostenlos!<\/i><\/p>\n

DS<\/b>: Das ist nicht so entscheidend. Die Kostenfreiheit ist f\u00fcr einen nicht allzu gro\u00dfen Marktsektor wichtig. Es geht um etwas anderes\u2026 Du erinnerst dich sicher an den Bericht \u201eDatenbanken und Kubernetes<\/a><\/noindex>\u00bb?<\/p>\n

NS<\/b>: Ja.<\/i><\/p>\n

DS<\/b>: Ich habe verstanden, dass es sehr unterschiedlich aufgenommen wurde. Ein Teil der Leute dachte, dass ich sage: \u201eLeute, lasst uns alle DBs in Kubernetes bringen!\u201c, w\u00e4hrend andere dachten, dass es sich um gr\u00e4ssliche Fahrr\u00e4der handelt. Ich wollte eigentlich etwas ganz anderes sagen: \u201eSchaut, was passiert, welche Probleme es gibt und wie man sie l\u00f6sen kann. Soll man jetzt mit Datenbanken in Kubernetes arbeiten? In Produktion? Nun, nur wenn man\u2026 bestimmte Dinge liebt. Aber f\u00fcr dev kann ich sagen, dass ich es empfehle. F\u00fcr dev ist es sehr wichtig, dass man Umgebungen schnell erstellen und l\u00f6schen kann.<\/p>\n

NS: Mit dev meinst du alle Umgebungen, die nicht prod sind? Staging, QA\u2026<\/i><\/p>\n

DS<\/b>: Wenn wir von Performance-St\u00e4nden sprechen, dann wahrscheinlich nicht, denn die Anforderungen sind dort spezifisch. Wenn wir von speziellen F\u00e4llen sprechen, in denen im Staging eine sehr gro\u00dfe Datenbank ben\u00f6tigt wird, dann auch wahrscheinlich nicht\u2026 Wenn es sich um eine statische, langlebige Umgebung handelt, was bringt es dann, wenn die Datenbank in K8s liegt?<\/p>\n

NS<\/b>: Gar nichts. Aber wo sehen wir statische Umgebungen? Eine statische Umgebung ist schon morgen veraltet.<\/i><\/p>\n

DS<\/b>: Staging kann statisch sein. Wir haben Kunden\u2026<\/p>\n

NS<\/b>: Ja, ich habe auch welche. Es ist ein gro\u00dfes Problem, wenn du eine Datenbank mit 10 TB hast, aber Staging nur 200 GB\u2026<\/i><\/p>\n

DS<\/b>: Ich habe einen sehr coolen Fall! Auf Staging befindet sich die Produktionsdatenbank, in der \u00c4nderungen vorgenommen werden. Und es gibt einen Knopf: \u201eIn die Produktion ausrollen\u201c. Diese \u00c4nderungen \u2014 Delten \u2014 werden (scheinbar einfach \u00fcber eine API synchronisiert) in die Produktion \u00fcbertragen. Das ist eine sehr exotische Variante.<\/p>\n

NS<\/b>: Ich habe Startups im Valley gesehen, die immer noch in RDS oder sogar in Heroku sitzen \u2014 das sind Geschichten aus den letzten 2-3 Jahren \u2014 und sie laden sich das Dump auf ihren Laptop herunter. Weil die Datenbank gerade mal 80 GB hat und auf dem Laptop Platz ist. Dann kaufen sie Festplatten f\u00fcr jeden, um 3 Datenbanken zu haben, um verschiedene Entwicklungen zu verfolgen. So etwas passiert auch. Ich habe auch gesehen, dass sie keine Angst haben, die Produktion in Staging zu kopieren \u2014 das h\u00e4ngt stark vom Unternehmen ab. Aber ich habe auch gesehen, dass viele Angst haben und oft die Zeit und Ressourcen fehlen. Aber bevor wir zu diesem Thema \u00fcbergehen, m\u00f6chte ich mehr \u00fcber Kubernetes h\u00f6ren. Verstehe ich richtig, dass es in der Produktion noch nichts gibt?<\/i><\/p>\n

DS<\/b>: Wir haben kleine Datenbanken in der Produktion. Es geht um Gr\u00f6\u00dfenordnungen im Bereich von Dutzenden von Gigabyte und nicht kritische Dienste, f\u00fcr die es zu m\u00fchsam war, Replikate zu erstellen (und es gab auch keinen Bedarf daf\u00fcr). Und vorausgesetzt, dass es unter Kubernetes ein vern\u00fcnftiger Speicher ist. Diese Datenbank lief in einer virtuellen Maschine \u2014 vereinfacht gesagt in VMware, \u00fcber einem SAN. Wir haben sie platziert in PV<\/a><\/noindex> verschoben und k\u00f6nnen sie jetzt von Maschine zu Maschine transferieren.<\/p>\n

NS<\/b>: Datenbanken dieser Gr\u00f6\u00dfe, bis zu 100 GB, auf guten Festplatten und bei einer stabilen Netzwerkanbindung k\u00f6nnen innerhalb weniger Minuten bereitgestellt werden, oder? Eine Geschwindigkeit von 1 GB pro Sekunde ist mittlerweile nichts Au\u00dfergew\u00f6hnliches.<\/i><\/p>\n

DS<\/b>: Ja, f\u00fcr lineare Operationen ist das kein Problem.<\/p>\n

NS<\/b>: Okay, wir m\u00fcssen nur \u00fcber die Produktionsumgebung nachdenken. Und wie sieht es aus, wenn wir Kubernetes f\u00fcr Nicht-Produktionsumgebungen in Betracht ziehen \u2014 wie gehe ich vor? Ich sehe, dass bei Zalando ein Operator<\/a><\/noindex>entwickelt wird, bei Crunchy arbeiten sie daran, und es gibt noch einige andere Optionen. Und bei<\/a><\/noindex>OnGres \u2014 das ist unser guter Bekannter Alvaro aus Spanien: Sie erstellen nicht einfach nur<\/a><\/noindex> einen Operator , sondern eine komplette Distribution (<\/a><\/noindex>StackGres), die neben PostgreSQL auch ein Backup-Tool und den Envoy-Proxy integriert hat\u2026<\/a><\/noindex>), in das wir neben Postgres auch ein Backup integriert haben, Proxy Envoy\u2026<\/i><\/p>\n

DS<\/b>: Wof\u00fcr ist Envoy? F\u00fcr die Lastverteilung von PostgreSQL-Traffic?<\/p>\n

NS<\/b>: Ja. Sie sehen es also so: Wenn man ein Linux-Distribution und den Kernel nimmt, dann ist PostgreSQL im Grunde der Kernel, und sie wollen eine Distribution erstellen, die cloudfreundlich ist und in Kubernetes l\u00e4uft. Sie verbinden Komponenten (Backups usw.) und optimieren sie, damit sie gut funktionieren.<\/i><\/p>\n

DS<\/b>: Sehr cool! Im Grunde handelt es sich um eine Software, um ein verwaltetes Postgres zu erstellen.<\/p>\n

NS<\/b>: Linux-Distributionen haben immer Probleme: Wie man Treiber erstellt, damit die gesamte Hardware unterst\u00fctzt wird. Ihre Idee ist, dass sie in Kubernetes arbeiten werden. Ich wei\u00df, dass wir bei dem Betreiber Zalando k\u00fcrzlich eine Bindung an AWS gesehen haben, und das ist schon nicht so gut. Es sollte keine Bindung an eine spezifische Infrastruktur geben \u2013 wo w\u00e4re dann der Sinn?<\/i><\/p>\n

DS<\/b>: Ich wei\u00df nicht, in welcher spezifischen Situation Zalando sich festgelegt hat, aber derzeit ist der Storage in Kubernetes so gestaltet, dass man keine generische Methode verwenden kann, um ein Disk-Backup zu erstellen. K\u00fcrzlich wurde in den Standards \u2013 in der letzten Version der CSI-Spezifikation<\/a><\/noindex> \u2013 die M\u00f6glichkeit von Snapshots eingef\u00fchrt, aber wo wurde das umgesetzt? Ehrlich gesagt, es ist immer noch so unausgereift\u2026 Wir testen CSI auf AWS, GCE, Azure, vSphere, aber wenn man es etwas verwendet, sieht man, dass es noch nicht bereit ist.<\/p>\n

NS<\/b>: Daher m\u00fcssen wir uns manchmal mit der Infrastruktur besch\u00e4ftigen. Ich denke, wir befinden uns noch in einer fr\u00fchen Phase \u2014 den Wachstumsproblemen. Frage: Was w\u00fcrdest du Anf\u00e4ngern raten, die PgSQL in K8s ausprobieren m\u00f6chten? Welchen Operator k\u00f6nntest du empfehlen?<\/i><\/p>\n

DS<\/b>: Das Problem ist, dass Postgres f\u00fcr uns nur 3% ausmacht. Wir haben noch eine sehr lange Liste unterschiedlicher Software in Kubernetes, ich werde gar nicht alles aufz\u00e4hlen. Zum Beispiel Elasticsearch. Es gibt viele Operatoren: einige entwickeln sich aktiv, andere nicht. Wir haben uns Anforderungen aufgestellt, die in einem Operator erf\u00fcllt sein m\u00fcssen, damit wir ihn ernst nehmen. Der Operator ist speziell f\u00fcr Kubernetes \u2014 nicht wie \u201eein Operator, um etwas unter Amazon zu machen\u201c\u2026 Faktisch verwenden wir einen einzigen Operator recht umfassend (= fast bei allen Kunden) \u2014 f\u00fcr Redis<\/a><\/noindex> (bald ver\u00f6ffentlichen wir auch einen Artikel \u00fcber ihn)<\/i>.<\/p>\n

NS<\/b>: Gibt es f\u00fcr MySQL keinen? Ich wei\u00df, dass Percona... da sie jetzt sowohl MySQL als auch MongoDB und Postgres unterst\u00fctzen, m\u00fcssen sie wahrscheinlich eine universelle L\u00f6sung entwickeln: f\u00fcr alle Datenbanken und alle Cloud-Anbieter.<\/i><\/p>\n

DS<\/b>: Wir haben die Operatoren f\u00fcr MySQL noch nicht betrachtet. Das ist f\u00fcr uns derzeit nicht der Hauptfokus. MySQL funktioniert gut im Standalone-Modus. Warum einen Operator, wenn man einfach die Datenbank starten kann\u2026 Man kann einen Docker-Container mit Postgres starten, oder es ganz einfach halten.<\/p>\n

NS<\/b>: Dazu gab es auch eine Frage. Ganz ohne Operator?<\/i><\/p>\n

DS<\/b>: Ja, zu 100% l\u00e4uft bei uns PostgreSQL ohne Operator. Im Moment ist es so. Wir nutzen aktiv einen Operator f\u00fcr Prometheus und f\u00fcr Redis. Wir haben Pl\u00e4ne, einen Operator f\u00fcr Elasticsearch zu finden \u2013 das ist am dringendsten, weil wir ihn in 100% der F\u00e4lle in Kubernetes setzen m\u00f6chten. Genauso wie wir auch wollen, dass MongoDB immer in Kubernetes l\u00e4uft. Es gibt bestimmte W\u00fcnsche \u2013 das Gef\u00fchl, dass wir in diesen F\u00e4llen etwas tun k\u00f6nnen. Aber bei Postgres haben wir uns noch nicht umgesehen. Nat\u00fcrlich wissen wir von den verschiedenen Optionen, aber in der Praxis nutzen wir Standalone.<\/p>\n

Datenbank f\u00fcr Tests in Kubernetes<\/h2>\n

\nNS<\/b>: Lasst uns zum Thema Testen \u00fcbergehen. Wie man \u00c4nderungen in der Datenbank ausrollt \u2013 aus der Perspektive von DevOps. Es gibt Mikrodienste, viele Datenbanken, und st\u00e4ndig \u00e4ndert sich etwas. Wie stellt man sicher, dass CI\/CD gut funktioniert, damit alles aus der Sicht der DBMS in Ordnung ist? Was ist dein Ansatz?<\/i><\/p>\n

DS<\/b>: Es gibt nicht die eine Antwort. Es gibt mehrere Parameter. Der erste ist die Gr\u00f6\u00dfe der Datenbank, die wir ausrollen wollen. Du hast selbst erw\u00e4hnt, dass Unternehmen unterschiedlich mit der Bereitstellung einer Kopie der Prod-Datenbank auf Dev und Staging umgehen.<\/p>\n

NS<\/b>: Im Hinblick auf die GDPR denke ich, dass sie immer vorsichtiger werden... Ich kann sagen, dass in Europa bereits mit Bu\u00dfgeldern begonnen wurde.<\/i><\/p>\n

DS<\/b>: Aber oft kann man Software schreiben, die ein Dump von der Produktion erstellt und diesen obfuskiert. Es entstehen produktive Daten (Snapshot, Dump, bin\u00e4re Kopie\u2026), aber anonymisiert. Alternativ k\u00f6nnen auch Generierungsskripte verwendet werden: das k\u00f6nnen Fixtures oder einfach ein Skript sein, das eine gro\u00dfe Datenbank generiert. Das eigentliche Problem ist: Wie viel Zeit ben\u00f6tigt man zur Erstellung des Basisimages? Und wie lange dauert es, dieses in der ben\u00f6tigten Umgebung zu implementieren?<\/p>\n

Wir haben uns f\u00fcr folgendes Schema entschieden: Wenn der Kunde einen Fixture-Datensatz hat (eine minimale Version der Datenbank), verwenden wir diesen standardm\u00e4\u00dfig. Wenn es um Review-Umgebungen geht, bei denen wir einen Branch erstellt haben und eine Instanz der Anwendung hochgefahren wird \u2013 dann setzen wir eine kleine Datenbank ein. Aber auch die Variante ist gut gelungen.<\/a><\/noindex>, wenn wir einmal pro Tag (nachts) aus der Produktion einen Dump machen und auf dieser Grundlage einen Docker-Container mit PostgreSQL und MySQL erstellen, die mit diesen geladenen Daten gef\u00fcllt sind. Wenn aus diesem Image die Datenbank 50 Mal implementiert werden muss, ist das relativ einfach und schnell.<\/p>\n

NS<\/b>: Einfach durch Kopieren?<\/i><\/p>\n

DS<\/b>: Die Daten werden direkt im Docker-Image gespeichert. Das hei\u00dft, wir haben ein fertiges Image, sagen wir 100 GB gro\u00df. Dank der Schichten in Docker k\u00f6nnen wir dieses Image schnell die gew\u00fcnschte Anzahl von Male bereitstellen. Die Methode ist einfach, funktioniert aber gut.<\/p>\n

NS<\/b>: Weiter, wenn ihr testet, wird das direkt innerhalb von Docker ver\u00e4ndert, oder? Copy-on-write innerhalb von Docker \u2014 wir l\u00f6schen und fangen neu an, alles gut. Klasse! Und nutzt ihr das schon voll aus?<\/i><\/p>\n

DS<\/b>: Schon lange.<\/p>\n

NS<\/b>: Wir besch\u00e4ftigen uns mit sehr \u00e4hnlichen Dingen. Allerdings verwenden wir nicht das Docker-Copy-on-Write, sondern etwas anderes.<\/i><\/p>\n

DS<\/b>: Es ist nicht generisch. Der Docker-Speicher funktioniert \u00fcberall.<\/p>\n

NS<\/b>: Theoretisch ja. Aber auch wir haben dort Module, verschiedene Module k\u00f6nnen gemacht werden, um mit verschiedenen Dateisystemen zu arbeiten. Hier ist es wichtig. Wir sehen das aus der Perspektive von Postgres anders. Jetzt habe ich es aus der Perspektive von Docker betrachtet und gesehen, dass bei euch alles funktioniert. Aber wenn die Datenbank riesig ist, zum Beispiel 1 TB, dann wird alles schon lange: sowohl die Operationen nachts als auch das Einf\u00fcllen in Docker\u2026 Oder ist es in Ordnung, 5 TB in Docker zu packen\u2026?<\/i><\/p>\n

DS<\/b>: Was macht das f\u00fcr einen Unterschied: das sind doch Blobs, einfach Bits und Bytes.<\/p>\n

NS<\/b>: Der Unterschied ist: Machen Sie das \u00fcber Dump und Restore?<\/i><\/p>\n

DS<\/b>: Das ist \u00fcberhaupt nicht notwendig. Die Methoden zur Erstellung dieses Images k\u00f6nnen unterschiedlich sein.<\/p>\n

NS<\/b>: F\u00fcr einige Kunden haben wir es so eingerichtet, dass wir anstelle der regul\u00e4ren Generierung eines Basisimages dieses st\u00e4ndig aktuell halten. Es ist im Wesentlichen eine Kopie, aber die Daten werden nicht direkt vom Master, sondern \u00fcber ein Archiv bezogen. Ein bin\u00e4res Archiv, in das die WALs jeden Tag eingespielt werden, dort werden auch Backups gemacht\u2026 Diese WALs erreichen das Basisimage nach einer kurzen Verz\u00f6gerung (gerade mal 1-2 Sekunden). Von dort aus klonen wir nach Belieben \u2014 standardm\u00e4\u00dfig verwenden wir ZFS.<\/i><\/p>\n

DS<\/b>: Aber mit ZFS sind Sie auf einen Knoten beschr\u00e4nkt.<\/p>\n

NS<\/b>: Ja. Aber ZFS hat auch einen magischen send<\/a><\/noindex>: damit kann man einen Snapshot senden und sogar (das habe ich noch nicht so richtig getestet, aber\u2026) kann man das Delta zwischen zwei PGDATA<\/code>. Tats\u00e4chlich haben wir noch ein weiteres Werkzeug, das wir f\u00fcr solche Aufgaben nicht wirklich in Betracht gezogen haben. In PostgreSQL gibt es pg_rewind<\/a><\/noindex>, das wie ein \u201eintelligentes\u201c rsync funktioniert und vieles \u00fcberspringt, was man nicht beachten muss, weil sich dort sicher nichts ge\u00e4ndert hat. Wir k\u00f6nnen zwischen zwei Servern eine schnelle Synchronisation durchf\u00fchren und genauso zur\u00fcckspulen.<\/i><\/p>\n

Also, wir versuchen, von dieser eher DBA-lastigen Seite ein Tool zu entwickeln, das genau das erm\u00f6glicht, wor\u00fcber du gesprochen hast: Wir haben eine Datenbank, wollen aber 50 Mal etwas testen, fast gleichzeitig.<\/i><\/p>\n

DS<\/b>: 50 Mal bedeutet, dass Sie 50 Spot-Instanzen bestellen m\u00fcssen.<\/p>\n

NS<\/b>: Nein, wir machen das alles auf einer Maschine.<\/i><\/p>\n

DS<\/b>: Aber wie m\u00f6chten Sie 50 Mal bereitstellen, wenn diese eine Datenbank, sagen wir, ein Terabyte gro\u00df ist? H\u00f6chstwahrscheinlich ben\u00f6tigt sie bedingt 256 GB RAM?<\/p>\n

NS<\/b>: Ja, manchmal ben\u00f6tigt man viel Speicher \u2013 das ist normal. Aber so ein Beispiel aus dem Leben: Auf der Produktionsmaschine gibt es 96 Kerne und 600 GB. Dabei werden f\u00fcr die Datenbank 32 Kerne (sogar 16 Kerne manchmal) und 100-120 GB Speicher verwendet.<\/i><\/p>\n

DS<\/b>: Und da passen 50 Kopien rein?<\/p>\n

NS<\/b>: Es ist also eine Kopie, und dann wird copy-on-write (auf ZFS-Basis) verwendet\u2026 Ich erz\u00e4hle mehr dar\u00fcber.<\/i><\/p>\n

For us, for example, the database is 10 TB. We created a disk for it, and ZFS compressed its size by about 30-40%. Since we don\u2019t perform load testing, exact response time is not critical for us: it can be up to twice as slow \u2014 that\u2019s fine.<\/i><\/p>\n

Wir erm\u00f6glichen Programmierern, QA, DBAs usw., Tests in 1-2 Streams durchzuf\u00fchren. Zum Beispiel k\u00f6nnen sie eine Migration starten. Diese ben\u00f6tigt nicht sofort 10 Kerne \u2014 sie ben\u00f6tigt 1 Backend von Postgres und 1 Kern. Die Migration wird gestartet \u2014 vielleicht, autovacuum<\/a><\/noindex> will also kick in, then the second core will become active. We have 16-32 cores allocated, so 10 people can work simultaneously without issues.<\/i><\/p>\n

Since physically PGDATA<\/code> es ergibt sich so, dass wir Postgres tats\u00e4chlich \u00fcberlisten. Der Trick ist folgender: Zum Beispiel werden 10 Postgres gleichzeitig gestartet. Was ist normalerweise das Problem? Man hat immer shared_buffers<\/a><\/noindex>, for instance, at 25%. Accordingly, that is 200 GB. You can\u2019t start more than three of those, otherwise, memory will run out.<\/i><\/p>\n

But at some point, we realized that this is unnecessary: we set shared_buffers to 2 GB. PostgreSQL has effective_cache_size<\/a><\/noindex>, and in reality, only it influences the plans<\/a><\/noindex>Wir setzen ihn auf 0,5 TB. Und es spielt keine Rolle, dass es sie eigentlich nicht gibt: Er plant, als ob sie vorhanden w\u00e4ren.<\/i><\/p>\n

Also, wenn wir eine Migration testen, k\u00f6nnen wir alle Pl\u00e4ne sammeln \u2014 wir sehen, wie es in der Produktion ablaufen wird. Die Sekunden werden anders sein (langsamer), aber die Daten, die wir tats\u00e4chlich lesen, und die Pl\u00e4ne (wie JOINs und so weiter) sind genau die gleichen wie in der Produktion. Und man kann parallel viele solcher \u00dcberpr\u00fcfungen auf einer Maschine ausf\u00fchren.<\/i><\/p>\n

DS<\/b>: Denkst du nicht, dass es hier mehrere Probleme gibt? Erstens \u2013 das ist eine L\u00f6sung, die nur mit PostgreSQL funktioniert. Dieser Ansatz ist sehr spezifisch, nicht generisch. Zweitens \u2013 Kubernetes (und alles, wohin die Cloud-Technologien jetzt gehen) setzt auf viele Knoten, und diese Knoten sind fl\u00fcchtig. In deinem Fall handelt es sich jedoch um einen zustandsbehafteten, persistenten Knoten. Diese Dinge verursachen bei mir Widerspr\u00fcche.<\/p>\n

NS<\/b>: Erstens \u2014 ich stimme zu, das ist rein Postgres-spezifisch. Ich denke, wenn wir irgendwelche Direct IOs und einen Pufferpools haben, der fast den gesamten Speicher abdeckt, w\u00e4re dieser Ansatz nicht geeignet \u2014 die Pl\u00e4ne w\u00e4ren anders. Aber wir arbeiten bisher nur mit Postgres und denken nicht \u00fcber andere nach.<\/i><\/p>\n

\u00dcber Kubernetes. Du erz\u00e4hlst \u00fcberall, dass wir eine persistente Datenbank haben. Wenn eine Instanz ausf\u00e4llt, ist das Wichtigste, die Festplatte zu sichern. Unsere gesamte Plattform basiert ebenfalls auf Kubernetes, und die Komponente mit Postgres ist separat (obwohl sie auch irgendwann dort sein wird). Daher ist es so: Die Instanz f\u00e4llt aus, aber wir haben ihr PV gespeichert und einfach an eine andere (neue) Instanz angeschlossen, als w\u00e4re nichts passiert.<\/i><\/p>\n

DS<\/b>: Aus meiner Sicht erstellen wir Pods in Kubernetes. K8s ist elastisch: Knoten werden bei Bedarf selbst bestellt. Die Aufgabe besteht einfach darin, einen Pod zu erstellen und ihm zu sagen, dass er X Ressourcen ben\u00f6tigt, und K8s wird sich selbst darum k\u00fcmmern. Aber die Unterst\u00fctzung f\u00fcr Speicher in Kubernetes ist nach wie vor instabil: in 1.16<\/a><\/noindex>, in 1.17<\/a><\/noindex> (diese Version kam heraus Wochen<\/i> her) werden diese Funktionen nur zur Beta.<\/p>\n

Nach einem halben Jahr bis Jahr wird es mehr oder weniger stabil sein, oder zumindest so deklariert. Dann l\u00f6st die M\u00f6glichkeit von Snapshots und Resize Ihr Problem komplett. Denn Sie haben eine Basis. Ja, sie kann nicht besonders schnell sein, aber die Geschwindigkeit h\u00e4ngt davon ab, was \u201eunter der Haube\u201c passiert, denn einige Implementierungen k\u00f6nnen das Kopieren und Copy-on-Write auf der Ebene des Festplattensystems.<\/p>\n

NS<\/b>: Es muss auch sichergestellt werden, dass alle Engines (Amazon, Google\u2026) diese Version unterst\u00fctzen \u2013 das ben\u00f6tigt schlie\u00dflich auch seine Zeit.<\/i><\/p>\n

DS<\/b>: Solange verwenden wir sie nicht. Wir nutzen eigene L\u00f6sungen.<\/p>\n

Lokale Entwicklung mit Kubernetes<\/h2>\n

\nNS<\/b>: Hast du schon einmal mit dem Wunsch zu k\u00e4mpfen gehabt, alle Pods auf einer Maschine hochzufahren und ein kleines Testen durchzuf\u00fchren? Um schnell einen Proof of Concept zu erhalten und zu sehen, dass die Anwendung in Kubernetes funktioniert, ohne viele Maschinen daf\u00fcr bereitzustellen. Es gibt Minikube, oder?<\/i><\/p>\n

DS<\/b>: Ich denke, dieser Anwendungsfall \u2013 alles auf einem Knoten bereitzustellen \u2013 bezieht sich ausschlie\u00dflich auf lokale Entwicklung oder zeigt solche Muster. Es gibt Minikube<\/a><\/noindex>, und es gibt k3s<\/a><\/noindex>, KIND<\/a><\/noindex>. Wir bewegen uns in Richtung Nutzung von Kubernetes IN Docker. Wir haben begonnen, damit f\u00fcr Tests zu arbeiten.<\/p>\n

NS<\/b>: Fr\u00fcher dachte ich, das sei ein Versuch, alle Pods in ein Docker-Image zu packen. Doch es stellte sich heraus, dass es um etwas ganz anderes geht. Dort sind immer noch separate Container, separate Pods \u2014 einfach in Docker.<\/i><\/p>\n

DS<\/b>: Ja. Und dort gibt es eine ziemlich am\u00fcsante Nachbildung, aber die Idee ist\u2026 Wir haben ein Tool f\u00fcr das Deployment \u2013 werf<\/a><\/noindex>. Wir m\u00f6chten darin einen Modus einrichten \u2013 hypothetisch werf up<\/code>: \u201eStarte mir ein lokales Kubernetes\u201c. Und dann dort eine hypothetische Instanz von werf follow<\/code>. Dann kann der Entwickler in der IDE bearbeiten, w\u00e4hrend im System ein Prozess l\u00e4uft, der \u00c4nderungen erkennt und Images neu erstellt und sie ins lokale K8s neu bereitstellt. So wollen wir versuchen, das Problem der lokalen Entwicklung zu l\u00f6sen.<\/p>\n

Snapshots und Datenbankklonierung in K8s Realit\u00e4ten<\/h2>\n

\nNS<\/b>: Wenn wir zum Copy-on-Write zur\u00fcckkehren. Mir ist aufgefallen, dass Clouds auch Snapshots haben. Sie funktionieren unterschiedlich. Zum Beispiel in GCP: Du hast an der Ostk\u00fcste der USA eine Multi-Terabyte-Instanz. Du machst regelm\u00e4\u00dfig Snapshots. Du hebst aus einem Snapshot eine Kopie der Festplatte an der Westk\u00fcste hervor \u2014 in wenigen Minuten ist alles bereit, es funktioniert sehr schnell, nur der Cache muss im Speicher gef\u00fcllt werden. Aber diese Klone (Snapshots) sind dazu da, um ein neues Volume aber zu provisionieren. Es ist gro\u00dfartig, wenn man viele Instanzen erstellen muss.<\/i><\/p>\n

F\u00fcr Tests scheinen mir die Snapshots, von denen du in Docker sprichst oder von denen ich in ZFS, btrfs und sogar LVM spreche\u2026 \u2014 sie erlauben es, auf einer Maschine keine echten neuen Daten zu erzeugen. In der Cloud wirst du jedes Mal daf\u00fcr zahlen m\u00fcssen und warten schon nicht Sekunden, sondern Minuten (und im Fall von Lazy Loading<\/a><\/noindex>, m\u00f6glicherweise sogar Stunden).<\/i><\/p>\n

Stattdessen k\u00f6nnen diese Daten in ein oder zwei Sekunden abgerufen, ein Test durchgef\u00fchrt und dann verworfen werden. Diese Snapshots erf\u00fcllen verschiedene Aufgaben. Im ersten Fall geht es darum, zu skalieren und neue Replikate zu erhalten, im zweiten Fall f\u00fcr Tests.<\/i><\/p>\n

DS<\/b>: Da stimme ich nicht zu. Eine ordnungsgem\u00e4\u00dfe Klonierung von Volumina ist eine Aufgabe f\u00fcr die Cloud. Ich habe ihre Implementierung nicht gesehen, wei\u00df aber, wie wir das auf unserer Hardware umsetzen. Wir haben Ceph, wo man jedem physischen Volume (RBD<\/a><\/noindex>) sagen kann, clone<\/i> und innerhalb von vielen Millisekunden ein zweites Volume mit den gleichen Eigenschaften, IOPS<\/a><\/noindex>'s usw. Man muss verstehen, dass da drin der raffinierte Copy-on-Write steckt. Warum sollte die Cloud das nicht auch so machen? Ich bin mir sicher, dass sie es auf die eine oder andere Weise versuchen.<\/p>\n

NS<\/b>: Aber sie werden trotzdem Sekunden, Dutzende von Sekunden ben\u00f6tigen, um eine Instanz hochzufahren, Docker dorthin zu bringen usw.<\/i><\/p>\n

DS<\/b>: Warum muss unbedingt eine gesamte Instanz hochgefahren werden? Wir haben doch eine Instanz mit 32 Kernen, mit 16\u2026 und da passen eine bestimmte Anzahl rein \u2013 zum Beispiel vier. Wenn wir die f\u00fcnfte bestellen, wird bereits eine Instanz hochgefahren und danach wieder gel\u00f6scht.<\/p>\n

NS<\/b>: Ja, interessant, in Kubernetes ergibt sich eine andere Geschichte. Unsere DB l\u00e4uft nicht in K8s und ist eine einzige Instanz. Aber f\u00fcr das Klonen einer mehrere Terabyte umfassenden Datenbank ben\u00f6tigt man nicht mehr als zwei Sekunden.<\/i><\/p>\n

DS<\/b>: Das ist gro\u00dfartig. Aber mein urspr\u00fcnglicher Punkt ist, dass es keine generische L\u00f6sung ist. Ja, es ist klasse, aber es funktioniert nur mit Postgres und nur auf einem Knoten.<\/p>\n

NS<\/b>: Es ist nicht nur f\u00fcr Postgres geeignet: Diese Pl\u00e4ne, wie ich beschrieben habe, werden nur in diesem funktionieren. Aber wenn wir uns nicht um die Pl\u00e4ne k\u00fcmmern, sondern einfach alle Daten f\u00fcr funktionale Tests ben\u00f6tigen, dann ist es f\u00fcr jede DBMS geeignet.<\/i><\/p>\n

DS<\/b>: Vor vielen Jahren haben wir etwas \u00c4hnliches mit LVM-Snapshots gemacht. Das ist klassisch. Dieser Ansatz wurde sehr h\u00e4ufig verwendet. Stateful-Knoten sind jedoch eine Herausforderung. Weil man sie nicht ignorieren darf, immer pr\u00e4sent sein muss\u2026<\/p>\n

NS<\/b>: Siehst du hier nicht eine M\u00f6glichkeit f\u00fcr ein Hybridsystem? Angenommen, der Stateful-Knoten ist ein Pod, der von mehreren Mitarbeitern (viele Tester) genutzt wird. Wir haben nur einen Speicher, aber dank des Dateisystems sind die Klone lokal. Wenn der Pod ausf\u00e4llt, bleibt die Festplatte \u2014 der Pod wird neu gestartet, erkennt alle Klone und gibt an: \u201eHier sind eure Klone, die auf diesen Ports laufen, arbeitet weiter damit.\u201c<\/i><\/p>\n

DS<\/b>: Technisch bedeutet das, dass es im Rahmen von Kubernetes ein Pod ist, innerhalb dessen wir viele Postgres-Instanzen starten.<\/p>\n

NS<\/b>: Ja. Es gibt ein Limit: Angenommen, nicht mehr als 10 Personen arbeiten gleichzeitig daran. Wenn 20 ben\u00f6tigt werden, starten wir einen zweiten solchen Pod. Es ist v\u00f6llig realistisch, ihn zu klonen und einen zweiten vollst\u00e4ndigen Volume zu erhalten, auf dem ebenfalls 10 \u201ed\u00fcnne\u201c Klone laufen. Siehst du diese M\u00f6glichkeit nicht?<\/i><\/p>\n

DS<\/b>: Hier m\u00fcssen Sicherheitsfragen hinzugef\u00fcgt werden. Diese Art der Organisation impliziert, dass dieser Pod hohe Privilegien (Capabilities) hat, da er nicht standardm\u00e4\u00dfige Operationen am Dateisystem durchf\u00fchren kann\u2026 Aber ich wiederhole: Ich glaube, dass Kubernetes mittelfristig den Storage reparieren wird, und in den Clouds wird die gesamte Geschichte mit den Volumes gel\u00f6st \u2014 alles wird \u00abeinfach funktionieren\u00bb. Es wird Resize, Klonen geben\u2026 Es gibt ein Volume \u2014 wir sagen: \u00abErstelle ein neues basierend auf diesem\u00bb \u2014 und innerhalb von anderthalb Sekunden haben wir, was wir brauchen.<\/p>\n

NS<\/b>: Ich glaube nicht an anderthalb Sekunden f\u00fcr mehrere Terabyte. Bei Ceph machst du das selbst, w\u00e4hrend du von Clouds sprichst. Geh in die Cloud, mach auf EC2 einen Klon eines EBS-Volumes mit vielen Terabytes und schau dir die Leistung an. Das wird keine paar Sekunden dauern. Ich bin sehr gespannt, wann sie dieses Leistungsniveau erreichen. Ich verstehe, wor\u00fcber du sprichst, aber ich erlaube mir, nicht einverstanden zu sein.<\/i><\/p>\n

DS<\/b>: In Ordnung, aber ich habe gesagt, dass ich mittel- bis langfristig spreche, nicht kurzfristig. Innerhalb von ein paar Jahren.<\/p>\n

\u00dcber den Operator f\u00fcr PostgreSQL von Zalando<\/h2>\n

\nMitte dieses Treffens kam auch Alexey Klyukin, ein ehemaliger Entwickler von Zalando, zu Wort, der die Geschichte des PostgreSQL-Operators erz\u00e4hlte:<\/p>\n

Es ist gro\u00dfartig, dass dieses Thema \u00fcberhaupt angesprochen wurde: Postgres und Kubernetes. Als wir 2017 bei Zalando damit anfingen, war es ein Thema, das alle interessierte, aber niemand k\u00fcmmerte sich darum. Alle hatten bereits Kubernetes, aber wenn man fragte, wie man es mit Datenbanken macht, sagten sogar solche Leute wie Kelsey Hightower<\/a><\/noindex>, die f\u00fcr K8s pl\u00e4dierten, etwa folgendes:<\/p>\n

\u201eGeht zu Managed-Services und nutzt diese, startet keine DB in Kubernetes. Andernfalls wird euer K8s zum Beispiel ein Upgrade machen, alle Knoten herunterfahren und eure Daten werden weit weg sein.\u201c<\/i><\/p>\n

Wir haben entschieden, einen Operator zu entwickeln, der entgegen diesem Rat Postgres-Datenbanken in Kubernetes starten wird. Und wir hatten eine gute Grundlage \u2013 Patroni<\/a><\/noindex>. Das ist ein automatischer Failover f\u00fcr PostgreSQL, der richtig umgesetzt wurde, d.h. etcd, consul oder ZooKeeper als Speichersystem f\u00fcr Clusterinformationen verwendet. So ein Speicher, der allen, die fragen, die gleiche Information \u00fcber den aktuellen Leader zur\u00fcckgibt \u2014 egal, dass alles verteilt ist \u2014 um Split-Brain zu vermeiden. Au\u00dferdem hatten wir ein Docker-Image<\/a><\/noindex> daf\u00fcr.<\/p>\n

Generell entstand der Bedarf an Auto-Failover in der Firma nach der Migration aus einem internen physischen Rechenzentrum in die Cloud. Die Cloud basierte auf einer eigenen PaaS-L\u00f6sung (Platform-as-a-Service). Diese ist Open Source, aber um sie einzurichten, musste man viel Arbeit investieren. Sie hie\u00df STUPS<\/a><\/noindex>.<\/p>\n

Urspr\u00fcnglich gab es kein Kubernetes. Genauer gesagt, als die eigene L\u00f6sung implementiert wurde, gab es bereits K8s, aber es war so unausgereift, dass es sich nicht f\u00fcr die Produktion eignete. Das war, glaube ich, 2015 oder 2016. Bis 2017 war Kubernetes mehr oder weniger ausgereift geworden \u2014 die Notwendigkeit zur Migration dorthin war gegeben.<\/p>\n

Wir hatten bereits einen Docker-Container. Es gab eine PaaS, die Docker verwendet hat. Warum nicht K8s ausprobieren? Warum nicht einen eigenen Operator schreiben? Murat Kabilov, der zu uns von Avito kam, hat dies als Projekt aus eigener Initiative begonnen \u2013 um ein bisschen zu experimentieren \u2013 und das Projekt hat Erfolg gehabt.<\/p>\n

Ich wollte jedoch eigentlich \u00fcber AWS sprechen. Warum gab es dort historisch gesehen Code, der mit AWS verkn\u00fcpft ist...<\/p>\n

Wenn Sie etwas in Kubernetes starten, sollten Sie verstehen, dass K8s ein kontinuierlicher Entwicklungsprozess ist. Es entwickelt sich st\u00e4ndig weiter, wird verbessert und geht gelegentlich auch mal kaputt. Man muss die \u00c4nderungen in Kubernetes genau im Auge behalten und bereit sein, sich tief damit auseinanderzusetzen und zu verstehen, wie es im Detail funktioniert \u2013 vielleicht mehr, als einem lieb ist. Das gilt im Grunde f\u00fcr jede Plattform, auf der Sie Ihre Datenbanken betreiben...<\/p>\n

Als wir den Operator entwickelten, hatten wir Postgres, das mit einem externen Volume (in diesem Fall EBS, da wir in AWS arbeiteten) verbunden war. Die Datenbank wuchs, und irgendwann war es notwendig, eine Gr\u00f6\u00dfen\u00e4nderung durchzuf\u00fchren: Zum Beispiel war die urspr\u00fcngliche EBS-Gr\u00f6\u00dfe 100 TB und die Datenbank hat diesen Betrag erreicht, nun m\u00f6chten wir EBS auf 200 TB erweitern. Wie geht das? Man k\u00f6nnte einen Dump\/Restore auf eine neue Instanz machen, aber das w\u00e4re zeitaufwendig und w\u00fcrde zu Ausfallzeiten f\u00fchren.<\/p>\n

Deshalb wollten wir ein Resize, das die EBS-Partition vergr\u00f6\u00dfert und dann das Dateisystem anweist, den neuen Speicherplatz zu nutzen. Und wir haben das geschafft, aber zu der Zeit hatte Kubernetes keine API f\u00fcr die Resize-Operation. Da wir auf AWS arbeiteten, haben wir Code f\u00fcr dessen API geschrieben.<\/p>\n

Es steht niemandem im Weg, das Gleiche f\u00fcr andere Plattformen zu tun. Der Operator ist nicht an AWS gebunden, er funktioniert auch auf anderen Plattformen. Letztlich ist es ein Open-Source-Projekt: Wenn jemand die Einf\u00fchrung eines neuen APIs beschleunigen m\u00f6chte \u2013 herzlich willkommen. Es gibt GitHub<\/a><\/noindex>, Pull-Requests \u2013 das Zalando-Team bem\u00fcht sich, darauf recht z\u00fcgig zu reagieren und den Operator voranzubringen. Soweit ich wei\u00df, hat das Projekt teilgenommen<\/a><\/noindex> im Google Summer of Code und \u00e4hnlichen Initiativen. Zalando arbeitet sehr aktiv daran.\n<\/p><\/blockquote>\n

<\/p>\n

P.S. Bonus!<\/h2>\n

\nWenn Sie sich f\u00fcr das Thema PostgreSQL und Kubernetes interessieren, m\u00f6chten wir auch darauf hinweisen, dass in der letzten Woche der n\u00e4chste Postgres-Dienstag stattfand, bei dem Nikolai sich mit Alexander Kukushkin von Zalando unterhielt.<\/b>. Das Video davon ist verf\u00fcgbar. hier<\/a><\/noindex>.<\/p>\n

P.P.S.<\/h2>\n

\nLesen Sie auch in unserem Blog:<\/p>\n