Volúmenes efímeros con seguimiento de la capacidad de almacenamiento: EmptyDir con esteroides

Volúmenes efímeros con seguimiento de la capacidad de almacenamiento: EmptyDir con esteroides

Algunas aplicaciones también necesitan almacenar datos, pero se sienten bastante cómodas con el hecho de que los datos no se guardarán después de reiniciar.

Por ejemplo, los servicios de almacenamiento en caché están limitados por la RAM, pero también pueden mover datos que rara vez se utilizan a un almacenamiento que es más lento que la RAM, con poco impacto en el rendimiento general. Otras aplicaciones deben tener en cuenta que puede haber algunas entradas de sólo lectura en los archivos, como configuraciones o claves secretas.

Kubernetes ya tiene varios tipos volúmenes efímeros, pero su funcionalidad se limita a lo que se implementa en los K8.

Efímero volúmenes CSI permitió ampliar Kubernetes con controladores CSI para brindar soporte para volúmenes locales livianos. De esta manera es posible utilizar estructuras arbitrarias: configuraciones, secretos, datos de identificación, variables, etc. Los controladores CSI deben modificarse para admitir esta característica de Kubernetes, ya que se supone que los controladores estandarizados habituales no funcionarán, pero se supone que dichos volúmenes se pueden utilizar en cualquier nodo seleccionado para el pod.

Esto puede ser un problema para volúmenes que consumen importantes recursos de host o para almacenamiento que solo está disponible en algunos hosts. Es por eso que Kubernetes 1.19 presenta dos nuevas funciones de volumen de prueba alfa que son conceptualmente similares a los volúmenes EmptyDir:

  • volúmenes efímeros de propósito general;

  • Seguimiento de la capacidad de almacenamiento CSI.

Ventajas del nuevo enfoque:

  • el almacenamiento puede ser local o estar conectado a través de una red;

  • los volúmenes pueden tener un tamaño específico que la aplicación no puede exceder;

  • funciona con cualquier controlador CSI que admita el aprovisionamiento de volúmenes persistentes y (para admitir el seguimiento de la capacidad) implemente la llamada GetCapacity;

  • los volúmenes pueden tener algunos datos iniciales según el controlador y la configuración;

  • se admiten todas las operaciones estándar con un volumen (creación de una instantánea, cambio de tamaño, etc.);

  • los volúmenes se pueden utilizar con cualquier controlador de aplicación que acepte una especificación de módulo o volumen;

  • El programador de Kubernetes selecciona los nodos adecuados por sí solo, por lo que ya no es necesario aprovisionar y configurar extensiones del programador ni modificar webhooks.

Opciones de aplicación

Por lo tanto, los volúmenes efímeros de uso general son adecuados para los siguientes casos de uso:

Memoria persistente como reemplazo de la RAM para memcached

Últimas versiones de memcached soporte adicional utilizando memoria persistente (Intel Optane, etc., aprox. traductor) en lugar de RAM normal. Al implementar Memcached a través de un controlador de aplicaciones, puede usar volúmenes efímeros de propósito general para solicitar que se asigne un volumen de un tamaño determinado desde PMEM usando el controlador CSI, por ejemplo. PMEM-CSI.

Almacenamiento local LVM como espacio de trabajo

Las aplicaciones que funcionan con datos mayores que la RAM pueden requerir almacenamiento local con un tamaño o métricas de rendimiento que los volúmenes vacíos normales de Kubernetes no pueden proporcionar. Por ejemplo, para este propósito fue escrito TopoLVM.

Acceso de solo lectura para volúmenes de datos

La asignación de un volumen puede dar lugar a la creación de un volumen completo cuando:

Estos volúmenes se pueden montar en modo de solo lectura.

¿Cómo funciona esto

Volúmenes efímeros de uso general

Una característica clave de los volúmenes efímeros de uso general es la nueva fuente de volumen, EphemeralVolumeSource, que contiene todos los campos para crear una solicitud de volumen (históricamente denominada solicitud de volumen persistente, PVC). Nuevo controlador en kube-controller-manager analiza los pods que crean dicha fuente de volumen y luego crea un PVC para esos pods. Para el controlador CSI, esta solicitud tiene el mismo aspecto que las demás, por lo que no se necesita soporte especial aquí.

