The essence of the story about the most popular package manager for Kubernetes could be illustrated with emojis:
- the box represents Helm (it's the best analogy in the latest Emoji release);
- the lock symbolizes security;
- the person signifies the solution to the problem.
In reality, things are a bit more complex, and the narrative is filled with technical details about how to make Helm secure..
- Briefly, what is Helm if you didn't know or have forgotten? What problems does it solve and where does it fit into the ecosystem?
- Let's examine the architecture of Helm. No discussion about security and how to make a tool or solution more secure can occur without an understanding of the component architecture.
- We will discuss the components of Helm.
- The most pressing question â the future â is the new version Helm 3.Â
Everything in this article pertains to Helm 2. This version is currently in production and is most likely what you are using now, and it contains security threats.
About the speaker: Alexander Khayev () has been developing for 10 years, helping to improve content and joined the committee of . Aktualisht punon nĂ« Chainstack si udhĂ«heqĂ«s zhvillimi â njĂ« hibrid mes njĂ« drejtuesi zhvillimi dhe njĂ« personi pĂ«rgjegjĂ«s pĂ«r dorĂ«zimin e versioneve pĂ«rfundimtare. Pra, ndodhet nĂ« vendin e ngjarjeve, ku ndodh gjithçka nga krijimi i produktit deri te pĂ«rdorimi i tij.
Chainstack është një startup i vogël dhe me rritje të shpejtë, i cili ka për qëllim të ofrojë mundësinë për klientët që të harrojnë për infrastrukturen dhe vështirësitë e operimit të aplikacioneve të decentralizuara; ekipi i zhvillimit ndodhet në Singapor. Mos kërkoni nga Chainstack të shesë apo blejë kriptovalutë, por ofroni të flisni për kuadrin e blockchain-it për ndërmarrje, dhe ata do t'ju përgjigjen me kënaqësi.
Helm
Ky është një menaxher paketash (chart) për Kubernetes. Mënyra më e qartë dhe universale për të sjellë aplikacione në një grup Kubernetes.
Sigurisht, bëhet fjalë për një qasje më strukturore dhe industrielle, sesa të krijosh manifestet e tua YAML dhe të shkruash utilitete të vogla.
Helm është e mira më e mirë që ekziston tani në dispozicion dhe popullore.
Pse Helm? Para së gjithash, sepse mbështetet nga CNCF. Cloud Native është një organizatë e madhe, e cila është kompaninë nënë për projektet e Kubernetes, etcd, Fluentd dhe të tjerë.
Një fakt tjetër i rëndësishëm është se Helm është një projekt shumë i popullarizuar. Kur në janar 2019 mendova për ta përshkruar se si të bëjmë Helm të sigurt, projekti kishte mijëra yje në GitHub. Deri në maj, numri i tyre arriti në 12 mijë.
Shumë njerëz janë të interesuar për Helm, prandaj, edhe nëse nuk e përdorni ende, njohuritë në lidhje me sigurinë e tij do t'ju ndihmojnë. Siguria është e rëndësishme.
Ekipi kryesor i Helm mbështetet nga Microsoft Azure, dhe prandaj ky projekt është mjaft i qëndrueshëm në krahasim me shumë të tjerë. Dalja e Helm 3 Alpha 2 në mes të korrikut tregon se shumë njerëz po punojnë për projektin, dhe ata kanë dëshirë dhe fuqi për ta zhvilluar dhe përmirësuar Helm.
Helm zgjidh disa probleme thelbësore në menaxhimin e aplikacioneve në Kubernetes.
- Paketa e aplikacionit. Edhe një aplikacion si 'Hello, World' në WordPress përfaqëson disa shërbime, dhe dëshira është t'i paketojmë ato së bashku.
- Menaxhimi i kompleksitetit që lind me menaxhimin e këtyre aplikacioneve.
- Një cikël jetësor që nuk përfundon pas instalimit ose shpërndarjes së aplikacionit. Ai vazhdon të jetojë, duhet të përditësohet, dhe në këtë ndihmon Helm, duke u përpjekur të ofrojë masat dhe politikën e duhur për këtë.
Paketa është e strukturuar në një mënyrë të qartë: ka meta të dhëna që përputhen plotësisht me funksionimin e menaxherëve të zakonshëm të paketave për Linux, Windows ose MacOS. Këtu përfshihet depoja, varësitë nga paketat e ndryshme, metainformacioni për aplikacionet, konfigurimet, karakteristikat e konfiguruarjes, indeksimi i informacionit etj. Helm lejon që të gjitha këto të marrin dhe përdorin për aplikacionet.
Menaxhimi i kompleksitetit. Nëse keni shumë aplikacione të ngjashme, do të nevojitet parametrizimi. Këtu dalin modelet, por për të mos krijuar mënyrën tuaj të krijimit të modeleve, mund të përdorni atë që Helm ofron prej fillimit.
Menaxhimi i ciklit jetĂ«sor tĂ« aplikacionit â sipas mendimit tim, kjo Ă«shtĂ« pyetja mĂ« interesante dhe e pazgjidhur. Kjo Ă«shtĂ« arsyeja pse nĂ« tĂ« kaluarĂ«n kam ardhur nĂ« Helm. Na duhej tĂ« monitoronim ciklin jetĂ«sor tĂ« aplikacionit, dĂ«shironim tĂ« transferonim CI/CD dhe ciklet e aplikacioneve nĂ« kĂ«tĂ« paradigmĂ«.
Helm lejon:
- menaxho deploy-t, prezanton konceptin e konfigurimit dhe revizionit;
- të kryejnë me sukses rollback;
- të përdorin hook-et për ngjarje të ndryshme;
- të shtojnë kontrollime shtesë për aplikacionet dhe të reagojnë ndaj rezultateve të tyre.
PĂ«r mĂ« tepĂ«r Helm ka "bateritĂ«" â njĂ« sasi tĂ« madhe gjĂ«rash tĂ« shijshme qĂ« mund tĂ« pĂ«rfshihen si plugins, duke e bĂ«rĂ« jetĂ«n tuaj mĂ« tĂ« lehtĂ«. Plugins mund tĂ« shkruhen nga vetĂ«, ato janĂ« mjaft tĂ« izoluara dhe nuk kĂ«rkojnĂ« njĂ« arkitekturĂ« tĂ« ndĂ«rlikuar. NĂ«se dĂ«shironi tĂ« realizoni diçka, rekomandoj ta bĂ«ni si njĂ« plugin, dhe pastaj ndoshta ta pĂ«rfshini nĂ« upstream.
Helm mbështetet në tri koncepte kryesore:
- Chart Repo â pĂ«rshkrimi dhe njĂ« grup parametrash, tĂ« mundshĂ«m pĂ«r manifestin tuaj.Â
- Konfigurimi â dmth, vlerat qĂ« do tĂ« aplikohen (teksti, vlera numerike etj.).
- Release përfshin dy komponentët e sipërm, dhe së bashku ata shndërrohen në Release. Rrelease-t mund të versionohen, duke arritur kështu organizimin e ciklit të jetës: i vogël në momentin e instalimit dhe i madh në momentin e upgrade, downgrade ose rollback.
Arkitektura e Helm
Në diagram tregohet konceptualisht arkitektura e nivelit të lartë të Helm.
Të kujtojmë se Helm është diçka që lidhet me Kubernetes. Prandaj, ne nuk mund të shkojmë pa një klaster Kubernetes (drejtkëndësh). Komponenti kube-apiserver është në master. Pa Helm, kemi Kubeconfig. Helm sjell një utilitar të vogël binar, nëse mund ta quajmë kështu, Helm CLI, e cila instalohet në kompjuter, laptop, mainframe - në gjithçka.
Por kjo nuk është e mjaftueshme. Helm ka një komponent serveri Tiller. Ai përfaqëson interesat e Helm brenda klasterit, është një aplikacion i tillë brenda klasterit Kubernetes, si çdo aplikacion tjetër.
Komponenti tjetër është Chart Repo - një depo me chart-e. Ka një depo zyrtare dhe mund të ketë një depo private të kompanisë ose projektit.
Ndërveprimi
Le të shqyrtojmë se si ndërveprojnë komponentët e arkitekturës kur duam të instalojmë një aplikacion me Helm.
- Ne themi
Helm install, i drejtohemi depozitës (Chart Repo) dhe marrim Helm-chart-in.
- Utilitari Helm (Helm CLI) ndĂ«rvepron me Kubeconfig, pĂ«r tĂ« zbuluar se cili klaster duhet tĂ« kontaktohet.Â
- Pas marrjes sĂ« kĂ«saj informacioni, utilitari i drejtohet Tiller, i cili ndodhet nĂ« klasterin tonĂ«, si njĂ« aplikacion.Â
- Tiller i drejtohet Kube-apiserver për të kryer veprime në Kubernetes, për të krijuar disa objekte (shërbime, pod, riprodhime, sekrete etj.).
Më pas ne do ta komplikohem skemën për të parë vektorin e sulmeve, të cilit mund t'i përballohet e gjithë arkitektura e Helm në përgjithësi. E në fund do të përpiqemi ta mbrojmë.
Vektori i sulmeve
Pika e parĂ« potencialisht e dobĂ«t â API i privilegjuarâpĂ«rdorues. NĂ« kuadĂ«r tĂ« skemĂ«s ky Ă«shtĂ« njĂ« hakues i cili ka marrĂ« qasje administrative nĂ« Helm CLI.
Një përdorues i API-së jo të privilegjuar mund gjithashtu të përbëjë rrezik, nëse ndodhet diku afër. Ky përdorues do të ketë një kontekst tjetër, për shembull, ai mund të jetë i regjistruar në një namespace të clustrit në konfigurimet Kubeconfig.
Vektori më interesant i sulmit mund të jetë procesi që ndodhet brenda clustrit diku afër Tiller dhe mund t'i drejtohet atij. Kjo mund të jetë një server uebi ose një mikroshërbim që sheh ambientin rrjet të clustrit.
Një variant eksotik, por në rritje të popullaritetit, i sulmeve lidhet me Chart Repo. Chart-i i krijuar nga një autor të keq është mund të përmbajë burime të pa sigurta, dhe ju do ta ekzekutoni atë, duke e pranuar për të vërtetë. Ose ai mund të zëvendësojë chart-in që shkarkoni nga depoja zyrtare dhe, për shembull, të krijojë burime në formë politikash dhe të eskaloni aksesin tuaj.
Të përpiqemi të mbrohemi nga këto katër anë të sulmeve dhe të kuptojmë, ku janë problemet në arkitekturën Helm, dhe ku ndoshta nuk ka asnjë.
Të zgjerim skemën, të shtojmë më shumë elementë, por të ruajmë të gjitha përbërësit bazë.
Helm CLI komunikon me Chart Repo, interakton me Kubeconfig, puna dërgohet në klaster në komponentin Tiller.
Tiller paraqitet me dy objekte:
- Shërbimi Tiller-deploy, që ofron njëfarë shërbimi;
- Pod-i Tiller-deploy (në skemë si një kopje në një replikë), mbi të cilin funksionon të gjithë ngarkesa, që i drejtohet klasterit.
Për ndërlidhje përdoren protokolle dhe skema të ndryshme. Nga pikëpamja e sigurisë, ne jemi më shumë të interesuar për:
- Mekanizmi me të cilin Helm CLI i drejtohet chart repo: cili protokoll, a ka autentifikim dhe çfarë mund të bëhet me këtë.
- Protokolli me të cilin Helm CLI komunikon me Tiller duke përdorur kubectl. Ky është një server RPC i instaluar brenda klasterit.
- Tiller vetë është në dispozicion për mikroshërbimet që ndodhen në klaster dhe ndërvepron me Kube-apiserver.
Le të diskutojmë të gjitha këto drejtime rend pas rendit.
RBAC
ĂshtĂ« e panevojshme tĂ« flasim pĂ«r ndonjĂ« siguri tĂ« Helm ose shĂ«rbimit tjetĂ«r brenda klasterit nĂ«se RBAC nuk Ă«shtĂ« aktivizuar.
Duket se kjo nuk është rekomandimi më i ri, por jam i sigurt që ende shumë nuk e kanë aktivizuar RBAC as në prodhim, sepse është një punë e madhe dhe kërkon shumë konfigurime. Megjithatë, ju inkurajoj ta bëni këtë.
â njĂ« faqe avokate pĂ«r RBAC. Aty Ă«shtĂ« mbledhur njĂ« sasi e madhe materialesh interesante qĂ« do t'ju ndihmojnĂ« tĂ« konfiguroni RBAC, do tĂ« tregojnĂ« pse Ă«shtĂ« i mirĂ« dhe si tĂ« jetoni me tĂ« nĂ« prodhim.
Do të përpiqem të shpjegoj si funksionon Tiller dhe RBAC. Tiller punon brenda klasterit nën një llogari shërbimi. Për zakon, nëse RBAC nuk është i konfiguruar, ky do të jetë superpërdoruesi. Në konfigurimin themelor, Tiller do të jetë admin. Kjo është arsyeja pse shpesh thuhet se Tiller është një tunel SSH për klasterin tuaj. Në të vërtetë, kjo është e vërtetë, prandaj mund të përdorni një llogari shërbimi të specializuar të veçantë në vend të Llogarisë Shërbimi Default në skemën më sipër.
Kur e inicializoni Helm, kur e instaloni për herë të parë në server, mund të specifikoni llogarinë e shërbimit me --service-account. Kjo do të mundësojë përdorimin e një përdoruesi me grupin minimal të të drejtave të nevojshme. Megjithatë, do të duhet të krijoni një "garlandë": Role dhe RoleBinding.
Fatkeqësisht, Helm nuk e bëni këtë për ju. Ju ose administratori i klasterit tuaj Kubernetes duhet të përgatisin paraprakisht një grup Role, RoleBinding për llogarinë e shërbimit, për t'ja kaluar Helm.
Shfaqet njĂ« pyetje â cili Ă«shtĂ« dallimi midis Role dhe ClusterRole? Dallimi Ă«shtĂ« se ClusterRole vepron pĂ«r tĂ« gjithĂ« namespaces, nĂ« kundĂ«rshtim me Rollat e zakonshme dhe RoleBinding, tĂ« cilat funksionojnĂ« vetĂ«m pĂ«r njĂ« namespace specifik. Mund tĂ« konfiguroni politika pĂ«r tĂ« gjithĂ« klasterin dhe tĂ« gjithĂ« namespaces, si dhe nĂ« mĂ«nyrĂ« tĂ« personalizuar pĂ«r secilin namespace veçmas.
Duhet tĂ« theksohet se RBAC zgjidh njĂ« tjetĂ«r problem tĂ« madh. ShumĂ« ankojnĂ« se Helm, fatkeqĂ«sisht, nuk Ă«shtĂ« multitenancy (nuk mbĂ«shtet shumĂ«qenĂ«si). NĂ«se disa ekipe pĂ«rdorin klasterin dhe pĂ«rdorin Helm, nĂ« thelb Ă«shtĂ« e pamundur tĂ« konfiguroni politika dhe tĂ« kufizoni qasje brenda kĂ«tij klasteri, sepse ka njĂ« llogari shĂ«rbimi, nga e cila funksionon Helm, dhe ai krijon tĂ« gjithĂ« burimet nĂ« klaster nga ajo llogari, qĂ« ndonjĂ«herĂ« Ă«shtĂ« shumĂ« e papĂ«rshtatshme. Kjo Ă«shtĂ« e vĂ«rtetĂ« â si vetĂ« skedari binar, si proces, Helm Tiller nuk ka njohuri pĂ«r multitenancy.
Megjithatë, ka një mënyrë të shkëlqyer për të ekzekutuar Tiller disa herë në një klaster. Nuk ka asnjë problem me këtë; Tiller mund të ekzekutohet në çdo hapësirë emërtimi. Kështu, mund të shfrytëzoni RBAC, Kubeconfig si kontekst dhe të kufizoni aksesin në Helm të veçantë.
Kjo do të duket si më poshtë.
Për shembull, ka dy Kubeconfig me kontekst për ekipe të ndryshme (dy hapa emërtimi): Ekipi X për ekipin e zhvilluesve dhe klasteri i administratorit. Klasteri i administratorit ka Tiller të gjerë, i cili ndodhet në hapësirën e emërtimit kube-system, përkatësisht me një llogari shërbimi të avancuar. Dhe një hapësirë e veçantë për ekipin e zhvilluesve, ata do të jenë në gjendje të implementojnë shërbimet e tyre në një hapësirë të veçantë.
Ky është një qasje funksionale; Tiller nuk është aq i uritur sa të ndikojë dukshëm në buxhetin tuaj. Ky është një nga zgjidhjet e shpejta.
Mos hezitoni të konfiguroni veçmas Tiller dhe të ofroni Kubeconfig me kontekst për ekipin, për një zhvillues të caktuar ose për mjedisin: Dev, Staging, Produktion (është e dyshimtë që gjithçka do të ishte në të njëjtin klaster, megjithatë, kështu mund të bëhet).
Duke vazhduar historinë tonë, do të kalojmë nga RBAC në ConfigMaps.
ConfigMaps
Helm përdor ConfigMaps si një ruajtës të të dhënave. Kur folëm për arkitekturën, nuk kishte asnjë databazë në të cilën ruhej informacioni mbi lëshimet, konfigurimet, rikthimet dhe të tjerë. Për këtë përdoren ConfigMaps.
Problemi kryesor me ConfigMaps është i njohur - ato nuk janë të sigurta në parim, ato nuk mund të ruajnë të dhëna sensitive. Kjo ka të bëjë me gjithçka që nuk duhet të kalojë jashtë shërbimit, si për shembull fjalëkalimet. Një mënyrë më natyrale për Helm tani është kalimi nga përdorimi i ConfigMaps në sekrete.
Kjo bëhet shumë lehtë. E rinovoni konfigurimin e Tiller dhe tregoni se ruajtësi do të jenë sekretet. Atëherë për çdo implementim do të merrni jo një ConfigMap, por një sekret.
Mund të kundërshtoni se sekretet vetë janë një koncept i çuditshëm dhe kjo nuk është shumë e sigurt. Megjithatë, duhet të kuptohet se kjo merret nga zhvilluesit e Kubernetes. Duke filluar nga versioni 1.10, dmth. qysh herët, ka mundësi, të paktën në re publike, të lidhni ruajtjen e duhur për mbajtjen e sekretëve. Tani ekipi po punon për të shpërndarë më mirë aksesin në sekretet, për pods të veçanta ose entitete të tjera.
Storage Helm është më mirë të transferohet në sekretet, dhe për këtë arsye të sigurohen në mënyrë qendrore.
Sigurisht, do të mbetet një kufizim për ruajtjen e të dhënave prej 1 Mbyte.. Helm gjithashtu përdor etcd si një depo të shpërndarë për ConfigMaps. Atje e konsideruan këtë një grup të përshtatshëm të dhënash për replikime etj. Në lidhje me këtë, ka një diskutim interesant në Reddit, e rekomandoj ta gjeni atë si një lexim argëtues për fundjavë ose të lexoni përmbledhjen. .
Chart Repos
Chart-et janë më të prekshëm socialisht dhe mund të bëhen burim i "Man in the middle", veçanërisht nëse përdorni një zgjidhje pa pagesë. Kryesisht, kjo i referohet depozitave që janë të ekspozuara përmes HTTP.
Padyshim, duhet tĂ« ekspozoni Helm Repo pĂ«rmes HTTPS â kjo Ă«shtĂ« zgjidhja mĂ« e mirĂ« dhe nuk kushton shumĂ«.
Vini re mekanizmi i nĂ«nshkrimeve tĂ« chart-eve. Teknologjia Ă«shtĂ« shumĂ« e thjeshtĂ«. ĂshtĂ« e njĂ«jta gjĂ« qĂ« pĂ«rdorni nĂ« GitHub, njĂ« makineri standarde PGP me çelĂ«sa publikĂ« dhe privatĂ«. CilĂ«soni dhe do tĂ« jeni tĂ« sigurt, duke pasur çelĂ«sat e nevojshĂ«m dhe duke nĂ«nshkruar gjithçka qĂ« Ă«shtĂ« vĂ«rtet chart-i juaj.
PĂ«r mĂ« tepĂ«r, Klienti i Helm mbĂ«shtet TLS. (nĂ« kuptimin e HTTP nga serveri, por TLS i ndĂ«rsjellĂ«). Mund tĂ« pĂ«rdorni çelĂ«sa serveri dhe klienti pĂ«r tĂ« komunikuar. TĂ« them tĂ« drejtĂ«n, unĂ« nuk pĂ«rdor njĂ« mekanizĂ«m tĂ« tillĂ« pĂ«r shkak tĂ« mosdashjes pĂ«r certifikatat e ndĂ«rsjella. NĂ« thelb, â mjeti kryesor pĂ«r shpĂ«rndarjen e Helm Repo pĂ«r Helm 2 â gjithashtu mbĂ«shtet autentifikimin bazik. Mund tĂ« pĂ«rdorni autentifikimin bazik, nĂ«se Ă«shtĂ« mĂ« e lehtĂ« dhe mĂ« e qetĂ«.
Ka gjithashtu një plugin , i cili lejon vendosjen e Chart Repos në Google Cloud Storage. Kjo është mjaft e përshtatshme, funksionon shkëlqyer dhe është mjaft e sigurt, sepse përdoren të gjitha mekanizmat e përshkruar.
Nëse aktivizoni HTTPS ose TLS, përdorni mTLS, aktivizoni autentifikimin bazik për të ulur më shumë rreziqet, do të krijoni një kanal të sigurt komunikimi midis Helm CLI dhe Chart Repo.
gRPC API
Hapi pasues Ă«shtĂ« shumĂ« i rĂ«ndĂ«sishĂ«m â siguroni Tiller, i cili ndodhet nĂ« klaster dhe Ă«shtĂ«, nga njĂ«ra anĂ«, serveri, ndĂ«rsa nga ana tjetĂ«r â ai vetĂ« lidhet me komponentĂ« tĂ« tjerĂ« dhe pĂ«rpiqet tĂ« duket si dikush tjetĂ«r.
Siç e thashë, Tiller është një shërbim që ekspozon gRPC, klienti Helm lidhjet me të përmes gRPC. Me default, natyrshëm, TLS është i çaktivizuar. Pse është bërë kjo është një çështje diskutimi, më duket se është për të thjeshtuar konfigurimin në fillim.
Për production dhe madje edhe për staging, rekomandoj që të aktivizoni TLS për gRPC.
NĂ« mendimin tim, nĂ« krahasim me mTLS pĂ«r chartet, kĂ«tu Ă«shtĂ« e arsyeshme dhe bĂ«het shumĂ« lehtĂ«sisht â gjeneroni infrastrukturĂ«n PQI, krijoni njĂ« certificat, aktivizoni Tiller, dhe kaloni certificatĂ«n gjatĂ« inicializimit. Pas kĂ«saj, mund tĂ« ekzekutoni tĂ« gjitha komandat Helm, duke u identifikuar me certifikatĂ«n e gjeneruar dhe çelĂ«sin privat.
Kështu, do të mbroheni nga të gjitha kërkesat ndaj Tiller nga jashtë klasterit.
Prandaj, ne kemi siguruar kanal lidhjeje me Tiller, kemi diskutuar RBAC dhe rregulluar të drejtat e Kubernetes apiserver, kemi reduktuar domenin me të cilin ai mund të bashkëveprojë.
Helm i mbrojtur
Le të shohim skemën përfundimtare. Kjo është e njëjta arkitekturë me të njëjtat shigjeta.
Të gjitha lidhjet tani mund të vizatohen me të gjelbër:
- për Chart Repo përdorim TLS ose mTLS dhe basic auth;
- mTLS për Tiller, dhe ai është ekspozuar si shërbim gRPC me TLS, përdorim certifikatat;
- nĂ« klaster pĂ«rdoret njĂ« llogari shĂ«rbimi speciale me Role dhe RoleBinding.Â
Ne e kemi siguruar dukshëm klasterin, por dikush i zgjuar tha:
«Zgjidhja plotĂ«sisht e sigurt mund tĂ« jetĂ« vetĂ«m njĂ« â njĂ« kompjuter i fikur, i cili ndodhet nĂ« njĂ« kuti betoni dhe e mbajnĂ« ushtarĂ«t».
Ka mënyra të ndryshme për të manipuluar të dhënat dhe për të gjetur vektorë të rinj sulmesh. Megjithatë, unë jam i sigurt se këto rekomandime do të lejojnë implementimin e një standardi themelor të sigurisë industriale.
Bonus
Kjo pjesĂ« nuk i pĂ«rket drejtpĂ«rdrejt sigurisĂ«, por do tĂ« jetĂ« gjithashtu e dobishme. Do tĂ« tregoj disa gjĂ«ra interesante, pĂ«r tĂ« cilat shumĂ« pak njerĂ«z dinĂ«. PĂ«r shembull, si tĂ« kĂ«rkoni chartet â zyrtare dhe jozyrtare.
NĂ« repositor aktualisht ka rreth 300 chart dhe dy rrjedha: stable dhe incubator. Ai qĂ« kontribuon e di mirĂ« se sa e vĂ«shtirĂ« Ă«shtĂ« tĂ« kalosh nga incubator nĂ« stable, dhe sa e lehtĂ« Ă«shtĂ« tĂ« dalĂ«sh nga stable. MegjithatĂ«, ky nuk Ă«shtĂ« strumenti mĂ« i mirĂ« pĂ«r tĂ« kĂ«rkuar chartet pĂ«r Prometheus dhe gjithçka tjetĂ«r qĂ« ju pĂ«lqen, pĂ«r njĂ« arsye tĂ« thjeshtĂ« â nuk Ă«shtĂ« njĂ« portal ku Ă«shtĂ« e lehtĂ« tĂ« kĂ«rkosh paketa.
Por ka një shërbim , me të cilin është shumë më e lehtë të gjeni chart-et. Më e rëndësishmja, atje ka shumë më tepër depo të jashtme dhe janë në dispozicion gati 800 chart-e. Për më tepër, ju mund të lidhni depo tuaj nëse për ndonjë arsye nuk dëshironi të dërgoni chart-et tuaja në stable.
Provoni hub.helm.sh dhe le të zhvillojmë atë së bashku. Ky shërbim është nën projektin Helm, dhe ju mund të kontribuoni madje edhe në UI-në e tij, nëse jeni frontend developer dhe dëshironi thjesht të përmirësoni pamjen.
Dua gjithashtu të tërheq vëmendjen tuaj për integrimin e Open Service Broker API. Më duket e madhe dhe e paqartë, por zgjidh probleme që të gjithë përballen me to. Do ta shpjegoj me një shembull të thjeshtë.
Ka njĂ« Kubernetes cluster, nĂ« tĂ« cilin duam tĂ« ekzekutojmĂ« njĂ« aplikacion klasik â WordPress. NĂ« pĂ«rgjithĂ«si, pĂ«r funksionalitetin e plote nevojitet njĂ« bazĂ« tĂ« dhĂ«nash. Ka shumĂ« zgjidhje tĂ« ndryshme, pĂ«r shembull, mund tĂ« nisni shĂ«rbimin tuaj statefull. Kjo nuk Ă«shtĂ« shumĂ« e pĂ«rshtatshme, por shumĂ« njerĂ«z e bĂ«jnĂ« kĂ«tĂ«.
Të tjerët, si ne në Chainstack, përdorin baza të dhënash të menaxhuara, si MySQL ose PostgreSQL, për serverët. Prandaj, baza e të dhënave tonë ndodhet diku në re.
Por megjithatĂ«, ka njĂ« problem: duhet tĂ« lidhim shĂ«rbimin tonĂ« me bazĂ«n e tĂ« dhĂ«nave, tĂ« krijojmĂ« njĂ« lloj baze tĂ« dhĂ«nash, tĂ« dĂ«rgojmĂ« akreditimin dhe ndonjĂ« mĂ«nyrĂ« pĂ«r ta menaxhuar atĂ«. TĂ« gjitha kĂ«to zakonisht bĂ«hen manualisht nga administratori i sistemit ose zhvilluesi. Nuk ka asnjĂ« problem kur ka pak aplikacione. Kur ka shumĂ«, nevojitet njĂ« kombinator. NjĂ« i tillĂ« ekziston â Ă«shtĂ« Service Broker. Ai lejon pĂ«rdorimin e njĂ« plugin-i tĂ« veçantĂ« nĂ« klustĂ«rin e cloud publik dhe porosit burime nga ofruesi pĂ«rmes Broker-it, sikur tĂ« ishte njĂ« API. PĂ«r kĂ«tĂ« mund tĂ« pĂ«rdoren mjetet native tĂ« Kubernetes.
Kjo është shumë e thjeshtë. Mund të kërkoni, për shembull, Managed MySQL në Azure me nivelin bazë (kjo mund të konfigurohet). Duke përdorur API-në e Azure, baza do të krijohet dhe përgatitet për përdorim. Ju nuk do të duhet të ndërhyrni në këtë, pasi plugin-i është përgjegjës për këtë. Për shembull, OSBA (plugin-i i Azure) do të kthejë akreditimin në shërbim dhe do ta dërgojë këtë në Helm. Ju do të jeni në gjendje të përdorni WordPress me MySQL në cloud, pa u marrë fare me bazat e dhënave të menaxhuara dhe pa u shqetësuar për shërbimet stateful brenda.
Mund tĂ« thuhet se Helm Ă«shtĂ« ngjitĂ«si qĂ«, nga njĂ«ra anĂ« lejon tĂ« instalosh shĂ«rbime, dhe nga ana tjetĂ«r â tĂ« konsumosh burime nga ofruesit e cloud.
Mund të shkruani një plug-in tuaj dhe të përdorni të gjithë këtë histori on-premise. Atëherë do të keni thjesht një plug-in për ofruesin tuaj të Cloud-it korporativ. Ju rekomandoj të provoni këtë qasje, veçanërisht nëse keni një shkallë të madhe dhe dëshironi të zhvilloni shpejt dev, staging, ose gjithë infrastrukturën për një veçori. Kjo do ta thjeshtojë jetën për operacionet tuaja ose DevOps.
NjĂ« gjetje tjetĂ«r qĂ« e kam pĂ«rmendur tashmĂ« â Ă«shtĂ« plug-in helm-gcs, i cili lejon pĂ«rdorimin e Google-buckets (ruajtje objektuale) pĂ«r tĂ« ruajtur Helm-chart-et.
Kërkohen vetëm katër komanda për ta filluar përdorimin e tij:
- instaloni plug-in-in;
- init-ni atë;
- caktoni rrugën drejt bucket-it, i cili gjendet në gcp;
- publikoni chart-et në mënyrë standarde.
Bukuria Ă«shtĂ« se do tĂ« pĂ«rdoret mĂ«nyra native e gcp pĂ«r autorizimin. Mund tĂ« pĂ«rdorni njĂ« llogari shĂ«rbimi, llogarinĂ« e zhvilluesit â gjithçka qĂ« dĂ«shironi. Kjo Ă«shtĂ« shumĂ« e pĂ«rshtatshme dhe asgjĂ« nuk kushton nĂ« operim. NĂ«se ju, si unĂ«, propagoni filozofinĂ« opsless, atĂ«herĂ« kjo do tĂ« jetĂ« shumĂ« e dobishme, veçanĂ«risht pĂ«r ekipe tĂ« vogla.
Alternativat
Helm â nuk Ă«sht njĂ« zgjidhje e vetme pĂ«r menaxhimin e shĂ«rbimeve. Ka shumĂ« pyetje rreth tij, ndoshta pĂ«r kĂ«tĂ« arsye u shfaq kaq shpejt versioni i tretĂ«. PatjetĂ«r, ka alternativa.
Këto mund të jenë si zgjidhje të specializuara, siç janë Ksonnet ose Metaparticle. Mund të përdorni mjete klasike për menaxhimin e infrastrukturës (Ansible, Terraform, Chef etj.) për qëllime të njëjta, për të cilat kam folur.
Më në fund, ka një zgjidhje , popullariteti i së cilës po rritet.
Operator Framework â alternativa kryesore ndaj Helm, pĂ«r tĂ« cilĂ«n duhet tĂ« kushtoni vĂ«mendje.
Ajo është më natyrale për CNCF dhe Kubernetes, por pragu i hyrjes është shumë më i lartë, kërkon më shumë programim dhe më pak përshkrim të manifestëve.
Ka ndryshme addons, siç janĂ« Draft, Scaffold. Ato e lehtĂ«sojnĂ« shumĂ« jetĂ«n, pĂ«r shembull, zhvilluesit e kanĂ« lehtĂ«suar ciklin e dĂ«rgimit dhe ekzekutimit tĂ« Helm pĂ«r vendosjen e njĂ« ambienti testimi. Do tĂ« doja tâi quaja ato zgjerues tĂ« mundĂ«sive.
Këtu është një grafik shpjegues që tregon se ku ndodhet çdo gjë.
NĂ« aksin horizontal, niveli juaj i kontrollit mbi ndodhitĂ« Ă«shtĂ« i shfaqur, ndĂ«rsa nĂ« aksin vertikal â niveli i natyrshmĂ«risĂ« sĂ« Kubernetes. Helm versioni 2 ndodhet diku nĂ« mes. NĂ« versionin 3, nuk ka ndryshime shumĂ« tĂ« mĂ«dha, por kontrolli dhe niveli i natyrshmĂ«risĂ« janĂ« pĂ«rmirĂ«suar. Zgjidhjet e nivelit Ksonnet megjithatĂ« nuk i qĂ«ndrojnĂ« dot edhe Helm 2. MegjithatĂ«, ia vlen t'i shqyrtoni ato pĂ«r tĂ« ditur çfarĂ« tjetĂ«r ekziston nĂ« kĂ«tĂ« botĂ«. Sigurisht, menaxheri juaj i konfigurimeve do tĂ« jetĂ« nĂ«n kontrollin tuaj, por Ă«shtĂ« krejtĂ«sisht i huaj pĂ«r Kubernetes.
Operator Framework është krejtësisht i natyrshëm për Kubernetes dhe lejon menaxhimin e tij në një mënyrë shumë më elegante dhe të kujdesshme (por kujtoni nivelin e hyrjes). Më mirë do t'i përshtatej një aplikacioni të specializuar dhe krijimit të menaxhimit për të, sesa si një kombinator masiv që paketonte shumë aplikacione me ndihmën e Helm.
Zgjeruesit thjesht përmirësojnë pak kontrollin, plotësojnë procesin e punës ose i prerë këndet e pipeline-ve CI/CD.
E ardhmja e Helm
Lajmi i mirë është se po del Helm 3. Versioni alfa i Helm 3.0.0-alpha.2 ka dalë, mund ta provoni. Ai është mjaft stabil, por funksionaliteti është ende i kufizuar.
Pse nevojitet Helm 3? Në radhë të parë, kjo është një histori mbi shkëputjen e Tiller, si komponentë. Kjo, siç e kuptoni, është një hap i madh përpara, sepse nga pikëpamja e sigurisë së arkitekturës, gjithçka thjeshtohet.
Kur u krijua Helm 2, dhe kjo ndodhi në kohën e Kubernetes 1.8 ose edhe më herët, shumë koncepte flisnin pa përvojë. Për shembull, koncepti i CRD tani po implementohet aktivisht, dhe Helm do të përdorë CRD, për të ruajtur strukturat. Do të bëhet e mundur të përdoret vetëm klienti dhe të mos mbahet pjesa serverike. Prandaj, të përdoren komandat natyrore të Kubernetes për të punuar me strukturat dhe burimet. Ky është një hap i madh përpara.
Do të shfaqet mbështetje për depozitat natyrore OCI (Open Container Initiative). Kjo është një iniciativë e madhe, dhe Helm jep një interes të veçantë për të vendosur diagramet e tij. Arrin deri aty, sa për shembull, Docker Hub mbështet shumë standarde OCI. Nuk po e parashikoj, por ndoshta, ofruesit klasikë të depozitave Docker do të fillojnë të ofrojnë mundësinë e vendosjes së diagramëve tuaj Helm.
NjĂ« histori e debatueshme pĂ«r mua Ă«shtĂ« mbĂ«shtetje pĂ«r Lua., si siht ijtur qĂ« Ă«shtĂ« engine i templating pĂ«r tĂ« shkruar skriptet. Nuk jam njĂ« adhurues i madh i Lua, por kjo do tĂ« jetĂ« njĂ« mundĂ«si plotĂ«sisht opsionale. E kam verifikuar tri herĂ« â pĂ«rdorimi i Lua nuk do tĂ« jetĂ« i detyrueshĂ«m. Prandaj, ai qĂ« dĂ«shiron tĂ« pĂ«rdorĂ« Lua, ai qĂ« pĂ«lqen Go â bashkoni me kampin tonĂ« tĂ« madh dhe pĂ«rdorni go-tmpl pĂ«r kĂ«tĂ«.
Më në fund, ajo që më ka munguar me siguri është shfaqja e skemës dhe validimi i llojeve të dhënave. Nuk do të ketë më probleme me int apo string, s'ka nevojë të mbështjellësh zero-n në dy thonjza. Do të ketë një skemë JSONS që do të lejojë ta përshkruash këtë qartë për values.
Do të rikonstruktohet shumë modeli i drejtuar nga ngjarjet. Ajo tashmë është përshkruar konceptualisht. Shikoni në degën Helm 3, dhe do të shihni sa shumë janë shtuar ngjarje dhe hooks dhe gjithçka tjetër, që do ta thjeshtojë dhe, në anën tjetër, do të shtojë kontroll mbi proceset e deploy-it dhe reagimeve ndaj tyre.
Helm 3 do të jetë më i thjeshtë, më i sigurt dhe më interesante jo për shkak se nuk e duam Helm 2, por sepse Kubernetes po bëhet më i përparuar. Si rezultat, Helm mund të përdorë avancimet e Kubernetes dhe të krijojë menaxherë të shkëlqyer për Kubernetes.
Një lajm tjetër i mirë është se Aleksandër Khayërov do të flasë, Kujtojmë, konferenca për integrimin e proceseve të zhvillimit, testimit dhe operacioneve do të zhvillohet në Moskë më 30 Shtator dhe 1 Tetor. Deri më 20 Gusht akoma mund dhe të flisni për përvojën tuaj në zgjidhjen sfidave të qasjes DevOps.
Për njoftime dhe lajme rreth konferencës ndiqni në dhe .
Burimi: habr.com
