La sfârșitul anului trecut, a avut loc o altă transmisie în direct a comunității ruse PostgreSQL , în timpul căreia cofondatorul său Nikolai Samokhvalov a vorbit cu directorul tehnic Flant, Dmitri Stolyarov, despre acest DBMS în contextul Kubernetes.
Publicăm o transcriere a părții principale a acestei discuții, iar la Video complet postat:
Baze de date și Kubernetes
NS: Nu vom vorbi astăzi despre VACUUM și CHECKPOINT-uri. Vrem să vorbim despre Kubernetes. Știu că ai mulți ani de experiență. V-am vizionat videoclipurile și chiar am revizionat unele dintre ele... Să trecem direct la subiect: de ce Postgres sau MySQL în K8s?
DS: Nu există și nu poate exista un răspuns cert la această întrebare. Dar, în general, aceasta este simplitatea și comoditatea... potențialul. Toată lumea vrea servicii gestionate.
NS: La modul , doar acasa?
DS: Da: ca RDS, oriunde.
NS: „Oriunde” este un punct bun. În companiile mari, totul este situat în locuri diferite. Atunci de ce, dacă este o companie mare, să nu luați o soluție gata făcută? De exemplu, Nutanix are propriile dezvoltări, alte companii (VMware...) au același „RDS, doar acasă”.
DS: Dar vorbim despre o implementare separată care va funcționa doar în anumite condiții. Și dacă vorbim despre Kubernetes, atunci există o mare varietate de infrastructură (care poate fi în K8-uri). În esență, acesta este un standard pentru API-urile către cloud...
NS: Este și gratuit!
DS: Nu este atât de important. Libertatea este importantă pentru un segment nu foarte mare al pieței. Altceva este important... Probabil vă amintiți raportul „"?
NS: Da.
DS: Mi-am dat seama că a fost primit foarte ambiguu. Unii oameni au crezut că spun: „Băieți, să introducem toate bazele de date în Kubernetes!”, în timp ce alții au decis că toate acestea sunt biciclete groaznice. Dar am vrut să spun cu totul altceva: „Uite ce se întâmplă, ce probleme sunt și cum pot fi rezolvate. Ar trebui să folosim acum bazele de date Kubernetes? Productie? Ei bine, doar dacă îți place... să faci anumite lucruri. Dar pentru un dezvoltator, pot spune că îl recomand. Pentru un dezvoltator, dinamismul creării/ștergerii mediilor este foarte important.”
NS: Prin dev, te referi la toate mediile care nu sunt produse? Montare, QA...
DS: Dacă vorbim de standuri performante, atunci probabil că nu, deoarece cerințele de acolo sunt specifice. Dacă vorbim de cazuri speciale în care este nevoie de o bază de date foarte mare pentru staging, atunci probabil că nu... Dacă acesta este un mediu static, de lungă durată, atunci care este beneficiul de a avea baza de date localizată în K8s?
NS: Nici unul. Dar unde vedem mediile statice? Un mediu static va deveni învechit mâine.
DS: Înscenarea poate fi statică. Avem clienti...
NS: Da, am si eu unul. Este o mare problemă dacă ai o bază de date de 10 TB și 200 GB de staging...
DS: Am un caz foarte tare! La punere în scenă există o bază de date de produse la care se fac modificări. Și există un buton: „roll out to production”. Aceste modificări - delte - sunt adăugate (se pare că sunt pur și simplu sincronizate prin API) în producție. Aceasta este o opțiune foarte exotică.
NS: Am văzut startup-uri în Valley care stau în RDS sau chiar în Heroku - acestea sunt povești de acum 2-3 ani - și își descarcă gunoiul pe laptop. Pentru că baza de date este încă de doar 80 GB și există spațiu pe laptop. Apoi cumpără discuri suplimentare pentru toată lumea, astfel încât să aibă 3 baze de date pentru a realiza diferite dezvoltări. Asa se intampla si. De asemenea, am văzut că nu le este frică să copieze prod în scenă - depinde foarte mult de companie. Dar am văzut și că le este foarte frică și că adesea nu au suficient timp și mâini. Dar înainte de a trece la acest subiect, vreau să aud despre Kubernetes. Am înțeles bine că nimeni nu este încă în prod?
DS: Avem baze de date mici în prod. Vorbim de volume de zeci de gigabytes și de servicii non-critice pentru care ne-a fost prea lene să facem replici (și nu este nevoie de așa ceva). Și cu condiția să existe stocare normală sub Kubernetes. Această bază de date a funcționat într-o mașină virtuală - condiționat în VMware, deasupra sistemului de stocare. L-am pus înăuntru iar acum îl putem transfera de la mașină la mașină.
NS: Baze de date de această dimensiune, până la 100 GB, pot fi lansate în câteva minute pe discuri bune și o rețea bună, nu? O viteză de 1 GB pe secundă nu mai este exotică.
DS: Da, pentru operarea liniară aceasta nu este o problemă.
NS: Bine, trebuie doar să ne gândim la prod. Și dacă luăm în considerare Kubernetes pentru medii non-prod, ce ar trebui să facem? Văd asta în Zalando , în Crunchy , există și alte opțiuni. Si aici este - acesta este bunul nostru prieten Alvaro din Spania: ceea ce fac ei nu este, în esență, doar , și întreaga distribuție (), în care, pe lângă Postgres în sine, au decis să introducă și o copie de rezervă, proxy-ul Envoy...
DS: Trimis pentru ce? Echilibrați traficul Postgres în mod specific?
NS: Da. Adică, ei îl văd ca: dacă luați o distribuție și un nucleu Linux, atunci PostgreSQL obișnuit este nucleul și vor să facă o distribuție care să fie prietenoasă cu cloud-ul și să ruleze pe Kubernetes. Ei pun împreună componente (backup-uri etc.) și le depanează astfel încât să funcționeze bine.
DS: Foarte tare! În esență, acesta este un software pentru a vă crea propriul Postgres gestionat.
NS: Distribuțiile Linux au probleme eterne: cum să faci drivere astfel încât tot hardware-ul să fie suportat. Și au ideea că vor lucra în Kubernetes. Știu că în operatorul Zalando am văzut recent o conexiune la AWS și asta nu mai este foarte bună. Nu ar trebui să existe o legătură cu o anumită infrastructură - atunci ce rost are?
DS: Nu știu exact în ce situație a intrat Zalando, dar în Kubernetes stocarea este acum făcută în așa fel încât este imposibil să faci o copie de rezervă a discului folosind o metodă generică. Recent, în standard - în cea mai recentă versiune — am făcut posibile instantaneele, dar unde este implementat? Sincer, totul este încă atât de brut... Încercăm CSI pe deasupra AWS, GCE, Azure, vSphere, dar de îndată ce începi să-l folosești, poți vedea că nu este încă gata.
NS: De aceea trebuie uneori să ne bazăm pe infrastructură. Cred că aceasta este încă o etapă incipientă - dureri de creștere. Întrebare: Ce sfaturi le-ai da începătorilor care doresc să încerce PgSQL în K8s? Ce operator poate?
DS: Problema este că Postgres este 3% pentru noi. Avem, de asemenea, o listă foarte mare de software diferite în Kubernetes, nici măcar nu voi enumera totul. De exemplu, Elasticsearch. Există o mulțime de operatori: unii se dezvoltă activ, alții nu. Ne-am întocmit cerințe pentru noi înșine, ce ar trebui să fie în operator, astfel încât să o luăm în serios. Într-un operator special pentru Kubernetes - nu într-un „operator pentru a face ceva în condițiile Amazon”... De fapt, destul de larg (= aproape toți clienții) folosim un singur operator - (vom publica în curând un articol despre el).
NS: Și nici pentru MySQL? Știu că Percona... deoarece acum lucrează la MySQL, MongoDB și Postgres, va trebui să creeze un fel de soluție universală: pentru toate bazele de date, pentru toți furnizorii de cloud.
DS: Nu am avut timp să ne uităm la operatorii pentru MySQL. Acesta nu este obiectivul nostru principal în acest moment. MySQL funcționează bine în mod independent. De ce să folosiți un operator dacă puteți doar să lansați o bază de date... Puteți lansa un container Docker cu Postrges sau îl puteți lansa într-un mod simplu.
NS: A fost o întrebare și despre asta. Niciun operator?
DS: Da, 100% dintre noi au PostgreSQL care rulează fără operator. Pana acum asa. Utilizăm în mod activ operatorul pentru Prometheus și Redis. Avem planuri să găsim un operator pentru Elasticsearch - acesta este cel mai „pe foc”, pentru că vrem să-l instalăm în Kubernetes în 100% din cazuri. Așa cum dorim să ne asigurăm că MongoDB este întotdeauna instalat în Kubernetes. Aici apar anumite dorințe - există sentimentul că în aceste cazuri se poate face ceva. Și nici măcar nu ne-am uitat la Postgres. Desigur, știm că există diferite opțiuni, dar de fapt avem o variantă independentă.
DB pentru testare în Kubernetes
NS: Să trecem la subiectul testării. Cum să implementați modificări în baza de date - din perspectiva DevOps. Există microservicii, multe baze de date, ceva se schimbă undeva tot timpul. Cum să vă asigurați CI/CD normal, astfel încât totul să fie în ordine din perspectiva DBMS. Care este abordarea ta?
DS: Nu poate exista un singur răspuns. Există mai multe opțiuni. Prima este dimensiunea bazei pe care vrem să o întindem. Dumneavoastră ați menționat că companiile au atitudini diferite față de a avea o copie a bazei de date cu produse pe dev și pe scenă.
NS: Și în condițiile GDPR, cred că sunt din ce în ce mai atenți... Pot spune că în Europa au început deja să pună amenzi.
DS: Dar de multe ori puteți scrie software care ia o descărcare de la producție și îl ofusca. Se obțin date de producție (snapshot, dump, copie binară...), dar sunt anonimizate. În schimb, pot exista scripturi de generare: acestea pot fi fixtures sau doar un script care generează o bază de date mare. Problema este: cât timp durează crearea unei imagini de bază? Și cât timp durează implementarea acestuia în mediul dorit?
Am ajuns la o schemă: dacă clientul are un set de date fix (versiunea minimă a bazei de date), atunci le folosim implicit. Dacă vorbim de medii de revizuire, atunci când am creat o ramură, am implementat o instanță a aplicației - lansăm acolo o mică bază de date. Dar a ieșit bine , când luăm un dump din producție o dată pe zi (noaptea) și construim un container Docker cu PostgreSQL și MySQL cu aceste date încărcate pe baza acestuia. Dacă trebuie să extindeți baza de date de 50 de ori din această imagine, acest lucru se face destul de simplu și rapid.
NS: Prin simpla copiere?
DS: Datele sunt stocate direct în imaginea Docker. Acestea. Avem o imagine gata făcută, deși 100 GB. Datorită straturilor din Docker, putem implementa rapid această imagine de câte ori avem nevoie. Metoda este stupidă, dar funcționează bine.
NS: Apoi, când testați, se schimbă chiar în Docker, nu? Copiere pe scriere în Docker - aruncați-l și mergeți din nou, totul este în regulă. Clasă! Și îl folosești deja la maxim?
DS: Pentru o lungă perioadă de timp.
NS: Facem lucruri foarte asemănătoare. Numai că nu folosim copy-on-write al lui Docker, ci altul.
DS: Nu este generic. Și Docker funcționează peste tot.
NS: În teorie, da. Dar avem și module acolo, puteți face diferite module și puteți lucra cu diferite sisteme de fișiere. Ce moment aici. Din partea Postgres, privim totul diferit. Acum m-am uitat din partea Docker și am văzut că totul funcționează pentru tine. Dar dacă baza de date este uriașă, de exemplu, 1 TB, atunci toate acestea durează mult: operațiuni pe timp de noapte și încărcarea totul în Docker... Și dacă 5 TB sunt îndesați în Docker... Sau totul este bine?
DS: Care este diferența: acestea sunt blob-uri, doar biți și octeți.
NS: Diferența este următoarea: o faci prin dump și restaurare?
DS: Deloc necesar. Metodele de generare a acestei imagini pot fi diferite.
NS: Pentru unii clienți, am făcut astfel încât, în loc să generăm în mod regulat o imagine de bază, să o ținem constant la zi. Este în esență o replică, dar nu primește date direct de la master, ci printr-o arhivă. O arhivă binară în care WAL-urile sunt descărcate în fiecare zi, unde se fac copii de siguranță... Aceste WAL-uri ajung apoi la imaginea de bază cu o ușoară întârziere (literal 1-2 secunde). Clonăm din el în orice fel - acum avem ZFS în mod implicit.
DS: Dar cu ZFS sunteți limitat la un singur nod.
NS: Da. Dar ZFS are și o magie : cu el poți trimite un instantaneu și chiar (nu am testat asta încă, dar...) poți trimite o deltă între două PGDATA. De fapt, avem un alt instrument pe care nu l-am luat în considerare cu adevărat pentru astfel de sarcini. PostgreSQL are , care funcționează ca o sincronizare „inteligentă”, omitând multe din ceea ce nu trebuie să vizionați, pentru că nimic nu s-a schimbat acolo. Putem face o sincronizare rapidă între cele două servere și derulăm înapoi în același mod.
Deci, din aceasta, mai mult din partea DBA, încercăm să creăm un instrument care ne permite să facem același lucru pe care l-ai spus tu: avem o singură bază de date, dar vrem să testăm ceva de 50 de ori, aproape simultan.
DS: de 50 de ori înseamnă că trebuie să comandați 50 de instanțe Spot.
NS: Nu, facem totul pe o singură mașină.
DS: Dar cum vă veți extinde de 50 de ori dacă această bază de date este, să zicem, terabyte. Cel mai probabil are nevoie de 256 GB de RAM condiționată?
NS: Da, uneori ai nevoie de multă memorie - asta e normal. Dar acesta este un exemplu din viață. Mașina de producție are 96 de nuclee și 600 GB. În același timp, pentru baza de date sunt folosite 32 de nuclee (chiar și 16 nuclee acum uneori) și 100-120 GB de memorie.
DS: Și 50 de exemplare încap acolo?
NS: Deci există o singură copie, apoi funcționează copy-on-write (ZFS)... Vă voi spune mai detaliat.
De exemplu, avem o bază de date de 10 TB. Au făcut un disc pentru el, ZFS și-a comprimat și dimensiunea cu 30-40 la sută. Deoarece nu facem teste de încărcare, timpul exact de răspuns nu este important pentru noi: lăsați-l să fie de până la 2 ori mai lent - este în regulă.
Oferim oportunitatea programatorilor, QA, DBA etc. efectuați testarea în 1-2 fire. De exemplu, ar putea efectua un fel de migrare. Nu necesită 10 nuclee simultan - are nevoie de 1 backend Postgres, 1 nucleu. Migrația va începe - poate va porni în continuare, apoi va fi folosit al doilea nucleu. Avem 16-32 de nuclee alocate, astfel încât 10 persoane pot lucra în același timp, nicio problemă.
Pentru că fizic PGDATA la fel, se dovedește că de fapt îl înșelăm pe Postgres. Trucul este acesta: de exemplu, 10 Postgres sunt lansate simultan. Care este problema de obicei? Ei au pus , să zicem 25%. În consecință, acesta este 200 GB. Nu veți putea lansa mai mult de trei dintre acestea, deoarece memoria se va epuiza.
Dar la un moment dat ne-am dat seama că acest lucru nu era necesar: am setat shared_buffers la 2 GB. PostgreSQL are , iar în realitate este singurul care influențează . L-am setat la 0,5 TB. Și nici măcar nu contează că ele nu există de fapt: el face planuri de parcă ar exista.
În consecință, atunci când testăm un fel de migrare, putem colecta toate planurile - vom vedea cum se va întâmpla în producție. Secundele de acolo vor fi diferite (mai lente), dar datele pe care le citim de fapt și planurile în sine (ce JOIN-uri sunt acolo etc.) ies exact la fel ca în producție. Și puteți efectua multe astfel de verificări în paralel pe o singură mașină.
DS: Nu crezi că sunt câteva probleme aici? Prima este o soluție care funcționează numai pe PostgreSQL. Această abordare este foarte privată, nu este generică. Al doilea este că Kubernetes (și tot ceea ce fac acum tehnologiile cloud) implică multe noduri, iar aceste noduri sunt efemere. Și în cazul dvs. este un nod cu stare, persistent. Aceste lucruri mă fac să fiu în conflict.
NS: În primul rând, sunt de acord, aceasta este o poveste pur Postgres. Cred că dacă avem un fel de IO directă și un pool de buffer pentru aproape toată memoria, această abordare nu va funcționa - planurile vor fi diferite. Dar deocamdată lucrăm doar cu Postgres, nu ne gândim la alții.
Despre Kubernetes. Tu însuți ne spui peste tot că avem o bază de date persistentă. Dacă instanța eșuează, principalul lucru este să salvați discul. Aici avem și întreaga platformă în Kubernetes, iar componenta cu Postgres este separată (deși va fi acolo într-o zi). Prin urmare, totul este așa: instanța a căzut, dar i-am salvat PV și pur și simplu l-am conectat la o altă instanță (nouă), de parcă nimic nu s-ar fi întâmplat.
DS: Din punctul meu de vedere, creăm pod-uri în Kubernetes. K8s - elastic: nodurile sunt comandate la nevoie. Sarcina este de a crea pur și simplu un pod și de a spune că are nevoie de X resurse, iar apoi K8s își va da seama singur. Dar suportul pentru stocare în Kubernetes este încă instabil: În (această versiune a fost lansată a săptămânii în urmă) aceste caracteristici devin doar beta.
Vor trece șase luni până la un an - va deveni mai mult sau mai puțin stabil, sau cel puțin va fi declarat ca atare. Apoi, posibilitatea de a face instantanee și redimensionare vă rezolvă problema complet. Pentru că ai o bază. Da, s-ar putea să nu fie foarte rapid, dar viteza depinde de ceea ce este „sub capotă”, deoarece unele implementări pot copia și copia-pe-scriere la nivel de subsistem de disc.
NS: De asemenea, este necesar ca toate motoarele (Amazon, Google...) să înceapă să accepte această versiune - acest lucru durează, de asemenea, ceva timp.
DS: Încă nu le folosim. Noi le folosim pe ale noastre.
Dezvoltare locală pentru Kubernetes
NS: Ați dat peste o astfel de dorință când trebuie să instalați toate podurile pe o singură mașină și să faceți un test atât de mic. Pentru a obține rapid o dovadă a conceptului, vezi că aplicația rulează în Kubernetes, fără a-i dedica o grămadă de mașini. Există Minikube, nu?
DS: Mi se pare că acest caz - desfășurat pe un singur nod - este exclusiv despre dezvoltarea locală. Sau unele manifestări ale unui astfel de tipar. Mânca , există , . Ne îndreptăm spre utilizarea Kubernetes IN Docker. Acum am început să lucrăm cu el pentru teste.
NS: Obișnuiam să cred că aceasta a fost o încercare de a împacheta toate podurile într-o singură imagine Docker. Dar s-a dovedit că este vorba despre ceva complet diferit. Oricum, există containere separate, capsule separate - doar în Docker.
DS: Da. Și există o imitație destul de amuzantă, dar sensul este acesta... Avem o utilitate pentru desfășurare - . Vrem să facem din acesta un mod condiționat werf up: „Adu-mi Kubernetes local.” Și apoi rulați condiționalul acolo werf follow. Apoi, dezvoltatorul va putea edita IDE-ul și va fi lansat un proces în sistem care vede modificările și reconstruiește imaginile, redistribuindu-le pe K8-urile locale. Așa vrem să încercăm să rezolvăm problema dezvoltării locale.
Instantanee și clonarea bazelor de date în realitatea K8s
NS: Dacă revenim la copy-on-write. Am observat că norii au și instantanee. Ele lucrează diferit. De exemplu, în GCP: aveți o instanță de mai mulți teraocteți pe coasta de est a Statelor Unite. Faceți instantanee periodic. Ridicați o copie a discului de pe coasta de vest dintr-un instantaneu - în câteva minute totul este gata, funcționează foarte repede, doar cache-ul trebuie să fie completat în memorie. Dar aceste clone (instantanee) au scopul de a „furniza” un nou volum. Acest lucru este grozav când trebuie să creați o mulțime de instanțe.
Dar pentru teste, mi se pare că instantaneele, despre care vorbiți în Docker sau despre care vorbesc în ZFS, btrfs și chiar LVM... - vă permit să nu creați date cu adevărat noi pe o singură mașină. În cloud, veți plăti în continuare pentru ele de fiecare dată și veți aștepta nu secunde, ci minute (și în caz , eventual un ceas).
În schimb, puteți obține aceste date într-o secundă sau două, să rulați testul și să le aruncați. Aceste instantanee rezolvă diferite probleme. În primul caz - pentru a crește și pentru a obține replici noi, iar în al doilea - pentru teste.
DS: Nu sunt de acord. A face clonarea volumului să funcționeze corect este sarcina cloud-ului. Nu m-am uitat la implementarea lor, dar știu cum o facem pe hardware. Avem Ceph, permite orice volum fizic () Spune clona și obțineți un al doilea volum cu aceleași caracteristici în zeci de milisecunde, 'ami, etc. Trebuie să înțelegeți că în interior există o copiere la scriere dificilă. De ce nu ar trebui să facă norul la fel? Sunt sigur că încearcă să facă asta într-un fel sau altul.
NS: Dar le va lua totuși secunde, zeci de secunde pentru a ridica o instanță, a aduce Docker acolo etc.
DS: De ce este necesar să se ridice o instanță întreagă? Avem o instanță cu 32 de nuclee, 16... și se poate încadra în ea - de exemplu, patru. Când îl comandăm pe al cincilea, instanța va fi deja ridicată, iar apoi va fi ștearsă.
NS: Da, interesant, Kubernetes se dovedește a fi o altă poveste. Baza noastră de date nu este în K8s și avem o singură instanță. Dar clonarea unei baze de date multi-terabyte nu durează mai mult de două secunde.
DS: Asta e super. Dar punctul meu inițial este că aceasta nu este o soluție generică. Da, este grozav, dar este potrivit doar pentru Postgres și doar pe un singur nod.
NS: Este potrivit nu numai pentru Postgres: aceste planuri, așa cum am descris, vor funcționa doar în el. Dar dacă nu ne deranjam cu planurile și avem nevoie doar de toate datele pentru testarea funcțională, atunci aceasta este potrivită pentru orice SGBD.
DS: Cu mulți ani în urmă am făcut ceva asemănător cu instantaneele LVM. Acesta este un clasic. Această abordare a fost folosită foarte activ. Nodurile cu stare sunt doar o durere. Pentru că nu ar trebui să le scăpați, ar trebui să le amintiți mereu...
NS: Vedeți vreo posibilitate de un hibrid aici? Să presupunem că stateful este un fel de pod, funcționează pentru mai multe persoane (mulți testeri). Avem un singur volum, dar datorită sistemului de fișiere, clonele sunt locale. Dacă podul cade, dar discul rămâne, podul se va ridica, va număra informații despre toate clonele, va ridica totul din nou și va spune: „Iată clonele tale care rulează pe aceste porturi, continuă să lucrezi cu ele.”
DS: Din punct de vedere tehnic, aceasta înseamnă că în Kubernetes este un pod în care rulăm multe Postgres.
NS: Da. Are o limită: să presupunem că nu mai mult de 10 oameni lucrează cu el în același timp. Dacă aveți nevoie de 20, vom lansa un al doilea astfel de pod. Îl vom clona complet, după ce a primit al doilea volum complet, va avea aceleași 10 clone „subțiri”. Nu vezi această oportunitate?
DS: Trebuie să adăugăm probleme de securitate aici. Acest tip de organizare presupune că acest pod are privilegii (capacități) mari, deoarece poate efectua operațiuni non-standard pe sistemul de fișiere... Dar repet: cred că pe termen mediu vor repara stocarea în Kubernetes, iar în norii vor repara întreaga poveste cu volume - totul va „funcționa”. Va exista redimensionare, clonare... Există un volum - spunem: „Creează unul nou pe baza asta”, iar după o secundă și jumătate obținem ceea ce ne trebuie.
NS: Nu cred într-o secundă și jumătate pentru mulți terabytes. Pe Ceph o faci singur, dar vorbesti despre nori. Mergeți în cloud, faceți o clonă a unui volum EBS de mai mulți terabyte pe EC2 și vedeți care va fi performanța. Nu va dura câteva secunde. Sunt foarte interesat când vor ajunge la acest nivel. Înțeleg ce spui, dar vă rog să fiu diferit.
DS: Ok, dar am spus pe termen mediu, nu pe termen scurt. De cativa ani.
Despre operatorul pentru PostgreSQL de la Zalando
La mijlocul acestei întâlniri, Alexey Klyukin, un fost dezvoltator de la Zalando, s-a alăturat și el și a vorbit despre istoria operatorului PostgreSQL:
Este grozav că acest subiect este atins în general: atât Postgres, cât și Kubernetes. Când am început să o facem la Zalando în 2017, era un subiect pe care toată lumea dorea să îl facă, dar nimeni nu a făcut-o. Toată lumea avea deja Kubernetes, dar când au întrebat ce să facă cu bazele de date, chiar și oamenilor le place , care a predicat K8s, a spus ceva de genul acesta:
„Accesați serviciile gestionate și folosiți-le, nu rulați baza de date în Kubernetes. În caz contrar, K8-urile dvs. vor decide, de exemplu, să facă o actualizare, să oprească toate nodurile, iar datele dumneavoastră vor zbura departe, departe.”
Am decis să facem un operator care, contrar acestui sfat, va lansa o bază de date Postgres în Kubernetes. Și aveam un motiv întemeiat - . Aceasta este o failover automată pentru PostgreSQL, făcută corect, adică. folosind etcd, consul sau ZooKeeper ca stocare de informații despre cluster. Un astfel de depozit care va oferi tuturor celor care întreabă, de exemplu, care este liderul actual, aceleași informații – în ciuda faptului că avem totul distribuit – astfel încât să nu existe creier divizat. Plus că am avut pentru el.
În general, nevoia companiei de failover automat a apărut după migrarea de la un centru de date hardware intern la cloud. Cloud-ul s-a bazat pe o soluție proprietară PaaS (Platform-as-a-Service). Este Open Source, dar a fost nevoie de multă muncă pentru a-l pune în funcțiune. S-a numit .
Inițial, nu exista Kubernetes. Mai exact, atunci când a fost implementată propria noastră soluție, K8-urile existau deja, dar erau atât de brute încât nu erau potrivite pentru producție. A fost, după părerea mea, 2015 sau 2016. Până în 2017, Kubernetes devenise mai mult sau mai puțin matur – era nevoie să migreze acolo.
Și aveam deja un container Docker. Exista un PaaS care folosea Docker. De ce nu încercați K8-urile? De ce să nu-ți scrii propriul operator? Murat Kabilov, care a venit la noi de la Avito, a început asta ca un proiect din proprie inițiativă - „a juca” - și proiectul „a decolat”.
Dar, în general, am vrut să vorbesc despre AWS. De ce a existat un cod istoric legat de AWS...
Când rulați ceva în Kubernetes, trebuie să înțelegeți că K8s este un lucru în curs. Se dezvoltă constant, se îmbunătățește și chiar se defectează din când în când. Trebuie să urmăriți îndeaproape toate schimbările din Kubernetes, trebuie să fiți pregătit să vă scufundați în ele dacă se întâmplă ceva și să aflați cum funcționează în detaliu - poate mai mult decât v-ați dori. Acest lucru, în principiu, se aplică oricărei platforme pe care rulați bazele de date...
Deci, când am făcut declarația, am avut Postgres care rulează pe un volum extern (EBS în acest caz, deoarece lucram pe AWS). Baza de date a crescut, la un moment dat a fost necesar să o redimensionăm: de exemplu, dimensiunea inițială a EBS a fost de 100 TB, baza de date a crescut până la ea, acum vrem să facem EBS 200 TB. Cum? Să presupunem că puteți face un dump/restaurare pe o instanță nouă, dar acest lucru va dura mult timp și va implica timp de nefuncționare.
Prin urmare, am vrut o redimensionare care să mărească partiția EBS și apoi să spună sistemului de fișiere să folosească noul spațiu. Și am făcut-o, dar în acel moment Kubernetes nu avea niciun API pentru operația de redimensionare. Din moment ce am lucrat pe AWS, am scris cod pentru API-ul său.
Nimeni nu te împiedică să faci același lucru pentru alte platforme. Nu există niciun indiciu în declarația că poate fi rulat doar pe AWS și nu va funcționa la orice altceva. În general, acesta este un proiect Open Source: dacă cineva dorește să accelereze apariția utilizării noului API, ești binevenit. Mânca , solicitări pull - echipa Zalando încearcă să le răspundă destul de repede și să promoveze operatorul. Din câte știu eu, proiectul la Google Summer of Code și alte inițiative similare. Zalando lucrează foarte activ la asta.
PS Bonus!
Dacă sunteți interesat de subiectul PostgreSQL și Kubernetes, atunci vă rugăm să rețineți că următoarea Postgres Tuesday a avut loc săptămâna trecută, unde am vorbit cu Nikolai Alexander Kukushkin de la Zalando. Videoclipul din acesta este disponibil .
PPS
Citește și pe blogul nostru:
- «»;
- «»;
- «»;
- «".
Sursa: www.habr.com