Detaillierte Verwendung des Kubernetes-Objektvolumens

Überblick

Volume ist die Abstraktion und Virtualisierung verschiedener Speicherressourcen. Bietet eine einheitliche Schnittstelle zum Verwalten, Steuern und Verwenden von Speicherressourcen. Das Volume in OpenStack bietet Speicher für virtuelle Maschinen und das Volume in Docker bietet Speicher für Container. Da die kleinste bereitstellbare Ausführungseinheit in Kubernetes ein Pod ist, stellt das Kubernetes-Volume Speicher für den Pod bereit. Natürlich müssen Sie beim Bereitstellen eines Pods kein Volume angeben. Die Container im Pod verwenden die Festplatte des Knotens, auf dem sie sich befinden. Der Ort, an dem Daten gleichzeitig gelesen und geschrieben werden können, wird als lesbare und beschreibbare Ebene bezeichnet. Bei diesem Speicher handelt es sich um einen temporären Speicher auf Containerebene und nicht auf Podebene. Sein Lebenszyklus ist der gleiche wie der des Containers. Wenn der Container abstürzt und neu gestartet wird, d. h. der alte Container gelöscht und ein neuer Container gestartet wird, wird die lesbare und beschreibbare Ebene des alten Containers zusammen mit dem Container gelöscht und die darauf gespeicherten Daten gehen verloren. Wenn der Pod zwischen Knoten migriert und geplant wird, wird die Lese-/Schreibebene des Containers ebenfalls nicht migriert und geplant. Daher muss Kubernetes ein Volumen auf Pod-Ebene bereitstellen. Das Volumen in diesem Artikel bezieht sich speziell auf Kubernetes.

Datenträgertyp

Volumen ist ein abstraktes Konzept mit vielen konkreten Implementierungen, jede mit ihrem eigenen Zweck, ihren eigenen Merkmalen und Funktionen. Als Datenträger kann fast alles verwendet werden. Die Typen sind folgende:

• awsElasticBlockStore
• azureDisk
• azureFile
• cephfs
• Konfigurationskarte
• CSI
• nach untenAPI
• leeresVerzeichnis
• FC (Glasfaserkanal)
• Flocker
• gcePersistentDisk
• gitRepo (veraltet)
• Abonnieren
• Hostpfad
• iSCSI
• lokal
• nfs
• persistentVolumeClaim
• projiziert
• portworxVolumen
• quobyte
• rbd
• waageIO
• Geheimnis
• Speichergeräte
• vsphereVolume
• Wir werden hier nicht alle oben genannten Typen einzeln vorstellen, sondern nur kurz auf den lokalen Festplattenspeicher und den verteilten Speicher eingehen, die derzeit möglicherweise verwendet werden.

Beschreibung und Beispiele gängiger Speichertypen

cephfs

Cephfs ist eine hervorragende und beliebte Speicherlösung für Cloudumgebungen, da es Open Source ist, eine hohe Verfügbarkeit und flexible Skalierbarkeit aufweist, keine besonderen Anforderungen an Betriebssystem und Hardware stellt, für Benutzer einfach zu erstellen ist und keine besonderen Anforderungen an die Knoten stellt, die es verwenden. Es verfügt über alle in awsElasticBlockStore beschriebenen Funktionen und ein einzelnes Volume kann von mehreren Knoten gleichzeitig verwendet werden. Benutzer erstellen zunächst ihre eigene CephFS-Umgebung, konfigurieren dann den Kubernetes-Cluster, um eine Verbindung damit herzustellen, und verwenden schließlich das von ihm bereitgestellte Volume im Pod. Weitere Einzelheiten finden Sie hier.

Konfigurationskarte

Der Benutzer erstellt zunächst eine ConfigMap und speichert darin Daten. Zu diesem Zeitpunkt werden die Daten in der etcd-Datenbank von Kubernetes gespeichert, und das Volume existiert noch nicht. Wenn der Benutzer in einem Pod auf die erstellte ConfigMap verweist, erstellt das System zunächst ein Volume auf dem Knoten und speichert die Daten darin. Dieses Volume belegt den vom Knoten belegten Speicherplatz. Danach können Sie es wie ein normales Volumen verwenden.

ConfigMap ist ein Objekttyp in Kubernetes. Sein Kernelement besteht darin, separat verwaltete Konfigurationsinformationen in Form von Volumes an Container in Pods weiterzugeben, und wird nicht zum Speichern persistenter Daten verwendet. Einzelheiten finden Sie hier.

AbwärtsAPI

Ähnlich wie configMap übergibt es Informationen in Form eines Volumens an den Container im Pod. Die Informationen in configMap werden vom Benutzer beim Erstellen eines Objekts übergeben, während die Informationen in downstreamAPI vom Pod-Objekt selbst stammen. downstreamAPI muss nicht erstellt werden. Es ist ein Feld in der Pod-Spezifikation und sein Inhalt verweist auf andere Felder des Pod-Objekts selbst, wie z. B. Pod-Metadaten, Bilder und andere Informationen. Beim Erstellen eines Pods extrahiert das System zuerst die angegebenen Felder, erstellt dann ein Volume, speichert die extrahierten Felder und mountet sie, sodass der Container diese Felder lesen kann.

