Datenbank in den Wolken: an wen und warum - die Meinung von Data Egret-Spezialisten

Es wird angenommen, dass die Zukunft für DB as Service liegt. Lohnt es sich für alle, einen DBA zu starten und in eine öffentliche Cloud zu wechseln oder eine private Cloud auf Docker mit Kubernetes zu erstellen? Drei Experten von Data Egret - Alexei Lesovsky, Viktor Yegorov und Andrey Salnikov - auf dem # RuPostgres-Kanal live teilten ihre Ansichten darüber, für welche Projekte Cloud-Modelle geeignet sind.

Moderator und Moderator der Diskussion war Nikolay Samokhvalov, Gründer von Postgres.ai und Mitbegründer der RuPostgres.org-Community.



Unter dem Schnittprotokoll des Gesprächs.

- Heute sprechen wir über Postgres in den Wolken. Und ich beginne mit einer kniffligen Frage: Stimmt es, dass Sie mehr als die Hälfte der Kunden bereits in den Clouds haben?

Alexei: Ich denke nicht. Fühlt sich an wie weniger als die Hälfte. Jeder sitzt entweder in seinem eigenen Rechenzentrum oder mietet Eisenstücke.

Bevor wir jedoch über die Wolken sprechen, definieren wir die Begriffe. Was verstehen wir unter „Clouds“: Amazon, Google Cloud, DB as Service?

- Ich würde Postgres in der Cloud unterscheiden, die auf einer Amazon EC2-Instanz (oder einem Analogon von Google) erstellt wurde, wo Sie sich grob gesagt über ssh anmelden und die Konfiguration korrigieren können, und Postgres unter Kontrolle (auf Englisch „verwaltet“), wenn Sie direkt darauf zugreifen auf Dateiebene oder ohne ssh, aber es gibt nur die Möglichkeit, SQL-Abfragen zu verbinden und auszuführen. Sie sollten grundsätzlich getrennt betrachtet werden. Und meine erste Frage betraf verwaltete Postgres.

Alexei: Solche Kunden sind wesentlich weniger als die Hälfte.

Victor: Nun, im ersten Fall - welche wesentlichen Vorteile haben wir aus der Cloud? Was bedeutet die Wolke?

- Im ersten Fall können Sie mit verschiedenen modernen Tools wie Patroni und Kubernetes (wir werden sie separat behandeln) Elastizität, Microservices und all das erhalten. Dies ist nicht dasselbe wie nur ein Stück Eisen. Es ist wie "Haustiere gegen Herde" - die Einstellung, als Haustier zu bügeln, wächst zu einer Beziehung zu virtuellen Maschinen wie zu einer Herde. Sie wissen bereits nicht, welche Drüsen dort installiert sind. Sie haben sie nicht bestellt, Sie haben nicht mit dem Lieferanten zusammengearbeitet, Sie haben nicht über die Topologie nachgedacht. Sie können Zeit sparen.

Victor: Ja. Meiner Meinung nach vereinfacht der erste Fall einfach den Kauf von neuem Eisen. Sie wissen, was Sie brauchen: wie viele Kerne und RAM, welche Laufwerke. Und Sie wählen eine virtuelle Maschine aus dem, was sie Ihnen bietet. Es ist schnell. Andernfalls müssen Sie diesen Server weiterhin normal konfigurieren und warten.

- Und wie beurteilen Sie den durch virtuelle Maschinen verursachten Overhead (Prozesse innerhalb einer virtuellen Maschine, die nicht auf Bare-Metal-Basis sind, Performance-Overhead oder Verwaltungsschwierigkeiten)? Hat jemand von euch es gemessen?

Alexei: Der Overhead kann gemessen werden, wenn Sie die Kontrolle über den Hypervisor haben. Im öffentlichen Dienst ist es nicht - was sie geben, ist das, was Sie verwenden.

Der Overhead der üblichen Virtualisierungssysteme, die zu Hause bereitgestellt werden können (KVM, Xen), habe ich vor fünf Jahren gemessen und lag dann bei etwa 7-8%. Darüber hinaus hing es von den Einstellungen der virtuellen Maschine und der Arbeitslast ab. Zum Beispiel gab es bei Redis und Postgres deutlich mehr Overhead als bei Unicorn, das Rails-Backends bedient.

Vielleicht sind die Zahlen jetzt anders.

