Ehi Habr!
Vi ricurdemu chì avemu liberatu un altru estremamente interessante è utile nantu à i mudelli Kubernetes. Tuttu hà cuminciatu cù ""Brendan Burns, è, per via, avemu u travagliu in questu segmentu . Oghje vi invitamu à leghje un articulu da u blog MinIO chì delinea brevemente e tendenze è e specificità di i mudelli di almacenamiento di dati in Kubernetes.
Kubernetes hà cambiatu fundamentalmente i mudelli tradiziunali di sviluppu è di implementazione di l'applicazioni. Avà una squadra pò sviluppà, pruvà è implementà una applicazione in una questione di ghjorni, in parechji ambienti, tutti in cluster Kubernetes. Un tali travagliu cù e generazioni precedenti di tecnulugia di solitu durava settimane, se micca mesi.
Questa accelerazione hè fatta pussibule da l'astrazione furnita da Kubernetes - vale à dì, perchè Kubernetes stessu interagisce cù i dettagli di bassu livellu di e macchine fisiche o virtuali, chì permettenu à l'utilizatori di dichjarà u processatore desideratu, a quantità desiderata di memoria è u numeru di container. casi, frà altri paràmetri. Cù una grande cumunità chì sustene Kubernetes è a so adopzione in continua espansione, Kubernetes hè u capu trà tutte e piattaforme di orchestrazione di cuntainer per un largu margine.
Cume l'usu di Kubernetes cresce, cusì cresce a cunfusione annantu à i so mudelli di almacenamiento..
Cù tutti chì cumpetenu per un pezzu di u pezzu di Kubernetes (vale à dì, l'almacenamiento di dati), quandu si tratta di parlà di almacenamiento di dati, u signale hè affucatu in assai rumore.
Kubernetes incarna un mudellu mudernu per u sviluppu, l'implementazione è a gestione di l'applicazioni. Stu mudellu mudernu decouples l'almacenamiento di dati da a computazione. Per capiscenu cumplettamente u distaccu in u cuntestu di Kubernetes, avete ancu bisognu di capisce ciò chì l'applicazioni stateless è stateless sò, è cumu l'almacenamiento di dati si mette in questu. Hè quì chì l'approcciu di l'API REST utilizatu da S3 hà vantaghji chjaru nantu à l'approcciu POSIX / CSI di altre soluzioni.
In questu articulu, parlemu di i mudelli di almacenamiento di dati in Kubernetes è tocca in particulare u dibattitu trà l'applicazioni stateful è stateless per capisce megliu quale hè a diffarenza trà elli è perchè hè impurtante. U restu di u testu guarderà l'applicazioni è i so mudelli di almacenamiento di dati à a luce di e migliori pratiche per travaglià cù cuntenituri è Kubernetes.
Container senza Stato
I cuntenituri sò per natura ligeri è effimeri. Puderanu esse facilmente fermati, eliminati o implementati à un altru node - tuttu in sicondi. In un grande sistema di orchestrazione di cuntainer, tali operazioni passanu tuttu u tempu, è l'utilizatori ùn anu mancu tali cambiamenti. In ogni casu, i muvimenti sò pussibuli solu s'ellu u cuntinuu ùn hà micca dipendenze nantu à u node nantu à quale si trova. Tali cuntenituri sò dettu di travaglià apatride.
Container Stateful
Se un cuntainer guarda dati nantu à i dispositi attaccati in u locu (o nantu à un dispositivu di bloccu), allora u magazzinu di dati nantu à quale reside duverà esse spustatu in un novu node, cù u cuntinuu stessu, in casu di fallimentu. Questu hè impurtante perchè altrimenti l'applicazione in esecuzione in u cuntinuu ùn serà micca capace di funziunà bè perchè hà bisognu à accede à i dati almacenati in i media lucali. Tali cuntenituri sò dettu di travaglià stateful.
Da un puntu di vista puramente tecnicu, i cuntenituri stateful ponu ancu esse spustati in altri nodi. Questu hè tipicamenti ottinutu utilizendu sistemi di fugliali distribuiti o bluccate l'almacenamiento di rete attaccatu à tutti i nodi chì eseguinu cuntenituri. In questu modu, i cuntenituri accede à volumi per l'almacenamiento di dati persistenti, è l'infurmazione hè guardata nantu à i dischi situati in tutta a reta. Chjameraghju stu metudu "approcciu stateful container", è in u restu di l'articulu u chjameraghju cusì per a fine di uniformità.
In un approcciu tipicu di cuntainer stateful, tutti i pods di l'applicazione sò attaccati à un unicu sistema di fugliale distribuitu - un tipu di almacenamentu spartutu induve residenu tutti i dati di l'applicazione. Mentre alcune variazioni sò pussibuli, questu hè un approcciu di altu livellu.
Avà guardemu perchè l'approcciu di u containeru stateful hè un anti-pattern in un mondu centratu in nuvola.
Disegnu di l'applicazioni native in nuvola
Tradizionalmente, l'applicazioni utilizanu basa di dati per l'almacenamiento strutturatu di l'infurmazioni è i dischi lucali o sistemi di fugliali distribuiti induve tutti i dati non strutturati o ancu semi-strutturati sò stati scaricati. Cume i volumi di dati non strutturati criscenu, i sviluppatori anu capitu chì POSIX era troppu chiacchierone, avia un overhead significativu, è infine hà impeditu u rendiment di l'applicazione quandu si moveva à scale veramente grandi.
Questu hà cuntribuitu principalmente à l'emergenza di un novu standard per l'almacenamiento di dati, vale à dì, l'almacenamiento basatu in nuvola, chì travaglia principarmenti basatu annantu à l'API REST è libera l'applicazione da u mantenimentu oneru di un almacenamentu di dati lucale. In questu casu, l'applicazione entra in modu efficace in modu senza statu (perchè u statu hè in almacenamiento remoto). L'applicazioni muderne sò custruite da zero cun questu fattore in mente. Comu regula, ogni applicazione muderna chì processa dati di un tipu o un altru (logs, metadata, blobs, etc.) hè custruitu secondu un paradigma orientatu à u nuvulu, induve u statu hè trasferitu à un sistema di software dedicatu apposta per u so almacenamiento.
L'approcciu di u containeru stateful forza tuttu stu paradigma à torna esattamente induve era principiatu!
Utilizendu l'interfacce POSIX per almacenà e dati, l'applicazioni operanu cum'è s'elli eranu stateful, è per quessa, partenu da i principii più impurtanti di u disignu cloud-centric, vale à dì, a capacità di varià a dimensione di i fili di u travagliu di l'applicazione secondu l'entrata. input.load, spustà à un novu node appena u node attuale falla, è cusì.
Fighjendu un ochju più vicinu à sta situazione, truvamu chì quandu sceglite un magazzinu di dati, simu una volta è una volta affruntate cù u dilema POSIX vs REST API, MA cù l'aggravation addiziale di i prublemi POSIX per via di a natura distribuita di l'ambienti Kubernetes. In particulare,
- POSIX hè chatty: A semantica POSIX richiede chì ogni operazione sia assuciata cù metadata è descriptori di fugliale chì aiutanu à mantene u statu di l'operazione. Questu risultatu in costi significativi chì ùn anu micca valore reale. L'API d'almacenamiento d'ughjettu, in particulare l'API S3, sbarazzanu di sti requisiti, chì permettenu l'applicazione per u focu è dopu "dimenticà" di a chjama. A risposta di u sistema di almacenamiento indica se l'azzione hè stata successu o micca. Se falla, l'applicazione pò pruvà di novu.
- Restrizzione di a rete: In un sistema distribuitu, hè implicatu chì ci ponu esse parechje applicazioni chì pruvate di scrive dati à u stessu media attaccatu. Dunque, micca solu l'applicazioni cumpetenu cun l'altri per a larghezza di banda di trasferimentu di dati (per mandà dati à i media), ma u sistema di almacenamento stessu cumpeterà per questa larghezza di banda mandendu dati in i dischi fisici. A causa di a locusità di POSIX, u numeru di chjama di rete aumenta parechje volte. Per d 'altra banda, l'API S3 furnisce una distinzione chjara trà e chjama di rete trà quelli chì venenu da u cliente à u servitore è quelli chì si trovanu in u servitore.
- Seguretat: U mudellu di sicurità POSIX hè pensatu per a participazione umana attiva: l'amministratori cunfiguranu livelli d'accessu specifichi per ogni utilizatore o gruppu. Stu paradigma hè difficiule d'adattà à un mondu nuvola-centric. L'applicazioni muderni dependenu di mudelli di sicurezza basati in API, induve i diritti d'accessu sò definiti cum'è un inseme di pulitiche, cunti di serviziu, credenziali temporali, etc.
- Manageability: I cuntenituri stateful anu qualchì sopratuttu di gestione. Parlemu di sincronizà l'accessu parallelu à e dati, assicurendu a coherenza di dati, tuttu questu hè bisognu di cunsiderà attente chì i mudelli d'accessu di dati à utilizà. U software supplementu deve esse installatu, monitoratu è cunfiguratu, per ùn dì micca un sforzu di sviluppu supplementu.
Container Data Storage Interface
Mentre l'Interfaccia di Storage di Container (CSI) hè statu un grande aiutu cù a proliferazione di u livellu di volumi Kubernetes, parzialmente esternalizzandu à i venditori di almacenamentu di terzu, hà ancu cuntribuitu inavvertitamente à a credenza chì l'approcciu di u containeru stateful hè u metudu cunsigliatu per almacenà dati in Kubernetes.
CSI hè statu sviluppatu cum'è un standard per furnisce i blocchi arbitrarii è i sistemi di almacenamentu di file à l'applicazioni legacy quandu si eseguisce in Kubernetes. E, cum'è questu articulu hà dimustratu, l'unica situazione in quale un approcciu di cuntainer stateful (è CSI in a so forma attuale) hè sensu hè quandu l'applicazione stessu hè un sistema legatu in quale ùn hè micca pussibule aghjunghje supportu per l'API di almacenamiento d'ughjettu. .
Hè impurtante di capiscenu chì l'usu di CSI in a so forma attuale, vale à dì, volumi di muntagna quandu travaglià cù l'applicazioni muderne, scontru apprussimatamente i stessi prublemi chì sò ghjunti in sistemi induve l'almacenamiento di dati hè urganizatu in u stilu POSIX.
Un approcciu megliu
In questu casu, hè impurtante di capiscenu chì a maiò parte di l'applicazioni ùn sò micca cuncepiti in modu specificu per u travagliu statutu o senza statu. Stu cumpurtamentu dipende di l'architettura generale di u sistema è di e scelte di design specifichi fatti. Parlemu un pocu di applicazioni stateful.
In principiu, tutti i dati di l'applicazioni ponu esse divisi in parechji tipi:
- Log dati
- Dati di timestamp
- Dati di transazzione
- Metadata
- Imàghjini di u containeru
- Dati Blob (oggettu grande binari).
Tutti sti tipi di dati sò assai supportati nantu à e plataforme di almacenamiento muderni, è ci sò parechje piattaforme native in nuvola adattate per furnisce dati in ognuna di sti formati specifichi. Per esempiu, e dati di transazzione è metadati ponu risiede in una basa di dati moderna di nuvola nativa cum'è CockroachDB, YugaByte, etc. L'imaghjini di u containeru o i dati blob ponu esse almacenati in un registru docker basatu in MinIO. I dati di timestamp ponu esse guardati in una basa di dati di serie temporale cum'è InfluxDB, etc. Ùn andemu micca in dettagliu nantu à ogni tipu di dati è e so applicazioni quì, ma l'idea generale hè di evità u almacenamentu persistente di dati chì si basa nantu à u discu locale.
Inoltre, hè spessu efficace per furnisce una capa di cache temporale chì serve cum'è un magazinu di schedarii tempuranee per l'applicazioni, ma l'applicazioni ùn deve micca dipende di sta capa cum'è a fonte di a verità.
Archiviazione di applicazioni stateful
Mentre chì in a maiò parte di i casi hè utile per mantene l'applicazioni senza statu, quelli applicazioni chì sò pensati per almacenà dati - cum'è basa di dati, magazzini d'ogetti, magazzini di chjave-valore - deve esse stati. Fighjemu perchè queste applicazioni sò implementate in Kubernetes. Pigliemu MinIO cum'è un esempiu, ma principii simili s'applicanu à qualsiasi altru grande sistema di almacenamentu nativu in nuvola.
L'applicazioni native in nuvola sò pensate per prufittà pienamente di a flessibilità inherente à i cuntenituri. Questu significa chì ùn facenu micca ipotesi nantu à l'ambienti in quale saranu implementati. Per esempiu, MinIO usa un mecanismu di codificazione di cancellazione interna per furnisce u sistema abbastanza resilienza per esse operativa ancu se a mità di i dischi fallenu. MinIO gestisce ancu l'integrità è a sicurità di e dati utilizendu l'hashing è a criptografia di u servitore proprietariu.
Per tali applicazioni centrate in nuvola, i volumi persistenti lucali (PV) sò più convenienti cum'è almacenamiento di salvezza. U PV locale furnisce a capacità di almacenà e dati crudi, mentre chì l'applicazioni chì funzionanu sopra à questi PV raccoglie in modu indipendenti l'infurmazioni per scala e dati è gestisce e richieste di dati crescente.
Stu approcciu hè assai più simplice è significativamente più scalabile chì i PV basati in CSI, chì introducenu i so propri strati di gestione di dati è redundancy in u sistema; u puntu hè chì sti strati sò generalmente cunflitti cù l'applicazioni pensate per esse stateful.
Un forte muvimentu versu u disaccoppiamentu di dati da i calculi
In questu articulu, avemu parlatu di cumu l'applicazioni sò riorientate per travaglià senza salvà u statu, o, in altre parolle, l'almacenamiento di dati hè decoupled da l'informatica. In cunclusioni, fighjemu alcuni esempi veri di sta tendenza.
, una piattaforma di analisi di dati prominente, hè tradiziunale statale è implementata in HDFS. In ogni casu, cum'è Spark si move in un mondu centratu in nuvola, a piattaforma hè sempre più usata senza statu cù `s3a`. Spark usa s3a per trasferisce u statu à altri sistemi, mentre chì i cuntenituri Spark stessi operanu interamente senza statu. Altri attori principali di l'impresa in u campu di l'analisi di big data, in particulare, , , Anu ancu movendu à travaglià cù a siparazione di l'almacenamiento di dati è i calculi nantu à elli.
I mudelli simili ponu ancu esse vistu nantu à altre grandi plataforme analitiche, cumprese Presto, Tensorflow to R, Jupyter. Scaricà u statu à i sistemi di almacenamentu in nuvola remoti, diventa assai più faciule per gestisce è scala a vostra applicazione. Inoltre, facilita a portabilità di l'applicazione à una varietà di ambienti.
Source: www.habr.com