🥇Volume effimero con tracciamento della capacità di archiviazione: EmptyDir allo stato dell’arte

Alcune applicazioni necessitano anche di memorizzare dati, ma sono abbastanza tranquille riguardo al fatto che i dati non verranno salvati dopo il riavvio.

Ad esempio, i servizi di caching sono limitati dalla memoria RAM, ma possono anche spostare i dati raramente utilizzati in uno storage più lento della RAM, con un impatto ridotto sulle prestazioni generali. Ad altre applicazioni serve sapere che nei file potrebbero esserci alcuni input a sola lettura, come impostazioni o chiavi segrete.

In Kubernetes esistono già diversi tipi di volumi effimeri, ma la loro funzionalità è limitata a quanto implementato in K8s.

I volumi effimeri CSI hanno permesso di estendere Kubernetes tramite driver CSI per supportare volumi locali leggeri. In questo modo è possibile applicare strutture arbitrarie: impostazioni, segreti, dati per l'identificazione, variabili e così via. I driver CSI devono essere perfezionati per supportare questa funzione di Kubernetes, poiché si presume che i driver standardizzati usuali non funzioneranno — ma si presume che tali volumi possano essere utilizzati su qualsiasi nodo scelto per il pod.

Questo potrebbe diventare un problema per i volumi con un consumo significativo delle risorse del nodo o per lo storage accessibile solo su alcuni nodi. Pertanto, in Kubernetes 1.19 sono state introdotte due nuove funzioni per i volumi per il test in alpha, concettualmente simili ai volumi EmptyDir:

volumi efimeri di uso generale;
monitoraggio della capacità di storage CSI.

I vantaggi del nuovo approccio:

lo storage può essere locale o montato in rete;
i volumi possono avere una dimensione specificata che non può essere superata dall'applicazione;
funziona con qualsiasi driver CSI che supporta la fornitura di volumi persistenti e (per supportare il monitoraggio della capacità) implementa la chiamata GetCapacity;
i volumi possono avere alcuni dati iniziali a seconda del driver e delle opzioni;
tutte le operazioni standard sul volume (creazione di snapshot, ridimensionamento, ecc.) sono supportate;
i volumi possono essere utilizzati con qualsiasi controller di applicazioni che accette la specifica del modulo o del volume;
lo scheduler di Kubernetes seleziona automaticamente i nodi adatti, quindi non è più necessario garantire e configurare le estensioni dello scheduler o modificare i webhook.

Opzioni di utilizzo

Pertanto, i volumi effimeri di uso generale sono adatti per le seguenti opzioni di utilizzo:

Memoria persistente come sostituto della memoria volatile per memcached

Le ultime versioni di memcached hanno aggiunto supporto per l'uso di memoria persistente (Intel Optane, ecc., nota del traduttore) anziché la normale memoria volatile. Quando si distribuisce memcached tramite un controller di applicazioni, è possibile utilizzare volumi effimeri di uso generale per richiedere l'allocazione di un volume di dimensioni specificate da PMEM utilizzando il driver CSI, ad esempio PMEM-CSI.

Archiviazione locale LVM come area di lavoro

Le applicazioni che gestiscono dati di dimensioni superiori alla memoria RAM possono richiedere uno storage locale con dimensioni o metriche di prestazione che i normali volumi EmptyDir di Kubernetes non possono garantire. Ad esempio, è stato scritto per questo scopo TopoLVM.

Accesso in sola lettura per i volumi con dati

L'assegnazione del volume può portare alla creazione di un volume pieno in caso di:

Questi volumi possono essere montati in modalità di sola lettura.

Come funziona

Volumi effimeri di uso generale

Una caratteristica chiave dei volumi effimeri di uso generale è la nuova sorgente di volume, EphemeralVolumeSource, che contiene tutti i campi necessari per elaborare una richiesta per il volume (storicamente chiamata richiesta di volume persistente, PVC). Un nuovo controller in kube-controller-manager monitora i pod che creano questa sorgente di volume e poi crea un PVC per questi pod. Per il driver CSI, questa richiesta appare come le altre, quindi non è necessaria un supporto speciale qui.

Finché esistono PVC di questo tipo, possono essere utilizzati come qualsiasi altra richiesta su un volume. In particolare, possono fungere da riferimento come fonte di dati durante la copia di un volume o la creazione di uno snapshot del volume. L'oggetto PVC contiene anche lo stato attuale del volume.