- Selbst 5-7% sind ein akzeptabler Overhead im Vergleich zu den Pluspunkten, über die Victor gesprochen hat.

Und wie ändern Sie die Zusammensetzung der Kunden: Gibt es eine Bewegung in Richtung Managed-Bases?



Alexey: Nein. Der Trend ist eher umgekehrt. Menschen, die mit Dingen wie RDS arbeiten, fehlt die Flexibilität bei der Verwaltung und Verwaltung. Infolgedessen erhalten wir die gleiche Einstellung wie Haustiere, jedoch in EC2-Fällen.

Victor: Diese Situation zeichnet sich ab. Es gibt Kunden, deren Hauptproduktionsbasis sehr beschäftigt ist. Natürlich werden sie auf die zugewiesenen Eisenstücke gelegt und unter ständiger Aufsicht. Wenn das Unternehmen wächst, erfordert die Entwicklung eine große Anzahl von Test- und Entwicklungsinstanzen, die in die Virtualisierung gehen. Dies ist ein hybrider Fall: In Tests und Entwicklungsumgebungen kann Hardware gekauft oder virtuelle Maschinen gemietet werden. Die Produktion bleibt jedoch auf einer normalen, seriösen Hardware.

- Wird Amazon RDS dafür verwendet?

Alexey: Unsere Kunden lehnen RDS im Gegenteil ab. Der Grund ist, wie gesagt, die mangelnde Flexibilität im Management.

Die Instanzen stürzen ab, und in einigen Fällen wird das Problem nicht nur durch das Mieten eines stärkeren Stücks Eisen gelöst.

Sie können viele Probleme nicht selbst lösen - nur mit Hilfe der Unterstützung.

- Kann man Beispiele nennen? Es scheint, dass Amazon kürzlich OpenSCG gekauft hat - großartige Leute, die das interne Know-how von Postgres hätten entwickeln sollen. Und ich weiß aus eigener Erfahrung, dass es eine Prüfung gibt. Wenn Sie ein Ticket mit Amazon RDS-Support öffnen und auf eine Person stoßen, die Ihnen nicht helfen kann, schließen Sie das Ticket einfach und öffnen Sie es erneut, um zu einem kompetenteren zu gelangen.

Alexey: OpenSCG ist natürlich ein Team von Fachleuten. Der Kauf eines solchen Teams schließt jedoch nicht 100% aller möglichen Situationen. Es gibt Probleme, die Gesichter zum ersten Mal unterstützen. Das passiert auch bei uns.

Bei einem der PostgreSQL 10.6-Replikate stieg der durchschnittliche Auslastungsgrad des Kunden auf dem Host plötzlich um 30 bis 40 Einheiten, obwohl keine Auslastung vorliegt. Solch ein unverständlicher Untergrundschlag. Es hat keinen großen Einfluss, aber das Bild des durchschnittlichen Sprunges der Last ist unverständlich. Und sie nervt die Administratoren des Kunden. Wir haben ein paar Hypothesen, was sie verursacht hat, aber bisher konnten wir sie nicht testen, da das System produktiv ist und dort nicht alles schnell erledigt werden kann.

Und solche "Untergrundschläge" treten ungefähr einmal im Jahr auf, und Sie beginnen, sich der Aufgabe kreativ zu nähern. Und Amazon RDS ist eine größere Anzahl von Instanzen, eine größere Anzahl von Installationen bzw. Tickets, und alle Arten von Situationen sind viel größer.



Andrew: Ich möchte hinzufügen, wie man RDS- und EC2-Instanzen vergleicht.
Wir hatten einen Kunden mit Produktion auf RDS. Er suchte Rat. Dev-Circuit befand sich in Microsoft Azure. Anscheinend wurde Azure ursprünglich als Haupt-Cloud-Dienst angesehen.

Ich habe die Dev-Circuit-Basis in EC2 von Azure auf Amazon gezogen, um näher an die Produktion heranzukommen, und Prognoseprobleme näherten sich der Produktdatenbank an.

Obwohl der EC2-Server doppelt so einfach war wie unter RDS-Instanzen und die Testlast höher als das Produkt war, waren die Ergebnisse in der Entwicklungsschaltung nach meinem Setup viel besser als in Amazon auf der RDS-Instanz in der Produktion.

Ich habe den Verdacht, dass RDS aufgrund des Mangels an PostgreSQL-Fachwissen im Unternehmen des Kunden mit der Standardkonfiguration verwendet wurde. Wir verdrehen alle Einstellungen.

