Datenspeichermuster in Kubernetes

Hey Habr!

Wir erinnern Sie daran, dass wir ein weiteres äußerst interessantes und nützliches Produkt veröffentlicht haben Buch über Kubernetes-Muster. Alles begann mit „Muster„Brendan Burns, und wir haben übrigens Arbeit in diesem Segment kocht. Heute laden wir Sie ein, einen Artikel aus dem MinIO-Blog zu lesen, der kurz die Trends und Besonderheiten der Datenspeichermuster in Kubernetes beschreibt.

Kubernetes hat die traditionellen Anwendungsentwicklungs- und Bereitstellungsmuster grundlegend verändert. Jetzt kann ein Team innerhalb weniger Tage eine Anwendung entwickeln, testen und bereitstellen – in mehreren Umgebungen, alle innerhalb von Kubernetes-Clustern. Solche Arbeiten mit früheren Technologiegenerationen dauerten normalerweise Wochen, wenn nicht Monate.

Diese Beschleunigung wird durch die von Kubernetes bereitgestellte Abstraktion ermöglicht – das heißt, weil Kubernetes selbst mit den Low-Level-Details physischer oder virtueller Maschinen interagiert und es Benutzern ermöglicht, den gewünschten Prozessor, die gewünschte Speichermenge und die Anzahl der Container zu deklarieren Instanzen und andere Parameter. Mit einer riesigen Community, die Kubernetes unterstützt, und seiner ständig wachsenden Akzeptanz ist Kubernetes mit großem Abstand der Marktführer unter allen Container-Orchestrierungsplattformen.

Mit zunehmender Nutzung von Kubernetes wächst auch die Verwirrung über seine Speichermuster..

Da jeder um ein Stück vom Kubernetes-Kuchen (d. h. Datenspeicherung) konkurriert, geht das Gespräch über Datenspeicherung in viel Lärm unter.
Kubernetes verkörpert ein modernes Modell für die Anwendungsentwicklung, -bereitstellung und -verwaltung. Dieses moderne Modell entkoppelt die Datenspeicherung von der Berechnung. Um die Trennung im Kontext von Kubernetes vollständig zu verstehen, müssen Sie auch verstehen, was zustandsbehaftete und zustandslose Anwendungen sind und wie die Datenspeicherung dazu passt. Hier hat der von S3 verwendete REST-API-Ansatz klare Vorteile gegenüber dem POSIX/CSI-Ansatz anderer Lösungen.

In diesem Artikel sprechen wir über Datenspeichermuster in Kubernetes und gehen insbesondere auf die Debatte zwischen zustandsbehafteten und zustandslosen Anwendungen ein, um besser zu verstehen, was der Unterschied zwischen ihnen ist und warum er wichtig ist. Der Rest des Textes befasst sich mit Anwendungen und ihren Datenspeichermustern im Hinblick auf Best Practices für die Arbeit mit Containern und Kubernetes.

Zustandslose Container

Container sind von Natur aus leicht und vergänglich. Sie können einfach gestoppt, entfernt oder auf einem anderen Knoten bereitgestellt werden – und das alles in Sekundenschnelle. In einem großen Container-Orchestrierungssystem passieren solche Vorgänge ständig, und Benutzer bemerken solche Änderungen nicht einmal. Verschiebungen sind jedoch nur möglich, wenn der Container keine Abhängigkeiten zu dem Knoten hat, auf dem er sich befindet. Solche Behälter sollen funktionieren staatenlos.

Zustandsbehaftete Container

Wenn ein Container Daten auf lokal angeschlossenen Geräten (oder auf einem Blockgerät) speichert, muss im Falle eines Ausfalls der Datenspeicher, auf dem er sich befindet, zusammen mit dem Container selbst auf einen neuen Knoten verschoben werden. Dies ist wichtig, da sonst die im Container ausgeführte Anwendung nicht ordnungsgemäß funktionieren kann, da sie auf Daten zugreifen muss, die auf lokalen Medien gespeichert sind. Solche Behälter sollen funktionieren Staatsbürgerlich.

