Usar volúmenes persistentes locales en K8S
Existe un concepto de volúmenes en Docker, pero en Docker, un volumen de almacenamiento es solo un disco o directorio en otro contenedor, y no hay gestión de su ciclo de vida. Por lo tanto, el volumen de almacenamiento durará más que cualquier contenedor que se ejecute en el Pod y conservará los datos durante los reinicios del contenedor. Por supuesto, cuando el Pod deje de existir, el volumen de almacenamiento también dejará de existir. Kubernetes admite múltiples tipos de volúmenes y un Pod puede usar cualquier tipo y cantidad de volúmenes al mismo tiempo. Los volúmenes de almacenamiento se pueden utilizar en Pods especificando los siguientes campos:
Un PV es un almacenamiento configurado por el administrador del sistema. Es parte del clúster y es un recurso, por lo que tiene un ciclo de vida diferente al del mismo. la vaina.
Un PVC es una solicitud de almacenamiento del usuario. Es similar a Pod y PVC. El primero consume los recursos de CPU y memoria del nodo, mientras que el segundo consume recursos PV y puede utilizar tamaños de capacidad y patrones de acceso específicos.
Los PV y PVC siguen la siguiente gestión del ciclo de vida
Los PV se configuran de dos maneras: estático o dinámico
Para habilitar la configuración de almacenamiento dinámico según los niveles de almacenamiento, Gestión de clústeres Los administradores deben habilitar el controlador de acceso DefaultStorageClass en el servidor API. Esto se puede lograr, por ejemplo, asegurándose de que DefaultStorageClass esté en el indicador --admission-control del componente del servidor API y utilizando una lista ordenada de valores separados por comas. Para obtener más información sobre los indicadores de la línea de comandos del servidor API, consulte la documentación de kube-apiserver.
Una vez que un usuario crea o ha creado un PersistentVolumeClaim con una cantidad específica de almacenamiento y un patrón de acceso específico, el controlador de Kubernetes monitorea el nuevo PVC, busca PV coincidentes y los une. En resumen, los usuarios siempre obtendrán el almacenamiento que soliciten, pero la capacidad puede ser mayor que la solicitada. Una vez que un PV está vinculado a un PVC, el enlace PersistentVolumeClaim es exclusivo independientemente de cómo esté vinculado. Los enlaces de PVC y PV se asignan uno a uno.
Si no hay ningún PV coincidente, el PVC permanecerá sin consolidar indefinidamente. Cuando esté disponible un PV coincidente, el PVC quedará vinculado. Por ejemplo, un clúster configurado con muchos PV de 50 Gi no podrá coincidir con un PVC que solicite 100 Gi. Cuando se agrega un PV de 100 Gi al clúster, se vincula a ese PVC.
Los pods utilizan PVC como volúmenes. El clúster comprueba el PVC para el volumen enlazado y monta el volumen para el clúster. Para volúmenes que admiten múltiples modos de acceso, los usuarios deben especificar el modo deseado (lectura-escritura, solo lectura) cuando usan el reclamo como volumen en un contenedor.
Cuando un usuario utiliza un PVC y lo vincula, el PV vinculado pertenece al usuario siempre que lo necesite.
K8S admite múltiples tipos de volúmenes, divididos principalmente en DistributedFileSystem, ConfigMap y LocalFileSystem, de los cuales LocalFileSystem admite: hostPath y local (a partir de la versión Beta 1.11, la última versión de K8S al momento de escribir este artículo). artículo es 1.13).
En el desarrollo real de nuestro proyecto actual, a menudo usamos dos modos de montaje de volumen:
Pero para usar discos locales para almacenar datos, hostPath generalmente no es adecuado para nosotros, aunque Los pods pueden usar almacenamiento local, archivos del sistema de archivos de Node o directorios montados en el contenedor, pero en este escenario de aplicación, hostPath no es adecuado para producción.
Por supuesto, hostPath tiene otras deficiencias. Debido a estas dos deficiencias principales, en escenarios de aplicaciones que realmente requieren almacenamiento de datos persistentes, debemos considerar el volumen de almacenamiento local.
El PV local se introdujo a partir de Kuberntes 1.10, principalmente para resolver las deficiencias de hostPath. Al combinar un controlador fotovoltaico con un programador, los fotovoltaicos locales se procesan con una lógica específica, lo que permite programar pods en el mismo nodo varias veces.
Primero, preparemos el entorno de K8S y verifiquemos los nodos en K8S.
Ahora inicie sesión en el nodo 10.25.68.239 y cree manualmente un directorio donde vincularemos el PV local creado más adelante.
Crear una clase de almacenamiento local
Ver la clase de almacenamiento creada
Crear un PV:
Ver el estado del PV
Crear PVC
El PVC estará en estado pendiente hasta que creemos un Pod para usarlo.
Cree una implementación para utilizar este PVC.
El PVC ahora está vinculado al PV correspondiente.
Al observar el nodo del plan de pod, puede ver que este pod está planificado para el nodo donde se encuentra el PV:
Iniciemos sesión en 10.25.68.239 nuevamente y generar el archivo index.html
Ver los servicios en el archivo index.html
Los volúmenes persistentes locales básicamente tienen la capacidad y la conveniencia de vincular el directorio del sistema de archivos local a hostPath, y también automáticamente tiene la capacidad de programar nodos designados y administrar la capacidad de volúmenes persistentes.
El único problema es que todavía necesitamos ir manualmente al nodo correspondiente para crear el directorio correspondiente y eliminarlo, lo que requiere un diseño y una gestión unificados junto con nuestro sistema de aplicación.
En general, los volúmenes persistentes locales son una buena opción para implementaciones de aplicaciones con estado porque proporcionan un alto rendimiento que el almacenamiento distribuido no puede ofrecer, al mismo tiempo que permiten cierta flexibilidad de programación.