Kubernetes-en pakete kudeatzaile ezagunenari buruzko istorioaren funtsa emoji bat erabiliz irudikatu liteke:
- kutxa Helm da (hori da azken Emoji bertsiotik hurbilen dagoena);
- blokeoa - segurtasuna;
- gizontxoa da arazoaren konponbidea.
Izan ere, dena apur bat konplikatuagoa izango da, eta istorioa xehetasun teknikoz beteta dago Helm seguru nola egin.
- Laburbilduz, Helm zer den ezagutzen ez baduzu edo ahaztu baduzu. Zein arazo konpontzen dituen eta non kokatzen den ekosisteman.
- Ikus dezagun Helm arkitektura. Segurtasunari buruzko eta tresna edo irtenbide bat seguruago egiteko moduari buruzko elkarrizketarik ez dago osatuko osagaiaren arkitektura ulertu gabe.
- Azter ditzagun Helm osagaiak.
- Galderarik gogorrena etorkizuna da - Helm 3-ren bertsio berria.
Artikulu honetako guztia Helm 2-ri dagokio. Bertsio hau ekoizten ari da eta seguruenik erabiltzen ari zarena izango da, eta segurtasun-arriskuak dituen bertsioa da.
Hizlariari buruz: Alexander Khayorov () 10 urte daramatza garatzen, edukiak hobetzen laguntzen eta batzordean sartu zen . Orain Chainstack-en lan egiten du garapen-buru gisa - hau garapen-kudeatzaile baten eta azken bertsioak emateaz arduratzen den pertsona baten arteko hibrido bat da. Hau da, gudu-zelaian kokatzen da, non produktu bat sortzen denetik funtzionatzen den arte gertatzen dena.
Chainstack aktiboki hazten ari den startup txiki bat da, eta bezeroei aplikazio deszentralizatuen funtzionamenduaren azpiegitura eta konplexutasuna ahaztea da bere misioa; garapen taldea Singapurren dago. Ez eskatu Chainstack-i kriptografia-moneta saltzeko edo erosteko, baina eskaini enpresen blockchain esparruei buruz hitz egitea, eta pozik erantzungo dizute.
Helm
Hau Kubernetes-en paketeen (diagrama) kudeatzailea da. Aplikazioak Kubernetes kluster batera eramateko modurik intuitiboena eta unibertsalena.
Noski, zure YAML manifestuak sortzea eta utilitate txikiak idaztea baino ikuspegi estruktural eta industrialago bati buruz ari gara.
Helm gaur egun eskuragarri eta ezaguna den onena da.
Zergatik Helm? Batez ere CNCFk onartzen duelako. Cloud Native erakunde handi bat da eta Kubernetes, etcd, Fluentd eta beste proiektuen enpresa nagusia da.
Beste datu garrantzitsu bat Helm oso proiektu ezaguna dela da. 2019ko urtarrilean Helm seguru nola egin hitz egiten hasi nintzenean, proiektuak mila izar zituen GitHub-en. Maiatzean 12 mila ziren.
Jende asko Helm-en interesatzen da, beraz, oraindik erabiltzen ez baduzu ere, bere segurtasuna ezagutzeak mesede egingo diozu. Segurtasuna garrantzitsua da.
Helm taldea Microsoft Azure-k onartzen du eta, beraz, proiektu nahiko egonkorra da, beste asko ez bezala. Helm 3 Alpha 2 uztailaren erdialdean kaleratzeak adierazten du jende asko dagoela proiektuan lanean, eta Helm garatzeko eta hobetzeko gogoa eta energia dutela.
Helm-ek Kubernetes-en aplikazioen kudeaketaren erroko hainbat arazo konpontzen ditu.
- Aplikazioen ontziratzea. Nahiz eta WordPress-en "Hello, World" bezalako aplikazio batek hainbat zerbitzu ditu dagoeneko, eta elkarrekin paketatu nahi dituzu.
- Aplikazio hauek kudeatzeak dakarren konplexutasuna kudeatzea.
- Aplikazioa instalatu edo zabaldu ondoren amaitzen ez den bizi-zikloa. Bizitzen jarraitzen du, eguneratu egin behar da, eta Helm-ek horretan laguntzen du eta horretarako neurri eta politika egokiak ekartzen saiatzen da.
Poltsa egitea modu argian dago antolatuta: Linux, Windows edo MacOS-erako paketeen kudeatzaile arrunt baten lanarekin bat datozen metadatuak daude. Hau da, biltegi bat, hainbat paketeren menpekotasunak, aplikazioen meta informazioa, ezarpenak, konfigurazio funtzioak, informazioaren indexazioa, etab. Helm-ek hori guztia aplikazioetarako eskuratu eta erabiltzeko aukera ematen du.
Konplexutasunaren kudeaketa. Mota bereko aplikazio asko badituzu, parametrizazioa behar da. Txantiloiak hortik datoz, baina txantiloiak sortzeko zure modua asmatu beharrik ez izateko, Helm-ek eskaintzen duena erabil dezakezu.
Aplikazioaren bizi-zikloaren kudeaketa - nire ustez, hau da galderarik interesgarriena eta konpondu gabekoa. Horregatik etorri nintzen Helmera garai hartan. Aplikazioaren bizi-zikloa kontrolatu behar genuen eta gure CI/CD eta aplikazio-zikloak paradigma honetara eraman nahi genituen.
Helm-ek aukera ematen dizu:
- inplementazioak kudeatu, konfigurazio eta berrikuspen kontzeptua sartzen du;
- atzera egitea arrakastaz;
- erabili amuak ekitaldi ezberdinetarako;
- gehitu aplikazioen egiaztapen gehigarriak eta erantzun haien emaitzei.
Gainera Helm-ek "pilak" ditu - Plugin moduan sar daitezkeen gauza gozo ugari, zure bizitza erraztuz. Pluginak modu independentean idatz daitezke, nahiko isolatuak dira eta ez dute arkitektura harmoniatsurik behar. Zerbait inplementatu nahi baduzu, plugin gisa egitea gomendatzen dizut eta, ondoren, agian goran sartzea.
Helm hiru kontzeptu nagusitan oinarritzen da:
- Chart Repo β Zure manifestuarentzat posible den parametrizazioen deskribapena eta sorta.
- Config βhau da, aplikatuko diren balioak (testua, zenbakizko balioak, etab.).
- Askatu goiko bi osagaiak biltzen ditu, eta elkarrekin Release bihurtzen dira. Bertsioak bertsionatu daitezke, horrela antolatutako bizi-ziklo bat lortuz: txikiak instalatzen direnean eta handiak berritu, jaitsi edo atzera egiteko unean.
Helm arkitektura
Diagramak Helm-en goi-mailako arkitektura irudikatzen du kontzeptualki.
Gogorarazten dizut Helm Kubernetesekin lotutako zerbait dela. Hori dela eta, ezin dugu Kubernetes kluster (laukizuzena) gabe egin. Kube-apiserver osagaia maisuan dago. Helm gabe Kubeconfig dugu. Helm-ek bitar txiki bat ekartzen du, horrela deitu badiozu, Helm CLI utilitatea, ordenagailuan, ordenagailu eramangarrian, mainframean instalatuta dagoena - edozertan.
Baina hau ez da nahikoa. Helm-ek Tiller izeneko zerbitzari-osagai bat du. Helm-en interesak ordezkatzen ditu klusterraren barruan; Kubernetes klusterreko aplikazio bat da, beste edozein bezala.
Chart Repo-ren hurrengo osagaia diagramak dituen biltegi bat da. Biltegi ofizial bat dago, eta enpresa edo proiektu baten biltegi pribatu bat egon daiteke.
Elkarrekintza
Ikus dezagun nola elkarreragiten duten arkitekturako osagaiek Helm erabiliz aplikazio bat instalatu nahi dugunean.
- Hitz egiten ari gara
Helm install, sartu biltegian (Chart Repo) eta lortu Helm diagrama.
- Helm utilitatea (Helm CLI) Kubeconfig-ekin elkarreragiten du zein clusterrekin harremanetan jarri jakiteko.
- Informazio hori jasota, utilitateak gure klusterrean dagoen Tiller-i egiten dio erreferentzia aplikazio gisa.
- Tiller-ek Kube-apiserver-era deitzen du Kubernetes-en ekintzak egiteko, objektu batzuk sortzeko (zerbitzuak, pods, erreplikak, sekretuak, etab.).
Ondoren, diagrama zaildu egingo dugu Helm arkitektura osoa bere osotasunean jasan dezakeen eraso-bektorea ikusteko. Eta gero hura babesten saiatuko gara.
Eraso bektorea
Lehen puntu ahul potentziala da API pribilegiatua-erabiltzaileak. Eskemaren zati gisa, Helm CLIrako administratzaile sarbidea lortu duen hacker bat da.
Pribilegiorik gabeko API erabiltzailea arriskua ere sor dezake gertu nonbait baldin badago. Erabiltzaile horrek beste testuinguru bat izango du, adibidez, Kubeconfig ezarpenetan kluster izen-espazio batean finkatu daiteke.
Eraso-bektorerik interesgarriena Tillertik gertu dagoen kluster batean bizi den prozesu bat izan daiteke eta bertara sar daiteke. Hau klusterren sare-ingurunea ikusten duen web zerbitzaria edo mikrozerbitzua izan daiteke.
Eraso aldaera exotiko, baina gero eta ezagunagoa, Chart Repo dakar. Eskrupulurik gabeko egile batek sortutako taulak baliabide seguruak izan ditzake, eta fedez hartuz osatuko duzu. Edo biltegi ofizialetik deskargatzen duzun diagrama ordezkatu dezake eta, adibidez, baliabide bat sor dezake politika moduan eta haren sarbidea areagotu.
Saia gaitezen lau alde hauetako erasoak uxatzen eta asma dezagun Helm arkitekturan arazoak non dauden, eta, agian, non dauden.
Handitu dezagun diagrama, gehitu elementu gehiago, baina mantendu oinarrizko osagai guztiak.
Helm CLI Chart Repo-rekin komunikatzen da, Kubeconfig-ekin elkarreragin egiten du eta lana klusterera transferitzen da Tiller osagaira.
Tiller bi objektuk adierazten dute:
- Tiller-deploy svc, zerbitzu jakin bat erakusten duena;
- Tiller-deploy pod (diagraman kopia bakarrean erreplika batean), zeinetan karga osoa exekutatzen den, zeina klusterera sartzen den.
Interakziorako protokolo eta eskema desberdinak erabiltzen dira. Segurtasunaren ikuspuntutik, interesatzen zaigu gehien:
- Helm CLI-k diagrama-errepositoriora sartzeko duen mekanismoa: zer protokolo, autentifikaziorik dagoen eta zer egin daitekeen horrekin.
- Helm CLI, kubectl erabiliz, Tiller-ekin komunikatzen duen protokoloa. Hau kluster barruan instalatutako RPC zerbitzari bat da.
- Tiller bera klusterrean bizi diren eta Kube-apiserver-ekin elkarreragiten duten mikrozerbitzuentzat eskuragarri dago.
Azter ditzagun arlo guzti hauek ordenan.
RBAC
Helm-en edo klusterreko beste edozein zerbitzuren segurtasunez hitz egiteak ez du balio RBAC gaituta ez badago.
Badirudi hau ez dela azken gomendioa, baina ziur nago jende askok oraindik ez duela RBAC gaituta produkzioan ere, zalaparta handia baita eta gauza asko konfiguratu behar direlako. Hala ere, hau egitera animatzen zaitut.
β RBACeko webguneko abokatua. Material interesgarri ugari ditu, RBAC konfiguratzen lagunduko dizutena, zergatik den ona eta, funtsean, nola bizi den ekoizpenean.
Tiller eta RBAC nola funtzionatzen duten azaltzen saiatuko naiz. Tiller-ek kluster barruan lan egiten du zerbitzu-kontu jakin baten pean. Normalean, RBAC konfiguratuta ez badago, hau izango da supererabiltzailea. Oinarrizko konfigurazioan, Tiller administratzailea izango da. Horregatik esan ohi da Tiller zure klustererako SSH tunel bat dela. Izan ere, hori egia da, beraz, aparteko zerbitzu-kontu dedikatu bat erabil dezakezu goiko diagramako Zerbitzu-kontu lehenetsiaren ordez.
Helm hasieratzen duzunean eta zerbitzarian lehen aldiz instalatzen duzunean, zerbitzu-kontua ezar dezakezu erabiliz --service-account. Horri esker, beharrezkoa den gutxieneko eskubide multzoa duen erabiltzaile bat erabili ahal izango duzu. Egia da, halako "girlanda" bat sortu beharko duzu: Role eta RoleBinding.
Zoritxarrez, Helmek ez dizu hau egingo. Zuk edo zure Kubernetes klusterreko administratzaileak Rol eta RoleBindings multzo bat prestatu behar duzu zerbitzu-konturako aldez aurretik Helm gainditzeko.
Galdera sortzen da: zein da Role eta ClusterRole arteko aldea? Aldea da ClusterRole izen-espazio guztietan funtzionatzen duela, Roles eta RoleBinding arruntek ez bezala, izen-espazio espezializatu baterako soilik funtzionatzen dutenak. Kluster osorako eta izen-espazio guztietarako politikak konfigura ditzakezu, edo pertsonalizatuta izen-espazio bakoitzerako banan-banan.
Aipatzekoa da RBACk beste arazo handi bat konpontzen duela. Jende asko kexatzen da Helm, zoritxarrez, ez dela alokairu anitzeko (ez du onartzen alokairu anitzeko). Hainbat taldek kluster bat kontsumitzen badute eta Helm erabiltzen badute, funtsean, ezinezkoa da politikak konfiguratzea eta haien sarbidea mugatzea kluster honetan, Helm-ek exekutatzen duen zerbitzu-kontu jakin bat baitago eta klusterreko baliabide guztiak haren azpian sortzen dituelako. , batzuetan oso deserosoa. Hau egia da - fitxategi bitarra bera bezala, prozesua bezala, Helm Tiller-ek ez du maiztasun anitzeko kontzepturik.
Hala ere, Tiller kluster batean hainbat aldiz exekutatzeko aukera ematen duen modu bikaina dago. Honekin ez dago arazorik, Tiller izen-espazio guztietan abiarazi daiteke. Horrela, RBAC, Kubeconfig testuinguru gisa erabil ditzakezu eta Helm berezi baterako sarbidea mugatu.
Honela izango da.
Adibidez, talde ezberdinentzako testuingurua duten bi Kubeconfig daude (bi izen-espazio): X Team garapen-taldearentzat eta administratzaile-klusterra. Administratzaile-klusterrak bere Tiller zabala du, Kube-sistemaren izen-eremuan kokatuta dagoena, dagokion zerbitzu-kontu aurreratua. Eta garapen-taldearentzat izen-espazio bereizia, beren zerbitzuak izen-espazio berezi batean zabaldu ahal izango dituzte.
Planteamendu egokia da, Tiller-ek ez du hainbeste botere-gose zure aurrekontuan eragin handia izango duen. Hau da irtenbide azkarretako bat.
Anima zaitez Tiller bereizita konfiguratzeko eta Kubeconfig-i taldearen testuingurua emateko, garatzaile zehatz baterako edo ingurunerako: Dev, Staging, Production (zalantzazkoa da dena kluster berean egongo denik, hala ere, hori egin daiteke).
Gure istorioarekin jarraituz, RBACetik aldatu eta ConfigMaps-i buruz hitz egin dezagun.
ConfigMaps
Helm-ek ConfigMaps erabiltzen du datu biltegi gisa. Arkitekturari buruz hitz egin genuenean, ez zegoen inon datu-baserik kaleratzeei, konfigurazioei, atzeraegiteei eta abarri buruzko informazioa gordeko zuenik. Horretarako ConfigMaps erabiltzen da.
Ezaguna da ConfigMaps-en arazo nagusia - printzipioz ez dira seguruak; ezinezkoa da datu sentikorrak gordetzea. Zerbitzutik haratago joan behar ez den guztiaz ari gara, adibidez, pasahitzez. Helm-ek oraingoz berezkoena ConfigMaps erabiltzetik sekretuetara aldatzea da.
Hau oso erraz egiten da. Gainidatzi Tiller ezarpena eta zehaztu biltegiratzea sekretua izango dela. Ondoren, hedapen bakoitzeko ez duzu ConfigMap bat jasoko, sekretu bat baizik.
Sekretuak berak kontzeptu arraroa eta oso segurua ez direla argudiatu dezakezu. Hala ere, merezi du ulertzea Kuberneteseko garatzaileak beraiek egiten ari direla. 1.10 bertsiotik hasita, hau da. Aspalditik, posible da, hodei publikoetan behintzat, sekretuak gordetzeko biltegiratze egokia konektatzea. Taldea sekretuetarako sarbidea hobeto banatzeko moduak lantzen ari da orain.
Hobe da Storage Helm sekretuetara transferitzea, eta horiek, aldi berean, zentralki babestuta daude.
Noski geratuko da datuak biltegiratzeko muga 1 MB. Helm here etcd erabiltzen du ConfigMaps-en biltegiratze banatu gisa. Eta hor uste zuten hori erreplikatzeko datu-zati egokia zela, etab. Reddit-en honi buruzko eztabaida interesgarri bat dago, astebururako irakurketa dibertigarri hau aurkitzea edo laburpena irakurtzea gomendatzen dut .
Chart Repos
Grafikoak sozialki zaurgarrienak dira eta "Gizona erdian" iturri bihur daitezke, batez ere stock irtenbide bat erabiltzen baduzu. Lehenik eta behin, HTTP bidez azaltzen diren biltegiei buruz ari gara.
Helm Repo HTTPS bidez erakutsi behar duzu zalantzarik gabe - hau da aukerarik onena eta merkea da.
Kontuan izan diagramen sinadura mekanismoa. Teknologia oso erraza da. Hau GitHub-en erabiltzen duzun gauza bera da, gako publiko eta pribatuak dituen PGP makina arrunt batean. Konfiguratu eta ziurtatu, beharrezko gakoak edukiz eta dena sinatuz, hau benetan zure diagrama dela.
Horrez gain, Helm bezeroak TLS onartzen du (ez zerbitzariaren aldeko HTTP zentzuan, elkarrekiko TLS baizik). Zerbitzariaren eta bezeroaren gakoak erabil ditzakezu komunikatzeko. Egiari zor, ez dut horrelako mekanismorik erabiltzen, elkarrekiko ziurtagiriak ez zaizkidalako gustatzen. Funtsean, - Helm 2rako Helm Repo konfiguratzeko tresna nagusia - oinarrizko autentifikazioa ere onartzen du. Oinarrizko autentifikazioa erabil dezakezu erosoagoa eta isilagoa bada.
Plugin bat ere badago , Google Cloud Storage-n Chart Repos ostatatzeko aukera ematen duena. Hau nahiko erosoa da, ondo funtzionatzen du eta nahiko segurua da, deskribatutako mekanismo guztiak birziklatzen direlako.
HTTPS edo TLS gaitzen baduzu, mTLS erabiltzen eta oinarrizko autentifikazioa gaitzen baduzu arriskuak gehiago murrizteko, komunikazio kanal seguru bat lortuko duzu Helm CLI eta Chart Repo-rekin.
gRPC APIa
Hurrengo urratsa oso garrantzitsua da: Tiller ziurtatzea, klusterrean kokatuta dagoena eta, alde batetik, zerbitzaria dena, bestetik, beste osagai batzuetara sartzen da eta norbait dela itxuratzen saiatzen da.
Esan dudan bezala, Tiller gRPC erakusten duen zerbitzu bat da, Helm bezeroa gRPC bidez iristen da. Lehenespenez, noski, TLS desgaituta dago. Zergatik egin den galdera eztabaidagarria da, hasiera batean konfigurazioa erraztu behar duela iruditzen zait.
Ekoizpenerako eta baita eszenaratzeko ere, TLS gRPC-n gaitzea gomendatzen dut.
Nire ustez, diagrametarako mTLS ez bezala, hau egokia da hemen eta oso erraz egiten da: PQI azpiegitura bat sortu, ziurtagiri bat sortu, Tiller abiarazi, ziurtagiria hasieratzerakoan transferitu. Horren ondoren, Helm-en komando guztiak exekutatu ditzakezu, sortutako ziurtagiria eta gako pribatua aurkeztuz.
Horrela, klustertik kanpo Tiller-i egindako eskaera guztietatik babestuko zara.
Beraz, Tiller-ekin konexio-kanala ziurtatu dugu, dagoeneko RBAC eztabaidatu dugu eta Kubernetes apiserver-en eskubideak egokitu ditugu, elkarrekintzan jar dezakeen domeinua murriztuz.
Lema babestua
Ikus dezagun azken diagrama. Arkitektura bera da gezi berdinekin.
Konexio guztiak modu seguruan marraz daitezke berdez:
- Chart Repo-rako TLS edo mTLS eta oinarrizko autentifikazioa erabiltzen ditugu;
- Tiller-erako mTLS, eta TLS-rekin gRPC zerbitzu gisa azaltzen da, ziurtagiriak erabiltzen ditugu;
- klusterrak zerbitzu-kontu berezi bat erabiltzen du Role eta RoleBinding-ekin.
Klusterra nabarmen segurtatu dugu, baina norbaitek esan zuen:
"Erabat seguru irtenbide bakarra egon daiteke: itzalita dagoen ordenagailu bat, hormigoizko kutxa batean kokatuta dagoena eta soldaduek zaintzen dutena".
Datuak manipulatzeko eta eraso-bektore berriak aurkitzeko modu desberdinak daude. Hala ere, ziur nago gomendio hauek segurtasunerako oinarrizko industria estandarra lortuko dutela.
bonus
Zati hau ez dago zerikusi zuzena segurtasunarekin, baina erabilgarria izango da. Jende gutxik ezagutzen dituen gauza interesgarri batzuk erakutsiko dizkizut. Adibidez, nola bilatu diagramak - ofizialak eta ez ofizialak.
Biltegian Orain 300 grafiko inguru eta bi korronte daude: egonkorra eta inkubagailua. Ekartzen duenak ederki daki zein zaila den inkubagailutik ukuilura pasatzea, eta zein erraza den ukuilutik hegan egitea. Hala ere, hau ez da tresnarik onena Prometheus-en eta nahi duzun beste edozertarako grafikoak bilatzeko, arrazoi sinple batengatik: ez da paketeak eroso bilatzeko atari bat.
Baina bada zerbitzu bat , eta horrek diagramak aurkitzea askoz erosoagoa egiten du. Garrantzitsuena, kanpoko biltegi asko eta ia 800 xarma eskuragarri daude. Gainera, zure biltegia konekta dezakezu arrazoiren batengatik zure diagramak egonkor batera bidali nahi ez badituzu.
Probatu hub.helm.sh eta gara dezagun elkarrekin. Zerbitzu hau Helm proiektuaren menpe dago, eta bere UI-an ere lagundu dezakezu front-end garatzailea bazara eta itxura hobetu nahi baduzu.
Zure arreta ere deitu nahiko nuke Open Service Broker API integrazioa. Astuna eta argia dirudi, baina denek dituzten arazoak konpontzen ditu. Adibide erraz batekin azalduko dut.
Kubernetes kluster bat dago eta bertan aplikazio klasiko bat exekutatu nahi dugu - WordPress. Orokorrean, datu-base bat behar da funtzionaltasun osoa izateko. Hainbat irtenbide daude, adibidez, zure egoera osoa abiarazi dezakezu. Hau ez da oso erosoa, baina jende askok egiten du.
Beste batzuek, guk Chainstack-en bezala, MySQL edo PostgreSQL bezalako kudeatutako datu-baseak erabiltzen dituzte zerbitzarietarako. Horregatik, gure datu-baseak hodeian kokatuta daude.
Baina arazo bat sortzen da: gure zerbitzua datu-base batekin konektatu behar dugu, datu-basearen kutsua sortu, kredentziala transferitu eta nolabait kudeatu. Hori guztia eskuz egin ohi du sistemaren administratzaileak edo garatzaileak. Eta aplikazio gutxi daudenean ez dago arazorik. Asko daudenean, konbinatu bat behar duzu. Halako uzta-biltzaile bat dago - Service Broker da. Hodei publikoko kluster baterako plugin berezi bat erabiltzeko eta hornitzailearen baliabideak Broker bidez eskatzeko aukera ematen du, API bat balitz bezala. Horretarako, jatorrizko Kubernetes tresnak erabil ditzakezu.
Oso sinplea da. Kontsulta dezakezu, adibidez, Azure-n MySQL kudeatua oinarrizko maila batekin (hau konfiguratu daiteke). Azure APIa erabiliz, datu-basea sortu eta erabiltzeko prestatuko da. Ez duzu horretan oztopatu behar, plugina da honen arduraduna. Adibidez, OSBAk (Azure plugina) kredentziala itzuliko dio zerbitzuari eta Helm-i pasatuko dio. WordPress hodeiko MySQL-rekin erabili ahal izango duzu, kudeatutako datu-baseekin batere jorratu eta barruko zerbitzu egoeraz kezkatu gabe.
Helm-ek kola gisa jokatzen duela esan dezakegu, alde batetik zerbitzuak zabaltzeko aukera ematen duena, eta, bestetik, hodeiko hornitzaileen baliabideak kontsumitzen dituena.
Zure plugina idatzi dezakezu eta istorio osoa lokalean erabil dezakezu. Ondoren, zure plugina izango duzu Cloud hornitzaile korporatiborako. Ikuspegi hau probatzea gomendatzen dut, batez ere eskala handia baduzu eta funtzio baterako garapena, eszenaratzea edo azpiegitura osoa azkar zabaldu nahi baduzu. Horrek bizitza erraztuko die zure eragiketei edo DevOpsei.
Lehen aipatu dudan beste aurkikuntza bat da helm-gcs plugina, Google-buckets (objektuen biltegiratzea) erabiltzeko aukera ematen duena Helm diagramak gordetzeko.
Lau komando baino ez dituzu behar erabiltzen hasteko:
- instalatu plugina;
- abiarazi;
- ezarri bidea gcp-n dagoen ontzirako;
- grafikoak modu estandarrean argitaratzea.
Edertasuna da jatorrizko gcp metodoa erabiliko dela baimenerako. Zerbitzu-kontu bat, garatzaile-kontu bat, nahi duzuna erabil dezakezu. Oso erosoa da eta ez du ezer kostatzen funtzionatzeko. Zuk, ni bezala, opsless filosofia sustatzen baduzu, orduan hau oso erosoa izango da, batez ere talde txikientzat.
alternatibak
Helm ez da zerbitzuak kudeatzeko irtenbide bakarra. Galdera asko daude horri buruz, eta ziurrenik hirugarren bertsioa hain azkar agertu zen. Alternatibak badaudela noski.
Hauek soluzio espezializatuak izan daitezke, adibidez, Ksonnet edo Metapartikula. Zure azpiegiturak kudeatzeko tresna klasikoak (Ansible, Terraform, Chef, etab.) erabil ditzakezu hitz egin dudan helburu berberetarako.
Azkenik irtenbide bat dago , bere ospea gero eta handiagoa da.
Operator Framework kontuan hartu beharreko Helm alternatiba nagusia da.
CNCF eta Kubernetes-en jatorrizkoagoa da, baina sartzeko oztopoa askoz handiagoa da, gehiago programatu eta manifestuak gutxiago deskribatu behar dituzu.
Hainbat gehigarri daude, hala nola Draft, Scaffold. Bizitza asko errazten dute, adibidez, Helm bidaltzeko eta abiarazteko zikloa errazten dute garatzaileek proba-ingurune bat zabaltzeko. Ahalduntzaile deituko nieke.
Hona hemen dena non dagoen ikus-entzunezko taula.
X ardatzean gertatzen ari denaren gaineko zure kontrol pertsonalaren maila dago, y ardatzean Kubernetes-en jatorrizko maila. Helm 2. bertsioa erdian kokatzen da. 3. bertsioan, ez izugarri, baina bai kontrola eta bai natibotasun maila hobetu dira. Ksonnet mailan irtenbideak Helm 2 baino txikiagoak dira oraindik ere. Hala ere, merezi dute begiratzea mundu honetan zer dagoen jakiteko. Jakina, zure konfigurazio-kudeatzailea zure kontrolpean egongo da, baina ez da Kubernetes-en jatorrizkoa.
Operator Framework erabat Kubernetes-en berezkoa da eta askoz dotoreago eta zorrotzago kudeatzeko aukera ematen dizu (baina gogoratu sarrera mailaz). Aitzitik, hau egokia da aplikazio espezializatu baterako eta horren kudeaketa sortzeko, Helm erabiliz aplikazio kopuru handi bat ontziratzeko bilketa masibo bat baino.
Luzatzaileek kontrola apur bat hobetzen dute, lan-fluxua osatzen dute edo CI/CD kanalizazioetan ertzak mozten dituzte.
Helm-en etorkizuna
Albiste ona Helm 3 datorrela da. Helm 3.0.0-alpha.2-ren alfa bertsioa kaleratu da dagoeneko, probatu dezakezu. Nahiko egonkorra da, baina funtzionaltasuna mugatua da oraindik.
Zergatik behar duzu Helm 3? Lehenik eta behin, honi buruzko istorio bat da Tillerren desagerpena, osagai gisa. Hau, dagoeneko ulertzen duzun bezala, aurrerapauso itzela da, arkitekturaren segurtasunaren ikuspuntutik dena sinplifikatu delako.
Helm 2 sortu zenean, hau da, Kubernetes 1.8ren garaia edo lehenagokoa, kontzeptu asko heldugabeak ziren. Adibidez, CRD kontzeptua aktiboki inplementatzen ari da orain, eta Helm-ek egingo du erabili CRDegiturak gordetzeko. Bezeroa soilik erabiltzea posible izango da eta zerbitzariaren zatia ez mantentzea. Horren arabera, erabili jatorrizko Kubernetes komandoak egitura eta baliabideekin lan egiteko. Aurrerapauso itzela da hau.
Agertuko da OCI jatorrizko biltegietarako laguntza (Open Container Ekimena). Ekimen izugarria da eta Helm-i interesatzen zaio batez ere bere zerrendak argitaratzeko. Esaterako, Docker Hub-ek OCI estandar asko onartzen ditu. Ez dut asmatzen, baina agian Docker biltegi-hornitzaile klasikoak zure Helm diagramak ostatatzeko aukera ematen hasiko dira.
Niretzat istorio polemikoa da Lua laguntza, gidoiak idazteko txantiloi-motor gisa. Ez naiz Luaren zale handia, baina hau guztiz hautazkoa izango litzateke. Hau 3 aldiz egiaztatu nuen - Lua erabiltzea ez da beharrezkoa izango. Hori dela eta, Lua erabili ahal izan nahi dutenek, Go gustuko dutenek, bat egiten dute gure kanpamentu erraldoian eta go-tmpl erabiltzen dute horretarako.
Azkenik, zalantzarik gabe falta zitzaidana zen eskemaren agerpena eta datu motaren baliozkotzea. Ez da arazorik izango int edo string-ekin, ez da zero komatxo bikoitzetan bildu beharrik. Balioetarako hau esplizituki deskribatzeko aukera emango dizun JSONS eskema bat agertuko da.
Asko berrituko da gertaerak bultzatutako eredua. Dagoeneko kontzeptualki deskribatu da. Begira Helm 3 adarra, eta ikusiko duzu zenbat gertaera eta kako eta beste gauza gehitu diren, eta horrek asko erraztuko du eta, bestetik, hedapen prozesuen eta erreakzioen kontrola gehituko du.
Helm 3 sinpleagoa, seguruagoa eta dibertigarriagoa izango da, ez Helm 2 gustatzen ez zaigulako, Kubernetes gero eta aurreratuagoa delako baizik. Horren arabera, Helm-ek Kubernetesen garapenak erabil ditzake eta Kubernetesentzako kudeatzaile bikainak sor ditzake bertan.
Beste berri on bat hori da Alexander Khayorovek esango dizu: Gogora dezagun garapen, proba eta eragiketa prozesuen integrazioari buruzko konferentzia Moskun egingo dela. Irailaren 30ean eta urriaren 1ean. Oraindik egin dezakezu abuztuaren 20ra arte eta kontatu iezaguzu irtenbidearekin duzun esperientzia DevOps ikuspegiaren zereginak.
Jarraitu konferentziaren kontrol-puntuak eta albisteak helbidean ΠΈ .
Iturria: www.habr.com