Aus rein technischer Sicht können Stateful Container auch auf andere Knoten verschoben werden. Dies wird typischerweise durch verteilte Dateisysteme oder Block-Netzwerkspeicher erreicht, die an alle Knoten angeschlossen sind, auf denen Container ausgeführt werden. Auf diese Weise greifen Container auf Volumes zur dauerhaften Datenspeicherung zu und Informationen werden auf Festplatten im gesamten Netzwerk gespeichert. Ich werde diese Methode „Stateful-Container-Ansatz", und im Rest des Artikels werde ich es der Einheitlichkeit halber so nennen.

Bei einem typischen Stateful-Container-Ansatz sind alle Anwendungs-Pods an ein einziges verteiltes Dateisystem angeschlossen – eine Art gemeinsam genutzter Speicher, in dem sich alle Anwendungsdaten befinden. Obwohl einige Variationen möglich sind, handelt es sich hierbei um einen Ansatz auf hohem Niveau.

Schauen wir uns nun an, warum der Stateful-Container-Ansatz in einer Cloud-zentrierten Welt ein Anti-Pattern ist.

Cloud-natives Anwendungsdesign

Traditionell verwendeten Anwendungen Datenbanken zur strukturierten Speicherung von Informationen und lokale Festplatten oder verteilte Dateisysteme, in denen alle unstrukturierten oder sogar halbstrukturierten Daten gespeichert wurden. Als die Mengen unstrukturierter Daten zunahmen, stellten die Entwickler fest, dass POSIX zu gesprächig war, einen erheblichen Overhead verursachte und letztendlich die Anwendungsleistung bei der Umstellung auf wirklich große Mengen beeinträchtigte.

Dies trug vor allem zur Entstehung eines neuen Standards für die Datenspeicherung bei, nämlich des Cloud-basierten Speichers, der hauptsächlich auf der REST-API basiert und die Anwendung von der aufwändigen Wartung eines lokalen Datenspeichers befreit. In diesem Fall wechselt die Anwendung effektiv in den zustandslosen Modus (da sich der Zustand im Remotespeicher befindet). Moderne Anwendungen werden unter Berücksichtigung dieses Faktors von Grund auf entwickelt. In der Regel ist jede moderne Anwendung, die Daten der einen oder anderen Art (Protokolle, Metadaten, Blobs usw.) verarbeitet, nach einem Cloud-orientierten Paradigma aufgebaut, bei dem der Zustand an ein speziell für die Speicherung vorgesehenes Softwaresystem übertragen wird.

Der Stateful-Container-Ansatz zwingt dieses ganze Paradigma genau dorthin zurück, wo es begonnen hat!

Durch die Verwendung von POSIX-Schnittstellen zum Speichern von Daten funktionieren Anwendungen so, als wären sie zustandsbehaftet. Aus diesem Grund weichen sie von den wichtigsten Grundsätzen des cloudzentrierten Designs ab, d. h. der Möglichkeit, die Größe von Anwendungs-Worker-Threads abhängig vom Eingang zu variieren Eingabe, Wechsel zu einem neuen Knoten, sobald der aktuelle Knoten ausfällt, und so weiter.

Wenn wir uns diese Situation genauer ansehen, stellen wir fest, dass wir bei der Auswahl eines Datenspeichers immer wieder mit dem Dilemma POSIX vs. REST API konfrontiert sind, JEDOCH mit der zusätzlichen Verschärfung der POSIX-Probleme aufgrund der verteilten Natur von Kubernetes-Umgebungen. Insbesondere,

