Kub-në-kub, metaklustera, huall mjalti, shpërndarja e burimeve

Oriz. 1. Ekosistemi Kubernetes në Alibaba Cloud

Që nga viti 2015, shërbimi i kontejnerëve në renë kompjuterike Alibaba për Kubernetes (ACK) ka qenë një nga shërbimet cloud me rritje më të shpejtë në Alibaba Cloud. Ai u shërben klientëve të shumtë dhe gjithashtu mbështet infrastrukturën e brendshme të Alibaba dhe shërbimet e tjera cloud të kompanisë.

Ashtu si me shërbimet e ngjashme të kontejnerëve nga ofruesit e reve kompjuterike të klasit botëror, përparësitë tona kryesore janë besueshmëria dhe disponueshmëria. Prandaj, është krijuar një platformë e shkallëzueshme dhe e aksesueshme globalisht për dhjetëra mijëra grupe Kubernetes.

Në këtë artikull, ne do të ndajmë përvojën tonë për menaxhimin e një numri të madh grupesh Kubernetes në infrastrukturën cloud, si dhe arkitekturën e platformës themelore.

Hyrje

Kubernetes është bërë standardi de fakto për një sërë ngarkesash pune në re. Siç tregohet në Fig. 1 më lart, gjithnjë e më shumë aplikacione të Alibaba Cloud po funksionojnë tani në grupimet Kubernetes: aplikacione shtetërore dhe pa shtetësi, si dhe menaxherët e aplikacioneve. Menaxhimi i Kubernetes ka qenë gjithmonë një temë interesante dhe serioze diskutimi për inxhinierët që ndërtojnë dhe mirëmbajnë infrastrukturën. Kur bëhet fjalë për ofruesit e reve kompjuterike si Alibaba Cloud, çështja e shkallëzimit del në pah. Si të menaxhoni grupimet Kubernetes në këtë shkallë? Ne kemi mbuluar tashmë praktikat më të mira për menaxhimin e grupimeve të mëdha Kubernetes me 10 nyje. Sigurisht, ky është një problem interesant i shkallëzimit. Por ka një shkallë tjetër: sasia vetë grupimet.

Ne e kemi diskutuar këtë temë me shumë përdorues të ACK. Shumica e tyre zgjedhin të drejtojnë dhjetëra, nëse jo qindra, grupime të vogla ose të mesme Kubernetes. Ka arsye të mira për këtë: kufizimi i dëmeve të mundshme, ndarja e grupimeve për ekipe të ndryshme, krijimi i grupimeve virtuale për testim. Nëse ACK synon t'i shërbejë një audiencë globale me këtë model përdorimi, ajo duhet të menaxhojë me besueshmëri dhe efikasitet një numër të madh grupimesh në më shumë se 20 rajone.

Oriz. 2. Problemet e menaxhimit të një numri të madh grupimesh Kubernetes

Cilat janë sfidat kryesore të menaxhimit të grupimeve në këtë shkallë? Siç tregohet në figurë, ka katër çështje që duhen trajtuar:

• Heterogjeniteti

ACK duhet të mbështesë lloje të ndryshme të grupimeve, duke përfshirë standarde, pa server, Edge, Windows dhe disa të tjerë. Grupe të ndryshme kërkojnë opsione, komponentë dhe modele të ndryshme pritëse. Disa klientë kanë nevojë për ndihmë me personalizimin për rastet e tyre specifike.

• Madhësi të ndryshme grupesh

Grupet ndryshojnë në madhësi, nga disa nyje me disa pods deri në dhjetëra mijëra nyje me mijëra pods. Kërkesat për burime gjithashtu ndryshojnë shumë. Shpërndarja jo e duhur e burimeve mund të ndikojë në performancën apo edhe të shkaktojë dështim.

• Versione të ndryshme

Kubernetes po zhvillohet shumë shpejt. Versionet e reja lëshohen çdo disa muaj. Klientët janë gjithmonë të gatshëm të provojnë veçori të reja. Pra, ata duan të vendosin ngarkesën e provës në versionet e reja të Kubernetes dhe ngarkesën e prodhimit në ato të qëndrueshme. Për të përmbushur këtë kërkesë, ACK duhet të dorëzojë vazhdimisht versione të reja të Kubernetes tek klientët duke ruajtur versione të qëndrueshme.

• Pajtueshmëria e sigurisë

Grupet shpërndahen nëpër rajone të ndryshme. Si të tilla, ato duhet të jenë në përputhje me kërkesa të ndryshme sigurie dhe rregullore zyrtare. Për shembull, një grup në Evropë duhet të jetë në përputhje me GDPR, ndërsa një re financiare në Kinë duhet të ketë shtresa shtesë mbrojtjeje. Këto kërkesa janë të detyrueshme dhe është e papranueshme t'i shpërfillni, pasi kjo krijon rreziqe të mëdha për klientët e platformës cloud.

