Alcune applicazioni devono anche 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 che vengono utilizzati raramente in uno storage che funziona più lentamente della RAM, con un impatto minimo sulle prestazioni complessive. Altre applicazioni devono sapere che nei file possono esserci alcuni input di sola lettura, ad esempio impostazioni o chiavi segrete.
In Kubernetes ci sono già diversi tipi , ma le loro funzionalità sono limitate a quanto implementato in K8s.
I volumi hanno permesso di estendere Kubernetes tramite driver CSI per supportare volumi locali leggeri. In questo modo è possibile applicare : impostazioni, segreti, dati per identificazione, variabili e così via. I driver CSI devono essere adattati per supportare questa funzione di Kubernetes, poiché si presume che i driver standardizzati normali non funzioneranno — ma si presume che tali volumi possano essere utilizzati su qualsiasi nodo scelto per il pod.
Questo può diventare un problema per i volumi con un significativo consumo di risorse del nodo o per lo storage disponibile solo su alcuni nodi. Pertanto, in Kubernetes 1.19 sono state introdotte due nuove funzioni per i volumi in fase alfa di test, concettualmente simili ai volumi EmptyDir:
volumi efimeri di uso generale;
monitoraggio della capacità dello storage CSI.
I vantaggi del nuovo approccio:
lo storage può essere locale o montato tramite 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 impostazioni;
tutte le operazioni standard sui volumi (creazione di snapshot, ridimensionamento, ecc.) sono supportate;
i volumi possono essere utilizzati con qualsiasi controller di applicazioni che accetta la specifica del modulo o del volume;
Il pianificatore Kubernetes sceglie autonomamente i nodi appropriati, quindi non è più necessario gestire e configurare le estensioni del pianificatore o modificare i webhook.
Opzioni di utilizzo
Pertanto, i volumi efimeri di uso generale sono adatti per le seguenti opzioni di utilizzo:
Memoria permanente come sostituto della memoria volatile per memcached
Ultime versioni di memcached per l'uso della memoria permanente (Intel Optane, ecc., nota del traduttore) invece della memoria volatile normale. Quando si distribuisce memcached tramite un controller delle applicazioni, è possibile utilizzare volumi efimeri di uso generale per fare richiesta dell'assegnazione di un volume di dimensione specificata da PMEM utilizzando il driver CSI, ad esempio .
Archiviazione locale LVM come spazio di lavoro
Le applicazioni che lavorano con dati le cui dimensioni superano la memoria volatile possono richiedere archiviazione locale con dimensioni o metriche di prestazione che i normali volumi EmptyDir di Kubernetes non possono fornire. Ad esempio, per questo scopo è stato scritto .
Accesso di sola lettura per i volumi di dati
L'assegnazione di un volume può portare alla creazione di un volume riempito in caso di:
recupero ;
creazione ;
operazione .
Questi volumi possono essere montati in modalità di sola lettura.
Come funziona
Volumi efimeri di uso generale
Una caratteristica chiave dei volumi efimeri di uso generale è la nuova fonte di volume, EphemeralVolumeSource, contenente tutti i campi per creare una richiesta per il volume (storicamente chiamata richiesta di volume permanente, PVC). Un nuovo controller in kube-controller-manager esamina i pod che creano tale fonte di volume e poi crea PVC per questi pod. Per il driver CSI, questa richiesta sembra come le altre, quindi non è necessaria un particolare supporto qui.
Finché esistono tali PVC, possono essere utilizzati come qualsiasi altra richiesta di volume. In particolare, possono essere utilizzati come fonte di dati durante la copia di un volume o la creazione di uno snapshot da un volume. L'oggetto PVC contiene anche lo stato attuale del volume.
I nomi dei PVC creati automaticamente sono predefiniti: è una combinazione del nome del pod e del nome del volume, separati da un trattino. La predeterminazione dei nomi semplifica l'interazione con i PVC, poiché non è necessario cercarlo se si conoscono il nome del pod e il nome del volume. Lo svantaggio è che il nome potrebbe già essere in uso, il che viene rilevato da Kubernetes e di conseguenza l'avvio del pod viene bloccato.
Per essere certi che il volume venga eliminato insieme al pod, il controller rende il pod proprietario della richiesta sul volume. Quando il pod viene eliminato, viene attivato il meccanismo standard di raccolta dei rifiuti, che elimina sia la richiesta che il volume.
Le richieste vengono associate a un driver di archiviazione tramite un meccanismo standard di classe di archiviazione. Anche se vengono supportate le classi con collegamento immediato e tardivo (ossia WaitForFirstConsumer), ha senso utilizzare WaitForFirstConsumer, in modo che il pianificatore possa tenere conto sia dell'uso del nodo sia della disponibilità dell'archiviazione nella scelta del nodo. Qui emerge anche una nuova funzione.
Monitoraggio della capacità di archiviazione
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 quello in cui i volumi possono essere disponibili (collegamento tardivo) o lascia completamente la scelta del posto al driver (collegamento immediato).
Nuovo CSIStorageCapacity, in fase alpha, consente di memorizzare i dati necessari in etcd, in modo che siano disponibili per il pianificatore. A differenza del supporto per volumi efimeri a scopo generale, durante il deployment del driver è necessario abilitare il monitoraggio della capacità di archiviazione: external-provisioner deve pubblicare le informazioni sulla capacità ottenute dal driver tramite un normale GetCapacity.
Se il pianificatore deve scegliere un nodo per un pod con un volume non collegato, utilizzando il collegamento tardivo, e il driver ha attivato questa funzione durante il deployment impostando il flag CSIDriver.storageCapacity, verranno automaticamente esclusi i nodi che non hanno una capacità di archiviazione sufficiente. Questo funziona sia per i volumi efimeri a scopo generale che per i volumi permanenti, ma non per i volumi efimeri CSI, poiché i loro parametri non possono essere letti da Kubernetes.
Come di consueto, i volumi con collegamento immediato vengono creati prima della pianificazione dei pod e il loro posizionamento è scelto dal driver di archiviazione, quindi durante la configurazione external-provisioner di default vengono tralasciate le classi di archiviazione con collegamento immediato, poiché questi dati non verranno comunque utilizzati.
Poiché lo scheduler di Kubernetes è costretto a lavorare con informazioni potenzialmente obsolete, non ci sono garanzie che la capacità sarà disponibile in qualsiasi momento venga creato il volume, tuttavia, le possibilità che venga creato senza ulteriori tentativi aumentano.
N.B. Potrai ottenere informazioni più dettagliate, e anche 'fare pratica sul campo' in sicurezza, e in caso di situazioni particolarmente difficili, ricevere assistenza qualificata dal supporto tecnico durante i workshop — si terranno dal 28 al 30 settembre, e per specialisti più avanzati 14–16 ottobre.
Sicurezza
CSIStorageCapacity
Gli oggetti CSIStorageCapacity sono all'interno dei namespace, durante il dispiegamento di ogni driver CSI nel proprio namespace è consigliabile limitare i diritti RBAC per CSIStorageCapacity in questo namespace, poiché è evidente da dove provengono i dati. In ogni caso, Kubernetes non verifica questo, e di solito i driver vengono installati in uno stesso namespace, quindi ci si aspetta che i driver funzionino e non pubblicano dati errati (e qui la mia mappa ha fatto il suo dovere, nota del traduttore ispirata da una barzelletta classica)
Volumi efimeri di uso generale
Se gli utenti hanno diritti per creare un pod (direttamente o indirettamente) — saranno in grado di creare volumi efimeri di uso generale anche se non hanno diritti per creare una richiesta di volume. Questo perché le verifiche dei diritti RBAC si applicano al controller che crea il PVC e non all'utente. Questa è la modifica principale da aggiungere , prima di attivare questa funzione nei cluster, se gli utenti non affidabili non devono avere diritti per creare volumi.
Esempio
Un in PMEM-CSI contiene tutte le modifiche necessarie per l'esecuzione di un cluster Kubernetes 1.19 all'interno di macchine virtuali QEMU con tutte le funzionalità in alpha. Il codice del driver non è stato modificato, è stata solo cambiata la distribuzione.
Su una macchina adatta (Linux, un utente normale può utilizzare , vedi 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 è 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 effettuato l'accesso. In alternativa, utilizza direttamente kubectl con la
seguente variabile d'ambiente:
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 a essere letti dagli esseri umani, quindi è necessaria una certa elaborazione. Utilizzando i filtri del modello in Golang verranno mostrati i tipi di archiviazione, 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 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 oggetto separato ha il seguente contenuto:
$ kubectl describe csistoragecapacities/csisc-6cw8j
Nome: csisc-sqdnt
Namespace: default
Etichette:
Annotazioni:
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 di Riferimento: /apis/storage.k8s.io/v1alpha1/namespaces/default/csistoragecapacities/csisc-sqdnt
UID: da36215b-3b9d-404a-a4c7-3f1c3502ab13
Topologia del Nodo:
Etichette di corrispondenza:
pmem-csi.intel.com/node: pmem-csi-pmem-govm-worker1
Nome della Classe di Archiviazione: pmem-csi-sc-late-binding
Eventi:
Proviamo a creare un'applicazione dimostrativa con un singolo volume effimero di uso generale. 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 mostrato nelle istruzioni sopra, abbiamo un pod e un PVC aggiuntivi:
$ kubectl get pods/my-csi-app-inline-volume -o wide
NOME PRONTO STATO RICARICAMENTI ETÀ IP NODO NODO NOMINATO GATES DI PRONTO
my-csi-app-inline-volume 1/1 In Esecuzione 0 6m58s 10.36.0.2 pmem-csi-pmem-govm-worker1
$ kubectl get pvc/my-csi-app-inline-volume-my-csi-volume
NOME STATO VOLUME CAPACITÀ MODI DI ACCESSO STORAGECLASS ETÀ
my-csi-app-inline-volume-my-csi-volume Legato 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
...
È stata aggiornata come previsto l'informazione 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 avrà bisogno di più di 26620Mi, il pianificatore non lo prenderà in considerazione pmem-csi-pmem-govm-worker1 in ogni caso.
Cosa succede dopo?
Entrambe le funzionalità sono ancora in fase di sviluppo. Sono state aperte diverse richieste durante il test alpha. Sono in corso documentazioni sui collegamenti con suggerimenti per miglioramenti, riguardo al lavoro necessario per passare alla fase beta, e quali alternative siano già state esaminate e scartate:
Fonte: habr.com
