ProHoster > Blog > Administración > Volumes efémeros con seguimento da capacidade de almacenamento: EmptyDir en esteroides

Volumes efémeros con seguimento da capacidade de almacenamento: EmptyDir en esteroides

Volumes efémeros con seguimento da capacidade de almacenamento: EmptyDir en esteroides

Algunhas aplicacións tamén precisan almacenar datos, pero están bastante cómodos co feito de que os datos non se gardarán despois dun reinicio.

Por exemplo, os servizos de almacenamento en caché están limitados pola memoria RAM, pero tamén poden mover datos que raramente se usan a un almacenamento máis lento que a RAM, con pouco impacto no rendemento xeral. Outras aplicacións deben ter en conta que pode haber algunha entrada de só lectura nos ficheiros, como a configuración ou as claves secretas.

Kubernetes xa ten varios tipos volumes efémeros, pero a súa funcionalidade limítase ao que se implementa nos K8.

Efémero Volumes CSI permitiu que Kubernetes se estendese con controladores CSI para ofrecer soporte para volumes locais lixeiros. Deste xeito é posible utilizar estruturas arbitrarias: axustes, segredos, datos de identificación, variables, etc. Os controladores CSI deben modificarse para admitir esta función de Kubernetes, xa que se supón que os controladores normalizados normais non funcionarán, pero suponse que tales volumes poden usarse en calquera nodo seleccionado para o pod.

Isto pode ser un problema para volumes que consumen recursos de host importantes ou para almacenamento que só está dispoñible nalgúns hosts. É por iso que Kubernetes 1.19 introduce dúas novas funcións de volume de proba alfa que son conceptualmente similares aos volumes EmptyDir:

  • volumes efémeros de propósito xeral;

  • Seguimento da capacidade de almacenamento CSI.

Vantaxes do novo enfoque:

  • o almacenamento pode ser local ou conectado a través dunha rede;

  • os volumes poden ter un tamaño especificado que a aplicación non pode superar;

  • funciona con calquera controlador CSI que admita a subministración de volumes persistentes e (para soportar o seguimento da capacidade) implementar a chamada GetCapacity;

  • os volumes poden ter algúns datos iniciais dependendo do controlador e da configuración;

  • admiten todas as operacións estándar cun volume (creación dunha instantánea, redimensionamento, etc.);

  • os volumes pódense usar con calquera controlador de aplicación que acepte unha especificación de módulo ou volume;

  • O programador de Kubernetes selecciona os nós axeitados por si mesmo, polo que xa non hai necesidade de aprovisionar e configurar extensións do programador nin modificar os webhooks.

Aplicacións

Polo tanto, os volumes efémeros de propósito xeral son axeitados para os seguintes casos de uso:

Memoria persistente como substituto da memoria RAM para memcached

Últimos lanzamentos de memcached apoio adicional usando memoria persistente (Intel Optane, etc., aprox. tradutor) en lugar de RAM normal. Ao implementar memcached a través dun controlador de aplicación, pode usar volumes efémeros de propósito xeral para solicitar que un volume dun tamaño determinado sexa asignado desde PMEM mediante o controlador CSI, por exemplo PMEM-CSI.

Almacenamento local LVM como espazo de traballo

As aplicacións que traballan con datos que son máis grandes que a RAM poden requirir almacenamento local cun tamaño ou métricas de rendemento que os volumes EmptyDir habituais de Kubernetes non poden proporcionar. Por exemplo, para este fin escribiuse TopoLVM.

Acceso de só lectura para volumes de datos

A asignación dun volume pode dar lugar á creación dun volume completo cando:

Estes volumes pódense montar en modo de só lectura.

Chat isto

Volumes efémeros de propósito xeral

Unha característica clave dos volumes efémeros de propósito xeral é a nova fonte de volume, EphemeralVolumeSource, que contén todos os campos para crear unha solicitude de volume (históricamente chamada solicitude de volume persistente, PVC). Novo controlador en kube-controller-manager mira as vainas que crean esa fonte de volume e, a continuación, crea un PVC para esas vainas. Para o controlador CSI, esta solicitude ten o mesmo aspecto que as outras, polo que aquí non se precisa soporte especial.

Mentres existan tales PVC, pódense usar como calquera outra solicitude no volume. En particular, pódense facer referencia a eles como fonte de datos cando se copia un volume ou se crea unha instantánea desde un volume. O obxecto de PVC tamén contén o estado actual do volume.

Os nomes dos PVC creados automaticamente están predefinidos: son unha combinación do nome do pod e do nome do volume, separados por un guión. Os nomes predefinidos facilitan a interacción co PVC porque non tes que buscalo se coñeces o nome do pod e o nome do volume. A desvantaxe é que é posible que o nome xa estea en uso, o que Kubernetes detecta e, como resultado, o pod bloquea o inicio.

Para asegurarse de que o volume se elimine xunto co pod, o controlador envía unha solicitude ao volume baixo o propietario. Cando se elimina o pod, funciona o mecanismo estándar de recollida de lixo, que elimina tanto a solicitude como o volume.