Platforma ACK është krijuar për të zgjidhur shumicën e problemeve të mësipërme. Aktualisht menaxhon në mënyrë të besueshme dhe të qëndrueshme më shumë se 10 mijë grupime Kubernetes në mbarë botën. Le të shohim se si u arrit kjo, duke përfshirë disa parime kryesore të projektimit/arkitekturës.

Dizajn

Kub mbi kub dhe huall mjalti

Ndryshe nga një hierarki e centralizuar, arkitektura e bazuar në qeliza zakonisht përdoret për të shkallëzuar një platformë përtej një qendre të vetme të dhënash ose për të zgjeruar fushën e rikuperimit nga fatkeqësitë.

Çdo rajon në renë Alibaba përbëhet nga disa zona (AZ) dhe zakonisht korrespondon me një qendër specifike të dhënash. Në një rajon të madh (p.sh. Huangzhou), shpesh ka mijëra grupe klientësh Kubernetes që drejtojnë ACK.

ACK menaxhon këto grupime Kubernetes duke përdorur vetë Kubernetes, që do të thotë se ne kemi një metacluster Kubernetes që funksionon për të menaxhuar grupet e klientëve Kubernetes. Kjo arkitekturë quhet edhe "kube-on-kube" (KoK). Arkitektura KoK thjeshton menaxhimin e grupimeve të klientëve sepse vendosja e grupimeve është e thjeshtë dhe përcaktuese. Më e rëndësishmja, ne mund të ripërdorim veçoritë vendase të Kubernetes. Për shembull, menaxhimi i serverëve API përmes vendosjes, përdorimi i operatorit etcd për të menaxhuar etcds të shumta. Një rikthim i tillë gjithmonë sjell kënaqësi të veçantë.

Disa metaklustera Kubernetes vendosen brenda një rajoni, në varësi të numrit të klientëve. Ne i quajmë këto metaklustera qeliza. Për të mbrojtur kundër dështimit të një zone të tërë, ACK mbështet vendosjet multi-aktive në një rajon të vetëm: metaklusteri shpërndan komponentët master të grupit të klientëve Kubernetes nëpër zona të shumta dhe i ekzekuton ato njëkohësisht, domethënë në modalitetin multi-aktiv. Për të siguruar besueshmërinë dhe efikasitetin e masterit, ACK optimizon vendosjen e komponentëve dhe siguron që serveri API dhe etcd të jenë afër njëri-tjetrit.

Ky model ju lejon të menaxhoni Kubernetes në mënyrë efikase, fleksibël dhe të besueshme.

Planifikimi i burimeve metakluster

Siç e kemi përmendur tashmë, numri i metaklusterave në çdo rajon varet nga numri i klientëve. Por në cilën pikë të shtoni një metakluster të ri? Ky është një problem tipik i planifikimit të burimeve. Si rregull, është zakon të krijohet një i ri kur metaklusterët ekzistues kanë shteruar të gjitha burimet e tyre.

Le të marrim burimet e rrjetit, për shembull. Në arkitekturën KoK, komponentët Kubernetes nga grupimet e klientëve vendosen si pods në një metakluster. Ne përdorim Terway (Fig. 3) është një plugin me performancë të lartë i zhvilluar nga Alibaba Cloud për menaxhimin e rrjetit të kontejnerëve. Ai siguron një grup të pasur politikash sigurie dhe ju lejon të lidheni me retë private virtuale të klientëve (VPC) përmes Ndërfaqes Elastike të Rrjetit Alibaba Cloud (ENI). Për të shpërndarë në mënyrë efektive burimet e rrjetit nëpër nyje, pods dhe shërbime në një metakluster, ne duhet të monitorojmë me kujdes përdorimin e tyre brenda metaklusterit të reve private virtuale. Kur burimet e rrjetit marrin fund, krijohet një qelizë e re.

Për të përcaktuar numrin optimal të grupeve të klientëve në çdo metakluster, ne marrim gjithashtu parasysh kostot tona, kërkesat e densitetit, kuotën e burimeve, kërkesat e besueshmërisë dhe statistikat. Vendimi për të krijuar një metakluster të ri merret në bazë të gjithë këtij informacioni. Ju lutemi vini re se grupimet e vogla mund të zgjerohen shumë në të ardhmen, kështu që konsumi i burimeve rritet edhe nëse numri i grupimeve mbetet i pandryshuar. Ne zakonisht lëmë hapësirë ​​të mjaftueshme të lirë që çdo grup të rritet.

Oriz. 3. Arkitektura e rrjetit Terway

Shkallëzimi i komponentëve të magjistarit nëpër grupimet e klientëve