• POSIX ist gesprächig: Die POSIX-Semantik erfordert, dass jede Operation mit Metadaten und Dateideskriptoren verknüpft wird, die dabei helfen, den Status der Operation aufrechtzuerhalten. Dadurch entstehen erhebliche Kosten, die keinen wirklichen Wert haben. Objektspeicher-APIs, insbesondere die S3-API, machen diese Anforderungen überflüssig, sodass die Anwendung den Aufruf starten und dann „vergessen“ kann. Die Antwort des Speichersystems zeigt an, ob die Aktion erfolgreich war oder nicht. Wenn dies fehlschlägt, kann die Anwendung es erneut versuchen.
• Netzwerkbeschränkungen: In einem verteilten System bedeutet dies, dass möglicherweise viele Anwendungen versuchen, Daten auf dasselbe angeschlossene Medium zu schreiben. Daher konkurrieren nicht nur Anwendungen untereinander um Datenübertragungsbandbreite (um Daten an die Medien zu senden), sondern auch das Speichersystem selbst konkurriert um diese Bandbreite, indem es Daten über physische Festplatten sendet. Aufgrund der Geschwätzigkeit von POSIX erhöht sich die Anzahl der Netzwerkaufrufe um ein Vielfaches. Andererseits bietet die S3-API eine klare Unterscheidung zwischen Netzwerkaufrufen zwischen solchen, die vom Client an den Server ausgehen, und solchen, die innerhalb des Servers erfolgen.
• Sicherheit: Das POSIX-Sicherheitsmodell ist auf die aktive menschliche Beteiligung ausgelegt: Administratoren konfigurieren spezifische Zugriffsebenen für jeden Benutzer oder jede Gruppe. Dieses Paradigma lässt sich nur schwer an eine Cloud-zentrierte Welt anpassen. Moderne Anwendungen sind auf API-basierte Sicherheitsmodelle angewiesen, bei denen Zugriffsrechte als eine Reihe von Richtlinien definiert, Dienstkonten, temporäre Anmeldeinformationen usw. zugewiesen werden.
• Verwaltbarkeit: Zustandsbehaftete Container haben einen gewissen Verwaltungsaufwand. Wir sprechen über die Synchronisierung des parallelen Zugriffs auf Daten und die Sicherstellung der Datenkonsistenz. All dies erfordert eine sorgfältige Überlegung, welche Datenzugriffsmuster verwendet werden sollen. Zusätzliche Software muss installiert, überwacht und konfiguriert werden, ganz zu schweigen von zusätzlichem Entwicklungsaufwand.

Container-Datenspeicherschnittstelle

Während das Container Storage Interface (CSI) eine große Hilfe bei der Verbreitung der Kubernetes-Volume-Schicht war und diese teilweise an Speicher-Drittanbieter auslagerte, hat es unbeabsichtigt auch zu der Überzeugung beigetragen, dass der Stateful-Container-Ansatz die empfohlene Methode dafür ist Speichern von Daten in Kubernetes.

CSI wurde als Standard für die Bereitstellung beliebiger Block- und Dateispeichersysteme für Legacy-Anwendungen bei der Ausführung auf Kubernetes entwickelt. Und wie dieser Artikel gezeigt hat, ist ein Stateful-Container-Ansatz (und CSI in seiner aktuellen Form) nur dann sinnvoll, wenn es sich bei der Anwendung selbst um ein Legacy-System handelt, in dem es nicht möglich ist, Unterstützung für die Objektspeicher-API hinzuzufügen .

Es ist wichtig zu verstehen, dass wir bei der Verwendung von CSI in seiner aktuellen Form, d.

Ein besserer Ansatz

In diesem Fall ist es wichtig zu verstehen, dass die meisten Anwendungen nicht von Natur aus speziell für zustandsbehaftete oder zustandslose Arbeit konzipiert sind. Dieses Verhalten hängt von der gesamten Systemarchitektur und den getroffenen spezifischen Designentscheidungen ab. Lassen Sie uns ein wenig über zustandsbehaftete Anwendungen sprechen.

Grundsätzlich lassen sich alle Bewerbungsdaten in mehrere große Typen einteilen:

• Logdaten
• Zeitstempeldaten
• Transaktionsdaten
• Metadaten
• Containerbilder
• Blob-Daten (binäres großes Objekt).

Alle diese Datentypen werden auf modernen Speicherplattformen sehr gut unterstützt, und es gibt mehrere Cloud-native Plattformen, die darauf zugeschnitten sind, Daten in jedem dieser spezifischen Formate bereitzustellen. Transaktionsdaten und Metadaten können beispielsweise in einer modernen Cloud-nativen Datenbank wie CockroachDB, YugaByte usw. gespeichert sein. Container-Images oder Blob-Daten können in einer Docker-Registry auf Basis von MinIO gespeichert werden. Zeitstempeldaten können in einer Zeitreihendatenbank wie InfluxDB usw. gespeichert werden. Wir werden hier nicht im Detail auf jeden Datentyp und die damit verbundenen Anwendungen eingehen, aber die allgemeine Idee besteht darin, eine dauerhafte Datenspeicherung zu vermeiden, die auf der lokalen Festplattenmontage beruht.

