Mit navn er Dmitry Sugrobov, jeg er udvikler hos Leroy Merlin. I denne artikel vil jeg fortælle dig, hvorfor Helm er nødvendig, hvordan det forenkler arbejdet med Kubernetes, hvad der er ændret i den tredje version, og hvordan du bruger det til at opdatere applikationer i produktionen uden nedetid.
Dette er et resumé baseret på en tale på en konference by - hvis du ikke vil læse, så se videoen.
Hvorfor vi bruger Kubernetes i produktionen
Leroy Merlin er førende på DIY detailmarkedet i Rusland og Europa. Vores virksomhed har mere end hundrede udviklere, 33 interne medarbejdere og et stort antal mennesker, der besøger hypermarkeder og hjemmesiden. For at gøre dem alle glade besluttede vi at følge industristandardtilgange. Udvikle nye applikationer ved hjælp af mikroservicearkitektur; bruge beholdere til at isolere miljøer og sikre korrekt levering; og bruge Kubernetes til orkestrering. Prisen for at bruge orkestratorer bliver hurtigt billigere: Antallet af ingeniører, der er dygtige i teknologien, vokser på markedet, og udbydere dukker op, der tilbyder Kubernetes som en tjeneste.
Alt hvad Kubernetes laver, kan selvfølgelig gøres på andre måder, for eksempel ved at dække nogle Jenkins og docker-komponere med scripts, men hvorfor komplicere livet, hvis der er en færdiglavet og pålidelig løsning? Derfor kom vi til Kubernetes og har brugt det i produktionen i et år nu. Vi har i øjeblikket fireogtyve Kubernetes-klynger, hvoraf den ældste er mere end et år gammel, med omkring to hundrede bælg.
Forbandelsen af store YAML-filer i Kubernetes
For at lancere en mikrotjeneste i Kubernetes vil vi oprette mindst fem YAML-filer: til Deployment, Service, Ingress, ConfigMap, Secrets - og sende dem til klyngen. Til den næste ansøgning vil vi skrive den samme pakke med jambs, med den tredje vil vi skrive en anden, og så videre. Hvis vi gange antallet af dokumenter med antallet af miljøer, vil vi allerede få hundredvis af filer, og det tager endnu ikke højde for dynamiske miljøer.
Adam Reese, kernevedligeholder af Helm, introducerede konceptet "", som ser sådan ud:
- Kopier YAML - kopier en YAML-fil.
- Indsæt YAML - indsæt det.
- Fix Indents - fix indrykning.
- Gentag - gentag igen.
Indstillingen virker, men du skal kopiere YAML-filerne mange gange. For at ændre denne cyklus blev Helm opfundet.
Hvad er Helm
For det første, Helm - pakkeansvarlig, som hjælper dig med at finde og installere de programmer, du har brug for. For at installere for eksempel MongoDB behøver du ikke at gå til den officielle hjemmeside og downloade binære filer, bare køre kommandoen helm install stable/mongodb.
For det andet, Helm - skabelonmotor, hjælper med at parametrere filer. Lad os vende tilbage til situationen med YAML-filer i Kubernetes. Det er nemmere at skrive den samme YAML-fil, tilføje nogle pladsholdere til den, hvori Helm vil erstatte værdierne. Det vil sige, i stedet for et stort sæt stilladser, vil der være et sæt skabeloner, hvor de nødvendige værdier vil blive erstattet på det rigtige tidspunkt.
For det tredje, Helm - indsættelsesmester. Med den kan du installere, rulle tilbage og opdatere applikationer. Lad os finde ud af, hvordan man gør dette.
Sådan bruger du Helm til at implementere dine egne applikationer
Lad os installere Helm-klienten på din computer, efter den officielle . Dernæst opretter vi et sæt YAML-filer. I stedet for at angive specifikke værdier, vil vi efterlade pladsholdere, som Helm vil udfylde med information i fremtiden. Et sæt af sådanne filer kaldes et Helm-diagram. Det kan sendes til Helm-konsolklienten på tre måder:
- angiv en mappe med skabeloner;
- pak arkivet ind i en .tar og peg på det;
- læg skabelonen i et fjernlager og tilføj et link til lageret i Helm-klienten.
Du skal også bruge en fil med værdier - values.yaml. Dataene derfra vil blive indsat i skabelonen. Lad os også skabe det.
Den anden version af Helm har en ekstra serverapplikation - Tiller. Den hænger uden for Kubernetes og venter på anmodninger fra Helm-klienten, og når den kaldes, erstatter den de nødvendige værdier i skabelonen og sender den til Kubernetes.
Helm 3 er enklere: I stedet for at behandle skabeloner på serveren, behandles information nu udelukkende på Helm-klientsiden og sendes direkte til Kubernetes API. Denne forenkling forbedrer klyngesikkerheden og letter udrulningsordningen.
Hvordan fungerer det hele
Kør kommandoen helm install. Lad os angive navnet på applikationsudgivelsen og give stien til values.yaml. Til sidst vil vi angive arkivet, hvori kortet er placeret, og navnet på kortet. I eksemplet er disse henholdsvis "lmru" og "bestchart".
helm install --name bestapp --values values.yaml lmru/bestchart
Kommandoen kan kun udføres én gang, når den udføres igen i stedet install nødt til at bruge upgrade. For nemheds skyld kan du køre kommandoen i stedet for to kommandoer upgrade med ekstra nøgle --install. Når den udføres for første gang, vil Helm sende en kommando for at installere udgivelsen og opdatere den i fremtiden.
helm upgrade --install bestapp --values values.yaml lmru/bestchart
Faldgruberne ved at implementere nye versioner af en applikation med Helm
På dette tidspunkt i historien spiller jeg Who Wants to Be a Millionaire med publikum, og vi er ved at finde ud af, hvordan vi får Helm til at opdatere versionen af appen. .
Da jeg lærte, hvordan Helm fungerer, blev jeg overrasket over mærkelig adfærd, når jeg forsøgte at opdatere versioner af kørende applikationer. Jeg opdaterede applikationskoden, uploadede et nyt billede til Docker-registret, sendte implementeringskommandoen - og der skete ikke noget. Nedenfor er nogle ikke helt vellykkede måder at opdatere applikationer på. Ved at studere hver af dem mere detaljeret begynder du at forstå instrumentets interne struktur og årsagerne til denne ikke indlysende adfærd.
Metode 1. Ændre ikke information siden sidste lancering
Som man siger Helm, "Kubernetes-diagrammer kan være store og komplekse, så Helm prøver ikke at røre noget for meget." Derfor, hvis du opdaterer den seneste version af applikationsbilledet i docker-registret og kører kommandoen helm upgrade, så sker der ikke noget. Helm vil tro, at intet er ændret, og der er ingen grund til at sende en kommando til Kubernetes for at opdatere applikationen.
Her og nedenfor vises det seneste tag udelukkende som eksempel. Når du angiver dette tag, vil Kubernetes downloade billedet fra docker-registret hver gang, uanset parameteren imagePullPolicy. Brug af seneste i produktionen er uønsket og forårsager bivirkninger.
Metode 2. Opdater LABEL i billedet
Som skrevet i samme , "Helm vil kun opdatere en applikation, hvis den er ændret siden sidste udgivelse." En logisk mulighed for dette synes at være at opdatere LABEL i selve docker-billedet. Helm ser dog ikke på applikationsbillederne og har ingen anelse om ændringer i dem. Ved opdatering af etiketter i billedet vil Helm derfor ikke vide om dem, og kommandoen til applikationsopdatering vil ikke blive sendt til Kubernetes.
Metode 3: Brug en nøgle --force
Lad os gå til manualerne og se efter den nødvendige nøgle. Nøglen giver mest mening --force. På trods af det åbenlyse navn er adfærden anderledes end forventet. I stedet for at tvinge en applikationsopdatering er dens egentlige formål at gendanne en udgivelse, der er i FAILED-status. Hvis du ikke bruger denne nøgle, skal du udføre kommandoerne sekventielt helm delete && helm install --replace. Det foreslås at bruge nøglen i stedet for --force, som automatiserer den sekventielle udførelse af disse kommandoer. Mere information i denne . For at bede Helm om at opdatere applikationsversionen, vil denne nøgle desværre ikke virke.
Metode 4. Skift etiketter direkte i Kubernetes
Opdatering af label direkte i klyngen ved hjælp af kommandoen kubectl edit - dårlig idé. Denne handling vil føre til uoverensstemmelse mellem den kørende applikation og den, der oprindeligt blev sendt til implementering. Helm's adfærd under implementeringen i dette tilfælde adskiller sig fra dens version: Helm 2 vil ikke gøre noget, og Helm 3 vil implementere den nye version af applikationen. For at forstå hvorfor, skal du forstå, hvordan Helm fungerer.
Hvordan virker Helm?
For at afgøre, om en applikation er ændret siden dens sidste udgivelse, kan Helm bruge:
- kører applikation i Kubernetes;
- nye værdier.yaml og nuværende diagram;
- Helms interne frigivelsesoplysninger.
For de mere nysgerrige: hvor gemmer Helm interne oplysninger om udgivelser?Ved at udføre kommandoen helm history, vil vi få alle oplysninger om de versioner, der er installeret ved hjælp af Helm.
Der er også detaljeret information om de tilsendte skabeloner og værdier. Vi kan anmode om det:
I den anden version af Helm er denne information placeret i det samme navneområde, hvor Tiller kører (kube-system som standard), i ConfigMap, markeret med etiketten "OWNER=TILLER":
Da den tredje version af Helm dukkede op, flyttede informationen til hemmeligheder og til det samme navneområde, hvor applikationen kørte. Takket være dette blev det muligt at køre flere applikationer samtidigt i forskellige navneområder med samme udgivelsesnavn. I den anden version var det en alvorlig hovedpine, når navneområder er isolerede, men kan påvirke hinanden.
Det andet Helm, når det forsøger at forstå, om der er behov for en opdatering, bruger kun to informationskilder: hvad der leveres til det nu, og intern information om udgivelser, som ligger i ConfigMap.
Den tredje Helm bruger en tre-vejs flettestrategi: Ud over den information tager den også højde for den applikation, der kører lige nu i Kubernetes.
Af denne grund vil den gamle version af Helm ikke gøre noget, da den ikke tager højde for applikationsoplysningerne i klyngen, men Helm 3 vil modtage ændringerne og sende den nye applikation til implementering.
Metode 5. Brug --recreate-pods-kontakten
Med en nøgle --recreate-pods du kan opnå, hvad du oprindeligt planlagde at opnå med nøglen --force. Containerne vil genstarte, og ifølge imagePullPolicy: Always policy for the latest tag (mere om dette i fodnoten ovenfor), vil Kubernetes downloade og lancere en ny version af billedet. Dette vil ikke blive gjort på den bedste måde: uden at tage hensyn til strategitypen for implementering, vil det brat slukke for alle gamle applikationsforekomster og begynde at lancere nye. Under genstarten vil systemet ikke fungere, brugerne vil lide.
I selve Kubernetes eksisterede et lignende problem også i lang tid. Og nu, 4 år efter åbningen , problemet er blevet rettet, og fra og med version 1.15 af Kubernetes vises muligheden for at rulle-genstarte pods.
Helm slukker ganske enkelt alle applikationer og lancerer nye containere i nærheden. Du kan ikke gøre dette i produktionen, for ikke at forårsage nedetid for applikationen. Dette er kun nødvendigt til udviklingsbehov og kan kun udføres i scenemiljøer.
Hvordan opdaterer man applikationsversionen ved hjælp af Helm?
Vi vil ændre værdierne sendt til Helm. Typisk er disse værdier, der erstattes af billedtagget. I tilfælde af nyeste, som ofte bruges til uproduktive miljøer, er den udskiftelige information en annotering, som er ubrugelig for Kubernetes selv, og for Helm vil den fungere som et signal om behovet for at opdatere applikationen. Muligheder for at udfylde anmærkningsværdien:
- Tilfældig værdi ved at bruge standardfunktionen -
{{ randAlphaNum 6 }}.
Der er en advarsel: Efter hver implementering ved hjælp af et diagram med en sådan variabel, vil annotationsværdien være unik, og Helm vil antage, at der er ændringer. Det viser sig, at vi altid vil genstarte applikationen, selvom vi ikke har ændret dens version. Dette er ikke kritisk, da der ikke vil være nogen nedetid, men det er stadig ubehageligt. - Indsæt nuværende dato og tid —
{{ .Release.Date }}.
En variant ligner en tilfældig værdi med en permanent unik variabel. - En mere korrekt måde er at bruge kontrolsummer. Dette er SHA for billedet eller SHA for den sidste commit i git -
{{ .Values.sha }}.
De skal tælles og sendes til Helm-klienten på den kaldende side, for eksempel i Jenkins. Hvis applikationen er ændret, ændres kontrolsummen. Derfor vil Helm kun opdatere applikationen, når det er nødvendigt.
Lad os opsummere vores forsøg
- Helm foretager ændringer på den mindst invasive måde, så enhver ændring på applikationsbilledeniveauet i Docker Registry vil ikke resultere i en opdatering: intet vil ske efter kommandoen er udført.
- nøgle
--forcebruges til at gendanne problematiske udgivelser og er ikke forbundet med tvungne opdateringer. - nøgle
--recreate-podsvil kraftigt opdatere applikationer, men vil gøre det på en vandalisk måde: det vil brat slukke for alle containere. Brugere vil lide under dette; du bør ikke gøre dette i produktionen. - Foretag ændringer direkte til Kubernetes-klyngen ved hjælp af kommandoen
kubectl editikke: Vi vil bryde konsistensen, og adfærden vil variere afhængigt af versionen af Helm. - Med udgivelsen af den nye version af Helm er der dukket mange nuancer op. Problemer i Helm repository er beskrevet i et klart sprog, de vil hjælpe dig med at forstå detaljerne.
- Tilføjelse af en redigerbar annotering til et diagram vil gøre det mere fleksibelt. Dette giver dig mulighed for at udrulle applikationen korrekt uden nedetid.
En "verdensfred"-tanke, der virker på alle områder af livet: læs brugsanvisningen før brug, ikke efter. Kun med fuldstændig information vil det være muligt at bygge pålidelige systemer og gøre brugerne glade.
Andre relaterede links:
Denne rapport blev første gang præsenteret kl af Mail.ru Cloud Solutions. Se andre forestillinger og abonner på begivenhedsannonceringer på Telegram .
Kilde: www.habr.com