Na koncu prejšnjega leta je potekal še en neposredni prenos ruskega PostgreSQL društva , v okviru katerega je njegov soustanovitelj Nikolaj Samohvalov govoril s tehničnim direktorjem „Flanta“ Dmitrijem Stolyarovim o tej SGBD v kontekstu Kubernetes.
Objavljamo prepis glavnega dela te razprave, na je objavljen celoten video zapis:
Baze podatkov in Kubernetes
NS: Danes se ne bomo pogovarjali o VACUUM in CHECKPOINT-ih. Želimo govoriti o Kubernetesu. Vem, da imaš že dolgoletne izkušnje. Gledal sem tvoje videe in nekatere celo večkrat… Pojdimo takoj k stvari: zakaj sploh Postgres ali MySQL v K8s?
DS: Enotnega odgovora na to vprašanje ni in tudi ne more biti. Vendar pa gre na splošno za enostavnost in udobje… potencialno. Vsem seveda želi, da bi imeli upravljane storitve.
NS: Tako kot , samo pri sebi?
DS: Da: tako kot RDS, samo kjer koli.
NS: „Kjer koli“ — to je dobra pripomba. V velikih podjetjih je vse razporejeno na različnih mestih. Zakaj torej, če gre za veliko podjetje, ne bi vzeli že pripravljenega rešitve? Na primer, Nutanix ima svoje rešitve, druge družbe (VMware…) pa prav tako — „RDS, samo pri sebi“.
DS: A vendar govorimo o posamezni različici, ki bo delovala le pod določenimi pogoji. Če pa govorimo o Kubernetesu, je tu ogromna različnost infrastrukture (ki lahko obstaja v K8s). V bistvu je to standard za API do oblakov…
NS: In še brezplačno!
DS: To ni tako pomembno. Brezplačnost je pomembna le za manjši segment trga. Pomembno je drugo… Verjetno se spomniš moje predstavitve „»?
NS: Da.
DS: Ugotovil sem, da je bila sprejeta zelo nekonsistentno. Del ljudi je mislil, da govorim: „Fantje, gremo vse DB v Kubernetes!“, – drugi pa so se odločili, da so to vse grozni kolesa. Jaz pa sem želel govoriti o nečem povsem drugem: „Poglejte, kaj se dogaja, kakšne so težave in kako jih je mogoče rešiti. Ali sedaj iti z bazami v Kubernetes? Na produkcijo? No, le če radi … delate določene stvari. A za dev-a — lahko rečem, da priporočam. Za dev-a je zelo pomembna dinamika ustvarjanja/brisanja okolij.
NS: Pod dev-om misliš vse okolje, ki niso prod? Staging, QA…
DS: Če govorimo o perf-stendih, verjetno ni več, saj so tam zahteve specifične. Če govorimo o posebnih primerih, kjer je na stagingu potrebna zelo velika baza podatkov, potem tudi morda ne ... Če gre za statično okolje, ki dolgotrajno obstaja, kakšna je torej korist, da je baza nameščena v K8s?
NS: Nobene. Ampak kje običajno vidimo statična okolja? Statično okolje je že jutri zastaralo.
DS: Staging je lahko statičen. Imamo stranke ...
NS: Ja, tudi jaz imam. Velik problem je, če imaš bazo na 10 TB, staging pa 200 GB ...
DS: Imam zelo kul primer! Na stagingu je produkcijska baza, v katero se vnesejo spremembe. In predvidena je gumb: 'izvesti v produkcijo'. Te spremembe — delte — so dodane (zdi se, da se preprosto sinhronizirajo po API-ju) v produkcijo. To je zelo eksotična različica.
NS: Videla sem zagonska podjetja v Dolini, ki so še vedno v RDS-ju ali celo v Heroku — to so zgodbe starih 2-3 let — in si prenesejo dump na svoj prenosnik. Ker baza zaenkrat ima le 80 GB, na prenosniku pa je dovolj prostora. Potem kupujejo diske, da imajo po 3 baze, da lahko izvajajo različne projekte. Tudi to se zgodi. Prav tako sem videla, da se ne bojijo kopirati produkcijo v staging — močno je odvisno od podjetja. Ampak videla sem tudi, da so zelo prestrašeni, in da pogosto primanjkuje časa in rok. Ampak preden se premaknemo na to temo, bi rada slišala o Kubernetesu. Pravilno razumem, da ga v produkciji še nihče nima?
DS: Imamo majhne baze v produkciji. Gre za obsege v desetih gigabajtih in nekritične storitve, za katere se ni dalo truditi, da bi naredili replikate (pravzaprav ni bilo potrebe). In pod pogojem, da je pod Kubernetesom normalno shranjevanje. Ta baza je delovala v virtualni napravi — pogojno v VMware, nad SAN. Premestili smo jo v in zdaj jo lahko prenašamo iz naprave v napravo.
NS: Baze takšne velikosti, do 100 GB, na dobrih diskih in ob dobrem omrežju, lahko razporedimo v nekaj minutah, prav? Hitrost 1 GB na sekundo ni več eksotika.
DS: Ja, za linearno operacijo to ni težava.
NS: Okej, o produkciji moramo samo razmišljati. Kaj pa, če razmišljamo o Kubernetesu za ne-prod okolja — kako nastaviti? Vidim, da v Zalando , v Crunchy , obstajajo še druge možnosti. In tu je — to je naš dober prijatelj Alvaro iz Španije: oni ne delajo le , temveč celoten distribucijski paket (), v katerega poleg samega Postgres-a želijo vključiti tudi varnostno kopijo, proxy Envoy…
DS: Zakaj Envoy? Za uravnoteženje prometa Postgres-a?
NS: Da. Torej to vidijo tako: če vzamemo Linux distribucijo in jedro, potem je običajni PostgreSQL jedro, oni pa želijo ustvariti distribucijo, ki bo prijazna oblaku in se bo vrtela v Kubernetesu. Povezujejo komponente (varnostne kopije itd.) in jih optimizirajo, da dobro delujejo.
DS: Zelo kul! V bistvu je to programska oprema za ustvarjanje svojega upravljanega Postgres-a.
NS: Pri Linux distribucijah so vedno težave: kako izdelati gonilnike, da bo podprta vsa strojna oprema. Njihova ideja je, da bodo delovali v Kubernetesu. Vem, da smo pri operaterju Zalando nedavno opazili vezavo na AWS in to že ni dobro. Ne bi smelo biti vezano na določeno infrastrukturo — kakšen je potem smisel?
DS: Ne vem, v kateri situaciji se je Zalando vezal, ampak trenutno je shranjevanje v Kubernetesu urejeno tako, da ni mogoče splošno narediti diskovne varnostne kopije. Nedavno je v standardu — v zadnji različici — omogočeno snemanje posnetkov, a kje je to implementirano? Iskreno, še vedno je tako nepredelano… Poskušamo CSI nad AWS, GCE, Azure, vSphere, ampak takoj ko začneš uporabljati, je jasno, da še ni pripravljeno.
NS: Zato včasih moramo biti vezani na infrastrukturo. Mislim, da je to še vedno zgodnja faza — težave pri rasti. Vprašanje: kaj bi priporočil novincem, ki želijo preizkusiti PgSQL v K8s? Kakšen operater, morda?
DS: Težava je v tem, da je Postgres za nas le 3%. Imamo še zelo dolg seznam razne programske opreme v Kubernetesu, ne bom jih vse našteval. Na primer, Elasticsearch. Operaterjev je mnogo: nekateri se aktivno razvijajo, drugi ne. Mi smo si postavili zahteve, kaj mora imeti operater, da ga jemljemo resno. Operater mora biti posebej za Kubernetes — ne 'operater, da izvajamo karkoli v Amazonu'… V praksi uporabljamo precej množično (= skoraj pri vseh strankah) edini operater — (kmalu bomo objavili članek tudi o njem).
NS: A za MySQL tudi ni? Vem, da se Percona… ker sedaj obravnavajo tako MySQL, MongoDB, kot tudi Postgres, morajo razviti nek univerzalni sistem: za vse baze, za vse oblačne ponudnike.
DS: Nismo uspeli pogledati operatore za MySQL. To trenutno nije naš glavni fokus. MySQL dobro radi u standalone režimu. Zašto nam treba operator ako jednostavno možemo pokrenuti bazu podataka… Može se pokrenuti Docker kontejner s Postrgesom, ili se to može učiniti jednostavnije.
NS: O tome je također bilo pitanje. Uopće bez operatora?
DS: Da, 100% naš PostgreSQL se pokreće bez operatora. Za sada je to tako. Aktivno koristimo operator za Prometheus, za Redis. Planiramo pronaći operator za Elasticsearch — to je najhitnije, jer ga želimo postaviti u Kubernetes u 100% slučajeva. Također želimo da MongoDB uvijek bude u Kubernetesu. Ovde se pojavljuju određene želje — imamo osećaj da se u ovim slučajevima može nešto uraditi. A za Postgres čak nismo ni gledali. Naravno, znamo za postojanje različitih opcija, ali u praksi imamo standalone.
Baza podataka za testiranje u Kubernetesu
NS: Pređimo na temu testiranja. Kako implementirati promene u bazi — iz perspektive DevOps-a. Postoje mikroservisi, mnogo baza, stalno se nešto menja. Kako osigurati normalan CI/CD, tako da je sa stanovišta DB sve u redu. Koji je tvoj pristup?
DS: Ne može biti jednog odgovora. Postoji nekoliko parametara. Prvi — to je veličina baze koju želimo implementirati. Sam si spomenuo da se u kompanijama različito odnose prema tome da kopija production baze bude na dev i stage.
NS: A u uslovima GDPR-a, mislim da se sve više i više paze... Mogu reći da su u Evropi već počeli da kazne.
DS: Ali često se može napisati softver koji pravi dump s produkcije i obfuscira ga. Dobijamo prod podatke (snapshot, dump, binarnu kopiju…), ali su anonimni. Umesto toga mogu postojati i skripte za generisanje: to mogu biti fixture ili jednostavno skripta koja generiše veliku bazu. Problem je: koliko vremena treba da se kreira osnovna slika? I koliko vremena treba da se ona postavi u odgovarajuće okruženje?
Došli smo do sheme: ako klijent ima set podataka za fixture (minimalna verzija baze), po defaultu ih koristimo. Ako se radi o review okruženjima, kada smo kreirali branch, imamo instance aplikacije — tamo implementiramo malu bazu. Ali dobro je ispalo i , ko s produkcijskega okolja vsak dan (ponoči) vzamemo varnostno kopijo in na podlagi tega ustvarimo Docker vsebnik s PostgreSQL in MySQL s temi naloženimi podatki. Če je treba iz te slike 50-krat razporediti bazo, to naredimo dovolj enostavno in hitro.
NS: Preprosto kopiranje?
DS: Podatki so shranjeni neposredno v Docker sliki. Imamo torej pripravljeno sliko, recimo, da je velika 100 GB. Zaradi plasti v Dockerju lahko hitro razporedimo to sliko v potrebnem številu. Način je preprost, a deluje dobro.
NS: Nato, ko testirate, se to spremeni neposredno znotraj Dockerja, kajne? Copy-on-write znotraj Dockerja — zavržemo in spet začnemo, vse je dobro. Super! In to že uporabljate v polni meri?
DS: Že dolgo.
NS: Ukvarjamo se z zelo podobnimi stvarmi. Samo mi ne uporabljamo Dockerjevega copy-on-write, ampak kakšno drugo.
DS: Ni generičen. Ampak Dockerjev deluje povsod.
NS: V teoriji, ja. Ampak tudi mi imamo tam module, lahko naredimo različne module in delamo z različnimi datotečnimi sistemi. Tukaj je trenutek. Mi z vidika PostgreSQL na to gledamo drugače. Zdaj sem pogledal z vidika Dockerja in videl, da vse deluje pri vas. Ampak če je baza ogromna, na primer 1 TB, je to že počasno: tako operacije ponoči kot zakladanje vsega v Docker… Ali je to v redu, če damo 5 TB v Docker?
DS: Kakšna je razlika: to so le binarne datoteke, preprosto biti in bajti.
NS: Razlika je taka: to počnete preko dump in restore?
DS: Sploh ni nujno. Načini generiranja te slike so lahko različni.
NS: Za nekatere stranke smo naredili tako, da namesto rednega generiranja osnovne slike jo nenehno vzdržujemo v aktualnem stanju. V bistvu deluje kot replikat, ampak podatke pridobiva ne neposredno od glavne enote, temveč preko arhiva. Binarni arhiv, kamor se vsak dan nalagajo WAL-ji, tam se tudi varnostne kopije delajo… Ti WAL-ji nato pridejo — z majhnim zamikom (do 1-2 sekunde) — do osnovne slike. Od tam kloniramo na kakršenkoli način — trenutno po privzetku uporabljamo ZFS.
DS: Ampak z ZFS ste omejeni na eno vozlišče.
NS: Ja. Ampak ZFS ima še čarobno : z njim lahko pošljete posnetek in celo (to še nisem prav testiral, ampak…) lahko pošiljate razliko med dvema PGDATA. V resnici imamo še en instrument, ki ga nismo prav razmišljali za takšne naloge. V PostgreSQL obstaja , deluje kot „pameten“ rsync, ki preskoči veliko tistega, kar ni nujno gledati, ker se tam ni nič spremenilo. Med dvema strežnikoma lahko hitro sinhroniziramo in se natančno vrnemo nazaj.
Torej, trudimo se z bolj DBA perspektive narediti orodje, ki omogoča isto, o čemer si govoril: imamo eno bazo, ampak želimo 50-krat testirati nekaj, skoraj hkrati.
DS: 50-krat pomeni, da morate naročiti 50 Spot instanc.
NS: Ne, vse dela na eni napravi.
DS: Ampak kako boste razporedili 50-krat, če je ta ena baza, recimo, terabajtna. Najverjetneje potrebuje približno 256 GB RAM-a?
NS: Da, včasih potrebujemo veliko pomnilnika - to je normalno. Ampak to je primer iz prakse. Na produkcijski napravi imamo 96 jeder in 600 GB. Pri tem uporablja 32 jeder (tudi 16 jeder včasih) in 100-120 GB pomnilnika za BDP.
DS: In tam gre 50 kopij?
NS: Ampak kopija je ena, naprej deluje copy-on-write (ZFS)... Povedal bom več.
Naša baza ima na primer 10 TB. Disk zanj smo naredili, ZFS pa je še zmanjšal velikost za 30-40%. Ker ne izvajamo obremenitvenega testiranja, nam natančen odzivni čas ni pomemben: lahko je do 2-krat počasnejši - to je v redu.
Ponujamo možnost razvijalcem, QA, DBA itd. izvajati testiranje v 1-2 niti. Na primer, lahko izvedejo nekakšno migracijo. Ta ne zahteva takoj 10 jeder - potrebuje en backend Postgres, 1 jedro. Migracija se bo zagnala - morda, še ena se bo zagnala, takrat se vključi drugo jedro. Imamo dodeljenih 16-32 jeder, tako da lahko 10 oseb dela hkrati, brez težav.
Ker so fizično PGDATA enaki, izpade, da v resnici zavajamo Postgres. Finta je v tem: hkrati se zažene 10 Postgresov. Običajno je težava, katero nastavijo , recimo, na 25%. Tako je to 200 GB. Več kot tri take ne moreš zagnati, ker zmanjka pomnilnika.
Ampak v nekem trenutku smo ugotovili, da to ni potrebno: nastavljamo shared_buffers na 2 GB. PostgreSQL ima , in v resnici samo ta vpliva na . Ta je nastavljen na 0,5 TB. In ni pomembno, da dejansko ni: gradi načrte, kot da so.
Zato, kadar testiramo kakšno migracijo, lahko zberemo vse načrte — videli bomo, kako bo to potekalo v produkciji. Časovne sekunde bodo druge (manj hitre), vendar so podatki, ki jih dejansko preberemo, in sami načrti (kakšni so JOIN-i in podobno) povsem enaki tistim v produkciji. Hkrati pa lahko na enem strežniku zaženemo več takšnih preverjanj.
DS: Ne misliš, da tukaj obstaja več težav? Prva je rešitev, ki deluje samo na PostgreSQL. Tak pristop je zelo specifičen, ni generičen. Druga težava je, da Kubernetes (in vse, kamor zdaj gredo oblačne tehnologije) predpostavlja več vozlišč, ta vozlišča pa so efemerna. V tvojem primeru pa gre za stateful, persistentno vozlišče. Te stvari me motijo.
NS: Prvič, strinjam se, to je čisto PostgreSQL zgodba. Mislim, da če imamo kakšen direct IO in pomnilniški buffer skoraj vso pomnilnost, ta pristop ne bo ustrezal — načrti bodo drugačni. A zaenkrat delamo samo s PostgreSQL in o drugih ne razmišljamo.
Kar se tiče Kubernetesa. Saj sam povsod govoriš, da imamo trajno bazo. Če instanca propade, je ključno ohraniti disk. Naša celotna platforma deluje v Kubernetesu, komponenta s PostgreSQL pa je ločena (čeprav bo tudi ta enkrat tam). Zato je tako: instanca je propadla, a mi smo ohranili njen PV in preprosto priključili k drugi (novi) instanci, kot da se nič ni zgodilo.
DS: Z mojega stališča ustvarjamo pod v Kubernetesu. K8s je elastičen: vozlišča se sama naročajo po potrebi. Naloga je preprosto ustvariti pod in povedati, koliko virov potrebuje, K8s pa se bo sam poskrbel za ostalo. A podpora shrambe v Kubernetesu je še vedno nestabilna: v , v (ta izdaja je izšla pred tednom dni) te funkcije postajajo le beta.
Minilo bo pol leta do leta — postalo bo bolj ali manj stabilno, ali pa vsaj bo tako izjavljeno. Takrat možnost zajemanja in povečanja že popolnoma reši vašo nalogo. Ker imate bazo. Da, morda ni zelo hitra, a hitrost je odvisna od tega, kaj je 'pod pokrovom', ker nekatere izvedbe znajo izvajati kopiranje in copy-on-write na ravni disčnega podsistema.
NS: Tukaj pa je še potrebno, da vsi pogoni (Amazon, Google…) začnejo podpirati to različico — to tudi vzame nekaj časa.
DS: Zaenkrat je ne uporabljamo. Uporabljamo svoje.
Lokalni razvoj pod Kubernetes
NS: Si je n'ai pas rencontré ce souhait où il faut lancer tous les pod’ys sur une seule machine et faire un petit test. Pour obtenir rapidement une preuve de concept, voir si l'application fonctionne sous Kubernetes, sans nécessiter un tas de machines. Il y a Minikube, n'est-ce pas ?
DS: Je pense que ce cas - le déploiement sur un nœud - concerne exclusivement le développement local. Ou certains aspects d'un tel modèle. Il y a , il y a , . Nous allons utiliser Kubernetes IN Docker. Nous avons commencé à travailler avec pour les tests.
NS: Auparavant, je croyais que c'était une tentative d'enrouler tous les pod’ys dans une seule image Docker. Mais en réalité, c'est complètement différent. Il y a toujours des conteneurs séparés, des pod’ys séparés - juste dans Docker.
DS: Oui. Et ils ont réalisé une imitation assez amusante, mais le sens est le suivant… Nous avons un utilitaire pour le déploiement - . Nous voulons y ajouter un mode - disons werf up: «Lance moi un Kubernetes local». Et ensuite, lancer un certain werf follow. Ainsi, le développeur pourra modifier dans l'IDE, tandis qu'un processus est en cours dans le système, détectant les modifications et reconstruisant les images, les redéployant dans K8s local. C'est ainsi que nous voulons essayer de résoudre le problème du développement local.
Snapshots et clonage de DB dans les réalités de K8s
NS: Si nous revenons à copy-on-write. J'ai remarqué que les clouds ont aussi des snapshots. Ils fonctionnent différemment. Par exemple, dans GCP : vous avez une instance de plusieurs téraoctets sur la côte est des États-Unis. Vous faites des snapshots de temps en temps. Vous récupérez une copie du disque à partir d'un snapshot sur la côte ouest - en quelques minutes, tout est prêt, ça fonctionne très vite, il suffit juste de remplir le cache en mémoire. Mais ces clones (snapshots) sont là pour 'provision' un nouveau volume. C'est génial quand il faut créer beaucoup d'instances.
Mais pour les tests, je pense que les snapshots dont vous parlez dans Docker ou dont je parle dans ZFS, btrfs et même LVM… - ils permettent en fait de ne pas générer de nouvelles données sur une seule machine. Dans le cloud, vous devrez encore les payer chaque fois et attendre non pas des secondes, mais des minutes (et dans le cas de , peut-être même des heures).
Au lieu de cela, vous pouvez obtenir ces données en une ou deux secondes, exécuter le test et les jeter. Ces snapshots résolvent des tâches différentes. Dans le premier cas - pour évoluer et obtenir de nouvelles répliques, et dans le second - pour des tests.
DS: Ne strinjam se. Uroumeniti normalno kloniranje volumnov — to je naloga oblaka. Nisem gledal njihove implementacije, a vem, kako to delamo na strojni opremi. Imamo Ceph, v njem lahko kateremu koli fizičnemu volumnu () rečemo clone in za nekaj deset milisekund dobimo drugi volumen z enakimi specifikacijami, itd. Treba je razumeti, da tam noter stoji zapleten copy-on-write. Zakaj oblaku tega ne bi uspelo? Prepričan sem, da se trudijo to narediti na tak ali drugačen način.
NS: A vendar jim kljub vsemu minejo sekunde, desetine sekund, da dvignejo instanco, prinesejo tja Docker itd.
DS: Zakaj bi morali dvigovati celo instanco? Imamo instanco z 32 jedri, z 16 ... in vanjo se lahko spravi določeno število — na primer štiri. Ko naročimo peto, se že dvigne instanca, nato pa se izbriše.
NS: Da, zanimivo, v Kubernetesu je zgodba drugačna. Naša baza podatkov ni v K8s, in imamo samo eno instanco. Vendar pa za kloniranje večterabajtne baze ne porabimo več kot dve sekundi.
DS: To je super. Ampak moja prvotna misel je bila, da to ni generična rešitev. Da, je odlična, vendar deluje samo za Postgres in le na enem vozlišču.
NS: Ni primerno samo za Postgres: ti plani, kot sem opisoval, bodo tako delovali samo v njem. Ampak če se ne obremenjujemo s plani, ampak potrebujemo vse podatke za funkcionalno testiranje, potem je to primerno za katerikoli DBMS.
DS: Pred mnogimi leti smo delali podobno na LVM-snapshotih. To je klasika. Tak pristop je bil zelo aktivno uporabljen. Preprosto stateful vozlišča — to je težava. Ker jih ne smemo spraviti dol, vedno jih moramo imeti v mislih ...
NS: Ali ne vidiš tukaj kakšne možnosti hibrida? Recimo, stateful — to je nek pod, deluje na več ljudeh (mnogi testerji). Imamo en volumen, ampak zahvaljujoč datotečnemu sistemu so kloni — lokalni. Če pod pade, disk ostane — pod se ponovno dvigne, informacije o vseh klonih se preberejo, vse se vrne nazaj in reče: 'Tukaj so vaši kloni na teh vratih, delajte z njimi naprej.'
DS: Tehnično to pomeni, da je v okviru Kubernetes to en pod, znotraj katerega upravljamo več Postgresov.
NS: Da. Ima omejitev: recimo, hkrati ne delajo več kot 10 ljudi. Če je potrebno 20 — bomo zagnali drugi taki pod. Popolnoma se da klonirati, pridobiti drugi poln volumen, na njem bo 10 'tankih' klonov. Ne vidiš te možnosti?
DS: Treba dodati ovdje sigurnosna pitanja. Ova organizacija podrazumijeva da ovaj pod ima visoke privilegije (capabilities), jer može izvoditi nestandardne operacije na datotečnom sustavu... Ali ponavljam: smatram da će u srednjoročnom razdoblju Kubernetes ispraviti pohranu, u oblacima će popraviti cijelu priču s volumenima — sve će 'samo raditi'. Bit će resize, kloniranje... Imamo volume — kažemo: 'Kreiraj novi na temelju onoga', — i za pola sekunde dobijamo ono što trebamo.
NS: Ne vjerujem u pola sekunde za mnoge terabajte. Na Ceph-u to radiš sam, a govoriš o oblacima. Idi u oblak, na EC2 napravi klon volumen EBS s mnogo terabajta i vidi kakva će performansa biti. To neće trajati nekoliko sekundi. Jako me zanima kada će doći do takvog pokazatelja. Razumijem o čemu govoriš, ali ću se usuditi ne složiti.
DS: 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 tvrtke Zalando, koji je ispričao povijest operatora PostgreSQL:
Super je što se uopće dotakla ova tema: i Postgres i Kubernetes. Kada smo počeli raditi na tome u Zalandu 2017. godine, to je bila tema kojom su svi htjeli baviti, ali nitko nije radio. Svi su već imali Kubernetes, ali kada su pitali kako s bazama podataka, čak su i takvi ljudi kao , koji su propovijedali K8s, govorili otprilike sljedeće:
‘Idite u upravljane usluge i koristite ih, nemojte pokretati BDP u Kubernetesu. Inače će vaš K8s odlučiti, na primjer, napraviti nadogradnju, ugasiti sve čvorove, a vaši podaci otići daleko, daleko’.
Odlučili smo stvoriti operatora koji će, unatoč tom savjetu, pokretati BDP Postgres u Kubernetesu. I imali smo dobru osnovu — . Ovo je automatski failover za PostgreSQL, napravljen na pravilan način, tj. koristeći etcd, consul ili ZooKeeper kao skladište informacija o klasteru. Takvo skladište koje će svima koji pitaju, na primjer, tko je sada vođa, dati istu informaciju — bez obzira na to što je sve distribuirano — kako ne bi došlo do split brain-a. Plus, imali smo zanj.
Potreba za automatskim prebacivanjem došao je nakon migracije iz unutrašnjeg datacentra u oblak. Oblak je bio zasnovan na vlastitom PaaS (Platforma kao usluga) rješenju. To je Open Source, ali je bilo potrebno puno truda da se to podigne. Zvao se .
Isprva nije bilo nikakvog Kubernetes-a. Tačnije, kada se razvijalo vlastito rješenje, K8s je već bio prisutan, ali toliko nezreo da nije bio pogodan za produkciju. To je, čini mi se, 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 vlastiti operator? Murat Kabilov, koji nam je došao iz Avita, započeo je to kao projekat po vlastitoj inicijativi — "za zabavu" — i projekat je "procvao".
Ali zapravo sam hteo govoriti o AWS-u. Zašto je tamo istorijski bio kod vezan za AWS...
Kada pokrećete nešto u Kubernetesu, treba razumeti da je K8s u stalnom razvoju. Kontinuirano se unapređuje i povremeno se čak i kvari. Potrebno je pažljivo pratiti sve promene u Kubernetesu, biti spreman u slučaju potrebe da se dublje upoznate sa njim i naučite kako sve to funkcioniše u detalje — možda čak više nego što biste želeli. To važi za svaku platformu na kojoj pokrećete svoje baze podataka...
Dakle, kada smo radili operator, imali smo Postgres koji je radio s eksternim volumenom (u ovom slučaju — EBS, pošto smo radili na AWS-u). Baza podataka je rasla, u jednom trenutku je bilo potrebno uraditi resize: na primer, inicijalna veličina EBS-a je bila 100 TB, baza je dostigla tu veličinu, a sada želimo povećati EBS na 200 TB. Kako? Pretpostavimo, možemo uraditi dump/restore na novi instancu, ali to je dug proces i uzrokuje zastoje.
Zato smo želeli takav resize koji će povećati EBS particiju i 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 za druge platforme. U operatoru nema zavisnosti da se može pokrenuti samo na AWS-u, nego može raditi i na svim ostalim platformama. U suštini, to je Open Source projekat: ako neko želi da ubrza korišćenje novog API-ja — dobrodošli. , pull-requests – ekipa Zalando se trudi da na njih reaguje prilično brzo i unapređuje operatera. koliko znam, projekat u Google Summer of Code i nekim sličnim inicijativama. Zalando aktivno radi na tome.
P.S. Bonus!
Ako vas zanima tema PostgreSQL i Kubernetes, takođe skrećemo pažnju da je prošle nedelje održan sledeći Postgres-torak, gde se Nikolaj razgovarao sa Aleksandrom Kukuškinom iz Zalando. Video je dostupan .
P.P.S.
Preberite tudi na našem blogu:
- «»;
- «»;
- «»;
- «».
Izvor: habr.com
