À a fine di l'annu passatu, una altra trasmissione in diretta di a cumunità russa PostgreSQL hè stata , durante u quale u so cofundatore Nikolai Samokhvalov hà parlatu cù u direttore tecnicu di Flant Dmitry Stolyarov nantu à questu DBMS in u cuntestu di Kubernetes.
Publicemu una trascrizione di a parte principale di sta discussione, è à Video cumpletu publicatu:
Basi di dati è Kubernetes
NS: Ùn parlemu micca di VACUUM è CHECKPOINT oghje. Vulemu parlà di Kubernetes. Sò chì avete parechji anni di sperienza. Aghju guardatu i vostri video è ancu re-guardatu alcuni di elli... Andemu direttamente à u puntu: perchè Postgres o MySQL in K8s in tuttu?
DC: Ùn ci hè micca è ùn pò esse una risposta definita à sta quistione. Ma in generale, questu hè simplicità è cunvenzione ... potenziale. Tutti volenu servizii amministrati.
NS: À cumu , solu in casa ?
DC: Iè: cum'è RDS, in ogni locu.
NS: "In ogni locu" hè un bonu puntu. In e grande cumpagnie, tuttu hè situatu in diversi lochi. Perchè allora, s'ellu hè una grande cumpagnia, ùn pigliate micca una suluzione pronta? Per esempiu, Nutanix hà i so sviluppi, altre cumpagnie (VMware...) anu u stessu "RDS, solu in casa".
DC: Ma parlemu di una implementazione separata chì hà da travaglià solu in certi cundizioni. E se parlemu di Kubernetes, allora ci hè una grande varietà di infrastruttura (chì pò esse in K8s). Essenzialmente, questu hè un standard per l'API à u nuvulu ...
NS: Hè ancu gratis !
DC: Ùn hè micca cusì impurtante. A libertà hè impurtante per un segmentu micca assai grande di u mercatu. Qualcosa altru hè impurtante... Probabilmente vi ricordate di u rapportu ""?"
NS: Iè.
DC: Aghju realizatu chì era ricevutu assai ambiguu. Certi pirsuni pensanu chì dicu: "Ragazzi, mettemu tutte e basa di dati in Kubernetes!", Mentre chì altri anu decisu chì questi eranu tutti biciclette terribili. Ma vulia dì qualcosa di completamente diversu: "Fighjate ciò chì succede, chì prublemi ci sò è cumu si ponu risolve. Duvemu aduprà e basa di dati Kubernetes avà? Pruduzzione ? Ebbè, solu s'ellu ti piace ... fà certe cose. Ma per un dev, possu dì chì u cunsigliu. Per un dev, u dinamisimu di creà / sguassà ambienti hè assai impurtante ".
NS: Per dev, intendi tutti l'ambienti chì ùn sò micca prod? Mise en scène, QA...
DC: Se parlemu di perf stands, allora probabilmente micca, perchè i requisiti sò specifichi. Se parlemu di casi spiciali induve una basa di dati assai grande hè necessariu per staging, allora probabilmente micca ... S'ellu hè un ambiente staticu, longu, allora chì hè u benefiziu di avè a basa di dati situata in K8s?
NS: nimu. Ma induve vedemu ambienti statici ? Un ambiente staticu diventerà obsoletu dumane.
DC: A messa in scena pò esse statica. Avemu clienti ...
NS: Iè, aghju ancu unu. Hè un grande prublema si avete una basa di dati di 10 TB è 200 GB di staging ...
DC: Aghju un casu assai bellu ! Nantu à a messa in scena, ci hè una basa di dati di produttu à quale sò fatti cambiamenti. È ci hè un buttone: "rol out to production". Questi cambiamenti - deltas - sò aghjuntu (pare chì sò simpliciamente sincronizati via l'API) in a produzzione. Questa hè una opzione assai esotica.
NS: Aghju vistu startups in u Valle chì si trovanu in RDS o ancu in Heroku - sò storie da 2-3 anni fà - è scaricanu u dump à u so laptop. Perchè a basa di dati hè sempre solu 80 GB, è ci hè spaziu nantu à u laptop. Allora cumprà dischi supplementari per tutti per avè 3 basa di dati per realizà diversi sviluppi. Hè cusì chì succede ancu. Aghju vistu ancu chì ùn anu micca paura di copià prod in staging - assai dipende da a cumpagnia. Ma aghju vistu ancu chì sò assai paura, è chì spessu ùn anu micca abbastanza tempu è mani. Ma prima di passà à stu tema, vogliu sente parlà di Kubernetes. Aghju capitu bè chì nimu hè ancu in prod?
DC: Avemu petite basa di dati in prod. Parlemu di volumi di decine di gigabytes è servizii non critichi per i quali eramu troppu pigri per fà rèpliche (è ùn ci hè micca bisognu). È sempre chì ci hè un almacenamentu normale sottu Kubernetes. Questa basa di dati hà travagliatu in una macchina virtuale - cundizionalmente in VMware, in cima di u sistema di almacenamento. L'avemu messu in è avà pudemu trasfiriri lu da machine à machine.
NS: E basa di dati di questa dimensione, finu à 100 GB, ponu esse sbulicati in pochi minuti nantu à boni dischi è una bona rete, nò ? Una velocità di 1 GB per seconda ùn hè più esotica.
DC: Iè, per u funziunamentu lineale ùn hè micca un prublema.
NS: D'accordu, avemu solu à pensà à prod. E se cunsideremu Kubernetes per ambienti non-prod, chì duvemu fà? Vecu chì in Zalando , in Crunchy , ci sò altre opzioni. È ci hè - questu hè u nostru bonu amicu Alvaro da Spagna: ciò chì facenu hè essenzialmente micca solu , è tutta a distribuzione (), in quale, in più di Postgres stessu, anu decisu ancu di stuff una copia di salvezza, u proxy Envoy ...
DC: Inviatu per chì ? Equilibrà u trafficu Postgres in particulare?
NS: Iè. Questu hè, u vedenu cum'è: se pigliate una distribuzione Linux è un kernel, allora PostgreSQL regulare hè u kernel, è volenu fà una distribuzione chì serà amichevule in nuvola è eseguisce in Kubernetes. Puderanu cumpunenti (backups, etc.) è li debug in modu chì travaglianu bè.
DC: Moltu bellu ! Essenzialmente, questu hè un software per creà u vostru propiu Postgres amministratu.
NS: Distribuzioni Linux anu prublemi eterni: cumu fà i drivers per chì tuttu u hardware hè supportatu. È anu l'idea chì anu da travaglià in Kubernetes. Sapemu chì in l'operatore Zalando avemu vistu pocu tempu una cunnessione à AWS è questu ùn hè più assai bonu. Ùn deve esse un ligame à una infrastruttura specifica - chì hè u puntu allora?
DC: Ùn sò micca esattamente in quale situazione Zalando hè ghjuntu, ma in Kubernetes l'almacenamiento hè avà fattu in tale manera chì hè impussibile di piglià una copia di salvezza di discu cù un metudu genericu. Recentemente in standard - in l'ultima versione - avemu fattu snapshots pussibuli, ma induve hè implementatu? Onestamente, tuttu hè sempre cusì crudu ... Pruvemu CSI nantu à AWS, GCE, Azure, vSphere, ma appena principiatu à aduprà, pudete vede chì ùn hè micca prontu ancu.
NS: Hè per quessa chì qualchì volta ci vole à appughjà nantu à l'infrastruttura. Pensu chì questu hè sempre una prima tappa - cresce i dolori. Quistione: Chì cunsigliu darebbe à i principianti chì volenu pruvà PgSQL in K8s? Chì operatore forse?
DC: U prublema hè chì Postgres hè 3% per noi. Avemu ancu una lista assai grande di diversi software in Kubernetes, ùn aghju mancu listinu tuttu. Per esempiu, Elasticsearch. Ci sò assai operatori: alcuni sò attivamente sviluppati, altri ùn sò micca. Avemu stabilitu esigenze per noi stessi nantu à ciò chì un operatore deve avè per noi per piglià in seriu. In un operatore specificamente per Kubernetes - micca in un "operatore per fà qualcosa in e cundizioni di Amazon"... In fatti, avemu abbastanza largamente (= guasi tutti i clienti) aduprà un unicu operatore - (Pubblicheremu un articulu annantu à ellu prestu).
NS: È micca ancu per MySQL ? Sapemu chì Percona... postu ch'elli travaglianu avà nantu à MySQL, MongoDB è Postgres, anu da creà una sorta di suluzione universale: per tutte e basa di dati, per tutti i fornitori di nuvola.
DC: Ùn avemu micca u tempu di guardà l'operatori per MySQL. Questu ùn hè micca u nostru focus principale avà. MySQL funziona bè in standalone. Perchè aduprà un operatore se pudete solu lancià una basa di dati ... Pudete lancià un containeru Docker cù Postrges, o pudete lancià in una manera simplice.
NS: Ci era ancu una quistione nantu à questu. Nisun operatore à tutti?
DC: Iè, 100% di noi avemu PostgreSQL in esecuzione senza operatore. Finu à quì. Utilizemu attivamente l'operatore per Prometheus è Redis. Avemu prughjetti di truvà un operatore per Elasticsearch - hè quellu chì hè più "in focu", perchè vulemu installallu in Kubernetes in 100% di i casi. Cum'è vulemu assicurà chì MongoDB hè ancu sempre stallatu in Kubernetes. Quì appare certi desideri - ci hè un sintimu chì in questi casi si pò fà qualcosa. È ùn avemu mancu fighjatu à Postgres. Di sicuru, sapemu chì ci sò diverse opzioni, ma in fattu avemu un standalone.
DB per a prova in Kubernetes
NS: Passemu à u tema di a prova. Cumu implementà cambiamenti à a basa di dati - da una perspettiva DevOps. Ci sò microservizi, parechje basa di dati, qualcosa cambia in ogni locu tuttu u tempu. Cumu assicurà CI / CD normale per chì tuttu hè in ordine da a perspettiva DBMS. Chì ghjè u vostru approcciu?
DC: Ùn ci pò esse una risposta. Ci sò parechje scelte. U primu hè a dimensione di a basa chì vulemu sparghje. Avete dettu chì l'imprese anu attitudini diverse per avè una copia di a basa di dati di prod in dev è stage.
NS: È in e cundizioni di u GDPR, pensu chì sò sempre più attenti... Possu dì chì in Auropa sò digià cuminciatu à impone ammende.
DC: Ma spessu pudete scrive un software chì piglia un dump da a pruduzzione è l'obfuscate. I dati di pruduzzione sò ottenuti (snapshot, dump, copia binaria...), ma sò anonimizati. Invece, ci ponu esse script di generazione: questi ponu esse apparecchi o solu un script chì genera una grande basa di dati. U prublema hè: quantu tempu ci vole à creà una maghjina di basa? E quantu tempu ci vole à implementà in l'ambiente desideratu?
Avemu ghjuntu à un schema: se u cliente hà un settore di dati fissu (versione minima di a basa di dati), allora l'utilizamu per automaticamente. Se parlemu di l'ambienti di rivisione, quandu avemu creatu una filiera, avemu implementatu una istanza di l'applicazione - stendemu una piccula basa di dati quì. Ma hè andatu bè , Quandu avemu pigliatu un dump da a pruduzzione una volta à ghjornu (à a notte) è custruiscenu un containeru Docker cù PostgreSQL è MySQL cù questa data caricata basatu annantu à questu. Sè avete bisognu di espansione a basa di dati 50 volte da questa imagine, questu hè fattu abbastanza simplice è rapidamente.
NS: Par simple copie ?
DC: I dati sò almacenati direttamente in l'imagine Docker. Quelli. Avemu una maghjina pronta, ancu 100 GB. Grazie à i strati in Docker, pudemu implementà rapidamente sta maghjina quante volte avemu bisognu. U metudu hè stupidu, ma funziona bè.
NS: Allora, quandu teste, cambia ghjustu in Docker, nò? Copy-on-write in Docker - lanciate è andate di novu, tuttu va bè. Classe ! È l'avete digià utilizatu à u massimu?
DC: Per un bellu pezzu.
NS: Facemu cose assai simili. Solu ùn usemu micca a copia di scrittura di Docker, ma qualcunu altru.
DC: Ùn hè micca genericu. È Docker travaglia in ogni locu.
NS: In teoria, sì. Ma avemu ancu moduli quì, pudete fà diversi moduli è travaglià cù diversi sistemi di schedari. Chì mumentu quì. Da u latu di Postgres, guardemu tuttu questu in modu diversu. Avà aghju vistu da u latu di Docker è aghju vistu chì tuttu funziona per voi. Ma s'è a basa di dati hè enormu, per esempiu, 1 TB, allura tuttu questu pigghia assai tempu: operazioni di notte, è stuffing tuttu in Docker ... E se 5 TB sò stuffed in Docker ... O hè tuttu bè?
DC: Chì hè a diffarenza : sò blobs, solu bits è byte.
NS: A diffarenza hè questu: fate u dump è restaurà ?
DC: Ùn hè micca necessariu. I metudi per generà sta maghjina pò esse sfarenti.
NS: Per certi clienti, avemu fattu cusì chì invece di generà regularmente una maghjina di basa, l'avemu sempre aghjurnata. Hè essenzialmente una replica, ma riceve dati micca direttamente da u maestru, ma attraversu un archiviu. Un archiviu binariu induve i WAL sò scaricati ogni ghjornu, induve e copie di salvezza sò pigliate... Questi WAL righjunghjenu dopu à l'imaghjini di basa cù un pocu ritardu (literalmente 1-2 seconde). Clonemu da ellu in ogni modu - avà avemu ZFS per difettu.
DC: Ma cù ZFS site limitatu à un node.
NS: Iè. Ma ZFS hà ancu un magicu : cun ellu pudete mandà una snapshot è ancu (ùn aghju micca veramente pruvatu questu, ma...) pudete mandà un delta trà dui PGDATA. In fatti, avemu un altru strumentu chì ùn avemu micca veramente cunsideratu per tali compiti. PostgreSQL hà , chì travaglia cum'è un rsync "intelligente", saltendu assai di ciò chì ùn avete micca bisognu, perchè nunda ùn hà cambiatu quì. Pudemu fà una sincronizazione rapida trà i dui servitori è rewind in u listessu modu.
Allora, da questu, più latu DBA, avemu a prova di creà un strumentu chì ci permette di fà a listessa cosa chì avete dettu: avemu una basa di dati, ma vulemu pruvà qualcosa 50 volte, quasi simultaneamente.
DC: 50 volte significa chì avete bisognu di urdinà 50 istanze Spot.
NS: No, facemu tuttu nantu à una macchina.
DC: Ma cumu si espansione 50 volte se sta basa di dati hè, per dì, terabyte. Probabilmente hà bisognu di 256 GB di RAM cundiziunali?
NS: Iè, qualchì volta avete bisognu di assai memoria - hè normale. Ma questu hè un esempiu di a vita. A macchina di pruduzzione hà 96 core è 600 GB. À u listessu tempu, 32 cores (ancu 16 cores avà qualchì volta) è 100-120 GB di memoria sò usati per a basa di dati.
DC: È ci sò 50 copie?
NS: Allora ci hè una sola copia, allora a copia in scrittura (ZFS) funziona... Vi dicu più in dettaglio.
Per esempiu, avemu una basa di dati 10 TB. Anu fattu un discu per ellu, ZFS hà ancu cumpressu a so dimensione da 30-40 per centu. Siccomu ùn facemu micca teste di carica, u tempu di risposta esatta ùn hè micca impurtante per noi: lasciate esse finu à 2 volte più lento - hè bè.
Demu l'uppurtunità à i programatori, QA, DBA, etc. eseguite a prova in 1-2 fili. Per esempiu, puderanu eseguisce qualchì tipu di migrazione. Ùn hè micca bisognu di 10 core à una volta - hà bisognu di 1 backend Postgres, 1 core. A migrazione principiarà - forse principiarà sempre, allora u sicondu core serà utilizatu. Avemu 16-32 cores attribuiti, cusì 10 persone ponu travaglià à u stessu tempu, senza prublema.
Perchè fisicamente PGDATA u listessu, si trova chì avemu ingannà veramente Postgres. U truccu hè questu: per esempiu, 10 Postgres sò lanciati simultaneamente. Chì ghjè u prublema di solitu? Si mettenu , dicemu 25%. Dunque, questu hè 200 GB. Ùn puderà micca lancià più di trè di questi, perchè a memoria sguasserà.
Ma à un certu puntu avemu capitu chì questu ùn era micca necessariu: avemu stabilitu shared_buffers à 2 GB. PostgreSQL hà , è in realtà hè l'unicu chì influenza . L'avemu stabilitu à 0,5 TB. È ùn importa mancu ch'elli ùn esistinu micca veramente : ellu face piani cum'è s'elli esistenu.
In cunsiquenza, quandu testemu qualchì tipu di migrazione, pudemu cullà tutti i piani - vedemu cumu si passa in a produzzione. I sicondi ci sarà differente (più lentu), ma i dati chì avemu in veru leghje, è i piani stessi (ciò chì JOIN ci sò, etc.) esce esattamente u listessu cum'è in pruduzzione. È pudete eseguisce parechji tali cuntrolli in parallelu nantu à una macchina.
DC: Ùn pensate micca chì ci sò uni pochi di prublemi quì ? U primu hè una suluzione chì travaglia solu nantu à PostgreSQL. Stu approcciu hè assai privatu, ùn hè micca genericu. U sicondu hè chì Kubernetes (è tuttu ciò chì i tecnulugii di nuvola vanu avà) implica parechji nodi, è questi nodi sò effimeri. È in u vostru casu hè un node stateful, persistente. Queste cose mi facenu cunflittu.
NS: Prima, sò d'accordu, questu hè una storia puramente Postgres. Pensu chì s'ellu avemu qualchì tipu di IO direttu è un buffer pool per quasi tutta a memoria, questu approcciu ùn hà micca travagliatu - i piani seranu diffirenti. Ma per avà avemu travagliatu solu cù Postgres, ùn pensemu micca à l'altri.
À propositu di Kubernetes. Tu stessu ci dici in ogni locu chì avemu una basa di dati persistente. Se l'istanza falla, a cosa principal hè di salvà u discu. Quì avemu ancu tutta a piattaforma in Kubernetes, è u cumpunente cù Postgres hè separatu (ancu se ci serà un ghjornu). Dunque, tuttu hè cusì: l'istanza hè cascata, ma avemu salvatu u so PV è simpricimenti cunnessu à un altru (novu) istanza, cum'è s'ellu ùn era nunda.
DC: Da u mo puntu di vista, creamu pods in Kubernetes. K8s - elasticu: i nodi sò urdinati quantu necessariu. U compitu hè solu di creà un pod è di dì chì hà bisognu di X quantità di risorse, è allora K8s hà da capisce da sè stessu. Ma u supportu di almacenamiento in Kubernetes hè sempre instabile: in (questa liberazione hè stata liberata недели fa) queste caratteristiche diventanu solu beta.
Passaranu sei mesi à un annu - diventerà più o menu stabile, o almenu serà dichjaratu cum'è tali. Allora a pussibilità di snapshots è resize risolve u vostru prublema cumplettamente. Perchè avete una basa. Iè, pò esse micca assai veloce, ma a vitezza dipende di ciò chì hè "sottu u cappucciu", perchè alcune implementazioni ponu copià è copia-in-scrittura à u livellu di u sottosistema di discu.
NS: Hè ancu necessariu chì tutti i mutori (Amazon, Google...) cumincianu à sustene sta versione - questu hè ancu un pocu di tempu.
DC: Ùn avemu micca aduprà ancu. Avemu aduprà u nostru.
Sviluppu lucale per Kubernetes
NS: Avete scontru un tali desideriu quandu avete bisognu di stallà tutti i pods nantu à una macchina è fà una prova cusì petite. Per ottene rapidamente una prova di cuncettu, vede chì l'applicazione corre in Kubernetes, senza dedicà una mansa di macchine per questu. Ci hè Minikube, nò?
DC: Mi pare chì stu casu - dispiegatu nantu à un node - hè solu di u sviluppu lucale. O qualchi manifestazioni di un tali mudellu. Manghja , Ci hè , . Avanzamu versu l'usu di Kubernetes IN Docker. Avà avemu cuminciatu à travaglià cun ellu per teste.
NS: Aghju avutu per pensà chì questu era un tentativu di imballà tutti i pods in una maghjina Docker. Ma si hè risultatu chì questu hè qualcosa di completamente diversu. In ogni casu, ci sò cuntenituri separati, pods separati - solu in Docker.
DC: Iè. È ci hè una imitazione piuttostu divertente fatta, ma u significatu hè questu... Avemu una utilità per a implementazione - . Vulemu fà un modu cundizionale werf up: "Prendemi Kubernetes locale." E poi eseguite u cundizionale quì werf follow. Allora u sviluppatore hà da pudè edità l'IDE, è un prucessu serà lanciatu in u sistema chì vede i cambiamenti è ricustruisce l'imaghjini, redistribuendu à i K8 lucali. Hè cusì chì vulemu pruvà à risolve u prublema di u sviluppu lucale.
Snapshots è clonazione di basa di dati in a realtà di K8s
NS: Se vultemu à copia-on-scrittura. Aghju nutatu chì i nuvuli anu ancu snapshots. Funcionanu in modu diversu. Per esempiu, in GCP: avete una istanza multi-terabyte nantu à a costa est di i Stati Uniti. Pigliate snapshots periodicamente. Pigliate una copia di u discu nantu à a costa uccidentale da una snapshot - in pochi minuti tuttu hè prontu, travaglia assai rapidamente, solu u cache deve esse pienu in memoria. Ma sti cloni (snapshots) sò per "furnisce" un novu voluminu. Questu hè bellu quandu avete bisognu di creà assai casi.
Ma per i testi, mi pari chì i snapshots, chì parli in Docker o parlu in ZFS, btrfs è ancu LVM... - permettenu micca di creà dati veramente novi nantu à una macchina. In u nuvulu, avete sempre pagà per elli ogni volta è aspittà micca seconde, ma minuti (è in u casu , forse un orologio).
Invece, pudete piglià sta dati in un secondu o dui, eseguite a prova è scaccià. Queste snapshots risolve diversi prublemi. In u primu casu - per scala è uttene novi rèpliche, è in u sicondu - per teste.
DC: Ùn sò micca d'accordu. Fà chì a clonazione di u voluminu funziona bè hè u compitu di u nuvulu. Ùn aghju micca guardatu à a so implementazione, ma sò cumu fà nantu à u hardware. Avemu Ceph, permette ogni volume fisicu () dì clonazzioni è uttene un secondu voluminu cù e stesse caratteristiche in decine di millisecondi, 'ami, ecc. Avete bisognu di capiscenu chì ci hè una copia di scrittura complicata in l'internu. Perchè u nuvulu ùn deve micca fà u listessu? Sò sicuru chì provanu à fà questu in un modu o un altru.
NS: Ma li purterà sempre seconde, decine di seconde per elevà una istanza, purtà Docker quì, etc.
DC: Perchè hè necessariu di elevà una istanza sana ? Avemu un esempiu cù 32 cores, 16 ... è pò mette in questu - per esempiu, quattru. Quandu avemu urdinatu u quintu, l'istanza serà digià risuscitata, è dopu serà sguassata.
NS: Iè, interessante, Kubernetes hè una storia diversa. A nostra basa di dati ùn hè micca in K8s, è avemu un esempiu. Ma a clonazione di una basa di dati multi-terabyte ùn dura micca più di dui seconde.
DC: Questu hè grande. Ma u mo puntu iniziale hè chì questu ùn hè micca una suluzione generica. Iè, hè bellu, ma hè adattatu solu per Postgres è solu in un node.
NS: Hè adattatu micca solu per Postgres: questi piani, cum'è l'aghju descrittu, solu travaglià in questu. Ma s'ellu ùn ci preoccupa micca di i piani, è avemu solu bisognu di tutti i dati per a prova funziunale, allora questu hè adattatu per qualsiasi DBMS.
DC: Parechji anni fà avemu fattu qualcosa simili nantu à i snapshots LVM. Questu hè un classicu. Stu approcciu hè statu usatu assai attivamente. Nodes stateful sò solu un dolore. Perchè ùn deve micca abbandunà elli, duvete sempre ricurdà di elli ...
NS: Videte a pussibilità di un hibridu quì ? Diciamu chì stateful hè un tipu di pod, funziona per parechje persone (assai testatori). Avemu un voluminu, ma grazia à u sistema di fugliale, i cloni sò lucali. Se u pod cascà, ma u discu ferma, u pod si alzarà, cuntarà l'infurmazioni nantu à tutti i cloni, ripigliate tuttu di novu è dicenu: "Eccu i vostri cloni chì currenu nantu à questi porti, cuntinuà à travaglià cun elli".
DC: Tecnicamente, questu significa chì in Kubernetes hè un pod in u quale eseguimu parechji Postgres.
NS: Iè. Hà un limitu: dicemu micca più di 10 persone chì travaglianu cun ellu à u stessu tempu. Se avete bisognu di 20, lanceremu una seconda poda. Cloneremu cumplettamente, dopu avè ricevutu u sicondu voluminu pienu, avarà i stessi 10 cloni "sottili". Ùn vede sta opportunità ?
DC: Avemu bisognu di aghjunghje prublemi di sicurezza quì. Stu tipu d'urganizazione implica chì sta poda hà alti privileghji (capacità), perchè pò esse realizatu operazioni non standard nantu à u sistema di schedari... Ma ripetu: Credu chì in u mediu termu riparà l'almacenamiento in Kubernetes, è in i nuvuli riparà tutta a storia cù volumi - tuttu "funcionà solu". Ci sarà resize, cloning... Ci hè un voluminu - dicemu: "Create un novu basatu annantu à questu", è dopu un secondu è mezu avemu bisognu di ciò chì avemu bisognu.
NS: Ùn credu micca in una seconda è mezu per parechji terabytes. Nant'à Ceph fate voi stessu, ma parli di i nuvuli. Andate à u nuvulu, fate un clone di un voluminu EBS multi-terabyte nantu à EC2 è vede ciò chì serà u rendiment. Ùn piglià micca uni pochi di seconde. Sò assai interessatu à quandu ghjunghjeranu à stu livellu. Capiscu ciò chì dite, ma pregu di differisce.
DC: Ok, ma aghju dettu à u mediu termine, micca à cortu termini. Per parechji anni.
Circa l'operatore per PostgreSQL da Zalando
À mezu à sta riunione, Alexey Klyukin, un anticu sviluppatore di Zalando, hà ancu unitu è hà parlatu di a storia di l'operatore PostgreSQL:
Hè bellu chì stu tema hè toccu in generale: sia Postgres sia Kubernetes. Quandu avemu cuminciatu à fà in Zalando in 2017, era un tema chì tutti vulianu fà, ma nimu hà fattu. Tutti avianu digià Kubernetes, ma quandu anu dumandatu ciò chì fà cù e basa di dati, ancu a ghjente piace , chì hà pridicatu K8s, hà dettu qualcosa cum'è questu:
"Vai à i servizii amministrati è aduprate, ùn eseguite micca a basa di dati in Kubernetes. Altrimenti, i vostri K8 decideranu, per esempiu, di fà un aghjurnamentu, disattivà tutti i nodi, è i vostri dati volaranu assai, luntanu.
Avemu decisu di fà un operatore chì, contru à stu cunsigliu, lanciarà una basa di dati Postgres in Kubernetes. È avemu avutu una bona ragione - . Questu hè un failover automaticu per PostgreSQL, fattu currettamente, i.e. usendu etcd, cunsul o ZooKeeper cum'è un almacenamiento d'infurmazioni nantu à u cluster. Un tali repositoriu chì darà à tutti quelli chì dumandanu, per esempiu, quale hè u capu attuale, a listessa infurmazione - malgradu u fattu chì avemu tuttu distribuitu - per chì ùn ci hè micca un cervellu split. In più avemu avutu per ellu.
In generale, a necessità di a cumpagnia di fallu automaticu apparsu dopu a migrazione da un centru di dati di hardware internu à u nuvulu. U nuvulu era basatu annantu à una soluzione patentata PaaS (Platform-as-a-Service). Hè Open Source, ma hà pigliatu assai travagliu per mette in opera. Hè statu chjamatu .
Inizialmente, ùn ci era micca Kubernetes. Più precisamente, quandu a nostra propria suluzione hè stata implementata, K8 esiste digià, ma era cusì crudu chì ùn era micca adattatu per a produzzione. Era, in u mo parè, 2015 o 2016. In u 2017, Kubernetes era diventatu più o menu maturu - ci era bisognu di migrà quì.
È avemu digià avutu un containeru Docker. Ci era un PaaS chì usava Docker. Perchè ùn pruvà K8s? Perchè ùn scrive micca u vostru propiu operatore? Murat Kabilov, chì hè ghjuntu à noi da Avito, hà iniziatu questu cum'è un prughjettu nantu à a so propria iniziativa - "per ghjucà" - è u prugettu "pigliò".
Ma in generale, vulia parlà di AWS. Perchè ci era un codice storicu legatu à AWS ...
Quandu correte qualcosa in Kubernetes, avete bisognu di capisce chì K8s hè un tali travagliu in corso. Si sviluppa constantemente, migliurà è ancu sguassate da u tempu à u tempu. Avete bisognu di guardà attente à tutti i cambiamenti in Kubernetes, avete bisognu à esse prontu à immerse in questu se qualcosa succede è amparà cumu funziona in dettagliu - forse più di ciò chì vulete. Questu, in principiu, s'applica à qualsiasi piattaforma nantu à quale eseguite e vostre basa di dati ...
Allora, quandu avemu fattu a dichjarazione, avemu avutu Postgres in esecuzione nantu à un voluminu esternu (EBS in questu casu, postu chì avemu travagliatu in AWS). A basa di dati hà crisciutu, in un certu puntu era necessariu di ridimensionà: per esempiu, a dimensione iniziale di EBS era 100 TB, a basa di dati hà crisciutu à questu, avà vulemu fà EBS 200 TB. Cumu? Diciamu chì pudete fà un dump / risturà nantu à una nova istanza, ma questu duverà assai tempu è implica un downtime.
Per quessa, vulia un resize chì ingrandà a partizione EBS è poi dite à u sistema di fugliale per utilizà u novu spaziu. È l'avemu fattu, ma à quellu tempu Kubernetes ùn avia micca API per l'operazione di resize. Siccomu avemu travagliatu in AWS, avemu scrittu codice per a so API.
Nimu ùn vi impedisce di fà u listessu per altre piattaforme. Ùn ci hè micca un suggerimentu in a dichjarazione chì pò esse eseguitu solu nantu à AWS, è ùn funziona micca in tuttu u restu. In generale, questu hè un prughjettu Open Source: se qualchissia vole accelerà l'emergenza di l'usu di a nova API, site benvenutu. Manghja , pull requests - a squadra di Zalando prova di risponde à elli abbastanza rapidamente è prumove l'operatore. Quantu sò, u prugettu à Google Summer of Code è alcune altre iniziative simili. Zalando travaglia assai attivamente nantu à questu.
PS Bonus!
Sè vo site interessatu in u tema di PostgreSQL è Kubernetes, allora per piacè nutate ancu chì u prossimu marti di Postgres hà fattu a settimana passata, induve aghju parlatu cù Nikolai. Alexander Kukushkin da Zalando. Video da ellu hè dispunibule .
PPS
Leghjite puru nant'à u nostru blog:
- «";
- «";
- «";
- «».
Source: www.habr.com