ProHoster > Blogs > Administrācija > Postgres otrdiena Nr. 5: ā€œPostgreSQL un Kubernetes. CI/CD. Testa automatizācija"

Postgres otrdiena Nr. 5: ā€œPostgreSQL un Kubernetes. CI/CD. Testa automatizācija"

Postgres otrdiena Nr. 5: ā€œPostgreSQL un Kubernetes. CI/CD. Testa automatizācija"

PagājuŔā gada nogalē notika vēl viena Krievijas PostgreSQL kopienas tieÅ”raide #RuPostgres, kuras laikā tās lÄ«dzdibinātājs Nikolajs Samohvalovs runāja ar Flant tehnisko direktoru Dmitriju Stoļarovu par Å”o DBVS Kubernetes kontekstā.

Publicējam Ŕīs diskusijas galvenās daļas atÅ”ifrējumu, un plkst Kopienas YouTube kanāls Pilns video ievietots:

Datu bāzes un Kubernetes

NS: Mēs Å”odien nerunāsim par VAKUUMU un PĀRBAUDES PUNKTIEM. Mēs vēlamies runāt par Kubernetes. Es zinu, ka jums ir daudzu gadu pieredze. Es noskatÄ«jos jÅ«su videoklipus un pat noskatÄ«jos dažus no tiem atkārtoti... Sāksim uzreiz pie lietas: kāpēc Postgres vai MySQL vispār K8s?

DS: Uz Å”o jautājumu nav un nevar bÅ«t konkrētas atbildes. Bet kopumā tā ir vienkārŔība un ērtÄ«bas... potenciāls. Ikviens vēlas pārvaldÄ«tus pakalpojumus.

NS: Kā RDS, tikai mājās?

DS: Jā: tāpat kā RDS, jebkurā vietā.

NS: ā€œJebkurā€ ir labs punkts. Lielajos uzņēmumos viss atrodas dažādās vietās. Kāpēc tad, ja tas ir liels uzņēmums, neņemt gatavu risinājumu? Piemēram, Nutanix ir savas izstrādes, citiem uzņēmumiem (VMware...) ir tas pats ā€œRDS, tikai mājāsā€.

DS: Bet mēs runājam par atseviŔķu ievieÅ”anu, kas darbosies tikai noteiktos apstākļos. Un, ja mēs runājam par Kubernetes, tad tur ir ļoti daudz dažādu infrastruktÅ«ru (kas var bÅ«t K8s). BÅ«tÄ«bā Å”is ir mākoņa API standarts...

NS: Tas ir arī bez maksas!

DS: Tas nav tik svarÄ«gi. BrÄ«vÄ«ba ir svarÄ«ga ne pārāk lielam tirgus segmentam. SvarÄ«gs ir kas cits... JÅ«s droÅ”i vien atceraties ziņojumu ā€œDatu bāzes un Kubernetes"?

NS: Jā.

DS: Sapratu, ka tas tika uztverts ļoti neviennozÄ«mÄ«gi. Dažiem likās, ka es saku: "PuiÅ”i, ielaidÄ«sim visas datubāzes Kubernetes!", bet citi uzskatÄ«ja, ka tie visi ir briesmÄ«gi velosipēdi. Bet man gribējās teikt pavisam ko citu: ā€œPaskatieties, kas notiek, kādas ir problēmas un kā tās var atrisināt. Vai mums tagad vajadzētu izmantot Kubernetes datu bāzes? RažoÅ”ana? Nu, tikai tad, ja jums patÄ«k... darÄ«t noteiktas lietas. Bet izstrādātājam varu teikt, ka iesaku. Izstrādātājiem vides izveides/dzÄ“Å”anas dinamisms ir ļoti svarÄ«gs.

NS: Vai ar izstrādātāju jÅ«s domājat visas vides, kas nav ražotas? Iestudējums, kvalitātes nodroÅ”ināŔanaā€¦

DS: Ja mēs runājam par perf stendiem, tad droÅ”i vien nē, jo prasÄ«bas tur ir specifiskas. Ja mēs runājam par Ä«paÅ”iem gadÄ«jumiem, kad inscenÄ“Å”anai nepiecieÅ”ama ļoti liela datu bāze, tad droÅ”i vien nē... Ja Ŕī ir statiska, ilgstoÅ”a vide, tad kāds labums no tā, ka datubāze atrodas K8s?

NS: Nav. Bet kur mēs redzam statisku vidi? Rīt statiska vide kļūs novecojusi.

DS: Iestudējums var būt statisks. Mums ir klienti...

NS: Jā, man arī tāds ir. Tā ir liela problēma, ja jums ir 10 TB datu bāze un 200 GB inscenējums...

DS: Man ir ļoti forÅ”s gadÄ«jums! UzstādÄ«Å”anas laikā ir produktu datu bāze, kurā tiek veiktas izmaiņas. Un ir poga: ā€œizrullēt uz ražoÅ”anuā€. Å Ä«s izmaiņas - deltas - tiek pievienotas (Ŕķiet, ka tās ir vienkārÅ”i sinhronizētas, izmantojot API) ražoÅ”anā. Å Ä« ir ļoti eksotiska iespēja.

