Aprovisionamiento de PVC en el servicio Block Volume

Puede aprovisionar dinámicamente un volumen en bloque mediante el plugin CSI especificado por la definición de la clase de almacenamiento oci-bv (provisioner: blockvolume.csi.oraclecloud.com). Por ejemplo, si el administrador del cluster no ha creado ningún PV adecuado que coincida con la solicitud de PVC.

Se define una PVC en un archivo llamado csi-bvs-pvc.yaml. Por ejemplo:

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

Introduzca el siguiente comando para crear la PVC a partir del archivo csi-bvs-pvc.yaml:

kubectl create -f  csi-bvs-pvc.yaml

La salida del comando anterior confirma la creación de la PVC.

persistentvolumeclaim "mynginxclaim" created

Verifique que la PVC se haya creado ejecutando kubectl get pvc:

kubectl get pvc

La salida del comando anterior muestra el estado actual de la PVC:

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

La PVC tiene el estado Pending porque la definición de la clase de almacenamiento oci-bv incluye volumeBindingMode: WaitForFirstConsumer.

Puede utilizar esta PVC al crear otros objetos, como pods. Por ejemplo, puede crear un nuevo pod a partir de la siguiente definición de pod, que indica al sistema que utilice la PVC mynginxclaim como volumen nginx, montado por el pod en /data.

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

Tras crear el nuevo pod, puede verificar que la PVC se haya enlazado a un nuevo volumen persistente introduciendo:

kubectl get pvc

La salida del comando anterior confirma que la PVC se ha enlazado:

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

Puede verificar que el pod está utilizando la nueva reclamación de volumen persistente introduciendo:

kubectl describe pod nginx

Puede ver las estadísticas de capacidad del nuevo volumen persistente mediante una herramienta de agregación de métricas como Prometheus.

Una instantánea de volumen de Kubernetes es una instantánea de un volumen persistente en un sistema de almacenamiento. Puede utilizar una instantánea de volumen para aprovisionar un nuevo volumen persistente. Para obtener más información sobre las instantáneas de volumen de Kubernetes, consulte Instantáneas de volumen en la documentación de Kubernetes.

Al utilizar el plugin de volumen CSI para conectar clusters a volúmenes en bloque en el servicio Volumen en bloque, puede utilizar copias de seguridad de volumen en bloque para aprovisionar instantáneas de volumen de Kubernetes. Puede utilizar una instantánea de volumen para crear un nuevo volumen en bloque y rellenarlo previamente con datos de la copia de seguridad de volumen en bloque. Para obtener más información sobre las copias de seguridad de volumen en bloque en el servicio de volumen en bloque, consulte Descripción general de copias de seguridad de volumen en bloque.

Puede utilizar el plugin de volumen CSI para aprovisionar una instantánea de volumen de una de las dos maneras siguientes:

• Dinámicamente: puede solicitar la creación de una copia de seguridad del volumen en bloque que aprovisiona un volumen persistente. Especifique la reclamación de volumen persistente mediante el objeto VolumeSnapshot y especifique los parámetros que se utilizarán para crear la copia de seguridad de volumen en bloque mediante el objeto VolumeSnapshotClass. Las instantáneas de volúmenes aprovisionadas dinámicamente también se denominan instantáneas de volúmenes dinámicos. Consulte Creación de instantáneas de volumen aprovisionadas dinámicamente.
• Estáticamente: puede proporcionar detalles de una copia de seguridad de volumen en bloque existente mediante el objeto VolumeSnapshotContent. Las instantáneas de volúmenes aprovisionadas estáticamente también se conocen como instantáneas de volúmenes estáticos y como instantáneas de volúmenes aprovisionadas previamente. Creación de instantáneas de volumen aprovisionadas estáticamente

Al crear una instantánea de volumen aprovisionada dinámicamente, se aplican a la copia de seguridad del volumen en bloque las mismas etiquetas de formato libre y definidas que se han aplicado al volumen en bloque de origen. Sin embargo, puede utilizar parámetros para aplicar etiquetas adicionales a la copia de seguridad del volumen en bloque (consulte Etiquetado de copias de seguridad de volumen en bloque).

