Persistent Volume Claims (PVCs) im Block Volume-Service bereitstellen

Sie können ein Block-Volume dynamisch mit dem CSI-Plug-in bereitstellen, das in der Definition der Speicherklasse oci-bv (provisioner: blockvolume.csi.oraclecloud.com) angegeben ist. Beispiel: Der Clusteradministrator hat keine geeigneten PVs erstellt, die der PVC-Anforderung entsprechen.

Sie definieren einen PVC in einer Datei namens csi-bvs-pvc.yaml. Beispiel:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mynginxclaim
spec:
  storageClassName: "oci-bv"
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 50Gi

Geben Sie den folgenden Befehl ein, um den PVC aus der csi-bvs-pvc.yaml-Datei zu erstellen:

kubectl create -f  csi-bvs-pvc.yaml

Die Ausgabe des obigen Befehls bestätigt die Erstellung des PVC:

persistentvolumeclaim "mynginxclaim" created

Prüfen Sie, ob der PVC erstellt wurde, indem Sie den Befehl kubectl get pvc ausführen:

kubectl get pvc

Die Ausgabe des obigen Befehls zeigt den aktuellen Status des PVC an:

		
NAME               STATUS   VOLUME   CAPACITY   ACCESSMODES   STORAGECLASS   AGE
mynginxclaim       Pending                                    oci-bv         4m

Der PVC hat den Status Pending, da die Speicherklasse oci-bv den Wert volumeBindingMode: WaitForFirstConsumer enthält.

Sie können diesen PVC beim Erstellen anderer Objekte, wie Pods, verwenden. Beispiel: Sie können einen neuen Pod aus der folgenden Poddefinition erstellen, die das System anweist, den mynginxclaim-PVC als nginx-Volume zu verwenden, das vom Pod bei /data gemountet wird.

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
    - name: nginx
      image: nginx:latest
      ports:
        - name: http
          containerPort: 80
      volumeMounts:
        - name: data
          mountPath: /usr/share/nginx/html
  volumes:
    - name: data
      persistentVolumeClaim:
        claimName: mynginxclaim

Nach Erstellen des neuen Pods können Sie prüfen, ob der PVC an ein neues Persistent Volume gebunden wurde, indem Sie Folgendes eingeben:

kubectl get pvc

Die Ausgabe des obigen Befehls bestätigt, dass der PVC gebunden wurde:

			
NAME               STATUS    VOLUME                               CAPACITY   ACCESSMODES   STORAGECLASS   AGE
mynginxclaim       Bound     ocid1.volume.oc1.iad.<unique_ID>     50Gi       RWO           oci-bv         4m

Sie können prüfen, ob der Pod den neuen Persistent Volume Claim verwendet, indem Sie Folgendes eingeben:

kubectl describe pod nginx

Sie können Kapazitätsstatistiken für das neue persistente Volume mit einem Aggregationstool für Metriken wie Prometheus anzeigen.

Ein Kubernetes-Volume Snapshot ist ein Snapshot eines persistenten Volumes auf einem Speichersystem. Mit einem Volume Snapshot können Sie ein neues persistentes Volume bereitstellen. Weitere Informationen zu Kubernetes-Volume Snapshots finden Sie unter Volume Snapshots in der Kubernetes-Dokumentation.

Wenn Sie mit dem CSI-Volume-Plug-in Cluster mit Block-Volumes im Block-Volume-Service verbinden, können Sie Block-Volume-Backups verwenden, um Kubernetes-Volume-Snapshots bereitzustellen. Sie können einen Volume Snapshot verwenden, um ein neues Block-Volume zu erstellen und es mit Daten aus dem Block-Volume-Backup vorab aufzufüllen. Weitere Informationen zu Block-Volume-Backups im Block Volume Service finden Sie unter Überblick über Block-Volume-Backups.

Mit dem CSI-Volume-Plug-in können Sie einen Volume Snapshot auf zwei Arten bereitstellen:

• Dynamisch: Sie können die Erstellung eines Backups des Block-Volumes anfordern, das ein persistentes Volume bereitstellt. Sie geben den Persistent Volume Claim mit dem Objekt VolumeSnapshot an, und Sie geben die Parameter an, mit denen das Block-Volume-Backup mit dem Objekt VolumeSnapshotClass erstellt werden soll. Dynamisch bereitgestellte Volume Snapshots werden auch als dynamische Volume Snapshots bezeichnet. Siehe Dynamisch bereitgestellte Volume Snapshots erstellen.
• Statisch: Sie können Details zu einem vorhandenen Block-Volume-Backup mit dem Objekt VolumeSnapshotContent angeben. Statisch bereitgestellte Volume Snapshots werden auch als statische Volume Snapshots und als vorab bereitgestellte Volume Snapshots bezeichnet. Statisch bereitgestellte Volume Snapshots erstellen

