Kubernetes - Volúmenes

En Kubernetes, un volumen se puede considerar como un directorio al que pueden acceder los contenedores de un pod. Tenemos diferentes tipos de volúmenes en Kubernetes y el tipo define cómo se crea el volumen y su contenido.

El concepto de volumen estaba presente con el Docker, sin embargo, el único problema era que el volumen estaba muy limitado a un módulo en particular. Tan pronto como terminó la vida de una cápsula, el volumen también se perdió.

Por otro lado, los volúmenes que se crean a través de Kubernetes no se limitan a ningún contenedor. Admite cualquiera o todos los contenedores implementados dentro del pod de Kubernetes. Una ventaja clave del volumen de Kubernetes es que admite diferentes tipos de almacenamiento en los que el pod puede usar varios de ellos al mismo tiempo.

Tipos de volumen de Kubernetes

Aquí hay una lista de algunos volúmenes populares de Kubernetes:

  • emptyDir- Es un tipo de volumen que se crea cuando un Pod se asigna por primera vez a un Nodo. Permanece activo mientras el Pod se esté ejecutando en ese nodo. El volumen está inicialmente vacío y los contenedores del pod pueden leer y escribir los archivos en el volumen emptyDir. Una vez que se quita el Pod del nodo, se borran los datos en emptyDir.

  • hostPath - Este tipo de volumen monta un archivo o directorio desde el sistema de archivos del nodo host en su pod.

  • gcePersistentDisk- Este tipo de volumen monta un disco persistente de Google Compute Engine (GCE) en su pod. Los datos en ungcePersistentDisk permanece intacto cuando el Pod se retira del nodo.

  • awsElasticBlockStore- Este tipo de volumen monta un almacén de bloques elásticos de Amazon Web Services (AWS) en su pod. Al igual quegcePersistentDisk, los datos en un awsElasticBlockStore permanece intacto cuando el Pod se retira del nodo.

  • nfs - un nfsvolume permite montar un NFS (Network File System) existente en su pod. Los datos en unnfsel volumen no se borra cuando el Pod se quita del nodo. El volumen solo está desmontado.

  • iscsi - un iscsi volume permite montar un volumen iSCSI (SCSI sobre IP) existente en su pod.

  • flocker- Es un administrador de volumen de datos de contenedor agrupado de código abierto. Se utiliza para administrar volúmenes de datos. UNflockervolume permite montar un conjunto de datos Flocker en un pod. Si el conjunto de datos no existe en Flocker, primero debe crearlo utilizando la API de Flocker.

  • glusterfs- Glusterfs es un sistema de archivos en red de código abierto. Un volumen glusterfs permite montar un volumen glusterfs en su pod.

  • rbd- RBD son las siglas de Rados Block Device. Unrbdvolume permite montar un volumen de dispositivo de bloque Rados en su pod. Los datos permanecen conservados después de que el Pod se elimina del nodo.

  • cephfs - A cephfsvolume permite montar un volumen CephFS existente en su pod. Los datos permanecen intactos después de que el Pod se elimina del nodo.

  • gitRepo - A gitRepo volumen monta un directorio vacío y clona un git repositorio en él para que lo use su pod.

  • secret - A secret el volumen se utiliza para pasar información confidencial, como contraseñas, a los pods.

  • persistentVolumeClaim - A persistentVolumeClaimvolume se utiliza para montar un PersistentVolume en un pod. PersistentVolumes es una forma de que los usuarios "reclamen" almacenamiento duradero (como un GCE PersistentDisk o un volumen iSCSI) sin conocer los detalles del entorno de nube en particular.

  • downwardAPI - A downwardAPIEl volumen se utiliza para hacer que los datos API descendentes estén disponibles para las aplicaciones. Monta un directorio y escribe los datos solicitados en archivos de texto sin formato.

  • azureDiskVolume - un AzureDiskVolume se utiliza para montar un disco de datos de Microsoft Azure en un pod.

Volumen persistente y reclamo de volumen persistente