Hay una serie de requisitos que cumplir antes de crear instantáneas de volumen para su uso con clusters creados por Container Engine for Kubernetes. Consulte Requisitos para crear instantáneas de volumen.

Tenga en cuenta lo siguiente al crear y utilizar instantáneas de volúmenes:

• Solo puede crear instantáneas de volumen al utilizar el plugin de volumen CSI (es decir, no puede crear instantáneas de volumen al utilizar el plugin de volumen FlexVolume).
• En el caso de las copias de seguridad de volumen dinámicas, el plugin de volumen CSI crea una nueva copia de seguridad de volumen en bloque para aprovisionar una instantánea de volumen dinámica en el mismo compartimento que el cluster. En el caso de instantáneas de volumen estáticas, la copia de seguridad de volumen en bloque que aprovisiona una instantánea de volumen estática puede estar en un compartimento diferente al cluster, siempre que existan sentencias de política adecuadas para permitir que el cluster acceda a ese otro compartimento (consulte Requisitos para crear instantáneas de volumen).
• No puede utilizar el plugin de volumen CSI para volver a rellenar un volumen existente con datos. En otras palabras, no puede restaurar (revertir) los datos de un volumen persistente existente a un estado anterior cambiando la instantánea de volumen especificada en el manifiesto de la reclamación de volumen persistente. Solo puede usar el plugin de volumen CSI para rellenar un nuevo volumen con datos.
• Al crear una copia de seguridad de un volumen en bloque (por ejemplo, al crear una instantánea de un volumen dinámico), la clave de cifrado que se utilizó al crear el volumen en bloque también se utiliza para crear la copia de seguridad del volumen en bloque. No puede especificar una nueva clave de cifrado al crear una copia de seguridad de volumen en bloque. Por tanto, la copia de seguridad del volumen en bloque utiliza el mismo cifrado que el volumen en bloque del que realiza la copia de seguridad.
• El tamaño especificado para un volumen persistente aprovisionado por una instantánea de volumen no debe ser menor que el tamaño del volumen original a partir del cual se creó la instantánea.
• Cuando el plugin de volumen CSI crea un nuevo volumen en bloque para respaldar un volumen persistente aprovisionado por una instantánea de volumen, la ubicación del volumen en bloque depende de los requisitos de topología de la solicitud de creación de volumen. Por ejemplo, si el plugin de volumen CSI crea un volumen en bloque para un pod que utiliza una reclamación de volumen persistente, el volumen en bloque se crea en el mismo dominio de disponibilidad que el nodo de trabajador en el que se está ejecutando el pod.
• Las instantáneas entre espacios de nombres no están soportadas.

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

Una clonación de Kubernetes es un duplicado exacto de un volumen persistente existente en un sistema de almacenamiento. Puede clonar un volumen persistente existente para aprovisionar una nueva reclamación de volumen persistente. El nuevo volumen persistente contiene una copia de los datos del volumen persistente de origen, pero es independiente del volumen persistente de origen. Puede utilizar las clonaciones de volúmenes para probar los cambios de configuración rápidamente, sin que esto afecte a un entorno de producción. Para obtener más información sobre las clonaciones de Kubernetes, consulte Clonación de volúmenes CSI en la documentación de Kubernetes.

En el servicio de volumen en bloque, puede clonar un volumen en bloque para crear un nuevo volumen en bloque relleno previamente con datos del volumen en bloque de origen. Para obtener más información sobre la clonación de volúmenes en bloque en el servicio de volumen en bloque, consulte Clonación de un volumen en bloque.

Al utilizar el plugin de volumen CSI para conectar clusters a volúmenes en bloque en el servicio Block Volume, puede aprovisionar una nueva PVC con un nuevo volumen en bloque que se haya clonado a partir de un volumen en bloque existente aprovisionando otra PVC existente. Para indicar que desea que el plugin de volumen CSI clone el volumen en bloque existente para la nueva PVC, especifique la PVC existente como origen de datos para la nueva PVC.

El nuevo PVC se puede utilizar de la misma manera que cualquier otro PVC, y es completamente independiente del PVC existente especificado como origen de datos. Del mismo modo, el nuevo volumen en bloque y el volumen en bloque existente desde el que se clona son recursos totalmente independientes y se pueden actualizar, clonar, crear instantáneas y suprimir de forma independiente.

