Hej Habr!
Podsjećamo vas da smo objavili još jedan iznimno zanimljiv i koristan članak o Kubernetes obrascima. Sve je počelo s ""Brendan Burns, i, usput rečeno, imamo posla u ovom segmentu Danas vas pozivamo da pročitate članak s MinIO bloga koji ukratko opisuje trendove i specifičnosti obrazaca pohrane podataka u Kubernetesu.
Kubernetes je temeljno promijenio tradicionalne obrasce razvoja i implementacije aplikacija. Timovi sada mogu razviti, testirati i implementirati aplikaciju u samo nekoliko dana - u više okruženja, sve unutar Kubernetes klastera. Ova vrsta posla, s prethodnim generacijama tehnologija, obično je trajala tjednima, ako ne i mjesecima.
Ovo ubrzanje omogućeno je apstrakcijom koju pruža Kubernetes - odnosno činjenicom da sam Kubernetes obrađuje detalje niske razine fizičkih ili virtualnih strojeva, omogućujući korisnicima da, između ostalih parametara, odrede željeni procesor, potrebnu memoriju i broj instanci kontejnera. Sa svojom ogromnom zajednicom koja ga podržava i sve većim usvajanjem, Kubernetes je daleko vodeći među platformama za orkestraciju kontejnera.
Kako raste prihvaćanje Kubernetesa, raste i zbunjenost oko njegovih obrazaca pohrane..
S obzirom na to da se svi natječu za dio Kubernetesovog kolača (odnosno za pohranu podataka), kada je u pitanju pohrana podataka, signal je nadglasan velikom količinom šuma.
Kubernetes utjelovljuje moderni model za razvoj, implementaciju i upravljanje aplikacijama. Ovaj moderni model odvaja pohranu od računalstva. Da bi se u potpunosti razumjelo ovo odvajanje u kontekstu Kubernetesa, potrebno je razumjeti i koncepte aplikacija sa stanjem i aplikacija bez stanja te kako se pohrana uklapa u njih. Ovdje S3-ov REST API pristup nudi jasne prednosti u odnosu na POSIX/CSI pristup tipičan za druga rješenja.
U ovom ćemo članku raspravljati o obrascima pohrane podataka u Kubernetesu i posebno se pozabaviti raspravom između aplikacija sa stanjem i aplikacija bez stanja kako bismo u potpunosti razumjeli razlike i zašto su važne. Ostatak članka ispitat će aplikacije i njihove obrasce pohrane u svjetlu najboljih praksi kontejnera i Kubernetesa.
Kontejneri bez stanja
Kontejneri su inherentno lagani i kratkotrajni. Mogu se lako zaustaviti, izbrisati ili rasporediti na drugi čvor - sve u nekoliko sekundi. U velikom sustavu orkestracije kontejnera, takve se operacije odvijaju kontinuirano, a korisnici nisu svjesni promjena. Međutim, premještanje je moguće samo ako kontejner nema ovisnosti o čvoru na kojem se nalazi. Za takve se kontejnere kaže da rade. bez državljanstva.
Kontejneri s potpunim stanjem
Ako kontejner pohranjuje podatke na lokalno priključenim uređajima (ili na blok uređaju), spremište podataka na kojem se nalazi mora se premjestiti na novi čvor zajedno sa samim kontejnerom u slučaju kvara. To je važno jer u suprotnom aplikacija koja se izvodi u kontejneru neće moći ispravno funkcionirati jer treba pristupiti podacima pohranjenim na lokalnoj pohrani. Za takve kontejnere kaže se da se izvode sa stanjem.
S čisto tehničke perspektive, spremnici sa stanjem mogu se premjestiti i na različite čvorove. To se obično postiže korištenjem distribuiranih datotečnih sustava ili mrežno povezane blokovne pohrane povezane sa svim čvorovima koji pokreću spremnike. Na taj način spremnici imaju pristup trajnim volumenima pohrane, a informacije se pohranjuju na diskovima koji se nalaze diljem mreže. Ovu metodu nazvat ću "pristup kontejnera s potpunim stanjem", a u ostatku članka ću ga tako nazivati radi dosljednosti.
U tipičnom pristupu kontejnera sa stanjem, svi podovi aplikacije pridruženi su jednom distribuiranom datotečnom sustavu, stvarajući vrstu dijeljene pohrane u kojoj se nalaze svi podaci aplikacije. Iako su moguće neke varijacije, ovo je pristup visoke razine.
Sada pogledajmo zašto je pristup kontejnera sa stanjem anti-uzorak u svijetu zasnovanom na oblaku.
Dizajn aplikacija usmjerenih na oblak
Tradicionalno, aplikacije su koristile baze podataka za strukturiranu pohranu i lokalne diskove ili distribuirane datotečne sustave za pohranu svih nestrukturiranih ili čak polustrukturiranih podataka. Kako je količina nestrukturiranih podataka rasla, programeri su shvatili da je POSIX previše opširan, da uzrokuje značajno opterećenje i u konačnici ometa performanse aplikacija u doista velikim razmjerima.
To je uvelike pridonijelo pojavi novog standarda pohrane podataka: cloud-native pohrane, koja prvenstveno radi na REST API-ju i oslobađa aplikacije tereta održavanja lokalne pohrane podataka. U tom slučaju, aplikacija učinkovito prelazi u način rada bez stanja (budući da se stanje pohranjuje na daljinu). Moderne aplikacije grade se od temelja imajući na umu ovaj faktor. U pravilu, svaka moderna aplikacija koja obrađuje bilo koju vrstu podataka (logove, metapodatke, blobove itd.) gradi se korištenjem cloud-native paradigme, gdje se stanje migrira u namjenski softverski sustav.
Pristup kontejnera s potpunim stanjem vraća cijelu ovu paradigmu na početak!
Korištenjem POSIX sučelja za pohranu podataka, aplikacije se ponašaju kao da su stateful i time napuštaju najvažnija načela cloud-native dizajna, kao što je mogućnost promjene veličine radnih niti aplikacije na temelju dolaznog opterećenja, prelaska na novi čvor čim trenutni čvor zakaže i tako dalje.
Detaljnije promatrajući ovu situaciju, otkrivamo da se pri odabiru pohrane podataka iznova i iznova suočavamo s dilemom "POSIX vs. REST API", ALI s dodatnim pogoršanjem POSIX problema zbog distribuirane prirode Kubernetes okruženja. Konkretno,
- POSIX je pričljivPOSIX semantika zahtijeva da svaka operacija bude povezana s metapodacima i deskriptorima datoteka koji pomažu u održavanju stanja operacije. To uvodi značajno opterećenje koje nema stvarnu vrijednost. API-ji za pohranu objekata, posebno S3 API, eliminirali su te zahtjeve, omogućujući aplikaciji da se izvrši, a zatim "zaboravi" poziv. Odgovor sustava za pohranu pokazuje je li akcija bila uspješna ili ne. Ako nije uspješna, aplikacija može ponovno pokušati.
- Mrežna ograničenjaU distribuiranom sustavu podrazumijeva se da može postojati više aplikacija koje pokušavaju pisati podatke na isti priključeni uređaj za pohranu. Stoga se ne samo da će se aplikacije međusobno natjecati za propusnost prijenosa podataka (za slanje podataka na uređaj za pohranu), već će se i sam sustav za pohranu natjecati za tu propusnost distribuirajući podatke po fizičkim diskovima. Zbog detaljnosti POSIX-a, broj mrežnih poziva se višestruko povećava. S druge strane, S3 API osigurava jasno razlikovanje između mrežnih poziva koji dolaze od klijenta prema poslužitelju i onih koji se odvijaju unutar poslužitelja.
- sigurnostiPOSIX sigurnosni model oslanja se na aktivnu ljudsku intervenciju: administratori konfiguriraju određene razine pristupa za svakog korisnika ili grupu. Ovu paradigmu je teško prilagoditi svijetu temeljenom na oblaku. Moderne aplikacije oslanjaju se na sigurnosne modele temeljene na API-ju, gdje su prava pristupa definirana kao skup pravila, servisnih računa, privremenih vjerodajnica i tako dalje.
- upravljivostSpremnici s praćenjem stanja dolaze s određenim režijskim troškovima upravljanja. Sinkronizacija istodobnog pristupa podacima i osiguravanje konzistentnosti podataka zahtijevaju pažljivo razmatranje obrazaca pristupa podacima. Dodatni softver mora se instalirati, upravljati i konfigurirati, a da ne spominjemo dodatni napor razvoja.
Sučelje spremnika za pohranu podataka
Iako je Container Storage Interface (CSI) bio od velike pomoći u usvajanju Kubernetesovog sloja volumena, dijelom i prepuštanjem istog trećim stranama koje nude pohranu podataka, nenamjerno je pridonio uvjerenju da je pristup kontejnera sa stanjem preporučena metoda pohrane podataka u Kubernetes.
CSI je razvijen kao standard za pružanje proizvoljnih sustava za pohranu blokova i datoteka naslijeđenim aplikacijama koje se izvode na Kubernetes platformi. I, kao što je prikazano u ovom članku, jedina situacija u kojoj pristup kontejnera sa stanjem (i CSI u svom trenutnom obliku) ima smisla jest kada je sama aplikacija naslijeđeni sustav koji ne može podržavati API-je za pohranu objekata.
Važno je razumjeti da ćemo pri korištenju CSI-ja u njegovom trenutnom obliku, odnosno montiranju volumena pri radu s modernim aplikacijama, naići na približno iste probleme koji su se pojavili u sustavima gdje je pohrana podataka organizirana u POSIX stilu.
Kvalitativniji pristup
U ovom slučaju, važno je razumjeti da većina aplikacija nije dizajnirana za rad ni sa stanjem ni bez stanja. Ovo ponašanje ovisi o ukupnoj arhitekturi sustava i specifičnim dizajnerskim izborima. Razgovarajmo malo o aplikacijama sa stanjem.
U načelu, svi podaci aplikacije mogu se podijeliti u nekoliko širokih tipova:
- Podaci zapisnika
- Podaci vremenske oznake
- Podaci o transakcijama
- metapodataka
- Slike kontejnera
- Blob podaci (veliki binarni objekti)
Sve ove vrste podataka vrlo dobro podržavaju moderne platforme za pohranu podataka, a postoji nekoliko cloud-native platformi dizajniranih za isporuku podataka u svakom od ovih specifičnih formata. Na primjer, podaci o transakcijama i metapodaci mogu se nalaziti u modernoj cloud-native bazi podataka kao što su CockroachDB, YugaByte i druge. Slike spremnika ili blob podaci mogu se pohraniti u Docker registru na temelju MinIO-a. Podaci vremenskih oznaka mogu se pohraniti u bazu podataka vremenskih serija kao što su InfluxDB i druge. Ovdje nećemo ulaziti u detalje svake vrste podataka i odgovarajućih aplikacija, ali opća je ideja izbjegavati trajnu pohranu podataka na temelju lokalnih montiranja diska.
Osim toga, često je učinkovito osigurati privremeni sloj predmemorije koji služi kao vrsta privremenog spremišta datoteka za aplikacije, ali aplikacije ne bi trebale ovisiti o ovom sloju kao izvoru istine.
Pohrana za aplikacije s pouzdanim stanjem
Iako je u većini slučajeva korisno pokretati aplikacije bez stanja, aplikacije dizajnirane za pohranu podataka - poput baza podataka, pohrane objekata i pohrane ključ-vrijednost - trebale bi biti s stanjem. Istražimo zašto se te aplikacije implementiraju na Kubernetes. Kao primjer ćemo koristiti MinIO, ali slični principi vrijede i za bilo koji drugi veliki sustav za pohranu u oblaku.
Aplikacije u oblaku dizajnirane su kako bi iskoristile inherentnu fleksibilnost kontejnera. To znači da ne donose nikakve pretpostavke o okruženju u kojem će se implementirati. Na primjer, MinIO koristi interni mehanizam kodiranja za brisanje, pružajući sustavu dovoljnu otpornost da ostane operativan čak i ako polovica njegovih diskova zakaže. MinIO također upravlja integritetom i sigurnošću podataka koristeći vlastito hashiranje i šifriranje na strani poslužitelja.
Za takve cloud-native aplikacije, lokalni trajni volumeni (PV) su najprikladnija pohrana sigurnosnih kopija. Lokalni PV omogućuje pohranu sirovih podataka, dok aplikacije koje se izvode na tim PV-ovima neovisno prikupljaju informacije za skaliranje podataka i upravljanje rastućim zahtjevima za podacima.
Ovaj pristup je puno jednostavniji i znatno se bolje skalira od PV-ova temeljenih na CSI-ju, koji u sustav uvode vlastite slojeve upravljanja podacima i redundancije; problem je što se ti slojevi obično sukobljavaju sa aplikacijama koje održavaju stanje.
Samouvjeren potez prema odvajanju podataka od računanja
U ovom smo članku raspravljali o tome kako se aplikacije prebacuju prema radu bez zadržavanja stanja, odnosno, drugim riječima, odvajanju pohrane podataka od izračuna. Zaključno ćemo pogledati neke primjere ovog trenda iz stvarnog svijeta.
Spark, poznata platforma za analizu podataka, tradicionalno je bila stateful i implementirana na HDFS-u. Međutim, kako se Spark kreće prema cloud-native svijetu, sve se više koristi bez statusa pomoću s3a. Spark koristi s3a za komunikaciju stanja s drugim sustavima, dok su sami Spark kontejneri potpuno bez statusa. Drugi veliki poslovni igrači u prostoru analize velikih podataka, posebno , , Također se kreću prema radu s odvajanjem pohrane podataka i izračuna.
Slični obrasci mogu se vidjeti i u drugim glavnim analitičkim platformama, uključujući Presto, Tensorflow to R i Jupyter. Prebacivanjem stanja na udaljene sustave za pohranu u oblaku, upravljanje i skaliranje aplikacije postaje mnogo lakše. To također olakšava prenosivost aplikacije u raznim okruženjima.
Izvor: www.habr.com
