Postgres Martes Num. 5: “PostgreSQL ug Kubernetes. CI/CD. Pagsulay sa automation"

Postgres Martes Num. 5: “PostgreSQL ug Kubernetes. CI/CD. Pagsulay sa automation"

Sa katapusan sa miaging tuig, laing live broadcast sa Russian nga PostgreSQL nga komunidad ang nahitabo #RuPostgres, diin ang co-founder niini nga si Nikolai Samokhvalov nakigsulti sa Flant technical director nga si Dmitry Stolyarov mahitungod niini nga DBMS sa konteksto sa Kubernetes.

Kami nagmantala sa usa ka transcript sa nag-unang bahin niini nga diskusyon, ug sa Komunidad nga channel sa YouTube Gi-post ang tibuuk nga video:

Mga database ug Kubernetes

NS: Dili ta maghisgot bahin sa VACUUM ug CHECKPOINT karon. Gusto namon maghisgot bahin sa Kubernetes. Nahibal-an ko nga ikaw adunay daghang mga tuig nga kasinatian. Gitan-aw nako ang imong mga video ug bisan sa pagtan-aw pag-usab sa pipila niini... Diretso ta sa punto: nganong Postgres o MySQL sa K8s man?

DS: Wala ug dili mahimong tino nga tubag niini nga pangutana. Apan sa kinatibuk-an, kini mao ang kayano ug kasayon ​​... potensyal. Ang tanan gusto sa pagdumala sa mga serbisyo.

NS: Sa unsa nga paagi RDS, sa balay ra?

DS: Oo: sama sa RDS, bisan asa.

NS: “Bisan asa” maoy maayong punto. Sa dagkong mga kompanya, ang tanan nahimutang sa lainlaing mga lugar. Ngano man, kung kini usa ka dako nga kompanya, dili magkuha usa ka andam nga solusyon? Pananglitan, ang Nutanix adunay kaugalingon nga mga kalamboan, ang ubang mga kompanya (VMware...) adunay parehas nga "RDS, sa balay ra."

DS: Apan naghisgot kami bahin sa usa ka bulag nga pagpatuman nga molihok lamang sa ilawom sa pipila nga mga kondisyon. Ug kung naghisgot kami bahin sa Kubernetes, nan adunay daghang lainlain nga imprastraktura (nga mahimo sa K8s). Sa tinuud kini usa ka sumbanan alang sa mga API sa panganod ...

NS: Libre sab!

DS: Dili kaayo importante. Ang kagawasan hinungdanon alang sa dili usa ka dako nga bahin sa merkado. Naa pay laing importante... Basin mahinumduman nimo ang report “Mga database ug Kubernetes?

NS: Oo.

DS: Nakaamgo ko nga kini nadawat nga dili klaro. Ang pipila ka mga tawo naghunahuna nga ako nag-ingon: "Mga higala, atong ibutang ang tanan nga mga database sa Kubernetes!", samtang ang uban nakahukom nga kining tanan makalilisang nga mga bisikleta. Apan gusto nakong isulti ang usa ka butang nga lahi kaayo: "Tan-awa kung unsa ang nahitabo, kung unsa ang mga problema ug kung giunsa kini masulbad. Kinahanglan ba natong gamiton ang mga database sa Kubernetes karon? Produksyon? Buweno, kung gusto nimo ... pagbuhat sa pipila ka mga butang. Apan alang sa usa ka dev, makaingon ako nga girekomenda ko kini. Alang sa usa ka dev, ang kadasig sa paghimo/pagtangtang sa mga palibot hinungdanon kaayo.

NS: Pinaagi sa dev, ang imong gipasabut sa tanan nga mga palibot nga dili prod? Pagpahigayon, QA…

DS: Kung naghisgot kami bahin sa perf stand, tingali dili, tungod kay ang mga kinahanglanon didto espesipiko. Kung naghisgot kita bahin sa mga espesyal nga kaso diin ang usa ka dako kaayo nga database gikinahanglan alang sa pagpahigayon, nan tingali dili ... Kung kini usa ka static, taas nga kinabuhi nga palibot, nan unsa ang kaayohan sa pagbaton sa database nga nahimutang sa K8s?

NS: Wala. Apan asa nato makita ang mga static nga palibot? Ang usa ka static nga palibot mahimong obsolete ugma.

DS: Ang dula mahimong static. Naa mi mga kliyente...

NS: Oo, ako adunay usa usab. Dakong problema kung naa kay 10 TB database ug 200 GB nga staging...

DS: Naa koy cool nga case! Sa dula adunay usa ka database sa produkto diin gihimo ang mga pagbag-o. Ug adunay usa ka buton: "pag-roll out sa produksiyon". Kini nga mga pagbag-o - delta - gidugang (daw gi-synchronize lang kini pinaagi sa API) sa produksiyon. Kini usa ka eksotikong kapilian.

