Almacenamiento en kubernetes

El almacenamiento en Kubernetes es un aspecto crucial para la gestión de aplicaciones que requieren persistencia de datos, ya que por defecto, los contenedores en Kubernetes son efímeros y su almacenamiento local se pierde al destruirse o reiniciarse. Para solventar este problema, Kubernetes permite definir volúmenes persistentes que sobreviven al ciclo de vida de los pods, lo que asegura que los datos no se pierdan.

Conceptos Clave de Almacenamiento en Kubernetes

Volúmenes: Un volumen en Kubernetes es una abstracción que permite a los contenedores acceder a un espacio de almacenamiento en disco. A diferencia del almacenamiento temporal de los contenedores, los volúmenes permanecen incluso si el pod es eliminado o reiniciado.
PersistentVolume (PV): Es un recurso en el clúster que representa un espacio de almacenamiento persistente, el cual puede ser proporcionado por un administrador de almacenamiento (como un administrador de la nube, un almacenamiento local, NFS, etc.).
PersistentVolumeClaim (PVC): Es una solicitud por parte del usuario de un volumen persistente específico con ciertas características (como tamaño o tipo de almacenamiento). Un PVC se asocia con un PV disponible que cumple con los criterios de la solicitud.
StorageClass: Define los diferentes tipos de almacenamiento que pueden estar disponibles en el clúster (por ejemplo, SSD rápido, almacenamiento en la nube, almacenamiento en red). Los administradores de clústeres crean StorageClasses para permitir a los usuarios definir el tipo de almacenamiento que necesitan sin preocuparse por los detalles técnicos.

CSI (Container Storage Interface)

La Container Storage Interface (CSI) es un estándar que Kubernetes usa para permitir a los proveedores de almacenamiento crear controladores que gestionen volúmenes. La idea es desacoplar el almacenamiento de las especificidades del clúster y permitir que Kubernetes soporte cualquier sistema de almacenamiento sin necesidad de cambios en el núcleo del clúster.

¿Cómo funciona CSI?

Driver CSI: Es un software que se ejecuta como un contenedor y se encarga de proporcionar almacenamiento persistente. Este driver puede conectarse a cualquier backend de almacenamiento como AWS EBS, Ceph, NFS, etc.
Controladores de almacenamiento CSI: Están desacoplados del núcleo de Kubernetes y funcionan a través de controladores externos (plugins CSI), lo que significa que Kubernetes no necesita modificaciones para soportar nuevos tipos de almacenamiento.
Ventajas del CSI:
- Estándar abierto: Define una API que puede ser implementada por cualquier proveedor de almacenamiento.
- Desacoplamiento: Permite añadir nuevos tipos de almacenamiento sin modificar el código base de Kubernetes.
- Flexibilidad: Soporta múltiples funcionalidades como la creación, eliminación y redimensionamiento de volúmenes, y gestión de snapshots.

Con CSI, Kubernetes obtiene una arquitectura de almacenamiento mucho más flexible y modular, lo que permite a los desarrolladores integrar cualquier tipo de almacenamiento con mayor facilidad.

Caso de Uso

Si estás utilizando un clúster Kubernetes y necesitas integrar un sistema de almacenamiento como Ceph, Google Cloud Storage, o un almacenamiento empresarial, el CSI te permite implementar controladores que gestionen estos volúmenes y sean compatibles con Kubernetes, simplificando la operación y gestión del almacenamiento en tu clúster.

Podes leer mas en la documentacion oficial

Como crear volumenes

Crear un volumen en Kubernetes es un proceso que involucra varios componentes, principalmente un PersistentVolume (PV) y un PersistentVolumeClaim (PVC). Aquí te explico el flujo básico:

Pasos para Crear un Volumen Persistente en Kubernetes

Definir el PersistentVolume (PV): El PV es una pieza de almacenamiento en el clúster que proporciona un volumen persistente. Es administrado por el clúster, y puede estar basado en almacenamiento local, NFS, AWS EBS, entre otros.
Definir el PersistentVolumeClaim (PVC): El PVC es una solicitud para un volumen que se hace desde el pod. Es lo que utiliza un usuario para acceder a un PersistentVolume.
Usar el PVC en un Pod: Finalmente, el pod hace referencia a un PVC, lo que le da acceso al almacenamiento persistente.