En cuanto se haya clonado el volumen en bloque de origen y se haya creado un nuevo volumen en bloque (normalmente en unos segundos), el nuevo volumen en bloque tendrá el estado Disponible. Todos los datos presentes en el volumen en bloque de origen en ese momento se copian en el nuevo volumen en bloque (no se copian los cambios posteriores). Sin embargo, los datos se copian en segundo plano, lo que puede tardar hasta treinta minutos en función del tamaño del volumen en bloque (por ejemplo, puede tardar hasta quince minutos en copiar un volumen en bloque de 1 TB). Por lo tanto, para evitar la posibilidad de errores o corrupción de datos, la nueva PVC tiene el estado Pendiente hasta que se hayan copiado todos los datos. Cuando se han copiado todos los datos, la nueva PVC se enlaza al PV aprovisionado por el nuevo volumen en bloque y la nueva PVC tiene el estado Disponible.

Hay una serie de requisitos que se deben cumplir antes de aprovisionar una nueva reclamación de volumen persistente mediante la clonación del volumen en bloque que ya está aprovisionando una reclamación de volumen persistente existente. Consulte Requisitos para clonar un volumen en bloque existente para aprovisionar una nueva PVC.

Tenga en cuenta lo siguiente al clonar un volumen en bloque para aprovisionar una nueva PVC:

• El plugin del volumen CSI crea el nuevo volumen en bloque en el mismo dominio de disponibilidad, región y arrendamiento que el volumen en bloque de origen.
• El nuevo volumen en bloque creado por el plugin de volumen CSI se puede clonar en cuanto tenga el estado Available.
• Los requisitos de topología de una solicitud de creación de volúmenes se ignoran. Por ejemplo, si el plugin de volumen CSI clona un volumen en bloque para un pod que utiliza una reclamación de volumen persistente, el nuevo volumen en bloque se crea en el mismo dominio de disponibilidad que el nodo de trabajador en el que se está ejecutando el pod.
• No puede utilizar el plugin de volumen CSI para clonar volúmenes en bloque creados por el plugin de volumen FlexVolume.
• No puede suprimir la PVC de origen mientras la clonación está en curso. Del mismo modo, no puede suprimir un volumen en bloque de origen mientras se copian los datos en un volumen en bloque que se ha clonado a partir de él.
• La clonación entre espacios de nombres no está soportada. El nuevo PVC y el PVC de origen deben estar en el mismo espacio de nombres.
• No es necesario especificar explícitamente una clase de almacenamiento para la nueva PVC. Si especifica explícitamente una clase de almacenamiento para la nueva PVC, la clase de almacenamiento que especifique puede ser diferente a la clase de almacenamiento especificada para la PVC de origen. Si no especifica una clase de almacenamiento para la nueva PVC, se utiliza la clase de almacenamiento por defecto.

Por ejemplo, puede definir una reclamación de volumen persistente denominada my-clone-pvc en un archivo denominado csi-myclonepvc.yaml. La reclamación de volumen persistente my-clone-pvc se aprovisiona mediante un volumen en bloque creado mediante la clonación del volumen en bloque que aprovisiona la reclamación de volumen persistente my-source-pvc:

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

Cree la reclamación de volúmenes persistentes:

kubectl create -f csi-myclonepvc.yaml

Puede utilizar la reclamación de volumen persistente al definir otros objetos, como los pods. Por ejemplo, la siguiente definición de pod indica al sistema que utilice la reclamación de volumen persistente my-clone-pvc como volumen nginx, montado por el pod en /sample-volume.

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

Una vez creado el nuevo pod, la reclamación de volumen persistente my-clone-pvc está enlazada a un nuevo volumen persistente aprovisionado por un volumen en bloque que se ha clonado a partir del volumen en bloque que aprovisiona la reclamación de volumen persistente my-source-pvc.

Puede crear una PVC a partir de un volumen en bloque existente o una copia de seguridad de volumen en bloque para que la utilice el plugin de volumen FlexVolume. Por ejemplo, si el administrador del cluster ha creado una copia de seguridad de volumen en bloque para que la utilice al aprovisionar una nueva reclamación de volumen persistente. Esta copia de seguridad de volumen en bloque puede incluir datos listos para su uso por otros objetos como pods.