NS: Nakita nako ang mga startup sa Walog nga naglingkod sa RDS o bisan sa Heroku - kini mga istorya gikan sa 2-3 ka tuig ang milabay - ug ilang gi-download ang dump sa ilang laptop. Kay 80 GB lang gihapon ang database, ug naay space sa laptop. Unya sila mopalit ug dugang nga mga disk para sa tanan aron sila adunay 3 ka mga database aron sa paghimo sa lain-laing mga kalamboan. Ingon usab niini ang nahitabo. Nakita pud nako nga wa sila mahadlok mukopya sa prod sa staging - depende ra kaayo sa kompanya. Apan nakita usab nako nga sila nahadlok kaayo, ug nga sila sa kasagaran walay igong panahon ug mga kamot. Apan sa dili pa kita mopadayon niini nga hilisgutan, gusto kong makadungog mahitungod sa Kubernetes. Sakto ba ko nga nakasabot nga wala pay naa sa prod?

DS: Kami adunay gagmay nga mga database sa prod. Naghisgot kami bahin sa mga volume nga napulo ka gigabytes ug dili kritikal nga mga serbisyo diin tapolan kaayo kami sa paghimo og mga replika (ug wala’y kinahanglan). Ug basta adunay normal nga pagtipig ubos sa Kubernetes. Kini nga database nagtrabaho sa usa ka virtual nga makina - kondisyon sa VMware, sa ibabaw sa sistema sa pagtipig. Gibutang namo kini PV ug karon mabalhin na nato kini gikan sa makina ngadto sa makina.

NS: Ang mga database niini nga gidak-on, hangtod sa 100 GB, mahimong ma-roll out sa pipila ka minuto sa maayong mga disk ug maayong network, di ba? Ang katulin nga 1 GB matag segundo dili na exotic.

DS: Oo, alang sa linear nga operasyon dili kini problema.

NS: Sige, huna-hunaon lang nato ang prod. Ug kung atong gikonsiderar ang mga Kubernetes alang sa mga dili-prod nga palibot, unsa ang atong buhaton? Nakita nako kana sa Zalando mag operator, sa Crunchy paggabas, adunay ubang mga kapilian. Ug adunay OnGres - kini ang among suod nga higala nga si Alvaro gikan sa Spain: kung unsa ang ilang gibuhat dili ra operator, ug ang tibuok distribusyon (StackGres), diin, dugang sa mga Postgres mismo, nakahukom usab sila nga magbutang usa ka backup, ang Envoy proxy ...

DS: Sugo para sa unsa? Pagbalanse sa trapiko sa Postgres ilabi na?

NS: Oo. Sa ato pa, nakita nila kini nga: kung magkuha ka usa ka pag-apod-apod sa Linux ug kernel, nan ang regular nga PostgreSQL mao ang kernel, ug gusto nila nga maghimo usa ka pag-apod-apod nga mahimong cloud-friendly ug modagan sa Kubernetes. Gihiusa nila ang mga sangkap (mga backup, ug uban pa) ug gi-debug kini aron kini molihok nga maayo.

DS: Nindot kaayo! Sa tinuud kini usa ka software aron mahimo ang imong kaugalingon nga gidumala nga mga Postgres.

NS: Ang mga distribusyon sa Linux adunay walay katapusan nga mga problema: unsaon paghimo sa mga drayber aron ang tanang hardware masuportahan. Ug sila adunay ideya nga sila magtrabaho sa Kubernetes. Nahibal-an ko nga sa operator sa Zalando bag-ohay lang nakakita kami usa ka koneksyon sa AWS ug kini dili na kaayo maayo. Dili kinahanglan nga adunay usa ka bugkos sa usa ka piho nga imprastraktura - unsa man ang punto?

DS: Wala ko mahibal-an kung unsa nga sitwasyon ang gisulod ni Zalando, apan sa Kubernetes storage gihimo na karon sa paagi nga imposible ang pagkuha sa disk backup gamit ang generic nga pamaagi. Bag-o lang sa standard - sa pinakabag-o nga bersyon Mga detalye sa CSI — gihimo namon nga posible ang mga snapshot, apan diin kini gipatuman? Sa tinuod lang, hilaw pa kaayo ang tanan... Gisulayan namo ang CSI sa ibabaw sa AWS, GCE, Azure, vSphere, apan sa diha nga nagsugod ka sa paggamit niini, imong makita nga dili pa kini andam.

NS: Mao nga usahay kinahanglan kitang magsalig sa imprastraktura. Sa akong hunahuna kini usa pa ka sayo nga yugto - nagtubo nga mga kasakit. Pangutana: Unsang tambag ang imong ihatag sa mga bag-ong gustong mosulay sa PgSQL sa K8s? Unsa kaha operator?