NS: Esmu redzējis jaunuzņēmumus Valley, kas darbojas RDS vai pat Heroku ā€” tie ir stāsti pirms 2ā€“3 gadiem ā€” un viņi lejupielādē izgāztuvi savā klēpjdatorā. Jo datubāze joprojām ir tikai 80 GB, un klēpjdatorā ir vieta. Tad viņi iegādājas papildu diskus katram, lai viņiem bÅ«tu 3 datu bāzes, lai veiktu dažādas izstrādes. Tā tas arÄ« notiek. Es arÄ« redzēju, ka viņi nebaidās kopēt prod iestudējumā - tas ir ļoti atkarÄ«gs no uzņēmuma. Bet es arÄ« redzēju, ka viņi ļoti baidās, un viņiem bieži vien nepietiek laika un roku. Bet, pirms mēs pārejam pie Ŕīs tēmas, es vēlos dzirdēt par Kubernetes. Vai es pareizi saprotu, ka neviens vēl nav prod?

DS: Mums ir nelielas datu bāzes ražoÅ”anā. Mēs runājam par desmitiem gigabaitu apjomiem un nekritiskiem pakalpojumiem, kuriem mēs bijām pārāk slinki, lai izveidotu kopijas (un tādas vajadzÄ«bas nav). Un ar nosacÄ«jumu, ka zem Kubernetes ir normāla krātuve. Å Ä« datu bāze darbojās virtuālajā maŔīnā - nosacÄ«ti VMware, virs atmiņas sistēmas. Mēs to ievietojām PV un tagad mēs varam to pārsÅ«tÄ«t no maŔīnas uz maŔīnu.

NS: Šāda izmēra datu bāzes, lÄ«dz 100 GB, var izvilkt dažu minÅ«Å”u laikā labos diskos un labā tÄ«klā, vai ne? Ātrums 1 GB sekundē vairs nav eksotisks.

DS: Jā, lineārai darbībai tā nav problēma.

NS: Labi, mums tikai jādomā par prod. Un, ja mēs apsveram Kubernetes izmantoÅ”anu vidēm, kas nav ražotas, kas mums jādara? Es to redzu Zalando darÄ«t operatoru, in Crunchy zāģēŔana, ir vēl dažas iespējas. Un ir OnGres - tas ir mÅ«su labs draugs Alvaro no Spānijas: tas, ko viņi dara, bÅ«tÄ«bā nav tikai operators, un viss sadalÄ«jums (StackGres), kurā bez paÅ”a Postgres nolēma iebāzt arÄ« rezerves kopiju, Envoy proxy...

DS: Sūtni par ko? Vai īpaŔi līdzsvarot Postgres trafiku?

NS: Jā. Tas ir, viņi to uztver Ŕādi: ja izmantojat Linux izplatÄ«Å”anu un kodolu, tad parastais PostgreSQL ir kodols, un viņi vēlas izveidot izplatÄ«Å”anu, kas bÅ«s draudzÄ«ga mākoņiem un darbosies Kubernetes. Viņi saliek komponentus (dublējumus utt.) un atkļūdo, lai tie darbotos labi.

DS: Ļoti forŔs! Būtībā Ŕī ir programmatūra, lai izveidotu savu pārvaldīto Postgres.

NS: Linux distribÅ«cijām ir mūžīgas problēmas: kā izveidot draiverus, lai tiktu atbalstÄ«ta visa aparatÅ«ra. Un viņiem ir doma, ka viņi strādās Kubernetes. Es zinu, ka Zalando operatorā mēs nesen redzējām savienojumu ar AWS, un tas vairs nav pārāk labs. Nevajadzētu bÅ«t saistÄ«tai ar konkrētu infrastruktÅ«ru ā€” kāda tad jēga?

DS: Es precÄ«zi nezinu, kādā situācijā Zalando nokļuva, bet Kubernetes krātuve tagad ir izveidota tā, ka nav iespējams veikt diska dublējumu, izmantojot vispārÄ«gu metodi. Nesen standarta - jaunākajā versijā CSI specifikācijas ā€” mēs padarÄ«jām iespējamus momentuzņēmumus, bet kur tas tiek Ä«stenots? GodÄ«gi sakot, viss vēl ir tik neapstrādāts... Mēģinām CSI virsÅ« AWS, GCE, Azure, vSphere, bet tiklÄ«dz sāc lietot, var redzēt, ka tas vēl nav gatavs.

NS: Tāpēc mums dažreiz ir jāpaļaujas uz infrastruktÅ«ru. Es domāju, ka tas vēl ir sākuma posms - augÅ”anas sāpes. Jautājums: Kādu padomu jÅ«s sniegtu iesācējiem, kuri vēlas izmēģināt PgSQL K8s? Kāds operators varbÅ«t?