Darüber hinaus ist es häufig effektiv, eine temporäre Caching-Schicht bereitzustellen, die als temporärer Dateispeicher für Anwendungen dient. Anwendungen sollten jedoch nicht auf diese Schicht als Quelle der Wahrheit angewiesen sein.

Zustandsbehafteter Anwendungsspeicher

Während es in den meisten Fällen nützlich ist, Anwendungen zustandslos zu halten, müssen Anwendungen, die zum Speichern von Daten konzipiert sind – wie Datenbanken, Objektspeicher, Schlüsselwertspeicher – zustandsbehaftet sein. Schauen wir uns an, warum diese Anwendungen auf Kubernetes bereitgestellt werden. Nehmen wir MinIO als Beispiel, aber ähnliche Prinzipien gelten auch für jedes andere große Cloud-native Speichersystem.

Cloud-native Anwendungen sind so konzipiert, dass sie die Flexibilität von Containern voll ausnutzen. Das bedeutet, dass sie keine Annahmen über die Umgebung treffen, in der sie eingesetzt werden. MinIO verwendet beispielsweise einen internen Erasure-Coding-Mechanismus, um dem System genügend Ausfallsicherheit zu verleihen, damit es auch dann betriebsbereit bleibt, wenn die Hälfte der Festplatten ausfällt. MinIO verwaltet außerdem die Datenintegrität und -sicherheit durch proprietäres serverseitiges Hashing und Verschlüsselung.

Für solche Cloud-zentrierten Anwendungen sind lokale persistente Volumes (PVs) als Backup-Speicher am praktischsten. Lokale PV bietet die Möglichkeit, Rohdaten zu speichern, während Anwendungen, die auf diesen PVs laufen, unabhängig Informationen sammeln, um Daten zu skalieren und wachsende Datenanforderungen zu bewältigen.

Dieser Ansatz ist viel einfacher und deutlich skalierbarer als CSI-basierte PVs, die ihre eigenen Ebenen der Datenverwaltung und Redundanz in das System einführen; Der Punkt ist, dass diese Schichten normalerweise im Konflikt mit Anwendungen stehen, die auf Zustandsbeurteilung ausgelegt sind.

Eine starke Bewegung hin zur Entkopplung von Daten und Berechnungen

In diesem Artikel haben wir darüber gesprochen, wie Anwendungen neu ausgerichtet werden, um ohne Zustandsspeicherung zu funktionieren, oder, mit anderen Worten, das Speichern von Daten von der darauf basierenden Berechnung entkoppelt wird. Schauen wir uns abschließend einige reale Beispiele dieses Trends an.

Spark, eine bekannte Datenanalyseplattform, ist traditionell zustandsbehaftet und wird auf HDFS bereitgestellt. Da Spark jedoch in eine Cloud-zentrierte Welt vordringt, wird die Plattform zunehmend zustandslos mit „s3a“ genutzt. Spark verwendet s3a, um den Status an andere Systeme zu übertragen, während Spark-Container selbst völlig zustandslos arbeiten. Insbesondere andere große Unternehmensakteure im Bereich Big Data Analytics: Vertica, Teradata, Grüne Pflaume Sie gehen auch dazu über, die Datenspeicherung und die darauf basierenden Berechnungen zu trennen.

Ähnliche Muster sind auch auf anderen großen Analyseplattformen zu beobachten, darunter Presto, Tensorflow to R, Jupyter. Durch die Auslagerung des Status auf Remote-Cloud-Speichersysteme wird die Verwaltung und Skalierung Ihrer Anwendung wesentlich einfacher. Darüber hinaus erleichtert es die Portabilität der Anwendung auf eine Vielzahl von Umgebungen.

Source: habr.com