DS: Ang problema kay ang Postgres 3% para namo. Adunay usab kami usa ka dako kaayo nga lista sa lainlaing software sa Kubernetes, dili nako ilista ang tanan. Pananglitan, Elasticsearch. Adunay daghang mga operator: ang uban aktibo nga nag-uswag, ang uban dili. Naghimo kami og mga kinahanglanon alang sa among kaugalingon, kung unsa ang kinahanglan nga naa sa operator aron kini seryosohon. Sa usa ka operator nga espesipiko alang sa Kubernetes - dili sa usa ka "operator sa pagbuhat sa usa ka butang sa Amazon's kondisyon"... Sa pagkatinuod, kami kaylap (= halos tanan nga mga kliyente) naggamit sa usa ka operator - alang kang Redis (magpatik mi ug artikulo bahin niya sa dili madugay).

NS: Ug dili alang sa MySQL usab? Nahibal-an ko nga ang Percona ... tungod kay nagtrabaho na sila karon sa MySQL, MongoDB, ug Postgres, kinahanglan silang maghimo usa ka matang sa unibersal nga solusyon: alang sa tanan nga mga database, alang sa tanan nga mga taghatag sa panganod.

DS: Wala kami panahon sa pagtan-aw sa mga operator alang sa MySQL. Dili kini ang among panguna nga gipunting karon. Maayo nga nagtrabaho ang MySQL sa standalone. Ngano nga mogamit usa ka operator kung mahimo ka lang maglansad sa usa ka database ... Mahimo nimong ilunsad ang usa ka sudlanan sa Docker nga adunay Postrges, o mahimo nimo kini ilansad sa yano nga paagi.

NS: Adunay pangutana bahin niini usab. Walay operator?

DS: Oo, 100% kanato adunay PostgreSQL nga nagdagan nga walay operator. Hangtod karon. Aktibo namong gigamit ang operator para sa Prometheus ug Redis. Kami adunay mga plano nga mangita usa ka operator alang sa Elasticsearch - kini ang labing "nasunog", tungod kay gusto namon i-install kini sa Kubernetes sa 100% sa mga kaso. Sama sa gusto namon nga masiguro nga ang MongoDB kanunay usab nga na-install sa Kubernetes. Dinhi makita ang pipila ka mga pangandoy - adunay usa ka pagbati nga sa kini nga mga kaso adunay mahimo. Ug wala namo tan-awa ang Postgres. Siyempre, nahibal-an namon nga adunay lainlaing mga kapilian, apan sa tinuud kami adunay usa ka standalone.

DB para sa pagsulay sa Kubernetes

NS: Mopadayon ta sa hilisgutan sa pagsulay. Giunsa ang paglansad sa mga pagbag-o sa database - gikan sa panan-aw sa DevOps. Adunay mga microservice, daghang mga database, adunay nagbag-o bisan diin sa tanan nga oras. Giunsa pagsiguro ang normal nga CI / CD aron ang tanan naa sa kahusay gikan sa panan-aw sa DBMS. Unsa imong approach?

DS: Walay usa ka tubag. Adunay daghang mga kapilian. Ang una mao ang gidak-on sa base nga gusto namong i-roll out. Ikaw mismo ang naghisgot nga ang mga kompaniya adunay lain-laing mga kinaiya sa pagbaton ug kopya sa prod database sa dev ug stage.

NS: Ug ubos sa mga kondisyon sa GDPR, sa akong hunahuna sila nag-amping ... makaingon ko nga sa Europe nagsugod na sila sa pagpahamtang og mga multa.

DS: Apan sa kasagaran makasulat ka og software nga mokuha og dump gikan sa produksiyon ug mo-obfuscate niini. Nakuha ang datos sa prod (snapshot, dump, binary copy...), apan wala kini mailhi. Hinunoa, mahimong adunay mga generation script: kini mahimong fixtures o usa lang ka script nga makamugna og dako nga database. Ang problema mao: unsa ka dugay ang paghimo sa usa ka base nga imahe? Ug unsa ka dugay ang pag-deploy niini sa gusto nga palibot?

Miabut kami sa usa ka laraw: kung ang kliyente adunay usa ka pirmi nga set sa datos (minimal nga bersyon sa database), nan gamiton namon kini nga default. Kung naghisgot kami bahin sa pagrepaso sa mga palibot, sa dihang naghimo kami usa ka sanga, nag-deploy kami usa ka pananglitan sa aplikasyon - nagpagawas kami usa ka gamay nga database didto. Apan maayo ang resulta kapilian, kung magkuha kami usa ka dump gikan sa produksiyon kausa sa usa ka adlaw (sa gabii) ug magtukod usa ka sudlanan sa Docker nga adunay PostgreSQL ug MySQL nga adunay kini nga gikarga nga datos base niini. Kung kinahanglan nimo nga palapdan ang database 50 ka beses gikan sa kini nga imahe, kini gihimo nga yano ug dali.

NS: Sa yanong pagkopya?

DS: Direkta nga gitipigan ang datos sa imahe sa Docker. Mga. Kami adunay usa ka andam nga gihimo nga imahe, bisan kung 100 GB. Salamat sa mga layer sa Docker, mahimo namon nga dali nga ma-deploy kini nga imahe sa daghang mga higayon nga kinahanglan namon. Ang pamaagi hungog, apan kini molihok nga maayo.