Wenn Sie einen dynamisch bereitgestellten Volume Snapshot erstellen, werden dieselben Freiformtags und definierten Tags, die auf das Quellblock-Volume angewendet wurden, auf das Block-Volume-Backup angewendet. Sie können jedoch Parameter verwenden, um zusätzliche Tags auf das Block-Volume-Backup anzuwenden (siehe Block-Volume-Backups taggen).

Vor dem Erstellen von Volume Snapshots zur Verwendung mit Clustern, die von der Kubernetes-Engine erstellt werden, müssen mehrere Voraussetzungen erfüllt sein. Siehe Voraussetzungen für das Erstellen von Volume Snapshots.

Beachten Sie beim Erstellen und Verwenden von Volume Snapshots Folgendes:

• Sie können Volume-Snapshots nur erstellen, wenn Sie das CSI-Volume-Plug-in verwenden (das heißt, Sie können keine Volume-Snapshots erstellen, wenn Sie das Volume-Plug-in FlexVolume verwenden).
• Bei dynamischen Volume-Backups erstellt das CSI-Volume-Plug-in ein neues Block-Volume-Backup, um einen dynamischen Volume-Snapshot im selben Compartment wie das Cluster bereitzustellen. Bei statischen Volume Snapshots kann sich das Block-Volume-Backup, das ein statischer Volume Snapshot bereitstellt, in einem anderen Compartment als das Cluster befinden, sofern entsprechende Policy-Anweisungen vorhanden sind, damit das Cluster auf dieses andere Compartment zugreifen kann (siehe Voraussetzungen für das Erstellen von Volume Snapshots).
• Mit dem CSI-Volume-Plug-in können Sie ein vorhandenes Volume nicht erneut mit Daten auffüllen. Mit anderen Worten: Sie können Daten in einem vorhandenen persistenten Volume nicht in einen früheren Status zurücksetzen (wiederherstellen), indem Sie den Volume Snapshot ändern, der im Manifest des Persistent Volume Claims angegeben ist. Sie können nur das CSI-Volume-Plug-in verwenden, um ein neues Volume mit Daten zu füllen.
• Wenn Sie ein Block-Volume-Backup erstellen (z.B. beim Erstellen eines dynamischen Volume-Snapshots), wird der Verschlüsselungsschlüssel, der beim Erstellen des Block-Volumes verwendet wurde, auch zum Erstellen des Block-Volume-Backups verwendet. Beim Erstellen eines Block-Volume-Backups können Sie keinen neuen Verschlüsselungsschlüssel angeben. Daher verwendet das Block-Volume-Backup dieselbe Verschlüsselung wie das Block-Volume, das gesichert wird.
• Die für ein persistentes Volume, das von einem Volume Snapshot bereitgestellt wird, angegebene Größe darf nicht kleiner als die Größe des ursprünglichen Volumes sein, von dem der Snapshot erstellt wurde.
• Wenn das CSI-Volume-Plug-in ein neues Block-Volume erstellt, um ein persistentes Volume zu sichern, das von einem Volume Snapshot bereitgestellt wird, hängt die Platzierung des Block-Volumes von den Topologieanforderungen der Volume-Erstellungsanforderung ab. Beispiel: Wenn das CSI-Volume-Plug-in ein Block-Volume für einen Pod erstellt, der einen persistenten Volume Claim verwendet, wird das Block-Volume in derselben Availability-Domain wie der Worker-Knoten erstellt, auf dem der Pod ausgeführt wird.
• Namespace-übergreifende Snapshots werden nicht unterstützt.
• Wenn die Anzahl der VolumeSnapshot- und VolumeSnapshotContent-Objekte in einem Cluster zunimmt, können sie erheblichen Speicherplatz in etcd belegen, was zu unerwartetem Clusterverhalten führen kann. Um das Cluster fehlerfrei zu halten, wird empfohlen, einen Löschmechanismus zu implementieren, um nicht mehr benötigte VolumeSnapshot- und VolumeSnapshotContent-Objekte regelmäßig zu bereinigen.

kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/master/client/config/crd/snapshot.storage.k8s.io_volumesnapshotclasses.yaml

kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/master/client/config/crd/snapshot.storage.k8s.io_volumesnapshotcontents.yaml

kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/master/client/config/crd/snapshot.storage.k8s.io_volumesnapshots.yaml

ALLOW any-user to manage volume-backups in compartment <compartment-name> where request.principal.type = 'cluster'
ALLOW any-user to use volumes in compartment <compartment-name> where request.principal.type = 'cluster'

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: sample-pvc
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: "oci-bv"
  resources:
    requests:
      storage: 50Gi

kubectl create -f csi-mypvctobackup.yaml

apiVersion: v1
kind: Pod
metadata:
  name: sample-pod
spec:
  containers:
    - name: sample-nginx
      image: nginx
      ports:
        - containerPort: 80
          name: "http-server"
      volumeMounts:
        - mountPath: "/usr/share/nginx/html"
          name: sample-volume
  volumes:
  - name: sample-volume
    persistentVolumeClaim:
      claimName: sample-pvc

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
  name: my-snapclass