DS: Problēma ir tāda, ka Postgres mums ir 3%. Mums ir arÄ« ļoti liels dažādu programmatÅ«ru saraksts Kubernetes, es pat neuzskaitÄ«Å”u visu. Piemēram, Elasticsearch. Operatoru ir daudz: daži aktÄ«vi attÄ«stās, citi ne. Esam sev izstrādājuÅ”i prasÄ«bas, kam jābÅ«t operatoram, lai mēs to uztvertu nopietni. Operatorā speciāli Kubernetes - nevis "operatorā, lai kaut ko darÄ«tu Amazones apstākļos"... PatiesÄ«bā mēs diezgan plaÅ”i (= gandrÄ«z visi klienti) izmantojam vienu operatoru - par Redisu (drÄ«zumā publicēsim rakstu par viņu).

NS: Un arī ne MySQL? Es zinu, ka Percona... tā kā viņi tagad strādā pie MySQL, MongoDB un Postgres, viņiem būs jāizveido kaut kāds universāls risinājums: visām datu bāzēm, visiem mākoņa pakalpojumu sniedzējiem.

DS: Mums nebija laika apskatÄ«t MySQL operatorus. Å obrÄ«d tas nav mÅ«su galvenais uzsvars. MySQL darbojas labi atseviŔķi. Kāpēc izmantot operatoru, ja var vienkārÅ”i palaist datu bāzi... Varat palaist Docker konteineru ar Postrges, vai arÄ« varat to palaist vienkārŔā veidā.

NS: Par Ŕo arī bija jautājums. Nav operatora vispār?

DS: Jā, 100% no mums PostgreSQL darbojas bez operatora. LÄ«dz Å”im tā. Mēs aktÄ«vi izmantojam operatoru Prometheus un Redis. Esam plānojuÅ”i atrast Elasticsearch operatoru - tas ir visvairāk ā€œugunsā€, jo 100% gadÄ«jumu vēlamies to uzstādÄ«t Kubernetes. Tāpat kā mēs vēlamies nodroÅ”ināt, ka MongoDB vienmēr tiek instalēts arÄ« Kubernetes. Te parādās zināmas vēlmes ā€“ ir sajÅ«ta, ka Å”ajos gadÄ«jumos kaut ko var izdarÄ«t. Un mēs pat nepaskatÄ«jāmies uz Postgresu. Protams, mēs zinām, ka ir dažādas iespējas, bet patiesÄ«bā mums ir savrupa.

DB pārbaudei Kubernetes

NS: Pāriesim pie tēmas par testÄ“Å”anu. Kā ieviest izmaiņas datu bāzē ā€” no DevOps viedokļa. Ir mikropakalpojumi, daudzas datu bāzes, visu laiku kaut kas mainās. Kā nodroÅ”ināt normālu CI/CD, lai no DBVS viedokļa viss bÅ«tu kārtÄ«bā. Kāda ir jÅ«su pieeja?

DS: Viena atbilde nevar bÅ«t. Ir vairākas iespējas. Pirmais ir pamatnes izmērs, kuru vēlamies izrullēt. JÅ«s pats minējāt, ka uzņēmumiem ir atŔķirÄ«ga attieksme pret prod datu bāzes kopiju izstrādē un stadijā.

NS: Un GDPR apstākļos, manuprāt, viņi ir arvien uzmanÄ«gāki... Varu teikt, ka Eiropā jau ir sākuÅ”i uzlikt sodus.

DS: Bet bieži vien jÅ«s varat rakstÄ«t programmatÅ«ru, kas paņem izgāztuvi no ražoÅ”anas un aptumÅ”o to. Prod dati tiek iegÅ«ti (momentuzņēmums, dump, binārā kopija...), taču tie ir anonimizēti. Tā vietā var bÅ«t Ä£enerÄ“Å”anas skripti: tie var bÅ«t fiksatori vai vienkārÅ”i skripti, kas Ä£enerē lielu datu bāzi. Problēma ir: cik ilgs laiks nepiecieÅ”ams, lai izveidotu pamata attēlu? Un cik ilgs laiks nepiecieÅ”ams, lai to izvietotu vēlamajā vidē?

Mēs nonācām pie shēmas: ja klientam ir fiksēta datu kopa (minimālā datu bāzes versija), tad mēs tos izmantojam pēc noklusējuma. Ja mēs runājam par pārskatÄ«Å”anas vidēm, izveidojot filiāli, mēs izvietojām lietojumprogrammas instanci - mēs tur izlaižam nelielu datu bāzi. Bet sanāca labi iespēja, kad mēs reizi dienā (naktÄ«) paņemam izgāztuvi no ražoÅ”anas un izveidojam Docker konteineru ar PostgreSQL un MySQL, pamatojoties uz Å”iem ielādētajiem datiem. Ja jums ir nepiecieÅ”ams paplaÅ”ināt datu bāzi 50 reizes no Ŕī attēla, tas tiek darÄ«ts diezgan vienkārÅ”i un ātri.

NS: ar vienkārÅ”u kopÄ“Å”anu?

DS: dati tiek glabāti tieÅ”i Docker attēlā. Tie. Mums ir gatavs attēls, lai gan 100 GB. Pateicoties Docker slāņiem, mēs varam ātri izvietot Å”o attēlu tik reižu, cik nepiecieÅ”ams. Metode ir muļķīga, bet tā darbojas labi.

