Algunes aplicacions també necessiten emmagatzemar dades, però se senten molt còmodes amb el fet que les dades no es desaran després d'un reinici.
Per exemple, els serveis de memòria cau estan limitats per la memòria RAM, però també poden moure dades que rarament s'utilitzen a un emmagatzematge més lent que la memòria RAM, amb poc impacte en el rendiment general. Altres aplicacions han de ser conscients que hi pot haver algunes entrades de només lectura als fitxers, com ara la configuració o les claus secretes.
Kubernetes ja té diversos tipus , però la seva funcionalitat es limita al que s'implementa als K8.
Efímer va permetre estendre Kubernetes amb controladors CSI per oferir suport per a volums locals lleugers. D'aquesta manera es pot utilitzar : configuracions, secrets, dades d'identificació, variables, etc. Els controladors CSI s'han de modificar per donar suport a aquesta funció de Kubernetes, ja que se suposa que els controladors normalitzats normalitzats no funcionaran, però se suposa que aquests volums es poden utilitzar en qualsevol node seleccionat per al pod.
Això pot ser un problema per als volums que consumeixen recursos d'amfitrió importants o per a l'emmagatzematge que només està disponible en alguns amfitrions. És per això que Kubernetes 1.19 introdueix dues noves funcions de volum de proves alfa que són conceptualment similars als volums EmptyDir:
volums efímers de propòsit general;
Seguiment de la capacitat d'emmagatzematge CSI.
Avantatges del nou enfocament:
L'emmagatzematge pot ser local o connectat mitjançant una xarxa;
els volums poden tenir una mida especificada que l'aplicació no pot superar;
funciona amb qualsevol controlador CSI que admet el subministrament de volums persistents i (per donar suport al seguiment de la capacitat) implementar la trucada
GetCapacity;els volums poden tenir algunes dades inicials segons el controlador i la configuració;
s'admeten totes les operacions estàndard amb un volum (creació d'una instantània, canvi de mida, etc.);
els volums es poden utilitzar amb qualsevol controlador d'aplicació que accepti una especificació de mòdul o volum;
El programador de Kubernetes selecciona els nodes adequats per si mateix, de manera que ja no cal proporcionar i configurar extensions del programador ni modificar els webhooks.
Aplicacions
Per tant, els volums efímers de propòsit general són adequats per als casos d'ús següents:
Memòria persistent com a reemplaçament de la memòria RAM per a memcached
Últimes versions de memcached utilitzant memòria persistent (Intel Optane, etc., aprox. traductor) en lloc de la memòria RAM normal. Quan desplegueu memcached mitjançant un controlador d'aplicació, podeu utilitzar volums efímers de propòsit general per sol·licitar que s'assigni un volum d'una mida determinada des de PMEM mitjançant el controlador CSI, per exemple. .
Emmagatzematge local LVM com a espai de treball
Les aplicacions que funcionen amb dades més grans que la memòria RAM poden requerir emmagatzematge local amb una mida o mètriques de rendiment que els volums EmptyDir habituals de Kubernetes no poden proporcionar. Per exemple, amb aquesta finalitat es va escriure .
Accés de només lectura per a volums de dades
L'assignació d'un volum pot donar lloc a la creació d'un volum complet quan:
restauració ;
creació ;
treball .
Aquests volums es poden muntar en mode de només lectura.
Com funciona això
Volums efímers d'ús general
Una característica clau dels volums efímers de propòsit general és la nova font de volum, EphemeralVolumeSource, que conté tots els camps per crear una sol·licitud de volum (històricament anomenada sol·licitud de volum persistent, PVC). Nou controlador entrat kube-controller-manager mira les beines que creen aquesta font de volum i, a continuació, crea un PVC per a aquestes beines. Per al controlador CSI, aquesta sol·licitud té el mateix aspecte que les altres, de manera que no es necessita cap suport especial aquí.
Mentre existeixin aquests PVC, es poden utilitzar com qualsevol altra petició del volum. En particular, es poden fer referència com a font de dades quan es copia un volum o es crea una instantània des d'un volum. L'objecte de PVC també conté l'estat actual del volum.
Els noms dels PVC creats automàticament estan predefinits: són una combinació del nom del pod i el nom del volum, separats per un guionet. Els noms predefinits faciliten la interacció amb el PVC perquè no cal que el cerquis si coneixes el nom del pod i el nom del volum. L'inconvenient és que és possible que el nom ja estigui en ús, que Kubernetes detecta i, com a resultat, el pod no s'inicia.
Per assegurar-se que el volum s'elimina juntament amb el pod, el controlador fa una sol·licitud al volum del propietari. Quan s'elimina el pod, funciona el mecanisme estàndard de recollida d'escombraries, que elimina tant la sol·licitud com el volum.
El controlador d'emmagatzematge fa coincidir les sol·licituds mitjançant el mecanisme normal de la classe d'emmagatzematge. Tot i que les classes amb enquadernació immediata i tardana (també conegut com WaitForFirstConsumer) són compatibles, per a volums efímers té sentit utilitzar-los WaitForFirstConsumer, aleshores el planificador pot considerar tant l'ús del node com la disponibilitat d'emmagatzematge en seleccionar un node. Aquí apareix una funció nova.
Seguiment de la capacitat d'emmagatzematge
Normalment, el planificador no sap on el controlador CSI crearà el volum. Tampoc el planificador no té cap manera de contactar directament amb el conductor per sol·licitar aquesta informació. Per tant, el planificador sondeja els nodes fins que en troba un en què es pot accedir als volums (enllaç tardà) o deixa l'elecció de la ubicació totalment al controlador (enllaç immediat).
Nou CSIStorageCapacity, que es troba en fase alfa, permet emmagatzemar les dades necessàries a etcd perquè estiguin disponibles per al planificador. A diferència del suport per a volums efímers de propòsit general, quan desplegueu el controlador, heu d'activar el seguiment de la capacitat d'emmagatzematge: external-provisioner hauria de publicar la informació de capacitat rebuda del conductor via normal GetCapacity.
Si el planificador ha de seleccionar un node per a un pod amb un volum no vinculat que utilitza la vinculació tardana i el controlador ha activat aquesta funció durant el desplegament establint la marca CSIDriver.storageCapacity, llavors els nodes que no tenen prou capacitat d'emmagatzematge es descartaran automàticament. Això funciona tant per a volums efímers de propòsit general com per a volums persistents, però no per a volums efímers CSI perquè Kubernetes no pot llegir els seus paràmetres.
Com és habitual, els volums enllaçats immediatament es creen abans de programar els pods i la seva ubicació l'escull el controlador d'emmagatzematge, de manera que quan es configuren external-provisioner De manera predeterminada, les classes d'emmagatzematge amb vinculació immediata es salten, ja que aquestes dades no s'utilitzaran de totes maneres.
Atès que el planificador de kubernetes està obligat a treballar amb informació potencialment no actualitzada, no hi ha cap garantia que la capacitat estigui disponible en tots els casos quan es creï el volum, però les possibilitats que es creï sense reintents augmenten.
NB Podeu obtenir informació més detallada, així com "pràcticar a la parada de gats" de manera segura i, en cas d'una situació completament incomprensible, rebre assistència tècnica qualificada en cursos intensius - se celebrarà del 28 al 30 de setembre, i per a especialistes més avançats 14-16 d'octubre.
Безопасность
Capacitat d'emmagatzematge del CSIS
Els objectes CSIStorageCapacity resideixen en espais de noms; quan es desenvolupen cada controlador CSI al seu propi espai de noms, es recomana restringir els drets RBAC a CSIStorageCapacity en aquest espai, ja que és obvi d'on provenen les dades. Kubernetes no ho comprova de totes maneres, i normalment els controladors es col·loquen al mateix espai de noms, de manera que, en última instància, s'espera que els controladors funcionin i no publiquin dades incorrectes (i aquí és on la meva targeta ha fallat, aprox. traductor basat en una broma amb barba)
Volums efímers d'ús general
Si els usuaris tenen drets per crear un pod (directament o indirectament), també podran crear volums efímers de propòsit general encara que no tinguin drets per crear una sol·licitud al volum. Això es deu al fet que les comprovacions de permís RBAC s'apliquen al controlador que crea el PVC, no a l'usuari. Aquest és el canvi principal a afegir , abans d'activar aquesta funció en clústers on els usuaris no fiables no haurien de tenir drets per crear volums.
Exemple
Separat PMEM-CSI conté tots els canvis necessaris per executar un clúster Kubernetes 1.19 dins de màquines virtuals QEMU amb totes les funcions de l'etapa alfa. El codi del controlador no ha canviat, només ha canviat el desplegament.
En un cotxe adequat (Linux, un usuari normal pot utilitzar , mira detalls) aquestes ordres mostraran el clúster i instal·laran 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
Després que tot funcioni, la sortida contindrà instruccions d'ús:
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 -
Els objectes CSIStorageCapacity no estan destinats a ser llegits per humans, per la qual cosa es requereix algun processament. Els filtres de plantilla de Golang mostraran les classes d'emmagatzematge, aquest exemple mostrarà el nom, la topologia i la capacitat:
$ 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 únic objecte té el contingut següent:
$ 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>
Intentem crear una aplicació de demostració amb un sol volum efímer de propòsit general. Continguts del fitxer 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
Després de crear, tal com es mostra a les instruccions anteriors, ara tenim una beina i un PVC addicionals:
$ 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
Propietari de PVC - sota:
$ 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ó actualitzada esperada 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
Si una altra aplicació necessita més de 26620Mi, el planificador no tindrà en compte pmem-csi-pmem-govm-worker1 en qualsevol cas.
Què serà el següent?
Les dues funcions encara estan en desenvolupament. Es van obrir diverses aplicacions durant les proves alfa. Els enllaços de proposta de millora documenten el treball que cal fer per passar a l'etapa beta, així com quines alternatives ja s'han considerat i rebutjat:
Font: www.habr.com