Komponentët e magjistarit kanë nevoja të ndryshme për burime. Ato varen nga numri i nyjeve dhe podeve në grup, numri i kontrolluesve/operatorëve jo standardë që ndërveprojnë me APIServer.

Në ACK, çdo grup klientësh Kubernetes ndryshon në madhësi dhe kërkesat e kohës së funksionimit. Nuk ka asnjë konfigurim universal për vendosjen e komponentëve të magjistarit. Nëse gabimisht vendosim një kufi të ulët të burimeve për një klient të madh, atëherë grupi i tij nuk do të jetë në gjendje të përballojë ngarkesën. Nëse vendosni një kufi të lartë konservativ për të gjitha grupimet, burimet do të shpërdorohen.

Për të gjetur një shkëmbim delikate midis besueshmërisë dhe kostos, ACK përdor një sistem tipi. Domethënë, ne përcaktojmë tre lloje të grupimeve: të vogla, të mesme dhe të mëdha. Çdo lloj ka një profil të veçantë të shpërndarjes së burimeve. Lloji përcaktohet në bazë të ngarkesës së komponentëve të magjistarit, numrit të nyjeve dhe faktorëve të tjerë. Lloji i grupit mund të ndryshojë me kalimin e kohës. ACK monitoron vazhdimisht këta faktorë dhe mund të shkruajë lart/poshtë në përputhje me rrethanat. Pasi të ndryshohet lloji i grupit, shpërndarja e burimeve përditësohet automatikisht me ndërhyrje minimale të përdoruesit.

Ne po punojmë për të përmirësuar këtë sistem me shkallëzim më të imët dhe përditësim më të saktë të tipit, në mënyrë që këto ndryshime të ndodhin më mirë dhe të kenë më shumë kuptim ekonomik.

Oriz. 4. Ndërrimi inteligjent i tipit me shumë faza

Evoluimi i grupeve të klientëve në shkallë

Seksionet e mëparshme mbuluan disa aspekte të menaxhimit të një numri të madh grupimesh Kubernetes. Megjithatë, ka një problem tjetër që duhet zgjidhur: evolucioni i grupimeve.

Kubernetes është "Linux" i botës së reve. Ai përditësohet vazhdimisht dhe bëhet më modular. Ne duhet të ofrojmë vazhdimisht versione të reja për klientët tanë, të rregullojmë dobësitë dhe të përditësojmë grupimet ekzistuese, si dhe të menaxhojmë një numër të madh komponentësh të lidhur (CSI, CNI, Device Plugin, Scheduler Plugin dhe shumë të tjerë).

Le të marrim si shembull menaxhimin e komponentëve Kubernetes. Si fillim, ne zhvilluam një sistem të centralizuar për regjistrimin dhe menaxhimin e të gjithë këtyre komponentëve të lidhur.

Oriz. 5. Komponentët fleksibël dhe të mbyllshëm

Përpara se të ecni përpara, duhet të siguroheni që përditësimi ishte i suksesshëm. Për ta bërë këtë, ne kemi zhvilluar një sistem për kontrollimin e funksionalitetit të komponentëve. Kontrolli kryhet para dhe pas përditësimit.

Oriz. 6. Kontroll paraprak i komponentëve të grupimit

Për përditësimin e shpejtë dhe të besueshëm të këtyre komponentëve, një sistem vendosjeje të vazhdueshme funksionon me mbështetje për avancim të pjesshëm (shkallë gri), pauza dhe funksione të tjera. Kontrollorët standardë Kubernetes nuk janë të përshtatshëm për këtë rast përdorimi. Prandaj, për të menaxhuar komponentët e grupit, ne kemi zhvilluar një grup kontrolluesish të specializuar, duke përfshirë një plugin dhe një modul kontrolli ndihmës (menaxhimi i krahut anësor).

Për shembull, kontrolluesi BroadcastJob është krijuar për të përditësuar komponentët në secilën makinë pune ose për të kontrolluar nyjet në secilën makinë. Puna Broadcast ekzekuton një pod në secilën nyje në grup, si një DaemonSet. Sidoqoftë, DaemonSet gjithmonë e mban podin të funksionojë për një kohë të gjatë, ndërsa BroadcastJob e rrëzon atë. Kontrolluesi Broadcast gjithashtu lëshon pods në nyjet e sapobashkuara dhe inicializon nyjet me komponentët e nevojshëm. Në qershor 2019, ne hapëm kodin burimor të motorit të automatizimit OpenKruise, të cilin ne vetë e përdorim brenda kompanisë.

Oriz. 7. OpenKurise organizon ekzekutimin e detyrës Broadcast në të gjitha nyjet

