Hay varias formas de configurar el almacenamiento de datos para aplicaciones que se ejecutan en un clúster de Kubernetes. Algunos de ellos ya están desactualizados, otros aparecieron recientemente. En este artículo, veremos el concepto de tres opciones para conectar sistemas de almacenamiento, incluida la más reciente: la conexión a través de la interfaz de almacenamiento de contenedores.
Método 1: especificar PV en el manifiesto del pod
Un manifiesto típico que describe un pod en un clúster de Kubernetes:
Las partes del manifiesto que describen qué volumen está conectado y dónde están resaltadas en color.
En la sección montajes de volumen indique los puntos de montaje (mountPath): en qué directorio dentro del contenedor se montará el volumen permanente, así como el nombre del volumen.
En la sección x enumera todos los volúmenes que se utilizan en el pod. Especifique el nombre de cada volumen, así como el tipo (en nuestro caso: awsElasticBlockStore) y los parámetros de conexión. Los parámetros que se enumeran en el manifiesto dependen del tipo de volumen.
El mismo volumen se puede montar simultáneamente en varios contenedores de cápsulas. De esta manera, diferentes procesos de solicitud pueden acceder a los mismos datos.
Este método de conexión se inventó al principio, cuando Kubernetes estaba apenas en su infancia, y hoy el método está desactualizado.
Hay varios problemas al usarlo:
- todos los volúmenes deben crearse manualmente; Kubernetes no puede crear nada por nosotros;
- los parámetros de acceso para cada volumen son únicos y deben especificarse en los manifiestos de todos los pods que utilizan el volumen;
- Para cambiar el sistema de almacenamiento (por ejemplo, pasar de AWS a Google Cloud), debe cambiar la configuración y el tipo de volúmenes montados en todos los manifiestos.
Todo esto es muy inconveniente, por lo que en realidad este método se utiliza para conectar solo algunos tipos especiales de volúmenes: configMap, secret, vacíoDir, hostPath:
-
configMap y secret son volúmenes de servicio que le permiten crear un volumen con archivos de manifiestos de Kubernetes en el contenedor.
-
vacíoDir es un volumen temporal, creado solo durante la vida útil del pod. Conveniente de usar para probar o almacenar datos temporales. Cuando se elimina un pod, el volumen vacíoDir también se elimina y se pierden todos los datos.
-
hostPath: le permite montar cualquier directorio en el disco local del servidor en el que se ejecuta la aplicación dentro del contenedor con la aplicación, incluido /etc/kubernetes. Esta es una característica insegura, por lo que las políticas de seguridad normalmente prohíben el uso de volúmenes de este tipo. De lo contrario, la aplicación de un atacante podrá montar el directorio de HTC Kubernetes dentro de su contenedor y robar todos los certificados del clúster. Por lo general, los volúmenes hostPath solo pueden ser utilizados por aplicaciones del sistema que se ejecutan en el espacio de nombres del sistema kube.
se dan en la documentación.
Método 2. Conexión a hogares SC/PVC/PV
Un método de conexión alternativo es el concepto de clase de almacenamiento, PersistentVolumeClaim, PersistentVolume.
Clase de almacenamiento almacena los parámetros de conexión al sistema de almacenamiento de datos.
PersistentVolumeClaimPersistentVolumeClaim describe los requisitos de lo que necesita la aplicación.
PersistentVolumePersistentVolume almacena los parámetros de acceso y el estado del volumen.
La esencia de la idea: en el manifiesto del pod indican un volumen de tipo PersistentVolumeClaim e indican el nombre de esta entidad en el parámetro ClaimName.
El manifiesto PersistentVolumeClaim describe los requisitos para el volumen de datos que requiere la aplicación. Incluido:
- tamaño del disco;
- método de acceso: ReadWriteOnce o ReadWriteMany;
- enlace a la clase de almacenamiento: en qué sistema de almacenamiento de datos queremos crear el volumen.
El manifiesto de la clase de almacenamiento almacena el tipo y los parámetros de la conexión al sistema de almacenamiento. El cubelet los necesita para montar el volumen en su nodo.
Los manifiestos de PersistentVolume indican la clase de almacenamiento y los parámetros de acceso para un volumen específico (ID de volumen, ruta, etc.).
Al crear un PVC, Kubernetes analiza qué tamaño de volumen y qué clase de almacenamiento se requiere, y selecciona un PersistentVolume libre.
Si dichos PV no están disponibles, Kubernetes puede iniciar un programa especial: Aprovisionador (su nombre se indica en la clase Almacenamiento). Este programa se conecta al sistema de almacenamiento, crea un volumen del tamaño requerido, recibe un identificador y crea un manifiesto PersistentVolume en el clúster de Kubernetes, que está asociado con PersistentVolumeClaim.
Toda esta multitud de abstracciones le permite eliminar información sobre con qué sistema de almacenamiento está trabajando la aplicación desde el nivel de manifiesto de la aplicación hasta el nivel de administración.
Todos los parámetros para conectarse al sistema de almacenamiento de datos se encuentran en la clase Almacenamiento, de la cual son responsables los administradores del clúster. Todo lo que necesita hacer al pasar de AWS a Google Cloud es cambiar el nombre de la clase de almacenamiento a PVC en los manifiestos de la aplicación. El volumen de persistencia para el almacenamiento de datos se creará en el clúster automáticamente utilizando el programa Provisioner.
Método 3: interfaz de almacenamiento de contenedores
Todo el código que interactúa con varios sistemas de almacenamiento es parte del núcleo de Kubernetes. El lanzamiento de correcciones de errores o nuevas funciones está vinculado a nuevas versiones; el código debe cambiarse para todas las versiones compatibles de Kubernetes. Todo esto es difícil de mantener y agregar nuevas funcionalidades.
Para resolver el problema, los desarrolladores de Cloud Foundry, Kubernetes, Mesos y Docker crearon la Interfaz de almacenamiento de contenedores (CSI), una interfaz unificada simple que describe la interacción del sistema de administración de contenedores y un controlador especial (controlador CSI) que funciona con un específico. sistema de almacenamiento. Todo el código para la interacción con los sistemas de almacenamiento se trasladó del núcleo de Kubernetes a un sistema separado.
.
Normalmente, el controlador CSI consta de dos componentes: complemento de nodo y complemento de controlador.
Node Plugin se ejecuta en cada nodo y es responsable de montar volúmenes y realizar operaciones en ellos. El complemento Controlador interactúa con el sistema de almacenamiento: crea o elimina volúmenes, asigna derechos de acceso, etc.
Por ahora, los controladores antiguos permanecen en el kernel de Kubernetes, pero ya no se recomienda su uso y se recomienda a todos que instalen el controlador CSI específicamente para el sistema con el que trabajarán.
La innovación puede asustar a quienes ya están acostumbrados a configurar el almacenamiento de datos a través de la clase Almacenamiento, pero en realidad no ha sucedido nada terrible. Para los programadores, nada cambia realmente: han trabajado sólo con el nombre de clase Almacenamiento y seguirán haciéndolo. Para los administradores, se agregó la instalación del gráfico de timón y se cambió la estructura de la configuración. Si antes las configuraciones se ingresaban directamente en la clase Almacenamiento, ahora se deben configurar primero en el gráfico de timón y luego en la clase Almacenamiento. Si lo miras bien, no pasó nada malo.
Tomemos un ejemplo para ver los beneficios que puede obtener al cambiar a conectar sistemas de almacenamiento Ceph mediante el controlador CSI.
Cuando se trabaja con Ceph, el complemento CSI ofrece más opciones para trabajar con sistemas de almacenamiento que los controladores integrados.
- Creación de disco dinámico. Normalmente, los discos RBD se utilizan sólo en modo RWO, pero CSI para Ceph permite su uso en modo RWX. Varios pods en diferentes nodos pueden montar el mismo disco RDB en sus nodos y trabajar con ellos en paralelo. Para ser justos, no todo es tan brillante: este disco solo se puede conectar como un dispositivo de bloque, lo que significa que tendrá que adaptar la aplicación para que funcione con él en modo de acceso múltiple.
- Creando instantáneas. En un clúster de Kubernetes, puede crear un manifiesto con el requisito de crear una instantánea. El complemento CSI lo verá y tomará una instantánea del disco. En base a esto, puede realizar una copia de seguridad o una copia de PersistentVolume.
- Aumento del tamaño del disco sobre almacenamiento y PersistentVolume en un clúster de Kubernetes.
- Cuotas. Los controladores CephFS integrados en Kubernetes no admiten cuotas, pero los complementos CSI nuevos con el último Ceph Nautilus pueden habilitar cuotas en las particiones CephFS.
- Métricas. El complemento CSI puede proporcionar a Prometheus una variedad de métricas sobre qué volúmenes están conectados, qué comunicaciones se están realizando, etc.
- Consciente de la topología. Le permite especificar en los manifiestos cómo se distribuye geográficamente el clúster y evitar conectar un sistema de almacenamiento ubicado en Ámsterdam a pods que se ejecutan en Londres.
Cómo conectar Ceph a un clúster de Kubernetes a través de CSI, consulte . También puedes suscribirte a , que se lanzará el 15 de octubre.
Autor del artículo: Sergey Bondarev, arquitecto en ejercicio en Southbridge, administrador certificado de Kubernetes, uno de los desarrolladores de kubespray.
Un pequeño Post Scriptum no para publicidad, sino para beneficio...
PS Sergey Bondarev imparte dos cursos intensivos: actualizado 28-30 de septiembre y avanzados 14 al 16 de octubre.
Fuente: habr.com