NS: Tad, pārbaudot, tas mainās tieÅ”i Docker iekÅ”ienē, vai ne? KopÄ“Å”ana-uzrakstÄ«Å”ana iekŔā Docker - izmet un ej vēlreiz, viss kārtÄ«bā. Klase! Un vai jÅ«s to jau izmantojat pilnÄ«bā?

DS: Ilgu laiku.

NS: Mēs darām ļoti līdzīgas lietas. Tikai mēs neizmantojam Docker's copy-on-write, bet gan kādu citu.

DS: Tas nav vispārīgs. Un Docker darbojas visur.

NS: Teorētiski jā. Bet mums tur ir arÄ« moduļi, jÅ«s varat izgatavot dažādus moduļus un strādāt ar dažādām failu sistēmām. Kāds te brÄ«dis. No Postgres puses mēs uz to visu skatāmies savādāk. Tagad es paskatÄ«jos no Docker puses un redzēju, ka viss darbojas jÅ«su labā. Bet, ja datu bāze ir milzÄ«ga, piemēram, 1 TB, tad tas viss aizņem ilgu laiku: operācijas naktÄ«, un visu sabāzÅ”ana Docker... Un ja 5 TB iebāza Docker... Vai arÄ« viss ir kārtÄ«bā?

DS: Kāda ir atŔķirība: tie ir lāses, tikai biti un baiti.

NS: AtŔķirība ir Ŕāda: vai jūs to darāt, izmantojot izgāztuvi un atjaunoŔanu?

DS: Nemaz nav nepiecieÅ”ams. Å Ä« attēla Ä£enerÄ“Å”anas metodes var bÅ«t dažādas.

NS: Dažiem klientiem esam izveidojuÅ”i tā, ka tā vietā, lai regulāri Ä£enerētu bāzes attēlu, mēs to pastāvÄ«gi atjauninām. Tā bÅ«tÄ«bā ir kopija, taču tā saņem datus nevis tieÅ”i no galvenā, bet gan caur arhÄ«vu. Binārais arhÄ«vs, kurā katru dienu tiek lejupielādēti WAL, kur tiek veidotas dublējumkopijas... Pēc tam Å”ie WAL ar nelielu kavÄ“Å”anos (burtiski 1-2 sekundes) sasniedz bāzes attēlu. Mēs no tā klonējam jebkurā veidā - tagad mums pēc noklusējuma ir ZFS.

DS: Bet ar ZFS jūs aprobežojaties ar vienu mezglu.

NS: Jā. Bet ZFS ir arÄ« maÄ£isks sÅ«tÄ«t: ar to jÅ«s varat nosÅ«tÄ«t momentuzņēmumu un pat (es vēl neesmu Ä«sti pārbaudÄ«jis, bet...) jÅ«s varat nosÅ«tÄ«t delta starp diviem PGDATA. PatiesÄ«bā mums ir vēl viens rÄ«ks, ko mēs neesam Ä«sti apsvēruÅ”i Ŕādiem uzdevumiem. PostgreSQL ir pg_rewind, kas darbojas kā ā€œviedaisā€ rsync, izlaižot daudz no tā, kas nav jāskatās, jo tur nekas nav mainÄ«jies. Mēs varam veikt ātru sinhronizāciju starp diviem serveriem un attÄ«t atpakaļ tādā paŔā veidā.

Tātad, no Ŕīs, vairāk DBA puses, mēs cenÅ”amies izveidot rÄ«ku, kas ļauj mums darÄ«t to paÅ”u, ko jÅ«s teicāt: mums ir viena datu bāze, bet mēs vēlamies kaut ko pārbaudÄ«t 50 reizes, gandrÄ«z vienlaikus.

DS: 50 reizes nozīmē, ka jums ir jāpasūta 50 Spot gadījumi.

NS: Nē, mēs visu darām ar vienu maŔīnu.

DS: Bet kā jÅ«s paplaÅ”ināsiet 50 reizes, ja Ŕī viena datubāze ir, teiksim, terabaits. Visticamāk, viņai vajag nosacÄ«tu 256 GB RAM?

NS: Jā, dažreiz jums ir nepiecieÅ”ams daudz atmiņas - tas ir normāli. Bet tas ir piemērs no dzÄ«ves. RažoÅ”anas iekārtai ir 96 kodoli un 600 GB. Tajā paŔā laikā datubāzei tiek izmantoti 32 kodoli (pat 16 kodoli tagad dažreiz) un 100-120 GB atmiņa.

DS: Un 50 eksemplāri tur iederas?

NS: Tātad ir tikai viens eksemplārs, tad copy-on-write (ZFS) darbi... PastāstīŔu sīkāk.

Piemēram, mums ir 10 TB datu bāze. UztaisÄ«ja tam disku, ZFS arÄ« saspieda tā izmēru par 30-40 procentiem. Tā kā mēs neveicam slodzes testÄ“Å”anu, precÄ«zs reakcijas laiks mums nav svarÄ«gs: ļaujiet tam bÅ«t lÄ«dz 2 reizēm lēnāk - tas ir labi.

