Krajem prošle godine održan je još jedan livestream ruskog PostgreSQL zajedništva , tijekom kojeg je njegov suosnivač Nikolaj Samohvalov razgovarao s tehničkim direktorom «Flanta» Dmitrijem Stolyarovim o ovoj DBMS u kontekstu Kubernetesa.
Objavljujemo transkript glavnog dijela ove diskusije, a na objavljena je cjelovita video snimka:
Baze podataka i Kubernetes
НС: Danas nećemo govoriti o VACUUM-u i CHECKPOINT-ima. Želimo razgovarati o Kubernetesu. Znam da imaš mnogo godina iskustva. Gledao sam tvoje video snimke i neke čak ponovo pregledavao… Idemo odmah na stvar: zašto uopće Postgres ili MySQL u K8s?
ДС: Na ovo pitanje ne postoji jednoznačan odgovor, niti može postojati. Ali općenito, to je jednostavnost i praktičnost… potencijalne. Svi žele managed usluge.
НС: Da bude kao , samo svoje?
ДС: Da: kao RDS, samo gdje god želiš.
НС: «Gdje god želiš» — to je dobar komentar. U velikim kompanijama sve je smješteno na različitim lokacijama. A zašto onda, ako je to velika kompanija, ne uzeti gotovo rješenje? Na primjer, Nutanix ima vlastite razvojne projekte, a druge kompanije (VMware…) imaju isto «RDS, samo svoje».
ДС: Ali govorimo o posebno dizajniranom rješenju koje će raditi samo pod određenim uvjetima. A kada je riječ o Kubernetesu, ovdje je ogroman izbor infrastrukture (koja može biti u K8s). U suštini, to je standard za API prema oblaku…
НС: I još je besplatno!
ДС: To nije tako važno. Besplatnost je važna samo za manji segment tržišta. Važno je nešto drugo… Sigurno se sjećaš mog izlaganja «»?
НС: Da.
ДС: Shvatio sam da je bio primljen vrlo ambivalentno. Neki su pomislili da govorim: «Ljudi, idemo sa svim bazama u Kubernetese!», a drugi su smatrali da su to sve strašni bicikli. A ja sam zapravo htio reći nešto sasvim drugo: «Gledajte, što se događa, koje su probleme i kako ih možemo rješavati. Sada ići s bazama u Kubernetese? U produkciju? Pa, samo ako volite… baviti se određenim stvarima. Ali za dev – mogu reći da preporučujem. Za dev je vrlo važna dinamičnost stvaranja/uklanjanja okruženja.»
НС: Misliš na dev kao sve okruženje koje nije prod? Staging, QA…
ДС: Kada govorimo o perf-stendovima, mislim da ne, jer su zahtjevi specifični. Ako govorimo o posebnim slučajevima gdje je na stagingu potrebna jako velika baza podataka, također mislim da ne... Ako je to statično okruženje, dugotrajno, koja je onda korist od toga što se baza nalazi u K8s?
НС: Nema nikakve. Ali gdje vidimo statična okruženja? Statična okruženja su jučer postala zastarjela.
ДС: Staging može biti statičan. Imamo klijente...
НС: Da, i ja imam. Veliki je problem ako imate bazu od 10 TB, a staging od 200 GB...
ДС: Imam jako zanimljiv slučaj! Na stagingu se nalazi produkcijska baza, u koju se unose promjene. I postoji gumb: „objavi u produkciju“. Te promjene — delte — se dodaju (mislim, samo se sinkroniziraju putem API-a) u produkciju. To je vrlo egzotična varijanta.
НС: Vidio sam startupe u Dolini koji idu na RDS-u ili čak na Heroku još — to su priče od prije 2-3 godine — i oni preuzimaju dump na svoj laptop. Jer baza ima samo 80 GB, a na laptopu ima mjesta. Kasnije dodatno kupuju diskove svakome, da imaju po 3 baze za različite razvojne projekte. Također znam da se ne boje kopirati produkciju u staging — to jako ovisi o kompaniji. Ali sam vidio i da se vrlo boje, a često nedostaje vremena i ruku. No prije nego što pređemo na ovu temu, volio bih čuti nešto o Kubernetesu. Da li pravilno razumijem da u produkciji to još nitko nema?
ДС: Imamo male baze u produkciji. Riječ je o količinama od desetaka gigabajta i nekritičnim servisima, za koje nam se nije dalo raditi replikacije (niti ima potrebe za tim). I uz uvjet da pod Kubernetesom postoji normalno skladište. Ova baza je radila u virtualnoj mašini — uvjetno rečeno u VMware-u, na vrhu SAN-a. Premjestili smo je u i sada je možemo prenositi s mašine na mašinu.
НС: Baze takvih dimenzija, do 100 GB, na dobrim diskovima i uz dobru mrežu, mogu se razdići za nekoliko minuta, zar ne? Brzina od 1 GB u sekundi nije više egzotična.
ДС: Da, za linearnu operaciju to nije problem.
НС: U redu, o produkciji trebamo samo razmišljati. A ako razmatramo Kubernetes za ne-prod okruženja — kako raditi? Vidim da u Zalandu , u Crunchy , postoje još neki varijante. I tu je — naš dobar poznanik Alvaro iz Španjolske: oni ne rade samo , već čitav distributiv (), u koji osim samog Postgres-a još planiraju uključiti i backup, proxy Envoy...
ДС: Envoy za što? Za balansiranje prometom Postgres-a?
НС: Da. Dakle, oni to vide kao: ako uzmemo Linux distribuciju i jezgru, obični PostgreSQL je jezgra, a oni žele napraviti distribuciju koja će biti prijateljska prema oblačnim uslugama i raditi unutar Kubernetes-a. Spojit će komponente (backupi itd.) i optimizirati ih kako bi dobro radili.
ДС: Vrlo cool! U suštini, to je softver za izradu vlastitog upravljanog Postgres-a.
НС: Kod Linux distribucija postoje vječni problemi: kako napraviti drivere da bi se sav hardver podržao. A njihova ideja je da će raditi unutar Kubernetes-a. Znam da smo nedavno u operatoru Zalando vidjeli vezu na AWS, što već nije dobro. Ne bi se trebala raditi veza na specifičnu infrastrukturu — u čemu je onda smisao?
ДС: Ne znam u kojoj situaciji se konkretno Zalando povezao, ali trenutno je storage u Kubernetes-u napravljen tako da se diskovni backup ne može uzeti na generički način. Nedavno je u standardu — u posljednjoj verziji — omogućeno snimanje snimaka, ali gdje je to implementirano? Iskreno, još uvijek je sve toliko sirovo... Pokušavamo CSI na AWS-u, GCE-u, Azure-u, vSphere-u, ali čim počneš koristiti, vidi se da to još nije spremno.
НС: Zato ponekad moramo vezati na infrastrukturu. Mislim da je to još uvijek rani stadij — problemi rasta. Pitanje: što bi savjetovao početnicima koji žele probati PgSQL u K8s? Koji operator, možda?
ДС: Problem je što je Postgres za nas — to je 3%. Imamo još jako dugačak popis raznog softvera u Kubernetes-u, neću ni sve nabrajati. Na primjer, Elasticsearch. Operatora ima bezbroj: neki se aktivno razvijaju, drugi — ne. Za sebe smo sastavili zahtjeve koje operator mora imati da bismo ga shvatili ozbiljno. U operatoru za Kubernetes — ne u 'operatoru za rad u uvjetima Amazon-a'... U praksi, dovoljno masovno (= gotovo svi naši klijenti) koristimo jedini operator — (uskoro ćemo objaviti članak i o njemu).
НС: A za MySQL također nema? Znam da Percona... sada se bave i MySQL-om, i MongoDB-om, i Postgres-om, trebali bi napraviti neki univerzalni sustav: za sve baze, za sve cloud pružatelje.
ДС: Nismo stigli da pogledamo operatore za MySQL. To nam trenutno nije glavna preokupacija. MySQL dobro radi u standalone režimu. Zašto bi trebao operator, kada jednostavno možeš pokrenuti bazu podataka… Možeš pokrenuti Docker kontejner s Postgresom, ali možeš ga jednostavno pokrenuti.
НС: O tome je također bilo pitanje. U potpunosti bez operatora?
ДС: Da, 100% imamo PostgreSQL pokrenut bez operatora. Za sada tako. Aktivno koristimo operator za Prometheus, za Redis. Planiramo pronaći operator za Elasticsearch — on nam je najprioritetniji, jer ga želimo implementirati 100% slučajeva u Kubernetes. Također, želimo da MongoDB uvijek bude u Kubernetesu. Pojavljuju se određene želje — imamo osjećaj da možemo nešto napraviti u tim slučajevima. O Postgresu nismo ni razmišljali. Naravno, znamo za različite opcije, ali u stvarnosti imamo standalone.
Baza podataka za testiranje u Kubernetesu
НС: Idemo na temu testiranja. Kako primijeniti promjene u bazi — iz perspektive DevOps-a. Ima mnogo mikroservisa, puno baza, stalno se nešto mijenja. Kako osigurati normalan CI/CD, da s aspekta SDB-a sve bude u redu. Koji je tvoj pristup?
ДС: Ne može biti jednog odgovora. Ima nekoliko parametara. Prvi je veličina baze koju želimo primijeniti. Sam si spomenuo da se različito pristupa tome da kopija prod-baze bude na dev i stage.
НС: A u uvjetima GDPR-a, mislim da se pažljivije postupa… Mogu reći da su u Europi počeli s kažnjavanjem.
ДС: No često se može napisati softver koji pravi dump s produkcije i obfuskuje ga. Dobivaju se produkcijski podaci (snapshot, dump, binarna kopija...), ali su anonimni. Umjesto toga mogu postojati skripte za generiranje: to mogu biti fixture ili samo skripta koja generira veliku bazu. Problem je: koliko vremena treba da se kreira osnovna slika? I koliko vremena treba za njeno postavljanje u potrebnom okruženju?
Došli smo do sheme: ako klijent ima skup fiksnih podataka (minimalna verzija baze), onda ih po defaultu koristimo. Ako se radi o preglednim okruženjima, kada smo stvorili branch, naš instance aplikacije se pokrene — tamo primjenjujemo malu bazu. Ali dobro je i ispalo. , kada jednom dnevno s produkcije (noću) sklonimo dump i na temelju njega sastavimo Docker kontejner s PostgreSQL i MySQL s tim učitanim podacima. Ako iz tog image-a treba 50 puta pokrenuti bazu, to se radi dovoljno jednostavno i brzo.
НС: Jednostavnim kopiranjem?
ДС: Podaci se pohranjuju direktno u Docker image-u. To jest, imamo gotov image, recimo od 100 GB. Zahvaljujući slojevima u Docker-u, možemo brzo pokretati ovaj image onoliko puta koliko je potrebno. Način je trivijalan, ali dobro radi.
НС: Što dalje, kada testirate, to se unutar Docker-a mijenja, zar ne? Copy-on-write unutar Docker-a — odbacujemo i ponovo idemo, sve je u redu. Super! Već to koristite punom parom?
ДС: Već dugo.
НС: Mi se bavimo sličnim stvarima. Samo mi ne koristimo Docker-ov copy-on-write, nego nešto drugo.
ДС: Nije generički. A Docker-ov radi posvuda.
НС: Teoretski, da. Ali imamo i module, možemo napraviti različite module i raditi s različitim datotečnim sustavima. Tu je bitno da mi s strane Postgres-a na to gledamo drugačije. Sada sam pogledao s strane Docker-a i vidio da vam sve radi. Ali ako je baza ogromna, primjerice 1 TB, onda je sve to sporo: i operacije noću i ubacivanje svega u Docker… A ako 5 TB gurnemo u Docker… Ili je sve u redu?
ДС: Koja je razlika: to su blob-ovi, samo bitovi i bajtovi.
НС: Razlika je: da li to radite preko dump i restore?
ДС: O tome nije nužno. Postoji više načina generiranja ovog image-a.
НС: Za neke klijente učinili smo tako da umjesto redovitog generiranja osnovnog image-a, stalno ga održavamo ažuriranim. U suštini je replika, ali podatke ne dobiva direktno s mastera, nego kroz arhiv. Binarni arhiv, gdje se WAL-ovi primjenjuju svaki dan, tu se također snimaju backupi… Ti WAL-ovi potom dolaze — s malim kašnjenjem (doslovno 1-2 sekunde) — do osnovnog image-a. S njega kloniramo na bilo koji način — trenutno po zadanim postavkama koristimo ZFS.
ДС: Ali s ZFS-om ste ograničeni na jedan čvor.
НС: Da. Ali ZFS ima još jedan čarobni : s njim možete poslati snapshot i čak (ovo još nisam puno testirao, ali…) možete slati diferencijal između dvaju PGDATA. U stvarnosti, imamo još jedan alat koji nismo posebno razmatrali za takve zadatke. U PostgreSQL postoji , radi kao "pametni" rsync, preskočivši mnogo toga što se ne mora gledati, jer se tu zapravo ništa nije promijenilo. Možemo brzo sinkronizirati između dva poslužitelja i vratiti se unazad na isti način.
Dakle, pokušavamo s ove, DBA-ovske strane stvoriti alat koji omogućava isto ono o čemu si govorio: imamo jednu bazu, ali želimo 50 puta nešto testirati, gotovo istovremeno.
ДС: 50 puta znači da morate naručiti 50 Spot instanci.
НС: Ne, sve radimo na jednom stroju.
ДС: Kako ćete rasporediti 50 puta, ako je ta jedna baza, recimo, terabajtna? Vjerojatno joj treba, uvjetno rečeno, 256 GB RAM-a?
НС: Da, ponekad je potrebno puno memorije — to je normalno. Ali evo primjera iz stvarnog života. Na produkcijskom stroju imamo 96 jezgri i 600 GB. Pri tome za bazu podataka koristi 32 jezgre (čak i 16 jezgra ponekad) i 100-120 GB memorije.
ДС: I stane li 50 kopija tamo?
НС: Ali kopija je jedna; zatim radi copy-on-write (ZFS)... Ispričat ću detaljnije.
Naša baza, primjerice, ima 10 TB. Disk za nju je napravljen, a ZFS je smanjio njezinu veličinu za 30-40%. Budući da ne radimo opterećenja testiranja, točno vrijeme odziva nam nije važno: neka bude do 2 puta sporije — to je u redu.
Dajemo mogućnost programerima, QA, DBA i slično da provode testiranja u 1-2 niti. Na primjer, mogu pokrenuti neku migraciju. Ona ne zahtijeva odmah 10 jezgri — treba joj 1 backend Postgres-a, 1 jezgra. Migracija će se pokrenuti — možda, možda će se još pokrenuti, tada će druga jezgra biti uključena. Imamo dodijeljeno 16-32 jezgri, tako da 10 ljudi može raditi istovremeno, nema problema.
Budući da je fizički PGDATA isti, ispada da zapravo varamo Postgres. U čemu je trik: recimo, pokrene se 10 Postgres instanci istovremeno. Koji je obično problem? Postavljaju , recimo, na 25%. Tako da je to 200 GB. Više od tri takva ne može se pokrenuti, jer će memorija ponestati.
Ali shvatili smo u nekom trenutku da to nije potrebno: postavljamo shared_buffers na 2 GB. PostgreSQL ima , i zapravo samo on utječe na . To postavljamo na 0,5 TB. I nije ni važno što ih zapravo nema: gradi planove kao da postoje.
Kad testiramo neku migraciju, možemo prikupiti sve planove — tako ćemo vidjeti kako će to izgledati u produkciji. Sekunde će biti drugačije (sporije), ali podaci koje stvarno očitavamo i sami planovi (koji JOIN-ovi itd.) bit će potpuno isti kao u produkciji. I paralelno možemo pokretati brojne takve provjere na jednoj mašini.
ДС: Ne misliš li da ovdje postoji nekoliko problema? Prvi je da ovo rješenje funkcioniše samo na PostgreSQL-u. Takav pristup je veoma specifičan, nije općenit. Drugi je da Kubernetes (i sve što se sada odvija u oblaku) predviđa mnoštvo čvorova, a ti čvorovi su efemerni. A u tvom slučaju to je stateful, perzistentni čvor. Ove stvari mi stvaraju nesuglasice.
НС: Prvo — slažem se, to je isključivo Postgres priča. Mislim da, ako imamo neki direktni IO i buffer pool gotovo cijelu memoriju, takav pristup ne bi odgovarao — planovi će biti drugačiji. Ali za sada radimo samo s Postgresom, o drugim ne razmišljamo.
O Kubernetesu. Pa ti sam svuda govoriš da imamo perzistentnu bazu. Ako instanca padne, najvažnije je sačuvati disk. Tako je i naša cijela platforma u Kubernetesu, a komponenta s Postgresom je odvojeno (iako će i ona jednom biti tu). Zato je sve tako: instanca je pala, ali smo sačuvali njen PV i jednostavno je priključili drugoj (novoj) instanci, kao da se ništa nije dogodilo.
ДС: Iz mog ugla, kreiramo pod-ove u Kubernetesu. K8s je elastičan: čvorovi se naručuju sami po potrebi. Zadatak je samo stvoriti pod i reći mu da mu je potrebno X resursa, a dalje će se K8s sam snaći. Ali podrška za pohranu u Kubernetesu i dalje nije stabilna: u , u (ova verzija je objavljena nedjelja natrag) ove funkcije postaju samo beta.
Proći će pola godine do godine — postat će više-manje stabilno, ili će barem biti tako deklarirano. Tada će mogućnost snimanja snimaka i promjene veličine potpuno riješiti vaš problem. Jer imate bazu. Da, možda neće biti jako brza, ali brzina zavisi od onoga što je „ispod haube“, jer neka rješenja podržavaju kopiranje i copy-on-write na nivou disčne podsystems.
НС: Takođe, potrebno je da svi motori (Amazon, Google…) stignu početi podržavati ovu verziju — to takođe zahteva neko vreme.
ДС: Za sada ih ne koristimo. Koristimo svoje.
Lokalni razvoj pod Kubernetesom
НС: Jesi li se ikada susreo s takvom željom, kada treba na jednom stroju pokrenuti sve podove i provesti malo testiranje. Da bi brzo dobio proof of concept, pogledao da li aplikacija radi u Kubernetesu, a da ne moraš izdvajati gomilu strojeva za to. Postoji Minikube, zar ne?
ДС: Čini mi se da je ovaj slučaj — pokrenuti na jednom čvoru — isuviše usko vezan za lokalni razvoj. Ili neka manifestacija tog obrasca. Postoji , postoji , . Idemo ka tome da ćemo koristiti Kubernetes u Dockeru. Sada smo počeli raditi s njim za testove.
НС: Ranije sam mislio da je to pokušaj da se svi podovi umotaju u jedan Docker-image. No, ispostavilo se da je to nešto sasvim drugo. I dalje su to odvojeni kontejneri, odvojeni podovi — jednostavno u Dockeru.
ДС: Da. I tu je prilično zabavna imitacija napravljena, ali smisao je takav… Imamo alat za deploy — . Želimo u njemu napraviti režim — uvjetno werf up: «Podigni mi lokalni Kubernetes». A zatim pokrenuti neki werf follow. Tada će developer moći uređivati u IDE-u, dok je u sustavu pokrenut proces koji prati promjene i ponovo sastavlja slike, redeploya ih u lokalni K8s. Tako želimo pokušati riješiti problem lokalnog razvoja.
Snapshoti i kloniranje Baze podataka u stvarima K8s
НС: Ako se vratimo na copy-on-write. Primijetio sam da i oblaci imaju snapshotove. Oni rade različito. Na primjer, u GCP-u: imaš višeterabajtni instanc na istočnoj obali SAD-a. Periodično praviš snapshotove. Podigneš kopiju diska iz snapshot-a na zapadnoj obali — za nekoliko minuta sve je spremno, radi vrlo brzo, samo je potrebno napuniti keš u memoriji. No ti klonovi (snapshotovi) — koriste se za 'provisioning' novog volumena. To je sjajno kada trebaš stvoriti mnogo instanci.
A za testove, čini mi se, snapshotovi o kojima ti pričaš u Dockeru ili ja pričam u ZFS-u, btrfs-u pa čak i LVM-u... — omogućavaju upravo na jednom stroju ne stvarati nove podatke. U oblaku ćeš također plaćati za njih svaki put i čekati ne sekunde, nego minute (a u slučaju , možda i sate).
Umjesto toga, te podatke možeš dobiti za jednu-dvije sekunde, provesti test i odbaciti. Ti snapshotovi rješavaju različite zadatke. U prvom slučaju — da se skaliraš i dobiješ nove replikate, a u drugom — za testove.
ДС: Ne slažem se. Ispravno kloniranje volumena je zadatak za oblak. Nisam gledao njihovu implementaciju, ali znam kako to radimo na hardveru. Imamo Ceph, u njemu možemo bilo kojem fizičkom volumenu () reći clone i dobiti u desetinama milisekundi drugi volumen s istim karakteristikama, i slično. Treba razumjeti da je unutra pametan copy-on-write. Zašto oblak ne bi radio tako isto? Siguran sam da se na jedan ili drugi način trude to ostvariti.
НС: Ali će im ipak trebati sekunde, deseci sekundi da pokrenu instancu, postave Docker itd.
ДС: Zašto bi nužno morali pokretati cijelu instancu? Imamo instancu sa 32 jezgra, na 16… i u nju stane određeni broj — na primjer, četiri. Kada naručimo petu, instanca će se već pokrenuti, a zatim će se obrisati.
НС: Da, zanimljivo, u Kubernetesu je drugačija priča. Naša baza podataka nije u K8s, i imamo jednu instancu. Ipak, za kloniranje višeterabajtne baze ne treba više od dvije sekunde.
ДС: To je sjajno. Ali moja izvorna ideja je da to nije generičko rješenje. Da, super je, ali odgovara samo Postgresu i samo na jednom čvoru.
НС: Nije samo za Postgres: to su planovi, kao što sam opisivao, radit će samo u njemu. No, ako se ne zamaram planovima, a jednostavno trebamo sve podatke za funkcionalno testiranje, tada će to odgovarati svakoj bazi podataka.
ДС: Prije mnogo godina radili smo slično na LVM snapshotima. To je klasika. Ovaj pristup je bio vrlo aktivno korišten. Jednostavno, stateful čvorovi su bol. Jer ih ne smiješ ispustiti, uvijek ih se treba sjetiti…
НС: Ne vidiš li ovdje neku mogućnost hibrida? Recimo, stateful — to je neki pod, radi na nekoliko ljudi (više testera). Imamo jedan volumen, ali zahvaljujući datotečnom sustavu klonovi su lokalni. Ako pod padne, disk ostaje — pod će se ponovo pokrenuti, zabilježi informacije o svim klonovima, sve će ponovno podići i reći: „Evo vaši klonovi na ovim portovima su pokrenuti, radite s njima dalje“.
ДС: Tehnički to znači da je unutar Kubernetesa to jedan pod, unutar kojeg pokrećemo mnogo Postgresova.
НС: Da. Ima ograničenje: recimo, istovremeno s njim radi ne više od 10 osoba. Ako treba 20 — pokrenut ćemo drugi takav pod. Potpuno je realno klonirati ga, dobivajući drugi puni volumen, na njemu će biti isti 10 „tankih“ klonova. Ne vidiš tu mogućnost?
ДС: Treba dodati pitanja o sigurnosti. Ova vrsta organizacije podrazumijeva da ovaj pod ima visoke privilegije (capabilities), jer može izvoditi nestandardne operacije s datotečnim sustavom... No ponavljam: smatram da će se u srednjoročnom razdoblju u Kubernetesu popraviti storage, u oblaku će se riješiti cijela priča s volumenima — sve će 'jednostavno raditi'. Bit će resize, kloniranje... Postoji volumen — kažemo: 'Kreiraj novi na temelju onog', — i za sekundu i pol dobijemo ono što trebamo.
НС: Ne vjerujem u sekundu i pol za mnogo terabajta. Na Cephu to radiš sam, a govoriš o oblacima. Idi u oblak, na EC2 napravi klon volumena EBS od više terabajta i vidi kakva će biti izvedba. To neće trajati nekoliko sekundi. Zanimljivo mi je kada će doći do takvog mjera. Razumijem o čemu govoriš, ali ću se usuditi ne složiti.
ДС: U redu, ali rekao sam da u srednjoročnom razdoblju, ne kratkoročnom. Tijekom nekoliko godina.
O operatoru za PostgreSQL od Zalanda
Sredinom ovog sastanka pridružio se i Aleksej Kljukin, bivši programer iz kompanije Zalando, koji je ispričao povijest operatora PostgreSQL:
Sjajno je da je ova tema uopće spomenuta: i Postgres, i Kubernetes. Kada smo počeli raditi na tome u Zalandu 2017. godine, to je bila tema kojom su svi željeli baviti, ali nitko nije radio. Svi su već imali Kubernetes, ali kada se pitamo kako biti s bazama podataka, čak su i takvi ljudi kao , koji su propovijedali K8s, govorili otprilike sljedeće:
„Idite na managed usluge i koristite ih, ne pokrećite BDP u Kubernetesu. Inače će vaš K8s odlučiti, na primjer, napraviti nadogradnju, ugasiti sve čvorove i vaši podaci će odletjeti daleko.”
Odlučili smo napraviti operator koji će, unatoč ovom savjetu, pokretati BDP PostgreSQL u Kubernetesu. I imali smo dobru osnovu — . To je automatski failover za PostgreSQL, napravljen ispravno, tj. koristeći etcd, consul ili ZooKeeper kao skladište informacija o klasteru. Takvo skladište koje će svima koji pitaju, na primjer, koji je sada vođa, dati istu informaciju — bez obzira na to što imamo sve distribuirano — kako ne bi bilo split brain-a. Plus, imali smo za njega.
Ustvari, potreba za automatskim prebacivanjem pala je na kompaniju nakon migracije iz unutrašnjeg podatkovnog centra u oblak. Oblak je bio zasnovan na vlastitom PaaS rješenju (Platform-as-a-Service). Bilo je Open Source, ali da bi ga aktivirali, trebalo je mnogo truda. Zvalo se .
U početku nije bilo nikakvog Kubernetes-a. Tačnije, kada se razvijalo vlastito rješenje, K8s je već postojao, ali je bio toliko neusavršen da nije bio pogodan za produkciju. To je, mislim, bila 2015. ili 2016. godina. Do 2017. godine Kubernetes je postao više-manje zreo — pojavila se potreba za migracijom tamo.
Već smo imali Docker kontejner. Postojala je PaaS koja je koristila Docker. Zašto ne probati K8s? Zašto ne napisati svog operatera? Murat Kabilov, koji nam se pridružio iz Avita, započeo je to kao projekat iz vlastite inicijative — "da se zabavi" — i projekat je "poletio".
Ali generalno, želeo sam da pričam o AWS-u. Zašto je istorijski imao kod povezan sa AWS-om...
Kada pokrećete nešto u Kubernetes-u, morate razumeti da je K8s u stalnom razvoju. Neprestano se unapređuje, a povremeno se čak i pokvari. Uvek treba pažljivo pratiti sve promene u Kubernetes-u, morate biti spremni da se u slučaju potrebe upustite u njega i saznate kako sve funkcioniše u detalje — verovatno više nego što biste želeli. To je, zapravo, slučaj sa svakom platformom na kojoj pokrećete svoje baze podataka...
Dakle, kada smo pravili operatera, imali smo Postgres koji je radio sa spoljašnjim volumenom (u ovom slučaju — EBS, jer smo radili u AWS-u). Baza podataka se širila, i u nekom trenutku se javila potreba da se izvrši resize: na primer, prvi veličina EBS-a bila je 100 TB, baza je dostigla tu veličinu, sada želimo da napravimo EBS od 200 TB. Kako? Recimo, može se napraviti dump/restore na novom instance, ali to traje dugo i dolazi do zastoja.
Zato smo želeli takav resize koji će povećati particiju EBS-a, a zatim reći datotečnom sistemu da koristi novi prostor. I to smo uradili, ali u to vreme Kubernetes nije imao nikakav API za operaciju resize-a. Pošto smo radili na AWS-u, napisali smo kod za njegov API.
Niko ne sprečava da se isto uradi i za druge platforme. U operateru nema zavisnosti da se može pokrenuti samo na AWS-u, a na svemu ostalom neće raditi. U suštini, ovo je Open Source projekat: ako neko želi ubrzati korišćenje novog API-ja — slobodno. , pull-zahtjevi — tim Zalanda se trudi da na njih brzo odgovara i unaprijedi operatera. Koliko znam, projekt u Google Summer of Code i nekim drugim sličnim inicijativama. Zalando aktivno radi na tome.
P.S. Bonus!
Ako vas zanima tema PostgreSQL i Kubernetes, skrećemo pažnju da je prošlog tjedna održan sljedeći Postgres-vtorak, gdje je s Nikolajem razgovarao Aleksandar Kukuškin iz Zalanda. Video s događaja je dostupan .
P.S.
Pročitajte i na našem blogu:
- «»;
- «»;
- «»;
- «».
Izvor: habr.com
Russian
Italian
German
Polish
Estonian
Albanian
Bulgarian
Croatian
Czech
Danish
Dutch
English
French
Hungarian
Latvian
Lithuanian
Norwegian
Portuguese
Romanian
Slovak
Slovenian
Spanish
Swedish