Der Zweck von DownwardAPI besteht darin, eine Möglichkeit bereitzustellen, die eigenen Feldinformationen des Pods, wie etwa Bezeichnung und Anmerkung, an den Container zu übergeben. Einzelheiten finden Sie hier.

leeresVerzeichnis

Das emptyDir-Volume wird nur erstellt, wenn eine Pod-Instanz auf dem Knoten ausgeführt wird. Es ist zunächst ein leeres Verzeichnis auf dem Knoten und jeder Container im Pod kann es als Volume bereitstellen. Wenn der Container aus irgendeinem Grund gelöscht und neu gestartet wird, wird das erstellte „emptyDir“ nicht gelöscht oder bereinigt. Wenn eine Pod-Instanz einen Knoten verlässt und für einen anderen Knoten eingeplant wird oder aufgrund einer Skalierung nach unten gelöscht wird, wird „emptyDir“ gelöscht. Dies bedeutet, dass der Pod noch vorhanden ist, die Daten jedoch verloren sind. Beispiel:

API-Version: v1
Art: Pod
Metadaten:
 Name: test-pd
Spezifikation:
 Behälter:
 - Bild: k8s.gcr.io/test-webserver
  Name: Testcontainer
  Volumenhalterungen:
  - MountPfad: /cache
   Name: Cache-Volume
 Bände:
 - Name: Cache-Volume
  leeres Verzeichnis: {}

Abonnieren

Wie cephfs, eine beliebte Speicherlösung für Cloud-Umgebungen

Hostpfad

API-Version: v1
Art: Pod
Metadaten:
 Name: test-pd
Spezifikation:
 Behälter:
 - Bild: k8s.gcr.io/test-webserver
  Name: Testcontainer
  Volumenhalterungen:
  - MountPfad: /test-pd
   Name: Testvolumen
 Bände:
 - Name: Testvolumen
  Hostpfad:
   # Verzeichnisspeicherort auf dem Host
   Pfad: /data
   # dieses Feld ist optional
   Typ: Verzeichnis

iSCSI

Internet Small Computer System Interface, das sich durch seine geringen Kosten auszeichnet.

lokal

Ähnlich wie emptyDir belegt es auch Speicherplatz im Knoten. Der Unterschied besteht darin, dass es sich um einen Objekttyp in Kubernetes handelt und Benutzer ihn wie gewöhnliche Objekte verwalten können. emptyDir wird zur Laufzeit zugewiesen, wenn eine Pod-Instanz gestartet wird, und gelöscht, wenn der Pod den Knoten verlässt. Das lokale Volume wird vom Benutzer erstellt und das System weist ihm auf dem entsprechenden Knoten Ressourcen zu. Der für diesen Knoten geplante Pod kann es bereitstellen und es verschwindet nicht, wenn der Pod es verlässt, es sei denn, der Benutzer löscht es. Beispiel:

API-Version: v1
Art: PersistentVolume
Metadaten:
 Name: Beispiel-PV
Spezifikation:
 Kapazität:
  Speicher: 100Gi
 # Für das Feld „volumeMode“ muss das BlockVolume Alpha-Feature-Gate aktiviert sein.
 volumeMode: Dateisystem
 Zugriffsmodi:
 -Einmal lesen/schreiben
 persistentVolumeReclaimPolicy: Löschen
 Speicherklassenname: lokaler Speicher
 lokal:
  Pfad: /mnt/disks/ssd1
 Knotenaffinität:
  erforderlich:
   nodeSelectorTerms:
   - Übereinstimmungsausdrücke:
    - Schlüssel: kubernetes.io/Hostname
     Betreiber: In
     Werte:
     - Beispielknoten

nfs

nfs
Netzwerkdateisystem

persistentVolumeClaim

Ähnlich wie Flocker, wird zum Schutz verschiedener Cloud-Umgebungen verwendet

projiziert

Wenn ein Container mehrere vorhandene Volumes wie Secret, ConfigMap, DownwardAPI usw. mounten muss, muss jedes Volume dieses Typs jeweils ein Mount-Verzeichnis belegen. projected kann sie jedoch zusammen integrieren und in nur einem Verzeichnis mounten. Beispiel:

API-Version: v1
Art: Pod
Metadaten:
 Name: Volumentest
Spezifikation:
 Behälter:
 - Name: Container-Test
  Bild: busybox
  Volumenhalterungen:
  - Name: Alles-in-einem
   MountPath: "/projiziertes Volumen"
   schreibgeschützt: true
 Bände:
 - Name: Alles-in-einem
  projiziert:
   Quellen:
   - Geheimnis:
     Name: meinGeheimnis
     Artikel:
      - Schlüssel: Benutzername
       Pfad: meine-Gruppe/mein-Benutzername
   - AbwärtsAPI:
     Artikel:
      - Pfad: „Labels“
       FeldRef:
        Feldpfad: metadata.labels
      - Pfad: "cpu_limit"
       Ressourcenfeldreferenz:
        Containername: Containertest
        Ressource: limits.cpu
   - Konfigurationskarte:
     Name: meineconfigmap
     Artikel:
      - Schlüssel: config
       Pfad: meine-Gruppe/meine-Konfiguration