Se define una PVC en un archivo denominado flex-pvcfrombackup.yaml. Utilice el elemento de anotación volume.beta.kubernetes.io/oci-volume-source para especificar el origen del volumen en bloque que se va a utilizar al aprovisionar una nueva reclamación de volumen persistente mediante el plugin de volumen FlexVolume. Puede especificar el OCID de un volumen en bloque o una copia de seguridad de volumen en bloque como el valor de la anotación. En este ejemplo, especifique el OCID de la copia de seguridad de volumen en bloque creada por el administrador del cluster. Por ejemplo:

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

Tenga en cuenta que el archivo flex-pvcfrombackup.yaml incluye el elemento matchLabels, que solo es aplicable en el caso del plugin de volumen FlexVolume.

Introduzca el siguiente comando para crear la PVC a partir del archivo flex-pvcfrombackup.yaml:

kubectl create -f flex-pvcfrombackup.yaml

La salida del comando anterior confirma la creación de la PVC.

persistentvolumeclaim "myvolume" created

Verifique que la PVC se ha creado y enlazado a un nuevo volumen persistente creado a partir de la copia de seguridad de volumen introduciendo:

kubectl get pvc

La salida del comando anterior muestra el estado actual de la PVC:

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

Puede utilizar el nuevo volumen persistente creado a partir de la copia de seguridad del volumen al definir otros objetos, como los pods. Por ejemplo, la siguiente definición de pod indica al sistema que utilice la PVC como volumen nginx, montado por el pod en /data.

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

Tras crear el nuevo pod, puede verificar que se está ejecutando y utilizando la nueva reclamación de volumen persistente introduciendo:

kubectl describe pod nginx

El servicio Oracle Cloud Infrastructure Block Volume siempre cifra todos los volúmenes en bloque y las copias de seguridad de volumen estáticas mediante el algoritmo estándar de cifrado avanzado (AES) con cifrado de 256 bits. Por defecto, todos los volúmenes y sus copias de seguridad se cifran con las claves de cifrado proporcionadas por Oracle. Cada vez que se clona o restaura un volumen a partir de una copia de seguridad, se le asigna una nueva clave de cifrado única.

Puede cifrar todos los volúmenes y sus copias de seguridad mediante claves propias y gestionar mediante el servicio de almacén. Para obtener más información, consulte Gestión de claves. Si no configura un volumen para que utilice el servicio de almacén ni anula posteriormente la asignación de una clave del volumen, el servicio de volumen en bloque utiliza la clave de cifrado proporcionada por Oracle en su lugar. Esto se aplica tanto al cifrado estático como al cifrado en tránsito paravirtualizado.

Todos los datos que se mueven entre la instancia y el volumen en bloque se transfieren a través de una red interna altamente segura. Si tiene requisitos de conformidad específicos relacionados con el cifrado de los datos mientras se mueven entre la instancia y el volumen en bloque, el servicio de volumen en bloque proporciona la opción de activar el cifrado en tránsito para asociaciones de volúmenes paravirtualizadas en instancias de máquina virtual (VM). Algunas unidades dedicadas admiten el cifrado en tránsito para los volúmenes en bloque con asociación iSCSI de la instancia.

Para obtener más información sobre el cifrado de volúmenes en bloque y el soporte de cifrado en tránsito, consulte Cifrado de volumen en bloque.

Cuando las PVC de Kubernetes están respaldadas por el servicio de volumen en bloque, puede elegir cómo se cifran los volúmenes en bloque especificando:

• Clave de cifrado maestra que se va a utilizar, definiendo la propiedad kms-key-id en la definición de la clase de almacenamiento de Kubernetes. Puede especificar el OCID de una clave de cifrado maestra en el servicio Almacén.
• Cómo se asocia el volumen en bloque a la instancia informática definiendo la propiedad attachment-type en la definición de la clase de almacenamiento de Kubernetes en iscsi o paravirtualized.
• Si el cifrado en tránsito está activado para cada pool de nodos de un cluster, mediante la configuración de la propiedad isPvEncryptionInTransitEnabled del pool de nodos (mediante la CLI, la API o la opción Usar cifrado en tránsito del pool de nodos en la consola).

