{"id":71858,"date":"2020-02-28T21:00:08","date_gmt":"2020-02-28T18:00:08","guid":{"rendered":"https:\/\/prohoster.info\/blog\/patterny-hraneniya-dannyh-v-kubernetes"},"modified":"2020-03-03T16:14:09","modified_gmt":"2020-03-03T13:14:09","slug":"patterny-hraneniya-dannyh-v-kubernetes","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/patterny-hraneniya-dannyh-v-kubernetes","title":{"rendered":"Datenablage-Muster in Kubernetes.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Datenablage-Muster<\/a><\/noindex>
\nHallo, Habr!<\/p>\n

Wir erinnern Sie daran, dass wir einen weiteren \u00e4u\u00dferst interessanten und n\u00fctzlichen Buch<\/a><\/noindex> \u043e \u043f\u0430\u0442\u0442\u0435\u0440\u043d\u0430\u0445 Kubernetes. \u041d\u0430\u0447\u0438\u043d\u0430\u043b\u043e\u0441\u044c \u0432\u0441\u0435 \u0435\u0449\u0435 \u0441 "Patterns<\/a><\/noindex>" \u0411\u0440\u0435\u043d\u0434\u0430\u043d\u0430 \u0411\u0435\u0440\u043d\u0441\u0430, \u0438, \u0432\u043f\u0440\u043e\u0447\u0435\u043c, \u0440\u0430\u0431\u043e\u0442\u0430 \u0432 \u044d\u0442\u043e\u043c \u0441\u0435\u0433\u043c\u0435\u043d\u0442\u0435 \u0443 \u043d\u0430\u0441 sehr aktiv<\/a><\/noindex>. Heute m\u00f6chten wir Ihnen einen Beitrag aus dem MinIO Blog vorstellen, der die Trends und Besonderheiten der Datenspeicher-Patterns in Kubernetes zusammenfasst.
\n<\/a><\/noindex><\/p>\n

Kubernetes hat die traditionellen Patterns f\u00fcr die Entwicklung und Bereitstellung von Anwendungen grundlegend ver\u00e4ndert. Nun kann das Team in nur wenigen Tagen eine Anwendung entwickeln, testen und bereitstellen \u2013 in verschiedenen Umgebungen, und das alles innerhalb von Kubernetes-Clustern. Mit Technologien fr\u00fcherer Generationen ben\u00f6tigte man daf\u00fcr in der Regel Wochen, wenn nicht Monate.<\/p>\n

Diese Beschleunigung wurde durch die Abstraktion erm\u00f6glicht, die Kubernetes bietet \u2013 das hei\u00dft, Kubernetes \u00fcbernimmt selbst die Interaktion mit den niedrigstufigen Details physischer oder virtueller Maschinen. Benutzer k\u00f6nnen unter anderem die ben\u00f6tigte CPU, den gew\u00fcnschten Arbeitsspeicher und die Anzahl der Containerinstanzen angeben. Da eine riesige Gemeinschaft die Unterst\u00fctzung von Kubernetes \u00fcbernimmt und der Umfang seiner Anwendung st\u00e4ndig w\u00e4chst, f\u00fchrt es mit gro\u00dfem Abstand unter allen Plattformen zur Orchestrierung von Containern.<\/p>\n

Mit der zunehmenden Verbreitung von Kubernetes w\u00e4chst auch die Verwirrung \u00fcber die angewandten Datenmuster.<\/b><\/i>.<\/p>\n

In einem wettbewerbsintensiven Umfeld um das Datenlager Kubernetes (also um den Speicher) geht das Signal beim Thema Datenspeicherung im starken Rauschen unter.
\nKubernetes verk\u00f6rpert ein modernes Modell f\u00fcr die Entwicklung und Bereitstellung von Anwendungen sowie deren Verwaltung. Dieses moderne Modell trennt die Datenspeicherung von den Rechenoperationen. Um diese Trennung im Kontext von Kubernetes vollst\u00e4ndig zu verstehen, ist es auch notwendig zu erkennen, was zustandsbehaftete und zustandslose Anwendungen sind und wie dies mit der Datenspeicherung zusammenh\u00e4ngt. Hierbei bietet der REST-API-Ansatz von S3 klare Vorteile im Vergleich zu dem POSIX\/CSI-Ansatz, der f\u00fcr andere L\u00f6sungen charakteristisch ist.<\/p>\n

In diesem Artikel werden wir die Muster der Datenspeicherung in Kubernetes besprechen und speziell auf die Debatte \u00fcber zustandsbehaftete und zustandslose Anwendungen eingehen, um die Unterschiede zwischen ihnen richtig zu verstehen und deren Bedeutung zu erl\u00e4utern. Weiterhin werden die in Anwendungen verwendeten Datenspeicherungsmuster im Lichte der besten Praktiken f\u00fcr den Umgang mit Containern und Kubernetes betrachtet.<\/p>\n

Zustandslose Container<\/h4>\n

\nContainer sind von Natur aus leicht und verg\u00e4nglich. Sie k\u00f6nnen problemlos gestoppt, entfernt oder auf einem anderen Knoten bereitgestellt werden \u2013 all dies geschieht in wenigen Sekunden. In einem umfangreichen System zur Orchestrierung von Containern kommen solche Vorg\u00e4nge st\u00e4ndig vor, und die Benutzer bemerken diese Ver\u00e4nderungen nicht einmal. Allerdings sind Verschiebungen nur m\u00f6glich, wenn der Container keine Abh\u00e4ngigkeiten von dem Knoten hat, auf dem er sich befindet. Man spricht von Containern, die arbeiten ohne Zustandsspeicherung<\/i>.<\/p>\n

Container mit Zustandsspeicherung<\/h4>\n

\nWenn ein Container Daten auf lokal angeschlossenen Ger\u00e4ten (oder auf einem Blockger\u00e4t) speichert, muss der Datenspeicher, auf dem er sich befindet, zusammen mit dem Container auf einen neuen Knoten verschoben werden \u2013 im Falle eines Ausfalls. Dies ist wichtig, da die in dem Container ausgef\u00fchrte Anwendung ansonsten nicht korrekt funktionieren kann, da sie auf die auf den lokalen Speichermedien gespeicherten Daten zugreifen muss. Man spricht von Containern, die arbeiten mit Zustandsspeicherung<\/i>.<\/p>\n

Aus rein technischer Sicht k\u00f6nnen auch zustandsbehaftete Container auf andere Knoten verschoben werden. Dies wird normalerweise durch verteilte Dateisysteme oder blockbasierte Netzwerkdatenspeicher erm\u00f6glicht, die an alle Knoten angeschlossen sind, auf denen die Container laufen. Dadurch erhalten die Container Zugriff auf Volumes f\u00fcr die persistente Speicherung von Daten, und die Informationen werden auf Festplatten gespeichert, die im gesamten Netzwerk verteilt sind. Ich nenne diese Methode \u00abzustandsbehafteter Containeransatz<\/i>\u00bb, und im weiteren Verlauf des Artikels werde ich ihn so zur Einheitlichkeit benennen.<\/p>\n

\"Datenablage-Muster
\n
\nBei dem typischen zustandsbehafteten Containeransatz werden alle Pods der Anwendungen an ein einziges verteiltes Dateisystem angeh\u00e4ngt \u2013 es entsteht eine Art gemeinsamer Speicher, in dem alle Anwendungsdaten verwaltet werden. Obwohl es einige Variationen geben kann, ist dies ein hochgradiger Ansatz.<\/p>\n

Lassen Sie uns nun untersuchen, warum der zustandsbehaftete Containeransatz in einer cloudorientierten Welt ein Antipattern ist.<\/p>\n

Cloud-orientierte Anwendungsarchitektur<\/h4>\n

\nTraditionell verwendeten Anwendungen Datenbanken f\u00fcr die strukturierte Speicherung von Informationen und lokale Laufwerke oder verteilte Dateisysteme, in die alle unstrukturierten oder sogar halbstrukturierten Daten abgelegt wurden. Mit dem Wachstum der unstrukturierten Datenmengen erkannten die Entwickler, dass POSIX zu \"gespr\u00e4chig\" ist, erhebliche Kosten verursacht und letztlich die Leistung der Anwendung bei der Skalierung auf wirklich gro\u00dfe Umf\u00e4nge behindert.<\/p>\n

Dies hat in erster Linie zur Entstehung eines neuen Standards f\u00fcr die Datenspeicherung beigetragen, n\u00e4mlich cloudbasierter Speicher, der haupts\u00e4chlich auf REST-APIs basiert und Anwendungen von der belastenden Wartung lokaler Datenspeicher befreit. In diesem Fall arbeitet die Anwendung faktisch im Zustand ohne Speicherung (da der Zustand in einem entfernten Speicher liegt). Moderne Anwendungen werden von Grund auf unter Ber\u00fccksichtigung dieses Faktors entwickelt. In der Regel basiert jede moderne Anwendung, die irgendeine Art von Daten verarbeitet (Protokolle, Metadaten, Blobs usw.), auf dem cloudbasierten Paradigma, bei dem der Zustand in ein speziell daf\u00fcr vorgesehenes Softwaresystem \u00fcbertragen wird. <\/p>\n

Der containerbasierte Ansatz mit Zustandsspeicherung zwingt dieses gesamte Paradigma genau dorthin zur\u00fcck, wo es urspr\u00fcnglich begonnen hat! <\/b><\/i><\/p>\n

Wenn Anwendungen POSIX-Schnittstellen zur Datenspeicherung verwenden, verhalten sie sich \u00e4hnlich, als w\u00fcrden sie ihren Zustand speichern. Dadurch weichen sie von den wichtigsten Grunds\u00e4tzen des cloudbasierten Designs ab \u2014 insbesondere von der F\u00e4higkeit, die Gr\u00f6\u00dfe der Arbeitslasten an die eingehende Nachfrage anzupassen, auf einen neuen Knoten zu wechseln, sobald der aktuelle Knoten ausf\u00e4llt, und so weiter.<\/p>\n

Ein genauerer Blick auf diese Situation zeigt, dass wir bei der Auswahl eines Datenspeichers immer wieder mit dem Dilemma \u201ePOSIX gegen REST API\u201c konfrontiert werden, wobei es jedoch zus\u00e4tzliche Probleme gibt, die durch die verteilte Natur von Kubernetes-Umgebungen verst\u00e4rkt werden. Insbesondere<\/p>\n