Nire izena Dmitry Sugrobov da, Leroy Merlinen garatzailea naiz. Artikulu honetan Helm zergatik behar den esango dizut, nola errazten duen Kubernetesekin lan egitea, zer aldatu den hirugarren bertsioan eta nola erabili produkzioan aplikazioak etenaldirik gabe eguneratzeko.
Kongresu bateko hitzaldi batean oinarritutako laburpena da hau by β Irakurri nahi ez baduzu, ikusi bideoa.
Zergatik erabiltzen dugu Kubernetes ekoizpenean
Leroy Merlin Errusian eta Europan brikolaje txikizkako merkatuan liderra da. Gure enpresak ehun garatzaile baino gehiago ditu, 33 barne-langile eta hipermerkatuak eta webgunea bisitatzen dituen jende kopuru handia. Guztiak zoriontsu izateko, industriako ikuspegi estandarrak jarraitzea erabaki genuen. Aplikazio berriak garatzea mikrozerbitzuen arkitektura erabiliz; ontziak erabiltzea inguruneak isolatzeko eta entrega egokia ziurtatzeko; eta erabili Kubernetes orkestraziorako. Orkestratzaileak erabiltzearen prezioa azkar ari da merketzen: teknologian trebeak diren ingeniarien kopurua hazten ari da merkatuan, eta hornitzaileak agertzen ari dira Kubernetes zerbitzu gisa eskaintzen.
Kubernetes-ek egiten duen guztia, noski, beste modu batzuetan egin daiteke, adibidez, Jenkins batzuk eta docker-compose scriptekin estaliz, baina zergatik zaildu bizitza prest dagoen irtenbide fidagarri bat badago? Horregatik etorri ginen Kubernetesera eta urtebete daramagu produkzioan erabiltzen. Gaur egun, hogeita lau Kubernetes kluster ditugu, zaharrenak urtebete baino gehiagokoa, berrehun leka ingururekin.
Kubernetes-en YAML fitxategi handien madarikazioa
Kubernetes-en mikrozerbitzu bat abiarazteko, gutxienez bost YAML fitxategi sortuko ditugu: Deployment, Service, Ingress, ConfigMap, Secrets - eta klusterera bidaliko ditugu. Hurrengo aplikaziorako jamba pakete bera idatziko dugu, hirugarrenarekin beste bat idatziko dugu, eta abar. Dokumentu kopurua ingurune kopuruaz biderkatzen badugu, dagoeneko ehunka fitxategi lortuko ditugu, eta hori oraindik ez da ingurune dinamikoak kontuan hartzen.
Adam Reese-k, Helm-en oinarrizko mantentzaileak, " kontzeptua aurkeztu zuen", itxura hau:
- Kopiatu YAML - kopiatu YAML fitxategi bat.
- Itsatsi YAML - itsatsi.
- Konpondu koskak - konpondu koskak.
- Errepikatu - errepikatu berriro.
Aukerak funtzionatzen du, baina YAML fitxategiak askotan kopiatu behar dituzu. Ziklo hori aldatzeko, Helm asmatu zen.
Zer da Helm
Lehenik eta behin, Helm - paketeen kudeatzailea, behar dituzun programak aurkitzen eta instalatzen laguntzen dizu. Instalatzeko, adibidez, MongoDB, ez duzu webgune ofizialera joan eta bitarrak deskargatu beharrik, exekutatu komandoa. helm install stable/mongodb.
Bigarrenik, Helm - txantiloi motorra, fitxategiak parametrizatzen laguntzen du. Itzuli gaitezen Kubernetes-en YAML fitxategien egoerara. Errazagoa da YAML fitxategi bera idaztea, leku-markak gehitzea, Helm-ek balioak ordezkatuko dituena. Hau da, aldamio-multzo handi baten ordez, txantiloi-multzo bat egongo da eta bertan behar diren balioak une egokian ordezkatuko dira.
Hirugarrenik, Helm - hedapen maisua. Berarekin aplikazioak instalatu, atzera egin eta eguneratu ditzakezu. Asma dezagun hau nola egin.
Helm nola erabili zure aplikazioak zabaltzeko
Instala dezagun Helm bezeroa zure ordenagailuan, ofizialari jarraituz . Ondoren, YAML fitxategi multzo bat sortuko dugu. Balio zehatzak zehaztu beharrean, leku-markak utziko ditugu, Helm-ek informazioz beteko dituenak etorkizunean. Fitxategi horietako multzo bati Helm diagrama deitzen zaio. Helm kontsola bezeroari hiru modutara bidali daiteke:
- txantiloiekin karpeta bat adierazi;
- paketatu artxiboa .tar batean eta seinalatu;
- jarri txantiloia urruneko biltegi batean eta gehitu esteka Helm bezeroan biltegira.
Balioak dituen fitxategi bat ere behar duzu - values.yaml. Bertako datuak txantiloian txertatuko dira. Sor dezagun ere.
Helm-en bigarren bertsioak zerbitzari-aplikazio gehigarri bat du - Tiller. Kubernetesetik kanpo zintzilikatzen da eta Helm bezeroaren eskaeren zain dago, eta deitzen denean, beharrezko balioak txantiloian ordezkatzen ditu eta Kubernetesera bidaltzen du.
Helm 3 sinpleagoa da: zerbitzarian txantiloiak prozesatu beharrean, Helm bezeroaren aldean informazioa prozesatzen da eta zuzenean Kubernetes APIra bidaltzen da. Sinplifikazio honek klusterraren segurtasuna hobetzen du eta zabaltze-eskema errazten du.
Nola funtzionatzen du dena
Exekutatu komandoa helm install. Adierazi dezagun aplikazioaren bertsioaren izena eta eman dezagun bidea values.yaml. Amaieran diagrama zein biltegia dagoen eta diagramaren izena adieraziko dugu. Adibidean, "lmru" eta "bestchart" dira, hurrenez hurren.
helm install --name bestapp --values values.yaml lmru/bestchart
Komandoa behin bakarrik exekutatu daiteke, berriro exekutatzen denean install erabili behar upgrade. Sinpletasuna lortzeko, bi komandoren ordez, komandoa exekutatu dezakezu upgrade giltza gehigarriarekin --install. Lehen aldiz exekutatzen denean, Helmek komando bat bidaliko du bertsioa instalatzeko, eta etorkizunean eguneratuko du.
helm upgrade --install bestapp --values values.yaml lmru/bestchart
Helm-ekin aplikazio baten bertsio berriak zabaltzeak dituen zailtasunak
Istorioaren une honetan, Who Wants to Be a Millionaire jolasten ari naiz ikus-entzuleekin, eta Helm-ek aplikazioaren bertsioa egunera dezan nola lortu asmatzen ari gara. .
Helm-ek nola funtzionatzen duen ikasten ari nintzela, exekutatzen ari diren aplikazioen bertsioak eguneratzen saiatzean jokaera arraroak harritu ninduen. Aplikazioaren kodea eguneratu nuen, irudi berri bat igo nuen Docker erregistrora, inplementazio komandoa bidali nuen, eta ez zen ezer gertatu. Jarraian, aplikazioak eguneratzeko guztiz arrakastatsuak ez diren modu batzuk daude. Horietako bakoitza zehatzago aztertuz, tresnaren barne-egitura eta agerikoa ez den portaera horren arrazoiak ulertzen hasten zara.
1. metodoa. Ez aldatu informaziorik azken abiarazi zenetik
Esaten den bezala Helm, "Kubernetes diagramak handiak eta konplexuak izan daitezke, beraz Helm saiatzen da ezer gehiegi ez ukitzen". Hori dela eta, docker erregistroan aplikazioaren irudiaren azken bertsioa eguneratzen baduzu eta komandoa exekutatzen baduzu helm upgrade, orduan ez da ezer gertatuko. Helmek pentsatuko du ez dela ezer aldatu eta ez dagoela komandorik bidali behar Kubernetesera aplikazioa eguneratzeko.
Hemen eta behean, azken etiketa adibide gisa bakarrik erakusten da. Etiketa hau zehazten duzunean, Kubernetes-ek docker erregistrotik deskargatuko du irudia aldi bakoitzean, imagePullPolicy parametroa edozein dela ere. Ekoizpen berriena erabiltzea ez da desiragarria eta albo-ondorioak eragiten ditu.
2. metodoa. Eguneratu LABEL irudian
berean idatzita dagoen bezala , "Helm-ek aplikazio bat eguneratuko du azken bertsiotik aldatu bada." Horretarako aukera logiko bat docker irudian bertan LABEL eguneratzea izango litzateke. Hala ere, Helm-ek ez ditu aplikazioaren irudiak aztertzen eta ez du ideiarik izan horien aldaketarik. Horren arabera, irudiko etiketak eguneratzean, Helm-ek ez du horien berri izango eta aplikazioak eguneratzeko komandoa ez da Kubernetesera bidaliko.
3. metodoa: Erabili tekla bat --force
Jo dezagun eskuliburuetara eta bilatu behar dugun giltza. Giltzak zentzurik handiena du --force. Izen agerikoa izan arren, jokabidea espero zenetik ezberdina da. Aplikazioa eguneratzea behartu beharrean, bere benetako helburua FAILED egoeran dagoen bertsio bat berreskuratzea da. Ez baduzu tekla hau erabiltzen, aginduak sekuentzialki exekutatu behar dituzu helm delete && helm install --replace. Horren ordez tekla erabiltzea gomendatzen da --force, komando horien exekuzio sekuentziala automatizatzen duena. Informazio gehiago honetan . Helm-i aplikazioaren bertsioa eguneratzeko esateko, zoritxarrez, gako honek ez du funtzionatuko.
4. metodoa. Aldatu etiketak zuzenean Kubernetes-en
Etiketa zuzenean klusterrean eguneratzen komandoa erabiliz kubectl edit - ideia txarra. Ekintza honek exekutatzen ari den aplikazioaren eta jatorriz hedatzera bidalitakoaren arteko informazio-inkoherentzia ekarriko du. Helm-en portaera inplementazioan zehar kasu honetan bere bertsiotik desberdina da: Helm 2-k ez du ezer egingo eta Helm 3-k aplikazioaren bertsio berria zabalduko du. Zergatik ulertzeko, Helm-ek nola funtzionatzen duen ulertu behar duzu.
Nola funtzionatzen du Helm-ek?
Azken bertsiotik aplikazio bat aldatu den zehazteko, Helm-ek:
- Kubernetesen aplikazioa exekutatzen;
- balio berriak.yaml eta egungo diagrama;
- Helm-en barne-oharrari buruzko informazioa.
Jakin-mina dutenentzat: non gordetzen du Helm-ek bertsioen barne-informazioa?Komandoa exekutatuz helm history, Helm erabiliz instalatutako bertsioei buruzko informazio guztia jasoko dugu.
Bidalitako txantiloiei eta balioei buruzko informazio zehatza ere badago. Eska dezakegu:
Helm-en bigarren bertsioan, informazio hori Tiller exekutatzen ari den izen-espazio berean dago (kube-system lehenespenez), ConfigMap-en, "OWNER=TILLER" etiketarekin markatuta:
Helm-en hirugarren bertsioa agertu zenean, informazioa sekretuetara eraman zen, eta aplikazioa exekutatzen ari zen izen-eremu berera. Horri esker, hainbat aplikazio aldi berean exekutatzeko aukera izan zen bertsio-izen berdina zuten izen-espazio ezberdinetan. Bigarren bertsioan buruhauste larria izan zen izen-espazioak isolatuta daudenean baina elkarrengan eragina izan dezaketenean.
Bigarren Helm-ek, eguneraketa behar den ala ez ulertzen saiatzean, bi informazio iturri baino ez ditu erabiltzen: orain ematen zaiona eta bertsioei buruzko barne informazioa, ConfigMap-en dagoena.
Hirugarren Helm-ek hiru norabideko batzeko estrategia erabiltzen du: informazio horretaz gain, Kubernetesen oraintxe exekutatzen ari den aplikazioa ere hartzen du kontuan.
Horregatik, Helm-en bertsio zaharrak ez du ezer egingo, ez baitu klusterreko aplikazioaren informazioa kontuan hartzen, baina Helm 3-k aldaketak jasoko ditu eta aplikazio berria bidaliko du zabaltzeko.
5. metodoa. Erabili --recreate-pods etengailua
Giltza batekin --recreate-pods giltzarekin hasiera batean aurreikusitakoa lor dezakezu --force. Ontziak berrabiaraziko dira eta, imagePullPolicy: beti azken etiketari buruzko politikaren arabera (goiko oin-oharrean honi buruzko informazio gehiago), Kubernetes-ek irudiaren bertsio berri bat deskargatu eta abiaraziko du. Hau ez da modurik onenean egingo: inplementazio StrategyType kontuan hartu gabe, bat-batean aplikazio zaharren instantzia guztiak itzaliko ditu eta berriak abiarazten hasiko dira. Berrabiarazi bitartean, sistemak ez du funtzionatuko, erabiltzaileek sufrituko dute.
Kubernetesen bertan ere antzeko arazo bat egon zen aspalditik. Eta orain, inauguraziotik 4 urtera , arazoa konpondu da, eta Kubernetes-en 1.15 bertsioarekin hasita, lekak berrabiarazteko gaitasuna agertzen da.
Helm-ek aplikazio guztiak itzali eta edukiontzi berriak abiarazten ditu inguruan. Ezin duzu hau egin produkzioan, aplikazioen geldialdi-denbora ez sortzeko. Hau garapen-beharretarako bakarrik behar da eta ingurune eszenikoetan bakarrik egin daiteke.
Nola eguneratu aplikazioaren bertsioa Helm erabiliz?
Helm-era bidalitako balioak aldatuko ditugu. Normalean, irudiaren etiketaren ordez ordezkatzen diren balioak dira. Azkenengoaren kasuan, ingurune ez-produktiboetarako erabili ohi dena, informazio aldagarria oharpen bat da, eta hori alferrikakoa da Kubernetesentzat berarentzat, eta Helmentzat aplikazioa eguneratu beharraren seinale gisa jokatuko du. Oharpen-balioa betetzeko aukerak:
- Ausazko balioa funtzio estandarra erabiliz -
{{ randAlphaNum 6 }}.
Oharra dago: inplementazio bakoitzaren ondoren, aldagai hori duen diagrama bat erabiliz, oharpen-balioa bakarra izango da, eta Helmek aldaketak daudela suposatuko du. Ematen du beti berrabiaraziko dugula aplikazioa, bere bertsioa aldatu ez badugu ere. Hau ez da kritikoa, ez baita geldialdirik egongo, baina oraindik desatsegina da. - Itsatsi korrontea data eta ordua -
{{ .Release.Date }}.
Aldaera bat betirako aldagai bakarra duen ausazko balio baten antzekoa da. - Modu zuzenagoa erabiltzea da checksumak. Hau da irudiaren SHA edo git-eko azken konpromisoaren SHA -
{{ .Values.sha }}.
Deien aldean zenbatu eta Helm bezeroari bidali beharko zaizkio, adibidez Jenkins-en. Aplikazioa aldatu bada, checksuma aldatuko da. Beraz, Helm-ek aplikazioa behar denean soilik eguneratuko du.
Labur ditzagun gure saiakerak
- Helm-ek modurik inbaditzaile txikienean egiten ditu aldaketak, beraz, Docker Erregistroko aplikazioaren irudi mailan egindako edozein aldaketak ez du eguneratzerik ekarriko: komandoa exekutatu ondoren ez da ezer gertatuko.
- gakoa
--forcebertsio problematikoak leheneratzeko erabiltzen da eta ez dago behartutako eguneratzeekin lotuta. - gakoa
--recreate-podsindarrez eguneratuko ditu aplikazioak, baina modu bandaloan egingo ditu: bat-batean ontzi guztiak itzaliko ditu. Erabiltzaileek hori jasango dute; ez zenuke hori egin behar ekoizpenean. - Zuzenean egin aldaketak Kubernetes klusterrean komandoa erabiliz
kubectl editez egin: koherentzia hautsiko dugu, eta portaera desberdina izango da Helm-en bertsioaren arabera. - Helm-en bertsio berria kaleratzearekin batera, Γ±abardura asko agertu dira. Helm biltegian dauden arazoak hizkuntza argian deskribatzen dira, xehetasunak ulertzen lagunduko dizute.
- Grafiko bati ohar editagarri bat gehitzeak malgutu egingo du. Honek aplikazioa behar bezala zabaltzeko aukera emango dizu, geldialdirik gabe.
Bizitzako arlo guztietan funtzionatzen duen βmunduko bakeaβ pentsamendu bat: irakurri argibideak erabili aurretik, ez ondoren. Informazio osoarekin bakarrik izango da posible sistema fidagarriak eraikitzea eta erabiltzaileak zoriontsu izatea.
Erlazionatutako beste estekak:
Txosten hau lehen aldiz aurkeztu zen Mail.ru Cloud Solutions-en eskutik. Begira beste emanaldi batzuk eta harpidetu Telegram-en ekitaldien iragarpenetara .
Iturria: www.habr.com