La interacción de la configuración que especifique determina cómo se cifran los volúmenes en bloque, como se muestra en la tabla:

Para poder crear un cluster para el que desee gestionar la clave de cifrado maestra usted mismo, debe:

• Cree una clave de cifrado maestra adecuada en el almacén de claves (u obtenga el OCID de dicha clave). Consulte Gestión de claves.
• Cree una política que otorgue acceso a la clave de cifrado maestra. Consulte Create Policy to Access User-Managed Encryption Keys for Encrypting Boot Volumes, Block Volumes, and/o File Systems.

Para obtener más información sobre la rotación de claves en el servicio Vault, consulte Rotación de una clave de Vault.

Cuando se crea una PVC con el plugin de volumen CSI (provisioner: blockvolume.csi.oraclecloud.com), puede ampliar el tamaño del volumen en línea. Al hacerlo, permite desplegar inicialmente aplicaciones con una determinada cantidad de almacenamiento y, a continuación, aumentar el almacenamiento disponible sin tiempo de inactividad.

Si desea soportar aumentos de solicitudes de almacenamiento, defina allowVolumeExpansion: true en la definición de la clase de almacenamiento que especifique para la PVC. Por ejemplo:

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

La clase de almacenamiento oci-bv por defecto para el plugin de volumen CSI tiene allowVolumeExpansion: true por defecto.

Para ampliar el tamaño de un volumen, edite el manifiesto de PVC, actualice el tamaño del volumen y, a continuación, aplique el manifiesto. La próxima vez que se vuelva a explorar el disco para permitir que el sistema operativo identifique el tamaño de volumen ampliado (que puede tardar unos minutos), el almacenamiento aumentado estará disponible automáticamente para los pods mediante PVC. No es necesario reiniciar los pods.

Introduzca el siguiente comando para confirmar que la PVC se ha enlazado a un volumen en bloque recién ampliado:

kubectl get pvc <pvc_name> -o yaml

Tenga en cuenta lo siguiente:

• La expansión de volúmenes está soportada en clusters que ejecutan Kubernetes 1.19 o posterior.
• La clase de almacenamiento oci-bv por defecto para el plugin de volumen CSI se configura con allowVolumeExpansion: true en clusters que ejecutan Kubernetes 1.19 o posterior. Las definiciones de clases de almacenamiento oci-bv en clusters existentes que ejecutan Kubernetes 1.19 o posterior se editan automáticamente para definir allowVolumeExpansion: true.
• No puede reducir el tamaño de un volumen en bloque. Solo puede especificar un valor mayor que el tamaño actual del volumen en bloque. Si actualiza un manifiesto de PVC para solicitar menos almacenamiento del solicitado anteriormente, la solicitud de almacenamiento falla.
• Para obtener más información sobre cómo aumentar el tamaño de los volúmenes en bloque en el servicio de volumen en bloque, consulte Cambio de tamaño de un volumen. En concreto, tenga en cuenta la recomendación de crear una copia de seguridad antes de cambiar el tamaño de un volumen en bloque.

Los volúmenes en bloque del servicio de volumen en bloque se pueden configurar para distintos niveles de rendimiento, según los requisitos de E/S de carga de trabajo esperados. El rendimiento de los volúmenes en bloque se expresa en unidades de rendimiento de volumen (VPU). Hay una serie de niveles de rendimiento disponibles, que incluyen:

• Costo bajo (0 VPU)
• Equilibrado (10 VPU)
• Alto rendimiento (20 VPU)
• Rendimiento ultraalto (entre 30 VPU y 120 VPU)

Por defecto, los volúmenes en bloque se configuran para el nivel de rendimiento Equilibrado (10 VPU). Para obtener más información sobre los diferentes niveles de rendimiento de volumen en bloque, consulte Niveles de rendimiento de volumen en bloque.

Al definir una PVC mediante el plugin de volumen CSI (provisioner: blockvolume.csi.oraclecloud.com), puede especificar un nivel de rendimiento de volumen en bloque diferente en la definición de clase de almacenamiento que sea adecuado para la carga de trabajo esperada.