Ejemplo YAML para Crear un Volumen

Aquí te muestro un ejemplo básico de cómo se puede definir un PV, un PVC y cómo el pod lo utilizaría.

1. Definir el PersistentVolume (PV)

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-example
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: manual
  hostPath:
    path: "/mnt/data"  # El almacenamiento local en el nodo

capacity: Define el tamaño del volumen, en este caso 1 GiB.
accessModes: Define cómo se puede acceder al volumen:
- ReadWriteOnce: El volumen puede ser montado en modo de lectura-escritura por un solo nodo.
- ReadOnlyMany: El volumen puede ser montado por muchos nodos en modo de solo lectura.
- ReadWriteMany: El volumen puede ser montado por muchos nodos en modo de lectura-escritura.
persistentVolumeReclaimPolicy: Determina qué pasa con el volumen cuando el PVC se elimina (en este caso, se retiene el volumen).
hostPath: Para este ejemplo, estamos usando el almacenamiento local del nodo, montado en /mnt/data.

2. Definir el PersistentVolumeClaim (PVC)

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-example
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
  storageClassName: manual

resources.requests.storage: Esto especifica cuánto almacenamiento necesita el PVC, en este caso 1 GiB.
storageClassName: El nombre del StorageClass que se usará, debe coincidir con el definido en el PV.

3. Usar el PVC en un Pod

apiVersion: v1
kind: Pod
metadata:
  name: pod-using-pvc
spec:
  containers:
  - name: mycontainer
    image: nginx
    volumeMounts:
    - mountPath: "/usr/share/nginx/html"
      name: myvolume
  volumes:
  - name: myvolume
    persistentVolumeClaim:
      claimName: pvc-example

volumeMounts: Monta el volumen en el contenedor. En este caso, está montando el volumen en /usr/share/nginx/html.
volumes.persistentVolumeClaim.claimName: Hace referencia al nombre del PVC (pvc-example), que es donde se encuentra el volumen.

Flujo Completo

El PV es creado y representa un recurso de almacenamiento físico.
El PVC solicita espacio de almacenamiento definido por el PV.
El Pod utiliza el PVC para acceder al almacenamiento en el contenedor.

Una vez aplicas estos YAML usando kubectl, puedes gestionar el almacenamiento persistente en Kubernetes. Ejemplo:

kubectl apply -f pv.yaml
kubectl apply -f pvc.yaml
kubectl apply -f pod.yaml

Este es un flujo básico que puedes expandir según tu backend de almacenamiento (NFS, Ceph, EBS, etc.), o ajustar las configuraciones para necesidades más complejas.

Deben coincidir el PV con el PVC?

No necesariamente deben coincidir el tamaño del PersistentVolume (PV) y el PersistentVolumeClaim (PVC) en todos los casos, pero es una buena práctica que el tamaño solicitado por el PVC sea igual o menor al tamaño disponible en el PV. Aquí te explico por qué:

¿Deben coincidir siempre?

PVC puede ser menor que el PV:
- Permitido: Un PVC puede solicitar menos espacio del que está disponible en un PV, siempre y cuando haya un PV disponible que cumpla o exceda los requisitos del PVC. Por ejemplo, si tienes un PV de 10Gi y un PVC que solicita 5Gi, Kubernetes asignará el PV de 10Gi al PVC de 5Gi.
- Razón: Esto puede suceder cuando se reutilizan volúmenes que tienen más espacio del necesario, pero no se realiza un ajuste preciso en la solicitud de almacenamiento.
PVC no puede ser mayor que el PV:
- No permitido: Un PVC no puede solicitar más espacio del que ofrece un PV. Por ejemplo, si tienes un PV de 1Gi y el PVC solicita 2Gi, Kubernetes no podrá enlazarlos y el PVC quedará en estado Pending hasta que haya un PV adecuado disponible.
- Razón: Kubernetes no asignará volúmenes si el espacio solicitado es mayor que el disponible, ya que esto podría generar errores o fallos de almacenamiento en las aplicaciones.

¿Cuándo deben coincidir?