I nomi dei PVC creati automaticamente sono predefiniti: si tratta di una combinazione del nome del pod e del nome del volume, separati da un trattino. La predefinizione dei nomi semplifica l'interazione con i PVC, poiché non è necessario cercarli se si conoscono il nome del pod e il nome del volume. Uno svantaggio è che il nome potrebbe già essere utilizzato, il che viene rilevato da Kubernetes e di conseguenza il pod non può essere avviato.

Per garantire che il volume venga eliminato insieme al pod, il controller rende il pod proprietario della richiesta sul volume. Quando il pod viene eliminato, si attiva il meccanismo di pulizia standard che rimuove sia la richiesta che il volume.

Alle richieste viene associato il driver di archiviazione tramite il meccanismo consueto della classe di archiviazione. Sebbene siano supportate le classi con associazione immediata e ritardata (che sono) WaitForFirstConsumer) ha senso utilizzare per i volumi efimeri. WaitForFirstConsumer, allora il pianificatore può tenere conto sia dell'uso del nodo che della disponibilità dello storage nella scelta del nodo. Qui compare una nuova funzionalità.

Monitoraggio della capacità di storage

Di solito, il pianificatore non ha dati su dove il driver CSI creerà il volume. Inoltre, il pianificatore non ha la possibilità di contattare direttamente il driver per richiedere queste informazioni. Pertanto, il pianificatore interroga i nodi finché non trova uno in cui i volumi sono disponibili (collegamento posticipato) oppure lascia completamente la scelta del luogo al driver (collegamento immediato).

Nuovo API CSIStorageCapacity, attualmente in fase alpha, consente di memorizzare le informazioni necessarie in etcd, rendendole accessibili al pianificatore. A differenza del supporto per i volumi efimeri generici, durante il deployment del driver è necessario abilitare il monitoraggio della capacità di storage: external-provisioner deve pubblicare informazioni sulla capacità ricevute dal driver attraverso il solito GetCapacity.

Se il pianificatore deve scegliere un nodo per un pod con un volume non collegato, che utilizza il collegamento posticipato, e il driver durante il deployment ha attivato questa funzione impostando il flag CSIDriver.storageCapacity, verranno automaticamente scartati i nodi che non hanno abbastanza capacità di archiviazione. Questo vale sia per i volumi ephemeral a uso generico che per quelli permanenti, ma non per i volumi ephemeral CSI, poiché le loro configurazioni non possono essere lette da Kubernetes.

Come al solito, i volumi con binding immediato vengono creati prima della programmazione dei pod, e la loro posizione viene scelta dal driver di archiviazione, quindi durante la configurazione external-provisioner per impostazione predefinita vengono ignorate le classi di archiviazione con binding immediato, poiché questi dati non verranno comunque utilizzati.

Poiché il pianificatore di Kubernetes è costretto a lavorare con informazioni potenzialmente obsolete, non ci sono garanzie che la capacità sarà disponibile in qualsiasi caso quando il volume verrà creato, tuttavia, le possibilità che venga creato senza ripetuti tentativi aumentano.

N.B. Puoi ottenere maggiori informazioni e anche 'fare pratica' in un ambiente sicuro, e in caso di situazioni totalmente incomprensibili ricevere assistenza qualificata dal supporto tecnico durante gli intensivi — Base di Kubernetes che si svolgeranno dal 28 al 30 settembre, e per professionisti più avanzati Kubernetes Mega dal 14 al 16 ottobre.

Sicurezza

CSIStorageCapacity

Le risorse CSIStorageCapacity si trovano nei namespace; durante la distribuzione di ogni driver CSI, è consigliabile limitare i diritti RBAC per CSIStorageCapacity in quel namespace, poiché è chiaro da dove provengono i dati. In ogni caso, Kubernetes non verifica questo, e in genere i driver vengono installati in un unico namespace, quindi alla fine ci si aspetta che i driver funzionino e non pubblicizzino dati errati (e qui mi è andata bene). nota del traduttore ispirata a una barzelletta)

Volumi effimeri di uso generale

