Volumi effimeri con monitoraggio della capacità di archiviazione: VuotoDir sugli steroidi

Volumi effimeri con monitoraggio della capacità di archiviazione: VuotoDir sugli steroidi

Anche alcune applicazioni necessitano di memorizzare dati, ma sono abbastanza a loro agio con il fatto che i dati non verranno salvati dopo il riavvio.

Ad esempio, i servizi di memorizzazione nella cache sono limitati dalla RAM, ma possono anche spostare dati utilizzati raramente in uno spazio di archiviazione più lento della RAM, con un impatto minimo sulle prestazioni complessive. Altre applicazioni devono essere consapevoli del fatto che potrebbero esserci degli input di sola lettura nei file, come impostazioni o chiavi segrete.

Kubernetes ne ha già diversi tipi volumi effimeri, ma la loro funzionalità è limitata a quanto implementato nei K8.

Effimero Volumi CSI ha consentito di estendere Kubernetes con i driver CSI per fornire supporto per volumi locali leggeri. In questo modo è possibile utilizzare strutture arbitrarie: impostazioni, segreti, dati identificativi, variabili e così via. I driver CSI devono essere modificati per supportare questa funzionalità Kubernetes, poiché si presuppone che i normali driver standardizzati non funzioneranno, ma si presuppone che tali volumi possano essere utilizzati su qualsiasi nodo selezionato per il pod.

Ciò potrebbe rappresentare un problema per i volumi che consumano risorse host significative o per l'archiviazione disponibile solo su alcuni host. Ecco perché Kubernetes 1.19 introduce due nuove funzionalità del volume di test alpha che sono concettualmente simili ai volumi VuotoDir:

  • volumi effimeri per uso generale;

  • Monitoraggio della capacità di archiviazione CSI.