Expansión de Volúmenes: Si estás redimensionando un volumen para aumentar el tamaño, generalmente debes hacer que el PV y el PVC coincidan después de la expansión para reflejar el nuevo tamaño real en tu configuración YAML. Es especialmente importante mantener los archivos sincronizados cuando trabajas en una infraestructura declarativa para evitar inconsistencias.
Escenarios de almacenamiento optimizado: En escenarios donde desees asignar exactamente la cantidad de espacio que necesitas, es una buena práctica que el tamaño del PVC coincida con el tamaño del PV. Esto asegura que el espacio asignado sea utilizado eficientemente sin asignar más recursos de los necesarios.

Ejemplo de PVC menor que PV

Supongamos que tienes un PV de 10Gi pero tu aplicación solo requiere 5Gi. El PVC podría verse así:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-example
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi  # Solicita menos espacio del que proporciona el PV
  storageClassName: manual

El PV correspondiente aún podría tener 10Gi disponibles:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-example
spec:
  capacity:
    storage: 10Gi  # Espacio total del PV
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: manual
  hostPath:
    path: "/mnt/data"

Casos donde el tamaño del PVC es menor al PV:

Reutilización de volúmenes grandes: Puede que tengas un volumen preexistente grande (PV) que quieras reutilizar para una aplicación que no necesita todo el espacio (PVC). Esto evita desperdiciar almacenamiento y permite flexibilidad.

Resumen de Buenas Prácticas:

PVC ≤ PV: El PVC siempre debe solicitar un tamaño igual o menor al del PV.
Coincidencia ideal: Para asegurar claridad y simplicidad, especialmente en nuevas configuraciones, es recomendable que el tamaño del PV y PVC coincidan, lo que facilita la comprensión y el mantenimiento de la infraestructura.
Redimensionamiento: Cuando aumentes el tamaño del PVC, el PV debe actualizarse para reflejar el cambio y mantener la consistencia en los archivos YAML.

Mantener los YAML del PV y PVC sincronizados y claros hace que la administración de tu clúster sea más fácil, reproducible y menos propensa a errores en el futuro.

Que pasan si luego quiero aumentar el espacio de mi pvc?

En Kubernetes, si tu aplicación necesita más espacio de almacenamiento del que originalmente solicitaste (en este caso, si tu PVC necesita crecer de 1Gi a 2Gi), no pierdes los datos, pero hay algunos pasos importantes para seguir, ya que el proceso no es automático en todas las configuraciones.

Redimensionar un PersistentVolumeClaim

Desde Kubernetes 1.11, se introdujo la capacidad de redimensionar volúmenes persistentes (PVCs), pero esta funcionalidad depende de que tu proveedor de almacenamiento y el StorageClass que estés usando lo soporten. Aquí te explico los pasos:

1. Verifica que tu StorageClass soporte redimensionamiento

Para permitir el redimensionamiento, la StorageClass que estás utilizando debe tener habilitada la expansión de volúmenes. En el StorageClass debe existir el campo allowVolumeExpansion: true.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: example-storageclass
provisioner: kubernetes.io/aws-ebs  # Ejemplo para AWS EBS, puede variar según tu proveedor
allowVolumeExpansion: true

allowVolumeExpansion: Esta opción debe estar configurada en true para permitir la expansión de volúmenes asociados a este StorageClass.

Si esta opción está habilitada, podrás redimensionar volúmenes asociados a este StorageClass sin perder datos.

2. Modificar el PersistentVolumeClaim (PVC)

Para redimensionar el PVC, puedes modificar el tamaño solicitado directamente en el recurso YAML del PVC.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-example
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 2Gi  # Cambia el tamaño aquí de 1Gi a 2Gi
  storageClassName: manual

Aplicar el cambio usando:

kubectl apply -f pvc.yaml

3. Condiciones para la Expansión

Soporte del proveedor de almacenamiento: Algunos proveedores de almacenamiento (como AWS EBS, Google Persistent Disks, etc.) soportan la expansión en caliente, es decir, sin detener el pod o aplicación. Sin embargo, en algunos casos, es necesario que el volumen esté desmontado para permitir la expansión.
Sistema de archivos: Una vez que el volumen ha sido redimensionado, el sistema de archivos dentro del contenedor debe reconocer el nuevo espacio disponible. Algunos sistemas de archivos, como ext4, pueden expandirse automáticamente, pero otros pueden necesitar pasos adicionales para hacerlo.