driver: blockvolume.csi.oraclecloud.com
parameters:
  backupType: full
deletionPolicy: Delete

kubectl create -f csi-mysnapshotclass.yaml

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: my-snapshot
  namespace: default
spec:
  volumeSnapshotClassName: my-snapclass
  source:
    persistentVolumeClaimName: sample-pvc

kubectl create -f csi-mysnapshot.yaml

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotContent
metadata:
  name: my-static-snapshot-content
spec:
  deletionPolicy: Retain
  driver: blockvolume.csi.oraclecloud.com
  source:
    snapshotHandle: ocid1.volumebackup.oc1.iad.aaaaaa______xbd
  volumeSnapshotRef:
    name: my-static-snapshot
    namespace: default

kubectl create -f csi-mystaticsnapshotcontent.yaml

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: my-static-snapshot
spec:
  source:
    volumeSnapshotContentName: my-static-snapshot-content

kubectl create -f csi-mystaticsnapshot.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-fromsnapshot
  namespace: default
spec:
  storageClassName: oci-bv
  dataSource:
    name: test-snapshot
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 50Gi

kubectl create -f csi-mypvcfromsnapshot.yaml

apiVersion: v1
kind: Pod
metadata:
  name: sample-pod-restore
spec:
  containers:
    - name: nginx
      image: nginx:latest
      ports:
        - name: http
          containerPort: 80
      volumeMounts:
        - name: data
          mountPath: /data
  volumes:
    - name: data
      persistentVolumeClaim:
        claimName: pvc-fromsnapshot

oci.oraclecloud.com/freeform-tags: '{"<first-tag-key>":","<first-tag-value>","<second-tag-key>":"<second-tag-value>"...}'

oci.oraclecloud.com/defined-tags: '{"<tag-namespace>": {"<first-tag-key>":","<first-tag-value>","<second-tag-key>":"<second-tag-value>"...}}'

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
  name: my-snapclass
driver: blockvolume.csi.oraclecloud.com
parameters:
  backupType: full
  oci.oraclecloud.com/freeform-tags: '{"<first-tag-key>":","<first-tag-value>","<second-tag-key>":"<second-tag-value>"...}'
deletionPolicy: Delete

Ein Kubernetes-Klon ist ein exaktes Duplikat eines vorhandenen persistenten Volumes auf einem Speichersystem. Sie können ein vorhandenes persistentes Volume klonen, um einen neuen Persistent Volume Claim bereitzustellen. Das neue persistente Volume enthält eine Kopie der Daten aus dem persistenten Quell-Volume, ist jedoch unabhängig vom persistenten Quell-Volume. Mit Volume-Klonen können Sie Konfigurationsänderungen schnell testen, ohne dass sich dies auf eine Produktionsumgebung auswirkt. Weitere Informationen zu Kubernetes-Klonen finden Sie unter CSI-Volume-Klonen in der Kubernetes-Dokumentation.

Im Block-Volume-Service können Sie ein Block-Volume klonen, um ein neues Block-Volume zu erstellen, das vorab mit Daten aus dem Quellblock-Volume aufgefüllt wird. Weitere Informationen zum Klonen von Block-Volumes im Block Volume Service finden Sie unter Block-Volumes klonen.

Wenn Sie das CSI-Volume-Plug-in verwenden, um Cluster mit Block-Volumes im Block-Volume-Service zu verbinden, können Sie ein neues PVC mit einem neuen Block-Volume bereitstellen, das aus einem vorhandenen Block-Volume geklont wurde, das ein anderes vorhandenes PVC bereitstellt. Um anzugeben, dass das CSI-Volume-Plug-in das vorhandene Block-Volume für das neue PVC klonen soll, geben Sie das vorhandene PVC als Datenquelle für das neue PVC an.

Das neue PVC kann auf die gleiche Weise wie jedes andere PVC verwendet werden und ist vollständig getrennt von dem vorhandenen PVC, das als Datenquelle angegeben ist. Ebenso sind das neue Block-Volume und das vorhandene Block-Volume, aus dem es geklont wird, völlig separate Ressourcen. Sie können unabhängig voneinander aktualisiert, geklont, Snapshot erstellt und gelöscht werden.

Sobald das Quellblock-Volume geklont und ein neues Block-Volume erstellt wurde (in der Regel innerhalb weniger Sekunden), hat das neue Block-Volume den Status "Verfügbar". Alle in diesem Moment im Quellblock-Volume vorhandenen Daten werden auf das neue Block-Volume kopiert (keine nachfolgenden Änderungen werden kopiert). Die Daten werden jedoch im Hintergrund kopiert, was je nach Größe des Block-Volumes bis zu dreißig Minuten dauern kann (Beispiel: Das Kopieren eines Block-Volumes mit 1 TB kann bis zu fünfzehn Minuten dauern). Um Fehler oder Datenbeschädigungen zu vermeiden, hat das neue PVC den Status "Ausstehend", bis alle Daten kopiert wurden. Wenn alle Daten kopiert wurden, ist das neue PVC an das vom neuen Block-Volume bereitgestellte PV gebunden, und das neue PVC hat den Status "Verfügbar".