Infolgedessen war der Kunde sehr beeindruckt. Ich wandte mich mit einem Vorschlag anstelle von RDS an das Management, um einfache Instanzen zu übernehmen und zu konfigurieren.

- Wie wurde übrigens gemessen, was ist besser, was ist schlechter?

Andrew: Der Kunde hat sich die Metriken seiner Anwendung angesehen, wie schnell die Daten heruntergeladen und verarbeitet wurden.

- Wir schimpfen jetzt mit RDS, aber es hat enorme Vorteile - es beseitigt viele Kopfschmerzen, die mit Bereitstellung, Sicherungen und Replikation verbunden sind. Sind Sie einverstanden?

Andrew: Ja. Und höchstwahrscheinlich war der Hauptgrund dafür, dass der Client in RDS blieb, genau der erwähnte Mangel an PostgreSQL-Fachwissen. Mit RDS bekommen sie alles, was sie brauchen, sie zahlen nur mehr für die Instanzen.

- Neben Amazon RDS gibt es noch andere Cloud-basierte verwaltete Postgres. Haben Sie zum Beispiel den Yandex-Service kennengelernt?

Andrei: Ich bin auf ihre virtuellen Maschinen gestoßen und habe sie nicht wirklich gemocht - NVMe-Laufwerke sind dort nicht sehr ehrlich. Tatsächlich sind Laufwerke über ein Netzwerk verbunden.

- Ehrliches NVMe (lokale Laufwerke) ist ebenfalls ein Problem. Google und Amazon haben NVMe, aber die Laufwerke sind kurzlebig. Wenn Sie die Instanz neu starten, verlieren Sie alle Daten, weil Sie eine andere virtuelle Maschine erhalten.

Andrei: Sie haben mich bei Yandex Cloud kommentiert, dass sie ehrliches NVMe in DB als Service haben, aber ich bin diesem Service noch nicht begegnet. Anscheinend gibt es auf der Ebene der Ressourcenbereitstellung eine etwas andere Architektur.

Sie arbeiten sehr hart an DB als Service, da sie ihn für ihre Services verwenden. Es gibt nur unterschiedliche Einstiegspunkte für externe Kunden und den internen Gebrauch.

- Und was denkst du, gibt es Aussichten für die russischen Postgres in der Cloud? Wird abheben oder nicht abheben?

Andrew:

Yandex hat ein exzellentes Team, ziemlich erfahren, mit gutem Fachwissen. Ich denke, sie werden abheben.

Erstens betreiben sie selbst viele Postgres (mehr als 1000 Datenbanken in ihren Projekten) und seitdem Exploit, alle Zapfen und wunden Stellen werden schneller funktionieren und reparieren. Ich denke, der Kunde wird den endgültigen Service von ziemlich guter Qualität erhalten.

Und es gibt eine Nachfrage nach solchen Lösungen. Nehmen Sie ein Startup, das zu Beginn aus verschiedenen Gründen nicht über das erforderliche Know-how in Postgres verfügen kann: teuer, sie sehen den Punkt nicht, probieren Sie verschiedene Technologien aus. Für ihn ist dies eine gute Lösung, da es bei solchen Diensten nur begrenzte „Wendungen“ gibt, die nicht verdreht werden sollten, und wenn dies der Fall ist, wird es meiner Meinung nach technischen Support geben.

Zwar steht Yandex Cloud noch am Anfang, und im Moment werden nicht so viele Funktionen angeboten.

- Wir haben Fragen aus dem Chatroom: Was halten Sie von der Tatsache, dass bei der Ausgabe von virtuellen Maschinen jemand physisch auf dieser Maschine sitzen kann (Drosselung, Zeit stehlen).



Victor: Ja, es gibt so eine Erfahrung. Ich wollte es nur erwähnen. Es gibt Clients, für die eigene Virtualisierungssysteme bereitgestellt werden. Von Zeit zu Zeit fragen sie nach einem Nicht-Produkt-Server, und wir sehen eine unverständliche Situation: Wir beobachten nicht die Gründe, warum er auf diesem Server ausfallen sollte. Anschließend leiten wir Fragen an ihre Administratoren weiter, um zu erfahren, was auf dem Host geschieht.