NS: Unya, kung imong gisulayan, kini nausab sa sulod mismo sa Docker, di ba? Copy-on-write sa sulod sa Docker - ilabay kini ug balik, maayo ang tanan. Klase! Ug gigamit na ba nimo kini sa hingpit?

DS: Sa dugay nga panahon.

NS: Nagbuhat kami parehas nga mga butang. Wala ra namo gigamit ang copy-on-write ni Docker, apan ang uban.

DS: Dili kini generic. Ug ang Docker nagtrabaho bisan asa.

NS: Sa teorya, oo. Apan aduna usab kami mga modulo didto, makahimo ka og lain-laing mga module ug magtrabaho uban sa lain-laing mga sistema sa file. Unsa ka gutlo dinhi. Gikan sa bahin sa Postgres, lahi ang among pagtan-aw niining tanan. Karon akong gitan-aw gikan sa Docker nga bahin ug nakita nga ang tanan nagtrabaho alang kanimo. Apan kung ang database dako, pananglitan, 1 TB, nan kining tanan nagkinahanglan og taas nga panahon: ang mga operasyon sa gabii, ug ang tanan nga butang sa Docker ... Ug kung ang 5 TB gisulod sa Docker ... O maayo ba ang tanan?

DS: Unsa ang kalainan: kini mga blobs, mga bits ug bytes lang.

NS: Ang kalainan mao kini: gibuhat ba nimo kini pinaagi sa dump and restore?

DS: Dili gyud kinahanglan. Ang mga paagi sa paghimo niini nga imahe mahimong lahi.

NS: Alang sa pipila ka mga kliyente, gihimo namo kini aron imbes nga regular nga maghimo og base nga imahe, kanunay namo kining gi-update. Kini usa ka replika, apan nakadawat kini nga datos dili gikan sa agalon direkta, apan pinaagi sa usa ka archive. Usa ka binary archive diin ang mga WAL gi-download kada adlaw, diin ang mga pag-backup gikuha ... Kini nga mga WAL dayon nakaabot sa base nga imahe nga adunay gamay nga paglangan (literal nga 1-2 segundos). Gi-clone namon kini sa bisan unsang paagi - karon naa na kami ZFS nga default.

DS: Apan sa ZFS ikaw limitado sa usa ka node.

NS: Oo. Apan ang ZFS usab adunay usa ka mahika ipadala: uban niini mahimo ka magpadala usa ka snapshot ug bisan pa (wala pa nako kini gisulayan, apan ...) mahimo ka magpadala usa ka delta taliwala sa duha PGDATA. Sa tinuud, kami adunay lain nga himan nga wala gyud namo mahunahuna alang sa ingon nga mga buluhaton. Ang PostgreSQL adunay pg_rewind, nga naglihok sama sa usa ka "smart" rsync, paglaktaw sa daghang mga butang nga dili nimo kinahanglan nga tan-awon, tungod kay walay nausab didto. Makahimo kami usa ka dali nga pag-synchronize tali sa duha nga mga server ug i-rewind sa parehas nga paagi.

Mao nga, gikan niini, dugang nga bahin sa DBA, naningkamot kami nga maghimo usa ka himan nga nagtugot kanamo sa pagbuhat sa parehas nga butang nga imong giingon: kami adunay usa ka database, apan gusto namon nga sulayan ang usa ka butang 50 ka beses, hapit dungan.

DS: Ang 50 ka beses nagpasabot nga kinahanglan ka mag-order og 50 ka mga higayon sa Spot.

NS: Dili, gibuhat namo ang tanan sa usa ka makina.

DS: Apan unsaon nimo pagpalapad ang 50 ka beses kung kining usa ka database, ingnon ta, terabyte. Lagmit nagkinahanglan siya og conditional 256 GB nga RAM?

NS: Oo, usahay kinahanglan nimo ang daghang memorya - normal kana. Apan kini usa ka ehemplo sa kinabuhi. Ang makina sa produksiyon adunay 96 ka mga core ug 600 GB. Sa samang higayon, 32 ka mga cores (bisan ang 16 ka mga cores karon usahay) ug 100-120 GB sa memorya ang gigamit alang sa database.

DS: Ug 50 ka kopya ang naa diha?

NS: Mao nga adunay usa ra ka kopya, unya ang copy-on-write (ZFS) molihok... Sultihan ko ikaw sa mas detalyado.

Pananglitan, kami adunay 10 TB database. Naghimo sila og disk alang niini, gi-compress usab sa ZFS ang gidak-on niini sa 30-40 porsyento. Tungod kay wala kami mag-load testing, ang eksaktong oras sa pagtubag dili importante kanamo: pasagdi kini nga 2 ka beses nga mas hinay - okay ra.

Gihatagan namon ang higayon sa mga programmer, QA, DBA, ug uban pa. paghimo sa pagsulay sa 1-2 nga mga hilo. Pananglitan, mahimo silang modagan sa usa ka matang sa paglalin. Wala kini magkinahanglan og 10 ka mga cores sa usa ka higayon - kini nagkinahanglan og 1 Postgres backend, 1 core. Ang paglalin magsugod - tingali autovacuum magsugod gihapon, unya ang ikaduhang core gamiton. Kami adunay 16-32 nga mga cores nga gigahin, mao nga 10 ka mga tawo ang makatrabaho sa samang higayon, walay problema.