Vor dem Provisioning eines neuen Persistent Volume Claims müssen mehrere Voraussetzungen erfüllt sein, indem das Block-Volume geklont wird, das bereits einen vorhandenen Persistent Volume Claim bereitstellt. Siehe Voraussetzungen für das Klonen eines vorhandenen Block-Volumes zum Provisioning eines neuen PVCs.

Beachten Sie Folgendes, wenn Sie ein Block-Volume klonen, um ein neues PVC bereitzustellen:

• Das CSI-Volume-Plug-in erstellt das neue Block-Volume in derselben Availability-Domain, Region und demselben Mandanten wie das Quellblock-Volume.
• Das vom CSI-Volume-Plug-in erstellte neue Block-Volume kann selbst geklont werden, sobald es den Status "Verfügbar" aufweist.
• Topologieanforderungen in einer Volume-Erstellungsanforderung werden ignoriert. Beispiel: Wenn das CSI-Volume-Plug-in ein Block-Volume für einen Pod klont, der einen persistenten Volume Claim verwendet, wird das neue Block-Volume in derselben Availability-Domain wie der Worker-Knoten erstellt, auf dem der Pod ausgeführt wird.
• Sie können das CSI-Volume-Plug-in nicht zum Klonen von Block-Volumes verwenden, die mit dem Volume-Plug-in FlexVolume erstellt wurden.
• Sie können den Quell-PVC nicht löschen, während das Klonen ausgeführt wird. Ebenso können Sie ein Quellblock-Volume nicht löschen, während Daten in ein Block-Volume kopiert werden, das von ihm geklont wurde.
• Namespace-übergreifendes Klonen wird nicht unterstützt. Das neue PVC und das Quell-PVC müssen sich beide im selben Namespace befinden.
• Sie müssen keine Speicherklasse für den neuen PVC explizit angeben. Wenn Sie explizit eine Speicherklasse für das neue PVC angeben, kann sich die angegebene Speicherklasse von der für das Quell-PVC angegebenen Speicherklasse unterscheiden. Wenn Sie keine Speicherklasse für den neuen PVC angeben, wird die Standardspeicherklasse verwendet.

Beispiel: Sie definieren einen persistenten Volume Claim namens my-clone-pvc in einer Datei namens csi-myclonepvc.yaml. Der Persistent Volume Claim "my-clone-pvc" wird von einem Block-Volume bereitgestellt, das durch Klonen des Block-Volumes erstellt wird, das den Persistent Volume-Claim "my-source-pvc" bereitstellt:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-clone-pvc
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: custom-clone-storage-class
  resources:
    requests:
      storage: 50Gi
  dataSource:
    kind: PersistentVolumeClaim
    name: my-source-pvc

Erstellen Sie den Persistent Volume Claim:

kubectl create -f csi-myclonepvc.yaml

Sie können den Persistent Volume Claim beim Definieren anderer Objekte, wie Pods, verwenden. Beispiel: Die folgende Poddefinition weist das System an, den Persistent Volume Claim "my-clone-pvc" als nginx-Volume zu verwenden, das vom Pod bei /sample-volume gemountet ist.

apiVersion: v1
kind: Pod
metadata:
  name: sample-pod
spec:
  containers:
    - name: sample-nginx
      image: nginx
      ports:
        - containerPort: 80
          name: "http-server"
      volumeMounts:
        - mountPath: "/usr/share/nginx/html"
          name: sample-volume
  volumes:
  - name: sample-volume
    persistentVolumeClaim:
      claimName: my-clone-pvc

Nachdem der neue Pod erstellt wurde, ist der Persistent Volume Claim "my-clone-pvc" an ein neues Persistent Volume gebunden, das von einem Block-Volume bereitgestellt wird, das aus dem Block-Volume geklont wurde, das den Persistent Volume Claim "my-source-pvc" bereitstellt.

Sie können einen PVC aus einem vorhandenen Block-Volume oder einem Block-Volume-Backup zur Verwendung durch das Volume-Plug-in FlexVolume erstellen. Beispiel: Der Clusteradministrator hat ein Block-Volume-Backup erstellt, das Sie beim Provisioning eines neuen Persistent Volume Claims verwenden können. Ein solches Block-Volume-Backup kann Daten enthalten, die von anderen Objekten wie Pods verwendet werden können.