Mēs dodam iespēju programmētājiem, QA, DBA u.c. veikt testÄ“Å”anu 1-2 pavedienos. Piemēram, viņi var veikt sava veida migrāciju. Tam nav nepiecieÅ”ami 10 kodoli vienlaikus - tam ir nepiecieÅ”ams 1 Postgres aizmugursistēma, 1 kodols. Sāksies migrācija ā€“ varbÅ«t autovakuums joprojām sāksies, tad tiks izmantots otrais kodols. Mums ir atvēlēti 16-32 kodoli, tātad 10 cilvēki var strādāt vienlaicÄ«gi, bez problēmām.

Jo fiziski PGDATA tas pats, izrādās, ka mēs patiesÄ«bā maldinām Postgresu. ViltÄ«ba ir Ŕāda: piemēram, vienlaikus tiek palaistas 10 Postgres. Kāda parasti ir problēma? Viņi liek share_buffers, pieņemsim, ka 25%. AttiecÄ«gi tas ir 200 GB. JÅ«s nevarēsit palaist vairāk kā trÄ«s no tiem, jo ā€‹ā€‹beigsies atmiņa.

Bet kādā brÄ«dÄ« mēs sapratām, ka tas nav nepiecieÅ”ams: mēs iestatÄ«jām share_buffers uz 2 GB. PostgreSQL ir efektÄ«vas_keÅ”atmiņas_izmērs, un patiesÄ«bā tas ir vienÄ«gais, kas ietekmē plāniem. Mēs iestatÄ«jām to uz 0,5 TB. Un tas pat nav svarÄ«gi, ka tie patiesÄ«bā neeksistē: viņŔ plāno plānus tā, it kā tie pastāvētu.

AttiecÄ«gi, kad mēs pārbaudām kaut kādu migrāciju, mēs varam savākt visus plānus - mēs redzēsim, kā tas notiks ražoÅ”anā. Sekundes tur bÅ«s dažādas (lēnākas), bet dati, kurus mēs faktiski nolasām, un paÅ”i plāni (kādi tur ir JOIN utt.) izrādās tieÅ”i tādi paÅ”i kā ražoÅ”anā. Un jÅ«s varat veikt daudzas Ŕādas pārbaudes paralēli vienā maŔīnā.

DS: Vai jums neŔķiet, ka Å”eit ir dažas problēmas? Pirmais ir risinājums, kas darbojas tikai uz PostgreSQL. Å Ä« pieeja ir ļoti privāta, tā nav vispārÄ«ga. Otrais ir tas, ka Kubernetes (un viss, ko tagad izmanto mākoņtehnoloÄ£ijas) ietver daudzus mezglus, un Å”ie mezgli ir Ä«slaicÄ«gi. Un jÅ«su gadÄ«jumā tas ir stāvoÅ”s, pastāvÄ«gs mezgls. Å Ä«s lietas man rada pretrunas.

NS: Pirmkārt, es piekrÄ«tu, Å”is ir tikai Postgres stāsts. Es domāju, ka, ja mums ir kaut kāds tieÅ”ais IO un bufera baseins gandrÄ«z visai atmiņai, Ŕī pieeja nedarbosies - plāni bÅ«s atŔķirÄ«gi. Bet pagaidām strādājam tikai ar Postgres, par citiem nedomājam.

Par Kubernetes. JÅ«s pats mums visur sakāt, ka mums ir pastāvÄ«ga datubāze. Ja gadÄ«jums neizdodas, galvenais ir saglabāt disku. Å eit mums ir arÄ« visa platforma Kubernetes, un komponents ar Postgres ir atseviŔķs (lai gan kādu dienu tas tur bÅ«s). Tāpēc viss ir tā: instance nokrita, bet mēs saglabājām tās PV un vienkārÅ”i pieslēdzām citai (jaunai) instancei, it kā nekas nebÅ«tu noticis.

DS: No mana viedokļa, mēs veidojam pākstis Kubernetes. K8s - elastÄ«gs: mezgli tiek pasÅ«tÄ«ti pēc nepiecieÅ”amÄ«bas. Uzdevums ir vienkārÅ”i izveidot podziņu un pateikt, ka tam vajag X resursu daudzumu, un tad K8s to izdomās pats. Bet Kubernetes krātuves atbalsts joprojām ir nestabils: 1.16Uz 1.17 (Å”is izdevums tika izlaists Nedēļas pirms) Ŕīs funkcijas kļūst tikai par beta versiju.

Paies seÅ”i mēneÅ”i lÄ«dz gads - tas kļūs vairāk vai mazāk stabils vai vismaz par tādu tiks deklarēts. Tad momentuzņēmumu un izmēru maiņas iespēja pilnÄ«bā atrisina jÅ«su problēmu. Jo jums ir bāze. Jā, tas var nebÅ«t ļoti ātrs, bet ātrums ir atkarÄ«gs no tā, kas atrodas ā€œzem pārsegaā€, jo dažas implementācijas var kopēt un kopēt uz rakstÄ«Å”anas diska apakÅ”sistēmas lÄ«menÄ«.