Mientras existan dichos PVC, se pueden utilizar como cualquier otra solicitud en el volumen. En particular, se puede hacer referencia a ellos como fuente de datos al copiar un volumen o crear una instantánea a partir de un volumen. El objeto PVC también contiene el estado actual del volumen.

Los nombres de los PVC creados automáticamente están predefinidos: son una combinación del nombre del pod y el nombre del volumen, separados por un guión. Los nombres predefinidos facilitan la interacción con el PVC porque no es necesario buscarlo si conoce el nombre del pod y el nombre del volumen. La desventaja es que es posible que el nombre ya esté en uso, lo cual es detectado por Kubernetes y, como resultado, el pod no puede iniciarse.

Para garantizar que el volumen se elimine junto con el pod, el controlador realiza una solicitud al volumen bajo el propietario. Cuando se elimina el pod, funciona el mecanismo de recolección de basura estándar, que elimina tanto la solicitud como el volumen.

El controlador de almacenamiento hace coincidir las solicitudes a través del mecanismo normal de la clase de almacenamiento. Aunque las clases con vinculación inmediata y tardía (también conocidas como WaitForFirstConsumer) son compatibles, para volúmenes efímeros tiene sentido usar WaitForFirstConsumer, entonces el programador puede considerar tanto el uso del nodo como la disponibilidad de almacenamiento al seleccionar un nodo. Aquí aparece una nueva característica.

Seguimiento de la capacidad de almacenamiento

Normalmente, el programador no sabe dónde creará el volumen el controlador CSI. Tampoco hay forma de que el programador se comunique directamente con el conductor para solicitar esta información. Por lo tanto, el programador sondea los nodos hasta que encuentra uno en el que se puede acceder a los volúmenes (enlace tardío) o deja la elección de la ubicación completamente al controlador (enlace inmediato).

nuevo API CSIStorageCapacity, que se encuentra en etapa alfa, permite almacenar los datos necesarios en etcd para que estén disponibles para el programador. A diferencia de la compatibilidad con volúmenes efímeros de uso general, cuando implementa el controlador, debe habilitar el seguimiento de la capacidad de almacenamiento: external-provisioner debe publicar la información de capacidad recibida del conductor a través de la vía normal. GetCapacity.

Si el programador necesita seleccionar un nodo para un pod con un volumen independiente que utiliza enlace tardío y el controlador habilitó esta característica durante la implementación estableciendo la marca CSIDriver.storageCapacity, los nodos que no tengan suficiente capacidad de almacenamiento se descartarán automáticamente. Esto funciona tanto para volúmenes efímeros como persistentes de propósito general, pero no para volúmenes efímeros CSI porque Kubernetes no puede leer sus parámetros.

Como de costumbre, los volúmenes vinculados inmediatamente se crean antes de programar los pods y el controlador de almacenamiento elige su ubicación, por lo que al configurar external-provisioner De forma predeterminada, se omiten las clases de almacenamiento con enlace inmediato, ya que estos datos no se utilizarán de todos modos.

Dado que el programador de Kubernetes se ve obligado a trabajar con información potencialmente desactualizada, no hay garantía de que la capacidad esté disponible en todos los casos cuando se crea el volumen, pero de todos modos aumentan las posibilidades de que se cree sin reintentos.

NB Puede obtener información más detallada, así como "practicar en el puesto de gatos" de forma segura y, en caso de una situación completamente incomprensible, recibir asistencia técnica calificada en cursos intensivos. Base de Kubernetes se llevará a cabo del 28 al 30 de septiembre, y para especialistas más avanzados Mega de Kubernetes 14 al 16 de octubre.

seguridad

Capacidad de almacenamiento CSIS

Los objetos CSIStorageCapacity residen en espacios de nombres; al implementar cada controlador CSI en su propio espacio de nombres, se recomienda restringir los derechos RBAC a CSIStorageCapacity en ese espacio, ya que es obvio de dónde provienen los datos. Kubernetes no verifica esto de todos modos y, por lo general, los controladores se colocan en el mismo espacio de nombres, por lo que, en última instancia, se espera que los controladores funcionen y no publiquen datos incorrectos (y aquí es donde falló mi tarjeta). aprox. traductor basado en un chiste barbudo)