Sie definieren einen PVC in einer Datei namens flex-pvcfrombackup.yaml. Mit dem Annotationselement volume.beta.kubernetes.io/oci-volume-source geben Sie die Quelle des Block-Volumes an, die beim Provisioning eines neuen Persistent Volume Claims mit dem FlexVolume-Plug-in verwendet werden soll. Sie können die OCID eines Block-Volumes oder eines Block-Volume-Backups als Wert der Annotation angeben. In diesem Beispiel geben Sie die OCID des vom Clusteradministrator erstellten Block-Volume-Backups an. Beispiel:

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: myvolume
  annotations:
    volume.beta.kubernetes.io/oci-volume-source: ocid1.volumebackup.oc1.iad.abuw...
spec:
  selector:
    matchLabels:
      topology.kubernetes.io/zone: US-ASHBURN-AD-1
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 50Gi

Beachten Sie, dass die Datei flex-pvcfrombackup.yaml das Element matchLabels enthält, das nur mit dem FlexVolume-Volume-Plug-in verwendet werden darf.

Geben Sie den folgenden Befehl ein, um den PVC aus der flex-pvcfrombackup.yaml-Datei zu erstellen:

kubectl create -f flex-pvcfrombackup.yaml

Die Ausgabe des obigen Befehls bestätigt die Erstellung des PVC:

persistentvolumeclaim "myvolume" created

Prüfen Sie, ob der PVC erstellt wurde und an ein neues, aus dem Volume-Backup erstelltes Persistent Volume gebunden ist, indem Sie Folgendes eingeben:

kubectl get pvc

Die Ausgabe des obigen Befehls zeigt den aktuellen Status des PVC an:

			
NAME           STATUS    VOLUME                               CAPACITY   ACCESSMODES   STORAGECLASS   AGE
myvolume       Bound     ocid1.volume.oc1.iad.<unique_ID>     50Gi       RWO           oci            4m

Sie können das neue Persistent Volume, das aus dem Volume-Backup erstellt wurde, beim Definieren anderer Objekte, wie Pods, verwenden. Beispiel: Die folgende Poddefinition weist das System an, den myvolume-PVC als nginx-Volume zu verwenden, das vom Pod bei /data gemountet ist.

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
    - name: nginx
      image: nginx:latest
      ports:
        - name: http
          containerPort: 80
      volumeMounts:
        - name: data
          mountPath: /usr/share/nginx/html
  volumes:
    - name: data
      persistentVolumeClaim:
        claimName: myvolume

Nach Erstellen des neuen Pods können Sie prüfen, ob er ausgeführt wird und den neuen Persistent Volume Claim verwendet, indem Sie Folgendes eingeben:

kubectl describe pod nginx

Der Oracle Cloud Infrastructure Block Volume Service verschlüsselt immer alle Block-Volumes und Volume-Backups im Ruhezustand mit dem Advanced Encryption Standard-(AES-)Algorithmus und 256-Bit-Verschlüsselung. Standardmäßig werden alle Volumes und ihre Backups mit den von Oracle bereitgestellten Verschlüsselungsschlüsseln verschlüsselt. Jedes Mal, wenn ein Volume aus einem Backup geklont oder wiederhergestellt wird, wird dem Volume ein neuer eindeutiger Verschlüsselungsschlüssel zugewiesen.

Sie können alle Volumes und ihre Backups mit den Schlüsseln verschlüsseln, deren Eigentümer Sie sind, und die Sie mit dem Vault-Service verwalten. Weitere Informationen finden Sie unter Key Management. Wenn Sie kein Volume für die Verwendung des Vault-Service konfigurieren oder später die Zuweisung eines Schlüssels zu dem Volume aufheben, verwendet der Block Volume-Service stattdessen den von Oracle bereitgestellten Verschlüsselungsschlüssel. Das gilt sowohl für die Verschlüsselung im Ruhezustand als auch für die paravirtualisierte Verschlüsselung während der Übertragung.

Sämtliche Daten werden beim Verschieben zwischen der Instanz und dem Block-Volume über ein internes und besonders sicheres Netzwerk übertragen. Wenn Daten bei der Übertragung zwischen der Instanz und dem Block-Volume aufgrund spezieller Complianceanforderungen verschlüsselt werden müssen, bietet der Block Volume Service die Option zur Aktivierung der Verschlüsselung während der Übertragung für paravirtualisierte Volume-Anhänge auf VM-Instanzen (virtuellen Maschine). Einige Bare-Metal-Ausprägungen unterstützen die Verschlüsselung während der Übertragung für die über iSCSI angehängten Block-Volumes der Instanz.

Weitere Informationen zur Block-Volume-Verschlüsselung und zur Unterstützung der Verschlüsselung während der Übertragung finden Sie unter Block-Volume-Verschlüsselung.

Wenn Kubernetes-PVCs vom Block Volume-Service unterstützt werden, wählen Sie, wie Block-Volumes verschlüsselt werden, indem Sie Folgendes angeben:

• Der zu verwendende Masterverschlüsselungsschlüssel, indem die Eigenschaft kms-key-id in der Definition der Kubernetes-Speicherklasse festgelegt wird. Sie können die OCID eines Masterverschlüsselungsschlüssels im Vault-Service angeben.
• Wie das Block-Volume an die Compute-Instanz angehängt wird, indem Sie die Eigenschaft attachment-type in der Definition der Kubernetes-Speicherklasse auf iscsi oder paravirtualized setzen.
• Ob die Verschlüsselung während der Übertragung für jeden Knotenpool in einem Cluster aktiviert ist, indem die Eigenschaft isPvEncryptionInTransitEnabled des Knotenpools festgelegt wird (mit der CLI, der API oder der Option Verschlüsselung während der Übertragung verwenden: des Knotenpools in der Konsole).

Die Interaktion der von Ihnen angegebenen Einstellungen bestimmt, wie Block-Volumes verschlüsselt werden, wie in der Tabelle dargestellt:

Bevor Sie ein Cluster erstellen können, für das Sie den Masterverschlüsselungsschlüssel selbst verwalten möchten, müssen Sie folgende Schritte ausführen:

• Erstellen Sie einen geeigneten Master-Verschlüsselungsschlüssel in Vault (oder rufen Sie die OCID eines solchen Schlüssels ab). Siehe Schlüssel verwalten.
• Erstellen Sie eine Policy, die Zugriff auf den Masterverschlüsselungsschlüssel erteilt. Siehe Policy zum Zugriff auf benutzerverwaltete Verschlüsselungsschlüssel zum Verschlüsseln von Boot-Volumes, Block-Volumes und/oder Dateisystemen erstellen.

Weitere Informationen zur Schlüsselrotation im Vault-Service finden Sie unter Vault-Schlüssel rotieren.

Wenn ein PVC mit dem CSI-Volume-Plug-in (provisioner: blockvolume.csi.oraclecloud.com) erstellt wird, können Sie die Volume-Größe online erweitern. Dadurch können Sie Anwendungen zunächst mit einer bestimmten Speichermenge bereitstellen und anschließend den verfügbaren Speicher ohne Ausfallzeiten erhöhen.

Wenn Sie Erhöhungen von Speicheranforderungen unterstützen möchten, legen Sie allowVolumeExpansion: true in der Definition der Speicherklasse fest, die Sie für den PVC angeben. Beispiel:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: my-bv
provisioner: blockvolume.csi.oraclecloud.com
parameters:
  attachment-type: "paravirtualized"
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true

Die Standardspeicherklasse oci-bv für das CSI-Volume-Plug-in hat standardmäßig allowVolumeExpansion: true.

Um die Größe eines Volumes zu erweitern, bearbeiten Sie das PVC-Manifest, aktualisieren Sie die Volume-Größe, und wenden Sie das Manifest an. Wenn der Datenträger das nächste Mal neu gescannt wird, damit das Betriebssystem die erweiterte Volume-Größe identifizieren kann (was einige Minuten dauern kann), wird der erhöhte Speicher automatisch für Pods mit dem PVC verfügbar. Die Pods müssen nicht neu gestartet werden.

Geben Sie den folgenden Befehl ein, um zu bestätigen, dass PVC an ein neu vergrößertes Block-Volume gebunden wurde:

kubectl get pvc <pvc_name> -o yaml

Beachten Sie Folgendes:

• Die Volume-Erweiterung wird in Clustern unterstützt, auf denen Kubernetes 1.19 oder höher ausgeführt wird.
• Die Standardspeicherklasse oci-bv für das CSI-Volume-Plug-in wird mit allowVolumeExpansion: true in Clustern konfiguriert, auf denen Kubernetes 1.19 oder höher ausgeführt wird. Definitionen von oci-bv-Speicherklassen in vorhandenen Clustern, auf denen Kubernetes 1.19 oder höher ausgeführt wird, werden automatisch bearbeitet und setzen allowVolumeExpansion: true.
• Sie können die Größe eines Block-Volumes nicht reduzieren. Sie können nur einen größeren Wert als die aktuelle Größe des Block-Volumes angeben. Wenn Sie ein PVC-Manifest aktualisieren, um weniger Speicher als zuvor angefordert anzufordern, verläuft die Speicheranforderung nicht erfolgreich.
• Weitere Informationen zum Erhöhen der Block-Volume-Größen im Block-Volume Service finden Sie unter Volumes skalieren. Beachten Sie insbesondere die Empfehlung, ein Backup zu erstellen, bevor Sie die Größe eines Block-Volumes ändern.

Block-Volumes im Block-Volume-Service können entsprechend den erwarteten Workload-I/O-Anforderungen für verschiedene Performanceebenen konfiguriert werden. Die Block-Volume-Performance wird in Volume-Performanceeinheiten (Volume Performance Units, VPUs) ausgedrückt. Es stehen eine Reihe von Leistungsstufen zur Verfügung, darunter:

• Niedrigere Kosten (0 VPUs)
• Ausgeglichen (10 VPUs)
• Höhere Performance (20 VPUs)
• Äußerst hohe Performance (zwischen 30 VPUs und 120 VPUs)

Standardmäßig werden Block-Volumes für die Performanceebene Ausgeglichen (10 VPUs) konfiguriert. Weitere Informationen zu den verschiedenen Block-Volume-Performanceebenen finden Sie unter Block-Volume-Performanceebenen.

Wenn Sie einen PVC mit dem CSI-Volume-Plug-in (provisioner: blockvolume.csi.oraclecloud.com) definieren, können Sie in der Speicherklassendefinition eine andere Block-Volume-Performanceebene angeben, die für die erwartete Workload geeignet ist.

Beachten Sie, dass Sie die Performanceebene eines Block-Volumes, das PVC unterstützt, nachträglich nicht ändern können. Stattdessen müssen Sie eine neue Speicherklasse definieren, die Performanceebene nach Bedarf festlegen und ein neues PVC erstellen, das von dieser neuen Speicherklasse bereitgestellt wird.

Block-Volumes im Block-Volume-Service können für verschiedene Dateisystemtypen konfiguriert werden. Das am besten geeignete Dateisystem hängt (unter anderem) von der erwarteten Dateigröße und der Anzahl der zu verarbeitenden Dateien ab. Es stehen verschiedene Dateisystemtypen zur Verfügung, darunter:

• ext3: Der Dateisystemtyp ext3 umfasst Journaling-Funktionen zur Verbesserung der Zuverlässigkeit und Verfügbarkeit. Konsistenzprüfungen nach einem Stromausfall oder einem unkontrollierten Herunterfahren des Systems sind nicht erforderlich.
• ext4: Neben den ext3-Features unterstützt der Dateisystemtyp ext4 Extents (zusammenhängende physische Blöcke), Vorabzuweisung, verzögerte Zuweisung, schnellere Dateisystemprüfung, robusteres Journaling und andere Verbesserungen.
• XFS: Das XFS-Dateisystem ist ein leistungsstarker Journaling-Dateisystemtyp, der eine hohe Skalierbarkeit für I/O-Threads, Dateisystembandbreite, Datei- und Dateisystemgröße bietet, selbst wenn das Dateisystem viele Speichergeräte umfasst.

Die Dateisysteme ext3 und ext4 werden im Allgemeinen als besser geeignet für Anwendungen betrachtet, die einen einzelnen Lese-/Schreib-Thread und kleine Dateien verwenden. Während das XFS-Dateisystem im Allgemeinen als besser geeignet für Anwendungen mit mehreren Lese-/Schreib-Threads und größeren Dateien angesehen wird.

Wenn ein PVC mit dem CSI-Volume-Plug-in (provisioner: blockvolume.csi.oraclecloud.com) erstellt wird, können Sie einen Dateisystemtyp für das Block-Volume angeben, der für die erwartete Workload geeignet ist.

Standardmäßig werden Block-Volumes mit einem ext4-Dateisystem konfiguriert. Wenn das Dateisystem ext4 nicht das am besten geeignete Dateisystem für die erwartete Workload ist, können Sie in der Definition der Speicherklasse einen alternativen Dateisystemtyp angeben.

Um einen PVC zu erstellen, der von einem Block-Volume mit einem ext3- oder XFS-Dateisystem unterstützt wird, legen Sie den Parameter fstype in der Definition der benutzerdefinierten Speicherklasse wie folgt fest:

• Legen Sie für ext3 csi.storage.k8s.io/fstype: ext3 fest
• für XFS setzen Sie csi.storage.k8s.io/fstype: xfs

Beispiel: So erstellen Sie einen PVC, der von einem Block-Volume mit einem ext3-Dateisystem gesichert wird:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: oci-bv-ext3
provisioner: blockvolume.csi.oraclecloud.com
parameters:
  csi.storage.k8s.io/fstype: ext3
reclaimPolicy: Retain
allowVolumeExpansion: true
volumeBindingMode: WaitForConsumer

Erstellen Sie ein Manifest für ein PVC, das von der Speicherklasse oci-bv-ext3 bereitgestellt wird, und fügen Sie eine Speicheranforderung hinzu. Beispiel: In einer Datei mit dem Namen csi-bvs-pvc-fstype.yaml:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: oci-bv-claim-ext3
spec:
  storageClassName: oci-bv-ext3
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 50Gi

Geben Sie den folgenden Befehl ein, um den PVC aus der csi-bvs-PVC-fstype.yaml-Datei zu erstellen:

kubectl apply -f csi-bvs-pvc-fstype.yaml

Nachdem Sie den PVC erstellt haben, können Sie ihn beim Erstellen anderer Objekte, wie Pods, verwenden. Beispiel: Sie können einen neuen Pod aus der folgenden Poddefinition erstellen, die das System anweist, den PVC "oci-bv-claim-ext3" als nginx-Volume zu verwenden, das vom Pod bei /data gemountet ist.

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
    - name: nginx
      image: nginx:latest
      ports:
        - name: http
          containerPort: 80
      volumeMounts:
        - name: data
          mountPath: /usr/share/nginx/html
  volumes:
    - name: data
      persistentVolumeClaim:
        claimName: oci-bv-claim-ext3

