ProHoster > Bloc > Administració > Volums efímers amb seguiment de la capacitat d'emmagatzematge: EmptyDir en esteroides
Volums efímers amb seguiment de la capacitat d'emmagatzematge: EmptyDir en esteroides
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 volums efímers, però la seva funcionalitat es limita al que s'implementa als K8.
Efímer Volums CSI va permetre estendre Kubernetes amb controladors CSI per oferir suport per a volums locals lleugers. D'aquesta manera es pot utilitzar estructures arbitràries: 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 suport afegit 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. PMEM-CSI.
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 TopoLVM.
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:
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 APICSIStorageCapacity, 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 - Base Kubernetes se celebrarà del 28 al 30 de setembre, i per a especialistes més avançats Kubernetes Mega 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 al teu compte, abans d'activar aquesta funció en clústers on els usuaris no fiables no haurien de tenir drets per crear volums.
Exemple
Separat branca 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 una màquina adequada (Linux, un usuari normal pot utilitzar estibador, mira aquí 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:
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
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: