🥇Die Helm-toestel en sy slaggate

Tyfon vragvervoerder konsep, Anton Swanepoel

My naam is Dmitri Sugrobov, ek is 'n ontwikkelaar by Leroy Merlin. In die artikel sal ek jou vertel hoekom Helm nodig is, hoe dit die werk met Kubernetes vergemaklik, wat in die derde weergawe verander het, en hoe om dit te gebruik om toepassings in produksie op te dateer sonder stilstand.

Hierdie is 'n opsomming gebaseer op 'n toespraak by 'n konferensie @Kubernetes Konferensie by Mail.ru Wolkoplossings As jy nie wil lees nie, kyk na die video.

Waarom ons Kubernetes in produksie gebruik

Leroy Merlin is die leier in die selfdoen-kleinhandelmark in Rusland en Europa. Ons maatskappy het meer as honderd ontwikkelaars, 33 000 interne werknemers en 'n groot aantal mense wat hipermarkte en die webwerf besoek. Om hulle almal gelukkig te maak, het ons besluit om by die industriestandaard te hou. Ontwikkel nuwe toepassings deur mikrodiensargitektuur te gebruik; houers gebruik om omgewings te isoleer en korrek af te lewer; en vir orkestrasie gebruik Kubernetes. Die prys van die gebruik van orkestreerders word vinnig goedkoper: die aantal ingenieurs wat die tegnologie besit, groei op die mark, en verskaffers verskyn Kubernetes as 'n diens.

Alles wat Kubernetes doen, kan natuurlik op ander maniere gedoen word, byvoorbeeld deur 'n paar Jenkins te smeer en docer-compose met skrifte, maar hoekom kompliseer die lewe as daar 'n klaargemaakte en betroubare oplossing is? Daarom het ons na Kubernetes gekom en gebruik dit nou al 'n jaar in produksie. Ons het nou vier-en-twintig Kubernetes-trosse, waarvan die oudste meer as 'n jaar oud is met ongeveer tweehonderd peule.

Die vloek van 'n groot aantal YAML-lêers in Kubernetes

Om 'n mikrodiens in Kubernetes te laat loop, sal ons ten minste vyf YAML-lêers skep: vir Ontplooiing, Diens, Ingang, ConfigMap, Secrets - en dit na die groep stuur. Vir die volgende toepassing sal ons dieselfde pakket yamliki skryf, met die derde - nog een, ensovoorts. Deur die aantal dokumente met die aantal omgewings te vermenigvuldig, kry ons reeds honderde lêers, en dit neem nie eers dinamiese omgewings in ag nie.

Adam Reese, Helm se kernonderhouer, het die konsep van "Ontwikkelingsiklus in Kubernetes", wat so lyk:

Kopieer YAML - kopieer 'n YAML-lêer.
Plak YAML - plak dit.
Maak inkepings reg - maak inkepings reg.
Herhaal - herhaal weer.

Die opsie werk, maar jy moet YAML-lêers baie keer kopieer. Om hierdie siklus te verander, het hulle met Helm vorendag gekom.

Wat is stuur

Eerstens, Helm pakketbestuurder, wat jou help om die programme wat jy nodig het te vind en te installeer. Om byvoorbeeld MongoDB te installeer, hoef jy nie na die amptelike webwerf te gaan en binaries af te laai nie, voer net die opdrag uit helm install stable/mongodb.

Tweedens, Helm - sjabloon enjin, help om lêers te parameteriseer. Kom ons keer terug na die situasie met YAML-lêers in Kubernetes. Dit is makliker om dieselfde YAML-lêer te skryf, voeg 'n paar plekhouers daarby, waarin Helm waardes sal vervang. Dit wil sê, in plaas van 'n groot stel yamliks, sal daar 'n stel sjablone (sjablone) wees waarin die nodige waardes op die regte tyd vervang sal word.

Derdens, Helm - ontplooiingstowenaar. Daarmee kan u toepassings installeer, terugrol en opdateer. Kom ons kyk hoe om dit te doen.

Hoe om Helm te gebruik om jou eie toepassings te ontplooi

Installeer die Helm-kliënt op die rekenaar, volg die amptelike instruksies. Dan sal ons 'n stel YAML-lêers skep. In plaas daarvan om spesifieke waardes te spesifiseer, laat ons plekhouers wat Helm in die toekoms met inligting sal invul. 'n Stel sulke lêers word 'n Helm-kaart genoem. Dit kan op drie maniere na die Helm-konsole-kliënt gestuur word:

spesifiseer 'n gids met sjablone;
pak in 'n .tar argief en wys daarna;
plaas die sjabloon in 'n afgeleë bewaarplek en voeg 'n skakel by die bewaarplek in die Helm-kliënt.

Jy benodig ook 'n lêer met waardes - values.yaml. Die data van daar sal in die sjabloon vervang word. Kom ons skep dit ook.

Die tweede weergawe van Helm het 'n bykomende bedienertoepassing genaamd Tiller. Dit hang buite Kubernetes en wag vir versoeke van die Helm-kliënt, en wanneer dit geroep word, vervang dit die nodige waardes in die sjabloon en stuur dit na Kubernetes.

Helm 3 is eenvoudiger: in plaas daarvan om sjablone op die bediener te verwerk, word die inligting nou heeltemal aan die kant van die Helm-kliënt verwerk en direk na die Kubernetes API gestuur. Hierdie vereenvoudiging verbeter die sekuriteit van die groepering en vergemaklik die ontplooiingskema.

Hoe dit alles werk

Voer die opdrag uit helm install. Spesifiseer die naam van die toepassingvrystelling, gee die pad na waardes.yaml. Aan die einde sal ons die bewaarplek spesifiseer wat die grafiek en die naam van die grafiek bevat. In die voorbeeld is dit onderskeidelik "lmru" en "bestchart".

helm install --name bestapp --values values.yaml lmru/bestchart

Uitvoering van die opdrag is slegs een keer moontlik, wanneer dit weer uitgevoer word in plaas van install moet gebruik upgrade. Vir eenvoud, in plaas van twee opdragte, kan jy die opdrag uitvoer upgrade met bykomende sleutel --install. By die eerste uitvoering sal Helm 'n opdrag stuur om die vrystelling te installeer, en sal dit in die toekoms opdateer.

helm upgrade --install bestapp --values values.yaml lmru/bestchart

Slaggate van die implementering van nuwe toepassingsweergawes met Helm

Op hierdie punt in die storie speel ek Wie wil 'n miljoenêr wees met die gehoor en ons is besig om uit te vind hoe om Helm te kry om die toepassingweergawe op te dateer. Kyk die video.

Toe ek Helm se werk bestudeer het, was ek verras deur die vreemde gedrag wanneer ek probeer het om weergawes van lopende toepassings op te dateer. Ek het die toepassingskode opgedateer, 'n nuwe prent na die docker-register opgelaai, die opdrag gestuur om te ontplooi - en niks het gebeur nie. Hieronder is 'n paar nie-so-goeie maniere om programme op te dateer. Deur elkeen van hulle in meer besonderhede te bestudeer, begin jy die interne struktuur van die instrument en die redes vir hierdie nie-vanselfsprekende gedrag verstaan.

Metode 1. Moenie inligting verander sedert die laaste lopie nie

Soos die spreekwoord sê amptelike webwerf Helm, "Kubernetes-kaarte kan groot en kompleks wees, so Helm probeer dinge so eenvoudig as moontlik hou." As u dus die nuutste weergawe van die toepassingsbeeld in die docker-register opdateer en die opdrag uitvoer helm upgrade, dan sal niks gebeur nie. Helm sal dink dat niks verander het nie en dat dit nie nodig is om 'n opdrag na Kubernetes te stuur om die toepassing op te dateer nie.

Hierna word die nuutste merker slegs as 'n voorbeeld getoon. Wanneer hierdie merker gespesifiseer is, sal Kubernetes elke keer die prent van die docker-register aflaai, ongeag die imagePullPolicy-parameter. Die gebruik van die nuutste in produksie is ongewens en veroorsaak newe-effekte.

Metode 2. Dateer LABEL in beeld op

Soos geskryf in dieselfde dokumentasie, "Helm sal slegs 'n toepassing opdateer as dit sedert die laaste vrystelling verander het." Die logiese opsie hiervoor sou wees om die ETIKET in die docker-beeld self op te dateer. Helm kyk egter nie na die toepassingsbeelde nie en is nie bewus van enige veranderinge daaraan nie. Gevolglik, wanneer etikette in die prent opgedateer word, sal Helm nie daarvan weet nie, en die toepassingsopdatering-opdrag sal nie in Kubernetes ontvang word nie.

Metode 3. Gebruik die sleutel --force

Kom ons blaai na die handleidings en soek die regte sleutel. Die sleutel wat die meeste sin maak --force. Ten spyte van die veelseggende naam, verskil die gedrag van wat verwag word. In plaas van 'n gedwonge opdatering van die toepassing, is die werklike doel daarvan om 'n vrystelling te herstel wat in die MISLUKT-status is. As jy nie hierdie sleutel gebruik nie, moet jy opeenvolgend opdragte uitvoer helm delete && helm install --replace. In plaas daarvan word voorgestel om die sleutel te gebruik --force, wat die opeenvolgende uitvoering van hierdie opdragte outomatiseer. Meer inligting hierin trek versoek. Om vir Helm te vertel om die weergawe van die toepassing op te dateer, sal hierdie sleutel ongelukkig nie werk nie.

Metode 4. Verander etikette direk in Kubernetes

Dateer etiket direk in groepie op met behulp van opdrag kubectl edit - slegte idee. Hierdie aksie sal lei tot inligting inkonsekwentheid tussen die lopende toepassing en die een wat oorspronklik gestuur is vir ontplooiing. Die gedrag van Helm tydens ontplooiing in hierdie geval verskil van sy weergawe: Helm 2 sal niks doen nie, en Helm 3 sal 'n nuwe weergawe van die toepassing ontplooi. Om te verstaan hoekom, moet jy verstaan hoe Helm werk.

Hoe Helm werk

Om te bepaal of 'n toepassing sedert die laaste vrystelling verander het, kan Helm gebruik:

'n lopende toepassing in Kubernetes;
nuwe waardes.yaml en huidige grafiek;
Helm se interne vrystelling-inligting.

Vir die mees nuuskieriges: waar stoor Helm interne vrystelling-inligting?Deur die opdrag uit te voer helm history, sal ons al die inligting kry oor die weergawes wat met Helm geïnstalleer is.

Daar is ook gedetailleerde inligting oor gestuurde patrone en waardes. Ons kan dit versoek:

In die tweede weergawe van Helm is hierdie inligting in dieselfde naamruimte waar Tiller loop (by verstek, kube-stelsel), in die ConfigMap, gemerk met die etiket "OWNER=TILLER":

Ten tyde van die verskyning van die derde weergawe van Helm, het die inligting ook na geheime verskuif na dieselfde naamruimte waar die toepassing loop. Danksy dit het dit moontlik geword om verskeie toepassings gelyktydig in verskillende naamruimtes met dieselfde vrystellingnaam te laat loop. In die tweede weergawe was dit 'n erge kopseer wanneer naamruimtes geïsoleer word, maar mekaar kan beïnvloed.

Die tweede stuur, wanneer hy probeer uitvind of 'n opdatering nodig is, gebruik slegs twee bronne van inligting: wat nou aan hom verskaf is, en interne inligting oor vrystellings, wat in die ConfigMap lê.

Die derde Helm gebruik 'n drierigting-samesmeltingstrategie: benewens daardie inligting, neem dit ook die toepassing in ag wat tans in Kubernetes loop.

Om hierdie rede sal die ou weergawe van Helm niks doen nie, aangesien dit nie die inligting van die toepassing in die cluster in ag neem nie, maar Helm 3 sal die veranderinge ontvang en die nuwe aansoek vir ontplooiing stuur.

Metode 5: Gebruik --recreate-pods-sleutel

Met 'n sleutel --recreate-pods jy kan bereik wat oorspronklik beplan is om verkry te word deur die sleutel te gebruik --force. Die houers sal herbegin en, volgens die imagePullPolicy: Always-beleid vir die nuutste merker (meer hieroor in die voetnoot hierbo), sal Kubernetes die nuwe weergawe van die prent aflaai en laat loop. Dit sal nie op die beste manier gedoen word nie: sonder om die strategietipe van die ontplooiing in ag te neem, sal dit al die ou toepassinggevalle skielik afskakel en nuwes begin begin. Tydens die herbegin sal die stelsel nie werk nie, gebruikers sal ly.

In Kubernetes self bestaan 'n soortgelyke probleem ook al lank. En nou, 4 jaar na die opening Issue, die probleem is reggestel, en begin met weergawe 1.15 van Kubernetes, verskyn die moontlikheid om peule te herbegin.

Helm skakel eenvoudig alle toepassings af en stel nuwe houers naby bekend. In produksie kan u dit nie doen nie, om nie 'n eenvoudige toepassing te veroorsaak nie. Dit is slegs nodig vir ontwikkelingsbehoeftes, dit kan slegs in verhoogomgewings gedoen word.

Hoe om die programweergawe op te dateer met Helm?

Ons sal die waardes wat aan Helm gestuur word, verander. Tipies is dit waardes wat vir die beeldmerker vervang word. In die geval van nuutste, wat dikwels vir nie-produktiewe omgewings gebruik word, dien die aantekening as veranderlike inligting, wat nutteloos is vir Kubernetes self, en vir Helm sal dit dien as 'n sein om die toepassing op te dateer. Aantekeningwaarde-vulopsies:

ewekansige waarde gebruik die standaardfunksie {{ randAlphaNum 6 }}.
Daar is 'n nuanse: na elke ontplooiing met behulp van 'n grafiek met so 'n veranderlike, sal die aantekeningwaarde uniek wees, en Helm sal aanvaar dat daar veranderinge is. Dit blyk dat ons altyd die toepassing sal herbegin, selfs al het ons nie die weergawe daarvan verander nie. Dit is nie krities nie, aangesien daar geen stilstand sal wees nie, maar steeds onaangenaam.
Voeg stroom in datum en tyd - {{ .Release.Date }}.
'n Variant is soos 'n ewekansige waarde met 'n permanent unieke veranderlike.
'n Beter manier is om te gebruik kontrolesomme. Dit is die SHA van die beeld of die SHA van die laaste commit in die git - {{ .Values.sha }}.
Hulle sal getel moet word en na die Helm-kliënt aan die roepende kant gestuur moet word, byvoorbeeld in Jenkins. As die toepassing verander het, sal die kontrolesom ook verander. Daarom sal Helm slegs die toepassing opdateer wanneer dit nodig is.

Kom ons som ons pogings op

Helm maak veranderinge op die minste indringende manier, so enige verandering op die toepassingsbeeldvlak in die Docker-register sal nie 'n opdatering tot gevolg hê nie: niks sal gebeur nadat die opdrag uitgevoer is nie.
sleutel --force gebruik om problematiese vrystellings te herstel en word nie met 'n gedwonge opgradering geassosieer nie.
sleutel --recreate-pods sal toepassings met geweld bywerk, maar sal dit op 'n vandale manier doen: dit sal alle houers skielik afskakel. Gebruikers sal hieraan ly, dit is nie die moeite werd om dit op die uitverkoping te doen nie.
Maak direk veranderinge aan die Kubernetes-kluster met behulp van die opdrag kubectl edit moenie: ons sal die konsekwentheid breek, en die gedrag sal verskil afhangende van die weergawe van Helm.
Met die vrystelling van die nuwe weergawe van Helm het baie nuanses verskyn. Kwessies in die Helm-bewaarplek word in duidelike taal beskryf, dit sal jou help om die besonderhede te verstaan.
Deur 'n veranderlike aantekening by 'n grafiek te voeg, sal dit meer buigsaam maak. Dit sal die toepassing toelaat om korrek uit te rol, sonder stilstand.

Gedagte uit die kategorie van "vrede in die wêreld", werk op alle terreine van die lewe: lees die instruksies voor gebruik, nie daarna nie. Slegs met volledige inligting sal dit moontlik wees om betroubare stelsels te bou en gebruikers gelukkig te maak.

Ander verwante skakels:

Hierdie verslag is die eerste keer aangebied by @Kubernetes Konferensie deur Mail.ru Cloud Solutions. Sien video ander optredes en teken in op aankondigings van gebeure in Telegram Rondom Kubernetes in Mail.ru Group.

Bron: will.com

Die Helm-toestel en sy slaggate