Persistente Daten müssen den Pod, der sie verwendet, überdauern
Kubernetes macht Anwendungen von Grund auf austauschbar. Zustandsbehaftete Dienste benötigen daher einen Speicherlebenszyklus, der trotz Neuplanung, Knotenwartung, Upgrades und Ausfällen vorhersehbar bleibt
Kubernetes-Objekte und das zugrunde liegende Speichersystem sind separate Betriebsschichten
Verwenden Sie den richtigen Lebenszyklus für jeden Datensatz
Kubernetes trennt die Anwendungsanfrage von der Speicherressource. Diese Abstraktion ist nur dann sinnvoll, wenn der zugrunde liegende Lebenszyklus und das Fehlerverhalten verstanden werden
Ephemerer Speicher
Scratch-Daten, beschreibbare Container-Layer, Logs und einige temporäre Volumes folgen dem Pod- oder Node-Lebenszyklus
- Nützlich für Caches und wiederherstellbare Arbeitsdaten
- Kann bei einem Knotenausfall verloren gehen
- Benötigt Anforderungen, Limits und Kapazitätsüberwachung
PersistentVolume
Ein PV repräsentiert den dem Cluster zur Verfügung gestellten Speicher. Es existiert unabhängig vom Lebenszyklus einzelner Pods
- Kann statisch oder dynamisch erstellt werden
- Verfügt über Zugriffsmodi, Kapazität und Rückforderungsverhalten
- Hängt weiterhin vom Backend und der Anbindungsmethode ab
PersistentVolumeClaim
Ein PVC ist die Workload-Anforderung für Kapazität, Zugriffsmodus und eine bestimmte Speicherklasse
- Trennt Entwickler von Backend-Details
- Bindet an ein kompatibles PV
- Gewährleistet allein weder Backup noch Hochverfügbarkeit
Eine StorageClass ist nur so leistungsfähig wie ihr Provisionierer
Pod referenziert ein PVC
Die Anwendung deklariert Speicheranforderungen, ohne eine physische Festplatte oder ein Ziel auszuwählen
StorageClass wird ausgewählt
Sie definiert einen Provisionierer sowie backendspezifische Parameter und das Rückgewinnungsverhalten
PersistentVolume wird erstellt oder zugeordnet
Ein unterstützter Treiber oder Administrator-Workflow stellt die tatsächliche Speicherressource bereit und protokolliert sie
Der Knoten stellt die Ressource dem Pod zur Verfügung
Anhängen, Einbinden und Pfadwiederherstellung müssen unabhängig vom geplanten Einsatzort der Workload funktionieren
Wichtig: Ohne einen geeigneten Provisioner kann Speicher weiterhin statisch durch vorab erstellte PersistentVolumes bereitgestellt und repräsentiert werden. Dies ist ein Betriebsmodell – keine dynamische Bereitstellung
Unterschiedliche Dienste benötigen unterschiedliche Zugriffssemantiken
Vorhersagbarer Block- oder unterstützter Dateizugriff
- Schreibbeständigkeit und Wiederherstellung müssen der Datenbank entsprechen
- Zugriffsmodi und Neuplanungsverhalten müssen getestet werden
- Anwendungsreplikation kann sich mit dem Speicherschutz überschneiden
Ein gemeinsamer Namensraum für mehrere Pods
- NFS kann, sofern unterstützt, gemeinsamen Dateizugriff bereitstellen
- Sperren, Berechtigungen und gleichzeitige Schreibvorgänge sind wichtig
- Die Metadatenleistung kann bei kleinen Dateilasten dominieren
S3 über die Anwendungs-API verwenden
- Auf S3 wird normalerweise von der Anwendung zugegriffen und nicht als PV eingebunden
- Geeignet für Artefakte, Backups, Medien und Datenpipelines
- Anmeldeinformationen und Mandantentrennung gehören in das Anwendungsdesign
Festlegen, was wirklich vergütungspflichtig ist
- Lokaler ephemerer Speicher ist möglicherweise am schnellsten für wiederherstellbare Daten
- Zentrale Protokolle benötigen einen separaten Export- und Aufbewahrungspfad
- Das Verhalten bei Knotenausfällen und -verdrängung sollte explizit sein
Separater Speicherzugriff von der Kubernetes-Automatisierung
Ein Protokoll kann für einen Knoten geeignet sein, erfordert aber dennoch einen separaten Treiber-, Provisionierungs- oder Administratorprozess, um zu einem Kubernetes-Volume zu werden
| Zugriffsmethode | Gemeinsame Containerrolle | Potenzieller Vorteil | Kubernetes-Integration zur Validierung |
|---|---|---|---|
| NFS | Gemeinsame Dateien und ReadWriteMany-Anwendungsdesigns | Vertrauter gemeinsam genutzter Namespace über Knoten hinweg | Statischer PV oder unterstützter externer Provisioner-/CSI-Pfad, Berechtigungen, Sperrung und Failover-Remount-Verhalten |
| iSCSI | Persistente Block-Volumes für zustandsbehaftete Anwendungen | Ausgereifter IP-Blockzugriff und breite Host-Unterstützung | Qualifizierter Knoten Initiator, Multipathing, Attachment-Workflow und unterstützter Provisioner |
| NVMe-oF | Latenzempfindlicher Blockspeicher, sofern der gesamte Host-Stack dies unterstützt | Effizienter NVMe-Zugriff über TCP oder RDMA | Es wird keine native euroNAS Kubernetes-Bereitstellung beansprucht; Qualifizierende Anbindung, Multipathing und der gewählte CSI- oder Administrator-Workflow |
| Ceph-gestützte Dienste | Scale-out-Block-, Datei- oder Objektspeicher | Verteilter Schutz und Wachstum über Ausfalldomänen hinweg | Jede direkte Kubernetes/Ceph-Integration benötigt einen eigenen unterstützten Treiber, eine Versionsmatrix und eine Betriebsvalidierung |
| S3-kompatible API | Anwendungsobjekte, Repositories, Backups und Datenpipelines | Zugriff auf Anwendungsebene ohne eingebundenes Volume | SDK/CLI-Kompatibilität, Anmeldeinformationen, Endpunktverfügbarkeit und Anwendungskonsistenz |
Schließen Sie nicht von einem Speicherprotokoll auf einen Kubernetes-Treiber
euroNAS kann Block-, Datei- und S3-Dienste bereitstellen, die in einer Kubernetes-Architektur verwendet werden können. Kubernetes-native dynamische Bereitstellung, Snapshots, Klonen, Erweiterung und Topologieerkennung hängen vom exakten CSI-Treiber oder -Provisioner ab, der für die jeweilige Umgebung ausgewählt wird
Klarer Geltungsbereich: Diese Seite beansprucht weder einen nativen euroNAS- noch einen nativen CSI-Treiber, eine Kubernetes-Zertifizierung oder die automatische Volume-Bereitstellung. Jede Integrationsschicht muss unabhängig ausgewählt, unterstützt und getestet werden
Validieren Sie die gesamte Kette
Ein erfolgreiches Mounten ist nur der erste Test
Zustandsbehaftete Container benötigen mehr als eine persistente Einbindung
Knoten verbunden halten
Redundante Verbindungen, Multipathing und korrekte Timeouts schützen den Pfad, sofern die Blockintegration dies unterstützt
Überstehen eines Speicherknotenausfalls
Automatische Hochverfügbarkeit oder verteilter Speicherschutz adressiert eine andere Ebene als die Pod-Neuplanung
Koordinierter Zustand
Datenbanken und verteilte Anwendungen benötigen möglicherweise Quiescing oder anwendungsnativen Schutz
Frühere Daten wiederherstellen
Beibehaltene, unabhängige Kopien schützen vor Löschung, Beschädigung und größeren Ausfallgrenzen
Volume-Snapshots erfordern explizite Unterstützung: Kubernetes-Snapshot-Objekte basieren auf der Funktionalität von CSI und machen nicht automatisch jeden Backend-Snapshot anwendungskonsistent oder unabhängig wiederherstellbar
Verwalten Sie Ceph-Dienste über geführte Workflows
eEKAS kann verteilte Block-, Datei- und S3-Dienste für Containerplattformen und andere externe Nutzer bereitstellen. Clustererstellung, Laufwerke, Pools, Schutzprofile, Metadatenplatzierung und Endpunkte werden über die grafische Benutzeroberfläche von euroNAS verwaltet
euroNAS-Produkte auf klar definierten Infrastrukturebenen verwenden
Diese Beispiele beschreiben, wo Speicher und Virtualisierung eingesetzt werden können; sie schreiben keine bestimmte Kubernetes-Distribution oder CSI-Implementierung vor
Fokussierter externer Speicher
Block- oder Dateidienste für eine kompakte Umgebung, in der Speicherintegration und vollständige Serverwiederherstellung von der umgebenden Architektur übernommen werden
- Geeignet für statisch verwalteten oder unabhängig bereitgestellten Speicher
- Kann als physischer oder Virtual Storage Appliance
- Kein automatisches Storage-Controller-Failover innerhalb eines eigenständigen Servers bereitgestellt werden
Hochverfügbarer externer Speicher
Gemeinsamer Speicher mit automatischem lokalem Service-Failover durch ein synchrones Spiegel- oder Dual-Controller-Shared-Storage-Design
- Multipathing für unterstützten Blockzugriff
- NFS oder Blockdienste gemäß Anwendungsdesign
- Separate asynchrone Wiederherstellungs- und Sicherungssteuerungen bleiben erforderlich
Scale-out Datendienste
Verteilte Block-, Datei- und S3 Dienste, die skalieren unabhängig von der Kubernetes-Rechenschicht und kann mehrere Verbrauchergruppen bedienen
- Ceph Schutz über definierte Ausfalldomänen hinweg
- Replikation oder Erasure Coding nach Workload
- Jede direkte CSI-Integration muss unabhängig qualifiziert werden
Kubernetes-Knoten als virtuelle Maschinen
eEVOS kann Kubernetes-Knoten als virtuelle Maschinen hosten und interne, externe gemeinsam genutzte oder Ceph-gestützte Infrastruktur gemäß dem Clusterdesign bereitstellen
- VM-Hochverfügbarkeit und Live-Migration
- Integriertes Backup & Disaster Recovery für geschützte VMs
- Kubernetes-Anwendungsschutz benötigt weiterhin ein eigenes Design
Fragen, die vor dem ersten StorageClass geklärt werden müssen
Benötigt die Workload einen Schreiber, mehrere Leser oder gleichzeitigen Lese-/Schreibzugriff über Knoten hinweg?
Werden die Volumes statisch, über einen externen Provisioner oder über einen qualifizierten CSI-Treiber erstellt?
Was geschieht mit dem Status von Anbindung, Einbindung und Anwendung, wenn ein Pod auf einen anderen Knoten verschoben wird?
Sollen Daten beim Entfernen eines PVC gelöscht oder beibehalten werden, und wer ist für den Bereinigungsprozess verantwortlich?
Welche RPO und RTO gelten für Löschung, Anwendungsbeschädigung, Knotenausfall und Standortverlust?
Welche Kubernetes-, Treiber-, Knotenbetriebssystem-, Anwendungs- und Speicherversionen werden gemeinsam getestet?
Kubernetes-Speicherkonzepte
Verwenden Sie die aktuelle Kubernetes- und Integrationsdokumentation zur Validierung der endgültigen Bereitstellung
Persistente Volumes
Offizielle Kubernetes-Erklärung zu Volumes, die länger als einzelne Pods bestehen, und dem anspruchsbasierten Speichermodell
Kubernetes-Dokumentation öffnen →Storage-Klassen
Beschreibung von Speicherrichtlinien, Provisionern, Reclaim-Verhalten und Bindungsmodi durch Administratoren
Dokumentation der Storage-Klasse öffnen →Ephemere Volumes
Offizielle Anleitung für Scratch-, Konfigurations- und temporären Speicher, dessen Lebenszyklus einem Pod folgt
Anleitung zu ephemerem Speicher öffnen →Bringen Sie die Workload und den Integrationsplan mit
. Wir können Zugriffsmodi, Knotenkonnektivität, Speicherprotokolle, Verfügbarkeit, Wiederherstellung und Skalierbarkeit für eine Business-Container- oder Kubernetes-Umgebung überprüfen