Kay physically PGDATA mao gihapon, mogawas nga gilimbongan gyud nato ang mga Postgres. Ang lansis mao kini: pananglitan, 10 ka Postgres ang dungan nga gilusad. Unsa ang kasagaran nga problema? Ilang gibutang shared_buffers, ingnon ta nga 25%. Busa, kini mao ang 200 GB. Dili ka makalunsad og labaw sa tulo niini, tungod kay ang memorya mahurot.

Apan sa usa ka punto nahibal-an namon nga dili kini kinahanglan: gitakda namon ang shared_buffers sa 2 GB. Ang PostgreSQL adunay epektibo nga_cache_size, ug sa pagkatinuod kini lamang ang nag-impluwensya mga plano. Gibutang namon kini sa 0,5 TB. Ug dili igsapayan nga wala sila sa tinuud nga naglungtad: naghimo siya og mga plano ingon nga kini naglungtad.

Tungod niini, kung gisulayan namon ang usa ka matang sa paglalin, mahimo namon kolektahon ang tanan nga mga plano - among makita kung giunsa kini mahitabo sa produksiyon. Ang mga segundo didto magkalainlain (mas hinay), apan ang datos nga atong gibasa, ug ang mga plano mismo (unsa ang mga JOIN, ug uban pa) parehas ra sa produksiyon. Ug mahimo nimong ipadagan ang daghang ingon nga mga tseke nga managsama sa usa ka makina.

DS: Wala ka ba maghunahuna nga adunay pipila ka mga problema dinhi? Ang una usa ka solusyon nga magamit ra sa PostgreSQL. Kini nga pamaagi pribado kaayo, dili kini generic. Ang ikaduha mao nga ang Kubernetes (ug ang tanan nga ang mga teknolohiya sa panganod moadto karon) naglakip sa daghang mga node, ug kini nga mga node mga ephemeral. Ug sa imong kaso kini usa ka stateful, padayon nga node. Kini nga mga butang naghimo kanako nga magkasumpaki.

NS: Una, uyon ko, puros postgres story ni. Sa akong hunahuna kung kita adunay usa ka matang sa direkta nga IO ug usa ka buffer pool alang sa halos tanan nga panumduman, kini nga pamaagi dili molihok - ang mga plano magkalainlain. Apan sa pagkakaron nagtrabaho lang kami sa mga Postgres, wala kami maghunahuna sa uban.

Mahitungod sa Kubernetes. Ikaw mismo nagsulti kanamo bisan asa nga kami adunay usa ka padayon nga database. Kung mapakyas ang pananglitan, ang panguna nga butang mao ang pagluwas sa disk. Dinhi naa usab ang tibuuk nga plataporma sa Kubernetes, ug ang sangkap nga adunay Postgres bulag (bisan kung naa kini usa ka adlaw). Busa, ingon niini ang tanan: nahulog ang instance, apan gi-save namon ang PV niini ug gikonektar lang kini sa lain (bag-o) nga pananglitan, ingon nga wala’y nahitabo.

DS: Gikan sa akong panglantaw, naghimo kami og mga pod sa Kubernetes. K8s - pagkamaunat: ang mga knot gi-order kung gikinahanglan. Ang tahas mao ang paghimo lamang og usa ka pod ug pag-ingon nga kini nagkinahanglan sa X nga kantidad sa mga kahinguhaan, ug dayon ang K8s makahunahuna niini sa iyang kaugalingon. Apan ang suporta sa pagtipig sa Kubernetes dili gihapon lig-on: 1.16sa 1.17 (Kini nga pagpagawas gipagawas mga semana kaniadto) kini nga mga bahin nahimong beta lamang.

Unom ka bulan ngadto sa usa ka tuig ang molabay - kini mahimong mas o dili kaayo lig-on, o labing menos kini ideklarar nga ingon niini. Unya ang posibilidad sa mga snapshot ug pag-usab sa gidak-on makasulbad sa imong problema sa hingpit. Kay naa kay basehan. Oo, kini dili kaayo paspas, apan ang katulin nagdepende sa kung unsa ang "sa ilawom sa hood", tungod kay ang pipila nga mga pagpatuman mahimo’g kopyahon ug kopyahon-sa-pagsulat sa lebel sa subsystem sa disk.

NS: Kinahanglan usab nga ang tanan nga mga makina (Amazon, Google...) magsugod sa pagsuporta niini nga bersyon - nagkinahanglan usab kini og panahon.

DS: Wala pa namo kini gigamit. Gigamit namo ang among.

Lokal nga kalamboan para sa Kubernetes