Volúmenes efímeros de uso general

Si los usuarios tienen derechos para crear un pod (directa o indirectamente), también podrán crear volúmenes efímeros de propósito general incluso si no tienen derechos para crear una solicitud en el volumen. Esto se debe a que las comprobaciones de permisos RBAC se aplican al controlador que crea el PVC, no al usuario. Este es el principal cambio a agregar. a tu cuenta, antes de habilitar esta función en clústeres donde los usuarios que no son de confianza no deberían tener derechos para crear volúmenes.

ejemplo

Separado rama PMEM-CSI contiene todos los cambios necesarios para ejecutar un clúster Kubernetes 1.19 dentro de máquinas virtuales QEMU con todas las funciones en la etapa alfa. El código del controlador no ha cambiado, solo ha cambiado la implementación.

En una máquina adecuada (Linux, un usuario normal puede utilizar Docker, ver aquí detalles) estos comandos abrirá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

Después de que todo funcione, el resultado contendrá instrucciones de uso:

The test cluster is ready. Log in with [...]/pmem-csi/_work/pmem-govm/ssh.0, run
kubectl once logged in.  Alternatively, use kubectl directly with the
following env variable:
   KUBECONFIG=[...]/pmem-csi/_work/pmem-govm/kube.config

secret/pmem-csi-registry-secrets created
secret/pmem-csi-node-secrets created
serviceaccount/pmem-csi-controller created
...
To try out the pmem-csi driver ephemeral volumes:
   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 se requiere cierto procesamiento. Los filtros de plantilla de Golang mostrarán las clases de almacenamiento; este ejemplo mostrará 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 único objeto tiene el siguiente contenido:

$ kubectl describe csistoragecapacities/csisc-6cw8j
Name:         csisc-sqdnt
Namespace:    default
Labels:       <none>
Annotations:  <none>
API Version:  storage.k8s.io/v1alpha1
Capacity:     30716Mi
Kind:         CSIStorageCapacity
Metadata:
  Creation Timestamp:  2020-08-11T15:41:03Z
  Generate Name:       csisc-
  Managed Fields:
    ...
  Owner References:
    API Version:     apps/v1
    Controller:      true
    Kind:            StatefulSet
    Name:            pmem-csi-controller
    UID:             590237f9-1eb4-4208-b37b-5f7eab4597d1
  Resource Version:  2994
  Self Link:         /apis/storage.k8s.io/v1alpha1/namespaces/default/csistoragecapacities/csisc-sqdnt
  UID:               da36215b-3b9d-404a-a4c7-3f1c3502ab13
Node Topology:
  Match Labels:
    pmem-csi.intel.com/node:  pmem-csi-pmem-govm-worker1
Storage Class Name:           pmem-csi-sc-late-binding
Events:                       <none>

Intentemos crear una aplicación de demostración con un único volumen efímero de propósito general. 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 crear, como se muestra en las instrucciones anteriores, ahora tenemos un pod y PVC adicionales:

$ kubectl get pods/my-csi-app-inline-volume -o wide
NAME                       READY   STATUS    RESTARTS   AGE     IP          NODE                         NOMINATED NODE   READINESS GATES
my-csi-app-inline-volume   1/1     Running   0          6m58s   10.36.0.2   pmem-csi-pmem-govm-worker1   <none>           <none>
$ kubectl get pvc/my-csi-app-inline-volume-my-csi-volume
NAME                                     STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS               AGE
my-csi-app-inline-volume-my-csi-volume   Bound    pvc-c11eb7ab-a4fa-46fe-b515-b366be908823   4Gi        RWO            pmem-csi-sc-late-binding   9m21s

Propietario de PVC - bajo:

$ 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
...

Se espera información actualizada 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 tendrá en cuenta pmem-csi-pmem-govm-worker1 En todo caso.

¿Qué será lo próximo?

Ambas funciones aún están en desarrollo. Se abrieron varias aplicaciones durante la prueba alfa. Los enlaces de la propuesta de mejora documentan el trabajo que se debe realizar para pasar a la etapa beta, así como las alternativas que ya se han considerado y rechazado:

Fuente: habr.com

Añadir un comentario