4. Verifica el estado del PVC

Después de solicitar la expansión, puedes verificar si el PVC se ha redimensionado con el siguiente comando:

kubectl get pvc pvc-example

Deberías ver que el tamaño del volumen ha cambiado de 1Gi a 2Gi.

Consideraciones Importantes

No perderás los datos: Redimensionar un volumen no implica pérdida de datos. Sin embargo, si tu StorageClass no soporta la expansión de volúmenes o si no sigues los pasos adecuados, podrías tener problemas de compatibilidad.
Expandir un volumen mientras está en uso: No todos los volúmenes pueden expandirse mientras están montados en un pod. Esto depende del tipo de almacenamiento que estés utilizando. Por ejemplo, algunos volúmenes de red o en la nube pueden redimensionarse sin problemas en caliente, mientras que otros requerirán detener temporalmente los pods.

Alternativa

Si tu proveedor de almacenamiento o configuración actual no soporta la expansión de volúmenes, otra opción sería crear un nuevo PVC con más espacio y migrar los datos manualmente desde el antiguo volumen. Sin embargo, este proceso puede ser más complejo y podría implicar tiempos de inactividad o riesgo de pérdida de datos si no se realiza cuidadosamente.

Resumen de Pasos

Verifica que tu StorageClass soporte expansión (allowVolumeExpansion: true).
Modifica el PVC para aumentar el tamaño de almacenamiento solicitado.
Verifica el estado del PVC con kubectl get pvc.
Asegúrate de que el sistema de archivos del contenedor reconozca el nuevo espacio.

De esta forma, puedes expandir el almacenamiento de tu aplicación sin perder datos.

Ejercicio

apiVersion: v1
kind: Pod
metadata:
  name: volumenes
spec:
  containers:
  - name: nginx
    image: nginx
    volumeMounts:
    - mountPath: /home
      name: home
    - mountPath: /git
      name: git
      readOnly: true
    - mountPath: /temp
      name: temp
  volumes:
  - name: home
    hostPath:
      path: /home/kubernetes/datos
  - name: git
    gitRepo:
      repository: https://github.com/apasoftTraining/cursoKubernetes.git
  - name: temp
    emptyDir: {}

Tipos de Volúmenes en tu YAML:

hostPath:
- Descripción: Este tipo de volumen monta un directorio del sistema de archivos del nodo (en este caso /home/kubernetes/datos) directamente en el pod.
- Requiere PV/PVC: No, el volumen hostPath no necesita un PersistentVolume ni PersistentVolumeClaim. Kubernetes simplemente usa el directorio que ya existe en el nodo donde se ejecuta el pod.
- Riesgo: El uso de hostPath puede generar problemas si los pods se reprograman en otros nodos, ya que el directorio /home/kubernetes/datos podría no existir en todos los nodos.
gitRepo:
- Descripción: Este tipo de volumen clona automáticamente un repositorio Git en el directorio especificado dentro del pod (en este caso /git).
- Requiere PV/PVC: No, el volumen gitRepo no necesita un PersistentVolume ni PersistentVolumeClaim. Kubernetes clona el contenido del repositorio al directorio especificado en el pod cuando este es creado.
- Consideración: Este volumen se monta en modo solo lectura (readOnly: true), y es una opción útil si quieres que el pod tenga acceso a una instantánea del repositorio en el momento de su creación.
emptyDir:
- Descripción: Este volumen se crea vacío cuando se inicia el pod y se elimina cuando el pod es destruido. Es útil para almacenar datos temporales que no necesitan persistencia más allá del ciclo de vida del pod.
- Requiere PV/PVC: No, el volumen emptyDir no necesita un PersistentVolume ni PersistentVolumeClaim. Es un directorio temporal que vive y muere con el pod.

Resumen:

HostPath: Monta un directorio del sistema de archivos local del nodo donde el pod se está ejecutando.
GitRepo: Clona un repositorio Git en el contenedor, no necesita almacenamiento persistente.
EmptyDir: Crea un directorio temporal que se elimina cuando el pod es destruido.

¿Es necesario crear PV o PVC?