Nach Erstellen des neuen Pods können Sie prüfen, ob der PVC an ein neues Persistent Volume gebunden wurde, indem Sie Folgendes eingeben:

kubectl get pvc

Die Ausgabe des obigen Befehls bestätigt, dass der PVC gebunden wurde:

			
NAME                    STATUS    VOLUME                               CAPACITY   ACCESSMODES   STORAGECLASS        AGE
oci-bv-claim-ext3       Bound     ocid1.volume.oc1.iad.<unique_ID>     50Gi       RWO           oci-bv-ext3         4m

Sie können prüfen, ob der Pod den neuen Persistent Volume Claim verwendet, indem Sie Folgendes eingeben:

kubectl describe pod nginx

Beachten Sie, dass Sie das Dateisystem eines Block-Volumes, das PVC unterstützt, nachträglich nicht ändern können. Stattdessen müssen Sie eine neue Speicherklasse definieren, das Dateisystem nach Bedarf einstellen und ein neues PVC erstellen, das von dieser neuen Speicherklasse bereitgestellt wird.

Wenn Sie das CSI-Volume-Plug-in (provisioner: blockvolume.csi.oraclecloud.com ) verwenden, um Cluster mit Block-Volumes im Block-Volume-Service zu verbinden, können Sie ein PVC an ein PV binden, das von einem Block-Volume bereitgestellt wird, das als Raw-Block-Volume konfiguriert ist. Wenn ein Block-Volume als Raw-Block-Volume und nicht als gemountetes Dateisystem konfiguriert wurde, wird ein von diesem Block-Volume bereitgestelltes PV als Block-Device für die Container angezeigt, die in einem Cluster ausgeführt werden. Dadurch können Anwendungen, die im Container ausgeführt werden, als Block-Device auf das angehängte Block-Volume zugreifen, ohne dass der Performance-Overhead durch den Zugriff auf das Device über ein Dateisystem verursacht wird. Dieser Overhead kann besonders für leistungsabhängige Anwendungen (wie Datenbanken) von Bedeutung sein, die vom direkten Zugriff auf Block-Devices profitieren.

Um das Block-Volume zu konfigurieren, das ein PVC als Raw-Block-Volume unterstützt, geben Sie volumeMode: Block im PVC-Manifest an. Wenn keine Angabe gemacht wird, wird volumeMode: Filesystem angenommen, und Block-Volumes werden standardmäßig mit einem ext4-Dateisystem konfiguriert.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-raw-block-volume
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 50Gi
  storageClassName: oci-bv
  volumeMode: Block

Geben Sie den folgenden Befehl ein, um den PVC aus der csi-bvs-PVC-raw.yaml-Datei zu erstellen:

kubectl apply -f csi-bvs-pvc-raw.yaml

Nachdem Sie den PVC erstellt haben, können Sie ihn beim Erstellen anderer Objekte, wie Pods, verwenden. Beispiel: Sie können einen neuen Pod aus der folgenden Poddefinition erstellen, der das System anweist, PVC-Raw-Block-Volume als Speicherdatenträger für den Raw-Volume-Testcontainer zu verwenden, auf den der Container unter /dev/block zugreifen kann:

apiVersion: v1
kind: Pod
metadata:
  name: raw-volume-test-pod
spec:
  containers:
  - name: raw-volume-test
    image: centos
    command: ["/bin/sh"]
    volumeDevices:
    - name: raw-volume
      devicePath: /dev/block
  volumes:
  - name: raw-volume
    persistentVolumeClaim:
      claimName: pvc-raw-block-volume

Nach Erstellen des neuen Pods können Sie prüfen, ob der PVC an ein neues Persistent Volume gebunden wurde, indem Sie Folgendes eingeben:

kubectl get pvc

Die Ausgabe des obigen Befehls bestätigt, dass der PVC gebunden wurde:

			
NAME                    STATUS    VOLUME                               CAPACITY   ACCESSMODES   STORAGECLASS        AGE
pvc-raw-block-volume    Bound     ocid1.volume.oc1.iad.<unique_ID>     50Gi       RWO           oci-bv              4m

Sie können prüfen, ob der Pod den neuen Persistent Volume Claim verwendet, indem Sie Folgendes eingeben:

kubectl describe pod raw-volume-test-pod

Beachten Sie, dass Sie später nicht ändern können, ob das Block-Volume, das ein PVC unterstützt, als Raw-Block-Volume oder als gemountetes Dateisystem konfiguriert ist. Stattdessen müssen Sie ein neues PVC erstellen und volumeMode: entsprechend im PVC-Manifest festlegen.