Për të ndihmuar klientët të zgjedhin konfigurimet e duhura të grupit, ne ofrojmë gjithashtu një grup profilesh të paracaktuara, duke përfshirë profilet pa server, Edge, Windows dhe Bare Metal. Ndërsa peizazhi zgjerohet dhe nevojat e klientëve tanë rriten, ne do të shtojmë më shumë profile për të thjeshtuar procesin e lodhshëm të konfigurimit.

Oriz. 8. Profilet e avancuara dhe fleksibël të grupimeve për skenarë të ndryshëm

Vëzhgueshmëria globale nëpër qendrat e të dhënave

Siç tregohet në fig. 9, shërbimi cloud i Alibaba Cloud Container është vendosur në njëzet rajone anembanë botës. Duke pasur parasysh këtë shkallë, një nga qëllimet kryesore të ACK është të monitorojë me lehtësi gjendjen e grupeve të funksionimit në mënyrë që nëse një grup klienti has një problem, ne mund t'i përgjigjemi shpejt situatës. Me fjalë të tjera, ju duhet të gjeni një zgjidhje që do t'ju lejojë të mbledhni në mënyrë efikase dhe të sigurt statistika në kohë reale nga grupet e klientëve në të gjitha rajonet - dhe të prezantoni vizualisht rezultatet.

Oriz. 9. Shpërndarja globale e shërbimit Alibaba Cloud Container në njëzet rajone

Ashtu si shumë sisteme monitorimi Kubernetes, ne përdorim Prometheus si mjetin tonë kryesor. Për çdo metakluster, agjentët e Prometheus mbledhin matjet e mëposhtme:

• Metrikat e OS si burimet e hostit (CPU, memoria, disku, etj.) dhe gjerësia e brezit të rrjetit.
• Metrikë për sistemin e menaxhimit të grupimeve metacluster dhe klientëve, si kube-apiserver, kube-controller-manager dhe kube-scheduler.
• Metrikë nga kubernetes-state-metrics dhe cadvisor.
• Metrikat etjd si koha e shkrimit të diskut, madhësia e bazës së të dhënave, xhiroja e lidhjeve ndërmjet nyjeve, etj.

Statistikat globale mblidhen duke përdorur një model tipik grumbullimi me shumë shtresa. Të dhënat e monitorimit nga çdo metakluster grumbullohen fillimisht në çdo rajon dhe më pas dërgohen në një server qendror që tregon pamjen e përgjithshme. Gjithçka funksionon përmes mekanizmit të federatës. Një server Prometheus në çdo qendër të dhënash mbledh metrikë nga ajo qendër të dhënash dhe serveri qendror Prometheus është përgjegjës për grumbullimin e të dhënave të monitorimit. AlertManager lidhet me Prometheun qendror dhe, nëse është e nevojshme, dërgon sinjalizime përmes DingTalk, email, SMS, etj. Vizualizimi - duke përdorur Grafana.

Në figurën 10, sistemi i monitorimit mund të ndahet në tre nivele:

• Niveli i kufirit

Shtresa më e largët nga qendra. Serveri Prometheus Edge funksionon në çdo metakluster, duke mbledhur metrika nga grupet meta dhe klientë brenda të njëjtit domen të rrjetit.

• Niveli i kaskadës

Funksioni i shtresës së kaskadës Prometheus është të mbledhë të dhëna monitorimi nga rajone të shumta. Këta serverë funksionojnë në nivel të njësive më të mëdha gjeografike si Kina, Azia, Evropa dhe Amerika. Ndërsa grupimet rriten, rajoni mund të ndahet dhe më pas një server Prometheus i nivelit kaskadë do të shfaqet në çdo rajon të ri të madh. Me këtë strategji, ju mund të shkallëzoni pa probleme sipas nevojës.

• Niveli qendror

Serveri qendror Prometheus lidhet me të gjithë serverët kaskadë dhe kryen grumbullimin përfundimtar të të dhënave. Për besueshmëri, dy instanca qendrore të Prometheus u ngritën në zona të ndryshme, të lidhura me të njëjtët serverë kaskadë.

Oriz. 10. Arkitektura globale e monitorimit me shumë nivele e bazuar në mekanizmin e federatës Prometheus

Përmbledhje

Zgjidhjet cloud të bazuara në Kubernetes vazhdojnë të transformojnë industrinë tonë. Shërbimi i kontejnerëve të Alibaba Cloud ofron një pritje të sigurt, të besueshme dhe me performancë të lartë - është një nga hostet më të mirë të reve Kubernetes. Ekipi i Alibaba Cloud beson fort në parimet e Open Source dhe komunitetit me burim të hapur. Ne patjetër do të vazhdojmë të ndajmë njohuritë tona në fushën e funksionimit dhe menaxhimit të teknologjive cloud.

Burimi: www.habr.com