Persistent Volume (PV)- Es una pieza de almacenamiento de red que ha sido aprovisionada por el administrador. Es un recurso en el clúster que es independiente de cualquier pod individual que use el PV.

Persistent Volume Claim (PVC)- El almacenamiento solicitado por Kubernetes para sus pods se conoce como PVC. El usuario no necesita conocer el aprovisionamiento subyacente. Las notificaciones deben crearse en el mismo espacio de nombres donde se crea el pod.

Creación de volumen persistente

kind: PersistentVolume ---------> 1
apiVersion: v1
metadata:
   name: pv0001 ------------------> 2
   labels:
      type: local
spec:
   capacity: -----------------------> 3
      storage: 10Gi ----------------------> 4
   accessModes:
      - ReadWriteOnce -------------------> 5
      hostPath:
         path: "/tmp/data01" --------------------------> 6

En el código anterior, hemos definido:

  • kind: PersistentVolume → Hemos definido el tipo como PersistentVolume que le dice a kubernetes que el archivo yaml que se está utilizando es para crear el volumen persistente.

  • name: pv0001 → Nombre del PersistentVolume que estamos creando.

  • capacity: → Esta especificación definirá la capacidad de PV que estamos intentando crear.

  • storage: 10Gi → Esto le dice a la infraestructura subyacente que estamos tratando de reclamar espacio 10Gi en la ruta definida.

  • ReadWriteOnce → Esto indica los derechos de acceso del volumen que estamos creando.

  • path: "/tmp/data01" → Esta definición le dice a la máquina que estamos tratando de crear un volumen bajo esta ruta en la infraestructura subyacente.

Creando PV

$ kubectl create –f local-01.yaml
persistentvolume "pv0001" created

Comprobación de PV

$ kubectl get pv
NAME        CAPACITY      ACCESSMODES       STATUS       CLAIM      REASON     AGE
pv0001        10Gi            RWO         Available                            14s

Describiendo PV

$ kubectl describe pv pv0001

Crear reclamo de volumen persistente

kind: PersistentVolumeClaim --------------> 1
apiVersion: v1
metadata:
   name: myclaim-1 --------------------> 2
spec:
   accessModes:
      - ReadWriteOnce ------------------------> 3
   resources:
      requests:
         storage: 3Gi ---------------------> 4

En el código anterior, hemos definido:

  • kind: PersistentVolumeClaim → Indica a la infraestructura subyacente que estamos tratando de reclamar una cantidad específica de espacio.

  • name: myclaim-1 → Nombre del reclamo que estamos intentando crear.

  • ReadWriteOnce → Esto especifica el modo del reclamo que estamos tratando de crear.

  • storage: 3Gi → Esto le dirá a kubernetes sobre la cantidad de espacio que estamos tratando de reclamar.

Creando PVC

$ kubectl create –f myclaim-1
persistentvolumeclaim "myclaim-1" created

Obtener detalles sobre el PVC

$ kubectl get pvc
NAME        STATUS   VOLUME   CAPACITY   ACCESSMODES   AGE
myclaim-1   Bound    pv0001     10Gi         RWO       7s

Describe PVC

$ kubectl describe pv pv0001

Uso de PV y PVC con POD

kind: Pod
apiVersion: v1
metadata:
   name: mypod
   labels:
      name: frontendhttp
spec:
   containers:
   - name: myfrontend
      image: nginx
      ports:
      - containerPort: 80
         name: "http-server"
      volumeMounts: ----------------------------> 1
      - mountPath: "/usr/share/tomcat/html"
         name: mypd
   volumes: -----------------------> 2
      - name: mypd
         persistentVolumeClaim: ------------------------->3
         claimName: myclaim-1

En el código anterior, hemos definido:

  • volumeMounts: → Este es el camino en el contenedor en el que se realizará el montaje.

  • Volume: → Esta definición define la definición de volumen que vamos a reclamar.

  • persistentVolumeClaim: → Debajo de esto, definimos el nombre del volumen que vamos a utilizar en el pod definido.