NS: Ir arÄ« nepiecieÅ”ams, lai visi dzinēji (Amazon, Google...) sāktu atbalstÄ«t Å”o versiju - tas arÄ« aizņem kādu laiku.

DS: Mēs tos vēl neizmantojam. Mēs izmantojam savējo.

Vietējā attīstība Kubernetes

NS: Vai esat kādreiz saskāruÅ”ies ar Ŕādu vēlmi, kad jums ir jāuzstāda visi podi vienā maŔīnā un jāveic tik mazs tests. Lai ātri iegÅ«tu koncepcijas pierādÄ«jumu, pārbaudiet, vai lietojumprogramma darbojas Kubernetes, nevelkot tai virkni maŔīnu. Tur ir Minikube, vai ne?

DS: Man Ŕķiet, ka Ŕī lieta, kas izvietota vienā mezglā, ir saistÄ«ta tikai ar vietējo attÄ«stÄ«bu. Vai dažas Ŕāda modeļa izpausmes. Ēst Minikube, Tur ir k3, KIND. Mēs virzāmies uz Kubernetes IN Docker izmantoÅ”anu. Tagad mēs sākām strādāt ar to testu veikÅ”anai.

NS: Agrāk domāju, ka tas ir mēģinājums ietÄ«t visus pākstis vienā Docker attēlā. Taču izrādÄ«jās, ka runa ir par pavisam ko citu. Jebkurā gadÄ«jumā ir atseviŔķi konteineri, atseviŔķi podi - tikai Docker.

DS: Jā. Un ir izveidota diezgan smieklÄ«ga imitācija, bet nozÄ«me ir tāda... Mums ir utilÄ«ta izvietoÅ”anai - werf. Mēs vēlamies to padarÄ«t par nosacÄ«tu režīmu werf up: "Atnesiet man vietējo Kubernetes." Un tad tur palaist nosacÄ«to werf follow. Pēc tam izstrādātājs varēs rediģēt IDE, un sistēmā tiks palaists process, kas redz izmaiņas un pārbÅ«vē attēlus, pārizvietojot tos uz vietējiem K8. Tā mēs vēlamies mēģināt atrisināt vietējās attÄ«stÄ«bas problēmu.

Momentuzņēmumi un datu bāzes klonÄ“Å”ana K8s realitātē

NS: Ja mēs atgriežamies pie kopÄ“Å”anas-rakstÄ«Å”anas. PamanÄ«ju, ka mākoņiem ir arÄ« momentuzņēmumi. Viņi strādā savādāk. Piemēram, GSP: jums ir vairāku terabaitu instance Amerikas Savienoto Valstu austrumu krastā. JÅ«s periodiski uzņemat momentuzņēmumus. JÅ«s paņemat diska kopiju rietumu krastā no momentuzņēmuma - pēc dažām minÅ«tēm viss ir gatavs, tas darbojas ļoti ātri, tikai keÅ”atmiņa ir jāaizpilda atmiņā. Bet Å”ie kloni (momentuzņēmumi) ir paredzēti jauna apjoma nodroÅ”ināŔanai. Tas ir lieliski, ja jums ir jāizveido daudz gadÄ«jumu.

Bet testiem man liekas, ka momentuzņēmumi, par kuriem tu runā Docker vai es runāju par ZFS, btrfs un pat LVM... - tie ļauj neveidot Ä«sti jaunus datus uz vienas maŔīnas. MākonÄ« jÅ«s joprojām maksāsit par tiem katru reizi un gaidÄ«sit nevis sekundes, bet minÅ«tes (un gadÄ«jumā slinka slodze, iespējams, pulkstenis).

Tā vietā varat iegÅ«t Å”os datus sekundē vai divās, palaist pārbaudi un izmest tos. Å ie momentuzņēmumi atrisina dažādas problēmas. Pirmajā gadÄ«jumā - lai palielinātu mērogu un iegÅ«tu jaunas kopijas, bet otrajā - testiem.

DS: Es nepiekrÄ«tu. Pareiza apjoma klonÄ“Å”ana ir mākoņa uzdevums. Es neesmu apskatÄ«jis to ievieÅ”anu, bet es zinu, kā mēs to darām ar aparatÅ«ru. Mums ir Ceph, tas pieļauj jebkuru fizisko apjomu (RBD) teikt klons un iegÅ«stiet otru tilpumu ar tādām paŔām Ä«paŔībām desmitos milisekundēs, IOPSā€˜ami utt. Jums jāsaprot, ka iekŔā ir viltÄ«ga kopÄ“Å”ana uz rakstÄ«Å”anas. Kāpēc lai mākonis nedarÄ«tu to paÅ”u? Esmu pārliecināts, ka viņi tā vai citādi cenÅ”as to darÄ«t.

NS: Bet viņiem joprojām būs vajadzīgas sekundes, desmitiem sekunžu, lai paceltu instanci, nogādātu Dockeru utt.