NS: Nakakita ka ba sa ingon nga pangandoy kung kinahanglan nimo nga i-install ang tanan nga mga pod sa usa ka makina ug buhaton ang ingon ka gamay nga pagsulay. Aron dali nga makakuha og pruweba sa konsepto, tan-awa nga ang aplikasyon nagdagan sa Kubernetes, nga wala gipahinungod ang usa ka hugpong sa mga makina alang niini. Adunay Minikube, di ba?

DS: Para nako nga kini nga kaso - gipakatap sa usa ka node - eksklusibo bahin sa lokal nga kalamboan. O pipila ka mga pagpakita sa ingon nga sumbanan. Kaon Minikube, Adunay k3s, KIND. Nagpadayon kami sa paggamit sa Kubernetes SA Docker. Karon nagsugod kami sa pagtrabaho niini alang sa mga pagsulay.

NS: Naghunahuna ko kaniadto nga kini usa ka pagsulay sa pagputos sa tanan nga mga pod sa usa ka imahe sa Docker. Apan kini nahimo nga kini mahitungod sa usa ka butang nga hingpit nga lahi. Bisan pa, adunay lahi nga mga sudlanan, lahi nga mga pod - sa Docker ra.

DS: Oo. Ug adunay usa ka medyo kataw-anan nga imitasyon nga gihimo, apan ang kahulugan mao kini ... Kami adunay gamit alang sa pag-deploy - werf. Gusto namong himoon nga conditional mode werf up: “Kuhaa kog lokal nga mga Kubernete.” Ug dayon padagana ang conditional didto werf follow. Dayon ang developer makahimo sa pag-edit sa IDE, ug usa ka proseso ang ilunsad sa sistema nga makakita sa mga pagbag-o ug pagtukod pag-usab sa mga hulagway, pag-redeploy niini ngadto sa lokal nga K8s. Mao ni ang gusto natong paningkamutan nga masulbad ang problema sa lokal nga kalamboan.

Mga snapshot ug database cloning sa K8s reality

NS: Kung mobalik kita sa copy-on-write. Namatikdan nako nga ang mga panganod usab adunay mga snapshot. Lahi ang ilang trabaho. Pananglitan, sa GCP: aduna kay multi-terabyte nga instance sa silangang baybayon sa Estados Unidos. Magkuha ka mga snapshot matag karon ug unya. Gikuha nimo ang usa ka kopya sa disk sa kasadpang baybayon gikan sa usa ka snapshot - sa pipila ka mga minuto ang tanan andam na, kini dali nga molihok, ang cache lamang ang kinahanglan nga mapuno sa panumduman. Apan kini nga mga clone (mga snapshot) para sa 'paghatag' og bag-ong volume. Nindot kini kung kinahanglan nimo nga maghimo daghang mga higayon.

Apan alang sa mga pagsulay, ingon nako nga ang mga snapshot, nga imong gihisgutan sa Docker o akong gihisgutan sa ZFS, btrfs ug bisan sa LVM ... - gitugotan ka nila nga dili maghimo bag-ong datos sa usa ka makina. Sa panganod, magbayad ka gihapon alang kanila matag oras ug maghulat dili mga segundo, apan minuto (ug sa kaso tapolan nga load, lagmit usa ka relo).

Hinuon, mahimo nimong makuha kini nga datos sa usa o duha ka segundo, pagdagan ang pagsulay ug ilabay kini. Kini nga mga snapshot nagsulbad sa lainlaing mga problema. Sa una nga kaso - aron madugangan ug makakuha bag-ong mga replika, ug sa ikaduha - alang sa mga pagsulay.

DS: Dili ko musugot. Ang paghimo sa volume cloning nga molihok sa hustong paagi mao ang tahas sa panganod. Wala nako gitan-aw ang ilang pagpatuman, apan nahibal-an ko kung giunsa naton kini buhaton sa hardware. Kami adunay Ceph, gitugotan niini ang bisan unsang pisikal nga gidaghanon (RBD) ingon clone ug pagkuha usa ka ikaduha nga volume nga adunay parehas nga mga kinaiya sa napulo ka millisecond, IOPS'ami, etc. Kinahanglan nimong masabtan nga adunay usa ka malisud nga copy-on-write sa sulod. Ngano nga ang panganod dili mobuhat sa ingon? Sigurado ako nga sila naningkamot sa pagbuhat niini sa usa ka paagi o sa lain.

NS: Apan magkinahanglan gihapon sila og mga segundo, napulo ka mga segundo aron mapataas ang usa ka pananglitan, dad-on ang Docker didto, ug uban pa.

DS: Nganong gikinahanglan nga ipataas ang tibuok nga instance? Kami adunay usa ka pananglitan nga adunay 32 nga mga cores, 16 ... ug kini mahimong mohaum niini - pananglitan, upat. Kung nag-order kami sa ikalima, ang instance ipataas na, ug unya kini mapapas.

NS: Oo, makapaikag, ang Kubernetes nahimo nga lahi nga istorya. Ang among database wala sa K8s, ug kami adunay usa ka higayon. Apan ang pag-clone sa usa ka multi-terabyte database dili molapas sa duha ka segundo.