Se gli utenti hanno i diritti per creare un pod (direttamente o indirettamente), potranno anche creare volumi efimeri condivisi anche se non hanno diritti per creare una richiesta di volume. Questo perché i controlli dei diritti RBAC si applicano al controller che crea il PVC e non all'utente. Questa è la modifica principale da aggiungere all'account, prima di attivare questa funzione nei cluster, se utenti non affidabili non dovrebbero avere diritti per creare volumi.

Esempio

separato ramo PMEM-CSI contiene tutte le modifiche necessarie per avviare un cluster Kubernetes 1.19 all'interno di macchine virtuali QEMU con tutte le funzionalità in fase alpha. Il codice del driver non è cambiato, è stata modificata solo la distribuzione.

Su una macchina compatibile (Linux, un utente normale può utilizzare Docker, vedere qui i dettagli) questi comandi avvieranno il cluster e installeranno il driver 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

Dopo che tutto sarà stato eseguito, l'output conterrà istruzioni per l'uso:

Il cluster di test è pronto. Accedi con [...]/pmem-csi/_work/pmem-govm/ssh.0, esegui
kubectl una volta connesso. In alternativa, usa kubectl direttamente con la
seguente variabile env:
   KUBECONFIG=[...]/pmem-csi/_work/pmem-govm/kube.config

secret/pmem-csi-registry-secrets creato
secret/pmem-csi-node-secrets creato
serviceaccount/pmem-csi-controller creato
...
Per provare i volumi effimeri del driver pmem-csi:
   cat deploy/kubernetes-1.19/pmem-app-ephemeral.yaml |
   [...]/pmem-csi/_work/pmem-govm/ssh.0 kubectl create -f -

Gli oggetti CSIStorageCapacity non sono destinati alla lettura da parte degli esseri umani, quindi è necessaria un'elaborazione. I classi di archiviazione verranno mostrate tramite filtri del modello in Golang, in questo esempio verranno visualizzati nome, topologia e capacità:

$ 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 mappa[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker2] 30716Mi
csisc-sqdnt mappa[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker1] 30716Mi
csisc-ws4bv mappa[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker3] 30716Mi

Un oggetto separato ha questo contenuto:

$ kubectl describe csistoragecapacities/csisc-6cw8j
Nome:         csisc-sqdnt
Namespace:    default
Etichette:       <nessuna>
Annotazioni:  <nessuna>
Versione API:  storage.k8s.io/v1alpha1
Capacità:     30716Mi
Tipo:         CSIStorageCapacity
Metadati:
  Timestamp di Creazione:  2020-08-11T15:41:03Z
  Nome Generato:       csisc-
  Campi Gestiti:
    ...
  Riferimenti Proprietari:
    Versione API:     apps/v1
    Controllore:      true
    Tipo:            StatefulSet
    Nome:            pmem-csi-controller
    UID:             590237f9-1eb4-4208-b37b-5f7eab4597d1
  Versione Risorsa:  2994
  Link Autonomo:         /apis/storage.k8s.io/v1alpha1/namespaces/default/csistoragecapacities/csisc-sqdnt
  UID:               da36215b-3b9d-404a-a4c7-3f1c3502ab13
Topologia nodo:
  Etichetta di corrispondenza:
    pmem-csi.intel.com/node:  pmem-csi-pmem-govm-worker1
Nome Classe di Archiviazione:           pmem-csi-sc-late-binding
Eventi:                       <nessuno>

Proviamo a creare un'applicazione dimostrativa con un volume efimero di uso comune. Il contenuto del file 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

Dopo la creazione, come descritto nelle istruzioni precedenti, abbiamo ottenuto un pod aggiuntivo e PVC:

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

Il proprietario del PVC è il 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
...

Le informazioni sono state aggiornate come previsto per pmem-csi-pmem-govm-worker1:

csisc-2js6n mappa[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker2] 30716Mi
csisc-sqdnt mappa[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker1] 26620Mi
csisc-ws4bv mappa[pmem-csi.intel.com/node:pmem-csi-pmem-govm-worker3] 30716Mi

Se un'altra applicazione ha bisogno di più di 26620Mi, il pianificatore non lo prenderà in considerazione pmem-csi-pmem-govm-worker1 in ogni caso.

E ora?

Entrambi i servizi sono ancora in fase di sviluppo. Sono state aperte diverse segnalazioni durante il test alpha. I collegamenti con le proposte di miglioramento documentano il lavoro necessario per passare alla fase beta, così come le alternative già esaminate e scartate:

Fonte: habr.com