En este caso específico, no necesitas crear ni un PV ni un PVC porque estás utilizando volúmenes que no requieren persistencia fuera del ciclo de vida del pod o que dependen del nodo (como hostPath o emptyDir).
No se creará automáticamente ningún PV o PVC, ya que no estás solicitando un volumen persistente en el sentido de un volumen gestionado por Kubernetes (como lo sería un volumen en la nube o un sistema de almacenamiento compartido).

Consideraciones Finales:

Si necesitaras persistencia real (es decir, que los datos sobrevivan aunque el pod se elimine o se reprograma en otro nodo), entonces tendrías que configurar un PersistentVolume (PV) y un PersistentVolumeClaim (PVC).
Para tu caso actual, tu YAML funcionará correctamente sin necesidad de configurar PVs o PVCs adicionales, ya que los volúmenes declarados son manejados por Kubernetes de manera local o temporal.

Ejecutamos el yaml

Hacemos kubectl describe pods volumenes alli podremos ver los volumenes creados sus modos (rw,ro,r).

Podemos tambien la creacion de los pods y el volumen con kubectl get pods para asegurarnos de que el pod volumenes ya se haya creado.

Tambien podemos entrar al pod y ver la ruta que tenemos enlazadas con la maquina host:

kubectl exec -it volumenes sh 
cd /git

Deberiamos ver la carpeta cursoKubernetes

NFS

Para usar NFS (Network File System) como almacenamiento compartido en Kubernetes, debes seguir una serie de pasos que incluyen configurar un servidor NFS, crear un PersistentVolume (PV) que use el almacenamiento NFS, y luego definir un PersistentVolumeClaim (PVC) para que los pods puedan utilizarlo.

El servidor NFS nos permite compartir un almacenamiento entre distintos nodos. Es el recomandable para porduccion ya que el metodo hostname solo funciona en un solo nodo.

Pasos Generales para Usar NFS en Kubernetes

Configurar el servidor NFS (si no lo tienes ya configurado).
Crear un PersistentVolume (PV) que apunte al servidor NFS.
Crear un PersistentVolumeClaim (PVC) que solicite almacenamiento del PV.
Montar el PVC en tus pods para que usen el almacenamiento NFS.

Paso 1: Configurar el Servidor NFS

Si ya tienes un servidor NFS disponible, puedes saltarte este paso. De lo contrario, necesitarás configurar un servidor NFS. Aquí tienes los pasos básicos:

Instalar NFS Server (ejemplo en un servidor Linux):

sudo apt-get update
sudo apt-get install nfs-kernel-server

Crear un directorio que deseas compartir:

sudo mkdir -p /srv/nfs/kubedata
sudo chown nobody:nogroup /srv/nfs/kubedata
sudo chmod 777 /srv/nfs/kubedata

Configurar el acceso al directorio en el archivo de exportación NFS:

Edita el archivo /etc/exports y añade una línea como la siguiente:
```
/srv/nfs/kubedata    *(rw,sync,no_subtree_check,no_root_squash)
```
Esto permite que cualquier cliente acceda al directorio /srv/nfs/kubedata. Puedes reemplazar * con la IP específica de tus nodos de Kubernetes para restringir el acceso.

Aplicar los cambios:

sudo exportfs -a
sudo systemctl restart nfs-kernel-server

Verificar el servidor NFS:

Puedes comprobar que el servidor NFS esté funcionando correctamente:
```
sudo showmount -e localhost
```
Esto debe mostrar el directorio exportado /srv/nfs/kubedata.

Paso 2: Crear el PersistentVolume (PV)

Ahora que el servidor NFS está configurado, crea un PersistentVolume en Kubernetes que apunte a ese directorio NFS.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-pv
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteMany
  nfs:
    path: /srv/nfs/kubedata  # La ruta que configuraste en el servidor NFS
    server: <IP-del-servidor-NFS>  # IP o nombre del servidor NFS
  persistentVolumeReclaimPolicy: Retain

Detalles del PV:

storage: El tamaño del almacenamiento que proporciona el volumen.
accessModes: ReadWriteMany permite que múltiples nodos monten el volumen en modo lectura/escritura.
nfs.server: La IP o nombre del servidor NFS.
nfs.path: La ruta exportada desde el servidor NFS que usará Kubernetes.

