The essence of the story about the most popular package manager for Kubernetes could be depicted with emojis:
- a box â that's Helm (the most fitting representation in the latest Emoji release);
- a lock â security;
- a little person â solution to the problem.
In reality, however, it will be a bit more complicated, and the story is full of technical details on how to make Helm secure..
- Briefly, what is Helm, if you didn't know or forgot. What problems does it solve and where does it fit in the ecosystem.
- Let's look at the architecture of Helm. No discussion about security and how to make a tool or solution more secure can be without understanding the architecture of the component.
- Let's discuss the components of Helm.
- The most pressing question â the future â the new version of Helm 3.Â
Everything in this article pertains to Helm 2. This version is currently in production and is likely the one you are using now, and it contains security threats.
PĂ«r folĂ«sin: Alexander Khayev () has been developing for 10 years, helping to improve content and joined the committee . He currently works at Chainstack as a development lead â a hybrid role between a development manager and someone responsible for delivering final releases. This means he is right in the field, where everything happens from product creation to operation.
Chainstack is a small, rapidly growing startup with the mission to allow clients to forget about infrastructure and the complexities of operating decentralized applications. The development team is based in Singapore. Donât ask Chainstack to sell or buy cryptocurrency, but suggest discussing enterprise blockchain frameworks, and they'll gladly respond.
Helm
It is a package manager (charts) for Kubernetes. The clearest and most universal way to bring applications into a Kubernetes cluster.
This is, of course, about a more structured and industrial approach than creating your own YAML manifests and writing small utilities.
Helm is the best that is currently available and popular.
Why Helm? Primarily because it is backed by CNCF. Cloud Native is a large organization that is the parent company for Kubernetes projects, etcd, Fluentd, and others.
Fakti tjetër i rëndësishëm është se Helm është një projekt shumë popullor. Kur në janar 2019 unë fillova të mendoja se si ta bëja Helm të sigurt, projekti kishte një mijë yje në GitHub. Deri në maj, numri i tyre ishte rritur në 12 mijë.
Shumë njerëz janë të interesuar për Helm, prandaj, edhe nëse ende nuk e përdorni, njohuritë mbi sigurinë e tij do t'ju vijnë në ndihmë. Siguria është e rëndësishme.
Ekipi kryesor i Helm mbështetet nga Microsoft Azure, dhe prandaj ky është një projekt relativisht 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ë mbi projektin dhe se ata kanë dëshirë dhe energji për ta zhvilluar dhe përmirësuar Helm.
Helm zgjidh disa probleme themelore në menaxhimin e aplikacioneve në Kubernetes.
- Packaging i aplikacioneve. Edhe një aplikacion si "Hello, World" në WordPress përfaqëson disa shërbime, dhe dëshirohet që ato të paketohen së bashku.
- Menaxhimi i kompleksitetit që lind në menaxhimin e këtyre aplikacioneve.
- Jeta e një aplikacioni nuk përfundon pas instalimit ose publikimit të tij. Ai vazhdon të jetojë, duhet të përditësohet, dhe Helm ndihmon në këtë duke ofruar masat dhe politikat e duhura.
Packaging është organizuar në një mënyrë të kuptueshme: ka metadëta që i përputhen plotësisht funksionimit të menaxherëve të zakonshëm të pakove për Linux, Windows ose MacOS. Kështu, ka një depo, varësi nga paketa të ndryshme, metainformacione për aplikacionet, konfigurime, veçori të konfigurimeve, indekse informacioni, etj. Të gjitha këto Helm i lejon të merren dhe përdoren për aplikacione.
Menaxhimi i kompleksitetit. Nëse keni shumë aplikacione të ngjashme, do të nevojitet parametrizimi. Këtu dalin modelet, por për të mos shpikur një mënyrë tuaj për të krijuar modele, mund të përdorni atë që Helm ofron nga kutia.
Menaxhimi i ciklit tĂ« jetĂ«s sĂ« aplikacionit â sipas mendimit tim, Ă«shtĂ« pyetja mĂ« interesante dhe e pazgjidhur. Kjo Ă«shtĂ« arsyeja pse nĂ« atĂ« kohĂ« unĂ« i kam ardhur Helm. Na nevojitej tĂ« monitoronim ciklin e jetĂ«s sĂ« aplikacionit, dĂ«shironim tĂ« transferonim CI/CD dhe ciklet e aplikacioneve nĂ« kĂ«tĂ« paradigmĂ«.
Helm lejon:
- të menaxhojë publikimet, introdukton konceptin e konfigurimit dhe rishikimeve;
- të realizojë rikthime me sukses;
- të përdorë pika të ndryshme në ngjarje të ndryshme;
- të shtojë kontroll të mëtejshëm për aplikacionet dhe të reagojë ndaj rezultateve të tyre.
PĂ«r mĂ« tepĂ«r Helm ka «bateritë» â njĂ« sasi e madhe gjĂ«rash tĂ« shijshme qĂ« mund tĂ« pĂ«rfshihen si plugina, duke e bĂ«rĂ« jetĂ«n tuaj mĂ« tĂ« thjeshtĂ«. Pluginat mund tĂ« shkruhen vetĂ«, ato janĂ« tĂ« izoluara mjaftueshĂ«m dhe nuk kĂ«rkojnĂ« njĂ« arkitekturĂ« tĂ« ndĂ«rlikuar. NĂ«se dĂ«shironi tĂ« realizoni diçka, ju rekomandoj ta bĂ«ni si njĂ« plugin dhe pastaj ndoshta ta pĂ«rfshini nĂ« upstream.
Helm mbështetet në tre koncepte kryesore:
- Chart Repo â pĂ«rshkrimi dhe njĂ« masĂ« parametrizimi, e mundshme pĂ«r manifestin tuaj.Â
- Konfigurimi â domethĂ«nĂ« vlerat qĂ« do tĂ« aplikohen (tekst, vlera numerike dhe tĂ« tjera).
- Release përmbledh 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: të vogla në momentin e instalimit dhe të mëdha në momentin e upgrade, downgrade apo rollback.
Arkitektura e Helm
Në diagramin konceptual është reflektuar arkitektura e nivelit të lartë të Helm.
MĂ« kujtohet qĂ« Helm â Ă«shtĂ« diçka qĂ« lidhet me Kubernetes. Prandaj nuk mund tĂ« anashkalojmĂ« njĂ« klaster Kubernetes (drejtkĂ«ndĂ«shi). komponenti kube-apiserver ndodhet te masteri. Pa Helm kemi Kubeconfig. Helm sjell njĂ« utilitet tĂ« vogĂ«l binar, nĂ«se mund ta quajmĂ« ashtu, Helm CLI, i cili instalohet nĂ« kompjuter, laptop, mainframe â nĂ« çdo gjĂ«.
Por kjo nuk është e mjaftueshme. Helm ka një komponent server 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 Chart Repo â Ă«shtĂ« njĂ« repository me chart-e. Ka njĂ« repository zyrtar, dhe mund tĂ« ketĂ« njĂ« repository privat tĂ« kompanisĂ« ose projektit.
Ndërveprimi
Të shohim si interaktojnë komponentët e arkitekturës kur duam të instalojmë një aplikacion me anë të Helm.
- Ne themi
Helm install, i drejtohemi repository-t (Chart Repo) dhe marrim Helm chart-in.
- Utilitari Helm (Helm CLI) ndĂ«rvepron me Kubeconfig, pĂ«r tĂ« gjetur se cilit klaster t'i drejtohet.Â
- Pas marrjes sĂ« kĂ«tyre informacionit, utilitari i drejtohet Tiller, i cili ndodhet nĂ« klasterin tonĂ«, si njĂ« aplikacion.Â
- Tiller i drejtohet Kube-apiserver, për të realizuar veprime në Kubernetes, për të krijuar disa objekte (shërbime, pod-e, replika, sekrete etj.).
Më pas do ta komplikohemi diagramin, për të parë vektorin e sulmeve, të cilave mund t'i nënshtrohet e gjithë arkitektura e Helm në përgjithësi. Dhe pastaj do të përpiqemi ta mbrojmë atë.
Vektori i sulmeve
Vendi i parĂ« potencialisht i dobĂ«t â API e privilegjuarâpĂ«rdorues. NĂ« kuadĂ«r tĂ« skemĂ«s, ky Ă«shtĂ« njĂ« hacker qĂ« ka fituar qasje administratori nĂ« Helm CLI.
Përdoruesi API pa privilegje po ashtu mund të përbëjë një rrezik nëse ndodhet diku pranë. Një përdorues i tillë do të ketë një kontekst tjetër, për shembull, ai mund të jetë i regjistruar në një namespace të caktuar në cilësimet e Kubeconfig.
Një nga vektorët më interesantë të sulmit mund të jetë procesi që ndodhet brenda klasterit diku pranë Tiller dhe mund të lidhet me të. Kjo mund të jetë një server web ose një mikroshërbim, i cili sheh mjedisin rrjetor të klasterit.
Një variant ekzotik, por në rritje të popullaritetit, i sulmit është i lidhur me Chart Repo. Një chart, e krijuar nga një autor i pandershëm, mund të përmbajë resurse të pasigurta, 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ë një burim në formë politikash dhe të rrisë qasjen për veten.
Të përpiqemi të mbrojmë veten nga sulmet nga të katër anët dhe të kuptojmë ku janë këto probleme në arkitekturën e Helm, dhe ku ndoshta nuk ka.
Të zmadhojmë skemën, të shtojmë më shumë elemente, por të ruajmë të gjitha komponentët bazë.
Helm CLI komunikon me Chart Repo, ndërvepron me Kubeconfig, pune kalon në klaster në komponentin Tiller.
Tiller paraqitet me dy objekte:
- Tiller-deploy svc, i cili ofron një shërbim;
- Tiller-deploy pod (në skemë në një eksemplar të vetëm në një replikë), në të cilin funksionon të gjithë ngarkesa, e cila lidhet me klasterin.
Për ndërveprimin përdoren protokolle dhe skema të ndryshme. Nga pikëpamja e sigurisë, ato që na interesojnë më shumë janë:
- Mekanizmi me anë të të cilit Helm CLI lidhet me chart repo: cili është protokolli, a ka autentikim dhe çfarë mund të bëjmë me këtë.
- Protokolli me të cilin Helm CLI, duke përdorur kubectl, komunikon me Tiller. Ky është një server RPC, i instaluar brenda klasterit.
- Tiller vetë është i aksesueshëm për mikroshërbimet që gjenden në klaster dhe ndërvepron me Kube-apiserver.
Do tâi diskutojmĂ« tĂ« gjitha kĂ«to drejtime njĂ« nga njĂ«.
RBAC
ĂshtĂ« e kotĂ« 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 se shumë akoma nuk e kanë aktivizuar RBAC-in madje as në prodhimin e tyre, sepse është një proces i lodhshëm dhe kërkon shumë konfigurime. Megjithatë, ju inkurajoj ta bëni këtë.
â avokati i uebit pĂ«r RBAC. Aty Ă«shtĂ« mbledhur njĂ« numĂ«r tĂ« madh tĂ« materialeve interesante, qĂ« do tĂ« ndihmojnĂ« pĂ«r konfigurimin e RBAC, do tĂ« tregojnĂ« pse Ă«shtĂ« i mirĂ« dhe si mund tĂ« jetosh 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. Në përgjithësi, nëse RBAC nuk është konfiguruar, kjo do të jetë super përdoruesi. Në konfigurimin bazë, Tiller do të jetë administrator. Kjo është arsyeja pse shpesh thuhen se Tiller është një tunel SSH për klasterin tuaj. Në të vërtetë, është kështu, prandaj mund të përdorni një llogari shërbimi të specializuar në vend të Llogarisë Shërbimore Default në diagramin e mësipërm.
Kur e inicializoni Helm, herën e parë që e instaloni në server, mund të caktoni një llogari shërbimi duke përdorur --service-account. Kjo do të lejojë përdorimin e një përdoruesi me një grup minimal të të drejtave. Megjithatë, do të duhet të krijoni një "varg": Role dhe RoleBinding.
Me keqardhje, Helm nuk do ta bëjë këtë për ju. Ju ose administratori i klasterit tuaj Kubernetes duhet të përgatisin paraprakisht një grup Role, RoleBinding për llogarinë shërbimi, për t'i kaluar Helm.
ShqetĂ«simi Ă«shtĂ« â cila Ă«shtĂ« dallimi midis Role dhe ClusterRole? Dallimi qĂ«ndron nĂ« faktin se ClusterRole funksionon pĂ«r tĂ« gjitha namespaces, nĂ« kundĂ«rshtim me Role dhe RoleBinding normal, tĂ« cilat punojnĂ« vetĂ«m pĂ«r njĂ« namespace tĂ« specializuar. Mund tĂ« konfiguroni politika si pĂ«r tĂ« gjithĂ« klasterin edhe pĂ«r çdo namespace tĂ« veçantĂ« individualisht.
Dhe duhet tĂ« pĂ«rmendet se RBAC lejon zgjidhjen e njĂ« problemi tjetĂ«r tĂ« madh. ShumĂ« ankohet se Helm, fatkeqĂ«sisht, nuk Ă«shtĂ« multitenancy (nuk mbĂ«shtet shumĂ« qiradhĂ«nie). NĂ«se disa ekipe konsumojnĂ« klasterin dhe pĂ«rdorin Helm, Ă«shtĂ« e pamundur nĂ« thelb tĂ« konfiguroni politika dhe tĂ« kufizoni aksesin e tyre brenda kĂ«tij klasteri, sepse ka njĂ« llogari shĂ«rbimi nĂ«n tĂ« cilin funksionon Helm, dhe ai krijon tĂ« gjithĂ« burimet brenda klasterit nga ajo, e cila ndonjĂ«herĂ« Ă«shtĂ« shumĂ« e pakĂ«ndshme. Kjo Ă«shtĂ« e vĂ«rtetĂ« â si vetĂ« skedari binar, ashtu edhe procesi, Helm Tiller nuk ka asnjĂ« koncept pĂ«r multitenancy..
Megjithatë, ka një mënyrë të shkëlqyer që lejon të lansoni Tiller në klaster disa herë. Me këtë nuk ka asnjë problem, Tiller mund të fillohet në çdo namespace. Kështu, mund të shfrytëzoni RBAC, Kubeconfig si kontekst, dhe të kufizoni aksesin në Helm të veçantë.
Kjo do të duket kështu.
Për shembull, ka dy Kubeconfig me kontekst për ekipe të ndryshme (dy namespace): Ekipi X për ekipin e zhvilluesve dhe klustër admini. Klustëri admin ka Tiller të gjerë, i cili ndodhet në hapësirën Kube-system namespace, përkatësisht një service-account të avancuar. Dhe një namespace të veçantë për ekipin e zhvilluesve, ata do të mund të publikojnë shërbimet e tyre në një namespace të veçantë.
Kjo është një qasje e mirë, Tiller nuk është aq i keq për buxhetin tuaj. Kjo është një nga zgjidhjet më të shpejta.
Mos hezitoni të konfiguroni veçmas Tiller dhe të jepni Kubeconfig me kontekst për ekipin, për një zhvillues të veçantë ose për ambientet: Dev, Staging, Production (është e dyshimtë që gjithçka të jetë në një klustër, megjithatë, është e mundur të bëhet kështu).
Duke vazhduar historinë tonë, do të kalojmë nga RBAC dhe do të flasim për ConfigMaps.
ConfigMaps
Helm përdor ConfigMaps si një magazinë të dhënash. Kur flisnim për arkitekturën, atje nuk kishte bazë të dhënash në të cilën ruheshin informacionet për publikimet, konfigurimet, rikthimet etj. Për këtë përdoren ConfigMaps.
Problemi kryesor me ConfigMaps Ă«shtĂ« i njohur â ato nuk janĂ« tĂ« sigurta nĂ« parim, nĂ« to nuk mund tĂ« ruhen tĂ« dhĂ«nat sensitive. Flitet pĂ«r gjithçka qĂ« nuk duhet tĂ« kalojĂ« mĂ« tej shĂ«rbimit, siç janĂ« fjalĂ«kalimet. MĂ«nyra mĂ« natyrale pĂ«r Helm tani Ă«shtĂ« tĂ« kalojĂ« nga pĂ«rdorimi i ConfigMaps nĂ« sekrete.
Kjo bëhet shumë lehtë. Rregulloni konfigurimin e Tiller dhe tregoni se magazina do të jenë sekretet. Atëherë për çdo publikim do të merrni jo ConfigMap, por një sekret.
Mund të kundërshtoni se vetë sekretet janë një koncept i çuditshëm, dhe kjo nuk është shumë e sigurt. Megjithatë, duhet kuptuar se këto janë të menaxhuara nga zhvilluesit e Kubernetes. Që nga versioni 1.10, dmth. për një kohë të gjatë, ka mundësi, të paktën në cloud publik, të lidhni magazinën e duhur për ruajtjen e sekretet. Tani ekipi po punon për të ofruar akses më të mirë në sekretet, për pods të veçanta ose entitete të tjera.
Magazina Helm është më mirë të kalojë në sekrete, dhe ato në mënyrë të centralizuar të sigurohen.
Sigurisht, do të mbetet një kufizim për ruajtjen e të dhënave në 1 MB. Helm përdor këtu etcd si një ruajtje të shpërndarë për ConfigMaps. Aty menduan se kjo është një copë e përshtatshme të dhënash për riplikime etj. Në lidhje me këtë ka një diskutim interesant në Reddit, rekomandoj ta kërkoni këtë lexim argëtues për fundjavë ose ta lexoni përmbledhjen. .
Repo Chart
Chartet janë më socialisht të ndjeshme dhe mund të bëhen burim i "Njeriut në mes", veçanërisht nëse përdorni një zgjidhje të stokut. Në radhë të parë, është fjala për repozitat që publikohen përmes HTTP.
Padyshim, duhet tĂ« publikoni Helm Repo pĂ«rmes HTTPS â kjo Ă«shtĂ« opsioni mĂ« i mirĂ« dhe nuk kushton shumĂ«.
Kujdesi pĂ«r mekanizmi i nĂ«nshkrimeve tĂ« chart-eve. Teknologjia Ă«shtĂ« jashtĂ«zakonisht e thjeshtĂ«. ĂshtĂ« e njĂ«jta gjĂ« qĂ« pĂ«rdorni nĂ« GitHub, njĂ« makineri PGP e zakonshme me çelĂ«sa publikĂ« dhe privatĂ«. Konfiguroni 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 Helm mbĂ«shtet TLS (jo nĂ« kuptimin HTTP tĂ« serverit, por TLS tĂ« ndĂ«rsjellĂ«). Ju mund tĂ« pĂ«rdorni çelĂ«sat e serverit dhe klientit pĂ«r tĂ« komunikuar. TĂ« them sinqerisht, nuk e pĂ«rdor njĂ« mekanizĂ«m tĂ« tillĂ« pĂ«r shkak tĂ« mosdashjes pĂ«r certifikatat e ndĂ«rsjella. NĂ« parim, â instrumenti kryesor pĂ«r publikimin e Helm Repo pĂ«r Helm 2 â mbĂ«shtet gjithashtu basic auth. Mund tĂ« pĂ«rdorni basic auth, nĂ«se Ă«shtĂ« mĂ« e lehtĂ« dhe mĂ« e qetĂ«.
Ka gjithashtu një plugin , i cili lejon të vendosni Chart Repos në Google Cloud Storage. Kjo është mjaft e përshtatshme, funksionon shkëlqyeshëm dhe është mjaft e sigurt, sepse përdoren të gjitha mekanizmat e përshkruar.
Nëse aktivizoni HTTPS ose TLS, përdorni mTLS, lidhni basic auth, për të ulur edhe më shumë rreziqet, do të keni një kanal të sigurt komunikimi midis Helm CLI dhe Chart Repo.
gRPC API
Hapi tjetĂ«r Ă«shtĂ« shumĂ« i rĂ«ndĂ«sishĂ«m â tĂ« sigurohet Tiller, i cili ndodhet nĂ« klasĂ«r dhe Ă«shtĂ«, nga njĂ«ra anĂ«, server, nga ana tjetĂ«r â ai vet gjithashtu kĂ«rkon nĂ« komponentĂ«t e tjerĂ« dhe pĂ«rpiqet tĂ« paraqitet si dikush tjetĂ«r.
Siç e kam thĂ«nĂ«, Tiller Ă«shtĂ« njĂ« shĂ«rbim qĂ« ekspozon gRPC, Klienti Helm i qaset atij pĂ«rmes gRPC. NĂ« mĂ«nyrĂ« tĂ« paracaktuar, natyrisht, TLS Ă«shtĂ« i çaktivizuar. Pse Ă«shtĂ« bĂ«rĂ« kjo â Ă«shtĂ« njĂ« pyetje diskutimi, mua mĂ« duket qĂ« tĂ« thjeshtojĂ« konfigurimin nĂ« fillim.
Për produksion dhe madje edhe për staging, rekomandoj të aktivizoni TLS në gRPC.
Sipas mendimit tim, ndryshe nga mTLS pĂ«r chartet, kĂ«tu Ă«shtĂ« e pĂ«rshtatshme dhe bĂ«het shumĂ« lehtĂ« â krijoni infrastrukturĂ«n PQI, krijoni njĂ« certifikatĂ«, nisni Tiller, transmetoni certifikatĂ«n gjatĂ« inicializimit. Pas kĂ«saj, mund tĂ« kryeni tĂ« gjitha komandat Helm, duke u identifikuar me certifikatĂ«n e krijuar dhe çelĂ«sin privat.
Kështu, do të siguroni veten nga të gjitha kërkesat ndaj Tiller nga jashtë klasterit.
Kështu, ne e siguruam kanal lidhjeje me Tiller, tashmë diskutuam RBAC dhe rregulluam të drejtat e Kubernetes apiserver, zvogëluam domenin me të cilin ai mund të interagojë.
Helmi i mbrojtur
Le të shikojmë skemën përfundimtare. Kjo është e njëjta arkitekturë me të njëjtat shigjeta.
Të gjitha lidhjet tani mund të vizatohen me ngjyrë të gjelbër:
- për Chart Repo përdorim TLS ose mTLS dhe autentifikim bazik;
- mTLS për Tiller, dhe ai është vendosur si një shërbim gRPC me TLS, përdorim certifikatat;
- nĂ« klaster pĂ«rdoret njĂ« llogari shĂ«rbimi e specializuar me Role dhe RoleBinding.Â
Ne e siguruan dukshëm klasterin, por dikush i mençur tha:
«Zgjidhja absolutisht e sigurt mund tĂ« jetĂ« vetĂ«m njĂ« â njĂ« kompjuter i fikur, i cili ndodhet nĂ« njĂ« kuti betoni dhe ruhet nga ushtarë».
Ka mënyra të ndryshme për manipulimin e të dhënave dhe gjetjen e vektorëve të rinj të sulmit. Megjithatë, jam i sigurt se këto rekomandime do të lejojnë implementimin e një standardi bazë të sigurisë industriale.
Bonusi
Kjo pjesĂ« nuk i pĂ«rket drejtpĂ«rdrejt sigurisĂ«, por gjithashtu do tĂ« jetĂ« e dobishme. Do tĂ« tregoj disa gjĂ«ra interesante, pĂ«r tĂ« cilat pak njerĂ«z dinĂ«. PĂ«r shembull, si tĂ« kĂ«rkoni chartet â zyrtare dhe jozyrtare.
In the repository tani ka rreth 300 chart dhe dy rrjedha: stable dhe incubator. Ai qĂ« kontribuon e di mirĂ« sa e vĂ«shtirĂ« Ă«shtĂ« tĂ« kalosh nga incubator nĂ« stable, dhe sa e lehtĂ« Ă«shtĂ« tĂ« dalĂ«sh nga stable. MegjithatĂ«, kjo nuk Ă«shtĂ« instrumenti mĂ« i mirĂ« pĂ«r tĂ« kĂ«rkuar chartet pĂ«r Prometheus dhe gjithçka qĂ« ju pĂ«lqen, pĂ«r njĂ« arsye tĂ« thjeshtĂ« â nuk Ă«shtĂ« njĂ« portal ku Ă«shtĂ« e lehtĂ« tĂ« kĂ«rkosh paketat.
Por ka një shërbim , me ndihmën e të cilit është shumë më e lehtë të gjeni chartet. E rëndësishmja është se ka shumë më tepër repozita të jashtme dhe janë në dispozicion gati 800 chart. Përveç kësaj, mund të lidhni repozitë tuaj, nëse për ndonjë arsye nuk dëshironi të dërgoni chartet tuaja në stable.
Provo hub.helm.sh dhe le të zhvillojmë së bashku. Ky shërbim është nën projektin Helm, dhe mund të kontribuoni edhe në UI-në e tij, nëse jeni frontend dhe dëshironi thjesht të përmirësoni pamjen.
Dëshiroj gjithashtu të tërheq vëmendjen tuaj mbi shërbimet Open Service Broker API. Duket e rëndë dhe e paqartë, por zgjidh probleme me të cilat të gjithë përballen. Do ta shpjegoj me një shembull të thjeshtë.
Ka njĂ« kajstrer Kubernetes, nĂ« tĂ« cilin dĂ«shirojmĂ« tĂ« lançojmĂ« njĂ« aplikacion klasik â WordPress. Zakonisht, pĂ«r funksionalitet tĂ« plotĂ« nevojitet njĂ« bazĂ« tĂ« dhĂ«nash. Ka shumĂ« zgjidhje tĂ« ndryshme, pĂ«r shembull, mund tĂ« lançojmĂ« shĂ«rbimin tonĂ« statefull. Kjo nuk Ă«shtĂ« shumĂ« e pĂ«rshtatshme, por shumĂ« njerĂ«z e bĂ«jnĂ« kĂ«shtu.
Të tjerët, për shembull, ne në Chainstack, përdorin baza të dhënash të menaxhuara, si MySQL ose PostgreSQL, për serverët. Prandaj, baza jonë e të dhënave ndodhet diku në re.
Por lind problemi: duhet tĂ« lidhim shĂ«rbimin tonĂ« me bazĂ«n e tĂ« dhĂ«nave, tĂ« krijojmĂ« favorin e bazĂ«s sĂ« tĂ« dhĂ«nave, tĂ« kalojmĂ« kredencialet dhe tĂ« menaxhojmĂ« gjithçka. TĂ« gjitha kĂ«to zakonisht bĂ«hen manualisht nga njĂ« administrator sistemi ose zhvillues. Nuk ka ndonjĂ« problem kur ka pak aplikacione. Kur ka shumĂ«, duhet njĂ« kombajn. Ka njĂ« kombajn tĂ« tillĂ« â Ă«shtĂ« ShĂ«rbimi Broker. Ai lejon pĂ«rdorimin e njĂ« plani tĂ« veçantĂ« pĂ«r kajstrin e qelqit publik dhe tĂ« porosisĂ« resurse nga ofruesi pĂ«rmes Broker-it, sikur tĂ« ishte API. PĂ«r kĂ«tĂ« mund tĂ« pĂ«rdoren mjete native tĂ« Kubernetes.
ĂshtĂ« shumĂ« e thjeshtĂ«. Mund tĂ« kĂ«rkoni, pĂ«r shembull, Managed MySQL nĂ« Azure me tier themelor (kjo mund tĂ« konfigurohet). Duke pĂ«rdorur API-nĂ« Azure, baza do tĂ« krijohet dhe pĂ«rgatitet pĂ«r pĂ«rdorim. Nuk do ju nevojitet tĂ« ndĂ«rhyni nĂ« kĂ«tĂ«, pĂ«r kĂ«tĂ« kujdeset plaga. PĂ«r shembull, OSBA (plugin Azure) do tĂ« kthejĂ« kredencialet nĂ« shĂ«rbim, dhe do t'i kalojĂ« Helm-it. Ju do tĂ« jeni nĂ« gjendje tĂ« pĂ«rdorni WordPress me MySQL nĂ« re, pa u marrĂ« fare me bazat e dhĂ«nash tĂ« menaxhuara dhe pa u shqetĂ«suar pĂ«r shĂ«rbimet statefull brenda.
Mund tĂ« thuhet se Helm vepron si njĂ« lidhĂ«s, i cili nga njĂ«ra anĂ« mundĂ«son shpĂ«rndarjen e shĂ«rbimeve, dhe nga ana tjetĂ«r â konsumimin e resurseve tĂ« ofruesve tĂ« reve.
Mund të shkruani plagin tuaj dhe ta përdorni gjithë këtë histori on-premise. Atëherë do të keni thjesht plagin tuaj për ofruesin e Cloud-it korporativ. Unë rekomandoj ta provoni këtë qasje, veçanërisht nëse keni një shkallë të madhe dhe dëshironi të lançoni shpejt zhvillimin, testimin ose tërë infrastrukturën për një veçori. Kjo do ta thjeshtojë jetën për operacionet tuaja ose DevOps.
Një zbulim tjetër që e kam përmendur tashmë është plagini helm-gcs, që lejon përdorimin e Google-buckets (hapësira e objektit) për të ruajtur Helm-charts.
Duhet vetëm katër komanda për të filluar ta përdorni atë:
- të instaloni plugin-in;
- ta inicializoni atë;
- cakto një rrugë për bucket, që ndodhet në gcp;
- publikoni chart-et në mënyrën standarde.
E bukura është se do të përdoret një metodë natyrale e gcp për autorizim. Ju mund të përdorni një llogari shërbimi, llogari të zhvilluesit - çfarëdo që të doni. Kjo është shumë e lehtë dhe nuk kushton asgjë për operim. Nëse ju, si edhe unë, promovoni filozofinë opsless, atëherë kjo do të jetë shumë e përshtatshme, veçanërisht për ekipet e vogla.
Alternativat
Helm - nuk është zgjidhja e vetme për menaxhimin e shërbimeve. Ka shumë pyetje rreth tij, ndoshta për këtë arsye versi i tretë erdhi kaq shpejt. Sigurisht, ka alternativa.
Mund të jenë zgjidhje të specializuara, si Ksonnet ose Metaparticle. Ju mund të përdorni mjetet tuaja klasike të menaxhimit të infrastrukturës (Ansible, Terraform, Chef etj.) për të njëjtat qëllime që përmenda.
Në fund, ka një zgjidhje , e cila është në rritje të popullaritetit.
Operator Framework - alternativa kryesore ndaj Helm, që duhet t'i kushtoni vëmendje.
Eshtë më natyrale për CNCF dhe Kubernetes, por prag hyrjeje është shumë më i lartë, kërkohet më shumë programim dhe më pak përshkrim të manifestëve.
Ka dodat të ndryshme, si Draft, Scaffold. Ato e lehtësojnë shumë jetën, për shembull, për zhvilluesit që e thjeshtojnë ciklin e dërgimit dhe lançimit të Helm për implikimin e mjedisit testues. Unë do t'i quaja ato zgjerues të mundësive.
Ja një grafik ilustruese ku është çdo gjë.
Po në boshtin horizontal është niveli juaj i kontrollit personal mbi atë që ndodh, në boshtin vertikal është niveli natyralitetit të Kubernetes. Helm versioni 2 është diku në mes. Në versionin 3 nuk është ndjeshëm më mirë, por kontrolli dhe niveli i natyralitetit janë përmirësuar. Zgjidhjet e nivelit Ksonnet akoma bien short në Helm 2. Sidoqoftë, ato meritojnë të shihen, që të dini se çfarë tjetër ka në këtë botë. Sigurisht, menaxheri juaj i konfigurimeve do të jetë nën kontrollin tuaj, por asgjështu nuk është natyral për Kubernetes.
Operator Framework është plotësisht natyral për Kubernetes dhe lejon menaxhimin e tij në mënyrë më elegante dhe më të detajuar (por mos haroni për nivelin e hyrjes). Më shumë për këtë është i përshtatshëm për aplikacione të specializuara dhe krijimin e menaxhimit për to, në vend të një kombajni masiv për paketimin e një numri të madh aplikacionesh përmes Helm.
Zgjeruesit përmirësojnë pak kontrollet, plotësojnë flux-in e punës ose i shkurtuese këndet e pipeline-ve CI/CD.
E ardhmja e Helm
Lajmi i mirë është se Helm 3 po del. Versioni alfa i Helm 3.0.0-alpha.2 tani është në dispozicion për t'u provuar. Ai është mjaft stabil, por funksionaliteti është ende i kufizuar.
Pse është e nevojshme Helm 3? Para së gjithash, kjo është një histori për zhdukjen 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 bëhet më e thjeshtë.
Kur u krijua Helm 2, ndodhi gjatë kohës së Kubernetes 1.8 ose madje më herët, shumë koncepte ishin të pjekura. Për shembull, koncepti i CRD tani është duke u zbatuar me intensitet, dhe Helm do të përdorë CRD, për të ruajtur strukturat. Do të jetë e mundur të përdoren vetëm klienti dhe të mos mbahet pjesa server. Prandaj, do të përdoren komandat native të Kubernetes për të punuar me strukturat dhe burimet. Ky është një hap i madh përpara.
Do të ketë mbështetje për depot native OCI (Open Container Initiative). Kjo është një iniciativë e madhe, dhe helm është veçanërisht e interesuar për të vendosur chart-et e veta. Arrin deri në pikën që, për shembull, Docker Hub mbështet shumë standarde OCI. Nuk e parashikoj, por ndoshta ofruesit klasikë të depot Docker do të fillojnë të ofrojnë mundësinë për të vendosur chart-et e Helm-it tuaj.
Një histori e diskutueshme për mua është mbështetja për Lua, si një motor templating për shkruarjen e skripteve. Unë nuk jam një fans i madh i Lua-s, por kjo do të jetë një mundësi plotësuese. E kam verifikuar tri herë - përdorimi i Lua-s nuk do të jetë i detyrueshëm. Pra, ata që duan mund të përdorin Lua, ata që preferojnë Go - bashkohuni me kampin tonë të madh dhe përdorni go-tmpl për këtë.
Më në fund, gjëja që më mungonte me siguri ishte shfaqja e skemës dhe validimi i tipeve të të dhënave. Nuk do të ketë më probleme me int ose string, nuk do të jetë e nevojshme të rrotullohet zero në dy cita. Do të shfaqet një skemë JSONS, e cila do të lejojë të përshkruajë qartë këtë për vlerat.
Do të rishikohet shumë modeli i motivuar nga ngjarjet. Ai tashmë është përshkruar konceptualisht. Shikoni në degën Helm 3 dhe do të shihni se sa shumë ngjarje, hook-e dhe gjëra të tjera janë shtuar, të cilat do të thjeshtojnë dhe, nga ana tjetër, do të shtojnë kontroll mbi proceset e depozitimeve dhe reagimet ndaj tyre.
Helm 3 do të jetë më i thjeshtë, më i sigurt dhe më interesant, jo sepse nuk na pëlqen Helm 2, por sepse Kubernetes po bëhet më i avancuar. Prandaj, Helm mund të përdorë arritjet e Kubernetes dhe të krijojë menaxherë të shkëlqyer për Kubernetes.
Një lajm tjetër i mirë është se Aleksandër Hajerov do të flasë, Kujtojmë, kongresi për integrimin e proceseve të zhvillimit, testimit dhe operimit do të zhvillohet në Moskë më 30 shtator dhe 1 tetor. Deri më 20 gusht ende mund të dhe të flasë për përvojën e tij në zgjidhjen problemeve të qasjes DevOps.
PërCheckpointet e kongresit dhe lajmet ndiqni në dhe .
Burimi: habr.com