- Und was tun, gibt es einen ähnlichen Effekt bei Amazon? Gibt es Methoden, um festzustellen, ob Sie "gequetscht" sind? pgbench fahren?

Alexei: Daran kann ich mich nicht erinnern. Aber der übliche Weg ist, durch Diebstahlzeit zu bestimmen. In den Überwachungsgraphen sehen wir in der Regel keine großen Werte.

- Ich habe das Gefühl, dass Sie verwaltete Postgres nicht wirklich mögen. Liegt es daran, dass RDS Ihre Arbeit übernimmt?

Alexey: Nein. Dies liegt eher daran, dass wir es einfach nicht haben. Managed Postgres ist gut, da Sie die Infrastruktur auf Knopfdruck bereitstellen können. Solange Sie ein Startup sind und nur Daten ohne komplexe Logik hinzufügen oder lesen, ist alles in Ordnung. Und wenn Sie beispielsweise eine bestimmte Linie überschreiten, beginnen Sie, viele JOINs auszuführen, führen komplexes SQL aus, die Aufgabe besteht darin, Abfragen zu optimieren, und RDS reicht nicht mehr aus. Es erfordert mehr Freiheit und Einfluss, aber die verfügbaren Tools helfen Ihnen nicht, die tiefgreifenden Probleme zu lösen, die mit der Entsorgung von Ressourcen innerhalb von Postgres selbst verbunden sind. Es gibt nur die Möglichkeit, die Kraft des Eisenstücks zu erhöhen: mehr Geld bezahlt - erhalten.

Andrew: Es gibt nicht so viel Abneigung gegen RDS und Angst vor Arbeit. Das Problem ist anders. Angenommen, ein Startup nimmt RDS, er gibt ihnen alles. Aber er hat sein Fachwissen in Postgres nicht erweitert. Als nächstes sagen wir einen Startschuss. Die Lasten wachsen - Schreiben und Lesen haben zugenommen. In Ermangelung seines Fachwissens muss ein Startup nebenbei nach Menschen suchen. Schwere Datenbankadministratoren stellen fest, dass sie nicht mehr aus RDS herausholen können, aber mit einer regulären EC2-Instanz ist es durchaus möglich, mehr Leistung zu erzielen, wie in dem zuvor erwähnten Beispiel. Wenn wir auf RDS erlaubt wären, könnten wir vielleicht die Datenbank optimieren und verbessern, aber wir haben es nicht getan.

- Das Problem mit dem Zugriff wird behoben. Es gibt verwaltete Postgres, die SSH-Zugriff bieten (und sogar vollständig root sind), zum Beispiel eine kleine Firma Aiven aus Finnland. Standardmäßig gewähren sie keinen Root-Zugriff, aber der Gründer (und ich haben ein paar Mal mit ihm gesprochen) sprach über seine Bereitschaft, auf Anfrage Zugriff zu gewähren.

Andrew: Das Problem ist nicht nur der Zugang. Warum sind wir mit reinen Drüsen besser dran? Weil wir viele verschiedene Kunden haben und jeder seine eigene Infrastruktur hat. Und die Infrastrukturen sind so weit voneinander entfernt, dass wir die allgemeine Methodik, die überall gleich funktioniert, einfach nicht können. Weil es diejenigen gibt, die ihre eigene Hardware haben und einfach nicht irgendwo hosten können (gemäß einigen ihrer eigenen Regeln und Einschränkungen), und es gibt diejenigen, die sich in den Clouds befinden.

- Sie möchten sagen, dass die Definition nicht verwendeter Indizes vom Stück Eisen abhängt? Oder andere alltägliche Dinge?

Andrew: Aus Sicht der Verwaltung ist es das Datenbankschema und die Definition nicht verwendeter Indizes, dass sich die Clouds nicht von ihrer Hardware unterscheiden. Alles ist vereinheitlicht.

Der Unterschied zwischen einer Cloud und einer realen Hardware - in der Schicht zwischen der Basis und speziell der darunter liegenden Hardware - ist das Betriebssystem und die verwendeten Virtualisierungen. Wenn Sie über große Datenbanken verfügen, ist es wichtig, wie schnell die Laufwerke Daten senden und empfangen, wie effizient Speicher und Prozessor verwendet werden. Daher ist es äußerst wichtig, den Einfluss dieser Schicht zu verringern, damit die Datenbank am effizientesten funktioniert.