Paso 3: Crear el PersistentVolumeClaim (PVC)

Una vez creado el PV, debes crear un PersistentVolumeClaim (PVC) que solicite almacenamiento del PV.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nfs-pvc
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 5Gi  # La cantidad de almacenamiento solicitada

accessModes: Debe coincidir con el modo de acceso definido en el PV (ReadWriteMany).
storage: Debe ser igual o menor al almacenamiento disponible en el PV.

Paso 4: Usar el PVC en un Pod

Ahora, puedes montar el PVC en tus pods. Aquí te muestro un ejemplo de cómo hacerlo en un pod simple con un contenedor nginx:

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
spec:
  containers:
  - name: nginx
    image: nginx
    volumeMounts:
    - mountPath: /usr/share/nginx/html  # Donde montará el volumen dentro del contenedor
      name: nfs-storage
  volumes:
  - name: nfs-storage
    persistentVolumeClaim:
      claimName: nfs-pvc  # Hace referencia al PVC creado anteriormente

Paso 5: Aplicar las configuraciones

Crea el PersistentVolume:
```
kubectl apply -f nfs-pv.yaml
```
Crea el PersistentVolumeClaim:
```
kubectl apply -f nfs-pvc.yaml
```
Aun no crearemos el PODS, antes tenemos que configurar los nodos cliente para que se conecten mediante NFS al servidor que
contiene el volumen.

Paso 6: Verificar el Estado

Puedes verificar que el PV y PVC estén correctamente vinculados con los siguientes comandos:

Verificar el PV:
```
kubectl get pv
```
Debes ver el estado del PV como Bound, lo que indica que el PVC ha sido asignado correctamente.
Verificar el PVC:
```
kubectl get pvc
```
El PVC también debe estar en estado Bound.

El pod debe estar en estado Running.

Consideraciones:

Acceso NFS a múltiples nodos:
- NFS permite el acceso de múltiples nodos, lo que lo hace adecuado para usar con ReadWriteMany en Kubernetes. Este modo de acceso permite que varios pods, en diferentes nodos, lean y escriban en el mismo volumen.
Performance:
- NFS puede no ser la opción más rápida para almacenamiento compartido, especialmente en entornos de alta demanda de rendimiento. Sin embargo, es fácil de configurar y permite compartir almacenamiento entre nodos.
Seguridad:
- Considera restringir el acceso a NFS solo a los nodos de tu clúster, para evitar accesos no autorizados.

Resumen:

NFS permite montar un sistema de archivos compartido en múltiples nodos de Kubernetes.
Configuras un servidor NFS, creas un PV que apunte al servidor, y luego usas un PVC para que los pods accedan a ese almacenamiento.
Puedes montar el PVC en los pods para que usen ese almacenamiento compartido, con acceso múltiple permitido gracias a ReadWriteMany.

Este enfoque es muy útil para compartir almacenamiento entre diferentes pods y nodos dentro de un clúster de Kubernetes.

NFS en los workers (slaves)

Para que el volumen compartido funcione tenemos que hacer un paso adicional en los workers, osea en los nodos esclavos.

1. Verificar si el cliente NFS está instalado

El error sugiere que el sistema puede no tener el cliente NFS instalado. Para sistemas basados en Debian/Ubuntu, puedes instalar el cliente NFS con el siguiente comando:

sudo apt-get install nfs-common

Para sistemas basados en Red Hat/CentOS:

sudo yum install nfs-utils

2. Revisar las opciones de montaje

Montamos manualmente el NFS desde el nodo afectado con el siguiente comando, asegurándote de que la ruta de exportación de NFS sea accesible:

sudo mount -t nfs 192.168.0.13:/srv/nfs/kuberdata /srv/nfs/kuberdata

Creado el pod

Volviendo al maestro

Crea el Pod:

kubectl apply -f nginx-pod.yaml

Probando el vinculo

Si vamos al nodo esclavo y dentro de srv/nfs/kuberdata hacemos un touch hola.txt y luego vamos al servidor NFS ( en mi caso lo hice en el mismo control-plane (master)) si vemos la ruta srv/nfs/kuberdata veremos que esta hola.txt.