Tenga en cuenta que no puede cambiar posteriormente el nivel de rendimiento de un volumen en bloque que realiza una copia de seguridad de PVC. En su lugar, debe definir una nueva clase de almacenamiento, definir el nivel de rendimiento según sea necesario y crear una nueva PVC aprovisionada por esa nueva clase de almacenamiento.

Los volúmenes en bloque del servicio de volumen en bloque se pueden configurar para diferentes tipos de sistemas de archivos. El sistema de archivos más adecuado para utilizar depende (entre otras cosas) del tamaño de archivo esperado y del número de archivos que se van a procesar. Hay varios tipos de sistemas de archivos disponibles, incluidos:

• ext3: el tipo de sistema de archivos ext3 incluye capacidades de registro por diario para mejorar la fiabilidad y la disponibilidad. Las comprobaciones de coherencia después de un fallo de alimentación o un cierre incontrolado del sistema no son necesarias.
• ext4: además de las funciones ext3, el tipo de sistema de archivos ext4 soporta extensiones (bloques físicos contiguos), asignación previa, asignación retrasada, comprobación más rápida del sistema de archivos, registro por diario más sólido y otras mejoras.
• XFS: el sistema de archivos XFS es un tipo de sistema de archivos de registro por diario de alto rendimiento, que proporciona alta escalabilidad para threads de E/S, ancho de banda del sistema de archivos, tamaño de archivo y sistema de archivos, incluso cuando el sistema de archivos abarca muchos dispositivos de almacenamiento.

Los sistemas de archivos ext3 y ext4 se suelen considerar más adecuados para las aplicaciones que utilizan un único thread de lectura/escritura y archivos pequeños. Mientras que, el sistema de archivos XFS generalmente se considera más adecuado para aplicaciones que tienen varios threads de lectura/escritura y archivos más grandes.

Cuando se crea una PVC mediante el plugin de volumen CSI (provisioner: blockvolume.csi.oraclecloud.com), puede especificar un tipo de sistema de archivos para el volumen en bloque adecuado para la carga de trabajo esperada.

Por defecto, los volúmenes en bloque se configuran con un sistema de archivos ext4. Si el sistema de archivos ext4 no es el más adecuado para la carga de trabajo esperada, puede especificar un tipo de sistema de archivos alternativo en la definición de clase de almacenamiento.

Para crear una PVC respaldada por un volumen en bloque con un sistema de archivos ext3 o XFS, defina el parámetro fstype en la definición de clase de almacenamiento personalizada de la siguiente forma:

• para ext3, defina csi.storage.k8s.io/fstype: ext3
• para XFS, establezca csi.storage.k8s.io/fstype: xfs

Por ejemplo, para crear una PVC respaldada por un volumen en bloque con un sistema de archivos ext3:

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

Cree un manifiesto para una PVC aprovisionada por la clase de almacenamiento oci-bv-ext3 e incluya una solicitud de almacenamiento. Por ejemplo, en un archivo denominado 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

Introduzca el siguiente comando para crear la PVC a partir del archivo csi-bvs-PVC-fstype.yaml:

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

Una vez creada la PVC, puede utilizarla al crear otros objetos, como pods. Por ejemplo, puede crear un nuevo pod a partir de la siguiente definición de pod, que indica al sistema que utilice la PVC oci-bv-claim-ext3 como volumen nginx, montado por el pod en /data.

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

Tras crear el nuevo pod, puede verificar que la PVC se haya enlazado a un nuevo volumen persistente introduciendo:

kubectl get pvc

La salida del comando anterior confirma que la PVC se ha enlazado:

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

Puede verificar que el pod está utilizando la nueva reclamación de volumen persistente introduciendo:

kubectl describe pod nginx

Tenga en cuenta que no puede cambiar posteriormente el sistema de archivos de un volumen en bloque que realiza una copia de seguridad de PVC. En su lugar, debe definir una nueva clase de almacenamiento, definir el sistema de archivos según sea necesario y crear una nueva PVC aprovisionada por esa nueva clase de almacenamiento.