Kubernetes CSI: conceptos básicos de los volúmenes CSI y cómo crear un controlador CSI
Compartir esta página
Yifat Perry
¿Qué es Kubernetes CSI?
Kubernetes CSI es una implementación específica de Kubernetes de la Interfaz de Almacenamiento de Contenedores (CSI). La especificación CSI proporciona un estándar que permite la conectividad entre sistemas de almacenamiento y plataformas de orquestación de contenedores (CO). Es la base de Kubernetes storage management.
El estándar CSI determina cómo se exponen los bloques arbitrarios y los sistemas de almacenamiento de archivos a las cargas de trabajo en sistemas de contenedorización como Kubernetes. Los proveedores de almacenamiento de terceros pueden usar CSI para crear plugins y desplegarlos para permitir que Kubernetes funcione con nuevos sistemas de almacenamiento, sin tener que editar el código central de Kubernetes.
En este artículo:
- La necesidad de CSI
- ¿Cómo usar un volumen CSI?
- Creando tu propio controlador CSI para Kubernetes
- Almacenamiento de Kubernetes con NetApp Cloud Volumes ONTAP
La necesidad de CSI
Antes de la Container Storage Interface, Kubernetes solo admitía el uso de plugins de volumen k8s in-tree, que tenían que escribirse y desplegarse usando los binarios principales de Kubernetes. Esto significaba que los proveedores de almacenamiento tenían que registrar en el código principal de sus plugins k8s para habilitar el soporte para nuevos sistemas de almacenamiento.
Flex-volume, una solución basada en plugins, intentó resolver este problema exponiendo la API basada en ejecutables a plugins de terceros. Aunque esta solución funcionaba según un principio similar al de CSI en términos de desvinculación con binarios k8s, había una serie de problemas con este enfoque. Primero, requería acceso a raíz al sistema de archivos maestro y del host para permitir el despliegue de archivos de controladores. Segundo, venía con una carga significativa de dependencias del sistema operativo y requisitos previos que se suponía que estaban disponibles en el host.
CSI aborda estos problemas utilizando la contenedorización y aprovechando las primitivas de almacenamiento de k8s. CSI se ha convertido en la solución omnipresente para permitir el uso de plugins de almacenamiento fuera del árbol. Permite a los proveedores de almacenamiento desplegar plugins a través de primitivas estándar de k8s como clases de almacenamiento, PersistentVolumes (PVs) y PersistentVolumeClaims (PVCs).
El objetivo principal de CSI es estandarizar el mecanismo para exponer todos los tipos de sistemas de almacenamiento en todos los orquestadores de contenedores.
Contenido relacionado: lee nuestra guía sobre Kubernetes Persistent Volumes
¿Cómo usar un volumen CSI?
Un volumen CSI puede utilizarse para aprovisionar recursos PersistentVolume, que pueden ser consumidos por cargas de trabajo de Kubernetes. Puedes aprovisionar PersistentVolumes de forma dinámica (cuando son solicitados por una carga de trabajo) o manualmente.
Aprovisionamiento dinámico
Puedes crear un StorageClass que hace referencia a un plugin de almacenamiento CSI. Esto permite que las cargas de trabajo de Kubernetes creen dinámicamente PersistentVolumes. Los datos guardados en esos PersistentVolumes se persisten en el equipo de almacenamiento definido en el plugin CSI.
Por ejemplo, el siguiente StorageClass permite el aprovisionamiento de volúmenes de almacenamiento de tipo "fast-storage", usando un plugin CSI llamado "csi-driver.example.com". (este y los otros ejemplos abajo se compartieron en la entrada del blog oficial de Kubernetes CSI blog post )
Cuando una entidad de Kubernetes crea un objeto PersistentVolumeClaim que solicita este StorageClass, se aprovisiona dinámicamente un PersistentVolume que pertenece al StorageClass. La imagen de abajo contiene un ejemplo de un PVC que hace referencia al StorageClass fast-storage.
Observa que en la definición de StorageClass anterior hay tres parámetros: type y dos secretos llamados mysecret y mynamespace. Cuando se declara el PVC, esto es lo que pasa detrás de escena:
- El StorageClass realiza una llamada CreateVolume en el plugin CSI (csi-driver.example.com), pasando los parámetros, incluidos los secretos, que permiten el acceso al dispositivo de almacenamiento.
- Kubernetes crea automáticamente un objeto PersistentVolume que representa un volumen de almacenamiento que se almacena físicamente en el dispositivo del complemento CSI.
- Kubernetes vincula el objeto PersistentVolume (PV) al PersistentVolumeClaim (PVC) correspondiente.
- A partir de este momento, los pods o contenedores que hicieron la solicitud pueden usar el volumen de almacenamiento.
Lee nuestra entrada de blog: aprovisionamiento dinámico de volúmenes persistentes de Kubernetes con NetApp Trident y Cloud Volumes ONTAP
Aprovisionamiento manual
Puedes aprovisionar manualmente un volumen en Kubernetes y ponerlo a disposición de las cargas de trabajo sin usar el mecanismo de PVC. La imagen de abajo muestra un ejemplo de un objeto PV que permite a las cargas de trabajo usar un volumen de almacenamiento llamado “existingVolumeName”. Como arriba, el volumen CSI hace referencia al complemento de almacenamiento csi-driver.example.com.
Adjuntar y montar volúmenes
La imagen de abajo muestra un ejemplo de cómo una plantilla de pod de Kubernetes puede hacer referencia a un PVC para acceder a un volumen CSI.
Cuando aparece un PersistenVolumeClaim en la plantilla del pod, cada vez que se programa el pod, Kubernetes desencadena varias operaciones en el CSI plugin, incluyendo ControllerPublishVolume, NodeStageVolume y NodePublishVolume. Esto crea un volumen de almacenamiento, lo monta y lo deja disponible para que lo usen los contenedores que se ejecutan en el pod.
Creando tu propio controlador CSI para Kubernetes
Componentes del controlador CSI
Los controladores CSI en Kubernetes normalmente se implementan con componentes de controlador y por nodo.
Componente controlador
El complemento del controlador se despliega como un Deployment o un StatefulSet y puede montarse en cualquier nodo dentro del clúster. Incluye un controlador CSI que implementa un servicio de controlador CSI, así como un contenedor sidecar (o varios contenedores). Un contenedor sidecar de controlador normalmente interactúa con objetos de Kubernetes y también hace llamadas al servicio de controlador CSI.
El controlador no requiere acceso directo a un host; puede llevar a cabo todas las operaciones a través de servicios externos del plano de control y la API de Kubernetes. Es posible desplegar múltiples copias de un componente controlador para alta disponibilidad (HA), pero deberías implementar la elección de líder para asegurarte de que solo un controlador esté activo en un momento dado.
Entre los sidecars controladores se encuentran un external-provisioner, un external-attacher, un external-snapshotter y un external-resizer. La inclusión de ciertos sidecars en una implementación puede ser opcional, dependiendo de las especificaciones detalladas en la página del sidecar.
El controlador se comunica con los contenedores sidecar encargados de gestionar los eventos de Kubernetes. Luego, el controlador envía las llamadas relevantes al controlador CSI. Un socket de dominio UNIX se comparte mediante un volumen emptyDir, permitiendo las llamadas entre los sidecars y el controlador.
Los sidecars controladores utilizan reglas de control de acceso basado en roles (RBAC) para gobernar su interacción con los objetos de Kubernetes. Los repositorios de sidecars proporcionan ejemplos de configuraciones RBAC que puedes incorporar en tus políticas RBAC.
Componente por nodo
El plugin de nodo debe desplegarse en todos los nodos de un clúster, a través de un DaemonSet. Incluye el controlador CSI que implementa el servicio CSI Node y el contenedor sidecar que funciona como registrador del controlador de nodo.
El componente de nodo se comunica con el kubelet, que se ejecuta en todos los nodos y gestiona las llamadas al servicio de nodo CSI. Las llamadas pueden montar o desmontar volúmenes de almacenamiento de un sistema de almacenamiento y ponerlos a disposición del pod para que los consuma. El kubelet utiliza un socket de dominio UNIX, que se comparte a través de un volumen HostPath en el host, para hacer llamadas al controlador CSI. Un socket de dominio UNIX adicional es utilizado por el node-driver-registrar para registrar el controlador en el kubelet.
El complemento de nodo requiere acceso directo a un host para montar los volúmenes del driver. Para que los montajes del sistema de archivos y los dispositivos de bloque estén disponibles para el kubelet, el driver CSI necesita usar un punto de montaje bidireccional que permita al kubelet ver los montajes creados por el contenedor del driver.
Despliegue
Kubernetes no determina el empaquetado de un controlador de volumen CSI, pero sí ofrece recomendaciones para simplificar la implementación de controladores CSI en contenedores en Kubernetes.
Se recomienda a los proveedores de almacenamiento que sigan los siguientes pasos al desplegar un controlador de volumen CSI en contenedor:
- Crea un contenedor para implementar el comportamiento del plugin de volumen y exponer una interfaz gRPC a través de un socket de dominio UNIX. El contenedor debe llevar la etiqueta "CSI volume driver" y configurarse según las especificaciones de CSI (con servicios de controlador, nodo e identidad).
- Agrupa el contenedor del controlador de volumen con contenedores adicionales proporcionados por el equipo de Kubernetes, como external-attacher, external-provisioner, cluster-driver-registrar, node-driver-registrar, external-resizer, external-snapshotter y livenessprobe. Estos contenedores facilitan la interacción del contenedor del controlador con Kubernetes.
- Indica a los administradores de clúster que desplieguen el DaemonSet y el StatefulSet relevantes y añadan soporte para el sistema de almacenamiento del proveedor en el clúster de Kubernetes.
Otra opción para un despliegue potencialmente más simple es tener todos los componentes en un solo DaemonSet, incluyendo el external-provisioner y el external-attacher. Sin embargo, esta estrategia consume más recursos y requiere el uso de un protocolo de elección de líder (como https://git.k8s.io/contrib/election) para los componentes external-attacher y external-provisioner.
Habilitar pods con privilegios
El clúster de Kubernetes debe habilitar los pods con privilegios para permitir el uso de los controladores CSI. Por ejemplo, necesitas establecer el flag --allow-privileged en true para el kubelet y el API server; en ciertos entornos, como kubeadm, GCE y GKE, este es el valor predeterminado.
El servidor API debe iniciarse con los siguientes indicadores de privilegios:
$ ./kube-apiserver ... --allow-privileged=true ... $ ./kubelet ... --allow-privileged=true ...
Habilitar la propagación del montaje
La Container Storage Interface requiere una función de propagación de montaje que permite que los volúmenes montados se compartan entre contenedores dentro del mismo nodo o pod. El demonio Docker para un clúster necesita permitir la compartición de montajes para habilitar la propagación de montaje.
Kubernetes CSI con NetApp Cloud Volumes ONTAP
NetApp Cloud Volumes ONTAP, la solución líder de gestión de almacenamiento de clase empresarial, ofrece servicios de gestión de almacenamiento seguros y probados en AWS, Azure y Google Cloud. La capacidad de Cloud Volumes ONTAP puede escalar hasta los petabytes y admite varios casos de uso, como servicios de archivos, bases de datos, DevOps o cualquier otra carga de trabajo empresarial, con un sólido conjunto de funcionalidades que incluyen alta disponibilidad, protección de datos, eficiencias de almacenamiento, integración con Kubernetes y más.
En concreto, Cloud Volumes ONTAP es compatible con Kubernetes Persistent Volume provisioning and management requisitos de las cargas de trabajo en contenedores.
Conoce más sobre Kubernetes NFS Provisioning File Services with Cloud Volumes ONTAP and Trident.
Conoce más sobre cómo Cloud Volumes ONTAP ayuda a afrontar los retos de las aplicaciones en contenedores en estos Kubernetes Workloads with Cloud Volumes ONTAP Case Studies.