Vantaggi del nuovo approccio:

  • lo storage può essere locale o connesso tramite rete;

  • i volumi possono avere una dimensione specifica che non può essere superata dall'applicazione;

  • funziona con qualsiasi driver CSI che supporti il ​​provisioning di volumi persistenti e (per supportare il monitoraggio della capacità) implementi la chiamata GetCapacity;

  • i volumi potrebbero avere alcuni dati iniziali a seconda del driver e delle impostazioni;

  • sono supportate tutte le operazioni standard con un volume (creazione di un'istantanea, ridimensionamento, ecc.);

  • i volumi possono essere utilizzati con qualsiasi controller dell'applicazione che accetta una specifica di modulo o volume;

  • Lo scheduler Kubernetes seleziona autonomamente i nodi adatti, quindi non è più necessario fornire e configurare estensioni dello scheduler o modificare webhook.

Opzioni di applicazione

Pertanto, i volumi temporanei per uso generale sono adatti ai seguenti casi d'uso:

Memoria persistente in sostituzione della RAM per memcached

Ultime versioni di memcached aggiunto supporto utilizzando la memoria persistente (Intel Optane, ecc., ca. traduttore) invece della normale RAM. Quando si distribuisce memcached tramite un controller dell'applicazione, è possibile utilizzare volumi temporanei per uso generale per richiedere che un volume di una determinata dimensione venga allocato da PMEM utilizzando il driver CSI, ad esempio PMEM-CSI.

Archiviazione locale LVM come spazio di lavoro

Le applicazioni che funzionano con dati più grandi della RAM potrebbero richiedere un'archiviazione locale con dimensioni o parametri prestazionali che i normali volumi VuotoDir di Kubernetes non sono in grado di fornire. Ad esempio, è stato scritto per questo scopo TopoLVM.

Accesso in sola lettura per i volumi di dati

L'allocazione di un volume può comportare la creazione di un volume completo quando:

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

Come funziona

Volumi effimeri per uso generale

Una caratteristica fondamentale dei volumi temporanei per uso generale è la nuova origine del volume, EphemeralVolumeSource, contenente tutti i campi per creare una richiesta di volume (storicamente chiamata richiesta di volume persistente, PVC). Nuovo controller in arrivo kube-controller-manager esamina i pod che creano tale sorgente di volume e quindi crea una PVC per tali pod. Per il driver CSI, questa richiesta sembra uguale alle altre, quindi non è necessario alcun supporto speciale qui.

Finché esistono tali PVC, possono essere utilizzati come qualsiasi altra richiesta sul volume. In particolare, è possibile fare riferimento ad essi come origine dati durante la copia di un volume o la creazione di uno snapshot da un volume. L'oggetto PVC contiene anche lo stato corrente del volume.

I nomi dei PVC creati automaticamente sono predefiniti: sono una combinazione del nome del pod e del nome del volume, separati da un trattino. I nomi predefiniti semplificano l'interazione con il PVC perché non è necessario cercarlo se si conosce il nome del pod e il nome del volume. Lo svantaggio è che il nome potrebbe essere già in uso, cosa che viene rilevata da Kubernetes e di conseguenza l'avvio del pod viene bloccato.

Per garantire che il volume venga eliminato insieme al pod, il controller effettua una richiesta al volume del proprietario. Quando il pod viene eliminato, funziona il meccanismo standard di garbage collection, che elimina sia la richiesta che il volume.

Le richieste vengono soddisfatte dal driver di archiviazione tramite il normale meccanismo della classe di archiviazione. Sebbene le classi con rilegatura immediata e tardiva (aka WaitForFirstConsumer) sono supportati, per i volumi temporanei è opportuno utilizzarli WaitForFirstConsumer, lo scheduler può considerare sia l'utilizzo del nodo che la disponibilità dello storage quando seleziona un nodo. Una nuova funzionalità appare qui.

Monitoraggio della capacità di archiviazione

In genere lo scheduler non è a conoscenza di dove il driver CSI creerà il volume. Inoltre, non è possibile per lo scheduler contattare direttamente l'autista per richiedere queste informazioni. Pertanto, lo scheduler interroga i nodi finché non ne trova uno su cui è possibile accedere ai volumi (associazione tardiva) o lascia la scelta della posizione interamente al driver (associazione immediata).

Nuovo API CSIStorageCapacity, che è nella fase alfa, consente di memorizzare i dati necessari in etcd in modo che siano disponibili per lo scheduler. A differenza del supporto per volumi temporanei per uso generale, quando si distribuisce il driver è necessario abilitare il monitoraggio della capacità di archiviazione: external-provisioner dovrebbe pubblicare le informazioni sulla capacità ricevute dal conducente tramite normale GetCapacity.

Se lo scheduler deve selezionare un nodo per un pod con un volume non associato che utilizza l'associazione tardiva e il driver ha abilitato questa funzionalità durante la distribuzione impostando il flag CSIDriver.storageCapacity, i nodi che non dispongono di capacità di archiviazione sufficiente verranno automaticamente scartati. Funziona sia per i volumi temporanei che per quelli persistenti per uso generale, ma non per i volumi temporanei CSI poiché i relativi parametri non possono essere letti da Kubernetes.

Come al solito, i volumi collegati immediatamente vengono creati prima della pianificazione dei pod e il loro posizionamento viene scelto dal driver di archiviazione, quindi durante la configurazione external-provisioner Per impostazione predefinita, le classi di archiviazione con associazione immediata vengono saltate poiché questi dati non verranno comunque utilizzati.

Poiché lo scheduler di Kubernetes è costretto a lavorare con informazioni potenzialmente non aggiornate, non vi è alcuna garanzia che la capacità sia sempre disponibile al momento della creazione del volume, ma aumentano comunque le possibilità che venga creato senza nuovi tentativi.

NB È possibile ottenere informazioni più dettagliate, nonché "esercitarsi sul supporto dei gatti" in sicurezza e, in caso di una situazione completamente incomprensibile, ricevere assistenza di supporto tecnico qualificato durante corsi intensivi - Base Kubernetes si terrà dal 28 al 30 settembre e per gli specialisti più avanzati Kubernetes Mega 14-16 ottobre.

sicurezza

Capacità di archiviazione CSIS

Gli oggetti CSIStorageCapacity risiedono negli spazi dei nomi; quando si distribuisce ciascun driver CSI nel proprio spazio dei nomi, si consiglia di limitare i diritti RBAC a CSIStorageCapacity in quello spazio poiché è ovvio da dove provengono i dati. Kubernetes non lo verifica comunque e di solito i driver vengono inseriti nello stesso spazio dei nomi, quindi alla fine ci si aspetta che i driver funzionino e non pubblichino dati errati (ed è qui che la mia scheda ha fallito, ca. traduttore basato su uno scherzo barbuto)

Volumi effimeri per uso generale

Se gli utenti dispongono dei diritti per creare un pod (direttamente o indirettamente), potranno anche creare volumi temporanei per uso generale anche se non dispongono dei diritti per creare una richiesta sul volume. Questo perché i controlli delle autorizzazioni RBAC vengono applicati al controller che crea la PVC, non all'utente. Questa è la principale modifica da aggiungere al tuo account, prima di abilitare questa funzionalità sui cluster in cui gli utenti non attendibili non dovrebbero avere i diritti per creare volumi.

esempio

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

Su una macchina adatta (Linux, un utente normale può utilizzare docker, Vedere qui dettagli) questi comandi faranno apparire 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 funziona, l'output conterrà le istruzioni per l'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 -

Gli oggetti CSIStorageCapacity non sono pensati per essere letti dagli esseri umani, quindi è necessaria una certa elaborazione. I filtri del modello Golang mostreranno le classi di archiviazione, questo esempio mostrerà il nome, la topologia e la 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 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 singolo oggetto ha il seguente contenuto:

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

Proviamo a creare un'applicazione demo con un unico volume temporaneo per uso generale. 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 aver creato, come mostrato nelle istruzioni sopra, ora abbiamo un pod e un PVC aggiuntivi:

$ 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

Proprietario del PVC - sotto:

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

Informazioni aggiornate previste per 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 un'altra applicazione necessita di più di 26620Mi, lo scheduler non ne terrà conto pmem-csi-pmem-govm-worker1 comunque.

Quali sono le prospettive?

Entrambe le funzionalità sono ancora in fase di sviluppo. Durante l'alpha test sono state aperte diverse applicazioni. I collegamenti alle proposte di miglioramento documentano il lavoro che è necessario svolgere per passare alla fase beta, nonché quali alternative sono già state prese in considerazione e rifiutate:

Fonte: habr.com

Aggiungi un commento