DS: Kāpēc ir nepiecieÅ”ams izvirzÄ«t visu instanci? Mums ir eksemplārs ar 32 kodoliem, 16... un tajā var ietilpt - piemēram, četri. Kad pasÅ«tÄ«sim piekto, instance jau tiks pacelta, un tad tā tiks dzēsta.

NS: Jā, interesanti, Kubernetes izrādās cits stāsts. MÅ«su datubāze nav K8s, un mums ir viens gadÄ«jums. Bet vairāku terabaitu datu bāzes klonÄ“Å”ana aizņem ne vairāk kā divas sekundes.

DS: Tas ir lieliski. Bet mans sākotnējais viedoklis ir tāds, ka tas nav vispārējs risinājums. Jā, tas ir forÅ”i, taču tas ir piemērots tikai Postgres un tikai vienā mezglā.

NS: Tas ir piemērots ne tikai Postgres: Å”ie plāni, kā es aprakstÄ«ju, darbosies tikai tajā. Bet, ja mēs neuztraucamies par plāniem un mums ir nepiecieÅ”ami tikai visi dati funkcionālajai pārbaudei, tad tas ir piemērots jebkurai DBVS.

DS: Pirms daudziem gadiem mēs kaut ko līdzīgu darījām LVM momentuzņēmumos. Šī ir klasika. Šī pieeja tika ļoti aktīvi izmantota. Nozīmīgi mezgli ir tikai sāpes. Tā kā tos nedrīkst nomest, tie vienmēr jāatceras...

NS: Vai jÅ«s Å”eit redzat kādu hibrÄ«da iespēju? Pieņemsim, ka statusful ir sava veida pods, tas darbojas vairākiem cilvēkiem (daudziem testētājiem). Mums ir viens sējums, bet, pateicoties failu sistēmai, kloni ir lokāli. Ja pods nokrÄ«t, bet disks paliek, pods pacelsies, saskaitÄ«s informāciju par visiem kloniem, paņems visu vēlreiz un saka: "Å eit ir jÅ«su kloni, kas darbojas Å”ajos portos, turpiniet strādāt ar tiem."

DS: Tehniski tas nozīmē, ka Kubernetes tas ir viens pods, kurā mēs darbinām daudzus Postgres.

NS: Jā. Viņam ir ierobežojums: pieņemsim, ka ar viņu vienlaikus strādā ne vairāk kā 10 cilvēki. Ja jums ir nepiecieÅ”ami 20, mēs izlaidÄ«sim otru Ŕādu podziņu. Mēs to pilnÄ«bā klonēsim, saņemot otro pilno sējumu, tam bÅ«s tie paÅ”i 10 ā€œplānieā€ kloni. Vai jÅ«s neredzat Å”o iespēju?

DS: Å”eit ir jāpievieno droŔības jautājumi. Šāda veida organizācija nozÄ«mē, ka Å”im podam ir augstas privilēģijas (iespējas), jo tas var veikt nestandarta darbÄ«bas failu sistēmā... Bet es atkārtoju: es uzskatu, ka vidējā termiņā viņi sakārtos krātuvi Kubernetes, un mākoņus viņi visu stāstu salabos ar apjomiem - viss "vienkārÅ”i darbosies". BÅ«s izmēru maiņa, klonÄ“Å”ana... Ir sējums - sakām: ā€œIzveidojiet jaunu, pamatojoties uz to,ā€ un pēc pusotras sekundes mēs iegÅ«stam vajadzÄ«go.

NS: Es neticu pusotrai sekundei daudziem terabaitiem. Uz Ceph jÅ«s to darāt pats, bet jÅ«s runājat par mākoņiem. Dodieties uz mākoni, izveidojiet vairāku terabaitu EBS sējuma klonu uz EC2 un skatieties, kāds bÅ«s sniegums. Tas neaizņems dažas sekundes. Mani ļoti interesē, kad viņi sasniegs Å”o lÄ«meni. Es saprotu, ko jÅ«s sakāt, bet es lÅ«dzu atŔķirties.

DS: Labi, bet es teicu vidējā termiņā, nevis īstermiņā. Jau vairākus gadus.

Par PostgreSQL operatoru no Zalando

Å Ä«s sanāksmes vidÅ« arÄ« Aleksejs Kļukins, bijuÅ”ais Zalando izstrādātājs, pievienojās un runāja par PostgreSQL operatora vēsturi:

Lieliski, ka Ŕī tēma tiek skarta kopumā: gan Postgres, gan Kubernetes. Kad 2017. gadā sākām to darÄ«t Zalando, tā bija tēma, ko visi gribēja darÄ«t, bet neviens nedarÄ«ja. Visiem jau bija Kubernetes, bet kad jautāja, ko darÄ«t ar datu bāzēm, pat cilvēkiem patÄ«k Kelsija Haitora, kurÅ” sludināja K8s, teica apmēram Ŕādi:

ā€œDodieties uz pārvaldÄ«tajiem pakalpojumiem un izmantojiet tos, nepalaidiet datu bāzi Kubernetes. Pretējā gadÄ«jumā jÅ«su K8s nolems, piemēram, veikt jaunināŔanu, izslēgt visus mezglus, un jÅ«su dati lidos tālu, tālu.

