Hola Habr!
Us recordem que n'hem estrenat un altre extremadament interessant i útil sobre els patrons de Kubernetes. Tot va començar amb ""Brendan Burns i, per cert, tenim feina en aquest segment . Avui us convidem a llegir un article del bloc MinIO que descriu breument les tendències i les especificitats dels patrons d'emmagatzematge de dades a Kubernetes.
Kubernetes ha canviat fonamentalment els patrons de desenvolupament i desplegament d'aplicacions tradicionals. Ara un equip pot desenvolupar, provar i desplegar una aplicació en qüestió de dies, en diversos entorns, tot dins de clústers de Kubernetes. Aquest treball amb generacions anteriors de tecnologia sol durar setmanes, si no mesos.
Aquesta acceleració és possible gràcies a l'abstracció proporcionada per Kubernetes, és a dir, perquè el mateix Kubernetes interactua amb els detalls de baix nivell de les màquines físiques o virtuals, permetent als usuaris declarar el processador desitjat, la quantitat de memòria desitjada i el nombre de contenidors. casos, entre altres paràmetres. Amb una comunitat enorme que dóna suport a Kubernetes i la seva adopció en expansió contínua, Kubernetes és el líder entre totes les plataformes d'orquestració de contenidors per un ampli marge.
A mesura que creix l'ús de Kubernetes, també augmenta la confusió sobre els seus patrons d'emmagatzematge..
Amb tothom competint per un tros del pastís de Kubernetes (és a dir, l'emmagatzematge de dades), quan es tracta de parlar d'emmagatzematge de dades, el senyal s'ofega en molt de soroll.
Kubernetes encarna un model modern per al desenvolupament, desplegament i gestió d'aplicacions. Aquest model modern desacobla l'emmagatzematge de dades de la computació. Per entendre completament la separació en el context de Kubernetes, també heu d'entendre quines són les aplicacions amb estat i sense estat, i com s'adapta l'emmagatzematge de dades a això. Aquí és on l'enfocament de l'API REST utilitzat per S3 té avantatges clars sobre l'enfocament POSIX/CSI d'altres solucions.
En aquest article, parlarem dels patrons d'emmagatzematge de dades a Kubernetes i parlarem específicament del debat entre aplicacions amb estat i sense estat per entendre millor quina és la diferència entre elles i per què és important. La resta del text analitzarà les aplicacions i els seus patrons d'emmagatzematge de dades a la llum de les millors pràctiques per treballar amb contenidors i Kubernetes.
Contenidors sense estat
Els contenidors són per naturalesa lleugers i efímers. Es poden aturar, eliminar o desplegar fàcilment a un altre node, tot en segons. En un sistema d'orquestració de contenidors grans, aquestes operacions es produeixen tot el temps i els usuaris ni tan sols noten aquests canvis. Tanmateix, els moviments només són possibles si el contenidor no té cap dependència del node on es troba. Es diu que aquests contenidors funcionen apàtrida.
Contenidors amb estat
Si un contenidor emmagatzema dades en dispositius connectats localment (o en un dispositiu de bloc), el magatzem de dades on resideix s'haurà de moure a un nou node, juntament amb el propi contenidor, en cas d'error. Això és important perquè, en cas contrari, l'aplicació que s'executa al contenidor no podrà funcionar correctament perquè necessita accedir a les dades emmagatzemades en mitjans locals. Es diu que aquests contenidors funcionen amb estat.
Des d'un punt de vista purament tècnic, els contenidors amb estat també es poden traslladar a altres nodes. Això s'aconsegueix normalment mitjançant sistemes de fitxers distribuïts o emmagatzematge de xarxa de blocs connectat a tots els nodes que executen contenidors. D'aquesta manera, els contenidors accedeixen a volums per a l'emmagatzematge de dades persistents i la informació s'emmagatzema en discs situats a tota la xarxa. Anomenaré aquest mètode "enfocament de contenidors amb estat", i a la resta de l'article l'anomenaré així per uniformitat.
En un enfocament típic de contenidors amb estat, tots els pods d'aplicació s'adjunten a un únic sistema de fitxers distribuït, una mena d'emmagatzematge compartit on resideixen totes les dades de l'aplicació. Tot i que algunes variacions són possibles, aquest és un enfocament d'alt nivell.
Vegem ara per què l'enfocament del contenidor amb estat és un antipatró en un món centrat en el núvol.
Disseny d'aplicacions natives del núvol
Tradicionalment, les aplicacions utilitzaven bases de dades per a l'emmagatzematge estructurat d'informació i discs locals o sistemes de fitxers distribuïts on s'abocaven totes les dades no estructurades o fins i tot semiestructurades. A mesura que creixien els volums de dades no estructurades, els desenvolupadors es van adonar que POSIX era massa conversador, tenia una sobrecàrrega important i, finalment, dificultava el rendiment de l'aplicació quan es passava a escales realment grans.
Això va contribuir principalment a l'aparició d'un nou estàndard per a l'emmagatzematge de dades, és a dir, l'emmagatzematge basat en núvol, que funcionava principalment a partir de l'API REST i alliberava l'aplicació del costós manteniment d'un emmagatzematge de dades local. En aquest cas, l'aplicació passa efectivament al mode sense estat (ja que l'estat es troba a l'emmagatzematge remot). Les aplicacions modernes es creen des de zero tenint en compte aquest factor. Per regla general, qualsevol aplicació moderna que processi dades d'un tipus o altre (logs, metadades, blobs, etc.) es construeix seguint un paradigma orientat al núvol, on l'estat es transfereix a un sistema de programari especialment dedicat al seu emmagatzematge.
L'enfocament del contenidor amb estat obliga tot aquest paradigma a tornar exactament on va començar!
Mitjançant l'ús d'interfícies POSIX per emmagatzemar dades, les aplicacions funcionen com si tinguessin estat, i per això s'allunyen dels principis més importants del disseny centrat en el núvol, és a dir, la capacitat de variar la mida dels fils de treball de l'aplicació en funció de l'entrada. input.load, moure's a un nou node tan bon punt falla el node actual, i així successivament.
Si fem una ullada a aquesta situació, ens trobem que a l'hora d'escollir un magatzem de dades, ens trobem una vegada i una altra amb el dilema de l'API POSIX vs. REST, PERÒ amb l'agreujament addicional dels problemes POSIX a causa de la naturalesa distribuïda dels entorns Kubernetes. En particular,
- POSIX és conversador: La semàntica POSIX requereix que cada operació estigui associada amb metadades i descriptors de fitxers que ajudin a mantenir l'estat de l'operació. Això es tradueix en costos importants que no tenen valor real. Les API d'emmagatzematge d'objectes, especialment l'API S3, eliminen aquests requisits, permetent que l'aplicació s'activi i després "oblidi" de la trucada. La resposta del sistema d'emmagatzematge indica si l'acció va tenir èxit o no. Si falla, l'aplicació pot tornar-ho a provar.
- Restriccions de xarxa: En un sistema distribuït, s'implica que hi pot haver moltes aplicacions que intentin escriure dades al mateix suport adjunt. Per tant, les aplicacions no només competiran entre elles per l'ample de banda de transferència de dades (per enviar dades als mitjans), sinó que el propi sistema d'emmagatzematge competirà per aquesta amplada de banda enviant dades a través de discs físics. A causa de la locuacitat de POSIX, el nombre de trucades de xarxa augmenta diverses vegades. D'altra banda, l'API S3 ofereix una clara distinció entre les trucades de xarxa entre les que s'originen del client al servidor i les que es produeixen dins del servidor.
- Безопасность: El model de seguretat POSIX està dissenyat per a la participació humana activa: els administradors configuren nivells d'accés específics per a cada usuari o grup. Aquest paradigma és difícil d'adaptar a un món centrat en el núvol. Les aplicacions modernes depenen de models de seguretat basats en API, on els drets d'accés es defineixen com un conjunt de polítiques, s'assignen comptes de servei, credencials temporals, etc.
- Gestionabilitat: Els contenidors amb estat tenen una mica de sobrecàrrega de gestió. Estem parlant de sincronitzar l'accés paral·lel a les dades, garantint la coherència de les dades, tot això requereix una consideració acurada de quins patrons d'accés a les dades utilitzar. S'ha d'instal·lar, supervisar i configurar programari addicional, sense oblidar l'esforç de desenvolupament addicional.
Interfície d'emmagatzematge de dades del contenidor
Tot i que la interfície d'emmagatzematge de contenidors (CSI) ha estat de gran ajuda amb la proliferació de la capa de volum de Kubernetes, subcontractant-la parcialment a proveïdors d'emmagatzematge de tercers, també ha contribuït inadvertidament a la creença que l'enfocament del contenidor amb estat és el mètode recomanat per emmagatzemar dades a Kubernetes.
CSI es va desenvolupar com a estàndard per proporcionar sistemes d'emmagatzematge de fitxers i blocs arbitraris a aplicacions heretades quan s'executen a Kubernetes. I, com ha demostrat aquest article, l'única situació en què un enfocament de contenidors amb estat (i CSI en la seva forma actual) té sentit és quan l'aplicació en si és un sistema heretat en el qual no és possible afegir suport per a l'API d'emmagatzematge d'objectes. .
És important entendre que utilitzant CSI en la seva forma actual, és a dir, muntant volums quan es treballa amb aplicacions modernes, ens trobarem aproximadament amb els mateixos problemes que van sorgir en sistemes on l'emmagatzematge de dades està organitzat a l'estil POSIX.
Un millor enfocament
En aquest cas, és important entendre que la majoria de les aplicacions no estan dissenyades de manera inherent específicament per al treball amb estat o sense estat. Aquest comportament depèn de l'arquitectura general del sistema i de les eleccions de disseny específiques fetes. Parlem una mica de les aplicacions amb estat.
En principi, totes les dades de l'aplicació es poden dividir en diversos tipus amplis:
- Dades de registre
- Dades de marca de temps
- Dades de transacció
- Metadades
- Imatges de contenidors
- Dades blob (objecte binari gran).
Tots aquests tipus de dades s'admeten molt bé a les plataformes d'emmagatzematge modernes i hi ha diverses plataformes natives del núvol adaptades per oferir dades en cadascun d'aquests formats específics. Per exemple, les dades i les metadades de transaccions poden residir en una base de dades moderna nativa del núvol com ara CockroachDB, YugaByte, etc. Les imatges del contenidor o les dades de blob es poden emmagatzemar en un registre docker basat en MinIO. Les dades de marca de temps es poden emmagatzemar en una base de dades de sèries temporals com InfluxDB, etc. No entrarem en detalls sobre cada tipus de dades i les seves aplicacions associades aquí, però la idea general és evitar l'emmagatzematge de dades persistent que es basa en el muntatge del disc local.
A més, sovint és efectiu proporcionar una capa de memòria cau temporal que serveixi com a magatzem de fitxers temporal per a les aplicacions, però les aplicacions no haurien de dependre d'aquesta capa com a font de veritat.
Emmagatzematge d'aplicacions amb estat
Tot i que en la majoria dels casos és útil mantenir les aplicacions sense estat, les aplicacions dissenyades per emmagatzemar dades, com ara bases de dades, magatzems d'objectes, magatzems de clau-valor, han de tenir estat. Vegem per què aquestes aplicacions es despleguen a Kubernetes. Prenguem MinIO com a exemple, però principis similars s'apliquen a qualsevol altre gran sistema d'emmagatzematge natiu del núvol.
Les aplicacions natives del núvol estan dissenyades per aprofitar al màxim la flexibilitat inherent als contenidors. Això vol dir que no fan suposicions sobre l'entorn en què es desplegaran. Per exemple, MinIO utilitza un mecanisme de codificació d'esborrat intern per proporcionar al sistema prou resistència per continuar operatiu encara que la meitat dels discs fallin. MinIO també gestiona la integritat i la seguretat de les dades mitjançant hash i xifratge propietaris del costat del servidor.
Per a aquestes aplicacions centrades en el núvol, els volums persistents locals (PV) són més convenients com a emmagatzematge de còpia de seguretat. El PV local ofereix la possibilitat d'emmagatzemar dades en brut, mentre que les aplicacions que s'executen a sobre d'aquests PV recopilen informació de manera independent per escalar les dades i gestionar les demandes creixents de dades.
Aquest enfocament és molt més senzill i significativament més escalable que els PV basats en CSI, que introdueixen les seves pròpies capes de gestió de dades i redundància al sistema; la qüestió és que aquestes capes solen entrar en conflicte amb aplicacions dissenyades per tenir estat.
Un fort moviment cap a la desacoblament de dades dels càlculs
En aquest article, hem parlat de com es reorienten les aplicacions perquè funcionin sense desar l'estat, o, en altres paraules, l'emmagatzematge de dades es desacobla de la computació. En conclusió, anem a veure alguns exemples reals d'aquesta tendència.
, una plataforma d'anàlisi de dades destacada, tradicionalment ha estat amb estat i s'ha desplegat a HDFS. No obstant això, a mesura que Spark es trasllada a un món centrat en el núvol, la plataforma s'utilitza cada cop més sense estat mitjançant `s3a`. Spark utilitza s3a per transferir l'estat a altres sistemes, mentre que els propis contenidors Spark funcionen completament sense estat. Altres actors empresarials importants en el camp de l'anàlisi de big data, en particular, , , També estan passant a treballar amb la separació de l'emmagatzematge de dades i els càlculs sobre ells.
També es poden veure patrons similars en altres grans plataformes analítiques, com Presto, Tensorflow to R, Jupyter. En baixar l'estat als sistemes d'emmagatzematge al núvol remots, és molt més fàcil gestionar i escalar la vostra aplicació. A més, facilita la portabilitat de l'aplicació a una varietat d'entorns.
Font: www.habr.com
