Mitt navn er Dmitry Sugrobov, og jeg er utvikler hos Leroy Merlin. I denne artikkelen vil jeg fortelle deg hvorfor du trenger Helm, hvordan det forenkler arbeidet med Kubernetes, hva som har endret seg i den tredje versjonen, og hvordan du bruker den til å oppdatere applikasjoner i produksjon uten nedetid.
Dette er et sammendrag basert på et foredrag holdt på en konferanse. by – Hvis du ikke vil lese, se videoen.
Hvorfor vi bruker Kubernetes i produksjon
Leroy Merlin er en ledende aktør innen gjør-det-selv-markedet i Russland og Europa. Selskapet vårt har over hundre utviklere, 33 000 interne ansatte og et stort antall besøkende på hypermarkeder og nettsiden. For å gjøre dem alle fornøyde, bestemte vi oss for å holde oss til standardmetoder i bransjen. Utvikle nye applikasjoner ved hjelp av en mikrotjenestearkitektur; bruke containere for å isolere miljøer og sikre riktig levering; og bruke Kubernetes til orkestrering. Kostnaden ved å bruke orkestratorer synker raskt: antallet ingeniører som eier teknologien vokser på markedet, og det dukker opp leverandører som tilbyr Kubernetes som en tjeneste.
Alt Kubernetes gjør kan selvfølgelig gjøres på andre måter, for eksempel ved å belegge noen Jenkins- og Docker-Compose-skript, men hvorfor komplisere livet hvis det finnes en ferdig og pålitelig løsning? Det er derfor vi kom til Kubernetes og har brukt det i produksjon i et år nå. Vi har for tiden tjuefire Kubernetes-klynger, hvorav den eldste er over et år gammel, med omtrent to hundre pods.
Forbannelsen av for mange YAML-filer i Kubernetes
For å lansere en mikrotjeneste i Kubernetes, oppretter vi minst fem YAML-filer: for Deployment, Service, Ingress, ConfigMap, Secrets – og sender dem til klyngen. For den neste applikasjonen skriver vi den samme pakken med yaml-filer, den tredje – en til, og så videre. Ved å multiplisere antall dokumenter med antall miljøer, får vi allerede hundrevis av filer, og dette tar ikke engang hensyn til dynamiske miljøer.
Adam Reese, Helms kjernevedlikeholder, introduserte konseptet med "", som ser slik ut:
- Kopier YAML – kopier en YAML-fil.
- Lim inn YAML – sett det inn.
- Fiks innrykk – fiks innrykk.
- Gjenta – gjenta igjen.
Alternativet fungerer, men du må kopiere YAML-filer mange ganger. Helm ble oppfunnet for å endre denne syklusen.
Hva er Helm
Først av alt er Helm pakkeansvarlig, som hjelper med å finne og installere de nødvendige programmene. For å installere for eksempel MongoDB trenger du ikke å gå til det offisielle nettstedet og laste ned binærfiler, bare kjør kommandoen helm install stable/mongodb.
For det andre, Helm - malmotor, hjelper med å parameterisere filer. La oss gå tilbake til situasjonen med YAML-filer i Kubernetes. Det er enklere å skrive den samme YAML-filen, legge til noen plassholdere i den, som Helm vil erstatte verdier i. Det vil si at i stedet for et stort sett med yaml-filer, vil det være et sett med maler (templates), som de nødvendige verdiene vil bli erstattet i til rett tid.
For det tredje, Helm - DistribusjonsmesterMed hjelpen kan du installere, rulle tilbake og oppdatere applikasjoner. La oss finne ut hvordan du gjør dette.
Slik bruker du Helm til å distribuere dine egne applikasjoner
La oss installere Helm-klienten på datamaskinen din ved å følge de offisielle instruksjonene. Deretter oppretter vi et sett med YAML-filer. I stedet for å spesifisere spesifikke verdier, legger vi igjen plassholdere som Helm vil fylle med informasjon i fremtiden. Et sett med slike filer kalles et Helm-diagram. Det kan sendes til Helm-konsollklienten på tre måter:
- angi en mappe med maler;
- pakk inn i et .tar-arkiv og pek på det;
- plasser malen i et eksternt repository og legg til en lenke til repositoryet i Helm-klienten.
Du trenger også en fil med verdier – values.yaml. Dataene derfra vil bli satt inn i malen. La oss lage den også.
Den andre versjonen av Helm har en ekstra serverapplikasjon – Tiller. Den henger utenfor Kubernetes og venter på forespørsler fra Helm-klienten, og når den kalles, setter den inn de nødvendige verdiene i malen og sender dem til Kubernetes.
Helm 3 er enklere: i stedet for å behandle maler på serveren, behandles informasjonen nå utelukkende på Helm-klientsiden og sendes direkte til Kubernetes API. Denne forenklingen forbedrer klyngesikkerheten og gjør distribusjonsprosessen enklere.
Hvordan det hele fungerer
Kjør kommandoen helm installVi spesifiserer navnet på applikasjonsutgivelsen og gir banen til values.yaml. Til slutt spesifiserer vi depotet der diagrammet ligger og navnet på diagrammet. I eksemplet er disse henholdsvis "lmru" og "bestchart".
helm install --name bestapp --values values.yaml lmru/bestchart
Kommandoen kan bare utføres én gang, når den utføres igjen i stedet for install trenger å bruke upgradeFor enkelhets skyld kan du utføre kommandoen i stedet for to kommandoer upgrade med ekstra nøkkel --installNår Helm kjøres for første gang, sender den en kommando for å installere utgivelsen, og vil oppdatere den i fremtiden.
helm upgrade --install bestapp --values values.yaml lmru/bestchart
Fallgruver ved å distribuere nye versjoner av et program med Helm
På dette tidspunktet i historien spiller jeg Hvem vil bli millionær med publikum, og vi finner ut hvordan vi kan få Helm til å oppdatere versjonen av appen. .
Da jeg studerte Helms arbeid, ble jeg overrasket over den merkelige oppførselen når jeg prøvde å oppdatere versjoner av applikasjoner som kjører. Jeg oppdaterte applikasjonskoden, lastet opp et nytt bilde til Docker-registeret, sendte en kommando om å distribuere – og ingenting skjedde. Nedenfor er flere måter å oppdatere applikasjoner på, som ikke er helt vellykkede. Ved å studere hver av dem mer detaljert, begynner du å forstå verktøyets interne struktur og årsakene til slik ikke-åpenbar oppførsel.
Metode 1. Ikke endre informasjonen siden siste oppstart
Som det står Helm, «Kubernetes-diagrammer kan være store og komplekse, så Helm prøver å ikke røre noe unødvendig.» Så hvis du oppdaterer den nyeste versjonen av applikasjonsavbildningen i docker-registeret og kjører kommandoen helm upgrade, så vil ingenting skje. Helm vil tro at ingenting har endret seg, og det er ikke nødvendig å sende en kommando til Kubernetes for å oppdatere applikasjonen.
Her og nedenfor vises den nyeste taggen kun som et eksempel. Når denne taggen er spesifisert, vil Kubernetes laste ned bildet fra docker-registeret hver gang, uavhengig av imagePullPolicy-parameteren. Å bruke den nyeste i produksjon er uønsket og forårsaker bivirkninger.
Metode 2. Oppdater LABEL i bildet
Som skrevet i samme , «Helm vil bare oppdatere et program hvis det har endret seg siden forrige utgivelse.» Det logiske alternativet for dette ville være å oppdatere LABEL-etiketten i selve Docker-avbildningen. Helm ser imidlertid ikke på programavbildninger og har ingen anelse om eventuelle endringer i dem. Følgelig, når etiketter i et avbildning oppdateres, vil ikke Helm vite om dem, og kommandoen for å oppdatere programmet i Kubernetes vil ikke bli sendt.
Metode 3. Bruk nøkkelen --force
La oss slå opp i manualene og se etter den riktige nøkkelen. Nøkkelen som passer best til betydningen er --forceTil tross for det selvforklarende navnet, er virkemåten annerledes enn det du forventer. I stedet for å tvinge frem en programoppdatering, er dens egentlige formål å gjenopprette en utgivelse som har statusen FEILET. Hvis du ikke bruker denne nøkkelen, må du utføre kommandoene sekvensielt. helm delete && helm install --replaceDet anbefales å bruke nøkkelen i stedet. --force, som automatiserer den sekvensielle utførelsen av disse kommandoene. Mer informasjon i denne Dessverre vil ikke denne nøkkelen fungere for å fortelle Helm at den skal oppdatere programversjonen.
Metode 4. Endre etiketter direkte i Kubernetes
Oppdatere etiketter direkte i klyngen ved hjelp av kommandoen kubectl edit — er en dårlig idé. Denne handlingen vil føre til inkonsekvens i informasjonen mellom det kjørende programmet og det som opprinnelig ble sendt for distribusjon. Helms oppførsel under distribusjonen er i dette tilfellet forskjellig fra versjonen: Helm 2 vil ikke gjøre noe, og Helm 3 vil distribuere en ny versjon av programmet. For å forstå årsaken må du forstå hvordan Helm fungerer.
Hvordan hjelmen fungerer
For å finne ut om et program har endret seg siden forrige utgivelse, kan Helm bruke:
- kjøre applikasjon i Kubernetes;
- nye values.yaml og gjeldende diagram;
- Intern Helm-informasjon om utgivelser.
For de nysgjerrige: hvor lagrer Helm intern utgivelsesinformasjon?Etter å ha utført kommandoen helm history, vil vi få all informasjon om versjonene som er installert med Helm.
Det finnes også detaljert informasjon om de sendte malene og verdiene. Vi kan be om det:
I den andre versjonen av Helm ligger denne informasjonen i samme navneområde der Tiller kjører (som standard kube-system), i ConfigMap merket med etiketten «OWNER=TILLER»:
Da Helm 3 kom ut, ble informasjonen flyttet til hemmeligheter, og til samme navneområde der applikasjonen kjørte. Dette gjorde det mulig å kjøre flere applikasjoner samtidig i forskjellige navnerom med samme utgivelsesnavn. I Helm 2 var dette et stort problem da navnerom var isolert, men kunne påvirke hverandre.
Den andre Helm-versjonen bruker bare to informasjonskilder når den prøver å finne ut om en oppdatering er nødvendig: det den for øyeblikket leveres med, og den interne utgivelsesinformasjonen som finnes i ConfigMap.
Den tredje Helm-en bruker en treveis sammenslåingsstrategi: i tillegg til denne informasjonen tar den også hensyn til applikasjonen som for øyeblikket kjører i Kubernetes.
Av denne grunn vil den gamle versjonen av Helm ikke gjøre noe, siden den ikke tar hensyn til applikasjonsinformasjonen i klyngen, men Helm 3 vil motta endringene og sende den nye applikasjonen for distribusjon.
Metode 5. Bruk --recreate-pods-nøkkelen
Med hjelp av en nøkkel --recreate-pods det er mulig å oppnå det som opprinnelig var planlagt å oppnå ved hjelp av nøkkelen --forceContainerne vil starte på nytt, og i henhold til imagePullPolicy: Always-policyen for den nyeste taggen (se fotnoten ovenfor), vil Kubernetes laste ned og starte den nye versjonen av imaget. Dette vil gjøres på en ikke fullt så god måte: uten å ta hensyn til deployment StrategyType, vil den brått stenge ned alle gamle applikasjonsinstanser og starte nye. Under omstarten vil ikke systemet fungere, og brukerne vil lide.
I Kubernetes selv eksisterte et lignende problem også lenge. Og nå, fire år etter oppdagelsen , problemet ble løst, og fra og med Kubernetes versjon 1.15 er det mulig å starte pods på nytt med rullering.
Helm slår ganske enkelt av alle applikasjoner og starter nye containere i nærheten. Dette kan ikke gjøres i produksjon, for å unngå nedetid i applikasjoner. Dette er kun nødvendig for utviklingsformål, og kan bare gjøres i scenemiljøer.
Hvordan oppdaterer jeg programversjonen ved hjelp av Helm?
Vi vil endre verdiene som sendes til Helm. Vanligvis er dette verdier som erstatter bildekoden. Når det gjelder latest, som ofte brukes i ikke-produksjonsmiljøer, er den endrede informasjonen en annotasjon, som er ubrukelig for Kubernetes selv, men for Helm vil den fungere som et signal om behovet for å oppdatere applikasjonen. Alternativer for å fylle ut annotasjonsverdien:
- Tilfeldig verdi ved å bruke standardfunksjonen -
{{ randAlphaNum 6 }}.
Det er en nyanse: etter hver distribusjon ved bruk av et diagram med en slik variabel, vil annotasjonsverdien være unik, og Helm vil anta at det er endringer. Det viser seg at vi alltid vil starte applikasjonen på nytt, selv om vi ikke har endret versjonen. Dette er ikke kritisk, siden det ikke vil være noen nedetid, men det er fortsatt ubehagelig. - Sett inn strøm dato og klokkeslett -
{{ .Release.Date }}.
Varianten ligner på en tilfeldig verdi med en permanent unik variabel. - En mer korrekt måte er å bruke sjekksummerDette er SHA-en til bildet eller SHA-en til den siste commit-en i git —
{{ .Values.sha }}.
De må beregnes og sendes til Helm-klienten på den kallende siden, for eksempel i Jenkins. Hvis applikasjonen har endret seg, vil også sjekksummen endres. Derfor vil Helm bare oppdatere applikasjonen når det er nødvendig.
La oss oppsummere forsøkene våre
- Helm gjør endringer på den minst invasive måten, så endringer på applikasjonsavbildningsnivå i Docker-registret vil ikke resultere i en oppdatering: ingenting vil skje etter at kommandoen er kjørt.
- Ключ
--forcebrukes til å gjenopprette problematiske utgivelser og er ikke knyttet til tvungen oppdatering. - Ключ
--recreate-podsvil tvinge frem oppdatering av applikasjoner, men vil gjøre det på en vandalistisk måte: slå brått av alle containere. Brukere vil lide av dette, det er ikke verdt å gjøre dette i produksjon. - Gjør endringer direkte i en Kubernetes-klynge ved hjelp av kommandoen
kubectl editikke nødvendig: vi vil bryte konsistensen, og oppførselen vil variere avhengig av Helm-versjonen. - Med utgivelsen av den nye versjonen av Helm har det dukket opp mange nyanser. Problemer i Helm-repositoriet er beskrevet på et tydelig språk, slik at de vil bidra til å forstå detaljene.
- Å legge til en endringsbar annotering i diagrammet vil gjøre det mer fleksibelt. Dette vil tillate at applikasjonen distribueres riktig, uten nedetid.
En «verdensfred»-idé som fungerer på alle områder av livet: les bruksanvisningen før bruk, ikke etterpå. Bare med fullstendig informasjon kan du bygge pålitelige systemer og gjøre brukerne fornøyde.
Andre lenker om emnet:
Denne rapporten ble først presentert kl av Mail.ru Cloud Solutions. Se andre forestillinger og abonner på begivenhetskunngjøringer på Telegram .
Kilde: www.habr.com
