Më quajnë Sergey, jam nga kompania ITSumma, dhe dua t'ju tregoj si ne e qasemi rezervimit në Kubernetes. Kohët e fundit kam punuar shumë në këshillimin për zbatimin e zgjidhjeve të ndryshme devops për ekipe të ndryshme, dhe, veçanërisht, kam punuar ngushtësisht në projekte që përdorin K8s. Në konferencën Uptime day 4, e cila ishte e fokusuar në rezervimin në arkitektura komplekse, kam mbajtur një ligjëratë mbi rezervimin e "kubikës", dhe ja një përmbledhje e lirë e saj. Por më parë dëshiroj të paralajmëroj se ky nuk është një udhëzues i drejtpërdrejtë për veprim, por më tepër një përmbledhje e mendimeve mbi temën e përmendur.
Në parim, monitorimi dhe rezervimi janë dy mjetet kryesore për rritjen e qëndrueshmërisë së çdo projekti. Por, ndoshta do të thoni, në kuber gjithçka balancohet vetë, gjithçka shkallëzohet vetë, dhe nëse ndodh diçka - ajo ngrihet vetë... Kështu që, gjatë një hulumtimi të shkurtër të temës, përgjigjja në internet për pyetjen se si qasemi në rezervimin K8s ishte "pse?" Shumica mendojnë se kuber është një gjë magjike që heq çdo problem infrastruktural dhe bën që projekti të mos bjerë kurrë. Por... bota nuk është ashtu siç duket.
Si e qasëm ne procesin e rezervimit më parë? Kishim platforma identike për akomodim - ose ishin virtuale, ose ishin të metalit serverët, të cilave u aplikonim tri praktika bazë:
- sinkronizimi i kodit dhe statikës
- sinkronizimi i konfigurimeve
- replikimi i bazave të dhënash
Dhe vuala: në çdo moment ne kalojmë në platformën rezervë, të gjithë janë të lumtur, ne qëndrojmë dhe shpërndaheni.
ĂfarĂ« na ofrojnĂ« pĂ«r tĂ« rritur disponueshmĂ«rinĂ« e vazhdueshme tĂ« aplikacionit tonĂ« kubernetes? E para, pĂ«r tĂ« cilĂ«n flet dokumentacioni jozyrtar â Ă«shtĂ« vendosja e shumĂ« makinerive, tĂ« bĂ«sh shumĂ« mastera â numri i tyre duhet tĂ« plotĂ«sojĂ« kushtet pĂ«r tĂ« arritur kuorum brenda klasterit, dhe qĂ« nĂ« çdo master tĂ« jetĂ« ngritur etcd, api, MC, scheduler⊠Dhe, duket sikur gjithçka Ă«shtĂ« e mrekullueshme: nĂ« rast se disa node tĂ« punĂ«s ose masterat shkojnĂ« jashtĂ« funksionit, klasteri ynĂ« pĂ«rshtatet, dhe aplikacioni vazhdon tĂ« punojĂ«. PĂ«rsĂ«ri duket si magji! Por shpesh klasteri ynĂ« ndodhet brenda njĂ« qendre tĂ« vetme tĂ« pĂ«rpunimit tĂ« tĂ« dhĂ«nave dhe kjo mund tĂ« shkaktojĂ« disa pyetje. ĂfarĂ« ndodh nĂ«se njĂ« ekskavator mbĂ«rrin dhe gĂ«rmon kabllin, godet njĂ« rrufe, ndodh njĂ« pĂ«rmbytje universale? Gjithçka Ă«shtĂ« shkatĂ«rruar, klasteri ynĂ« nuk ekziston mĂ«. Si tĂ« qasemi ndaj rezervimit duke marrĂ« parasysh kĂ«tĂ« aspekt tĂ« problemit?
SĂ« pari, ju duhet tĂ« keni njĂ« klaster tjetĂ«r nĂ« rezervĂ« aktive, pra njĂ« klaster, nĂ« tĂ« cilin mund tĂ« kaloni nĂ« çdo moment. NĂ« tĂ« njĂ«jtĂ«n kohĂ«, nga pikĂ«pamja e kubernetes, infrastruktura duhet tĂ« jetĂ« plotĂ«sisht identike. KĂ«shtu qĂ« nĂ«se ka ndonjĂ« plugin jostandarde pĂ«r punĂ«n me sistemin e skedarĂ«ve, zgjidhje tĂ« personalizuara pĂ«r ingress, ato duhet tĂ« jenĂ« plotĂ«sisht identike nĂ« dy (apo tre, ose dhjetĂ«, kĂ«tu deri nĂ« sa para dhe forcĂ« e administratĂ«s) klasterĂ«t tuaj. ĂshtĂ« e nevojshme tĂ« pĂ«rcaktoni qartĂ« dy grupe aplikacionesh (implementimesh, statefulset, daemonset, cronjob, etj): cilat prej tyre mund tĂ« punojnĂ« vazhdimisht nĂ« rezervĂ« dhe cilat Ă«shtĂ« mĂ« mirĂ« tĂ« mos i aktivizoni deri nĂ« kalimin e drejtpĂ«rdrejtĂ«.
Pra, a duhet që klasteri ynë i rezervës të jetë plotësisht identik me klasterin tonë aktiv? Jo. Nëse më parë, në kuadër të punës me projekte monolitike dhe infrastrukturë harduerike, mbanim një ambient praktikisht identik, në kuadër të kubernetes, unë besoj se kjo nuk duhet të ndodhë. Le të shqyrtojmë se pse.
PĂ«r shembull, le tĂ« fillojmĂ« me entitetet bazĂ« tĂ« Kubernetes â deployments â ato duhet tĂ« jenĂ« identike. Aplikacionet duhet tĂ« jenĂ« aktive, tĂ« cilat nĂ« çdo moment mund tĂ« kapercejnĂ« trafikun dhe tĂ« lejojnĂ« projektin tonĂ« tĂ« vazhdojĂ« tĂ« ekzistojĂ«. Kur flasim pĂ«r skedat e konfigurimit, duhet tĂ« shohim nĂ«se ato duhet tĂ« jenĂ« identike apo jo. Pra, nĂ«se ne, njerĂ«zit inteligjentĂ«, nuk pĂ«rdorim substanca tĂ« ndaluara dhe nuk mbajmĂ« bazĂ«n nĂ« K8s, atĂ«herĂ« nĂ« configmaps duhet tĂ« kemi konfigurime pĂ«r qasjen nĂ« bazĂ«n kryesore (procesi i rezervimit tĂ« sĂ« cilĂ«s Ă«shtĂ« ndĂ«rtuar veçmas). Prandaj, pĂ«r tĂ« siguruar aksesin nĂ« versionin rezervĂ« tĂ« bazĂ«s sĂ« tĂ« dhĂ«nave duhet tĂ« kemi njĂ« skedĂ« konfigurimi (configmap) tĂ« veçantĂ«. Po ashtu, ne punojmĂ« me secretâĂ«t: fjalĂ«kalimet pĂ«r qasje nĂ« bazĂ«, çelĂ«sat e API; nĂ« çdo moment, mund tĂ« kemi ose secret-in aktiv, ose atĂ« rezervĂ«. Pra, kemi tashmĂ« dy entitete Kubernetes, versionet rezervĂ« tĂ« tĂ« cilave nuk duhet tĂ« jenĂ« identike me ato aktive. Entiteti tjetĂ«r mbi tĂ« cilin duhet tĂ« fokusohemi Ă«shtĂ« cronjob. CronjobâĂ«t nĂ« rezervĂ« kurrsesi nuk duhet tĂ« jenĂ« identike me setin e cronjobâĂ«ve tĂ« klasterit prodhues! NĂ«se ngremĂ« njĂ« klaster rezervĂ« dhe e ngremĂ« plotĂ«sisht me tĂ« gjitha cronjobâĂ«t e aktivizuar â atĂ«herĂ«, pĂ«r shembull, njerĂ«zit do tĂ« marrin dy letra gjithsej, nĂ« vend tĂ« njĂ« doreze. Ose ndonjĂ« sinkronizim tĂ« tĂ« dhĂ«nave me burimet e jashtme do tĂ« ndodhte dy herĂ«, pĂ«r pasojĂ« ne fillojmĂ« tĂ« sĂ«muremi, tĂ« qajmĂ«, tĂ« bĂ«rtasim dhe tĂ« grindim.
Por si na propozojnĂ« tĂ« organizojmĂ« klasterin rezervĂ« njerĂ«zit nga interneti? NjĂ« pĂ«rgjigje e dytĂ« mĂ« e njohur pas "pse?" â pĂ«rdorimi i FederatĂ«s Kubernetes.
ĂfarĂ« Ă«shtĂ« kjo? ĂshtĂ«, le tĂ« themi, njĂ« metakluster i madh. NĂ«se e imagjinojmĂ« arkitekturĂ«n e kubĂ«s â ku kemi njĂ« master, disa node â atĂ«herĂ«, nga pikĂ«pamja e federatĂ«s, gjithashtu kemi njĂ« master dhe disa node, vetĂ«m se çdo node Ă«shtĂ« njĂ« kluster i veçantĂ«. Pra, punojmĂ« me entitetet e njĂ«jta, me primitivat e njĂ«jtĂ«, si me njĂ« kubĂ« tĂ« vetme, vetĂ«m se manipulojmĂ« jo me makinat tona fizike, por me tĂ« gjithĂ« klasterĂ«t. NĂ« kuadĂ«r tĂ« federatĂ«s, kemi njĂ« sinkronizim tĂ« plotĂ« tĂ« resurset federative nga prindĂ«rit te pasardhĂ«sit. PĂ«r shembull, nĂ«se kemi nisur njĂ« deploy nĂ«pĂ«rmjet federatĂ«s â ai do tĂ« implementohet nĂ« çdo kluster dytĂ«sor. NĂ«se marrim ndonjĂ« configmap, sekret, e shpĂ«rndajmĂ« atĂ« nĂ«pĂ«rmjet federatĂ«s â ai do tĂ« shpĂ«rndahet nĂ« tĂ« gjithĂ« klasterĂ«t tanĂ« dytĂ«sorĂ«; nĂ« tĂ« njĂ«jtĂ«n kohĂ«, federata lejon personalizimin e resurseve tona te fĂ«mijĂ«t. Pra, morĂ«m njĂ« configmap, e implementuam atĂ« nĂ«pĂ«rmjet federatĂ«s dhe pastaj, nĂ«se na nevojitet tĂ« bĂ«jmĂ« ndonjĂ« rregullim nĂ« klasterĂ«t specifikĂ«, shkojmĂ« dhe e rregullojmĂ« nĂ« njĂ« kluster tĂ« veçantĂ«, dhe ky ndryshim nuk do tĂ« sinkronizohet askund.
Federata Kubernetes â njĂ« mjet qĂ« Ă«shtĂ« krijuar jo shumĂ« kohĂ« mĂ« parĂ«, dhe nuk mbĂ«shtet tĂ« gjithĂ« grupin e burimeve qĂ« ofron K8s vetĂ«: nĂ« momentin e publikimit tĂ« njĂ« nga versionet e para tĂ« dokumentacionit, thuhej qĂ« mbĂ«shtetja ishte e disponueshme vetĂ«m pĂ«r config-maps, deployment nĂ«n replica-set, ingress. Sekretet nuk pĂ«rkrahen, as puna me volume. NjĂ« grup shumĂ« i kufizuar burimesh. Sidomos nĂ«se jemi tĂ« apasionuar pas inovacionit, â pĂ«r shembull, pĂ«rmes custom resource definition pĂ«r tĂ« kaluar burimet tona nĂ« Kubernetes, â nuk do t'i pĂ«rfshijmĂ« ato nĂ« federatĂ«. Pra, siç duket⊠njĂ« zgjidhje shumĂ« afĂ«r sĂ« vĂ«rtetĂ«s, por na detyron tĂ« qĂ«llojmĂ« shpesh vetveten. Nga ana tjetĂ«r, federata na jep mundĂ«sinĂ« tĂ« menaxhojmĂ« fleksibilisht replica-setin tonĂ«. PĂ«r shembull, nĂ«se duam tĂ« kemi 10 replika tĂ« aplikacionit tonĂ«, federata, sipas parazgjedhjes, do ta ndajĂ« kĂ«tĂ« numĂ«r proporcionalisht midis klasterĂ«ve. Dhe gjithçka mund tĂ« konfigurohet! Pra, mund tĂ« specifikoni se nĂ« klasterin kryesor duhet tĂ« mbahen 6 replika tĂ« aplikacionit tonĂ«, ndĂ«rsa nĂ« klasterin rezervĂ«, pĂ«r tĂ« kursyer burime ose pĂ«r arsyet tona tĂ« tjera â vetĂ«m 4 replika tĂ« aplikacionit tonĂ«. Kjo Ă«shtĂ« gjithashtu mjaft e pĂ«rshtatshme. Por me federatĂ«n na duhet tĂ« pĂ«rdorim disa zgjidhje tĂ« reja, tĂ« shtojmĂ« diçka nĂ« mĂ«nyrĂ« dinamike, tĂ« detyrojmĂ« veten tĂ« mendojmĂ« pak mĂ« shumĂ«âŠ
A mund tĂ« afrohemi nĂ« procesin e rezervimit tĂ« Kubernetesit ndonjĂ«herĂ« mĂ« thjesht? ĂfarĂ« mjete kemi nĂ« dispozicion pĂ«r ne?
SĂ« pari, gjithmonĂ« kemi njĂ« sistem ci/cd, qĂ« do tĂ« thotĂ« se ne nuk shkojmĂ« dorazi dhe nuk shkruajmĂ« nĂ« serverĂ« create/apply. Sistemi gjeneron yamlâĂ«t pĂ«r kontejnerĂ«t tanĂ«.
Së dyti, ekzistojnë disa klasterë, kemi një ose disa (nëse jemi të zgjuar) registries, që gjithashtu i kemi rezervuar. Dhe ka një utilitar të jashtëzakonshëm, kubectl, i cili mund të punojë me disa klasterë njëkohësisht.
Pra ndiheni: sipas mendimit tim, zgjidhja më e thjeshtë dhe e saktë për ndërtimin e një klasteri rezervë është një implementim paralel primitiv. Ka një pipëline në sistemin ci/cd; së pari ndërlidhim kontejnerët tanë, i testojmë dhe i vendosim aplikacionet përmes kubectl në disa klasterë të pavarur. Mund të ndërtojmë shpërndarje paralelisht në disa klasterë. Në përputhje, ne gjithashtu e zgjidhim dërgimin e konfigurimeve në këtë fazë. Mund të përcaktojmë paraprakisht një grup konfigurimesh për klasterin tonë në prodhim, një grup konfigurimesh për klasterin rezervë dhe në nivelin e sistemit ci/cd të shpërndajmë mjedisin e prodhimit në klasterin e prodhimit, mjedisin rezervë - në klasterin rezervë. Në krahasim me federatën, nuk na duhet të shkojmë pas përcaktimit të burimit federal në çdo klaster të bijë dhe të rinegocjojmë ndonjë gjë. Ne e kemi bërë këtë paraprakisht. Sa mirë jemi.
Por⊠ka⊠unë kisha shkruar, ka «rrënjën e të gjitha të këqijave», por në të vërtetë janë dy. E para, sistemi i skedarëve. Ka ndonjë PV, ose ne përdorim një ruajtje të jashtme. Nëse i ruajmë skedaret brenda klasterit, ateherë duhet të veprojmë sipas praktikave të vjetra që kanë mbetur nga kohët e infrastrukturave fizike: për shembull, të sinkronizojmë me lsync. Ose me ndonjë tjetër mjet të preferuar nga ju. E shpërndajmë gjithçka në makina të tjera dhe jetojmë.
E dyta, 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 e të dhënave në kuber, atëherë procesi i rezervimit të të dhënave sipas të njëjtës skemë të vjetër - replikimi master-slave, pastaj kalimi, ne do ta arrijmë replikën dhe do të jetojmë mirë. Por nëse do të mbajmë DB-në tonë brenda klasterit, atëherë në parim ka shumë zgjidhje të gatshme për organizimin e të njëjtës replikë master-slave, shumë zgjidhje për ngritjen e DB-së brenda kuberit.
Për rezervimin e bazave të të dhënave janë lexuar një miliard raporte, janë shkruar një miliard artikuj, nuk ka asgjë të re këtu, në thelb. Në përgjithësi, ndiqni ëndrrën tuaj, jetoni si të doni, shpikni ndonjë përfitim të ndërlikuar, por patjetër mendoni për mënyrën se si do të rezervoni gjithçka këtë.
Tani tani, si si do tĂ« ndodhĂ« procesi i kalimit nĂ« platformĂ«n rezervĂ« nĂ« rast zjarri. NĂ« radhĂ« tĂ« parĂ«, deploym stateless-aplikacionet paralelisht. Ato nuk ndikojnĂ« nĂ« logjikĂ«n e biznesit tĂ« aplikacioneve tona, tĂ« projektit tonĂ«; ne mund tĂ« mbajmĂ« vazhdimisht dy grupe tĂ« hapura aplikacionesh, dhe ato mund tĂ« fillojnĂ« tĂ« pranojnĂ« trafik. ĂshtĂ« shumĂ« e rĂ«ndĂ«sishme qĂ«, gjatĂ« procesit tĂ« kalimit nĂ« platformĂ«n rezervĂ«, tĂ« shohim nĂ«se nevojitet tĂ« ri-konfigurojmĂ«? PĂ«r shembull, kemi klasterin e prodhimit Kubernetes, njĂ« klaster rezervĂ« Kubernetes, njĂ« bazĂ« tĂ« dhĂ«nash master tĂ« jashtme dhe njĂ« bazĂ« tĂ« dhĂ«nash master rezervĂ«. Kemi katĂ«r opsione se si kĂ«to aplikacione nĂ« prodhim mund tĂ« fillojnĂ« tĂ« ndĂ«rveprojnĂ« mes tyre. Mund tĂ« kalojmĂ« nĂ« njĂ« bazĂ«, dhe mund tĂ« ndodhĂ« qĂ« duhet tĂ« kalojmĂ« trafik nĂ« klasterin e prodhimit nĂ« bazĂ«n e re, ose mund tĂ« ndodhĂ« qĂ« klasteri tĂ« dĂ«shtojĂ« â dhe kalojmĂ« nĂ« rezervĂ«, por vazhdojmĂ« tĂ« punojmĂ« me bazĂ«n e prodhimit, dhe ka njĂ« variant tĂ« tretĂ«, kur e njejta ndodh me njĂ«ra ose tjetrĂ«n, dhe ne kalojmĂ« tĂ« dy aplikacionet, kemi ri-konfiguruar rregullat tona, pĂ«r tĂ« siguruar qĂ« aplikacionet e reja tĂ« punojnĂ« me bazĂ«n e re tĂ« tĂ« dhĂ«nave.
Pra, çfarë përfundimesh mund të nxjerrim nga e gjithë kjo?
PĂ«rfundimi i parĂ«: tĂ« jetosh me rezervĂ«n Ă«shtĂ« mirĂ«. Por Ă«shtĂ« e shtrenjtĂ«. Idealisht, nuk duhet tĂ« kesh vetĂ«m njĂ« rezervĂ«. Idealisht, duhet tĂ« kesh disa rezerva. NĂ« radhĂ« tĂ« parĂ«, rezervat duhet tĂ« jenĂ« minimumi, jo nĂ« njĂ« qendĂ«r tĂ« dhĂ«nash, dhe, nĂ« radhĂ« tĂ« dytĂ«, minimumi, te njĂ« hoster tjetĂ«r. Ka ndodhur shpesh â dhe kjo Ă«shtĂ« pĂ«rvoja ime. Nuk mund tĂ« citoj projekte, por pĂ«r fat tĂ« keq, ndodhi njĂ« zjarr nĂ« njĂ« qendĂ«r tĂ« dhĂ«nash... UnĂ« thashĂ«: kalojmĂ« nĂ« rezervĂ«! Por serverĂ«t rezervĂ« ndodheshin po nĂ« tĂ« njĂ«jtin raft...
Ose imagjinoni se Amazon u ndalua nĂ« Rusi (dhe kjo ka ndodhur). Dhe gjithçka: çfarĂ« dobie ka qĂ« rezervat tona ndodhen nĂ« njĂ« Amazon tjetĂ«r? Ai Ă«shtĂ« gjithashtu i papĂ«rdorshĂ«m. Pra, e them sĂ«rish: mbajmĂ« rezervat, minimumi, nĂ« njĂ« qendĂ«r tĂ« dhĂ«nash tjetĂ«r, dhe sa mĂ« mirĂ« â te njĂ« hoster tjetĂ«r.
Shqyrtimi i dytë: nëse keni një aplikacion në Kubernetes që komunikon me disa burime të jashtme (mund të jetë një bazë të dhënash apo një API i jashtëm), sigurohuni ta përcaktoni atë si shërbim me Endpoint të jashtëm, në mënyrë që kur të kaloni, të mos depozitoni 15 aplikacionet tuaja që lidhen me të njëjtën bazë të dhënash. Përcaktoni bazën si një shërbim të veçantë, lidheni me të siç do të bënit brenda klasterit: nëse ndodh një problem me bazën, ju në një vend ndryshoni IP-në dhe vazhdoni ta jetoni lumturisht.
Dhe përfundimisht: unë e dashuroj "kubikun", ashtu si edhe eksperimentet me të. Po ashtu më pëlqen të ndaja rezultatet e këtyre eksperimentëve dhe përvojën time personale. Prandaj regjistrova një seri webinarësh mbi K8s, mirë se vini në për detaje.
Burimi: habr.com
