Në fund të vitit të kaluar, u mbajt një transmetim tjetër të drejtpërdrejtë të komunitetit rus të PostgreSQL. , në kuadër të së cilës bashkëthemeluesi i tij, Nikolai Samokhvalov, bisedoi me drejtorin teknik të "Flantës" Dmitry Stolyarov mbi këtë DBMS në kontekstin e Kubernetes.
Ne publikojmë transkriptin e pjesës kryesore të kësaj diseksioni, dhe në është publikuar regjistrimi i plotë i videos:
Baza të dhënash dhe Kubernetes
NS: Ne nuk do të flasim sot për VACUUM dhe CHECKPOINT, dëshirojmë të flasim për Kubernetes. E di se ke shumë vite përvojë. Kam parë videot e tua dhe disa madje i kam parë përsëri... Le të kalojmë direkt te pyetja: përse Postgres ose MySQL në K8s?
DS: Nuk ka një përgjigje të qartë për këtë pyetje dhe nuk mund të ketë. Por në përgjithësi, është thjeshtësia dhe lehtësia... potenciale. Të gjithë duan shërbime të menaxhuara.
NS: Si , vetëm në serverin tuaj?
DS: Po: që si RDS, vetëm kudo.
NS: "Kudo" - kjo është një vërejtje e mirë. Në kompanitë e mëdha, gjithçka është e shpërndarë në vende të ndryshme. Pse atëherë, nëse kjo është një kompani e madhe, të mos marrim një zgjidhje të gatshme? Për shembull, Nutanix ka zhvillimet e veta, kompanitë e tjera (VMware...) kanë "RDS, vetëm në serverin tuaj".
DS: Por ne po flasim për një zbatim të veçantë, i cili do të funksionojë vetëm në kushte të caktuara. Nëse flasim për Kubernetes, këtu ka një shumëllojshmëri të madhe infrastrukturore (e cila mund të jetë në K8s). Në thelb, kjo është një standard për API në re...
NS: Dhe gjithashtu falas!
DS: Kjo nuk është aq e rëndësishme. Falas është e rëndësishme për një segment të vogël të tregut. E rëndësishmja është tjetër... Sigurisht, ti e kujton fjalimin "»?
NS: Po.
DS: Kuptova se ai u prit shumë në mënyra të ndryshme. Një pjesë e njerëzve menduan se unë po thosha: "Djem, le të kalojmë të gjitha DB në Kubernetes!", - ndërsa të tjerë vendosën se ishin të gjitha biçikleta të tmerrshme. Por unë doja të thoshja diçka krejt tjetër: "Shikoni, çfarë po ndodh, cilat janë problemet dhe si mund të zgjidhen ato. A duhet të kaloni me baza në Kubernetes? Në prodhim? Epo, vetëm nëse ju pëlqen... të bëni disa gjëra të caktuara. Por për dev, mund të them se e rekomandoj. Për dev është shumë e rëndësishme dinamizmi i krijimit / fshirjes së mjediseve".
NS: Me dev të kuptosh të gjitha mjediset që nuk janë prodhues? Staging, QA...
DS: Nëse flasim për perf-stenda, ndoshta jo, sepse kërkesat atje janë specifike. Nëse flasim për raste të veçanta, ku në staging nevojitet një DB shumë e madhe, gjithashtu ndoshta jo... Nëse kjo është një mjedis statik, që jeton për një kohë të gjatë, çfarë është dobi që baza është e vendosur në K8s?
NS: Asnjë. Por ku e shohim mjedisin statik? Mjedisi statik është i vjetruar që nesër.
DS: Staging mund të jetë statik. Ne kemi klientë...
NS: Po, edhe unĂ« kam. ĂshtĂ« njĂ« problem i madh nĂ«se ke njĂ« bazĂ« prej 10 TB, ndĂ«rsa staging Ă«shtĂ« 200 GB...
DS: Kam njĂ« rast shumĂ« tĂ« shkĂ«lqyer! NĂ« staging ndodhet baza prodhuese, nĂ« tĂ« cilĂ«n bĂ«hen ndryshime. Dhe Ă«shtĂ« paraparĂ« njĂ« buton: "nxir nĂ« production". KĂ«to ndryshime â dytĂ« â shtohen (mĂ« duket, thjesht sinkronizohen pĂ«rmes API-t) nĂ« production. ĂshtĂ« njĂ« variant shumĂ« ekzotik.
NS: Kam parĂ« startupe nĂ« Dalin, qĂ« qĂ«ndrojnĂ« nĂ« RDS-nĂ« ose madje edhe nĂ« Heroku ende â kĂ«to janĂ« histori tĂ« para 2-3 viteve, â dhe ata shkarkojnĂ« dump nĂ« laptopin e tyre. Sepse baza Ă«shtĂ« vetĂ«m 80 GB, dhe ka hapĂ«sirĂ« nĂ« laptop. Pastaj ata blejnĂ« disqe pĂ«r secilin, pĂ«r tĂ« pasur 3 baza, nĂ« mĂ«nyrĂ« qĂ« tĂ« zhvillojnĂ« projekte tĂ« ndryshme. KĂ«shtu ndodhin edhe kĂ«to. Kam parĂ« gjithashtu se nuk kanĂ« frikĂ« tĂ« kopjojnĂ« prodhimin nĂ« staging â shumĂ« varet nga kompania. Por kam parĂ« gjithashtu se ka qĂ« frikohen shumĂ«, dhe shpesh u mungon koha dhe duar. Por para se tĂ« kalojmĂ« nĂ« kĂ«tĂ« temĂ«, do tĂ« doja tĂ« dĂ«gjoja pĂ«r Kubernetes. E kuptoj saktĂ« se nĂ« prodhim tashmĂ« nuk ka askush?
DS: Ne kemi disa baza tĂ« vogla nĂ« prodhim. BĂ«het fjalĂ« pĂ«r vĂ«llime nĂ« dhjetĂ«ra gigabajt dhe shĂ«rbime jo kritike, pĂ«r tĂ« cilat ishte dembelizĂ«m tĂ« bĂ«hej kopje (dhe nuk kishte njĂ« kĂ«rkesĂ« tĂ« tillĂ«). Dhe me kusht qĂ« nĂ«n Kubernetes tĂ« ketĂ« njĂ« depo normale. Kjo bazĂ« punonte nĂ« njĂ« makinĂ« virtuale â nĂ« mĂ«nyrĂ« tĂ« kushtuar nĂ« VMware, mbi SHT. Ne e vendosĂ«m nĂ« dhe tani mund ta transferojmĂ« nga makina nĂ« machinĂ«.
NS: Baza tĂ« tilla, deri nĂ« 100 GB, nĂ« disqe tĂ« mira dhe me njĂ« rrjet tĂ« mirĂ« mund tĂ« operohen pĂ«r disa minuta, e drejtĂ«? ShpejtĂ«sia prej 1 GB nĂ« sekondĂ« â kjo nuk Ă«shtĂ« mĂ« ekzotike.
DS: Po, pĂ«r njĂ« operacion linear kjo sâĂ«shtĂ« problem.
NS: Okej, pĂ«r prodhimin duhet tĂ« mendojmĂ« vetĂ«m. Dhe nĂ«se e shqyrtojmĂ« Kubernetes pĂ«r mjediset jo-prodhuese â si tĂ« veprojmĂ«? Shoh qĂ« nĂ« Zalando , nĂ« Crunchy , ka disa mundĂ«si tĂ« tjera. Dhe ka â ky Ă«shtĂ« shoku ynĂ« i mirĂ« Alvaro nga Spanja: ata bĂ«jnĂ« nĂ« thelb jo vetĂ«m , por njĂ« distribucion tĂ« tĂ«rĂ« (), nĂ« tĂ« cilin pĂ«rveç PostgreSQL edhe backup-in e vendosĂ«n, proxy EnvoyâŠ
DS: Pse Envoy? Për balancimin e trafikut të Postgres-it në veçanti?
NS: Po. Pra ata e shohin kështu: nëse e marrim distribucionin e Linux-it dhe bërthamën, PostgreSQL-i i zakonshëm është bërthama, dhe ata duan të krijojnë një distribucion që do të jetë miqësor me re dhe do të funksionojë në Kubernetes. Ata po bashkojnë komponentët (backup-et etj.) dhe po e rregullojnë që të funksionojnë mirë.
DS: Shumë e bukur! Në thelb ky është një soft që bën që PostgreSQL-i të menaxhohet.
NS: Distribucionet e Linux-it kanë probleme të përhershme: si të krijojnë shoferë që të mbështesin gjithë harduerin. Dhe ata kanë idenë që do të punojnë në Kubernetes. E di që në operatorin e Zalando-s së fundmi kemi parë lidhjen me AWS dhe kjo nuk është shumë mirë. Nuk duhet të ketë lidhje me një infrastrukturë specifike - çfarë ka kuptim atëherë?
DS: Nuk di nĂ« cilĂ«n situatĂ« konkretisht Zalando Ă«shtĂ« lidhur, por nĂ« Kubernetes tani ruajtja Ă«shtĂ« bĂ«rĂ« nĂ« mĂ«nyrĂ« qĂ« nuk mund tĂ« merret njĂ« backup disku nĂ« mĂ«nyrĂ« generike. SĂ« fundmi nĂ« standard - nĂ« versionin mĂ« tĂ« ri â Ă«shtĂ« bĂ«rĂ« e mundur tĂ« merret snapshot, por ku Ă«shtĂ« implementuar? Sinqerisht, ende Ă«shtĂ« kaq e papjekur⊠Ne po e provojmĂ« CSI mbi AWS, GCE, Azure, vSphere, por sapo fillon ta pĂ«rdorĂ«sh, duket se ende nuk Ă«shtĂ« gati.
NS: Prandaj ndonjëherë duhet të lidhemi me infrastrukturën. Mendoj se kjo është ende një fazë e hershme - problemet e rritjes. Pyetje: çfarë do të rekomandoje për fillestarët që duan të provojnë PgSQL në K8s? Cilin operator, ndoshta?
DS: Problemi Ă«shtĂ« se Postgres pĂ«r ne Ă«shtĂ« 3%. Ne kemi njĂ« listĂ« shumĂ« tĂ« madhe softesh tĂ« ndryshĂ«m nĂ« Kubernetes, nuk do ta pĂ«rmend tĂ« gjithĂ«. PĂ«r shembull, Elasticsearch. Ka shumĂ« operatorĂ«: disa po zhvillohen aktivisht, tĂ« tjerĂ« - jo. Ne pĂ«r vete kemi pĂ«rgatitur kĂ«rkesa se çfarĂ« duhet tĂ« ketĂ« njĂ« operator qĂ« ta marrim seriozisht. NĂ« operatorin pĂ«r Kubernetes - jo nĂ« âoperatorin pĂ«r tĂ« bĂ«rĂ« diçka nĂ« kushtet e Amazon-itâ⊠NĂ« fakt ne pĂ«rdorim masivisht (= pothuajse tĂ« gjithĂ« klientĂ«t) njĂ« operator tĂ« vetĂ«m - (shpejt do tĂ« publikojmĂ« njĂ« artikull dhe pĂ«r tĂ«).
NS: Po për MySQL nuk ka edhe? E di që Percona⊠pasi tani ata janë duke u marrë me MySQL, MongoDB dhe Postgres, ata duhet të krijojnë diçka universale: për të gjitha bazat, për të gjithë ofruesit e shërbimeve cloud.
DS: Nuk e kemi parë operatorët për MySQL. Për ne, kjo nuk është fokus kryesor tani. MySQL funktionon mirë në mënyrë independente. Përse operator, nëse mund të fillosh thjesht DB-në... Mund të fillosh një konteiner Docker me Postgres, dhe mund ta nisësh atë në një mënyrë më të thjeshtë.
NS: Kjo ishte një pyetje gjithashtu. Në të vërtetë pa operator?
DS: Po, 100% ne e kemi PostgreSQL-in tĂ« nisur pa operator. PĂ«r momentin kĂ«shtu Ă«shtĂ«. Ne e pĂ«rdorim aktivisht operatorin pĂ«r Prometheus, pĂ«r Redis. Kemi plane pĂ«r tĂ« gjetur njĂ« operator pĂ«r Elasticsearch â ai Ă«shtĂ« mĂ« urgjenti, sepse e duam pĂ«r ta vendosur nĂ« 100% tĂ« rasteve nĂ« Kubernetes. Siç duam tĂ« arrijmĂ« qĂ« MongoDB gjithashtu tĂ« vendoset gjithmonĂ« nĂ« Kubernetes. KĂ«tu dalin disa dĂ«shira â ka njĂ« ndjenjĂ« se nĂ« kĂ«to raste mund tĂ« bĂ«jmĂ« diçka. PĂ«r Postgres nuk kemi parĂ«. Sigurisht, e dimĂ« pĂ«r ekzistencĂ«n e varianteve tĂ« ndryshme, por nĂ« fakt ne kemi qĂ«ndruar me standalone.
DB për testim në Kubernetes
NS: Le tĂ« kalojmĂ« nĂ« temĂ«n e testimit. Si tĂ« zgjerohen ndryshimet nĂ« bazĂ« â nga kĂ«ndvĂ«shtrimi DevOps. Ka mikroshĂ«rbime, shumĂ« baza, gjithmonĂ« ndodhin ndryshime diku. Si tĂ« sigurohet njĂ« CI/CD i mirĂ«, qĂ« nga pozita e DB-sĂ« gjithçka tĂ« jetĂ« nĂ« rregull. Cili Ă«shtĂ« qasja jote?
DS: Nuk mund tĂ« ketĂ« njĂ« pĂ«rgjigje tĂ« vetme. Ka disa parametra. I pari â Ă«shtĂ« madhĂ«sia e bazĂ«s qĂ« duam tĂ« shpĂ«rndajmĂ«. Ti e theve se nĂ« kompani lidhen ndryshe me faktin qĂ« kopja e bazĂ«s prodhuese tĂ« jetĂ« nĂ« dev dhe stage.
NS: Po në kushtet e GDPR, mendoj se ata e trajtojnë gjithnjë e më me kujdes... Mund të them se në Europë janë filluar të ndëshkohen.
DS: Por shpeshherë mund të shkruhet një softuer që bën një dump nga prodhimi dhe e obfuskon atë. Marrim të dhëna prodhuese (snapshot, dump, kopje binare...), por ato janë të anonimizuara. Mund të ketë gjithashtu skedarë gjenerimi: ato mund të jenë fikstura ose thjesht një skenar që gjeneron një bazë të madhe. Problemi qëndron: sa kohë ndihmon në krijimin e imazhit bazë? Dhe sa kohë duhet për ta zbatuar atë në mjedisin përkatës?
Ne erdhĂ«m nĂ« njĂ« skemĂ«: nĂ«se klienti ka njĂ« grup tĂ« dhĂ«nash fikstura (version minimale tĂ« bazĂ«s), atĂ«herĂ« automatikisht i pĂ«rdorim ato. NĂ«se flasim pĂ«r ambientet e rishikimit, kur ne krijuam branch-in, u hap njĂ« instancĂ« e aplikacionit â ne aty shpĂ«rndajmĂ« njĂ« bazĂ« tĂ« vogĂ«l. Por doli mirĂ« dhe , kur ne bĂ«jmĂ« njĂ« dump tĂ« production-it njĂ« herĂ« nĂ« ditĂ« (natĂ«n) dhe grumbullojmĂ« njĂ« kontejner Docker me PostgreSQL dhe MySQL me kĂ«to tĂ« dhĂ«na tĂ« ngarkuara. NĂ«se nga ky imazh duhet tĂ« zhvillojmĂ« databazĂ«n 50 herĂ«, kjo bĂ«het mjaft thjeshtĂ« dhe shpejt.
NS: Thjesht me kopjim?
DS: Të dhënat ruhen direkt në imazhin Docker. Domethënë, kemi një imazh të gatshëm, le të themi 100 GB. Falë shtresave në Docker, ne mund të ndajmë këtë imazh në numrin e nevojshëm herësh. Metoda është e thjeshtë, por funksionon mirë.
NS: MĂ« pas, kur provoni, ajo ndryshon direkt brenda Docker-it, a jo? Copy-on-write brenda Docker-it â heqim dhe fillojmĂ« nga e para, gjithçka Ă«shtĂ« mirĂ«. Super! Dhe ju e pĂ«rdorni kĂ«tĂ« tani?
DS: Që të njëjtë.
NS: Ne merremi me gjëra shumë të ngjashme. Vetëm se ne nuk përdorim copy-on-write të Docker-it, por ndonjë tjetër.
DS: Ai nuk është generic. Por ai i Docker-it funksionon gjithandej.
NS: Në teori, po. Por ne gjithashtu kemi module, mund të krijojmë module të ndryshme dhe të punojmë me sisteme të ndryshme skedarësh. Këtu është një moment. Ne e shikojmë të gjithë këtë nga këndvështrimi i Postgres-it. Tani e kam parë nga këndvështrimi i Docker-it dhe pashë që gjithçka funksionon. Por nëse databaza është e madhe, për shembull, 1 TB, atëherë gjithçka do të jetë e gjatë: dhe operacionet natën, të gjithçka në Docker... Dhe nëse duhet të ngjeshim 5 TB në Docker... A është gjithçka mirë?
DS: ĂfarĂ« ka rĂ«ndĂ«si: ato janĂ« blobs, thjesht bita dhe byte.
NS: Rëndësia është se a e bëni këtë përmes dump dhe restore?
DS: Krejtësisht e panevojshme. Mënyrat për të gjeneruar këtë imazh mund të jenë të ndryshme.
NS: PĂ«r disa klientĂ« ne e bĂ«mĂ« kĂ«shtu qĂ« nĂ« vend tĂ« gjenerimit tĂ« rregullt tĂ« imazhit bazĂ«, ne e mbajmĂ« atĂ« vazhdimisht nĂ« gjendje tĂ« pĂ«rditĂ«suar. Ai nĂ« thelb Ă«shtĂ« njĂ« replikĂ«, por tĂ« dhĂ«nat nuk i merr direkt nga masteri, por pĂ«rmes njĂ« arkive. NjĂ« arkiv binar, ku WAL-tĂ« ngarkohen çdo ditĂ«, dhe aty bĂ«hen rezervat... KĂ«to WAL mĂ« vonĂ« arrijnĂ« â me njĂ« vonesĂ« tĂ« vogĂ«l (nĂ« fakt, 1-2 sekonda) â nĂ« imazhin bazĂ«. Nga ai ne klonojmĂ« me çdo mĂ«nyrĂ« â tani si parazgjedhje kemi ZFS.
DS: Por me ZFS jeni të kufizuar në një nyje.
NS: Po. Por ZFS ka gjithashtu një magji tjetër : me të mund të dërgoni një snapshot dhe madje (këtë nuk e kam testuar shumë, por...) mund të dërgoni diferencën mes dy PGDATA. Në të vërtetë, ne kemi edhe një mjet tjetër, të cilin nuk e kemi shqyrtuar shumë për këto detyra. Në PostgreSQL ka , funksionon si një "rsync" i mençur, duke kaluar shumë prej atij që nuk ka nevojë të shikohet, sepse aty nuk ka ndryshuar asgjë. Ne mund të bëjmë një sinkronizim të shpejtë midis dy serverëve dhe të kthehemi mbrapa ashtu siç është.
Kështu që ne përpiqemi që nga kjo anë më DBA-ta, të bëjmë një instrument që lejon të bëhet e njëjta gjë për të cilën po flisje: ne kemi një bazë, por duam ta testojmë 50 herë, pothuajse njëkohësisht.
DS: 50 herë do të thotë se ju nevojitet të porositni 50 instanca Spot.
NS: Jo, gjithçka bëhet në një makinë.
DS: Por si do të shpërndani 50 herë, nëse kjo një bazë, le të themi, është një terabajt? Ndoshta iu nevojitet 256 GB RAM?
NS: Po, ndonjĂ«herĂ« nevojitet shumĂ« Memorje â Ă«shtĂ« normale. Por ky Ă«shtĂ« njĂ« shembull nga jeta. NĂ« makinĂ«n e production-it ka 96 bĂ«rthamĂ« dhe 600 GB. NdĂ«rsa pĂ«r DB pĂ«rdoren 32 bĂ«rthamĂ« (madje ndonjĂ«herĂ« edhe 16 bĂ«rthamĂ«) dhe memoria 100-120 GB.
DS: Dhe atje futen 50 kopje?
NS: Por kopja është një, më pas funksionon copy-on-write (në ZFS)⊠Do t'jua tregoj më në detaje.
Ne, pĂ«r shembull, kemi njĂ« bazĂ« prej 10 TB. Disku pĂ«r tĂ« Ă«shtĂ« bĂ«rĂ«, ZFS e ka kompresuar madhĂ«sinĂ« e saj me rreth 30-40%. Pasi ne nuk bĂ«jmĂ« teste ngarkese, koha e saktĂ« e pĂ«rgjigjes nuk Ă«shtĂ« e rĂ«ndĂ«sishme: le tĂ« jetĂ« deri nĂ« 2 herĂ« mĂ« e ngadaltĂ« â Ă«shtĂ« nĂ« rregull.
Ne u japim mundĂ«sinĂ« programuesve, QA-ve, DBA-ve etj. tĂ« bĂ«jnĂ« testime nĂ« 1-2 nĂ«ngrupe. PĂ«r shembull, ata mund tĂ« fillojnĂ« njĂ« migrim. Ajo nuk kĂ«rkon menjĂ«herĂ« 10 bĂ«rthama â i nevojitet 1 backend tĂ« Postgres, 1 bĂ«rthamĂ«. Kur migrimi fillon â ndoshta, do tĂ« startojĂ« gjithashtu, pastaj aktivizohet bĂ«rthama e dytĂ«. Ne kemi tĂ« rezervuar 16-32 bĂ«rthama, kĂ«shtu qĂ« 10 njerĂ«z mund tĂ« punojnĂ« pĂ«r njĂ«kohĂ«sish, nuk ka asnjĂ« problem.
Pasi fizikisht PGDATA Ă«shtĂ« e njĂ«jtĂ«, rezulton se nĂ« tĂ« vĂ«rtetĂ« ne jemi duke mashtruar Postgres-in. ĂfarĂ« Ă«shtĂ« truku: fillon, pĂ«r shembull, 10 Postgres tĂ« njĂ«kohshĂ«m. Problemi zakonisht Ă«shtĂ« se vendosin , le tĂ« themi, nĂ« 25%. Pra, kjo Ă«shtĂ« 200 GB. MĂ« shumĂ« se tre tĂ« tilla nuk mund tĂ« startohen, sepse do tĂ« mbarojĂ« memoria.
Por ne në një moment e kuptuam se kjo nuk është e nevojshme: ne vendosim shared_buffers në 2 GB. PostgreSQL ka , dhe në të vërtetë vetëm ai ndikon në . Atë e vendosim në 0,5 TB. Dhe nuk ka rëndësi që në të vërtetë nuk janë atje: ai nd construon planet, si të ishin atje.
Prandaj, kur testojmë ndonjë migrim, mund të grumbullojmë të gjitha planet - do të shohim se si do të ndodhë në production. Sekundat atje do të jenë ndryshe (më të ngadalta), por të dhënat që ne vërtet i lexojmë dhe vetë planet (cila është JOIN etj.) dalin të njëjta si në production. Dhe paralelisht mund të lancojmë shumë nga këto kontrolle në një makinë.
DS: A nuk mendon se ka disa probleme këtu? E para - është një zgjidhje që funksionon vetëm në PostgreSQL. Ky qasje është shumë specifike, nuk është generic. E dyta - Kubernetes (dhe gjithçka që tani po shkon në teknologjitë cloud) parashikon shumë nyje, dhe këto nyje janë efemere. Ndërsa në rastin tuaj është një nyje stateful, persistente. Këto gjëra më krijojnë kontradikta.
NS: E para - jam dakord, kjo është një histori krejtësisht Postgres. Mendoj se nëse kemi ndonjë IO direkt dhe një pool buffer pothuajse për të gjithë memorien, ky qasje nuk do të funksionojë - planet do të jenë të tjera. Por për momentin punojmë vetëm me Postgres, për të tjerët nuk po mendojmë.
Për Kubernetes. Ti vetë e tregon kudo se baza jonë është persistente. Nëse instanca bie, e rëndësishme është të ruash diskun. Ja, ne gjithashtu e gjithë platforma është në Kubernetes, dhe komponenti me Postgres është veçmas (edhe pse njëherë do të jetë atje). Prandaj, është kështu: instanca bie, por ne kemi ruajtur PV-në e saj dhe thjesht e lidhim me një instancë tjetër (të re), siç nuk ndodhi asgjë.
DS: Nga këndvështrimi im, ne krijojmë podë në Kubernetes. K8s është elastik: nyjet porositen vetë sipas nevojës. Detyra është thjesht të krijosh një pod dhe të thuash se i duhen X burime, dhe më pas K8s do ta rregullojë vetë. Por mbështetje e ruajtjeve në Kubernetes mbetet ende e paqëndrueshme: në , në (këtë version doli javë mirëpas
kësaj, këto veçori bëhen vetëm beta. Do të kalojnë gjashtë muaj deri një vit - do të bëhet më ose më pak e qëndrueshme, ose të paktën do të shpallet si e tillë. Atëherë mundësia e snapshot-eve dhe resize-it zgjidh plotësisht problemat tuaj. Sepse keni një bazë. Po, ajo mund të mos jetë shumë e shpejtë, por shpejtësia varet nga ajo që është "në kapak", sepse disa implementime dinë të bëjnë kopje dhe copy-on-write në nivelin e sistemit të disqeve.
NS: KĂ«tu duhet gjithashtu qĂ« tĂ« gjitha motorĂ«t (Amazon, GoogleâŠ) tĂ« fillojnĂ« tĂ« mbĂ«shtesin kĂ«tĂ« version - kjo gjithashtu merr ndonjĂ« kohĂ«.
DS: Deri tani nuk i përdorim ato. Ne përdorim tonat.
Zhvillimi lokal nën Kubernetes
NS: A ke keshillëse ndonjëherë për një dëshirë që duhet të ngrejë çdo pod në një makinë dhe të bëjë një test të vogël. Për shpejtësi për të marrë një provë koncepti, duke parë se si punon aplikacioni në Kubernetes, pa e ndarë këtë një grumbull makinash. Ka Minikube, apo jo?
DS: MĂ« duket se ky rast â tĂ« vendosĂ«sh njĂ« node â Ă«shtĂ« pĂ«r zhvillimin lokal ekskluzivisht. Ose disa shprehje tĂ« kĂ«tij modeli. Ka , ka , . Po shkojmĂ« drejt pĂ«rdorimit tĂ« Kubernetes IN Docker. Tani kemi filluar tĂ« punojmĂ« me tĂ« pĂ«r teste.
NS: MĂ« parĂ« mendova se ishte pĂ«r pĂ«rpjekjen pĂ«r tĂ« futur tĂ« gjitha pod nĂ« njĂ« imazh Docker. Por doli se Ă«shtĂ« krejt ndryshe. SĂ«rish ka konteinerĂ« tĂ« veçantĂ«, pod tĂ« veçantĂ« â thjesht nĂ« Docker.
DS: Po. Dhe ka njĂ« simulim mjaft tĂ« qeshur atje, por ideja Ă«shtĂ« kjo⊠Kemi njĂ« utilitar pĂ«r deploy â . Duam tĂ« bĂ«jmĂ« njĂ« mod pĂ«r atĂ« â hipotetikisht werf up: «MĂ« ngre Kubernetes lokal». Dhe mĂ« pas tĂ« nisim njĂ« werf follow. AtĂ«herĂ« zhvilluesi do tĂ« mund tĂ« bĂ«jĂ« ndryshime nĂ« IDE, ndĂ«rsa nĂ« sistem Ă«shtĂ« njĂ« proces qĂ« sheh ndryshimet dhe rindĂ«rton imazhet, duke i ri-ndryshuar ato nĂ« K8s lokal. KĂ«shtu duam tĂ« pĂ«rpiqemi tĂ« zgjidhim problemin e zhvillimit lokal.
Snapshotet dhe klonimi i DB në realitetin K8s
NS: NĂ«se kthehemi te copy-on-write. Vura re se edhe rekuperimet nĂ« cloud kanĂ« snapshotet. PunojnĂ« ndryshe. PĂ«r shembull, nĂ« GCP: ke njĂ« instancĂ« shumĂ«-terabajt nĂ« bregun lindor tĂ« SHBA-ve. BĂ«n periodikisht snapshotet. Ngre njĂ« kopje tĂ« diskut nga snapshot nĂ« bregun perĂ«ndimor â pas disa minutash Ă«shtĂ« gjithçka gati, punon shumĂ« shpejt, vetĂ«m caches duhet tĂ« mbushen nĂ« kujtesĂ«. Por kĂ«to klonime (snapshotet) janĂ« pĂ«r tĂ« 'provision'-uar njĂ« vĂ«llim tĂ« ri. Kjo Ă«shtĂ« e shkĂ«lqyer kur duhet tĂ« krijosh shumĂ« instanca.
Por pĂ«r teste, mendoj se snapshotet pĂ«r tĂ« cilat po flasĂ«sh nĂ« Docker ose unĂ« flas nĂ« ZFS, btrfs dhe madje LVM⊠â lejojnĂ« pikĂ«risht qĂ« nĂ« njĂ« makinĂ« tĂ« mos krijosh tĂ« dhĂ«na tĂ« reja realisht. NĂ« cloud do tĂ« paguash pĂ«r to sa herĂ«, dhe do tĂ« presĂ«sh jo sekonda, por minuta (nĂ« rastin e ndoshta edhe orĂ«).
NĂ« vend tĂ« kĂ«saj, mund tĂ« marrĂ« kĂ«to tĂ« dhĂ«na pĂ«r njĂ« sekondĂ«-dy, tĂ« zhvillosh testin dhe ta heqĂ«sh. KĂ«to snapshotet zgjidhin detyra tĂ« ndryshme. NĂ« rastin e parĂ« â pĂ«r tĂ« u zgjeruar dhe pĂ«r tĂ« marrĂ« replika tĂ« reja, nĂ« tĂ« dytĂ«n â pĂ«r teste.
DS: Nuk e pranoj. Të bësh një klonim të duhur të volumit është një detyrë për cloud. Nuk kam parë implementimin e tyre, por e di si e bëjmë ne në hardware. Ne kemi Ceph, ku mund t'i themi çdo volum fizik () dhe të marrim për disa milisekonda një volum të dytë me karakteristika të njëjta, clone IOPS : Por, ata gjithsesi do të duhet disa sekonda, disa dhjetëra sekonda, për të ngritur instancën, për të sjellë aty Docker etj.
NS: Pse Ă«shtĂ« e nevojshme tĂ« ngresh njĂ« instancĂ« tĂ« tĂ«rĂ«? Ne kemi njĂ« instancĂ« me 32 bĂ«rthamĂ«, me 16⊠dhe aty mund tĂ« hyjnĂ« disa â pĂ«r shembull, katĂ«r. Kur kĂ«rkojmĂ« tĂ« pestin, do tĂ« ngrihet njĂ« instancĂ«, e pastaj do tĂ« fshihet.
DS: Po, është interesante, në Kubernetes del një histori tjetër. Ne kemi DB-në jo në K8s, dhe një instancë. Megjithatë, për klonimin e një baze me shumë terabajt, nuk merr më shumë se dy sekonda.
NS: Kjo është e mrekullueshme. Por mesazhi im fillestar është se kjo nuk është një zgjidhje generike. Po, është e shkëlqyer, por përshtatet vetëm me Postgres dhe vetëm në një nyje.
DS: Ajo i përshtatet jo vetëm për Postgres: këto plane, siç përshkrova, do të funksionojnë vetëm në të. Por nëse nuk merremi me plane, por na duhen të dhënat për testimin funksional, atëherë kjo do të ishte e përshtatshme për çdo SGBD.
NS: Shumë vite më parë ne bëmë diçka të tillë me snapshotet e LVM. Kjo është klasikë. Ky qasje u përdor shumë. Thjesht, nyjet stateful janë një dhimbje. Sepse duhet t'i kujdesesh, gjithmonë të mbash mend për to...
DS: A nuk sheh ndonjĂ« mundĂ«si pĂ«r njĂ« hibrid kĂ«tu? Supozoni se stateful Ă«shtĂ« ndonjĂ« pod, ai punon pĂ«r disa njerĂ«z (shumĂ« testues). Volumi ynĂ« Ă«shtĂ« njĂ«, por falĂ« sistemit tĂ« skedarĂ«ve klonĂ«t â lokal. NĂ«se pod-i bie, disku mbetet â do tĂ« ngrihet pĂ«rsĂ«ri pod-i, do tĂ« lexojĂ« informacionin pĂ«r tĂ« gjithĂ« klonĂ«t, do tĂ« ngrejĂ« gjithçka mbrapsht dhe do tĂ« thotĂ«: "KĂ«tu janĂ« klonĂ«t tuaj tĂ« ngritur nĂ« kĂ«to porte, punoni me ta mĂ« tej".
NS: Teknikisht, kjo do të thotë se brenda Kubernetes është një pod, brenda të cilit ne lançohemi shumë Postgres.
DS: Po. Ai ka njĂ« kufizim: supozoni se nĂ« tĂ« njĂ«jtĂ«n kohĂ« punojnĂ« jo mĂ« shumĂ« se 10 njerĂ«z. NĂ«se nevojiten 20 â do tĂ« ngremĂ« njĂ« pod tĂ« dytĂ« tĂ« tillĂ«. PlotĂ«sisht e mundur ta klonojmĂ«, duke marrĂ« njĂ« volum tĂ« dytĂ« tĂ« plotĂ«, ku do tĂ« kemi gjithashtu 10 "tĂ« hollĂ«" klonĂ«. A nuk sheh ndonjĂ« mundĂ«si tĂ« tillĂ«?
NS: Po, nuk e shoh as të tillë.
DS: Duhet tĂ« shtohen kĂ«tu pyetje pĂ«r sigurinĂ«. Ky variant organizimi nĂ«nkupton se ky pod ka privilegje tĂ« larta (capabilities), sepse mund tĂ« kryejĂ« operacione jo standarde mbi sistemin e skedarĂ«ve... Por pĂ«rsĂ«ris: mendoj se nĂ« perspektivĂ«n afatmesme Kubernetes do tĂ« rregullojĂ« ruajtjen, nĂ« cloud do tĂ« zgjidhen tĂ« gjitha historitĂ« me volumet â gjithçka do tĂ« funksionojĂ« 'vetĂ«m'. Do tĂ« ketĂ« resize, klonim... Ka njĂ« volum â ne themi: 'Krijo njĂ« tĂ« ri mbi atĂ«', dhe pas njĂ« sekonde e gjysmĂ« e marrim atĂ« qĂ« na nevojitet.
NS: Nuk e besoj se do të bëhet në një sekondë e gjysmë për shumë terabajtë. Në Ceph e bën vetë, por po flet për cloud. Shko në cloud, në EC2 bëj një klon të volumit EBS të shumë terabajtëve dhe shiko çfarë performancë do të ketë. Nuk do të marrë disa sekonda. Më intereson shumë kur do të arrijnë në këtë tregues. E kuptoj për çfarë po flet, por do të lejoj veten të mos pranoj.
DS: Ok, por thashë se në perspektivën afatmesme, jo afatshkurtër. Për disa vite.
Për operatorin për PostgreSQL nga Zalando.
Në mes të kësaj takimi u bashkua gjithashtu Aleksej Kljukin, një ish-programues nga kompania Zalando, i cili tregoi historinë e operatorit PostgreSQL:
ĂshtĂ« e shkĂ«lqyer qĂ« ky temĂ« u prek: dhe Postgres, dhe Kubernetes. Kur filluam ta bĂ«nim kĂ«tĂ« nĂ« Zalando nĂ« vitin 2017, kjo ishte njĂ« temĂ« me tĂ« cilĂ«n tĂ« gjithĂ« dĂ«shironin tĂ« merreshin, por askush nuk e bĂ«nte. TĂ« gjithĂ« kishin filluar tĂ« merrnin Kubernetes, por kur pyeteshin se si tĂ« veprohej me baza tĂ« dhĂ«nash, edhe njerĂ«z si , qĂ« predikonin K8s, thonin diçka si:
'Shkoni në shërbimet e menaxhuara dhe përdorni ato, mos e nisni DB-në në Kubernetes. Përndryshe, K8s juaj do të vendosë, për shembull, të bëjë një azhurnim, do të fikë të gjitha nyjat dhe të dhënat tuaja do të shkojnë shumë larg'.
Ne vendosĂ«m tĂ« bĂ«jmĂ« njĂ« operator, i cili do tĂ« funksiononte, pavarĂ«sisht kĂ«tij kĂ«shillimi, pĂ«r tĂ« nisur DB-nĂ« Postgres nĂ« Kubernetes. Dhe kishim njĂ« bazĂ« tĂ« mirĂ« â . Ky Ă«shtĂ« njĂ« sistem automatik pĂ«r kalimin nĂ« rast dĂ«shtimi pĂ«r PostgreSQL, i bĂ«rĂ« siç duhet, dmth. duke pĂ«rdorur etcd, consul ose ZooKeeper si njĂ« depo pĂ«r informacionin mbi klasterin. NjĂ« depo e tillĂ«, qĂ« do tĂ« jepte tĂ« gjitha, ata qĂ« pyesin, pĂ«r shembull, kush Ă«shtĂ« tani lideri, tĂ« njĂ«jtin informacion â pavarĂ«sisht se kemi gjithçka tĂ« shpĂ«rndarĂ«, â pĂ«r tĂ« parandaluar split brain-in. Plus, kishim njĂ« pĂ«r tĂ«.
Në të vërtetë, nevoja për auto failover tek kompania u shfaq pas migrimit nga data center-i i brendshëm në cloud. Cloud-i ishte ndërtuar mbi një zgjidhje të vetme PaaS (Platform-as-a-Service). Ishte Open Source, por për ta ngritur, duhej punuar shumë. Quhej .
Fillimisht nuk kishte asnjĂ« Kubernetes. NjĂ«lloj, kur u zhvillua zgjidhja e brendshme, K8s tashmĂ« ekzistonte, por ishte aq i papjekur sa nuk ishte i pĂ«rshtatshĂ«m pĂ«r prodhim. Kjo ishte, nĂ« mendjen time, nĂ« vitin 2015 ose 2016. Deri nĂ« vitin 2017, Kubernetes u bĂ« mĂ« se mĂ«se i pjekur â shfaqej nevoja pĂ«r migrim atje.
Dhe ne kishim njĂ« kontenier Docker. PatĂ«m PaaS, e cila pĂ«rdorte Docker. Pse tĂ« mos provonim K8s? Pse tĂ« mos shkruanim operatorin tonĂ«? Murat Kabilov, i cili erdhi te ne nga Avito, e filloi kĂ«tĂ« si njĂ« projekt nga iniciativa e tij â "tĂ« luante" â dhe projekti "fluturoi".
Por në të vërtetë, doja të flisja për AWS. Pse aty kishte historikisht kod që lidhej me AWS...
Kur nisni ndonjĂ« gjĂ« nĂ« Kubernetes, duhet tĂ« kuptoni se K8s Ă«shtĂ« njĂ« punĂ« nĂ« progres. Ai zhvillohet vazhdimisht, pĂ«rmirĂ«sohet dhe herĂ« pas here, madje dĂ«shtojĂ«. Duhet tĂ« jeni tĂ« vĂ«mendshĂ«m ndaj tĂ« gjitha ndryshimeve nĂ« Kubernetes, duhet tĂ« jeni tĂ« gatshĂ«m, nĂ« rast se ndodh ndonjĂ« gjĂ«, tĂ« zhytuni nĂ« tĂ« dhe tĂ« mĂ«soni se si funksionon nĂ« detaje â ndoshta mĂ« shumĂ« se çfarĂ« do tĂ« donit. Kjo vlen pĂ«r çdo platformĂ« ku nisni bazat e tĂ« dhĂ«nave...
Pra, kur po bĂ«nim operatorin, ne kishim Postgres qĂ« punonte me njĂ« volum tĂ« jashtĂ«m (nĂ« kĂ«tĂ« rast â EBS, sepse po punonim nĂ« AWS). Baza e tĂ« dhĂ«nave u rrit, nĂ« njĂ« moment u kĂ«rkua tĂ« bĂ«hej resize: pĂ«r shembull, pĂ«rmasat fillestare EBS ishin 100 TB, baza arriti nĂ« atĂ« madhĂ«si, tani duam tĂ« rrisim EBS nĂ« 200 TB. Si? Supozoni se mund tĂ« bĂ«ni dump/restore nĂ« njĂ« instancĂ« tĂ« re, por kjo merr kohĂ« dhe ka ndalesa.
Prandaj, donim një resize që do të rrisë sektorin e EBS dhe pastaj do të thoshte sistemit të fichiers se të përdorë hapësirën e re. Dhe ne e bëmë këtë, por në atë kohë Kubernetes nuk kishte asnjë API për operacionin e resize-it. Duke qenë se po punonim në AWS, shkruam kodin për API-në e tij.
Askush nuk e pengon tĂ« bĂ«jĂ« tĂ« njĂ«jtĂ«n gjĂ« pĂ«r platforma tĂ« tjera. NĂ« operator nuk ka asnjĂ« lidhje qĂ« mund tĂ« niset vetĂ«m nĂ« AWS, dhe nĂ« çdo gjĂ« tjetĂ«r nuk do tĂ« funksionojĂ«. NĂ« pĂ«rgjithĂ«si, ky Ă«shtĂ« njĂ« projekt Open Source: nĂ«se dikush dĂ«shiron tĂ« pĂ«rshpejtojĂ« shfaqjen e pĂ«rdorimit tĂ« API-sĂ« sĂ« re â mirĂ«seardhĂ«t. , pull request-Ă«t â ekipi i Zalando pĂ«rpiqet tĂ« reagojĂ« mjaft shpejt ndaj tyre dhe tĂ« avancojĂ« operatorin. Sipas sa di, projekti nĂ« Google Summer of Code dhe iniciativa tĂ« ngjashme. Zalando po punon shumĂ« aktivisht mbi tĂ«.
P.S. Bonus!
Nëse jeni të interesuar për temën e PostgreSQL dhe Kubernetes, ju kujtojmë gjithashtu se javën e kaluar u mbajt Postgres-e martë, ku me Nikolain bisedoi Aleksandër Kukushkin nga Zalando. Video prej tij është e disponueshme .
P.P.S.
Lexoni gjithashtu në blogun tonë:
- «»;
- «»;
- «»;
- «».
Burimi: habr.com
