UnĂ« quhem Sergey, jam nga kompania ITSumma, dhe dua t'ju tregoj se si e qasemi rezervimit nĂ« Kubernetes. KohĂ«t e fundit, kam pĂ«rfshirĂ« shumĂ« nĂ« punĂ«n e konsultimit pĂ«r implementimin e zgjidhjeve tĂ« ndryshme devops pĂ«r ekipe tĂ« ndryshme, dhe veçanĂ«risht, kam punuar ngushtĂ« nĂ« projekte qĂ« pĂ«rdorin K8s. NĂ« konferencĂ«n Uptime day 4, e cila ishte e pĂ«rkushtuar rezervimit nĂ« arkitektura komplekse, kam mbajtur njĂ« fjalim mbi rezervimin e âkubikĂ«veâ, dhe ja njĂ« pĂ«rmbledhje e tij. Por, paraprakisht, dua tĂ« paralajmĂ«roj se kjo nuk Ă«shtĂ« njĂ« udhĂ«zim i drejtpĂ«rdrejtĂ« pĂ«r veprim, por pĂ«rmbledhje e reflektimeve mbi kĂ«tĂ« temĂ«.
NĂ« parim, monitorimi dhe rezervimi janĂ« dy mjetet kryesore pĂ«r tĂ« rritur qĂ«ndrushmĂ«rinĂ« e çdo projekti. Por ju do tĂ« thoni, nĂ« kuber gjithçka balancohet vetĂ«, gjithçka shkallĂ«zohet vetĂ«, dhe nĂ«se ndodh ndonjĂ« gjĂ«, do tĂ« ringrihet vetvetiu⊠Pra, gjatĂ« njĂ« kĂ«rkimi tĂ« parĂ« nĂ« temĂ«, pĂ«r pyetjen se si e qasen tĂ« tjerĂ«t rezervimit tĂ« K8s, interneti mĂ« kĂ«shilloi: âpse?â. ShumĂ« mendojnĂ« se kuber Ă«shtĂ« njĂ« gjĂ« magjike qĂ« shuan tĂ« gjitha problemet infrastrukturore dhe bĂ«n qĂ« projekti tĂ« mos bjerĂ« kurrĂ«. Por⊠bota nuk Ă«shtĂ« ashtu siç duket.
Si e qasnim ne procesin e rezervimit mĂ« parĂ«? Kishim platforma identike pĂ«r hostim â ose ishin virtuale, ose ishin fizike hostingut, pĂ«r tĂ« cilat ne aplikonim tri praktika bazĂ«:
- sinkronizimi i kodit dhe statikës
- sinkronizimi i konfigurimeve
- replicimi i bazës së dhënave
Dhe ja ku jemi: në çdo moment mund të kalojmë në platformën rezervë, të gjithë janë të lumtur, ne ngrihemi dhe shkojmë.
ĂfarĂ« na ofrohet pĂ«r tĂ« rritur disponueshmĂ«rinĂ« e vazhdueshme tĂ« aplikacionit tonĂ« kubernetes? E para qĂ« thotĂ« dokumentacioni jozyrtar â Ă«shtĂ« tĂ« vendosim shumĂ« makina, tĂ« bĂ«jmĂ« shumĂ« mastera â numri i tyre duhet tĂ« plotĂ«sojĂ« kushtet pĂ«r arritjen e kvorumit brenda klasterit, dhe qĂ« nĂ« secilin master tĂ« ketĂ« tĂ« ngritur etcd, api, MC, planifikuesin⊠Dhe, siç duket, gjithçka Ă«shtĂ« nĂ« rregull: kur disa nodet punuese ose masterat dalin jashtĂ« funksionit, klasteri ynĂ« do tĂ« rigrupohet, dhe aplikacioni do tĂ« vazhdojĂ« tĂ« punojĂ«. SĂ«rish duket si magji! Por shpesh klasteri ynĂ« Ă«shtĂ« brenda njĂ« qendre tĂ« vetme tĂ« pĂ«rpunimit tĂ« tĂ« dhĂ«nave, dhe kjo mund tĂ« sjellĂ« disa pyetje. ĂfarĂ« nĂ«se njĂ« ekskavator erdhi dhe gĂ«rmoi kabllin, njĂ« shkĂ«ndijĂ« goditi, ndodhi njĂ« pĂ«rmbytje globale? Gjithçka u shkatĂ«rrua, klasteri ynĂ« nuk ekziston mĂ«. Si duhet qasur nĂ« rezervimin duke marrĂ« parasysh kĂ«tĂ« anĂ« tĂ« problemit?
SĂ« pari, ju duhet njĂ« klaster tjetĂ«r nĂ« rezervĂ« tĂ« nxehtĂ«, domethĂ«nĂ« njĂ« klaster nĂ« tĂ« cilin mund tĂ« kaloni nĂ« çdo moment. NĂ« kĂ«tĂ« rast, nga pikĂ«pamja e kubers, infrastruktura duhet tĂ« jetĂ« plotĂ«sisht identike. KĂ«shtu qĂ« nĂ«se ka ndonjĂ« plugin jostandard pĂ«r tĂ« punuar me sistemin e skedarĂ«ve, zgjidhje custom pĂ«r ingress, ato duhet tĂ« jenĂ« plotĂ«sisht identike nĂ« tĂ« dy (ose tre, ose dhjetĂ«, ktu Ă«shtĂ« pĂ«r aq sa mjafton buxheti dhe forcat e administratorĂ«ve) klasteret tuaja. Duhet tĂ« pĂ«rcaktoni qartĂ« dy grupe aplikacionesh (deploymentâesh, statefulsetâesh, daemonsetâesh, cronjobâesh etj.): cila prej tyre mund tĂ« funksionojĂ« nĂ« rezervĂ«n pĂ«rherĂ«, dhe cila Ă«shtĂ« mĂ« mirĂ« tĂ« mos aktivizohet deri nĂ« kalimin e drejtpĂ«rdrejtĂ«.
Pra, a duhet që klasteri ynë rezervë të jetë plotësisht identik me klasterin tonë të prodhimit? Jo. Nëse më parë, në kuadër të punës me projekte monolitike, me infrastrukturë fizike, mbaheshim me një ambient pothuajse plotësisht identik, në kuadër të kubers, unë mendoj se kjo nuk duhet të ndodhë. Le të shohim pse.
PĂ«r shembull, le tĂ« fillojmĂ« me entitete themelore tĂ« Kubernetes â deployments â ato duhet tĂ« jenĂ« identike. Duhet tĂ« jenĂ« tĂ« aktivizuar aplikacione, tĂ« cilat nĂ« çdo moment mund tĂ« kapin pĂ«rpunimin e trafikut dhe tĂ« lejojnĂ« projektin tonĂ« tĂ« vazhdojĂ« tĂ« jetojĂ«. NĂ«se flasim pĂ«r skedarĂ«t e konfigurimit, duhet tĂ« shohim nĂ«se ata duhet tĂ« jenĂ« identikĂ« apo jo. Pra, nĂ«se ne, njerĂ«z tĂ« zgjuar, nuk konsumojmĂ« substanca tĂ« ndaluara dhe nuk mbajmĂ« bazĂ«n nĂ« K8s, atĂ«herĂ« nĂ« configmaps duhet tĂ« kemi parametrat e aksesit nĂ« bazĂ«n aktive (processi i rezervimit tĂ« sĂ« cilĂ«s Ă«shtĂ« ndĂ«rtuar ndaras). Pra, pĂ«r tĂ« siguruar aksesin nĂ« kopjen rezervĂ« tĂ« bazĂ«s sĂ« tĂ« dhĂ«nave, duhet tĂ« kemi njĂ« skedar ndihmĂ«s tĂ« veçantĂ« (configmap). Nga ana tjetĂ«r, punojmĂ« po ashtu me secret: fjalĂ«kalimet pĂ«r qasje nĂ« bazĂ«, çelĂ«sat API; nĂ« çdo moment tĂ« caktuar mund tĂ« kemi ose njĂ« secret aktiv, ose njĂ« rezervĂ«. KĂ«shtu qĂ« tashmĂ« kemi dy entitete Kubernetes, versionet rezervĂ« tĂ« tĂ« cilave nuk duhet tĂ« jenĂ« identike me ato aktive. Entiteti tjetĂ«r mbi tĂ« cilin duhet ndalur Ă«shtĂ« cronjob. Cronjob-et nĂ« rezervĂ« nĂ« asnjĂ« rast nuk duhet tĂ« jenĂ« identike me setin e cronjob-eve tĂ« klasterit prodhim! NĂ«se ngremĂ« njĂ« klaster rezervĂ« dhe e ngremĂ« plotĂ«sisht me tĂ« gjitha cronjob-et e aktivizuar â atĂ«herĂ«, pĂ«r shembull, njerĂ«zit do tĂ« marrin nga dy email-e njĂ«herazi nĂ« vend tĂ« njĂ«rit. Ose ndonjĂ« sinkronizim tĂ« dhĂ«nash me burime tĂ« jashtme do tĂ« ndodhĂ« dy herĂ«, kĂ«shtu qĂ« fillojmĂ« tĂ« ndjehemi keq, tĂ« qajmĂ«, tĂ« bĂ«rtasim dhe tĂ« njollosim.
Si na sugjerojnë njerëzit në internet të organizojmë klasterin rezervë? Përgjigjja e dytë më e popullarizuar pas 'përse' është përdorimi i Kubernetes Federation.
ĂfarĂ« Ă«shtĂ« kjo? ĂshtĂ«, si tĂ« thuash, njĂ« metaklaster i madh. NĂ«se paraqesim arkitekturĂ«n e Kubernetes â ku kemi njĂ« master, disa nod, â nga perspektiva e federatĂ«s kemi gjithashtu njĂ« master dhe disa nod, vetĂ«m qĂ« çdo nod Ă«shtĂ« njĂ« klaster i veçantĂ«. Pra, punojmĂ« me tĂ« njĂ«jtat entitete, me tĂ« njĂ«jtat primitive, si me njĂ« Kubernetes, vetĂ«m se pĂ«rdorim klastere tĂ« tĂ«ra e jo makineri fizike. Brenda federatĂ«s, kemi njĂ« sinkronizim tĂ« plotĂ« tĂ« burimeve federale nga prindĂ«rit te pasardhĂ«sit. PĂ«r shembull, nĂ«se aktivizojmĂ« ndonjĂ« deploymĂ«nt pĂ«rmes federatĂ«s â ai do tĂ« aktivizohet nĂ« çdo klaster fĂ«mijĂ«. NĂ«se marrim ndonjĂ« configmap, sekret, dhe e shpĂ«rndajmĂ« nĂ« federatĂ« â ai do tĂ« shpĂ«rndahet nĂ« tĂ« gjithĂ« klasterĂ«t tanĂ« fĂ«mijĂ«; ndĂ«rkohĂ« federata lejon pĂ«rshtatjen e burimeve tona nĂ« fĂ«mijĂ«t. Pra, marrim ndonjĂ« configmap, e aktivizojmĂ« pĂ«rmes federatĂ«s dhe mĂ« pas, nĂ«se na nevojitet ndonjĂ« rregullim nĂ« klasterĂ«t konkretĂ«, ne shkojmĂ« ta rregullojmĂ« nĂ« klasterin e veçantĂ«, dhe ky ndryshim nuk do tĂ« sinkronizohet askund.
Kubernetes Federation â Ă«shtĂ« njĂ« mjet qĂ« ekziston prej jo shumĂ« kohĂ«sh, dhe ajo mbĂ«shtet shumĂ« pak nga burimet qĂ« ofron vetĂ« K8s: nĂ« momentin e publikimit tĂ« njĂ« nga versionet e para tĂ« dokumentacionit, thuhej se mbĂ«shtetja ishte vetĂ«m pĂ«r configmaps, deployente pĂ«r replica-set, ingress. Sekretet nuk mbaheshin, punimi me volume gjithashtu nuk mbĂ«shtetej. NjĂ« gamĂ« e tejet e limituar. Sidomos nĂ«se na pĂ«lqen tĂ« argĂ«tohemi, â pĂ«r shembull, duke kaluar burimet tona tĂ« personalizuara te Kubernetes pĂ«rmes custom resource definition, â nuk do tâi futim ato nĂ« federatĂ«. Pra, si tĂ« them... njĂ« zgjidhje qĂ« duket shumĂ« e ngjashme me tĂ« vĂ«rtetĂ«n, por nashta na bĂ«n tĂ« gjuajmĂ« vetĂ« nĂ« kĂ«mbĂ« nga herĂ« pas here. Nga ana tjetĂ«r, federata lejon menaxhimin fleksibĂ«l tĂ« replicaset-it tonĂ«. PĂ«r shembull, duam qĂ« tĂ« jenĂ« aktivizuar 10 replikat e aplikacionit tonĂ«, nĂ« parim federata do ta ndajĂ« kĂ«tĂ« numĂ«r proporcionalisht mes numrit tĂ« klasterĂ«ve. Dhe kjo mund tĂ« konfigurohet gjithashtu! Pra, mund tĂ« tregojmĂ« se nĂ« klasterin aktiv duhet tĂ« mbajmĂ« 6 replikat e aplikacionit tonĂ«, ndĂ«rsa nĂ« klasterin rezervĂ«, pĂ«r tĂ« kursyer burime, ose pĂ«r ndonjĂ« argĂ«tim tĂ« vetin â vetĂ«m 4 replikat e aplikacionit tonĂ«. Kjo gjithashtu Ă«shtĂ« mjaft e pĂ«rshtatshme. Por me federatĂ«n na duhet tĂ« pĂ«rdorim disa zgjidhje tĂ« reja, tĂ« instalojmĂ« ndonjĂ«herĂ« diçka gjatĂ« rrugĂ«s, tĂ« pĂ«rpiqemi pak mĂ« shumĂ« pĂ«r tĂ« menduar...
A mund tĂ« qasemi nĂ« procesin e rezervimit tĂ« Kubernetes mĂ« thjeshtĂ«? ĂfarĂ« mjetesh kemi nĂ« dispozicion?
Së pari, gjithmonë kemi një sistem CI/CD, pra nuk shkojmë manualisht, nuk shkruajmë në servera create/apply. Sistemi gjeneron yaml për kontejnerët tanë.
Së dyti, kemi disa klasterë, kemi një regjistrim ose disa (nëse jemi të zgjuar) të regjistruar. Dhe kemi një utilitare të shkëlqyer kubectl, e cila mund të punojë me disa klasterë në të njëjtën kohë.
Pra ndaj: sipas mendimit tim, zgjidhja më e thjeshtë dhe e saktë për ndërtimin e një klasteri rezerv është një shpërndarje paralele primare. Ka një pipeline në sistemin ci/cd; së pari, ndërtuam kontejnerët tanë, i testojmë dhe i nxjerrim aplikacionet përmes kubectl në disa klasterë të pavarur. Ne mund të ndjekim shpërndarje të njëkohshme në disa klasterë. Për rrjedhojë, ne gjithashtu e zgjidhim dorëzimin e konfigurimeve në këtë fazë. Mund të përcaktojmë paraprakisht një grup konfiguracionesh për klasterin tonë të prodhimit, një grup konfiguracionesh për klasterin rezerv dhe në nivelin e sistemit ci/cd të shpërndajmë ambientin e prodhimit në klasterin e prodhimit, ambientin rezerv në klasterin rezerv. Krahasuar me federatën, nuk është nevoja të shkojmë pas përcaktimit të burimit federativ në çdo klaster dytësor dhe të rimekëm. Ne e bëmë këtë paraprakisht. Sa të mrekullueshëm që jemi.
Por⊠ka⊠unë isha shkruar, ka 'rrënjën e të gjitha të këqijave', por në të vërtetë janë dy. Së pari, sistemi i skedarëve. Ka një PV, ose ne përdorim një ruajtje të jashtme. Nëse ruajmë skedarët brenda klasterit, atëherë duhet të veprojmë sipas praktikave të vjetra, që kanë mbetur nga koha e infrastrukturave metalike: për shembull, sinkronizimi me lsync. Ose çdo tjetër çrregullim që ju preferoni. Shpërndajmë gjithçka në makina të tjera dhe jetojmë.
SĂ« dyti, dhe nĂ« tĂ« vĂ«rtetĂ«, njĂ« pikĂ« mĂ« e rĂ«ndĂ«sishme pengese â baza e tĂ« dhĂ«nave. NĂ«se jemi njerĂ«z tĂ« mençur dhe nuk e mbajmĂ« bazĂ«n nĂ« kuber, procesi i rezervimit tĂ« tĂ« dhĂ«nave sipas asaj skeme tĂ« vjetĂ«r â replikimi master-slave, pastaj kalimi, do ta pĂ«rfundojmĂ« replikĂ«n dhe do tĂ« jetojmĂ« mirĂ«. Por nĂ«se do ta mbajmĂ« DB-nĂ« tonĂ« brenda klasterit, nĂ« parim ka shumĂ« zgjidhje tĂ« gatshme pĂ«r organizimin e asaj replikĂ«s master-slave, shumĂ« zgjidhje pĂ«r ngritjen e DB-sĂ« brenda kuber.
Për rezervimin e bazave të dhënash janë lexuar miliardë prezantime, janë shkruar miliardë artikuj, nuk ka asgjë të re këtu, në të vërtetë. Në përgjithësi, ndiqni ëndrrën tuaj, jetoni si të doni, shpikni ndonjë çrregullim të ndërlikuar, por sigurisht mendoni se si do t'i rezervoni të gjitha këto.
Tani, le tĂ« flasim pĂ«r atĂ« se si do tĂ« ndodhĂ« procesi i kalimit nĂ« njĂ« vend rezerv pĂ«r rast zjarri. SĂ« pari, ne nĂ« mĂ«nyrĂ« paralele shpĂ«rndajmĂ« aplikacione pa shtesĂ«. Ato nuk ndikojnĂ« nĂ« logjikĂ«n e biznesit tĂ« aplikacioneve tona, projektit tonĂ«, ne mund tĂ« mbajmĂ« vazhdimisht dy grupe tĂ« aplikuar, dhe ato mund tĂ« fillojnĂ« tĂ« pranojnĂ« trafik. ĂshtĂ« shumĂ« e rĂ«ndĂ«sishme nĂ« procesin e kalimit nĂ« vendin rezerv tĂ« shohim nĂ«se duhet tĂ« rimekĂ«m konfigurimet? PĂ«r shembull, kemi klasterin e prodhimit kubernetes, kemi klasterin rezerv kubernetes, kemi njĂ« bazĂ« tĂ« dhĂ«nash master tĂ« jashtme, kemi njĂ« bazĂ« tĂ« dhĂ«nash master rezerv. Ne kemi katĂ«r variante si kĂ«to aplikacione nĂ« prodhim mund tĂ« fillojnĂ« tĂ« interaktojnĂ« me njĂ«ra-tjetrĂ«n. Mund tĂ« kalojĂ« baza, dhe mund tĂ« rezultojĂ« qĂ« duhet tĂ« kalojmĂ« trafik nĂ« klasterin e prodhimit nĂ« bazĂ«n e re, ose klasteri mund tĂ« dĂ«shtojĂ« â dhe ne kaluam nĂ« rezerv, por vazhdojmĂ« tĂ« punojmĂ« me bazĂ«n e prodhimit, dhe, nĂ« variantin e tretĂ«, kur dĂ«shtoi kjo dhe dĂ«shtoi ajo, dhe ne kalojmĂ« tĂ« dy aplikacionet, rimekĂ«m konfigurimin tonĂ« qĂ« aplikacionet e reja tĂ« punojnĂ« me bazĂ«n e dhĂ«nash tĂ« re.
Pra, cilat janë përfundimet që mund të nxjerrim nga të gjitha këto?
PĂ«rfundimi i parĂ«: Ă«shtĂ« mirĂ« tĂ« jetosh me rezerv. Por Ă«shtĂ« e shtrenjtĂ«. NĂ« ideal duhet tĂ« jetosh jo vetĂ«m me njĂ« rezervĂ«. NĂ« ideal, duhet tĂ« jetosh me disa rezerva. SĂ« pari, rezerva duhet tĂ« jetĂ«, tĂ« paktĂ«n, jo nĂ« njĂ« QendĂ«r tĂ« DhĂ«nash (DC), dhe sĂ« dyti, tĂ« paktĂ«n, tek njĂ« host tjetĂ«r. Ka ndodhur shpesh â dhe nĂ« praktikĂ«n time ka ndodhur. Projekte, padyshim, nuk mund t'i emĂ«rtoj, kur ndodhi zjarri nĂ« qendrĂ«n e tĂ« dhĂ«nave... UnĂ« thashĂ«: kalojmĂ« te rezervimi! Por serverat rezervĂ« ishin nĂ« tĂ« njĂ«jtin raft...
Ose imagjinoni se Amazon u ndalua nĂ« Rusi (dhe kjo ndodhi). Dhe gjithçka: çfarĂ« do tĂ« thotĂ« qĂ« rezervi ynĂ« ndodhet nĂ« njĂ« amazon tjetĂ«r? Ai Ă«shtĂ« gjithashtu i papĂ«rshkueshĂ«m. Pra, e pĂ«rsĂ«ris: mbani rezervĂ«n, tĂ« paktĂ«n, nĂ« njĂ« QendĂ«r tĂ« DhĂ«nash tjetĂ«r, dhe preferohet â te njĂ« host tjetĂ«r.
Përfundimi i dytë: nëse keni një aplikacion në kuber që komunikon me disa burime të jashtme (kjo mund të jetë ose një bazë të dhënash, ose ndonjë API të jashtëm), sigurisht që duhet ta përcaktoni atë si një shërbim me një Endpoint të jashtëm, në mënyrë që në momentin e kalimit të mos e rishpërndani 15 aplikacione tuaja që lidhen me të njëjtën bazë. Përcaktoni bazën si një shërbim të veçantë, lidheni me të, sikur të ishte brenda klasterit tuaj: nëse baza juaj dështoi, ju në një vend e ndryshoni ip-në dhe vazhdoni të jetoni të lumtur.
Dhe përfundimisht: unë e dua "kubikun", ashtu si eksperimet me të. Po ashtu, më pëlqen të ndaj rezultatet e këtyre eksperimenteve dhe përvojën time personale. Prandaj, kam regjistruar një serie webinarësh mbi K8s, mirëseardhje në për detaje.
Burimi: habr.com