- Eine weitere Frage des Publikums: Was ist mit den Kerneleinstellungen?

Victor: In EC2 sind solche Dinge anpassbar.

- Neben Amazon und Google gibt es neue Lösungen für die Klasse "Managed Postgres" von bekannten Anbietern. Zum Beispiel kündigten Nutanix und SAP 2018 die Schaffung von Postgres-basierten Lösungen an. Glauben Sie nicht, dass all diese Leute uns dazu führen, dass einige Entscheidungen getroffen werden, die dasselbe bewirken, aber nur auf Ihrem Stück Eisen? Damit können Sie auf die Schaltfläche klicken und die neuen Postgres bereitstellen, in denen Sicherungen und Replikationen bereits konfiguriert sind.

Alexei: Es scheint mir, dass SAP und andere nicht ganz profitabel sind. Dies sind große Anbieter von Eisen und Software. Sie machen ein Produkt mit dem Ziel, Geld zu verdienen. Verkaufe zumindest Support. Deshalb müssen wir uns ansehen, wie sie davon profitieren werden. Wenn ein solches Produktlieferungsmodell für sie von Vorteil ist, warum dann nicht?

- Ich meinte ein bisschen anders. Insbesondere werden diese Jungs nichts in Open Source posten und kostenlos verschenken. Aber glaubst du nicht, dass jemand aus dem kleineren, aber munteren so etwas tun wird? Vielleicht konzentriert sich dies auf Kubernetes, Operator Framework. Es gibt bereits einige Entwicklungen, die die Betreiber durchführen - zum Beispiel Zalando. Und glauben Sie nicht, dass Cloud-basiertes RDS einen schrittweisen Übergang zu solchen Lösungen ermöglicht? Wir sehen, wie Sie leben können, ohne mit Ihren Händen in die Konfiguration zu klettern.

Alexey: Es stellt sich heraus, dass es nicht ganz gelungen ist.

Trotzdem benötigen Sie Spezialisten, die all dies überwachen und unter die Motorhaube klettern, wenn etwas schief geht.

Sogar die Kubernetes sind eine sehr komplexe Maschine mit vielen Komponenten unter der Haube. Formal sind dies nur fünf Binärdateien. Ihre Interaktion untereinander wird jedoch durch umfangreiche Dokumentationen und viele Informationen zu Chatrooms, Newslettern und Google Groups beschrieben. Das heißt, Sie brauchen noch einen Spezialisten, der dieser Küche folgt.

Außerdem entwickelt sich das alles sehr dynamisch. Die Abwärtskompatibilität wird von Version zu Version unterbrochen. Das heißt, alles ist sehr instabil und instabil. Wenn sich alles beruhigt hat, bekommen wir vielleicht ein geeignetes Produkt, stabil und zuverlässig. Aber bisher ist nicht alles sehr.

Victor: Wir fangen an, über die Tatsache zu sprechen, dass wir eine zusätzliche Infrastrukturschicht haben, die verwaltet werden muss - um diese Kubernetes zu orchestrieren.

Ich bin nicht der Meinung, dass er immer auf Knopfdruck magisch arbeiten wird, wie wir es wollen. Es ist notwendig, relevante Spezialisten zu halten.

Und zweitens - unsere Kunden passen sich ständig an geschäftliche Veränderungen an. Dementsprechend ändert sich die Last in der Datenbank ständig. Und wenn wir vor drei Monaten alles geleckt haben, wodurch alle Anfragen so funktionierten, wie sie sollten, und alles in Ordnung war, kann eine neue Anfrage heute oder morgen eingehen, oder aufgrund von Datenänderungen funktioniert die vorhandene Anfrage nicht mehr so, wie sie sollte. Und wir müssen die Situation analysieren und in die Systemeinstellungen gelangen. Und dies ist diese Automatisierung, die meiner Meinung nach solche verwalteten Instanzen sehr schwierig macht. Wann die Wolken einen solchen Zustand erreichen, dass sie sich auch an solche Situationen anpassen, weiß ich nicht. Dies ist zwar ein wesentlicher Teil der zu erledigenden Arbeit, es ist jedoch erforderlich, die Datenbankeinstellungen an Änderungen im Muster eingehender Anforderungen anzupassen.

Und da die Cloud selbst einen zusätzlichen Verwaltungsaufwand darstellt, ist es für uns einfacher, wenn diese Schicht einfach nicht vorhanden ist, da wir uns auf die Probleme der Datenbank konzentrieren können.

