Krajem prošle godine održan je još jedan live prijenos ruske PostgreSQL zajednice , tijekom kojeg je njegov suosnivač Nikolai Samokhvalov razgovarao s tehničkim direktorom Flanta Dmitryjem Stolyarovim o ovom DBMS-u u kontekstu Kubernetesa.
Objavljujemo transkript glavnog dijela ove rasprave, a na Objavljen cijeli video:
Baze podataka i Kubernetes
NS: Nećemo danas o VAKUUMU i KONTROLNIM TOČKAMA. Želimo razgovarati o Kubernetesu. Znam da imate dugogodišnje iskustvo. Gledao sam vaše videe i čak ponovno pogledao neke od njih... Prijeđimo odmah na stvar: čemu uopće Postgres ili MySQL u K8s?
DS: Na ovo pitanje nema i ne može biti jasnog odgovora. Ali općenito, ovo je jednostavnost i praktičnost... potencijal. Svatko želi upravljane usluge.
NS: Kako , samo doma?
DS: Da: kao RDS, bilo gdje.
NS: “Bilo gdje” je dobra poanta. U velikim tvrtkama sve se nalazi na različitim mjestima. Zašto onda, ako se radi o velikoj tvrtki, ne uzeti već gotovo rješenje? Na primjer, Nutanix ima vlastiti razvoj, druge tvrtke (VMware...) imaju isti "RDS, samo kod kuće."
DS: Ali govorimo o zasebnoj implementaciji koja će raditi samo pod određenim uvjetima. A ako govorimo o Kubernetesu, onda postoji velika raznolikost infrastrukture (koja može biti u K8s). U biti ovo je standard za API-je za oblak...
NS: Također je besplatno!
DS: Nije toliko važno. Besplatnost je važna za ne baš veliki segment tržišta. Bitno je još nešto... Vjerojatno se sjećate reportaže “"?
NS: Da.
DS: Shvatio sam da je primljeno vrlo dvosmisleno. Neki ljudi su mislili da govorim: “Dečki, ajmo sve baze podataka staviti u Kubernetes!”, dok su drugi zaključili da su to sve strašni bicikli. Ali htio sam reći nešto sasvim drugo: “Pogledajte što se događa, kakvi su problemi i kako se oni mogu riješiti. Trebamo li sada koristiti Kubernetes baze podataka? Proizvodnja? Pa, samo ako voliš... raditi određene stvari. Ali za programera, mogu reći da ga preporučujem. Za programere je vrlo važna dinamičnost stvaranja/brisanja okruženja.”
NS: Pod dev, mislite li na sva okruženja koja nisu prod? Inscenacija, QA…
DS: Ako govorimo o perf tribinama, onda vjerojatno ne, jer su tamo zahtjevi specifični. Ako govorimo o posebnim slučajevima gdje je potrebna vrlo velika baza podataka za postavljanje, onda vjerojatno ne... Ako je ovo statično, dugotrajno okruženje, koja je onda korist od toga da se baza podataka nalazi u K8s?
NS: Nema. Ali gdje vidimo statična okruženja? Statično okruženje će sutra postati zastarjelo.
DS: Inscenacija može biti statična. Imamo klijente...
NS: Da, i ja imam jedan. Veliki je problem ako imate bazu podataka od 10 TB i staging od 200 GB...
DS: Imam vrlo cool slučaj! Prilikom postavljanja postoji baza podataka proizvoda u koju se unose izmjene. A tu je i gumb: "uvesti u proizvodnju". Te se promjene - delte - dodaju (čini se da su jednostavno sinkronizirane preko API-ja) u proizvodnji. Ovo je vrlo egzotična opcija.
NS: Vidio sam startupe u Dolini koji sjede u RDS-u ili čak u Herokuu - to su priče od prije 2-3 godine - i skinuli su dump na svoj laptop. Jer baza je još uvijek samo 80 GB, a ima mjesta na laptopu. Zatim kupuju dodatne diskove za sve kako bi imali 3 baze podataka za izvođenje različitih razvoja. I ovako se događa. Također sam vidio da se ne boje kopirati prod na pozornicu - to jako ovisi o tvrtki. Ali vidio sam i da se jako boje, i da često nemaju dovoljno vremena i ruku. Ali prije nego što prijeđemo na ovu temu, želim čuti o Kubernetesu. Jesam li dobro shvatio da još nitko nije u proizvodnji?
DS: Imamo male baze podataka u prod. Riječ je o količinama od desetaka gigabajta i nekritičnim uslugama za koje smo bili lijeni napraviti replike (a nema takve potrebe). I pod uvjetom da postoji normalno skladištenje pod Kubernetesom. Ova baza podataka radila je u virtualnom stroju - uvjetno u VMwareu, povrh sustava za pohranu podataka. Stavili smo ga unutra a sada ga možemo prenositi sa stroja na stroj.
NS: Baze podataka ove veličine, do 100 GB, mogu se razviti u nekoliko minuta na dobrim diskovima i dobroj mreži, zar ne? Brzina od 1 GB u sekundi više nije egzotika.
DS: Da, za linearni rad to nije problem.
NS: U redu, samo moramo misliti na prod. A ako razmatramo Kubernetes za neproizvodna okruženja, što bismo trebali učiniti? Vidim to u Zalandu , u Crunchyju , postoje neke druge opcije. I postoji - ovo je naš dobar prijatelj Alvaro iz Španjolske: ono što oni rade u biti nije pravedno , i cijela distribucija (), u koji su osim samog Postgresa odlučili ugurati i backup, Envoy proxy...
DS: Izaslanik za što? Konkretno balansiranje Postgres prometa?
NS: Da. Odnosno, oni to vide kao: ako uzmete Linux distribuciju i kernel, tada je obični PostgreSQL kernel i žele napraviti distribuciju koja će biti prilagođena oblaku i raditi na Kubernetesu. Sastavljaju komponente (sigurnosne kopije, itd.) i ispravljaju ih kako bi dobro radile.
DS: Jako cool! U biti ovo je softver za stvaranje vlastitog upravljanog Postgresa.
NS: Linux distribucije imaju vječne probleme: kako napraviti drivere da sav hardver bude podržan. I imaju ideju da će raditi u Kubernetesu. Znam da smo kod Zalando operatera nedavno vidjeli vezu na AWS i to više nije baš dobro. Ne bi trebala postojati veza s određenom infrastrukturom - koja je onda svrha?
DS: Ne znam točno u kakvu je situaciju Zalando dospio, ali u Kubernetesu pohrana je sada napravljena na takav način da je nemoguće napraviti backup diska generičkom metodom. Nedavno u standardu - u najnovijoj verziji — omogućili smo snimke, ali gdje se to implementira? Iskreno, sve je još tako sirovo... Pokušavamo CSI povrh AWS-a, GCE-a, Azure-a, vSphere-a, ali čim ga počnete koristiti, vidite da još nije spreman.
NS: Zato se ponekad moramo osloniti na infrastrukturu. Mislim da je ovo još rana faza - bolovi rasta. Pitanje: Što biste savjetovali početnicima koji žele isprobati PgSQL u K8s? Koji operater možda?
DS: Problem je što nam je Postgres 3%. Također imamo jako veliki popis različitog softvera u Kubernetesu, neću ni nabrajati sve. Na primjer, Elasticsearch. Postoji mnogo operatera: neki se aktivno razvijaju, drugi ne. Za sebe smo postavili zahtjeve što operater treba imati da bismo ga mogli ozbiljno shvatiti. U operatoru posebno za Kubernetes - ne u "operatoru koji radi nešto u Amazonovim uvjetima"... Zapravo, mi dosta široko (= gotovo svi klijenti) koristimo jedan operator - (uskoro ćemo objaviti članak o njemu).
NS: A ne i za MySQL? Znam da Percona... budući da sada rade na MySQL-u, MongoDB-u i Postgresu, morat će napraviti nekakvo univerzalno rješenje: za sve baze podataka, za sve cloud providere.
DS: Nismo imali vremena pogledati operatore za MySQL. Ovo nam trenutno nije glavni fokus. MySQL dobro radi samostalno. Zašto koristiti operator ako možete samo pokrenuti bazu podataka... Možete pokrenuti Docker kontejner s Postrgesom ili ga možete pokrenuti na jednostavan način.
NS: Bilo je i pitanje o ovome. Uopće nema operatera?
DS: Da, 100% nas ima PostgreSQL koji radi bez operatora. Za sada je tako. Aktivno koristimo operator za Prometheus i Redis. Imamo planove pronaći operatora za Elasticsearch - on je onaj koji najviše “gori”, jer ga želimo instalirati u Kubernetes u 100% slučajeva. Kao što želimo osigurati da MongoDB uvijek bude instaliran u Kubernetesu. Ovdje se pojavljuju određene želje - postoji osjećaj da se u tim slučajevima može nešto učiniti. A nismo ni pogledali Postgres. Naravno, znamo da postoje različite opcije, ali zapravo imamo samostalnu.
DB za testiranje u Kubernetesu
NS: Prijeđimo na temu testiranja. Kako uvesti promjene u bazu podataka - iz DevOps perspektive. Postoje mikroservisi, mnogo baza podataka, stalno se negdje nešto mijenja. Kako osigurati normalan CI/CD tako da sve bude u redu iz perspektive DBMS-a. Kakav je vaš pristup?
DS: Ne može biti jedan odgovor. Postoji nekoliko opcija. Prvi je veličina baze koju želimo razvaljati. Sami ste spomenuli da tvrtke imaju različite stavove prema posjedovanju kopije prod baze podataka na dev i stageu.
NS: A prema uvjetima GDPR-a, mislim da su sve oprezniji... Mogu reći da su u Europi već počeli uvoditi kazne.
DS: Ali često možete napisati softver koji iz proizvodnje uzima ispis i zamagljuje ga. Prod podaci se dobivaju (snimak, dump, binarna kopija...), ali su anonimizirani. Umjesto toga, mogu postojati skripte za generiranje: to mogu biti fixture ili samo skripte koje generiraju veliku bazu podataka. Problem je: koliko vremena je potrebno za stvaranje osnovne slike? I koliko je vremena potrebno da se postavi u željeno okruženje?
Došli smo do sheme: ako klijent ima fiksni skup podataka (minimalna verzija baze podataka), tada ih koristimo prema zadanim postavkama. Ako govorimo o okruženjima za pregled, kada smo stvorili granu, implementirali smo instancu aplikacije - tamo smo pokrenuli malu bazu podataka. Ali ispalo je dobro , kada uzimamo dump iz proizvodnje jednom dnevno (noću) i gradimo Docker spremnik s PostgreSQL i MySQL s tim učitanim podacima na temelju toga. Ako trebate proširiti bazu podataka 50 puta s ove slike, to se radi vrlo jednostavno i brzo.
NS: Jednostavnim kopiranjem?
DS: Podaci se pohranjuju izravno u Docker sliku. Oni. Imamo gotovu sliku, iako 100 GB. Zahvaljujući slojevima u Dockeru, možemo brzo implementirati ovu sliku onoliko puta koliko nam je potrebno. Metoda je glupa, ali dobro funkcionira.
NS: Onda, kada testirate, mijenja se unutar Dockera, zar ne? Copy-on-write unutar Dockera - bacite ga i idite ponovo, sve je u redu. Klasa! I koristite li ga već u potpunosti?
DS: Dugo vremena.
NS: Radimo vrlo slične stvari. Samo što mi ne koristimo Dockerov copy-on-write, nego neki drugi.
DS: Nije generički. A Docker radi posvuda.
NS: U teoriji, da. Ali tamo također imamo module, možete napraviti različite module i raditi s različitim sustavima datoteka. Kakav trenutak ovdje. Sa strane Postgresa, mi na sve to gledamo drugačije. Sad sam pogledao s Docker strane i vidio da ti sve radi. Ali ako je baza ogromna, npr. 1 TB, onda sve to dugo traje: operacije noću, pa trpanje svega u Docker... A ako se u Docker utrpa 5 TB... Ili je sve u redu?
DS: Koja je razlika: ovo su mrlje, samo bitovi i bajtovi.
NS: Razlika je u sljedećem: radite li to putem dumpa i vraćanja?
DS: Uopće nije potrebno. Metode za generiranje ove slike mogu biti različite.
NS: Za neke smo klijente napravili tako da umjesto redovitog generiranja osnovne slike, stalno je ažuriramo. U biti je replika, ali podatke ne prima izravno od glavnog, već putem arhive. Binarna arhiva gdje se svaki dan skidaju WAL-ovi, gdje se rade sigurnosne kopije... Ti WAL-ovi onda s malim kašnjenjem (doslovno 1-2 sekunde) stignu do osnovne slike. Kloniramo iz njega na bilo koji način - sada imamo ZFS prema zadanim postavkama.
DS: Ali sa ZFS-om ste ograničeni na jedan čvor.
NS: Da. Ali ZFS ima i magiju : njime možete poslati snimku, pa čak (nisam to još stvarno testirao, ali...) možete poslati deltu između dva PGDATA. Zapravo, imamo još jedan alat koji nismo baš razmatrali za takve zadatke. PostgreSQL ima , koji radi kao "pametni" rsync, preskačući puno toga što ne morate gledati, jer se tu ništa nije promijenilo. Možemo napraviti brzu sinkronizaciju između dva poslužitelja i premotati na isti način.
Dakle, s ove, više DBA strane, pokušavamo stvoriti alat koji nam omogućuje da radimo isto što ste rekli: imamo jednu bazu podataka, ali želimo nešto testirati 50 puta, gotovo istovremeno.
DS: 50 puta znači da trebate naručiti 50 Spot instanci.
NS: Ne, sve radimo na jednom stroju.
DS: Ali kako ćeš proširiti 50 puta ako je ova jedna baza recimo terabajtna. Najvjerojatnije joj treba uvjetnih 256 GB RAM-a?
NS: Da, ponekad vam treba puno memorije - to je normalno. Ali ovo je primjer iz života. Proizvodni stroj ima 96 jezgri i 600 GB. Istovremeno se za bazu koriste 32 jezgre (sada ponekad i 16 jezgri) i 100-120 GB memorije.
DS: I tu stane 50 primjeraka?
NS: Dakle postoji samo jedna kopija, onda radi kopiranje na pisanje (ZFS)... Reći ću vam detaljnije.
Na primjer, imamo bazu podataka od 10 TB. Napravili su mu disk, ZFS mu je također kompresirao veličinu za 30-40 posto. Budući da ne provodimo testiranje opterećenja, točno vrijeme odziva nije nam važno: neka bude do 2 puta sporije - to je u redu.
Pružamo priliku programerima, QA, DBA itd. provesti testiranje u 1-2 niti. Na primjer, mogli bi pokrenuti neku vrstu migracije. Ne zahtijeva 10 jezgri odjednom - treba mu 1 Postgres backend, 1 jezgra. Migracija će početi - možda će se i dalje pokrenuti, tada će se koristiti druga jezgra. Imamo 16-32 dodijeljene jezgre, tako da 10 ljudi može raditi u isto vrijeme, bez problema.
Jer fizički PGDATA isto, ispada da zapravo varamo Postgres. Trik je sljedeći: na primjer, 10 Postgresa se pokreće istovremeno. Što je obično problem? Stavili su , recimo 25%. Prema tome, ovo je 200 GB. Nećete moći pokrenuti više od tri takva jer će ponestati memorije.
Ali u nekom smo trenutku shvatili da to nije potrebno: postavili smo shared_buffers na 2 GB. PostgreSQL ima , a u stvarnosti samo ona utječe . Postavili smo ga na 0,5 TB. I nije čak ni važno što oni zapravo ne postoje: on pravi planove kao da postoje.
Sukladno tome, kada testiramo neku vrstu migracije, možemo skupiti sve planove – vidjet ćemo kako će to biti u proizvodnji. Sekunde će tamo biti drugačije (sporije), ali podaci koje zapravo čitamo i sami planovi (koji su tu JOIN-ovi itd.) ispadaju potpuno isto kao u produkciji. I možete pokrenuti mnogo takvih provjera paralelno na jednom stroju.
DS: Ne mislite li da ovdje ima nekoliko problema? Prvo je rješenje koje radi samo na PostgreSQL-u. Ovaj pristup je vrlo privatan, nije generički. Drugo je da Kubernetes (i sve što tehnologije u oblaku sada idu) uključuje mnogo čvorova, a ti čvorovi su prolazni. A u vašem slučaju to je postojan čvor sa statusom. Ove me stvari izazivaju sukobe.
NS: Prvo, slažem se, ovo je čisto Postgres priča. Mislim da ako imamo neku vrstu izravnog IO-a i međuspremnika za gotovo svu memoriju, ovaj pristup neće funkcionirati - planovi će biti drugačiji. Ali za sada radimo samo s Postgresom, o drugima ne razmišljamo.
O Kubernetesu. Sami nam posvuda govorite da imamo postojanu bazu podataka. Ako instanca ne uspije, glavna stvar je spasiti disk. Ovdje također imamo cijelu platformu u Kubernetesu, a komponenta s Postgresom je zasebna (iako će jednog dana biti tu). Dakle, sve je ovako: instanca je pala, ali smo sačuvali njen PV i jednostavno ga spojili na drugu (novu) instancu, kao da se ništa nije dogodilo.
DS: S moje točke gledišta, mi stvaramo podove u Kubernetesu. K8s - elastična: čvorovi se naručuju po potrebi. Zadatak je jednostavno kreirati pod i reći da mu je potrebno X resursa, a onda će K8s sam to shvatiti. Ali podrška za pohranu u Kubernetesu i dalje je nestabilna: U (ovo izdanje je objavljeno недели prije) ove značajke postaju samo beta.
Proći će šest mjeseci do godinu dana - postat će koliko-toliko stabilan, ili će se barem takvim proglasiti. Tada mogućnost snimanja i promjene veličine u potpunosti rješava vaš problem. Jer imate bazu. Da, možda nije jako brz, ali brzina ovisi o tome što je "ispod haube", jer neke implementacije mogu kopirati i kopirati na pisanje na razini podsustava diska.
NS: Također je potrebno da svi motori (Amazon, Google...) počnu podržavati ovu verziju - to također traje neko vrijeme.
DS: Još ih ne koristimo. Mi koristimo naše.
Lokalni razvoj za Kubernetes
NS: Jeste li naišli na takvu želju kada trebate instalirati sve podove na jedan stroj i napraviti tako mali test. Kako biste brzo dobili dokaz koncepta, provjerite radi li aplikacija u Kubernetesu, bez izdvajanja hrpe strojeva za nju. Postoji Minikube, zar ne?
DS: Čini mi se da se u ovom slučaju - raspoređenom na jednom čvoru - radi isključivo o lokalnom razvoju. Ili neke manifestacije takvog obrasca. Jesti tamo , . Idemo prema korištenju Kubernetes IN Dockera. Sada smo počeli raditi s njim za testove.
NS: Nekad sam mislio da je ovo pokušaj da se sve mahune zamotaju u jednu Docker sliku. No, pokazalo se da je riječ o nečem sasvim drugom. U svakom slučaju, postoje zasebni spremnici, zasebni podovi - samo u Dockeru.
DS: Da. I napravljena je prilično smiješna imitacija, ali značenje je sljedeće... Imamo pomoćni program za implementaciju - . Želimo to učiniti uvjetnim načinom rada werf up: "Nabavite mi lokalni Kubernetes." I onda tamo pokrenite uvjet werf follow. Zatim će programer moći uređivati IDE, a proces će se pokrenuti u sustavu koji vidi promjene i ponovno gradi slike, ponovno ih postavljajući na lokalne K8. Na ovaj način želimo pokušati riješiti problem lokalnog razvoja.
Snimke i kloniranje baze podataka u stvarnosti K8s
NS: Ako se vratimo na copy-on-write. Primijetio sam da i oblaci imaju snimke. Oni rade drugačije. Na primjer, u GCP-u: imate instancu od više terabajta na istočnoj obali Sjedinjenih Država. Povremeno snimate snimke. Uzmete kopiju diska na zapadnoj obali sa snimke - za nekoliko minuta sve je spremno, radi vrlo brzo, samo treba popuniti cache u memoriji. Ali ti klonovi (snimke) služe za 'proviziju' novog volumena. Ovo je super kada trebate stvoriti mnogo instanci.
Ali za testove, čini mi se da vam snimke, o kojima vi govorite u Dockeru ili ja govorim u ZFS-u, btrfs-u pa čak i LVM-u... - dopuštaju da ne stvarate stvarno nove podatke na jednom stroju. U oblaku ćete ih i dalje plaćati svaki put i čekati ne sekunde, već minute (i u kućištu , eventualno sat).
Umjesto toga, možete dobiti ove podatke za sekundu ili dvije, pokrenuti test i odbaciti ih. Ove snimke rješavaju različite probleme. U prvom slučaju - za povećanje i dobivanje novih replika, au drugom - za testove.
DS: Ne slažem se. Učiniti da kloniranje volumena radi ispravno zadatak je oblaka. Nisam gledao njihovu implementaciju, ali znam kako to radimo na hardveru. Imamo Ceph, dopušta bilo koji fizički volumen () reci klon i dobiti drugi volumen s istim karakteristikama za desetke milisekundi, 'ami, itd. Morate shvatiti da unutra postoji lukav način kopiranja na pisanje. Zašto oblak ne bi učinio isto? Siguran sam da to pokušavaju učiniti na ovaj ili onaj način.
NS: Ali svejedno će im trebati sekunde, deseci sekundi da pokrenu instancu, dovedu Docker tamo, itd.
DS: Zašto je potrebno pokrenuti cijelu instancu? Imamo instancu s 32 jezgre, 16... i u nju stane - npr. četiri. Kad naručimo peti, instanca će već biti podignuta, a zatim će biti izbrisana.
NS: Da, zanimljivo, ispada da je Kubernetes druga priča. Naša baza podataka nije u K8s, a imamo jedan primjer. Ali kloniranje baze podataka od više terabajta ne traje više od dvije sekunde.
DS: Ovo je super. Ali moja početna poenta je da ovo nije generičko rješenje. Da, super je, ali prikladno je samo za Postgres i samo na jednom čvoru.
NS: Pogodan je ne samo za Postgres: ovi planovi, kao što sam opisao, funkcionirat će samo u njemu. Ali ako se ne zamaramo planovima, a potrebni su nam samo svi podaci za funkcionalno testiranje, onda je ovo prikladno za bilo koji DBMS.
DS: Prije mnogo godina napravili smo nešto slično na LVM snimkama. Ovo je klasika. Ovaj pristup je vrlo aktivno korišten. Stalni čvorovi su samo bol. Jer ne treba ih ispuštati, treba ih se uvijek sjećati...
NS: Vidite li ovdje ikakvu mogućnost hibrida? Recimo, stateful je neka vrsta pod, radi za nekoliko ljudi (mnogo testera). Imamo jedan volumen, ali zahvaljujući datotečnom sustavu, klonovi su lokalni. Ako kapsula padne, ali disk ostane, kapsula će se podići, prebrojati informacije o svim klonovima, ponovno sve podići i reći: "Evo tvojih klonova koji rade na ovim portovima, nastavi raditi s njima."
DS: Tehnički to znači da je unutar Kubernetesa jedan pod unutar kojeg pokrećemo mnogo Postgresa.
NS: Da. On ima ograničenje: recimo da s njim ne radi više od 10 ljudi u isto vrijeme. Ako vam treba 20, pokrenut ćemo drugu takvu kapsulu. U potpunosti ćemo ga klonirati, nakon što smo dobili drugi puni volumen, imat će istih 10 "tankih" klonova. Zar ne vidite ovu priliku?
DS: Ovdje moramo dodati sigurnosna pitanja. Ova vrsta organizacije podrazumijeva da ovaj pod ima visoke privilegije (mogućnosti), jer može izvoditi nestandardne operacije na datotečnom sustavu... Ali ponavljam: vjerujem da će u srednjem roku u Kubernetesu popraviti pohranu, u oblaci oni će srediti cijelu priču s volumenima - sve će “samo raditi”. Bit će promjene veličine, kloniranja... Postoji volumen - kažemo: "Stvorite novi na temelju toga", i nakon sekunde i pol dobijemo što nam treba.
NS: Ne vjerujem u jednu i pol sekundu za mnogo terabajta. Na Cephu to radiš sam, ali pričaš o oblacima. Idite u oblak, napravite klon višeterabajtnog EBS volumena na EC2 i pogledajte kakve će biti performanse. Neće trajati nekoliko sekundi. Baš me zanima kada će doći do ove razine. Razumijem što govorite, ali molim da se ne razlikujem.
DS: Dobro, ali rekao sam srednjoročno, ne kratkoročno. Već nekoliko godina.
O operatoru za PostgreSQL iz Zalanda
Usred ovog sastanka, Alexey Klyukin, bivši programer iz Zalanda, također se pridružio i govorio o povijesti PostgreSQL operatora:
Super je što se ova tema općenito dotiče: i Postgres i Kubernetes. Kada smo to počeli raditi u Zalandu 2017., to je bila tema koju su svi htjeli raditi, ali nitko nije. Svi su već imali Kubernetes, ali kad su pitali što da rade s bazama podataka, čak se i ljudima sviđa , koji je propovijedao K8s, rekao je otprilike ovo:
“Idite na upravljane usluge i koristite ih, nemojte pokretati bazu podataka u Kubernetesu. U protivnom će vaš K8 odlučiti, na primjer, izvršiti nadogradnju, isključiti sve čvorove i vaši će podaci odletjeti daleko, daleko.”
Odlučili smo napraviti operatora koji će, suprotno ovom savjetu, pokrenuti Postgres bazu u Kubernetesu. A imali smo dobar razlog - . Ovo je automatski failover za PostgreSQL, izveden ispravno, tj. koristeći etcd, consul ili ZooKeeper kao pohranu informacija o klasteru. Takav repozitorij koji će svima koji pitaju, primjerice, tko je trenutni vođa, dati istu informaciju – unatoč tome što imamo sve raspoređeno – da ne dođe do cijepanja mozga. Plus imali smo za njega.
Općenito, potreba tvrtke za automatskim prebacivanjem u slučaju kvara pojavila se nakon migracije s internog hardverskog podatkovnog centra na oblak. Cloud se temeljio na vlastitom PaaS (Platform-as-a-Service) rješenju. To je Open Source, ali bilo je potrebno mnogo rada da se pokrene i pokrene. Zvalo se .
U početku nije postojao Kubernetes. Točnije, kada je naše vlastito rješenje implementirano, K8 je već postojao, ali je bio toliko sirov da nije bio pogodan za proizvodnju. Bilo je to, po meni, 2015. ili 2016. godine. Do 2017. Kubernetes je postao više-manje zreo — postojala je potreba za migracijom tamo.
A već smo imali Docker spremnik. Postojao je PaaS koji je koristio Docker. Zašto ne probati K8s? Zašto ne biste napisali vlastitog operatera? Murat Kabilov, koji nam je došao iz Avita, pokrenuo je ovo kao projekt samoinicijativno - "za igru" - i projekt je "uzeo maha".
Ali općenito, želio sam razgovarati o AWS-u. Zašto je postojao povijesni kod povezan s AWS-om...
Kada pokrenete nešto u Kubernetesu, morate shvatiti da je K8s takav rad u tijeku. Neprestano se razvija, poboljšava, pa čak i kvari s vremena na vrijeme. Morate pomno pratiti sve promjene u Kubernetesu, morate biti spremni zaroniti u to ako se nešto dogodi i naučiti kako to radi do detalja - možda i više nego što biste željeli. To se, u principu, odnosi na bilo koju platformu na kojoj pokrećete svoje baze podataka...
Dakle, kada smo radili izjavu, imali smo Postgres koji radi na vanjskom volumenu (EBS u ovom slučaju, budući da smo radili na AWS-u). Baza podataka je rasla, u nekom trenutku je bilo potrebno promijeniti veličinu: na primjer, početna veličina EBS-a bila je 100 TB, baza je narasla do toga, sada želimo napraviti EBS 200 TB. Kako? Recimo da možete napraviti dump/restore na novoj instanci, ali to će potrajati dugo i uključivati prekid rada.
Stoga sam želio promjenu veličine koja bi povećala EBS particiju i zatim rekla sustavu datoteka da koristi novi prostor. I uspjeli smo, ali u to vrijeme Kubernetes nije imao API za operaciju promjene veličine. Budući da smo radili na AWS-u, napisali smo kod za njegov API.
Nitko vas ne sprječava da učinite isto za druge platforme. Nema naznake u izjavi da se može pokrenuti samo na AWS-u i da neće raditi na svemu ostalom. Općenito, ovo je Open Source projekt: ako netko želi ubrzati pojavu korištenja novog API-ja, dobrodošli ste. Jesti , pull zahtjevi - Zalando tim nastoji odgovoriti na njih prilično brzo i promovirati operatera. Koliko ja znam, projekt na Google Summer of Code i nekim drugim sličnim inicijativama. Zalando vrlo aktivno radi na tome.
PS bonus!
Ako ste zainteresirani za temu PostgreSQL i Kubernetes, imajte na umu da je sljedeći utorak Postgres održan prošli tjedan, gdje sam razgovarao s Nikolajem Aleksandar Kukuškin iz Zalanda. Video s njega je dostupan .
PPS
Pročitajte i na našem blogu:
- «»;
- «»;
- «»;
- «".
Izvor: www.habr.com