As solicitudes son coincidentes polo controlador de almacenamento a través do mecanismo normal da clase de almacenamento. Aínda que as clases con vinculación inmediata e tardía (tamén coñecido como WaitForFirstConsumer) son compatibles, para volumes efémeros ten sentido usar WaitForFirstConsumer, entón o planificador pode considerar tanto o uso do nodo como a dispoñibilidade de almacenamento ao seleccionar un nodo. Aquí aparece unha nova función.

Seguimento da capacidade de almacenamento

Normalmente o programador non sabe onde o controlador CSI creará o volume. Tampouco hai xeito de que o programador se poña en contacto co condutor directamente para solicitar esta información. Polo tanto, o programador consulta os nós ata que atopa un no que se pode acceder aos volumes (ligadura tardía) ou deixa a elección da localización totalmente ao controlador (ligadura inmediata).

Novo API CSIStorageCapacity, que está na fase alfa, permite almacenar os datos necesarios en etcd para que estean dispoñibles para o planificador. A diferenza do soporte para volumes efémeros de propósito xeral, cando implementas o controlador, debes activar o seguimento da capacidade de almacenamento: external-provisioner debería publicar a información de capacidade recibida do condutor vía normal GetCapacity.

Se o programador precisa seleccionar un nodo para un pod cun volume sen vincular que usa a vinculación tardía e o controlador activou esta función durante a implantación configurando a marca CSIDriver.storageCapacity, entón os nós que non teñan suficiente capacidade de almacenamento descartaranse automaticamente. Isto funciona tanto para volumes efémeros de propósito xeral como para volumes persistentes, pero non para volumes efémeros CSI porque Kubernetes non pode ler os seus parámetros.

Como é habitual, os volumes ligados inmediatamente créanse antes de programar os pods e o controlador de almacenamento elixe a súa ubicación, polo que ao configurar external-provisioner De forma predeterminada, omítense as clases de almacenamento con vinculación inmediata, xa que estes datos non se usarán de todos os xeitos.

Dado que o planificador de kubernetes está obrigado a traballar con información potencialmente desactualizada, non hai garantía de que a capacidade estea dispoñible en todos os casos cando se cree o volume, pero as posibilidades de que se cree sen reintentos aumentan.

NB Podes obter información máis detallada, así como "practicar no posto de gatos" de forma segura e, en caso dunha situación completamente incomprensible, recibir asistencia técnica cualificada en cursos intensivos - Base Kubernetes celebrarase do 28 ao 30 de setembro, e para especialistas máis avanzados Kubernetes Mega 14-16 de outubro.

Безопасность

Capacidade de almacenamento CSIS

Os obxectos CSIStorageCapacity residen en espazos de nomes; ao lanzar cada controlador CSI no seu propio espazo de nomes, recoméndase restrinxir os dereitos RBAC ao CSIStorageCapacity nese espazo xa que é obvio de onde proceden os datos. Kubernetes non verifica isto de todos os xeitos, e normalmente os controladores colócanse no mesmo espazo de nomes, polo que, en última instancia, espérase que os controladores funcionen e non publiquen datos incorrectos (e aquí é onde fallou a miña tarxeta, aprox. tradutor baseado nun chiste barbudo)

Volumes efémeros de propósito xeral

Se os usuarios teñen dereitos para crear un pod (directa ou indirectamente), tamén poderán crear volumes efémeros de propósito xeral aínda que non teñan dereitos para crear unha solicitude no volume. Isto débese a que as comprobacións de permisos RBAC aplícanse ao controlador que crea o PVC, non ao usuario. Este é o principal cambio a engadir á súa conta, antes de activar esta función en clústeres nos que os usuarios non fiables non deberían ter dereitos para crear volumes.

Exemplo

Separar rama PMEM-CSI contén todos os cambios necesarios para executar un clúster Kubernetes 1.19 dentro de máquinas virtuais QEMU con todas as funcións na fase alfa. O código do controlador non cambiou, só cambiou a implementación.

Nunha máquina adecuada (Linux, un usuario normal pode usar Estivador, mirar aquí detalles) estes comandos mostrarán o clúster e instalarán o 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

Despois de que todo funcione, a saída conterá instrucións 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 -

Os obxectos CSIStorageCapacity non están destinados a ser lidos por humanos, polo que é necesario un procesamento. Os filtros de modelos de Golang mostrarán as clases de almacenamento, este exemplo mostrará o nome, a topoloxía e a capacidade:

$ 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 obxecto ten o seguinte contido:

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

Tentemos crear unha aplicación de demostración cun único volume efémero de propósito xeral. Contidos do ficheiro 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

Despois de crear, como se mostra nas instrucións anteriores, agora temos un pod e PVC adicional:

$ 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 - baixo:

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

Información actualizada esperadamente 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

Se outra aplicación precisa máis de 26620Mi, o programador non terá en conta pmem-csi-pmem-govm-worker1 en calquera caso.

Cal é o próximo?

Ambas funcións aínda están en desenvolvemento. Durante a proba alfa abríronse varias aplicacións. Os enlaces de propostas de mellora documentan o traballo que hai que facer para pasar á fase beta, así como que alternativas xa foron consideradas e rexeitadas:

Fonte: www.habr.com

Engadir un comentario