DS: Nindot ni. Apan ang akong inisyal nga punto mao nga kini dili usa ka generic nga solusyon. Oo, kini bugnaw, apan kini angay lamang alang sa mga Postgres ug sa usa lamang ka node.

NS: Kini angay dili lamang alang sa mga Postgres: kini nga mga plano, sama sa akong gihulagway, molihok lamang niini. Apan kung dili kami maghasol bahin sa mga plano, ug kinahanglan lang namon ang tanan nga datos alang sa pagsulay nga magamit, nan kini angay alang sa bisan unsang DBMS.

DS: Daghang tuig na ang milabay nagbuhat kami og susama sa LVM snapshots. Kini usa ka klasiko. Kini nga pamaagi aktibo kaayo nga gigamit. Ang mga stateful node usa lang ka kasakit. Tungod kay dili nimo sila ihulog, kinahanglan nimo nga hinumdoman kanunay ...

NS: Nakita ba nimo ang bisan unsang posibilidad nga usa ka hybrid dinhi? Let's say stateful is some kind of pod, it works for several people (daghang tester). Kami adunay usa ka volume, apan salamat sa file system, ang mga clone lokal. Kung mahulog ang pod, apan magpabilin ang disk, mobangon ang pod, mag-ihap sa kasayuran bahin sa tanan nga mga clone, kuhaa pag-usab ang tanan ug isulti: "Ania ang imong mga clone nga nagdagan sa kini nga mga pantalan, padayon sa pagtrabaho kauban nila."

DS: Sa teknikal nga paagi kini nagpasabot nga sulod sa Kubernetes kini usa ka pod sa sulod diin kami nagpadagan sa daghang mga Postgres.

NS: Oo. Siya adunay limitasyon: ingnon ta nga dili molapas sa 10 ka tawo ang nagtrabaho uban niya sa samang higayon. Kung kinahanglan nimo ang 20, maglansad kami usa ka ikaduha nga ingon pod. Hingpit namong i-clone kini, nga nakadawat sa ikaduha nga bug-os nga gidaghanon, kini adunay parehas nga 10 ka "manipis" nga mga clone. Wala ba nimo makita kini nga oportunidad?

DS: Kinahanglan namong idugang ang mga isyu sa seguridad dinhi. Kini nga matang sa organisasyon nagpasabot nga kini nga pod adunay taas nga mga pribilehiyo (kapabilidad), tungod kay kini makahimo sa non-standard nga mga operasyon sa file system... Apan sublion ko: Nagtuo ako nga sa medium nga termino sa Kubernetes sila mag-ayo sa storage, sa mga panganod ilang ayohon ang tibuuk nga istorya nga adunay mga volume - ang tanan "magtrabaho lang". Adunay pagbag-o, pag-clone ... Adunay usa ka volume - giingon namon: "Paghimo usa ka bag-o base niana," ug pagkahuman sa usa ka segundo ug tunga makuha namon ang among kinahanglan.

NS: Dili ko motuo sa usa ug tunga ka segundos sa daghang terabytes. Sa Ceph gibuhat nimo kini sa imong kaugalingon, apan naghisgot ka bahin sa mga panganod. Lakaw ngadto sa panganod, paghimo og clone sa usa ka multi-terabyte nga gidaghanon sa EBS sa EC2 ug tan-awa kung unsa ang pasundayag. Dili kini molungtad og pipila ka segundo. Interesado kaayo ko kung kanus-a sila makaabot niini nga lebel. Nakasabot ko sa imong gisulti, apan nagpakiluoy ako nga lahi.

DS: Ok, pero giingon nako sa medium term, dili short term. Sulod sa pipila ka tuig.

Mahitungod sa operator alang sa PostgreSQL gikan sa Zalando

Sa tunga-tunga niini nga miting, si Alexey Klyukin, usa ka kanhi developer gikan sa Zalando, miapil usab ug misulti mahitungod sa kasaysayan sa PostgreSQL operator:

Nindot nga kini nga hilisgutan natandog sa kinatibuk-an: parehong Postgres ug Kubernetes. Sa diha nga nagsugod kami sa pagbuhat niini sa Zalando sa 2017, kini usa ka hilisgutan nga gusto sa tanan nga buhaton, apan walay usa nga nagbuhat niini. Ang tanan adunay mga Kubernetes, apan sa dihang nangutana sila kung unsa ang buhaton sa mga database, bisan ang mga tawo ganahan Kelsey Hightower, kinsa nagsangyaw sa K8s, misulti og sama niini:

"Adto sa gidumala nga mga serbisyo ug gamita kini, ayaw pagdagan ang database sa Kubernetes. Kung dili, ang imong mga K8 ang magdesisyon, pananglitan, aron mag-upgrade, i-off ang tanan nga mga node, ug ang imong data molupad sa layo, sa layo.

