Krajem prošle godine održan je još jedan direktan prenos ruske PostgreSQL zajednice , tokom kojeg je njen suosnivač Nikolaj Samokhvalov razgovarao sa tehničkim direktorom Flanta Dmitrijem Stoljarovom o ovom DBMS-u u kontekstu Kubernetesa.
Objavljujemo transkript glavnog dijela ove rasprave, a na Kompletan video objavljen:
Baze podataka i Kubernetes
NS: O VAKUUMU i KONTROLNIM TAČKAMA danas nećemo. Želimo da razgovaramo o Kubernetesu. Znam da imate dugogodišnje iskustvo. Gledao sam vaše video zapise, pa čak i ponovo neke od njih... Hajdemo odmah na stvar: zašto uopće Postgres ili MySQL u K8s?
DC: Ne postoji i ne može biti definitivnog odgovora na ovo pitanje. Ali općenito, ovo je jednostavnost i praktičnost... potencijal. Svi žele upravljane usluge.
NS: Kako , samo kod kuće?
DC: Da: kao RDS, samo bilo gdje.
NS: “Bilo gdje” je dobra poenta. U velikim kompanijama sve se nalazi na različitim mjestima. Zašto onda, ako se radi o velikoj kompaniji, ne uzeti gotovo rješenje? Na primjer, Nutanix ima svoj razvoj, druge kompanije (VMware...) imaju isti „RDS, samo kod kuće“.
DC: Ali govorimo o zasebnoj implementaciji koja će raditi samo pod određenim uslovima. A ako govorimo o Kubernetesu, onda postoji ogromna raznolikost infrastrukture (koja može biti u K8s). U suštini ovo je standard za API-je u oblaku...
NS: Takođe je besplatno!
DC: Nije toliko važno. Sloboda je važna za ne baš veliki segment tržišta. Još nešto je važno... Verovatno se sećate izveštaja “"?"
NS: Da.
DC: Shvatio sam da je primljeno veoma dvosmisleno. Neki su mislili da ja govorim: „Momci, dajte sve baze podataka u Kubernetes!“, dok su drugi zaključili da su to sve strašni bicikli. Ali htio sam reći nešto sasvim drugo: „Pogledajte šta se dešava, kakvi problemi postoje i kako se mogu riješiti. Trebamo li sada koristiti Kubernetes baze podataka? Proizvodnja? Pa, samo ako voliš...da radiš određene stvari. Ali za dev, mogu reći da ga preporučujem. Za dev, dinamizam kreiranja/brisanja okruženja je veoma važan.”
NS: Pod dev mislite na sva okruženja koja nisu prod? Inscenacija, QA…
DC: Ako govorimo o perf stalcima, onda vjerovatno ne, jer su zahtjevi tamo specifični. Ako govorimo o posebnim slučajevima u kojima je potrebna veoma velika baza podataka za stažiranje, onda verovatno ne... Ako je ovo statično, dugovečno okruženje, koja je onda korist od toga da se baza podataka nalazi u K8s?
NS: Ništa. Ali gdje vidimo statična okruženja? Statičko okruženje će sutra postati zastarjelo.
DC: Postavljanje može biti statičko. Imamo klijente...
NS: Da, imam i ja. Veliki je problem ako imate 10 TB bazu podataka i 200 GB staging...
DC: Imam jako cool kofer! Prilikom postavljanja postoji baza podataka proizvoda u kojoj se vrše promjene. A tu je i dugme: „prebaciti u proizvodnju“. Ove promjene - delte - se dodaju (izgleda da su jednostavno sinkronizirane preko API-ja) u proizvodnji. Ovo je vrlo egzotična opcija.
NS: Video sam startape u Valley-u koji sjede u RDS-u ili čak u Heroku-u - ovo su priče od prije 2-3 godine - i preuzimaju dump na svoj laptop. Jer baza podataka je i dalje samo 80 GB, a prostora na laptopu ima. Zatim kupuju dodatne diskove za svakoga tako da imaju 3 baze podataka za obavljanje različitih razvoja. I ovako se to dešava. Također sam vidio da se ne plaše kopirati prod u scenu - to uvelike zavisi od kompanije. Ali vidio sam i da se jako plaše, i da često nemaju dovoljno vremena i ruku. Ali prije nego što pređemo na ovu temu, želim čuti nešto o Kubernetesu. Da li sam dobro shvatio da još niko nije u produkciji?
DC: Imamo male baze podataka u prod. Riječ je o količinama od desetine gigabajta i nekritičnim servisima za koje smo bili lijeni da pravimo replike (a nema takve potrebe). I pod uslovom da postoji normalno skladište pod Kubernetesom. Ova baza podataka je radila u virtuelnoj mašini - uslovno u VMware-u, na vrhu sistema za skladištenje podataka. Stavili smo ga unutra i sada ga možemo prenijeti sa mašine na mašinu.
NS: Baze podataka ove veličine, do 100 GB, mogu se pokrenuti za nekoliko minuta na dobrim diskovima i dobroj mreži, zar ne? Brzina od 1 GB u sekundi više nije egzotična.
DC: Da, za linearni rad to nije problem.
NS: Dobro, samo moramo razmišljati o prod. A ako razmatramo Kubernetes za ne-proizvodna okruženja, šta da radimo? Vidim to u Zalandu , u Crunchy , postoje neke druge opcije. I postoji - ovo je naš dobar prijatelj Alvaro iz Španije: ono što oni rade u suštini nije pravedno , i cijela distribucija (), u koji su pored samog Postgresa odlučili ubaciti i backup, Envoy proxy...
DC: Izaslanik za šta? Balansiranje Postgres prometa konkretno?
NS: Da. Odnosno, oni to vide kao: ako uzmete Linux distribuciju i kernel, onda je običan PostgreSQL kernel, i oni žele da naprave distribuciju koja će biti prilagođena oblaku i pokretana na Kubernetes-u. Oni sastavljaju komponente (sigurne kopije, itd.) i otklanjaju greške tako da dobro rade.
DC: Veoma cool! U suštini ovo je softver za kreiranje vašeg vlastitog upravljanog Postgresa.
NS: Linux distribucije imaju vječne probleme: kako napraviti drajvere da sav hardver bude podržan. I imaju ideju da će raditi u Kubernetesu. Znam da smo kod operatera Zalando nedavno vidjeli vezu sa AWS-om i to više nije dobro. Ne bi trebalo da postoji veza sa određenom infrastrukturom – koja je onda svrha?
DC: Ne znam tačno u kakvu je situaciju Zalando dospeo, ali u Kubernetes skladište je sada napravljeno tako da je nemoguće napraviti rezervnu kopiju diska generičkom metodom. Nedavno u standardnoj - najnovijoj verziji — omogućili smo snimke, ali gdje je to implementirano? Iskreno, još je sve tako sirovo... Probamo CSI na vrhu AWS, GCE, Azure, vSphere, ali čim počnete da ga koristite, vidite da još nije spreman.
NS: Zato se ponekad moramo oslanjati na infrastrukturu. Mislim da je ovo još uvijek rana faza – bolovi u rastu. Pitanje: Šta biste savjetovali početnicima koji žele isprobati PgSQL u K8s? Koji operater možda?
DC: Problem je što nam je Postgres 3%. Imamo i veoma veliku listu različitog softvera u Kubernetesu, neću ni da navodim sve. Na primjer, Elasticsearch. Postoji mnogo operatera: neki se aktivno razvijaju, drugi ne. Za sebe smo sastavili zahtjeve o tome šta operater treba da ima da bismo to shvatili ozbiljno. U operateru posebno za Kubernetes - ne u "operateru da uradi nešto u Amazonovim uslovima"... U stvari, mi prilično široko (= skoro svi klijenti) koristimo jednog operatera - (uskoro ćemo objaviti članak o njemu).
NS: A nije ni za MySQL? Znam da Percona... pošto sada rade na MySQL, MongoDB i Postgresu, moraće da naprave nekakvo univerzalno rešenje: za sve baze podataka, za sve cloud provajdere.
DC: Nismo imali vremena da pogledamo operatore za MySQL. Ovo trenutno nije naš glavni fokus. MySQL radi dobro samostalno. Zašto koristiti operator ako možete samo pokrenuti bazu podataka... Možete pokrenuti Docker kontejner sa Postrges-om ili ga možete pokrenuti na jednostavan način.
NS: Bilo je i pitanje o ovome. Uopšte nema operatera?
DC: Da, 100% nas ima PostgreSQL koji radi bez operatera. Za sada. Aktivno koristimo operatera za Prometheus i Redis. Planiramo da pronađemo operatera za Elasticsearch - on je onaj koji najviše "gori", jer želimo da ga instaliramo u Kubernetes u 100% slučajeva. Baš kao što želimo osigurati da je MongoDB također uvijek instaliran u Kubernetes. Ovdje se pojavljuju određene želje - postoji osjećaj da se u tim slučajevima nešto može učiniti. A nismo ni pogledali Postgres. Naravno, znamo da postoje različite opcije, ali u stvari imamo samostalnu.
DB za testiranje u Kubernetesu
NS: Pređimo na temu testiranja. Kako uvesti promjene u bazu podataka - iz DevOps perspektive. Ima mikroservisa, 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 tvoj pristup?
DC: Ne može biti jedan odgovor. Postoji nekoliko opcija. Prva je veličina baze koju želimo razvaljati. Sami ste spomenuli da kompanije imaju različite stavove prema tome da imaju kopiju baze podataka proizvoda na dev i bini.
NS: A pod uslovima GDPR-a, mislim da su sve oprezniji... Mogu reći da su u Evropi već počeli da izriču kazne.
DC: Ali često možete napisati softver koji uzima dump iz proizvodnje i zamagljuje ga. Dobijaju se prod podaci (snapshot, dump, binarna kopija...), ali su anonimizirani. Umjesto toga, mogu postojati skripte za generiranje: to mogu biti fiksne postavke ili samo skripta koja generiše veliku bazu podataka. Problem je: koliko vremena je potrebno za kreiranje osnovne slike? I koliko vremena je potrebno da se postavi u željeno okruženje?
Došli smo do šeme: ako klijent ima fiksni skup podataka (minimalna verzija baze podataka), onda ih koristimo po defaultu. Ako govorimo o okruženjima za recenzije, kada smo kreirali granu, postavili smo instancu aplikacije - tu smo izbacili malu bazu podataka. Ali ispalo je dobro , kada jednom dnevno (noću) uzmemo dump iz proizvodnje i napravimo Docker kontejner sa PostgreSQL-om i MySQL-om sa ovim učitanim podacima na osnovu njega. Ako trebate proširiti bazu podataka 50 puta sa ove slike, to se radi prilično jednostavno i brzo.
NS: Jednostavnim kopiranjem?
DC: Podaci se pohranjuju direktno u Docker sliku. One. Imamo gotovu sliku, doduše 100 GB. Zahvaljujući slojevima u Dockeru, ovu sliku možemo brzo postaviti onoliko puta koliko nam je potrebno. Metoda je glupa, ali dobro funkcionira.
NS: Onda, kada testirate, mijenja se u Dockeru, zar ne? Copy-on-write unutar Docker-a - bacite ga i idite ponovo, sve je u redu. Klasa! I da li ga već koristite u potpunosti?
DC: Dugo vremena.
NS: Radimo vrlo slične stvari. Samo što ne koristimo Dockerov copy-on-write, već neki drugi.
DC: Nije generički. A Docker radi svuda.
NS: U teoriji, da. Ali tu imamo i module, možete napraviti različite module i raditi sa različitim sistemima datoteka. Kakav trenutak ovde. Sa strane Postgresa, na sve ovo gledamo drugačije. Sada sam pogledao sa strane Dockera i vidio da sve radi za vas. Ali ako je baza podataka ogromna, na primjer, 1 TB, onda sve ovo traje dugo: operacije noću, i trpanje svega u Docker... A ako se 5 TB ugura u Docker... Ili je sve u redu?
DC: Koja je razlika: ovo su mrlje, samo bitovi i bajtovi.
NS: Razlika je u ovome: da li to radite kroz dump i restauraciju?
DC: Uopšte nije potrebno. Metode za generiranje ove slike mogu biti različite.
NS: Za neke klijente smo napravili tako da umjesto redovnog generisanja osnovne slike, stalno je ažuriramo. U suštini je replika, ali ne prima podatke direktno od mastera, već kroz arhivu. Binarna arhiva u kojoj se svaki dan preuzimaju WAL-ovi, gdje se prave sigurnosne kopije... Ovi WAL-ovi onda sa malim zakašnjenjem (bukvalno 1-2 sekunde) stižu do osnovne slike. Kloniramo ga na bilo koji način - sada imamo ZFS po defaultu.
DC: Ali sa ZFS-om ste ograničeni na jedan čvor.
NS: Da. Ali ZFS ima i magiju : s njim možete poslati snimak, pa čak (ja ovo još nisam stvarno testirao, ali...) možete poslati delta između dva PGDATA. U stvari, imamo još jedan alat koji zapravo nismo razmatrali za takve zadatke. PostgreSQL ima , koji radi kao "pametni" rsync, preskačući mnogo toga što ne morate gledati, jer se tu ništa nije promijenilo. Možemo izvršiti brzu sinhronizaciju između dva servera i premotati na isti način.
Dakle, sa ove, više DBA strane, pokušavamo da napravimo alat koji nam omogućava da uradimo isto što ste rekli: imamo jednu bazu podataka, ali želimo da testiramo nešto 50 puta, skoro istovremeno.
DC: 50 puta znači da morate naručiti 50 Spot instanci.
NS: Ne, sve radimo na jednoj mašini.
DC: Ali kako ćete proširiti 50 puta ako je ova baza podataka, recimo, terabajta. Najvjerovatnije joj treba uvjetnih 256 GB RAM-a?
NS: Da, ponekad vam treba puno memorije - to je normalno. Ali ovo je primjer iz života. Proizvodna mašina ima 96 jezgara i 600 GB. Istovremeno se za bazu podataka koriste 32 jezgra (ponekad čak 16 jezgara) i 100-120 GB memorije.
DC: I tu stane 50 primjeraka?
NS: Dakle, postoji samo jedna kopija, onda copy-on-write (ZFS) radi... Reći ću vam detaljnije.
Na primjer, imamo bazu podataka od 10 TB. Napravili su disk za njega, ZFS je takođe komprimovao njegovu veličinu za 30-40 posto. Budući da ne radimo testiranje opterećenja, nije nam važno tačno vrijeme odziva: neka bude do 2 puta sporije - u redu je.
Dajemo priliku programerima, QA, DBA itd. izvršiti testiranje u 1-2 niti. Na primjer, mogu pokrenuti neku vrstu migracije. Ne zahtijeva 10 jezgara 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 alocirana jezgra, tako da 10 ljudi može raditi u isto vrijeme, nema problema.
Jer fizički PGDATA isto, ispada da zapravo obmanjujemo Postgres. Trik je sljedeći: na primjer, 10 Postgresa se pokreće istovremeno. Šta je obično problem? Oni su stavili , recimo 25%. Prema tome, ovo je 200 GB. Nećete moći pokrenuti više od tri, jer će memorija ponestati.
Ali u nekom trenutku smo shvatili da to nije potrebno: postavili smo shared_buffers na 2 GB. PostgreSQL ima , a u stvarnosti jedino on utiče . Postavili smo ga na 0,5 TB. I nije važno što oni zapravo ne postoje: on pravi planove kao da postoje.
Shodno tome, kada testiramo neku vrstu migracije, možemo prikupiti sve planove - vidjećemo kako će se to odvijati u proizvodnji. Sekunde će tamo biti drugačije (sporije), ali podaci koje zapravo čitamo, i sami planovi (koji JOIN-ovi su tu, itd.) ispadaju potpuno isti kao u produkciji. I možete izvoditi mnoge takve provjere paralelno na jednoj mašini.
DC: Zar ne mislite da ovdje ima nekoliko problema? Prvo je rješenje koje radi samo na PostgreSQL-u. Ovaj pristup je vrlo privatan, nije generički. Drugi je da Kubernetes (i sve što tehnologije oblaka sada idu) uključuje mnogo čvorova, a ti čvorovi su efemerni. A u vašem slučaju to je uporni čvor sa stanjem. Ove stvari me čine konfliktnim.
NS: Prvo, slažem se, ovo je čisto Postgres priča. Mislim da ako imamo neku vrstu direktnog IO-a i bafera za skoro svu memoriju, ovaj pristup neće raditi - planovi će biti drugačiji. Ali za sada radimo samo sa Postgresom, ne razmišljamo o drugima.
O Kubernetesu. I sami nam svuda govorite da imamo postojanu bazu podataka. Ako instanca ne uspije, glavna stvar je sačuvati disk. Ovde takođe imamo celu platformu u Kubernetesu, a komponenta sa Postgresom je odvojena (iako će biti tamo jednog dana). Dakle, sve je ovako: instanca je pala, ali smo njen PV sačuvali i jednostavno spojili na drugu (novu) instancu, kao da se ništa nije dogodilo.
DC: Sa moje tačke gledišta, mi kreiramo podove u Kubernetesu. K8s - elastična: čvorovi se naručuju po potrebi. Zadatak je jednostavno kreirati pod i reći da mu je potrebna X količina resursa, a onda će K8s to sam shvatiti. Ali podrška za skladištenje u Kubernetesu je još uvijek nestabilna: , in (ovo izdanje je objavljeno nedelje prije) ove funkcije su postale samo beta.
Proći će šest mjeseci do godinu dana - postaće manje-više stabilan, ili će se barem tako proglasiti. Tada mogućnost snimka i promjene veličine u potpunosti rješava vaš problem. Jer imate bazu. Da, možda nije jako brzo, ali brzina zavisi od toga šta je „ispod haube“, jer neke implementacije mogu kopirati i kopirati-na-pisati na nivou podsistema diska.
NS: Također je potrebno da svi motori (Amazon, Google...) počnu podržavati ovu verziju - i to traje neko vrijeme.
DC: Još ih ne koristimo. Koristimo naše.
Lokalni razvoj za Kubernetes
NS: Da li ste naišli na takvu želju kada trebate instalirati sve podove na jednu mašinu i napraviti tako mali test. Da biste brzo dobili dokaz koncepta, pogledajte da aplikacija radi u Kubernetes-u, bez da za nju posvetite gomilu mašina. Tu je Minikube, zar ne?
DC: Čini mi se da je ovaj slučaj - raspoređen na jednom čvoru - isključivo o lokalnom razvoju. Ili neke manifestacije takvog obrasca. Jedi , postoji , . Idemo na korištenje Kubernetes IN Docker-a. Sada smo počeli raditi s njim za testove.
NS: Nekada sam mislio da je ovo pokušaj da se svi podovi umotaju u jednu Docker sliku. Ali pokazalo se da se radi o nečem sasvim drugom. U svakom slučaju, postoje odvojeni kontejneri, odvojeni podovi - samo u Dockeru.
DC: Da. I napravljena je prilično smiješna imitacija, ali značenje je ovo... Imamo uslužni program za implementaciju - . Želimo da to bude uslovni način rada werf up: "Nabavite mi lokalni Kubernetes." I onda tamo pokrenite uslov werf follow. Tada će programer moći uređivati IDE, a proces će biti pokrenut u sistemu koji vidi promjene i ponovo gradi slike, premještajući ih na lokalne K8s. Na ovaj način želimo pokušati riješiti problem lokalnog razvoja.
Snimci i kloniranje baze podataka u K8s stvarnosti
NS: Ako se vratimo na kopiranje na pisanje. Primetio sam da i oblaci imaju snimke. Oni rade drugačije. Na primjer, u GCP: imate instancu od više terabajta na istočnoj obali Sjedinjenih Država. Povremeno pravite snimke. Pokupite kopiju diska na zapadnoj obali sa snimka - za nekoliko minuta sve je spremno, radi vrlo brzo, samo treba popuniti keš memoriju. Ali ovi klonovi (snimci) služe za 'omogućavanje' novog volumena. Ovo je super kada treba da kreirate mnogo instanci.
Ali za testove, čini mi se da snimci, o kojima vi govorite u Dockeru ili ja govorim u ZFS-u, btrfs-u pa čak i LVM-u... - omogućavaju vam da ne kreirate zaista nove podatke na jednoj mašini. U oblaku ćete ih i dalje plaćati svaki put i čekati ne sekunde, već minute (i u slučaju , eventualno sat).
Umjesto toga, možete dobiti ove podatke za sekundu ili dvije, pokrenuti test i baciti ih. Ovi snimci rješavaju različite probleme. U prvom slučaju - za povećanje i dobijanje novih replika, au drugom - za testove.
DC: Ne slažem se. Zadatak oblaka je da kloniranje volumena funkcionira ispravno. Nisam gledao njihovu implementaciju, ali znam kako to radimo na hardveru. Imamo Ceph, dozvoljava bilo koji fizički volumen () reci Klon i dobiti drugi volumen sa istim karakteristikama za desetine milisekundi, 'ami, itd. Morate shvatiti da se unutra krije škakljivo kopiranje na pisanje. Zašto oblak ne bi uradio isto? Siguran sam da pokušavaju ovo da urade na ovaj ili onaj način.
NS: Ali i dalje će im trebati sekunde, desetine sekundi da pokrenu instancu, dovedu Docker tamo, itd.
DC: Zašto je potrebno podizati cijelu instancu? Imamo instancu sa 32 jezgra, 16... i može stati u nju - na primjer, četiri. Kada naručimo petu, instanca će već biti podignuta, a zatim će biti izbrisana.
NS: Da, zanimljivo, ispostavilo se da je Kubernetes druga priča. Naša baza podataka nije u K8s, a imamo jednu instancu. Ali kloniranje baze podataka od više terabajta ne traje više od dvije sekunde.
DC: Ovo je super. Ali moja početna poenta je da ovo nije generičko rješenje. Da, to je cool, ali je pogodno samo za Postgres i samo na jednom čvoru.
NS: Pogodan je ne samo za Postgres: ovi planovi će, kao što sam opisao, funkcionirati samo u njemu. Ali ako se ne trudimo oko planova, a potrebni su nam samo svi podaci za funkcionalno testiranje, onda je ovo pogodno za bilo koji DBMS.
DC: Prije mnogo godina radili smo nešto slično na LVM snimcima. Ovo je klasika. Ovaj pristup se vrlo aktivno koristio. Čvorovi sa stanjem samo su muka. Jer ne treba ih ispustiti, treba ih uvijek pamtiti...
NS: Vidite li ikakvu mogućnost hibrida ovdje? Recimo da je stateful neka vrsta pod, radi za nekoliko ljudi (mnogo testera). Imamo jedan volumen, ali zahvaljujući sistemu datoteka, klonovi su lokalni. Ako podloga padne, ali disk ostane, podići će se, prebrojati informacije o svim klonovima, pokupiti sve ponovo i reći: "Evo vaših klonova koji rade na ovim portovima, nastavite raditi s njima."
DC: Tehnički to znači da je unutar Kubernetesa jedan pod unutar kojeg pokrećemo mnoge Postgresove.
NS: Da. On ima ograničenje: recimo da ne radi više od 10 ljudi u isto vrijeme. Ako vam treba 20, lansirat ćemo drugu takvu kapsulu. U potpunosti ćemo ga klonirati, pošto dobijemo drugi puni volumen, imat će istih 10 „tankih“ klonova. Zar ne vidite ovu priliku?
DC: Ovdje moramo dodati sigurnosne probleme. Ovakav tip organizacije podrazumijeva da ovaj pod ima visoke privilegije (sposobnosti), jer može obavljati nestandardne operacije na sistemu datoteka... Ali ponavljam: vjerujem da će u srednjoročnom periodu popraviti skladište u Kubernetes-u, a u oblaci će popraviti celu priču obimima - sve će “samo raditi”. Biće promene veličine, kloniranja... Postoji volumen - kažemo: „Kreiraj novi na osnovu toga“ i nakon sekund i po dobijamo ono što nam treba.
NS: Ne vjerujem u jednu i po sekundu za mnogo terabajta. Na Cephu to radiš sam, ali pričaš o oblacima. Idite u oblak, napravite klon EBS volumena od više terabajta na EC2 i pogledajte kakve će biti performanse. Neće potrajati nekoliko sekundi. Jako me zanima kada će dostići ovaj nivo. Razumijem šta govorite, ali se slažem sa tim.
DC: Ok, ali rekao sam srednjoročno, a ne kratkoročno. Za nekoliko godina.
O operateru za PostgreSQL iz Zalanda
Usred ovog sastanka, Alexey Klyukin, bivši programer iz Zalanda, takođe se pridružio i govorio o istoriji PostgreSQL operatera:
Odlično je što se ova tema dotiče općenito: i Postgres i Kubernetes. Kada smo to počeli da radimo u Zalandu 2017. godine, to je bila tema kojom su svi želeli da se bave, ali niko nije. Svi su već imali Kubernetes, ali kada su pitali šta da rade sa bazama podataka, čak i ljudi vole , koji je propovedao K8s, rekao je nešto ovako:
“Idite na upravljane usluge i koristite ih, nemojte pokretati bazu podataka u Kubernetesu. U suprotnom, vaši K8 će odlučiti, na primjer, izvršiti nadogradnju, isključiti sve čvorove i vaši podaci će letjeti daleko, daleko.”
Odlučili smo napraviti operatera koji će, suprotno ovom savjetu, pokrenuti Postgres bazu podataka u Kubernetesu. I imali smo dobar razlog - . Ovo je automatski prelazak na grešku za PostgreSQL, urađen korektno, tj. koristeći etcd, consul ili ZooKeeper kao skladište informacija o klasteru. Takvo spremište koje će svima koji pitaju, na primjer, šta je trenutni vođa, dati iste informacije - uprkos tome što imamo sve raspoređeno - da ne dođe do raskola mozga. Plus smo imali za njega.
Generalno, potreba kompanije za automatskim prelaskom na grešku pojavila se nakon migracije sa internog hardverskog data centra u oblak. Oblak je zasnovan na vlasničkom PaaS (Platform-as-a-Service) rješenju. To je Open Source, ali je bilo potrebno mnogo rada da se pokrene i pokrene. To se zvalo .
U početku nije postojao Kubernetes. Tačnije, kada je naše vlastito rješenje uvedeno, K8 je već postojao, ali je bio toliko sirov da nije bio pogodan za proizvodnju. Bilo je to, po mom mišljenju, 2015. ili 2016. godine. Do 2017. Kubernetes je postao manje-više zreo – postojala je potreba za migracijom tamo.
I već smo imali Docker kontejner. Postojao je PaaS koji je koristio Docker. Zašto ne probati K8s? Zašto ne napišete svog vlastitog operatera? Murat Kabilov, koji je kod nas došao iz Avita, započeo je ovo kao projekat samoinicijativno - "da se igra" - i projekat je "krenuo".
Ali generalno, želeo sam da pričam o AWS-u. Zašto je postojao istorijski kod koji se odnosi na AWS...
Kada pokrenete nešto u Kubernetesu, morate shvatiti da je K8s takav rad u toku. Neprestano se razvija, poboljšava, pa čak s vremena na vrijeme i kvari. Morate pomno pratiti sve promjene u Kubernetesu, morate biti spremni da zaronite u to ako se nešto dogodi i naučite kako to funkcionira do detalja - možda više nego što biste željeli. Ovo 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 eksternom volumenu (EBS u ovom slučaju, pošto smo radili na AWS-u). Baza podataka je rasla, u nekom trenutku je bilo potrebno promijeniti njenu veličinu: na primjer, početna veličina EBS-a je bila 100 TB, baza podataka je porasla do nje, 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 zastoje.
Stoga sam želio promjenu veličine koja bi povećala EBS particiju i zatim rekla sistemu datoteka da koristi novi prostor. I mi smo to uradili, ali u to vreme Kubernetes nije imao nikakav API za operaciju promene veličine. Pošto smo radili na AWS-u, napisali smo kod za njegov API.
Niko vas ne brani da učinite isto za druge platforme. U izjavi nema nagoveštaja da se može pokrenuti samo na AWS-u i da neće raditi na svemu ostalom. Generalno, ovo je projekat otvorenog koda: ako neko želi da ubrza nastanak upotrebe novog API-ja, dobrodošli ste. Jedi , pull zahtjevi - Zalando tim pokušava odgovoriti na njih prilično brzo i promovirati operatera. Koliko ja znam, projekat na Google Summer of Code i nekim drugim sličnim inicijativama. Zalando vrlo aktivno radi na tome.
PS Bonus!
Ako ste zainteresovani za temu PostgreSQL-a i Kubernetes-a, imajte na umu da je sledeći Postgres utorak održan prošle nedelje, gde sam razgovarao sa Nikolajem Aleksandar Kukuškin iz Zalanda. Video sa njega je dostupan .
PPS
Pročitajte i na našem blogu:
- «»;
- «»;
- «»;
- «".
izvor: www.habr.com