Në fund të vitit të kaluar u mbajt një tjetër transmetim të drejtpërdrejtë të komunitetit rus të PostgreSQL, , në kuadër të të cilit bashkëthemeluesi i tij Nikolai Samokhvalov fliste me drejtorin teknik të «Flanta», Dmitry Stolyarov, për këtë SGBD në kontekstin e Kubernetes.
Ne publikojmë transkriptin e pjesës kryesore të kësaj diskusione, dhe në është publikuar regjistrimi i plotë video:
Baza të dhënash dhe Kubernetes
NS: Sot nuk do flasim për VACUUM dhe CHECKPOINT. Duam të flasim për Kubernetes. E di që ti ke shumë vjet përvojë. Kam parë videot e tua dhe disa madje i kam regjistruar… Le të kalojmë direkt në temë: përse në të vërtetë 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ësi dhe komoditet… potenciale. Të gjithë duan shërbime të menaxhuara.
NS: Që si , vetëm në shtëpi?
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 është një kompani e madhe, të mos marrësh një zgjidhje të gatshme? Për shembull, Nutanix ka zhvillimet e veta, kompanitë e tjera (VMware…) kanë gjithashtu «RDS, vetëm në shtëpi».
DS: Por po flasim për një implementim të veçantë, i cili do të funksionojë vetëm në kushte të caktuara. Kur flasim për Kubernetes, ka një shumëllojshmëri të madhe infrastrukture (e cila mund të jetë në K8s). Në thelb, kjo është një standard për API për cloud…
NS: Dhe gjithashtu falas!
DS: Kjo nuk është aq e rëndësishme. Falas përbën një segment të vogël të tregut. E rëndësishme është diçka tjetër… Ti, ndoshta, e mban mend prezantimin»?
NS: Po.
DS: E kuptova, që u perceptua shumë në mënyra të ndryshme. Disa njerëz menduan se unë thashë: «Djem, le të çojmë të gjitha DB-të në Kubernetes!», — ndërsa të tjerët menduan se këto ishin të gjitha biçikleta të tmerrshme. Por unë doja të thosha diçka tjetër: «Shikoni, çfarë po ndodh, cilat janë problemet dhe si mund të zgjidhen. A duhet të çojmë bazat në Kubernetes? Në production? Po, vetëm nëse ju pëlqen… të merreni me disa gjëra të caktuara. Por për zhvillim — mund të them se e rekomandoj. Për zhvillim është shumë e rëndësishme dinamika e krijimit / fshirjes së mjediseve».
NS: Me zhvillimin ke në mendje të gjitha ambientet që nuk janë prodhim? Staging, QA…
DS: Nëse flasim për performancën, ndoshta jo, sepse aty kërkesat janë specifike. Nëse flasim për raste të veçanta, ku në staging duhet një DB shumë e madhe, atëherë ndoshta ashtu… Nëse është një ambient statik, afatgjatë, cila është përfitimi që DB është në K8s?
NS: Asnjë. Por ku i shohim ambientet statike? Ambientet statike kanë skaduar tashmë nesër.
DS: Staging mund të jetë statik. Ne kemi klientë…
NS: Po, kam edhe unë. Është një problem i madh, nëse ke një DB me 10 Tb, ndërsa staging — 200 Gb…
DS: Kam një rast shumë të mrekullueshëm! Në staging ndodhet një bazë prodhimi, në të cilën bëhen ndryshime. Dhe është parashikuar një buton: «aktualizo në prodhim». Këto ndryshime — dytë — merren (duket, thjesht sinkronizohen përmes API-së) në prodhim. Ky është një variant shumë ekzotik.
NS: Kam parë startup-e në Silicon Valley, që janë në RDS ose madje në Heroku ende — këto janë histori 2-3 vjet të kaluara, — dhe ata shkarkojnë dump-in te vetja në laptop. Sepse baza është vetëm 80 Gb, dhe ka vend në laptop. Pastaj ata blejnë disqe për secilin, në mënyrë që të kenë 3 baza, për të udhëhequr zhvillime të ndryshme. Kështu ndodh gjithashtu. Kam parë gjithashtu që nuk e kanë frikë të kopjojnë prodhimin në staging — kjo varet shumë nga kompania. Por gjithashtu kam parë që kanë shumë frikë, dhe që shpesh nuk kanë kohë dhe duar. Por përpara se të kalojmë në këtë temë, dua të dëgjoj për Kubernetes. E kuptoj saktësisht, që në prodhim akoma askush?
DS: Ne kemi disa baza të vogla në prodhim. Flasim për vëllime në dhjetëra gigabajt dhe shërbime jo kritikë, për të cilat nuk kishte dëshirë të krijonin replika (as nuk kishte një nevojë të tillë). Dhe me kusht që nën Kubernetes të ketë ruajtje të mirë. Kjo bazë ka funksionuar në një makinë virtuale — lehtësisht me VMware, mbi sistemin e ruajtjes. E vumë në dhe tani mund ta transferojmë nga makina në makinë.
NS: Baza të këtij madhësie, deri në 100 Gb, në disqe të mira dhe me një rrjet të mirë mund të shpërndahet brenda disa minutash, e drejtë? Shpejtësia prej 1 Gb në sekondë — kjo nuk është më ekzotike.
DS: Po, për një operacion linear, kjo nuk është problem.
NS: Okej, për prodhim duhet vetëm të mendojmë. Por nëse e shqyrtojmë Kubernetes për ambientet jo-prodhuese — si ta bëjmë? Shikoj që në Zalando , në Crunchy , ka edhe disa mundësi të tjera. Dhe ka — ky është një mik ynë i mirë Alvaro nga Spanja: ata bëjnë përfundimisht jo vetëm , por një distribucion të tërë (), në të cilin përveç vetë Postgres-it vendosën edhe të përfshijnë backup-in, proxy-në Envoy…
DS: Envoy për çfarë? Për balancimin e trafikut pikërisht Postgres?
NS: Po, ato ata e shohin si: nëse marrim një distribuim të Linux-it dhe kernelin, atëherë PostgreSQL-i i zakonshëm është kernel, dhe ata duan të krijojnë një distribucion që do të jetë miqësor me cloud-in dhe do të funksionojë në Kubernetes. Ata lidhen me komponentët (backup-et etj.) dhe i testojnë që të funksionojnë mirë.
DS: Shumë super! Në thelb, kjo është një soft që krijon PostgreSQL të menaxhuar.
NS: Distribuimet e Linux-it kanë probleme të vazhdueshme: si të bëjnë drejtuese që të mbështetet çdo hardware. Dhe ata kanë idenë që do të punojnë në Kubernetes. E di që në operatorin Zalando, së fundmi, kemi parë lidhje me AWS dhe kjo nuk është shumë mirë. Nuk duhet të ketë lidhje me një infrastrukturë të veçantë — çfarë ka kuptim atëherë?
DS: Nuk e di, në cilën situatë konkretisht Zalando u lidh, por në Kubernetes tani storage është bërë kështu që nuk mund të merret një backup diskesh në mënyrë generike. Së fundmi, në standard, në versionin më të fundit — krijoi mundësinë e snapshot-eve, por ku është realizuar? Sinqerisht, ende është kaq në fillim… Ne po provojmë CSI mbi AWS, GCE, Azure, vSphere, por sapo fillon ta përdorësh, shihet se nuk është ende 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ë sugjeroje për fillestarët që duan të provojnë PgSQL në K8s? Cili operator, ndoshta?
DS: Problemi është se PostgreSQL për ne është 3%. Ne kemi një listë shumë të madhe të softuerëve të ndryshëm në Kubernetes, nuk do të përmend gjithçka. Për shembull, Elasticsearch. Ka shumë operatorë: disa po zhvillohen aktivisht, të tjerë jo. Ne kemi krijuar kërkesat për atë që duhet të ketë një operator në mënyrë që ne 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 mjaft masivisht (= pothuajse tek të gjithë klientët) një operator të vetëm — (shpejt do të publikojmë një artikull edhe për të).
NS: Dhe për MySQL nuk ka? E di që Percona… pasi ata tani merren me MySQL, MongoDB dhe PostgreSQL, ata duhet të krijojnë një zgjidhje universale: për të gjitha databazat, për të gjitha ofruesit e cloud.
DS: Nuk kemi pasur kohë të shohim operatorët për MySQL. Për ne tani nuk është fokusi kryesor. MySQL funksionon mirë në standalone. Pse një operator, nëse mund të thjesht nisësh DBA… Mund të startosh një kontejner Docker me Postgres, apo mund ta nisësh thjesht.
NS: Edhe për këtë ishte një pyetje. Në fakt pa operator?
DS: Po, në 100% të rasteve PostgreSQL ynë është nisur pa operator. Deri tani kështu. Ne aktivisht përdorim operator për Prometheus, për Redis. Kemi në planet të gjejmë një operator për Elasticsearch — ai është më i rëndësishëm, sepse duam ta vendosim në 100% të rasteve në Kubernetes. Po ashtu, siç duam të arrijmë të vendosim gjithashtu MongoDB gjithmonë në Kubernetes. Këtu dalin disa dëshira — ka një ndjesi se në këto raste mund të bëhet diçka. Dhe për Postgres, ne as nuk kemi parë. Sigurisht, e dimë për ekzistencën e variantëve të ndryshëm, por në fakt ne kemi standalone.
DB për testim në Kubernetes
NS: Le të kalojmë te tema e testimit. Si të implementosh ndryshimet në bazë — nga perspektiva e DevOps. Ka mikroshërbime, shumë baza, gjithmonë diçka po ndryshon diku. Si të sigurosh një CI/CD normal, për të qenë gjithçka në rregull nga perspektiva e DB-së. Cili është qasja jote?
DS: Nuk mund të ketë një përgjigje të vetme. Ka disa parametra. E para — është madhësia e bazës, që ne duam të implementojmë. Ti vetë e theke se në kompanitë lidhen ndryshe me atë që një kopje e bazës prodhuese të jetë në dev dhe stage.
NS: Dhe në kushte GDPR, mendoj se ata janë gjithnjë e më të kujdesshëm… Mund të them se në Evropë filluan të gjobisin.
DS: Por shpesh mund të shkruhet një soft që bën dump nga prodhimi dhe e obfuskon atë. Kështu marrim të dhëna prodhuese (snapshot, dump, kopje binar…), por ato janë të anonimizuara. Në vend të kësaj mund të ketë dhe skripte gjenerimi: mund të jenë fikstura ose thjesht një skript që gjeneron një bazë të madhe. Problemi është: sa kohë krijohet imazhi bazë? Dhe sa kohë zgjerohet në ambientin e nevojshëm?
Ne arritëm në një skemë: nëse klienti ka një grup të dhënash fikstura (versioni minimal i bazës), atëherë si rregull përdorim ato. Nëse flasim për ambientet review, kur ne krijuam branch-in, na u krijua një instancë e aplikacionit — ne atje implementojmë një bazë të vogël. Por u arrit gjithashtu të , kur nga prodhimi një herë në ditë (në mesnatë) marrim një dump dhe ndërrymë mbi të një kontejner Docker me PostgreSQL dhe MySQL me këto të dhëna të ngarkuara. Nëse nga ky imazh duhet të zgjasim bazën 50 herë, kjo bëhet mjaft lehtë dhe shpejt.
NS: Me kopjim të thjeshtë?
DS: Të dhënat ruhen direkt në imazhin Docker. Domethënë, ne kemi një imazh të gatshëm, le të themi, 100 GB. Falë shtresave në Docker, ne mund të shërbim shpejt këtë imazh aq herë sa na nevojitet. Metoda është e thjeshtë, por funksionon mirë.
NS: Më pas, kur e testoni, ajo ndryshon pikërisht brenda Docker’it, a është e vërtetë? Copy-on-write brenda Docker’it — ne heqim dhe fillojmë sërish, gjithçka është në rregull. Superb! A e përdorni këtë tashmë?
DS: Prej një kohe.
NS: Ne merremi me gjëra shumë të ngjashme. Por ne nuk përdorim kopjen-on-shkrim të Docker’it, por diçka tjetër.
DS: Ai nuk është universal. Por ai i Docker’it funksionon gjithandej.
NS: Në teori, po. Por ne gjithashtu kemi module atje, mund të krijojmë module të ndryshme dhe të punojmë me sisteme të ndryshme skedarësh. Këtu është një pikë. Ne e shohim këtë ndryshe nga pjesa e Postgres. Tani e pashë nga ana e Docker’it dhe pashë se gjithçka funksionon. Por nëse baza është e madhe, për shembull, 1 TB, atëherë gjithçka është më e ngadaltë: dhe operacionet ndodhin natën, dhe për ta futur gjithçka në Docker... Po nëse futim 5 TB në Docker... A është gjithçka në rregull?
DS: Çfarë rëndësi ka: ato janë bloba, thjesht biti dhe byte.
NS: Rëndësia është: e bëni këtë përmes dump dhe restore?
DS: Absolutisht jo, mënyrat e krijimit të këtij imazhi mund të jenë të ndryshme.
NS: Për disa klientë kemi bërë që, në vend të gjenerimit të rregullt të imazhit bazë, ne e mbajmë atë gjithmonë në gjendje aktuale. Ai në thelb është një replika, por të dhënat nuk i merr direkt nga masteri, por përmes arkivave. Një arkiv binar, ku WAL’ët përditë ngjiten, gjithashtu merren backup... Këto WAL’ë më pas arrijnë — me një vonesë të vogël (ndoshta 1-2 sekonda) — në imazhin bazë. Nga ai ne e kopjojmë në çdo mënyrë — tani sipas parazgjedhjes është ZFS.
DS: Por me ZFS jeni të kufizuar në një nyje.
NS: Po. Por ZFS ka gjithashtu një magji : me të mund të dërgoni një snapshot dhe madje (këtë nuk e kam testuar shumë përpara, por…) mund të dërgoni dytë mes dy PGDATA. Në të vërtetë, ne kemi një mjet tjetër, të cilin nuk e kemi shqyrtuar shumë për këto detyra. Në PostgreSQL ka , i cili funksionon si një rsync “inteligjent”, që shmang shumë nga ajo që nuk është e nevojshme të shikohet, sepse atje nuk ka ndryshuar asgjë. Ne mund të bëjmë një sinkronizim të shpejtë mes dy serverëve dhe të kthehemi pas njëlloj.
Pra, ne përpiqemi nga kjo, nga ana më DBA, të krijojmë një mjet që lejon të bëjmë të njëjtën gjë, për të cilën ti përmende: ne kemi një bazë, por duam ta testojmë 50 herë, pothuajse njëkohësisht.
DS: 50 herë do të thotë se duhet të kërkoni 50 instanca Spot.
NS: Jo, e bëjmë në një makinë.
DS: Por si do ta zhvilloni 50 herë, nëse kjo një bazë, le të themi, është një terabajt? Më shumë se të paktën 256 GB RAM?
NS: Po, ndonjëherë nevojitet shumë memorie — kjo është normale. Por një shembull nga jeta. Në makinat e production janë 96 bërthamë dhe 600 GB. Në të njëjtën kohë për DB përdoren 32 bërthama (në disa raste edhe 16 bërthama tani) dhe memorja 100-120 GB.
DS: Dhe atje futen 50 copia?
NS: Ka vetëm një kopje, më pas funksionon copy-on-write (ZFS)... Do ta shpjegoj më tepër.
Për shembull, baza jonë është 10 TB. Disku për të është bërë, ZFS akoma e ka kompresuar madhësinë e saj me rreth 30-40%. Pasi ne nuk bëjmë testim ngarkese, koha e saktë e reagimit nuk ka rëndësi: le të jetë deri në 2 herë më e ngadaltë — kjo është në rregull.
Ne u japim mundësi zhvilluesve, QA, DBA etj. të kryejnë testimin në 1-2 procese. Për shembull, ata mund të aktivizojnë ndonjë migrim. Ajo nuk kërkon menjëherë 10 bërthama — i nevojitet 1 backend Postgres, 1 bërthamë. Migrimi do të fillojë — ndoshta, do të fillojë përsëri, atëherë do të angazhohet bërthama e dytë. Ne kemi rezervuar 16-32 bërthama, kështu që 10 njerëz mund të punojnë njëkohësisht, nuk ka probleme.
Pasi fizikisht PGDATA është e njëjtë, rezulton se ne i mashtrojmë Postgres në të vërtetë. Çfarë është tema: për shembull, aktivizohen 10 Postgres’ë njëkohësisht. Cilës është zakonisht problemi? Ata vendosin , le të themi, në 25%. Për rrjedhojë, kjo është 200 GB. Nuk mund të aktivizoni më shumë se tre të tillë, sepse memoria do të mbarojë.
Por në një moment kupton se kjo nuk është e nevojshme: ne e vendosim shared_buffers në 2 GB. Në PostgreSQL ka , dhe në realitet ai ndikon vetëm në . Ne e vendosim atë në 0,5 TB. Dhe madje nuk ka rëndësi se ata në të vërtetë nuk ekzistojnë: ai ndërtan planet sikur ata janë.
Kështu, kur testojmë ndonjë migrim, mund të mbledhim të gjitha planet — do të shohim se si do të ndodhte në production. Sekundat atje do të jenë të tjera (më të ngadalta), por të dhënat që ne të vërtetë lexojmë dhe vetë planet (cilat janë JOIN’ët etj.) janë pikërisht si në production. Dhe paralelisht mund të aktivizoni shumë nga këto kontrolle në një makinë.
DS: A nuk mendon se këtu ka disa probleme? E para — është një zgjidhje që punon vetëm në PostgreSQL. Ky qasje — është shumë specifike, nuk është generic. E dyta — Kubernetes (dhe gjithçka, ku tani po shkojnë teknologjitë cloud) supozon shumë nyje, dhe këto nyje — janë efemerale. Dhe në rastin tënd, ky është një nyje stateful, me përhershmëri. Këto gjëra më krijojnë kontradita.
NS: Первое — согласен, это чисто Postgres’овая история. Думаю, если у нас есть какой-нибудь direct IO и буферный пул почти под всю память, такой подход не подойдет — планы будут другие. Но мы пока только с Postgres’ом и работаем, про других не думаем.
Rreth Kubernetes. Ti vetë e ndan gjithandej se ne kemi një bazë persistente. Nëse instanca bie, e rëndësishme është të ruash diskun. Pra, e gjithë platforma jonë është gjithashtu në Kubernetes, ndërsa komponenti me Postgres — ndaras (edhe pse një ditë do të jetë atje). Pra, gjithçka është kështu: instanca ra, por ne e ruajmë PV-në e saj dhe thjesht e lidhim me një instancë tjetër (të re), siç nuk ndodhi asgjë.
DS: С моей точки зрения, мы создаём pod’ы в Kubernetes. K8s — эластичный: узлы заказываются сами по мере необходимости. Задача — просто создать pod и сказать, что ему нужно X ресурсов, а дальше K8s сам разберётся. Но поддержка хранилищ в Kubernetes по-прежнему нестабильна: в , në (kjo lëshim doli javë më parë) këto karakteristika bëhen vetëm beta.
Пройдет полгода-год — оно станет более-менее стабильным, или хотя бы будет заявлено таковым. Тогда возможность снапшотов и resize’а уже решает вашу задачу полностью. Потому что у вас есть база. Да, она может быть не очень быстрой, но скорость зависит от того, что «под капотом», потому что некоторые реализации умеют копирование и copy-on-write на уровне дисковой подсистемы.
NS: Këtu duhet gjithashtu që të gjitha motorët (Amazon, Google…) të fillojnë të mbështesin këtë version — kjo gjithashtu merr pak kohë.
DS: Deri tani ne nuk i përdorim. Ne përdorim tonat.
Zhvillimi lokal nën Kubernetes
NS: Сталкивался ли ты с такой хотелкой, когда нужно на одной машине поднять все pod’ы и сделать такое маленькое тестирование. Чтобы по-быстрому получить proof of concept, посмотреть, что приложение работает в Kubernetes, не выделяя под это кучу машин. Есть Minikube, да?
DS: Më duket se ky rast — të vendosësh në një nyje — është për zhvillimin lokal ekskluzivisht. Ose ndonjë shfaqje e këtij modeli. Ka , ka , . Ne po shkojmë drejt përdorimit të Kubernetes IN Docker. Tani kemi filluar të punojmë me të për teste.
NS: Я раньше думал, что это попытка завернуть все pod’ы в один Docker-образ. Но оказалось, что это совсем о другом. Всё равно там отдельные контейнеры, отдельные pod’ы — просто в Docker’е.
DS: Po. Dhe aty është bërë një imitim mjaft argëtues, por kuptimi është se... Kemi një utilitar për deploy — . Duam ta bëjmë një modalitet — ndryshe werf up: 'Ngri mu Kubernetes lokal'. Dhe më pas të nisë atje një werf follow. Atëherë zhvilluesi mund të redaktojë në IDE, ndërsa në sistem është në funksion një proces që sheh ndryshimet dhe rindërton imazhet, duke i ri-diplouar ato në K8s lokale. Kështu duam të përpiqemi të zgjidhim problemin e zhvillimit lokal.
Snapshot-et dhe klonimi i DB në realitetin e K8s
NS: Если вернуться к copy-on-write. Я заметил, что у облаков тоже есть снапшоты. Они работают по-разному. Например, в GCP: у тебя на восточном побережье США есть многотерабайтный инстанс. Делаешь периодически снапшоты. Поднимаешь из снапшота копию диска на западном побережье — через несколько минут уже всё готово, работает очень быстро, только кэш надо заполнить в памяти. Но эти клоны (снапшоты) — для того, чтобы за’provision’ить новый том. Это круто, когда нужно много инстансов создать.
А вот для тестов, мне кажется, снапшоты, про которые ты рассказываешь в Docker’е или я рассказываю в ZFS, btrfs и даже LVM… — они позволяют как раз на одной машине не делать реально новые данные. В облаке ты ещё платить за них каждый раз будешь и ждать уже не секунды, а минуты (а в случае , ndoshta, edhe orë).
Në vend të kësaj, mund të marrësh këto të dhëna për një deri në dy sekonda, të realizosh testin dhe ta heqësh. Këto snapshot-e zgjidhin detyra të ndryshme. Në rastin e parë — për të shkallëzuar dhe për të marrë replika të reja, ndërsa në të dytin — për teste.
DS: Nuk do të pajtohem. Të bësh një klonim normal të volumeve — kjo është një detyrë e cloud. Nuk e kam parë implementimin e tyre, por e di si e bëjmë ne në harduer. Ne kemi Ceph, në të cilin mund t’i themi çdo volumi fizik () dhe të marrim në disa milisekonda një volum të dytë me karakteristika të njëjta, clone IOPS ‘ами и т.п. Надо понимать, что там внутри хитрый copy-on-write. Почему облаку не делать так же? Уверен, что они так или иначе стараются это сделать.
NS: Por shumë kohë, minuta dhe një pjesë tjetër do të merren për të ngritur instancën, për të futur Docker, etj.
DS: Pse është e nevojshme të ngritni një instancë të plotë? Ne kemi një instancë me 32 bërthama, një me 16… dhe në të futet një numër i caktuar — për shembull, katër. Kur të porositim të pestin, do të ngrihet një instancë, dhe më pas do të fshihet.
NS: Po, është interesante. Në Kubernetes ndodh një histori tjetër. Ne nuk e kemi DB-në në K8s, dhe kemi një instancë. Por, për sa i përket klonimit të një baze të dhënash me shumë terabajt, nuk merr më shumë se dy sekonda.
DS: Kjo është fantastike. Por qëllimi im fillestar është se kjo nuk është një zgjidhje generike. Po, është e shkëlqyer, por funksionon vetëm për Postgres dhe vetëm në një nyjë.
NS: Nuk është vetëm për Postgres: këto plane, siç e përshkrova, do të funksionojnë vetëm në të. Por nëse nuk merremi me planet, dhe na duhen thjesht të dhënat për testim funksional, atëherë kjo do të funksionojë për çdo DB.
DS: Para shumë vitesh, ne bëmë diçka të ngjashme me snapshotet LVM. Kjo është klasike. Ky qasje është përdorur shumë. Vetëm node-t me shtet janë të dhimbshme. Sepse nuk duhet t'i lësh, duhet gjithmonë të kujdesesh për to...
NS: A nuk sheh ndonjë mundësi hibridi këtu? Supozoni, shtetful — është një pod, funksionon për disa njerëz (shumë testues). Të dhënat tona janë një, por falë sistemit të skedave klonët janë lokalë. Nëse pod bie, disku mbetet — podi do të ngrihet, do të lexojë informacionin për të gjithë klonët, gjithçka do të ngjitet përsëri dhe do të thotë: 'Këtu janë klonët tuaj në këto porte, vazhdoni të punoni me ta'.
DS: Teknikisht, kjo do të thotë se brenda Kubernetes është një pod, brenda të cilit ne aktivizojmë shumë Postgres.
NS: Po. Ai ka një kufi: për shembull, nuk punojnë më shumë se 10 persona me të. Nëse duhen 20 — do të aktivizojmë një pod të dytë të tillë. Është krejtësisht e mundur ta klonosh, duke marrë një vëllim të dytë, ku do të ketë 10 'klonë të hollë' të tillë. A nuk e sheh atë mundësi?
DS: Duhet të shtoj këtu çështjet e sigurisë. Ky variant organizimi nënkupton që ky pod ka privilegje të larta (capabilities), sepse ai mund të kryejë operacione jo standarde mbi sistemin e skedarëve... Por po e përsëris: mendoj se në një afat mesatar, Kubernetes do të rregullojë ruajtjen, në re do të rregullojnë të gjithë historinë me volumin - gjithçka do të funksionojë 'në mënyrë të thjeshtë'. Do të ketë resize, klonim... Ka një volum — ne themi: 'Krijo një të ri në bazë të atij', dhe pas një sekonde e gjysmë ne marrim atë që na nevojitet.
NS: Nuk besoj në një sekondë e gjysmë për shumë terabajt. Në Ceph e bën vetë, dhe po flet për re. Shko në re, bëj një klon të volumit EBS të shumë terabajt dhe shiko se çfarë performance do të ketë. Kjo nuk do të marrë disa sekonda. Më intereson shumë të di se kur do të arrijnë një tregues të tillë. E kuptoj çfarë thua, por do ta lejoj veten të mos pajtohem.
DS: Ok, por thashë se në një afat mesatar, jo afatshkurtër. Brenda disa viteve.
Për operatorin për PostgreSQL nga Zalando
Në mes të kësaj takimi, u bashkua gjithashtu Alexey Klyukin, një ish-zhvillues nga kompania Zalando, i cili tregoi historinë e operatorit PostgreSQL:
Është shumë mirë që kjo temë është përmendur: si Postgres, ashtu edhe Kubernetes. Kur ne filluam ta bëjmë atë në Zalando në vitin 2017, kjo ishte një temë që të gjithë donin të merreshin me të, por askush nuk e bënte. Të gjithë kishin filluar të merrnin Kubernetes, por kur pyeteshin se si duhej përballemi me bazat e të dhënave, madje edhe njerëz si , predikuan K8s, thoshin diçka të tillë:
‘Shkoni në shërbime të menaxhuara dhe përdorni ato, mos zhvilloni DB në Kubernetes. Ndryshe, K8s juaj do të vendosë, për shembull, të bëjë një përmirësim, do t'i fikë të gjitha nyjat dhe të dhënat tuaja do të fluturojnë shumë larg.’
Ne vendosëm të bëjmë një operator që, përkundër këtij këshilli, do të aktivizonte DB Postgres në Kubernetes. Dhe ne kishim një bazë të fortë — . Ky është një automatik përfail për PostgreSQL, i bërë siç duhet, dmth., me përdorimin e etcd, consul ose ZooKeeper si një magazinë informacioni rreth klustrit. Një magazinë të tillë, e cila do të jepte të gjithëve që pyesnin, për shembull, cili është lideri aktual, të njëjtin informacion — pavarësisht se gjithçka është e shpërndarë — që të mos ketë ndarje mendore. Përveç kësaj, ne kishim për të.
Në të vërtetë, nevoja për përfail automatik iu paraqit kompanisë pas migrimit nga data-qendra e brendshme në cloud. Cloud ishte themeluar në një zgjidhje PaaS (Platform-as-a-Service) të brendshme. Ishte Open Source, por për ta ngritur duhej punuar shumë. E quajtur .
Fillimisht, nuk kishte Kubernetes. Saktësisht, kur u zhvillua zgjidhja e brendshme, K8s tashmë ekzistonte, por ishte aq i paqëndrueshëm, sa për prodhim nuk ishte i përshtatshëm. Më kujtohet, ishte vitin 2015 ose 2016. Në vitin 2017 Kubernetes u bë mjaft i pjekur — ndjekja për migrim aty ishte e domosdoshme.
Kemi patë një kontenier Docker. Kishim një PaaS që përdorte Docker. Pse të mos provojmë K8s? Pse të mos shkruajmë operatorin tonë? Murat Kabilov, që erdhi te ne nga Avito, e nisi këtë si një projekt me iniciativë të tijën — "të lojë", — dhe projekti "tradhtoi".
Por në të vërtetë doja të flisja për AWS. Pse kishte historikisht kod që lidhej me AWS…
Kur filloni ndonjë gjë në Kubernetes, duhet të kuptoni se K8s është një punë në vazhdim. Ai zhvillohet vazhdimisht, përmirësohet dhe herë pas here madje dështojnë. Duhet të jeni të vëmendshëm ndaj të gjitha ndryshimeve në Kubernetes, duhet të jeni të gatshëm që në rast nevoje të zhyteni brenda tij dhe të mësoni si funksionon në detaje — ndoshta më shumë se sa dëshironit. Kjo ndodh, në thelb, me çdo platformë mbi të cilën zhvilloni bazat e të dhënave tuaj…
Pra, kur po bënim operatorin, kishim Postgres që punonte me një vëllim të jashtëm (në këtë rast — EBS, duke pasur parasysh se ishim në AWS). Baza e të dhënave u rrit, dhe në një moment na duhej të bëjmë resizing: për shembull, madhësia fillestare e EBS ishte 100 Tb, baza e të dhënave e arriti atë madhësi, tani duam të bëjmë EBS 200 Tb. Si? Supozoni se mund të bëni dump/restore në një instancë të re, por kjo merr shumë kohë dhe shkakton ndalesa.
Prandaj dëshironim një resize që do të rrisë pjesën e EBS-së dhe më pas do t’i thoshte sistemit të skedarëve të përdorë hapësirën e re. E bëmë këtë, por në atë kohë Kubernetes nuk kishte asnjë API për operacionin e resize. Duke qenë se punonim në AWS, shkruam kod për API-në e tij.
Askush nuk e ndalon të bëjë të njëjtën gjë për platformat e tjera. Në operator nuk ka një varësi që mund të niset vetëm në AWS, dhe në çdo platformë tjetër nuk do të funksionojë. Në përgjithësi, ky është një projekt Open Source: nëse dikush dëshiron të nxitojë shfaqjen e një API të ri — është i mirëpritur. Ka , kërkesa pull — ekipi i Zalando mundohet të reagojë mjaft shpejt ndaj tyre dhe të promovojë operatorin. Sipas asaj që di, projekti në Google Summer of Code dhe në disa iniciativa të tjera të ngjashme. Zalando është shumë aktiv në këtë.
P.S. Bonus!
Nëse jeni të interesuar për temën e PostgreSQL dhe Kubernetes, atëherë gjithashtu vini re se javën e kaluar u mbajt Postgres-i i radhës, ku Nikolai u komunikua me Aleksandër Kukushkin nga Zalando. Video nga ai është e disponueshme .
P.P.S.
Lexoni gjithashtu në blogun tonë:
- «»;
- «»;
- «»;
- «».
Burimi: habr.com