Mēs nolēmām izveidot operatoru, kas pretēji Å”im ieteikumam palaidÄ«s Postgres datubāzi Kubernetes. Un mums bija labs iemesls - Patroni. Å Ä« ir automātiska PostgreSQL kļūmjpārlēce, kas veikta pareizi, t.i. izmantojot etcd, consul vai ZooKeeper kā informācijas krātuvi par kopu. Tāda krātuve, kas katram, kas jautās, piemēram, kāds ir paÅ”reizējais vadÄ«tājs, dos vienu un to paÅ”u informāciju - neskatoties uz to, ka mums viss ir sadalÄ«ts - lai nav saŔķeltu smadzenes. Turklāt mums bija Docker attēls viņam.

Kopumā uzņēmuma vajadzÄ«ba pēc automātiskās kļūmjpārlēces parādÄ«jās pēc migrÄ“Å”anas no iekŔējā aparatÅ«ras datu centra uz mākoni. Mākoņa pamatā bija patentēts PaaS (Platform-as-a-Service) risinājums. Tas ir atvērts avots, taču bija nepiecieÅ”ams daudz darba, lai to izveidotu un palaistu. Tas saucās STUPS.

Sākotnēji Kubernetes nebija. PrecÄ«zāk, kad tika ieviests mÅ«su paÅ”u risinājums, K8 jau pastāvēja, taču tas bija tik neapstrādāts, ka nebija piemērots ražoÅ”anai. Tas, manuprāt, bija 2015. vai 2016. gads. LÄ«dz 2017. gadam Kubernetes bija vairāk vai mazāk nobrieduÅ”as ā€” tur bija jāmigrē.

Un mums jau bija Docker konteiners. Bija PaaS, kas izmantoja Docker. Kāpēc gan neizmēģināt K8s? Kāpēc gan neuzrakstÄ«t savu operatoru? Murats Kabilovs, kurÅ” ieradās pie mums no Avito, sāka to kā projektu pēc savas iniciatÄ«vas - "spēlēt" - un projekts "pacēlās".

Bet kopumā es gribēju runāt par AWS. Kāpēc bija vēsturisks ar AWS saistīts kods...

Palaižot kaut ko Kubernetes, jāsaprot, ka K8s ir tāds nepabeigts darbs. Tas pastāvīgi attīstās, uzlabojas un ik pa laikam pat sabojājas. Jums rūpīgi jāseko līdzi visām Kubernetes izmaiņām, jābūt gatavam tajā ienirt, ja kaut kas notiek, un detalizēti uzzināt, kā tas darbojas - varbūt vairāk, nekā jūs vēlētos. Tas principā attiecas uz jebkuru platformu, kurā izmantojat savas datu bāzes...

Tātad, kad mēs sagatavojām paziņojumu, Postgres darbojās ārējā sējumā (Å”ajā gadÄ«jumā EBS, jo mēs strādājām pie AWS). Datubāze pieauga, kaut kad bija nepiecieÅ”ams to mainÄ«t: piemēram, EBS sākotnējais izmērs bija 100 TB, datu bāze izauga lÄ«dz tai, tagad gribam uztaisÄ«t EBS 200 TB. Kā? Pieņemsim, ka varat veikt izgāzÅ”anu/atjaunoÅ”anu jaunā instancē, taču tas prasÄ«s ilgu laiku un dÄ«kstāvi.

Tāpēc es gribēju mainīt izmēru, kas palielinātu EBS nodalījumu un pēc tam liktu failu sistēmai izmantot jauno vietu. Un mēs to izdarījām, bet tajā laikā Kubernetes nebija API izmēra maiņas darbībai. Tā kā mēs strādājām pie AWS, mēs rakstījām kodu tā API.

Neviens neliedz jums darÄ«t to paÅ”u attiecÄ«bā uz citām platformām. Paziņojumā nav mājienu, ka to var palaist tikai AWS, un tas nedarbosies ar visu pārējo. Kopumā Å”is ir atvērtā koda projekts: ja kāds vēlas paātrināt jaunā API lietoÅ”anas raÅ”anos, laipni lÅ«dzam. Ēst GitHub, pull pieprasÄ«jumus - Zalando komanda cenÅ”as diezgan ātri atbildēt uz tiem un reklamēt operatoru. Cik man zināms, projekts piedalÄ«jās Google Summer of Code un dažās citās lÄ«dzÄ«gās iniciatÄ«vās. Zalando ļoti aktÄ«vi strādā pie tā.

P.S. Bonuss!

Ja jÅ«s interesē PostgreSQL un Kubernetes tēma, lÅ«dzu, ņemiet vērā, ka nākamā Postgres otrdiena notika pagājuÅ”ajā nedēļā, kurā es runāju ar Nikolaju Aleksandrs KukuÅ”kins no Zalando. Ir pieejams video no tā Å”eit.

PPS

Lasi arī mūsu emuārā:

Avots: www.habr.com

Pievieno komentāru