Thelbi i tregimit për menaxherin më të njohur të paketave për Kubernetes mund të përshkruhet duke përdorur një emoji:
- kutia është Helm (që është gjëja më e afërt me lëshimin e fundit të Emoji);
- bllokoj - siguri;
- njeriu i vogël është zgjidhja e problemit.
Në fakt, gjithçka do të jetë pak më e komplikuar, dhe historia është plot me detaje teknike rreth saj Si ta bëni Helm të sigurt.
- Shkurtimisht çfarë është Helm në rast se nuk e keni ditur apo harruar. Çfarë problemesh zgjidh dhe ku ndodhet në ekosistem.
- Le të shohim arkitekturën e Helm. Asnjë bisedë rreth sigurisë dhe mënyrës se si të bëhet një mjet ose zgjidhje më e sigurt nuk është e plotë pa kuptuar arkitekturën e komponentit.
- Le të diskutojmë komponentët e Helm-it.
- Pyetja më djegëse është e ardhmja - versioni i ri i Helm 3.
Gjithçka në këtë artikull vlen për Helm 2. Ky version është aktualisht në prodhim dhe me shumë mundësi është ai që po përdorni aktualisht dhe është versioni që përmban rreziqet e sigurisë.
Rreth folësit: Alexander Khayorov () është zhvilluar për 10 vjet, duke ndihmuar në përmirësimin e përmbajtjes dhe iu bashkua komitetit . Tani ai punon në Chainstack si drejtues zhvillimi - ky është një hibrid midis një menaxheri zhvillimi dhe një personi që është përgjegjës për dhënien e publikimeve përfundimtare. Domethënë, ndodhet në fushën e betejës, ku ndodh gjithçka nga krijimi i një produkti e deri te funksionimi i tij.
Chainstack është një startup i vogël, në rritje aktive, misioni i të cilit është t'u mundësojë klientëve të harrojnë infrastrukturën dhe kompleksitetin e funksionimit të aplikacioneve të decentralizuara; ekipi i zhvillimit ndodhet në Singapor. Mos kërkoni nga Chainstack të shesë ose të blejë kriptovaluta, por ofroni të flisni për kornizat e blockchain të ndërmarrjeve dhe ata do t'ju përgjigjen me kënaqësi.
kaskë
Ky është një menaxher i paketave (grafikes) për Kubernetes. Mënyra më intuitive dhe universale për të sjellë aplikacione në një grupim Kubernetes.
Ne, sigurisht, po flasim për një qasje më strukturore dhe industriale sesa krijimi i manifesteve tuaja YAML dhe shkrimi i shërbimeve të vogla.
Helm është më i miri që është aktualisht në dispozicion dhe popullor.
Pse Helm? Kryesisht sepse mbështetet nga CNCF. Cloud Native është një organizatë e madhe dhe është kompania mëmë për projektet Kubernetes, etcd, Fluentd dhe të tjerë.
Një tjetër fakt i rëndësishëm është se Helm është një projekt shumë i njohur. Kur fillova të flas se si ta bëj Helm të sigurt në janar 2019, projekti kishte një mijë yje në GitHub. Deri në maj ishin 12 mijë prej tyre.
Shumë njerëz janë të interesuar për Helm, kështu që edhe nëse nuk e përdorni ende, do të përfitoni duke ditur për sigurinë e tij. Siguria është e rëndësishme.
Ekipi kryesor i Helm-it mbështetet nga Microsoft Azure dhe për këtë arsye është një projekt mjaft i qëndrueshëm, ndryshe nga shumë të tjerë. Publikimi i Helm 3 Alpha 2 në mesin e korrikut tregon se ka mjaft njerëz që punojnë në projekt, dhe ata kanë dëshirën dhe energjinë për të zhvilluar dhe përmirësuar Helm.
Helm zgjidh disa probleme rrënjësore të menaxhimit të aplikacioneve në Kubernetes.
- Paketimi i aplikacionit. Edhe një aplikacion si "Hello, World" në WordPress tashmë përbëhet nga disa shërbime dhe ju dëshironi t'i paketoni ato së bashku.
- Menaxhimi i kompleksitetit që vjen me menaxhimin e këtyre aplikacioneve.
- Një cikël jetësor që nuk përfundon pasi aplikacioni të instalohet ose vendoset. Ajo vazhdon të jetojë, duhet të përditësohet, dhe Helm ndihmon për këtë dhe përpiqet të sjellë masat dhe politikat e duhura për këtë.
Thithja e qeseve është i organizuar në mënyrë të qartë: ka meta të dhëna në përputhje të plotë me punën e një menaxheri të rregullt paketash për Linux, Windows ose MacOS. Kjo do të thotë, një depo, varësi nga paketa të ndryshme, meta informacion për aplikacionet, cilësimet, veçoritë e konfigurimit, indeksimi i informacionit, etj. Helm ju lejon të merrni dhe përdorni të gjitha këto për aplikacione.
Menaxhimi i Kompleksitetit. Nëse keni shumë aplikacione të të njëjtit lloj, atëherë nevojitet parametrizimi. Modelet vijnë nga kjo, por për të shmangur nevojën për të gjetur mënyrën tuaj të krijimit të shablloneve, mund të përdorni atë që Helm ofron jashtë kutisë.
Menaxhimi i ciklit jetësor të aplikacionit - për mendimin tim, kjo është pyetja më interesante dhe e pazgjidhur. Kjo është arsyeja pse erdha në Helm atë ditë. Ne kishim nevojë për të mbajtur një sy në ciklin e jetës së aplikacionit dhe donim të zhvendosnim ciklet tona të CI/CD dhe aplikimit në këtë paradigmë.
Helm ju lejon të:
- menaxhon vendosjet, prezanton konceptin e konfigurimit dhe rishikimit;
- kryeni me sukses rikthimin;
- përdorni grepa për ngjarje të ndryshme;
- shtoni kontrolle shtesë të aplikacionit dhe përgjigjuni rezultateve të tyre.
Për më tepër Helma ka "bateri" - një numër i madh i gjërave të shijshme që mund të përfshihen në formën e shtojcave, duke thjeshtuar jetën tuaj. Pluginat mund të shkruhen në mënyrë të pavarur, ato janë mjaft të izoluara dhe nuk kërkojnë një arkitekturë harmonike. Nëse dëshironi të zbatoni diçka, ju rekomandoj ta bëni atë si një shtojcë, dhe më pas ta përfshini atë në rrjedhën e sipërme.
Helm bazohet në tre koncepte kryesore:
- Chart Repo — përshkrimi dhe grupi i parametrave të mundshëm për manifestin tuaj.
- config - pra vlerat që do të aplikohen (teksti, vlerat numerike, etj.).
- Lirimin mbledh dy komponentët e sipërm, dhe së bashku ato kthehen në Release. Publikimet mund të modifikohen, duke arritur kështu një cikël të organizuar të jetës: i vogël në kohën e instalimit dhe i madh në kohën e përmirësimit, uljes ose rikthimit.
Arkitektura e timonit
Diagrami përshkruan konceptualisht arkitekturën e nivelit të lartë të Helm.
Më lejoni t'ju kujtoj se Helm është diçka që lidhet me Kubernetes. Prandaj, ne nuk mund të bëjmë pa një grup Kubernetes (drejtkëndësh). Komponenti kube-apiserver qëndron në master. Pa Helm ne kemi Kubeconfig. Helm sjell një binar të vogël, nëse mund ta quani kështu, mjetin Helm CLI, i cili është i instaluar në një kompjuter, laptop, mainframe - në çdo gjë.
Por kjo nuk mjafton. Helm ka një komponent të serverit të quajtur Tiller. Ai përfaqëson interesat e Helm brenda grupit; është një aplikacion brenda grupit Kubernetes, ashtu si çdo tjetër.
Komponenti tjetër i Chart Repo është një depo me grafikët. Ekziston një depo zyrtare dhe mund të ketë një depo private të një kompanie ose projekti.
Bashkëveprim
Le të shohim se si ndërveprojnë komponentët e arkitekturës kur duam të instalojmë një aplikacion duke përdorur Helm.
- Po flasim
Helm install, hyni në depo (Chart Repo) dhe merrni një tabelë Helm.
- Përdorimi Helm (Helm CLI) ndërvepron me Kubeconfig për të kuptuar se cilin grup duhet të kontaktojë.
- Pasi ka marrë këtë informacion, shërbimi i referohet Tiller, i cili ndodhet në grupin tonë, si një aplikacion.
- Tiller thërret Kube-apiserver për të kryer veprime në Kubernetes, për të krijuar disa objekte (shërbime, pods, kopje, sekrete, etj.).
Më pas, ne do të komplikojmë diagramin për të parë vektorin e sulmit ndaj të cilit mund të ekspozohet e gjithë arkitektura e Helm-it në tërësi. Dhe pastaj ne do të përpiqemi ta mbrojmë atë.
Vektori i sulmit
Pika e parë e dobët e mundshme është API i privilegjuar-përdoruesit. Si pjesë e skemës, ky është një haker që ka fituar akses administratori në Helm CLI.
Përdorues i paprivilegjuar API mund të përbëjë rrezik edhe nëse është diku afër. Një përdorues i tillë do të ketë një kontekst të ndryshëm, për shembull, ai mund të fiksohet në një hapësirë emri grupi në cilësimet e Kubeconfig.
Vektori më interesant i sulmit mund të jetë një proces që ndodhet brenda një grupi diku afër Tiller dhe mund të hyjë në të. Ky mund të jetë një server në internet ose mikroshërbim që sheh mjedisin e rrjetit të grupit.
Një variant sulmi ekzotik, por gjithnjë e më popullor, përfshin Chart Repo. Një grafik i krijuar nga një autor i paskrupullt mund të përmbajë burime të pasigurta dhe ju do ta plotësoni atë duke e marrë me besim. Ose mund të zëvendësojë grafikun që shkarkoni nga depoja zyrtare dhe, për shembull, të krijojë një burim në formën e politikave dhe të përshkallëzojë aksesin e tij.
Le të përpiqemi të shmangim sulmet nga të katër anët dhe të kuptojmë se ku ka probleme në arkitekturën e Helm-it dhe ku, ndoshta, nuk ka asnjë.
Le të zmadhojmë diagramin, të shtojmë më shumë elementë, por të mbajmë të gjithë përbërësit bazë.
Helm CLI komunikon me Chart Repo, ndërvepron me Kubeconfig dhe puna transferohet në grup në komponentin Tiller.
Tiller përfaqësohet nga dy objekte:
- Tiller-deploy svc, i cili ekspozon një shërbim të caktuar;
- Tiller-deploy pod (në diagram në një kopje të vetme në një kopje), mbi të cilën funksionon e gjithë ngarkesa, e cila akseson grupin.
Protokolle dhe skema të ndryshme përdoren për ndërveprim. Nga pikëpamja e sigurisë, ne jemi më të interesuar në:
- Mekanizmi me të cilin Helm CLI hyn në repon e grafikut: çfarë protokolli, a ka vërtetim dhe çfarë mund të bëhet me të.
- Protokolli me të cilin Helm CLI, duke përdorur kubectl, komunikon me Tiller. Ky është një server RPC i instaluar brenda grupit.
- Vetë Tiller është i aksesueshëm për mikroshërbimet që banojnë në grup dhe ndërvepron me Kube-apiserver.
Le të diskutojmë të gjitha këto fusha me radhë.
RBAC
Nuk ka kuptim të flasim për ndonjë siguri për Helm ose ndonjë shërbim tjetër brenda grupit, përveç nëse RBAC është i aktivizuar.
Duket se ky nuk është rekomandimi i fundit, por jam i sigurt se shumë njerëz ende nuk e kanë aktivizuar RBAC as në prodhim, sepse është shumë bujë dhe shumë gjëra duhet të konfigurohen. Megjithatë, ju inkurajoj ta bëni këtë.
— avokat në internet për RBAC. Ai përmban një sasi të madhe materialesh interesante që do t'ju ndihmojnë të vendosni RBAC, të tregoni pse është i mirë dhe si të jetoni në thelb me të në prodhim.
Do të përpiqem të shpjegoj se si funksionojnë Tiller dhe RBAC. Tiller punon brenda grupit nën një llogari të caktuar shërbimi. Në mënyrë tipike, nëse RBAC nuk është konfiguruar, ky do të jetë superpërdoruesi. Në konfigurimin bazë, Tiller do të jetë një administrator. Kjo është arsyeja pse shpesh thuhet se Tiller është një tunel SSH në grupin tuaj. Në fakt, kjo është e vërtetë, kështu që ju mund të përdorni një llogari të veçantë shërbimi të dedikuar në vend të llogarisë së shërbimit të paracaktuar në diagramin e mësipërm.
Kur inicializon Helm dhe e instalon atë në server për herë të parë, mund të konfigurosh llogarinë e shërbimit duke përdorur --service-account. Kjo do t'ju lejojë të përdorni një përdorues me grupin minimal të kërkuar të të drejtave. Vërtetë, do të duhet të krijoni një "garland" të tillë: Role dhe RoleBinding.
Fatkeqësisht, Helm nuk do ta bëjë këtë për ju. Ju ose administratori juaj i grupit Kubernetes duhet të përgatisni paraprakisht një grup Rolesh dhe RoleBindings për llogarinë e shërbimit në mënyrë që të kaloni Helm.
Shtrohet pyetja - cili është ndryshimi midis Rolit dhe ClusterRole? Dallimi është se ClusterRole funksionon për të gjitha hapësirat e emrave, ndryshe nga Roles dhe RoleBindings të rregullta, të cilat funksionojnë vetëm për një hapësirë të specializuar të emrave. Ju mund të konfiguroni politika për të gjithë grupin dhe të gjitha hapësirat e emrave, ose të personalizoni për secilën hapësirë të emrave individualisht.
Vlen të përmendet se RBAC zgjidh një problem tjetër të madh. Shumë njerëz ankohen se Helm, për fat të keq, nuk është multitenancy (nuk e mbështet multitenancy). Nëse disa skuadra konsumojnë një grup dhe përdorin Helm, në thelb është e pamundur të vendosësh politika dhe të kufizosh aksesin e tyre brenda këtij grupi, sepse ekziston një llogari e caktuar shërbimi nën të cilën funksionon Helm dhe krijon të gjitha burimet në grup nga poshtë tij. , e cila ndonjëherë është shumë e papërshtatshme. Kjo është e vërtetë - si vetë skedari binar, si procesi, Helm Tiller nuk ka koncept të shumëqirashmërisë.
Sidoqoftë, ekziston një mënyrë e shkëlqyer që ju lejon të ekzekutoni Tiller disa herë në një grup. Nuk ka asnjë problem me këtë, Tiller mund të lëshohet në çdo hapësirë emri. Kështu, ju mund të përdorni RBAC, Kubeconfig si një kontekst dhe të kufizoni aksesin në një Helm të veçantë.
Do të duket kështu.
Për shembull, ka dy Kubeconfig me kontekst për ekipe të ndryshme (dy hapësira emrash): X Team për ekipin e zhvillimit dhe grupin e administratorëve. Grupi i administratorëve ka Tiller-in e tij të gjerë, i cili ndodhet në hapësirën e emrave të sistemit Kube, një llogari shërbimi përkatësisht e avancuar. Dhe një hapësirë emri të veçantë për ekipin e zhvillimit, ata do të jenë në gjendje të vendosin shërbimet e tyre në një hapësirë të veçantë emrash.
Kjo është një qasje e zbatueshme, Tiller nuk është aq i uritur për pushtet sa do të ndikojë shumë në buxhetin tuaj. Kjo është një nga zgjidhjet e shpejta.
Mos ngurroni të konfiguroni Tiller veçmas dhe t'i jepni Kubeconfig kontekstin për ekipin, për një zhvillues specifik ose për mjedisin: Dev, Staging, Production (është e dyshimtë që gjithçka do të jetë në të njëjtin grup, megjithatë, kjo mund të bëhet).
Duke vazhduar historinë tonë, le të kalojmë nga RBAC dhe të flasim për ConfigMaps.
ConfigMaps
Helm përdor ConfigMaps si ruajtjen e të dhënave. Kur folëm për arkitekturën, nuk kishte askund asnjë bazë të dhënash që do të ruante informacione rreth lëshimeve, konfigurimeve, rikthimeve, etj. Për këtë përdoret ConfigMaps.
Problemi kryesor me ConfigMaps është i njohur - ato në parim janë të pasigurta; është e pamundur të ruhen të dhëna të ndjeshme. Ne po flasim për gjithçka që nuk duhet të shkojë përtej shërbimit, për shembull, fjalëkalimet. Mënyra më origjinale për Helm tani është kalimi nga përdorimi i ConfigMaps në sekretet.
Kjo bëhet shumë thjesht. Anuloni cilësimin Tiller dhe specifikoni që ruajtja do të jetë sekrete. Pastaj për çdo vendosje nuk do të merrni një ConfigMap, por një sekret.
Ju mund të argumentoni se sekretet në vetvete janë një koncept i çuditshëm dhe jo shumë i sigurt. Sidoqoftë, ia vlen të kuptohet që vetë zhvilluesit e Kubernetes po e bëjnë këtë. Duke filluar nga versioni 1.10, d.m.th. Prej mjaft kohësh, ka qenë e mundur, të paktën në retë publike, të lidhni hapësirën e duhur me ruajtjen e sekreteve. Ekipi tani po punon për mënyrat për të shpërndarë më mirë aksesin në sekrete, grupe individuale ose entitete të tjera.
Është më mirë të transferoni Helm Storage në sekrete, dhe ato, nga ana tjetër, sigurohen në qendër.
Sigurisht që do të mbetet Kufiri i ruajtjes së të dhënave prej 1 MB. Helm këtu përdor etcd si ruajtje të shpërndarë për ConfigMaps. Dhe atje ata konsideruan se kjo ishte një pjesë e përshtatshme e të dhënave për përsëritje, etj. Ka një diskutim interesant për këtë në Reddit, unë rekomandoj të gjeni këtë lexim qesharak për fundjavë ose të lexoni ekstraktin .
Tabela Repos
Grafikët janë më të prekshmit nga ana sociale dhe mund të bëhen burim i "Njeriu në mes", veçanërisht nëse përdorni një zgjidhje stoku. Para së gjithash, ne po flasim për depo që ekspozohen përmes HTTP.
Ju patjetër duhet të ekspozoni Helm Repo mbi HTTPS - ky është opsioni më i mirë dhe është i lirë.
Kushtojini vëmendje mekanizmi i nënshkrimit të grafikut. Teknologjia është e thjeshtë si dreqin. Kjo është e njëjta gjë që përdorni në GitHub, një makinë e rregullt PGP me çelësa publikë dhe privatë. Vendosni dhe sigurohuni, duke pasur çelësat e nevojshëm dhe duke nënshkruar gjithçka, se kjo është me të vërtetë grafiku juaj.
Përveç kësaj, Klienti Helm mbështet TLS (jo në kuptimin HTTP nga ana e serverit, por TLS e ndërsjellë). Ju mund të përdorni çelësat e serverit dhe klientit për të komunikuar. Të them të drejtën, nuk e përdor një mekanizëm të tillë sepse nuk më pëlqejnë certifikatat e ndërsjella. Në thelb, - mjeti kryesor për konfigurimin e Helm Repo për Helm 2 - gjithashtu mbështet vërtetimin bazë. Mund të përdorni vërtetimin bazë nëse është më i përshtatshëm dhe më i qetë.
Ekziston edhe një shtojcë , i cili ju lejon të organizoni Chart Repos në Google Cloud Storage. Ky është mjaft i përshtatshëm, funksionon shkëlqyeshëm dhe është mjaft i sigurt, sepse të gjithë mekanizmat e përshkruar riciklohen.
Nëse aktivizoni HTTPS ose TLS, përdorni mTLS dhe aktivizoni vërtetimin bazë për të reduktuar më tej rreziqet, do të merrni një kanal komunikimi të sigurt me Helm CLI dhe Chart Repo.
gRPC API
Hapi tjetër është shumë i rëndësishëm - sigurimi i Tiller, i cili ndodhet në grup dhe është, nga njëra anë, një server, nga ana tjetër, ai vetë akseson komponentët e tjerë dhe përpiqet të pretendojë se është dikush.
Siç thashë tashmë, Tiller është një shërbim që ekspozon gRPC, klienti Helm vjen tek ai nëpërmjet gRPC. Si parazgjedhje, natyrisht, TLS është i çaktivizuar. Pse u bë kjo është një pyetje e diskutueshme, më duket se e thjeshtoj konfigurimin në fillim.
Për prodhimin dhe madje edhe vendosjen në skenë, unë rekomandoj aktivizimin e TLS në gRPC.
Sipas mendimit tim, ndryshe nga mTLS për grafikët, kjo është e përshtatshme këtu dhe bëhet shumë thjesht - gjeneroni një infrastrukturë PQI, krijoni një certifikatë, lëshoni Tiller, transferoni certifikatën gjatë inicializimit. Pas kësaj, ju mund të ekzekutoni të gjitha komandat Helm, duke i paraqitur vetes certifikatën e gjeneruar dhe çelësin privat.
Në këtë mënyrë ju do të mbroheni nga të gjitha kërkesat ndaj Tiller nga jashtë grupit.
Pra, ne kemi siguruar kanalin e lidhjes me Tiller, kemi diskutuar tashmë RBAC dhe kemi rregulluar të drejtat e apiserverit Kubernetes, duke zvogëluar domenin me të cilin ai mund të ndërveprojë.
Helm i mbrojtur
Le të shohim diagramin përfundimtar. Është e njëjta arkitekturë me të njëjtat shigjeta.
Të gjitha lidhjet tani mund të vizatohen në mënyrë të sigurt në të gjelbër:
- për Chart Repo ne përdorim TLS ose mTLS dhe auth bazë;
- mTLS për Tiller, dhe është i ekspozuar si një shërbim gRPC me TLS, ne përdorim certifikata;
- grupi përdor një llogari të veçantë shërbimi me Role dhe RoleBinding.
Ne e kemi siguruar ndjeshëm grupin, por dikush i zgjuar tha:
"Mund të ketë vetëm një zgjidhje absolutisht të sigurt - një kompjuter i fikur, i cili ndodhet në një kuti betoni dhe ruhet nga ushtarët."
Ka mënyra të ndryshme për të manipuluar të dhënat dhe për të gjetur vektorë të rinj sulmi. Megjithatë, kam besim se këto rekomandime do të arrijnë një standard bazë të industrisë për sigurinë.
Shpërblim
Kjo pjesë nuk lidhet drejtpërdrejt me sigurinë, por do të jetë gjithashtu e dobishme. Do t'ju tregoj disa gjëra interesante për të cilat pak njerëz dinë. Për shembull, si të kërkoni për grafikët - zyrtare dhe jozyrtare.
Në depo Tani ka rreth 300 tabela dhe dy rryma: stabile dhe inkubator. Kushdo që kontribuon e di shumë mirë se sa e vështirë është të kalosh nga inkubatori në stallë dhe sa e lehtë është të fluturosh nga stalla. Sidoqoftë, ky nuk është mjeti më i mirë për të kërkuar grafikët për Prometheus dhe çfarëdo tjetër që ju pëlqen, për një arsye të thjeshtë - nuk është një portal ku mund të kërkoni lehtësisht paketa.
Por ka një shërbim , gjë që e bën shumë më të përshtatshëm gjetjen e grafikëve. Më e rëndësishmja, ka shumë më tepër depo të jashtme dhe pothuajse 800 bukuri në dispozicion. Plus, ju mund të lidhni depon tuaj nëse për ndonjë arsye nuk dëshironi të dërgoni grafikët tuaj në stabile.
Provo hub.helm.sh dhe le ta zhvillojmë së bashku. Ky shërbim është nën projektin Helm, dhe madje mund të kontribuoni në ndërfaqen e tij të ndërfaqes nëse jeni një zhvillues i nivelit të parë dhe thjesht dëshironi të përmirësoni pamjen.
Unë gjithashtu do të doja të tërhiqja vëmendjen tuaj Hap integrimin e API-së së ndërmjetësit të shërbimit. Tingëllon e rëndë dhe e paqartë, por zgjidh problemet me të cilat përballen të gjithë. Më lejoni të shpjegoj me një shembull të thjeshtë.
Ekziston një grup Kubernetes në të cilin duam të ekzekutojmë një aplikacion klasik - WordPress. Në përgjithësi, nevojitet një bazë të dhënash për funksionalitet të plotë. Ka shumë zgjidhje të ndryshme, për shembull, ju mund të hapni shërbimin tuaj shtetëror. Kjo nuk është shumë e përshtatshme, por shumë njerëz e bëjnë atë.
Të tjerët, si ne në Chainstack, përdorin bazat e të dhënave të menaxhuara si MySQL ose PostgreSQL për serverët e tyre. Kjo është arsyeja pse bazat tona të të dhënave janë të vendosura diku në re.
Por lind një problem: ne duhet të lidhim shërbimin tonë me një bazë të dhënash, të krijojmë një shije bazë të dhënash, të transferojmë kredencialet dhe disi ta menaxhojmë atë. E gjithë kjo zakonisht bëhet me dorë nga administratori ose zhvilluesi i sistemit. Dhe nuk ka asnjë problem kur ka pak aplikime. Kur ka shumë, ju duhet një kombinat. Ekziston një korrës i tillë - është Broker i Shërbimit. Kjo ju lejon të përdorni një shtojcë të veçantë për një grup publik cloud dhe të porosisni burime nga ofruesi përmes Broker, sikur të ishte një API. Për ta bërë këtë, mund të përdorni mjetet vendase Kubernetes.
Është shumë e thjeshtë. Ju mund të kërkoni, për shembull, MySQL Managed në Azure me një nivel bazë (kjo mund të konfigurohet). Duke përdorur Azure API, baza e të dhënave do të krijohet dhe përgatitet për përdorim. Ju nuk keni nevojë të ndërhyni me këtë, shtojca është përgjegjëse për këtë. Për shembull, OSBA (shtojca Azure) do të kthejë kredencialet në shërbim dhe do t'ia kalojë atë Helm. Ju do të jeni në gjendje të përdorni WordPress me cloud MySQL, të mos merreni fare me bazat e të dhënave të menaxhuara dhe të mos shqetësoheni për shërbimet shtetërore brenda.
Mund të themi se Helm vepron si një ngjitës që, nga njëra anë, ju lejon të vendosni shërbime, dhe nga ana tjetër, të konsumoni burimet e ofruesve të cloud.
Ju mund të shkruani shtojcën tuaj dhe të përdorni të gjithë këtë histori në premisë. Atëherë thjesht do të keni shtojcën tuaj për ofruesin e korporatës Cloud. Unë rekomandoj të provoni këtë qasje, veçanërisht nëse keni një shkallë të madhe dhe dëshironi të vendosni shpejt dev, skedimin ose të gjithë infrastrukturën për një veçori. Kjo do ta bëjë jetën më të lehtë për operacionet tuaja ose DevOps.
Një gjetje tjetër që përmenda tashmë është shtojca helm-gcs, i cili ju lejon të përdorni kova Google (ruajtje të objekteve) për të ruajtur grafikët Helm.
Ju duhen vetëm katër komanda për të filluar përdorimin e tij:
- instaloni shtojcën;
- inicoje atë;
- vendosni shtegun drejt kovës, e cila ndodhet në gcp;
- publikoni grafikët në mënyrë standarde.
E bukura është se për autorizim do të përdoret metoda amtare gcp. Ju mund të përdorni një llogari shërbimi, një llogari zhvilluesi, çfarëdo që dëshironi. Është shumë i përshtatshëm dhe nuk kushton asgjë për t'u përdorur. Nëse ju, si unë, promovoni filozofinë opsless, atëherë kjo do të jetë shumë e përshtatshme, veçanërisht për ekipet e vogla.
alternativa
Helm nuk është zgjidhja e vetme e menaxhimit të shërbimit. Ka shumë pyetje në lidhje me të, kjo është ndoshta arsyeja pse versioni i tretë u shfaq kaq shpejt. Sigurisht që ka alternativa.
Këto mund të jenë zgjidhje të specializuara, për shembull, 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 për të cilat fola.
Më në fund ka një zgjidhje , popullariteti i të cilit po rritet.
Korniza e Operatorit është alternativa më e mirë e Helm për t'u marrë parasysh.
Është më vendas për CNCF dhe Kubernetes, por pengesa për hyrje është shumë më e lartë, ju duhet të programoni më shumë dhe të përshkruani manifestet më pak.
Ka shtesa të ndryshme, si Draft, Scaffold. Ata e bëjnë jetën shumë më të lehtë, për shembull, thjeshtojnë ciklin e dërgimit dhe lëshimit të Helm për zhvilluesit që të vendosin një mjedis testimi. Unë do t'i quaja fuqizues.
Këtu është një tabelë vizuale se ku është gjithçka.
Në boshtin x është niveli i kontrollit tuaj personal mbi atë që po ndodh, në boshtin y është niveli i vendlindjes së Kubernetes. Versioni 2 i timonit bie diku në mes. Në versionin 3, jo jashtëzakonisht, por si kontrolli ashtu edhe niveli i vendlindjes janë përmirësuar. Zgjidhjet në nivelin Ksonnet janë ende inferiore edhe ndaj Helm 2. Megjithatë, ato ia vlen të shikohen për të ditur se çfarë ka tjetër në këtë botë. Sigurisht, menaxheri juaj i konfigurimit do të jetë nën kontrollin tuaj, por nuk është absolutisht vendas për Kubernetes.
Kuadri i Operatorit është absolutisht vendas për Kubernetes dhe ju lejon ta menaxhoni atë në mënyrë shumë më elegante dhe skrupuloze (por mbani mend për nivelin e hyrjes). Përkundrazi, kjo është e përshtatshme për një aplikim të specializuar dhe krijimin e menaxhimit për të, në vend të një korrjeje masive për paketimin e një numri të madh aplikacionesh duke përdorur Helm.
Zgjeruesit thjesht përmirësojnë pak kontrollin, plotësojnë rrjedhën e punës ose prenë qoshet në tubacionet CI/CD.
E ardhmja e Helm
Lajmi i mirë është se Helm 3 po vjen. Versioni alfa i Helm 3.0.0-alpha.2 tashmë është lëshuar, mund ta provoni. Është mjaft i qëndrueshëm, por funksionaliteti është ende i kufizuar.
Pse keni nevojë për Helm 3? Para së gjithash, kjo është një histori për zhdukja e Tiller, si përbërës. Ky, siç e kuptoni tashmë, është një hap i madh përpara, sepse nga pikëpamja e sigurisë së arkitekturës, gjithçka është thjeshtuar.
Kur u krijua Helm 2, i cili ishte rreth kohës së Kubernetes 1.8 ose edhe më herët, shumë nga konceptet ishin të papjekura. Për shembull, koncepti CRD tani po zbatohet në mënyrë aktive dhe Helm do ta bëjë këtë përdorni CRDpër të ruajtur strukturat. Do të jetë e mundur të përdoret vetëm klienti dhe të mos mirëmbahet pjesa e serverit. Prandaj, përdorni komandat vendase të Kubernetes për të punuar me strukturat dhe burimet. Ky është një hap i madh përpara.
Do te shfaqet mbështetje për magazinat vendase OCI (Iniciativa e kontejnerëve të hapur). Kjo është një nismë e madhe, dhe Helm është i interesuar kryesisht për të postuar grafikët e saj. Vjen deri në pikën që, për shembull, Docker Hub mbështet shumë standarde OCI. Nuk po hamendësoj, por mbase ofruesit klasikë të depove Docker do të fillojnë t'ju japin mundësinë të organizoni grafikët e tyre të Helm.
Historia e diskutueshme për mua është Lua mbështetje, si një motor shabllon për shkrimin e skripteve. Unë nuk jam një fans i madh i Luas, por kjo do të ishte një veçori krejtësisht opsionale. E kontrollova këtë 3 herë - përdorimi i Lua nuk do të jetë i nevojshëm. Prandaj, ata që duan të jenë në gjendje të përdorin Lua, ata që pëlqejnë Go, bashkohen në kampin tonë të madh dhe përdorin go-tmpl për këtë.
Më në fund, ajo që më mungonte padyshim ishte shfaqja e skemës dhe vërtetimi i llojit të të dhënave. Nuk do të ketë më probleme me int ose string, nuk ka nevojë të mbështillni zeron në thonjëza të dyfishta. Do të shfaqet një skemë JSONS që do t'ju lejojë ta përshkruani në mënyrë eksplicite këtë për vlerat.
Do të ripunohet shumë model i drejtuar nga ngjarjet. Ajo tashmë është përshkruar konceptualisht. Shikoni degën Helm 3 dhe do të shihni sa ngjarje, grepa dhe gjëra të tjera janë shtuar, të cilat do të thjeshtojnë shumë dhe, nga ana tjetër, do të shtojnë kontrollin mbi proceset e vendosjes dhe reagimet ndaj tyre.
Helm 3 do të jetë më i thjeshtë, më i sigurt dhe më argëtues, jo sepse nuk na pëlqen Helm 2, por sepse Kubernetes po bëhet më i avancuar. Prandaj, Helm mund të përdorë zhvillimet e Kubernetes dhe të krijojë menaxherë të shkëlqyer për Kubernetes në të.
Një tjetër lajm i mirë është ai Alexander Khayorov do t'ju tregojë, Ju kujtojmë se konferenca për integrimin e proceseve të zhvillimit, testimit dhe funksionimit do të mbahet në Moskë 30 shtator dhe 1 tetor. Mund ta bëni akoma deri më 20 gusht dhe na tregoni për përvojën tuaj me zgjidhjen detyrat e qasjes DevOps.
Ndiqni pikat e kontrollit të konferencës dhe lajmet në и .
Burimi: www.habr.com