Wenn der Kunde in der Cloud leben möchte und über das Fachwissen verfügt, haben wir nichts dagegen. Die Hauptsache ist, dass wir die Möglichkeit haben, wenn die Datenbank nicht sehr gut wird, zu klettern (vorzugsweise per SSH), alles zu überprüfen und Zugriff auf alle Statistiken zu erhalten.

Alexey: Nicht unbedingt von ssh. In jedem Fall werden jedoch Diagnosewerkzeuge benötigt. Weil die Diagnose per E-Mail sehr lang und langwierig ist. Es ist ärgerlich, wenn Sie einen Chat-Link an die auszuführende Anfrage senden. Der Client hingegen klickt auf diesen Link, kopiert die Anfrage, kopiert das Ergebnis an Sie oder sendet einen Screenshot. Das ist die ganze Zeit.

Es ist viel einfacher, eine Verbindung herzustellen und direkt zu sehen, einige Ihrer Hypothesen zu testen und weiter von ihnen entfernt zu handeln.

- Haben Sie aktive Beispiele dafür, wo Kubernetes bereits verwendet wird und Postgres darin lebt?

Alexei: Leider nicht. Aber ich würde wirklich gerne. Ich mag Kubernetes sehr, ich bin nah an seinem Konzept und seiner Philosophie.

Meiner Meinung nach ist Kubernetes so etwas, das Menschen dazu ermutigt, mehr zu programmieren, ein Produkt mehr zu entwickeln, ohne über Nebeneffekte wie die interne Struktur der Infrastruktur nachzudenken.

Eine ähnliche Rolle spielte früher OOP. Es schien, und viele Leute interessierten sich für diesen Bereich, weil die Programmierung etwas einfacher geworden ist. Kubernetes schließt auch viele Dinge für sich, versteckt sie unter der Haube und ermöglicht es einer Person, sich auf den kreativen Aspekt zu konzentrieren und mehr zu programmieren.

Kubernetes implementiert Unterstützung für Instanzen, Herde und die Anwendung funktioniert. Wenn es plötzlich abstürzt - na ja, dann startet Kubernetes es erneut. Das heißt, Entwickler und Administrator sind frei von Kopfschmerzen und ständiger Nachverfolgung. Ich mag diese Reaktion auf die Situation. Wenn etwas fällt, wird es automatisch neu gestartet.

, , . — , , . .

– , ?

: , . , . - , . , , Kubernetes. Kubernetes . CNCF . , .

– - kubernetes_ru. github, Kubernetes: . Postgres, .

, , , . , Kubernetes – , . - IT.

– , Amazon Aurora PostgreSQL Serverless ? , , . , . Das heißt, .

:

. .

, . , , . : , . , - . .

– . . , , .

: . , . , , – . , , , , .

Das heißt, . – , , 70% . . .

, , « », .

– . , , DBA : - , - — , ?

: , , , – DBA, SQL-developer. Oracle SQL-developer, , , , . , Oracle. . DBA , - .

DBA — - «» , .

Kubernetes. , . . , Kubernetes . , volume . Das heißt, , . , .

– ?

: .

, . , , . , Postgres ( ). Postgres - . Das heißt, (, ), .

, .

, , . . . .

– ?

: - . , , .

, Cassandra. . Das heißt, — , Kubernetes.

, , . , , .

Das heißt, . DBA, , – . , , - – .

– ?

: . , . , , , Kubernetes . , , , , - - Kubernetes ( ).

: Kubernetes. – patroni. Zalando Kubernetes. , , ( – , Amazon , ). , – . , – . – - Kubernetes.

– RDS. EC2 Postgres . patroni ( https://github.com/zalando/patroni ), .

: , , - high availability.

– . — , ?

: , - .
Zalando DBA, patroni. Das heißt, , Kubernetes , DBA .

– . DBA, DBA «» «».

: , . . , , .

– - Kubernetes? ?

: - , . Kubernetes – , . Kubernetes - . . DBA. Kubernetes (, Kubernetes , , ).

- , , - - -.

: ( Kubernetes ), - . , — — . - , , , , , , .

Victor:

. Kubernetes , . , . .

, — . , Postgres- , , . .

: …

– .. : - — dev environment, production – Kubernetes. ...

: latency , , . .

– , . .
, HighLoad++ .

PS .