Hi ha diverses maneres de configurar l'emmagatzematge de dades per a aplicacions que s'executen en un clúster de Kubernetes. Alguns d'ells ja estan obsolets, d'altres van aparèixer fa poc. En aquest article, analitzarem el concepte de tres opcions per connectar sistemes d'emmagatzematge, inclosa la més recent: connectar-se mitjançant la interfície d'emmagatzematge de contenidors.
Mètode 1: especifiqueu PV al manifest del pod
Un manifest típic que descriu un pod en un clúster de Kubernetes:
Les parts del manifest que descriuen quin volum està connectat i on es destaquen en color.
A la secció volumMounts indiqueu els punts de muntatge (mountPath): en quin directori dins del contenidor es muntarà el volum permanent, així com el nom del volum.
A la secció x enumera tots els volums que s'utilitzen al pod. Especifiqueu el nom de cada volum, així com el tipus (en el nostre cas: awsElasticBlockStore) i els paràmetres de connexió. Els paràmetres que es mostren al manifest depenen del tipus de volum.
El mateix volum es pot muntar simultàniament en diversos contenidors de beines. D'aquesta manera, diferents processos d'aplicació poden accedir a les mateixes dades.
Aquest mètode de connexió es va inventar al principi, quan Kubernetes estava en la seva infància, i avui el mètode està obsolet.
Hi ha diversos problemes en utilitzar-lo:
- tots els volums s'han de crear manualment, Kubernetes no ens pot crear res;
- els paràmetres d'accés per a cada volum són únics i s'han d'especificar als manifests de tots els pods que utilitzen el volum;
- per canviar el sistema d'emmagatzematge (per exemple, passar d'AWS a Google Cloud), heu de canviar la configuració i el tipus de volums muntats a tots els manifests.
Tot això és molt inconvenient, de manera que, en realitat, aquest mètode s'utilitza per connectar només alguns tipus especials de volums: configMap, secret, emptyDir, hostPath:
-
configMap i secret són volums de servei que us permeten crear un volum amb fitxers dels manifests de Kubernetes al contenidor.
-
emptyDir és un volum temporal, creat només durant la vida útil del pod. Convenient d'utilitzar per provar o emmagatzemar dades temporals. Quan s'elimina un pod, també s'elimina el volum emptyDir i es perden totes les dades.
-
hostPath: us permet muntar qualsevol directori al disc local del servidor on s'executa l'aplicació dins del contenidor amb l'aplicació, inclòs /etc/kubernetes. Aquesta és una característica insegura, de manera que les polítiques de seguretat normalment prohibeixen l'ús de volums d'aquest tipus. En cas contrari, l'aplicació d'un atacant podrà muntar el directori HTC Kubernetes dins del seu contenidor i robar tots els certificats del clúster. Normalment, els volums hostPath només poden ser utilitzats per les aplicacions del sistema que s'executen a l'espai de noms kube-system.
es donen a la documentació.
Mètode 2. Connexió a llars SC/PVC/PV
Un mètode de connexió alternatiu és el concepte de classe d'emmagatzematge, PersistentVolumeClaim, PersistentVolume.
Classe d'emmagatzematge emmagatzema els paràmetres de connexió al sistema d'emmagatzematge de dades.
Reclam de volum persistent descriu els requisits per al que necessita l'aplicació.
Volum persistent emmagatzema els paràmetres d'accés i l'estat del volum.
L'essència de la idea: al pod manifest indiquen un volum de tipus PersistentVolumeClaim i indiquen el nom d'aquesta entitat al paràmetre claimName.
El manifest PersistentVolumeClaim descriu els requisits per al volum de dades que requereix l'aplicació. Inclou:
- mida del disc;
- mètode d'accés: ReadWriteOnce o ReadWriteMany;
- enllaç a la classe d'emmagatzematge: en quin sistema d'emmagatzematge de dades volem crear el volum.
El manifest de classe d'emmagatzematge emmagatzema el tipus i els paràmetres de la connexió al sistema d'emmagatzematge. El cubelet els necessita per muntar el volum al seu node.
Els manifests de PersistentVolume indiquen la classe d'emmagatzematge i els paràmetres d'accés per a un volum específic (ID de volum, camí, etc.).
Quan es crea un PVC, Kubernetes mira quina mida de volum i quina classe d'emmagatzematge es requereix, i selecciona un PersistentVolume gratuït.
Si aquests PV no estan disponibles, Kubernetes pot llançar un programa especial: Provisioner (el seu nom s'indica a la classe d'emmagatzematge). Aquest programa es connecta al sistema d'emmagatzematge, crea un volum de la mida requerida, rep un identificador i crea un manifest de PersistentVolume al clúster de Kubernetes, que està associat amb PersistentVolumeClaim.
Tot aquest conjunt d'abstraccions us permet eliminar informació sobre quin sistema d'emmagatzematge està treballant l'aplicació des del nivell de manifest de l'aplicació fins al nivell d'administració.
Tots els paràmetres per connectar-se al sistema d'emmagatzematge de dades es troben a la classe Storage, de la qual són responsables els administradors del clúster. Tot el que heu de fer quan passeu d'AWS a Google Cloud és canviar el nom de la classe d'emmagatzematge a PVC als manifests de l'aplicació. El volum de persistència per a l'emmagatzematge de dades es crearà automàticament al clúster mitjançant el programa Provisioner.
Mètode 3: Interfície d'emmagatzematge de contenidors
Tot el codi que interactua amb diversos sistemes d'emmagatzematge forma part del nucli de Kubernetes. El llançament de correccions d'errors o de noves funcionalitats està lligat a les noves versions; el codi s'ha de canviar per a totes les versions admeses de Kubernetes. Tot això és difícil de mantenir i afegir noves funcionalitats.
Per resoldre el problema, els desenvolupadors de Cloud Foundry, Kubernetes, Mesos i Docker van crear la Interfície d'emmagatzematge de contenidors (CSI): una interfície unificada senzilla que descriu la interacció del sistema de gestió de contenidors i un controlador especial (Controlador CSI) que funciona amb un dispositiu específic. sistema d'emmagatzematge. Tot el codi per a la interacció amb els sistemes d'emmagatzematge es va traslladar del nucli de Kubernetes a un sistema independent.
.
Normalment, el controlador CSI consta de dos components: connector de node i connector de controlador.
Node Plugin s'executa a cada node i s'encarrega de muntar volums i fer-hi operacions. El connector Controller interactua amb el sistema d'emmagatzematge: crea o elimina volums, assigna drets d'accés, etc.
De moment, els controladors antics romanen al nucli de Kubernetes, però ja no es recomana utilitzar-los i es recomana a tothom que instal·li el controlador CSI específicament per al sistema amb el qual treballaran.
La innovació pot espantar els que ja estan acostumats a configurar l'emmagatzematge de dades mitjançant la classe d'emmagatzematge, però de fet no ha passat res terrible. Per als programadors, res no canvia realment: només han treballat amb el nom Classe d'emmagatzematge i ho continuaran fent. Per als administradors, s'ha afegit la instal·lació del gràfic del timó i l'estructura de la configuració ha canviat. Si abans els paràmetres s'introduïen directament a la classe d'emmagatzematge, ara primer s'han d'establir al gràfic del timó i després a la classe d'emmagatzematge. Si ho mireu, no ha passat res dolent.
Prenguem un exemple per veure els avantatges que podeu obtenir canviant a la connexió dels sistemes d'emmagatzematge Ceph mitjançant el controlador CSI.
Quan es treballa amb Ceph, el connector CSI ofereix més opcions per treballar amb sistemes d'emmagatzematge que els controladors integrats.
- Creació dinàmica del disc. Normalment, els discs RBD només s'utilitzen en mode RWO, però CSI per a Ceph els permet utilitzar-los en mode RWX. Diversos pods en diferents nodes poden muntar el mateix disc RDB als seus nodes i treballar amb ells en paral·lel. Per ser justos, no tot és tan brillant: aquest disc només es pot connectar com a dispositiu de bloc, el que significa que haureu d'adaptar l'aplicació per treballar-hi en mode d'accés múltiple.
- Creació d'instantànies. En un clúster de Kubernetes, podeu crear un manifest amb el requisit de crear una instantània. El connector CSI el veurà i farà una instantània del disc. A partir d'això, podeu fer una còpia de seguretat o una còpia de PersistentVolume.
- Augment de la mida del disc sobre l'emmagatzematge i el volum persistent en un clúster de Kubernetes.
- Quotes. Els controladors CephFS integrats a Kubernetes no admeten quotes, però els connectors CSI nous amb l'últim Ceph Nautilus poden habilitar quotes a les particions CephFS.
- Mètriques. El connector CSI pot proporcionar a Prometheus una varietat de mètriques sobre quins volums estan connectats, quines comunicacions s'estan duent a terme, etc.
- Coneixement de la topologia. Us permet especificar als manifests com es distribueix geogràficament el clúster i evitar connectar un sistema d'emmagatzematge situat a Amsterdam amb pods que s'executen a Londres.
Com connectar Ceph a un clúster de Kubernetes mitjançant CSI, vegeu . També us podeu subscriure , que es llançarà el 15 d'octubre.
Autor de l'article: Sergey Bondarev, arquitecte en exercici a Southbridge, administrador certificat de Kubernetes, un dels desenvolupadors de kubespray.
Una mica de Post Scriptum no per publicitat, sinó per benefici...
PS Sergey Bondarev dirigeix dos cursos intensius: actualitzat 28-30 de setembre i avançat 14-16 d'octubre.
Font: www.habr.com