Algunas aplicaciones también necesitan almacenar datos, pero son bastante tolerantes a que los datos no se conserven después del reinicio.
Por ejemplo, los servicios de caché están limitados por la memoria RAM, pero también pueden mover datos que se utilizan con poca frecuencia a un almacenamiento que funciona más lentamente que la memoria RAM, con un impacto mínimo en el rendimiento general. Otras aplicaciones necesitan saber que puede haber algunos archivos de entrada de solo lectura, como configuraciones o claves secretas.
En Kubernetes ya existen varios tipos , pero su funcionalidad está limitada a lo que está implementado en K8s.
Los volúmenes efímeros permitieron expandir Kubernetes utilizando controladores de CSI para proporcionar soporte para volúmenes locales ligeros. De esta forma, es posible aplicar : configuraciones, secretos, datos de identificación, variables, etc. Los controladores de CSI deben ser adaptados para soportar esta función de Kubernetes, ya que se prevé que los controladores estándar no funcionen, pero se asume que tales volúmenes pueden ser utilizados en cualquier nodo seleccionado para el pod.
Esto puede ser un problema para los volúmenes que consumen recursos significativos del nodo o para el almacenamiento disponible solo en algunos nodos. Por lo tanto, en Kubernetes 1.19 se presentan dos nuevas funciones de volúmenes para pruebas alfa, conceptualmente similares a los volúmenes EmptyDir:
volúmenes efímeros de propósito general;
seguimiento de la capacidad de almacenamiento de CSI.
Las ventajas del nuevo enfoque:
el almacenamiento puede ser local o montado en red;
los volúmenes pueden tener un tamaño definido que no puede ser superado por la aplicación;
funciona con cualquier controlador de CSI que admita la provisión de volúmenes persistentes y (para soporte de seguimiento de capacidad) implemente la llamada
GetCapacity;los volúmenes pueden tener algunos datos iniciales, dependiendo del controlador y los parámetros;
se admiten todas las operaciones estándar en el volumen (creación de instantáneas, cambio de tamaño, etc.);
los volúmenes pueden ser utilizados con cualquier controlador de aplicaciones que acepte una especificación de módulo o volumen;
El programador de Kubernetes elige automáticamente los nodos adecuados, por lo que ya no es necesario proporcionar y configurar extensiones del programador ni modificar los webhooks.
Opciones de uso
Por lo tanto, los volúmenes efímeros de propósito general son adecuados para las siguientes opciones de uso:
Memoria persistente como sustituto de la memoria RAM para memcached
Últimas versiones de memcached para el uso de memoria persistente (Intel Optane, etc., nota del traductor) en lugar de la memoria RAM convencional. Al implementar memcached a través del controlador de aplicaciones, se puede solicitar un volumen de tamaño específico de PMEM utilizando volúmenes efímeros de propósito general mediante el controlador CSI, por ejemplo, .
Almacenamiento local LVM como espacio de trabajo
Las aplicaciones que trabajan con datos cuyo tamaño excede la memoria RAM disponible pueden solicitar almacenamiento local con tamaños o métricas de rendimiento que no puedan ser proporcionados por los volúmenes EmptyDir normales de Kubernetes. Por ejemplo, para este propósito se escribió .
Acceso solo de lectura para volúmenes de datos
La asignación de un volumen puede llevar a la creación de un volumen lleno en:
la recuperación ;
la creación ;
trabajo .
Estos volúmenes pueden montarse en modo solo lectura.
¿Cómo funciona?
Volúmenes efímeros de propósito general
Una característica clave de los volúmenes efímeros de propósito general es la nueva fuente de volumen, EphemeralVolumeSource, que contiene todos los campos para realizar una solicitud de volumen (históricamente conocido como solicitud de volumen persistente, PVC). Un nuevo controlador en kube-controller-manager supervisa los pods que crean dicha fuente de volumen, y luego crea un PVC para estos pods. Para el controlador CSI, esta solicitud es similar a las demás, por lo que no se requiere soporte especial aquí.
Mientras existan estos PVC, pueden utilizarse como cualquier otra solicitud de volumen. En particular, pueden ser referenciados como fuente de datos al copiar un volumen o al crear una instantánea de un volumen. El objeto PVC también contiene el estado actual del volumen.
Los nombres de los PVC generados automáticamente son predefinidos: es una combinación del nombre del pod y del nombre del volumen, separados por un guion. La predefinición de los nombres facilita la interacción con los PVC, ya que no es necesario buscarlos si se conoce el nombre del pod y del volumen. La desventaja es que el nombre ya puede estar en uso, lo que Kubernetes detecta y, como resultado, se bloquea el lanzamiento del pod.
Para asegurarse de que el volumen se elimina junto con el pod, el controlador hace que el pod sea el propietario de la solicitud del volumen. Cuando se elimina el pod, se activa el mecanismo normal de recolección de basura, que elimina tanto la solicitud como el volumen.
Las solicitudes se asignan a un controlador de almacenamiento a través del mecanismo normal de clase de almacenamiento. Aunque se admiten las clases de enlace inmediato y tardío (que son WaitForFirstConsumer), para los volúmenes efímeros tiene sentido usar WaitForFirstConsumer, entonces el planificador puede tener en cuenta tanto el uso del nodo como la disponibilidad del almacenamiento al elegir el nodo. Aquí también aparece una nueva función.
Seguimiento de la capacidad de almacenamiento
Normalmente, el planificador no tiene datos sobre dónde el controlador CSI creará el volumen. Además, el planificador no tiene la capacidad de comunicarse directamente con el controlador para solicitar esta información. Por lo tanto, el planificador interroga a los nodos hasta que encuentra uno en el que los volúmenes pueden estar disponibles (vinculación tardía), o bien deja completamente la elección del lugar al controlador (vinculación inmediata).
Nuevo CSIStorageCapacity, que se encuentra en fase alpha, permite almacenar los datos necesarios en etcd, de modo que estén disponibles para el planificador. A diferencia del soporte para volúmenes efímeros de uso general, al desplegar el controlador es necesario habilitar el seguimiento de la capacidad de almacenamiento: external-provisioner debe publicar información sobre la capacidad, obtenida del controlador a través de GetCapacity.
Si el planificador necesita elegir un nodo para un pod con un volumen no vinculado que utiliza vinculación tardía, y el controlador activó esta función al desplegarse estableciendo la bandera CSIDriver.storageCapacity, se descartarán automáticamente los nodos que no tienen suficiente capacidad de almacenamiento. Esto funciona tanto para volúmenes efímeros de uso general como para volúmenes persistentes, pero no para volúmenes efímeros de CSI, ya que sus parámetros no pueden ser leídos por Kubernetes.
Como de costumbre, los volúmenes con enlace inmediato se crean antes de la planificación de pods, y su ubicación es seleccionada por el controlador de almacenamiento, por lo que al configurarlo external-provisioner por defecto se omiten las clases de almacenamiento con enlace inmediato, ya que estos datos de todos modos no se utilizarán.
Dado que el programador de Kubernetes tiene que trabajar con información potencialmente obsoleta, no hay garantías de que la capacidad esté disponible en cualquier momento en que se cree el volumen, pero, aun así, las posibilidades de que se cree sin reintentos aumentan.
N.B. Puede obtener más información y también practicar de forma segura en un entorno de prueba, y en caso de situaciones completamente incomprensibles, recibir ayuda calificada del soporte técnico en los intensivos — que se llevará a cabo del 28 al 30 de septiembre, y para profesionales más avanzados del 14 al 16 de octubre.
Seguridad
CSIStorageCapacity
Los objetos CSIStorageCapacity están en espacios de nombres, al implementar cada controlador de CSI en su propio espacio de nombres se recomienda restringir los permisos RBAC para CSIStorageCapacity en ese espacio, ya que es evidente de dónde provienen los datos. En cualquier caso, Kubernetes no verifica esto, y normalmente los controladores se instalan en un solo espacio de nombres, por lo que se espera que los controladores funcionen y no publiquen datos incorrectos (y aquí me sale la carta, nota del traductor inspirada en un chiste viejo)
Volúmenes efímeros de propósito general
Si los usuarios tienen permisos para crear un pod (directamente o indirectamente), también podrán crear volúmenes efímeros de uso general incluso si no tienen permisos para crear solicitudes de volumen. Todo esto se debe a que las verificaciones de permisos RBAC se aplican al controlador que crea el PVC, no al usuario. Este es un cambio fundamental que debe añadirse , antes de habilitar esta función en clústeres, si los usuarios no confiables no deben tener permisos para crear volúmenes.
Ejemplo
Una en PMEM-CSI contiene todos los cambios necesarios para ejecutar un clúster de Kubernetes 1.19 dentro de máquinas virtuales QEMU con todas las funciones en fase alpha. El código del controlador no ha cambiado, solo se modificó el despliegue.
En una máquina adecuada (Linux, un usuario normal puede usar , consulte los detalles) estos comandos levantarán el clúster e instalarán el controlador PMEM-CSI:
git clone --branch=kubernetes-1-19-blog-post https://github.com/intel/pmem-csi.git
cd pmem-csi
export TEST_KUBERNETES_VERSION=1.19 TEST_FEATURE_GATES=CSIStorageCapacity=true,GenericEphemeralVolume=true TEST_PMEM_REGISTRY=intel
make start && echo && test/setup-deployment.sh
Una vez que todo funcione, la salida contendrá instrucciones para su uso:
El clúster de pruebas está listo. Inicie sesión con [...] /pmem-csi/_work/pmem-govm/ssh.0, ejecute
kubectl una vez que haya iniciado sesión. Alternativamente, use kubectl directamente con la
siguiente variable de entorno:
KUBECONFIG=[...] /pmem-csi/_work/pmem-govm/kube.config
secret/pmem-csi-registry-secrets creado
secret/pmem-csi-node-secrets creado
serviceaccount/pmem-csi-controller creado
...
Para probar los volúmenes efímeros del controlador pmem-csi:
cat deploy/kubernetes-1.19/pmem-app-ephemeral.yaml |
[...] /pmem-csi/_work/pmem-govm/ssh.0 kubectl create -f -
Los objetos CSIStorageCapacity no están destinados a ser leídos por humanos, por lo que requiere algún tipo de procesamiento. Con filtros de plantilla en Golang se mostrarán las clases de almacenamiento; en este ejemplo se mostrarán el nombre, la topología y la capacidad:
$ kubectl get
-o go-template='{{range .items}}{{if eq .storageClassName "pmem-csi-sc-late-binding"}}{{.metadata.name}} {{.nodeTopology.matchLabels}} {{.capacity}}
{{end}}{{end}}'
csistoragecapacities
csisc-2js6n map[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker2] 30716Mi
csisc-sqdnt map[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker1] 30716Mi
csisc-ws4bv map[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker3] 30716Mi
Un objeto separado tiene el siguiente contenido:
$ kubectl describe csistoragecapacities/csisc-6cw8j
Nombre: csisc-sqdnt
Namespace: default
Etiquetas:
Anotaciones:
Versión API: storage.k8s.io/v1alpha1
Capacidad: 30716Mi
Tipo: CSIStorageCapacity
Metadatos:
Timestamp de creación: 2020-08-11T15:41:03Z
Nombre generado: csisc-
Campos gestionados:
...
Referencias del propietario:
Versión API: apps/v1
Controlador: verdadero
Tipo: StatefulSet
Nombre: pmem-csi-controller
UID: 590237f9-1eb4-4208-b37b-5f7eab4597d1
Versión del recurso: 2994
Enlace propio: /apis/storage.k8s.io/v1alpha1/namespaces/default/csistoragecapacities/csisc-sqdnt
UID: da36215b-3b9d-404a-a4c7-3f1c3502ab13
Topología de nodos:
Etiquetas de coincidencia:
pmem-csi.intel.com/node: pmem-csi-pmem-govm-worker1
Nombre de la clase de almacenamiento: pmem-csi-sc-late-binding
Eventos:
Intentemos crear una aplicación de demostración con un volumen efímero de uso general. El contenido del archivo pmem-app-ephemeral.yaml:
# This example Pod definition demonstrates
# how to use generic ephemeral inline volumes
# with a PMEM-CSI storage class.
kind: Pod
apiVersion: v1
metadata:
name: my-csi-app-inline-volume
spec:
containers:
- name: my-frontend
image: intel/pmem-csi-driver-test:v0.7.14
command: [ "sleep", "100000" ]
volumeMounts:
- mountPath: "/data"
name: my-csi-volume
volumes:
- name: my-csi-volume
ephemeral:
volumeClaimTemplate:
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 4Gi
storageClassName: pmem-csi-sc-late-binding
Después de la creación, como se muestra en las instrucciones anteriores, tenemos un pod y PVC adicionales:
$ kubectl get pods/my-csi-app-inline-volume -o wide
NOMBRE LISTO ESTADO RESTARTS EDAD IP NODO NODO NOMINADO PUERTAS DE DISPONIBILIDAD
my-csi-app-inline-volume 1/1 Ejecutando 0 6m58s 10.36.0.2 pmem-csi-pmem-govm-worker1
$ kubectl get pvc/my-csi-app-inline-volume-my-csi-volume
NOMBRE ESTADO VOLUMEN CAPACIDAD MODOS DE ACCESO STORAGECLASS EDAD
my-csi-app-inline-volume-my-csi-volume Vinculado pvc-c11eb7ab-a4fa-46fe-b515-b366be908823 4Gi RWO pmem-csi-sc-late-binding 9m21s
El propietario de PVC es el pod:
$ kubectl get -o yaml pvc/my-csi-app-inline-volume-my-csi-volume
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
annotations:
pv.kubernetes.io/bind-completed: "yes"
pv.kubernetes.io/bound-by-controller: "yes"
volume.beta.kubernetes.io/storage-provisioner: pmem-csi.intel.com
volume.kubernetes.io/selected-node: pmem-csi-pmem-govm-worker1
creationTimestamp: "2020-08-11T15:44:57Z"
finalizers:
- kubernetes.io/pvc-protection
managedFields:
...
name: my-csi-app-inline-volume-my-csi-volume
namespace: default
ownerReferences:
- apiVersion: v1
blockOwnerDeletion: true
controller: true
kind: Pod
name: my-csi-app-inline-volume
uid: 75c925bf-ca8e-441a-ac67-f190b7a2265f
...
La información se ha actualizado como se esperaba para pmem-csi-pmem-govm-worker1:
csisc-2js6n map[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker2] 30716Mi
csisc-sqdnt map[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker1] 26620Mi
csisc-ws4bv map[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker3] 30716Mi
Si otra aplicación necesita más de 26620Mi, el programador no lo tendrá en cuenta pmem-csi-pmem-govm-worker1 en cualquier caso.
¿Qué sigue?
Ambas funciones todavía están en desarrollo. Se han abierto varias solicitudes durante las pruebas alfa. Se está documentando el trabajo necesario para avanzar a la fase beta a partir de los enlaces con sugerencias de mejoras, así como qué alternativas ya se han considerado y rechazado:
Fuente: habr.com
