Eine Sache, die oft \u00fcbersehen wird, ist die Frage, wie man auf Daten in einem Kubernetes-Cluster mit mehreren Nodes zugreifen und sie speichern kann und welche Infrastruktur daf\u00fcr ben\u00f6tigt wird. Da wir hier mehrere Optionen haben, m\u00f6chte ich dieses Thema n\u00e4her beleuchten und die Unterschiede erl\u00e4utern.<\/p>\n\n\n\n
Warum muss man sich entscheiden?<\/h2>\n\n\n\n
H\u00e4ufig werden Anwendungen direkt auf einem einzigen Server (VM oder Bare Metal) ausgef\u00fchrt, da die Rechenleistung eines Computers f\u00fcr den jeweiligen Anwendungsfall ausreicht. Wenn noch andere Anwendungen laufen, werden diese entweder auf demselben Rechner oder auf einer anderen einzelnen Instanz betrieben. Das Speichern von Daten ist einfach, da die Anwendung nur auf einer lokalen Festplatte lesen und schreiben muss. Diese Architektur entwickelt sich meist aus historischen und wirtschaftlichen Gr\u00fcnden, da kein Load Balancer oder kompliziertes Cluster-Setup erforderlich ist. Basierend auf dem letzten Abschnitt l\u00e4sst sich der Zugriff auf das Speichersystem in Kubernetes in zwei Typen unterteilen:<\/p>\n\n\n\n Der Unterschied ist einfach zu erkl\u00e4ren. Wenn auf einen Speicherort nur ein \u00abWriter\u00bb (eine Anwendung, die Daten schreiben oder l\u00f6schen will) auf einen Node und zu einem bestimmten Zeitpunkt zugreifen kann, wird die Zugriffsart RWO genannt. Es kann sein, dass weitere Anwendungen, die auf anderen Nodes laufen, Lesezugriff auf diesen Speicherort erhalten k\u00f6nnen, aber das h\u00e4ngt vom verwendeten System ab. Wenn eine Anwendung auf Partitionen oder ganze Festplatten zugreift, sprechen wir im Allgemeinen von Block Storage (da auf Festplattenbl\u00f6cke direkt zugegriffen wird). Normalerweise legen wir ein Dateisystem an und stellen es den Anwendungen zur Verf\u00fcgung, die auf diesem einen Node laufen (Block Storage ist also ein Vertreter der Kategorie \u00abRWO-Zugriff\u00bb). Remote Block Storage kann im Falle eines Ausfalls oder einer Wartung oft an einen anderen Node angebunden werden und bietet daher Fehlertoleranz auf Maschinenebene. Persistent Node Local Block Storage hingegen ist an einen bestimmten Node gebunden, kann aber sinnvoll sein, wenn Bare-Metal-Server Teil des Kubernetes-Clusters sind und die Anwendung sehr schnellen Zugriff auf den Speicherort ben\u00f6tigt. Allerdings sind alle Anwendungen, die Persistent Node Local Block Storage verwenden, an diesen einen Server gebunden, und im Falle eines Ausfalls kann die Anwendung daher nicht ausgef\u00fchrt werden. M\u00f6glicherweise k\u00f6nnen in einem solchen Fall spezielle fehlerbehebende Algorithmen in der Anwendung selbst eingesetzt werden (in diesem Fall kommuniziert die Software selbst mit anderen Instanzen und kann sich bei Ausf\u00e4llen selbst reparieren), aber im Allgemeinen empfehlen wir die Verwendung von Fast Remote Block Storage, da dieser in den meisten F\u00e4llen mehr Flexibilit\u00e4t bietet (auch in Bezug auf die Speichererweiterung). Wir betreiben zum Beispiel alle unsere NKE-Cluster auf virtuellen Maschinen und unterst\u00fctzen standardm\u00e4ssig\u00a0Fast Remote Block Storage<\/a> statt Persistent Node Local Block Storage. Im Gegensatz zu Block Storage erm\u00f6glicht File Storage (wie der Name schon sagt) die gemeinsame Nutzung von Dateien durch mehrere verteilte Clients, indem ein gemeinsames Dateisystem genutzt wird. Anwendungen, die auf Kubernetes laufen, k\u00f6nnen auf diese Dateien zugreifen, als w\u00e4ren es lokale Dateien. Da fast jede Programmiersprache den Zugriff auf Dateien erm\u00f6glicht, ist die Verwendung von File Storage meist die erste Wahl, wenn ein verteilter Lese- und Schreibzugriff erforderlich ist. L\u00f6sungen wie NFS, CIFS, CephFS oder GlusterFS implementieren eine derartige L\u00f6sung. Neben den eben erw\u00e4hnten File-Storage-L\u00f6sungen erfreut sich Object Storage zunehmender Beliebtheit, da diese Speicherart ebenfalls einen verteilten Lese- und Schreibzugriff erm\u00f6glicht. Anstelle von Dateien werden die Daten in Objekten gespeichert, die eine eindeutige ID in einem \u00abFlat Namespace\u00bb (Bucket) haben. Jedes Objekt ist ausserdem mit Metadaten versehen (sodass eine Suche m\u00f6glich ist). Aber es gibt auch einige Nachteile bei Object Storage und dessen Implementierungen. Objekte k\u00f6nnen nur als Ganzes geschrieben werden. Das bedeutet, dass ein Objekt nicht ge\u00f6ffnet werden kann, um es zu erg\u00e4nzen (wie es bei File Storage m\u00f6glich ist). Man m\u00fcsste das gesamte Objekt herunterladen, die Daten in der Anwendung anh\u00e4ngen und alle Daten erneut hochladen. Der Zugriff auf Object Storage ist oft langsamer als auf File Storage, sodass Anwendungen, die einen schnellen Zugriff auf Daten ben\u00f6tigen, m\u00f6glicherweise zwischengespeichert werden oder auf eine File-Storage-L\u00f6sung zur\u00fcckgreifen m\u00fcssen. Um den Zugriff auf Object-Storage-Systeme zu beschleunigen, sollten die Anfragen nach M\u00f6glichkeit parallel erfolgen. Es gibt auch Unterschiede im Funktionsumfang (und der Qualit\u00e4t) von Object-Storage-L\u00f6sungen, die den Zugriff \u00fcber das gleiche Protokoll erm\u00f6glichen.<\/p>\n\n\n\n F\u00fcr unsere Kund*innen bieten wir eine S3-kompatible Object-Storage-L\u00f6sung, gehostet in Schweizer Rechenzentren.<\/p>\n\n\n\n Wenn die Anwendung nur aus einer einzigen Instanz besteht und nur selbst Lese- und Schreibzugriff ben\u00f6tigt, sollte ein schneller Block Storage die Wahl sein. Er erm\u00f6glicht im Falle eines Ausfalls ein Failover auf einen anderen Node und bietet eine gute Leistung.<\/p>\n\n\n\n Wenn verteilte Lese- und Schreibzugriffe ben\u00f6tigt werden, bevorzugen wir die Verwendung von Object Storage gegen\u00fcber File Storage (wenn dein Anwendungsfall dies zul\u00e4sst). Auch wenn die jeweilige Anwendung Object Storage noch nicht unterst\u00fctzt, k\u00f6nnte sich eine Implementierung dieser auf lange Sicht lohnen. Die Verwendung von Objekten erm\u00f6glicht einfach mehr Flexibilit\u00e4t und bietet oft auch mehr Funktionen.<\/p>\n\n\n\n
Um nun all diese Anwendungen in einem Kubernetes-Cluster zu konsolidieren (um das Deployment zu vereinheitlichen, mehr Fehlertoleranz zu bieten usw.), sollten die meisten Anwendungen Folgendes unterst\u00fctzen: den verteilten Betrieb mehrerer Instanzen derselben Applikation (auf verschiedenen Nodes).
Der Grund daf\u00fcr ist, dass die Nodes in einem Kubernetes-Cluster sehr dynamisch sind. Ein Node kann jederzeit ausfallen (aufgrund eines unerwarteten Ausfalls, einer Wartung, der automatischen Skalierung des Clusters usw.). Wenn wir zum Beispiel\u00a0Cluster-Upgrades auf unseren NKE-Clustern<\/a>\u00a0durchf\u00fchren, ersetzen wir die Nodes jedes Clusters vollst\u00e4ndig, anstatt die Softwarepakete des Betriebssystems auf jeder Instanz zu aktualisieren. Im Falle eines Node-Ausfalls k\u00fcmmert sich Kubernetes um das Verschieben laufender Anwendungen auf andere Server im Cluster. Dies kann jedoch einige Minuten dauern – wenn dabei nur eine Instanz der Anwendung l\u00e4uft, kann dies zu kurzen Unterbrechungen f\u00fchren. Diese Unterbrechungen k\u00f6nnen sich in einem Wartungsfenster summieren, da jeder Node ersetzt werden muss. Die parallele Ausf\u00fchrung der Anwendung auf mehreren Nodes l\u00f6st dieses Problem und ist eine der von uns empfohlenen Best Practices.
Eine Herausforderung gibt es jedoch dabei. Wenn jede Anwendungsinstanz Daten nur lokal auf dem Node speichert, auf dem sie l\u00e4uft, haben andere Instanzen keinen Zugriff auf diese Daten, da sie auf anderen Rechnern betrieben werden. H\u00e4ufig speichern Webanwendungen von Usern hochgeladene Daten (PDFs, Bilder usw.). Diese Daten m\u00fcssen nun f\u00fcr alle Anwendungsinstanzen zug\u00e4nglich sein. Neben unseren Applikationen, die f\u00fcr den Einsatz in einer verteilten Umgebung bereit sein m\u00fcssen, ben\u00f6tigen wir daher m\u00f6glicherweise auch ein Speichersystem, auf das verteilte Clients zugreifen k\u00f6nnen.<\/p>\n\n\n\nWas steht zur Auswahl<\/h2>\n\n\n\n
\n
Wenn mehrere Applikationen (auf verschiedenen Nodes) \u00c4nderungen an den Daten vornehmen m\u00fcssen, ben\u00f6tigen wir ein Speichersystem, das den RWX-Zugriff unterst\u00fctzt.![\"\"](\"https:\/\/archive.5fcf01f.deploio.app\/app\/uploads\/2024\/02\/09b510e0-UAS_storage_options-scaled.webp\")
Bildquelle:\u00a0<\/em>Canonical<\/a><\/p>\n\n\n\nBlock Storage<\/h2>\n\n\n\n
Wenn jemand also eine einzelne Anwendung (z. B. einen Postgres-Datenbank-Pod f\u00fcr die Entwicklung) hat, die ihren eigenen Speicherplatz ben\u00f6tigt, dann sollte derjenige auf Block Storage setzen.
Hierf\u00fcr gibt es zwei Varianten:<\/p>\n\n\n\n\n
Es gibt auch fl\u00fcchtige Node-Local-Speicherl\u00f6sungen wie Kubernetes emptyDir oder Googles lokale SSD-Funktion f\u00fcr GKE-Cluster, die als Scratch Space oder tempor\u00e4rer Speicher verwendet werden k\u00f6nnen.
Im Normalfall zahlt man f\u00fcr die Menge an Block Storage, die man angefordert hat, und nicht daf\u00fcr, wie viel man davon bereits verbraucht hat.<\/p>\n\n\n\nFile Storage<\/h2>\n\n\n\n
Dateien sind in einem Verzeichnisbaum strukturiert, der relativ viele Verzweigungen haben kann. Jede Datei hat eine Payload (die eigentlichen Daten der Datei), ben\u00f6tigt aber zus\u00e4tzlich Metadaten, die gespeichert werden m\u00fcssen (Zugriffsrechte, Dateityp usw.). Da mehrere verteilte Clients parallel auf das Dateisystem zugreifen k\u00f6nnen, m\u00fcssen zus\u00e4tzlich Sperrmechanismen vorhanden sein, die eine konsistente Sicht f\u00fcr jeden Client gew\u00e4hrleisten. Dies wird von den verschiedenen Implementierungen unterschiedlich gehandhabt (und hat sich beispielsweise auch bei NFS-Implementierungen im Laufe der Zeit ge\u00e4ndert). Ohne zu sehr in die technischen Details zu gehen, bieten File-Storage-Systeme meist eine geringere Leistung im Vergleich zu Block Storage. Allerdings erm\u00f6glichen sie auch den RWX-Zugriff, was mitunter eine Voraussetzung f\u00fcr die Verwendung von Kubernetes ist. Ausserdem bieten nicht alle File-Storage-L\u00f6sungen volle POSIX-Kompatibilit\u00e4t.
Aus Sicht eines Infrastrukturanbieters ist es nicht so einfach, dynamischen File Storage in einer Kubernetes-Umgebung bereitzustellen und zu betreiben. Fr\u00fcher haben wir einige NFS-Instanzen im Cluster selbst verwaltet, was zu Problemen w\u00e4hrend der Wartungszeiten f\u00fchrte, in denen alle Nodes ausgetauscht werden. Manchmal blieben Clients stecken und Pods konnten nicht gestartet werden. Hinzu kommt, dass NFS und CIFS seit langem bestehende L\u00f6sungen sind, die m\u00f6glicherweise nicht in die dynamischen Umgebungen von heute passen.
NFSv3 beispielsweise authentifiziert Clients auf Grundlage von IP-Adressen, die in einem Kubernetes-Cluster meist fl\u00fcchtig sind. NFSv4 kann Clients sicher authentifizieren, aber daf\u00fcr wird eine Kerberos-Infrastruktur ben\u00f6tigt. CIFS unterst\u00fctzt einige gute Funktionen, liefert aber auch Windows-spezifische Features wie etwa die Druckerfreigabe, die in einer Kubernetes-Umgebung nicht wirklich ben\u00f6tigt werden. Ausserdem gibt es derzeit zwei NFS-bezogene Kubernetes-Sigs-Projekte, aber keines f\u00fcr CIFS. CephFS ist sehr vielversprechend in Bezug auf Funktionen und Skalierbarkeit, aber die Verwaltung ist sehr komplex (auch wenn\u00a0rook<\/a>\u00a0diese Situation bereits verbessert hat). Als wir vor einigen Jahren noch Openshift-Cluster betrieben haben, verwendeten wir fr\u00fche Versionen von GlusterFS, was damals viele Probleme mit Konsistenz und Verf\u00fcgbarkeit verursachte.
Die Bereitstellung automatischer Sicherungen und Wiederherstellungsm\u00f6glichkeiten f\u00fcr File-Storage-L\u00f6sungen in einer Kubernetes-Umgebung kann eine zus\u00e4tzliche Herausforderung darstellen.
Insgesamt sind File-Storage-L\u00f6sungen mit einem h\u00f6heren Preis verbunden, da ihr automatisierter Betrieb einen erheblichen Entwicklungsaufwand erfordert. Wir stellen einen\u00a0RWX-Speicher<\/a>\u00a0in unseren NKE-Clustern bereit, der durch eine NFS-L\u00f6sung unseres Infrastruktur-Anbieters unterst\u00fctzt wird.<\/p>\n\n\n\nObject Storage<\/h2>\n\n\n\n
Der Zugriff auf die Objekte erfolgt \u00fcber HTTP-basierte Protokolle, wobei Amazons S3 das beliebteste ist (da es von Amazon entwickelt wurde). Diese Art des Zugriffs unterscheidet sich stark von L\u00f6sungen, die auf File Storage basieren. Es gibt kein gemeinsam genutztes Dateisystem mehr, das an den Container \u00fcbergeben wird. Das zugrundeliegende Betriebssystem oder der Cluster-Orchestrator sind nicht mehr beteiligt am Datenzugriff beteiligt. Stattdessen greift die Anwendung selbst \u00fcber Bibliotheken auf das Object-Storage-System zu. Dies bietet viel Flexibilit\u00e4t, kann aber auch \u00c4nderungen am Quellcode der Anwendung bedeuten. Diese Code\u00e4nderungen sind auch der Grund daf\u00fcr, dass einige Anwendungen nicht auf Object Storage setzen. Die Implementierung w\u00e4re einfach zu viel Arbeit.
Wenn eine Anwendung jedoch Object-Storage-L\u00f6sungen nutzen kann, bringt dies einige grossartige Vorteile mit sich. Hier einige Beispiele:<\/p>\n\n\n\n\n
Was soll ich also verwenden?<\/strong><\/h2>\n\n\n\n