Nakahukom kami nga maghimo usa ka operator nga, sukwahi sa kini nga tambag, maglunsad og database sa Postgres sa Kubernetes. Ug kami adunay maayong rason - Patroni. Kini usa ka awtomatikong failover alang sa PostgreSQL, gibuhat sa husto, i.e. gamit ang etcd, consul o ZooKeeper isip pagtipig sa impormasyon bahin sa cluster. Ang ingon nga usa ka tipiganan nga maghatag sa tanan nga mangutana, pananglitan, kung unsa ang karon nga lider, parehas nga kasayuran - bisan pa sa kamatuoran nga kita adunay tanan nga gipang-apod-apod - aron wala’y nabahin nga utok. Dugang pa nga kami adunay Imahe sa Docker para niya.

Sa kinatibuk-an, ang panginahanglan sa kompanya alang sa auto failover nagpakita human sa paglalin gikan sa usa ka internal nga hardware data center ngadto sa panganod. Ang panganod gibase sa usa ka proprietary PaaS (Platform-as-a-Service) nga solusyon. Kini mao ang Open Source, apan nagkinahanglan og daghang trabaho aron kini mabuhat ug makadagan. Gitawag kini MGA STUPS.

Sa sinugdan, walay Kubernetes. Sa mas tukma, sa diha nga ang atong kaugalingon nga solusyon gipakatap, K8s anaa na, apan kini hilabihan ka krudo nga kini dili angay alang sa produksyon. Kini, sa akong opinyon, 2015 o 2016. Pagka 2017, ang mga Kubernetes nahimong mas o dili kaayo hamtong—adunay panginahanglan nga molalin didto.

Ug naa na miy sudlanan sa Docker. Adunay usa ka PaaS nga gigamit ang Docker. Nganong dili sulayan ang K8s? Ngano nga dili isulat ang imong kaugalingon nga operator? Si Murat Kabilov, nga mianhi kanamo gikan sa Avito, nagsugod niini isip usa ka proyekto sa iyang kaugalingon nga inisyatiba - "sa pagdula" - ug ang proyekto "mikuha."

Apan sa kinatibuk-an, gusto kong maghisgot bahin sa AWS. Ngano nga adunay makasaysayan nga AWS nga may kalabutan nga code...

Kung nagpadagan ka sa usa ka butang sa Kubernetes, kinahanglan nimo nga masabtan nga ang K8s usa ka trabaho nga nagpadayon. Kanunay kini nga nag-uswag, nag-uswag ug bisan sa pagkaguba matag karon ug unya. Kinahanglan nimo nga bantayan pag-ayo ang tanan nga mga pagbag-o sa Kubernetes, kinahanglan nimo nga andam sa pag-dive niini kung adunay mahitabo ug mahibal-an kung giunsa kini molihok sa detalye - tingali labaw pa sa imong gusto. Kini, sa prinsipyo, magamit sa bisan unsang plataporma diin imong gipadagan ang imong mga database...

Busa, sa dihang gibuhat namo ang pahayag, kami adunay mga Postgres nga nagdagan sa usa ka eksternal nga gidaghanon (EBS niini nga kaso, tungod kay kami nagtrabaho sa AWS). Ang database mitubo, sa usa ka punto gikinahanglan nga usbon kini: pananglitan, ang inisyal nga gidak-on sa EBS mao ang 100 TB, ang database mitubo niini, karon gusto namong himoon ang EBS 200 TB. Giunsa? Ingnon ta nga makahimo ka og dump/restore sa usa ka bag-ong instance, apan kini magdugay ug mag-apil sa downtime.

Busa, gusto nako ang usa ka pagbag-o nga mopadako sa partisyon sa EBS ug dayon isulti sa file system nga gamiton ang bag-ong luna. Ug gibuhat namo kini, apan niadtong panahona walay API ang Kubernetes alang sa operasyon sa pag-resize. Tungod kay nagtrabaho kami sa AWS, nagsulat kami og code alang sa API niini.

Walay nagpugong kanimo sa pagbuhat sa sama alang sa ubang mga plataporma. Wala’y timailhan sa pahayag nga mahimo ra kini nga ipadagan sa AWS, ug dili kini molihok sa tanan. Sa kinatibuk-an, kini usa ka Open Source nga proyekto: kung adunay gusto nga mapadali ang pagtungha sa paggamit sa bag-ong API, welcome ka. Kaon GitHub, pagbitad sa mga hangyo - ang Zalando team naningkamot sa pagtubag kanila nga dali ug nagpasiugda sa operator. Sa akong nahibal-an, ang proyekto miapil sa Google Summer of Code ug uban pang susama nga mga inisyatibo. Si Zalando aktibo kaayo niini.

PS Bonus!

Kung interesado ka sa hilisgutan sa PostgreSQL ug Kubernetes, nan palihug timan-i usab nga ang sunod nga Postgres Martes nahitabo sa miaging semana, diin nakigsulti ako kang Nikolai Alexander Kukushkin gikan sa Zalando. Ang video gikan niini anaa dinhi.

PPS

Basaha usab sa among blog:

Source: www.habr.com

Idugang sa usa ka comment