Mitt navn er Dmitry Sugrobov, jeg er utvikler hos Leroy Merlin. I denne artikkelen skal jeg fortelle deg hvorfor Helm er nødvendig, hvordan det forenkler arbeidet med Kubernetes, hva som har endret seg i den tredje versjonen, og hvordan du bruker det til å oppdatere applikasjoner i produksjon uten nedetid.
Dette er et sammendrag basert på en tale på en konferanse by – hvis du ikke vil lese, se videoen.
Hvorfor vi bruker Kubernetes i produksjon
Leroy Merlin er ledende innen DIY detaljhandelsmarkedet i Russland og Europa. Vårt firma har mer enn hundre utviklere, 33 000 interne ansatte og et stort antall mennesker som besøker hypermarkeder og nettsiden. For å gjøre dem alle fornøyde, bestemte vi oss for å følge industristandardtilnærminger. Utvikle nye applikasjoner ved hjelp av mikrotjenestearkitektur; bruke beholdere for å isolere miljøer og sikre riktig levering; og bruk Kubernetes til orkestrering. Prisen for å bruke orkestratorer blir raskt billigere: Antallet ingeniører som er dyktige i teknologien vokser på markedet, og det dukker opp tilbydere som tilbyr Kubernetes som en tjeneste.
Alt Kubernetes gjør kan selvfølgelig gjøres på andre måter, for eksempel ved å dekke noen Jenkins og docker-komponere med skript, men hvorfor komplisere livet hvis det finnes en ferdig og pålitelig løsning? Derfor kom vi til Kubernetes og har brukt det i produksjon i et år nå. Vi har for tiden tjuefire Kubernetes-klynger, hvorav den eldste er mer enn ett år gammel, med omtrent to hundre belger.
Forbannelsen til store YAML-filer i Kubernetes
For å lansere en mikrotjeneste i Kubernetes vil vi opprette minst fem YAML-filer: for Deployment, Service, Ingress, ConfigMap, Secrets - og sende dem til klyngen. For neste søknad vil vi skrive den samme pakken med jambs, med den tredje vil vi skrive en annen, og så videre. Hvis vi multipliserer antall dokumenter med antall miljøer, vil vi allerede få hundrevis av filer, og dette tar ennå ikke hensyn til dynamiske miljøer.
Adam Reese, kjernevedlikeholder av Helm, introduserte konseptet "", som ser slik ut:
- Kopier YAML - kopier en YAML-fil.
- Lim inn YAML - lim inn.
- Fiks innrykk - fiks innrykk.
- Gjenta - gjenta igjen.
Alternativet fungerer, men du må kopiere YAML-filene mange ganger. For å endre denne syklusen ble Helm oppfunnet.
Hva er Helm
For det første, Helm - pakkeansvarlig, som hjelper deg med å finne og installere programmene du trenger. For å installere for eksempel MongoDB, trenger du ikke gå til den offisielle nettsiden og laste ned binærfiler, bare kjør kommandoen helm install stable/mongodb.
For det andre, Helm - malmotor, hjelper til med å parameterisere filer. La oss gå tilbake til situasjonen med YAML-filer i Kubernetes. Det er lettere å skrive den samme YAML-filen, legge til noen plassholdere i den, der Helm vil erstatte verdiene. Det vil si at i stedet for et stort sett med stillaser, vil det være et sett med maler der de nødvendige verdiene vil bli erstattet til rett tid.
For det tredje, Helm - utplasseringsmester. Med den 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, etter den offisielle . Deretter lager vi et sett med YAML-filer. I stedet for å spesifisere spesifikke verdier, vil vi forlate plassholdere, som Helm vil fylle med informasjon i fremtiden. Et sett med slike filer kalles et Helm-diagram. Den kan sendes til Helm-konsollklienten på tre måter:
- angi en mappe med maler;
- pakk arkivet inn i en .tar og pek på det;
- legg malen i et eksternt depot og legg til en lenke til depotet i Helm-klienten.
Du trenger også en fil med verdier - values.yaml. Dataene derfra vil bli satt inn i malen. La oss lage det 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, erstatter den de nødvendige verdiene i malen og sender den til Kubernetes.
Helm 3 er enklere: i stedet for å behandle maler på serveren, blir informasjon nå behandlet helt på Helm-klientsiden og sendt direkte til Kubernetes API. Denne forenklingen forbedrer klyngesikkerheten og letter utrullingsordningen.
Hvordan fungerer det hele
Kjør kommandoen helm install. La oss angi navnet på applikasjonsutgivelsen og gi banen til values.yaml. På slutten vil vi indikere depotet der kartet er plassert og navnet på kartet. 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 på nytt i stedet install trenger å bruke upgrade. For enkelhets skyld kan du kjøre kommandoen i stedet for to kommandoer upgrade med ekstra nøkkel --install. Når den kjøres for første gang, vil Helm sende en kommando for å installere utgivelsen, og vil oppdatere den i fremtiden.
helm upgrade --install bestapp --values values.yaml lmru/bestchart
Fallgruvene ved å distribuere nye versjoner av en applikasjon med Helm
På dette tidspunktet i historien spiller jeg Who Wants to Be a Millionaire med publikum, og vi finner ut hvordan vi kan få Helm til å oppdatere versjonen av appen. .
Da jeg lærte hvordan Helm fungerer, ble jeg overrasket over merkelig oppførsel når jeg prøvde å oppdatere versjoner av applikasjoner som kjører. Jeg oppdaterte applikasjonskoden, lastet opp et nytt bilde til Docker-registeret, sendte distribusjonskommandoen – og ingenting skjedde. Nedenfor er noen ikke helt vellykkede måter å oppdatere applikasjoner på. Ved å studere hver av dem mer detaljert, begynner du å forstå den interne strukturen til instrumentet og årsakene til denne ikke åpenbare oppførselen.
Metode 1. Ikke endre informasjon siden forrige lansering
Som det står Helm, "Kubernetes-diagrammer kan være store og komplekse, så Helm prøver å ikke røre noe for mye." Derfor, hvis du oppdaterer den nyeste versjonen av applikasjonsbildet i docker-registeret og kjører kommandoen helm upgrade, da skjer det ingenting. 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 siste taggen kun som et eksempel. Når du spesifiserer denne taggen, vil Kubernetes laste ned bildet fra docker-registeret hver gang, uavhengig av imagePullPolicy-parameteren. Bruk av det siste innen produksjon er uønsket og forårsaker bivirkninger.
Metode 2. Oppdater LABEL i bildet
Som skrevet i det samme , "Helm vil bare oppdatere en applikasjon hvis den har endret seg siden forrige utgivelse." Et logisk alternativ for dette ser ut til å være å oppdatere LABEL i selve docker-bildet. Helm ser imidlertid ikke på applikasjonsbildene og har ingen anelse om endringer i dem. Følgelig, når du oppdaterer etiketter i bildet, vil ikke Helm vite om dem, og applikasjonsoppdateringskommandoen vil ikke bli sendt til Kubernetes.
Metode 3: Bruk en nøkkel --force
La oss gå til håndbøkene og se etter den nødvendige nøkkelen. Nøkkelen gir mest mening --force. Til tross for det åpenbare navnet, er oppførselen annerledes enn forventet. I stedet for å tvinge en applikasjonsoppdatering, er dens egentlige formål å gjenopprette en utgivelse som er i MISLYKT-status. Hvis du ikke bruker denne nøkkelen, må du utføre kommandoene sekvensielt helm delete && helm install --replace. Det anbefales å bruke nøkkelen i stedet --force, som automatiserer sekvensiell kjøring av disse kommandoene. Mer informasjon i denne . For å fortelle Helm å oppdatere applikasjonsversjonen, vil dessverre ikke denne nøkkelen fungere.
Metode 4. Endre etiketter direkte i Kubernetes
Oppdaterer etiketten direkte i klyngen ved hjelp av kommandoen kubectl edit - dårlig ide. Denne handlingen vil føre til inkonsekvens av informasjon mellom den kjørende applikasjonen og den som opprinnelig ble sendt for distribusjon. Oppførselen til Helm under distribusjon i dette tilfellet er forskjellig fra versjonen: Helm 2 vil ikke gjøre noe, og Helm 3 vil distribuere den nye versjonen av applikasjonen. For å forstå hvorfor, må du forstå hvordan Helm fungerer.
Hvordan fungerer Helm?
For å finne ut om en applikasjon har endret seg siden den siste utgivelsen, kan Helm bruke:
- kjører applikasjon i Kubernetes;
- nye verdier.yaml og gjeldende diagram;
- Helms interne utgivelsesinformasjon.
For de mer nysgjerrige: hvor lagrer Helm intern informasjon om utgivelser?Ved å utføre kommandoen helm history, vil vi få all informasjon om versjonene som er installert med Helm.
Det er også detaljert informasjon om de sendte malene og verdiene. Vi kan be om det:
I den andre versjonen av Helm er denne informasjonen plassert i samme navneområde der Tiller kjører (kube-system som standard), i ConfigMap, merket med etiketten "OWNER=TILLER":
Da den tredje versjonen av Helm dukket opp, flyttet informasjonen til hemmeligheter og til samme navneområde der applikasjonen kjørte. Takket være dette ble det mulig å kjøre flere applikasjoner samtidig i forskjellige navneområder med samme utgivelsesnavn. I den andre versjonen var det en alvorlig hodepine når navneområder er isolert, men kan påvirke hverandre.
Den andre Helm, når den prøver å forstå om en oppdatering er nødvendig, bruker bare to informasjonskilder: hva som er gitt til den nå, og intern informasjon om utgivelser, som ligger i ConfigMap.
Den tredje Helm bruker en treveis flettestrategi: i tillegg til den informasjonen tar den også hensyn til applikasjonen som kjører akkurat nå 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-bryteren
Med en nøkkel --recreate-pods du kan oppnå det du opprinnelig planla å oppnå med nøkkelen --force. Beholderne vil starte på nytt, og i henhold til imagePullPolicy: Always policy for den nyeste taggen (mer om dette i fotnoten ovenfor), vil Kubernetes laste ned og lansere en ny versjon av bildet. Dette vil ikke bli gjort på den beste måten: uten å ta hensyn til StrategyType for distribusjon, vil det brått slå av alle gamle applikasjonsforekomster og begynne å lansere nye. Under omstart vil systemet ikke fungere, brukere vil lide.
I selve Kubernetes eksisterte også et lignende problem lenge. Og nå, 4 år etter åpningen , problemet er løst, og fra og med versjon 1.15 av Kubernetes, vises muligheten til å starte pods på nytt.
Helm slår ganske enkelt av alle applikasjoner og lanserer nye beholdere i nærheten. Du kan ikke gjøre dette i produksjonen, for ikke å forårsake nedetid for programmet. Dette er kun nødvendig for utviklingsbehov og kan kun utføres i scenemiljøer.
Hvordan oppdatere applikasjonsversjonen ved hjelp av Helm?
Vi vil endre verdiene som sendes til Helm. Vanligvis er dette verdier som erstattes i stedet for bildekoden. Når det gjelder nyeste, som ofte brukes for uproduktive miljøer, er den utskiftbare informasjonen en merknad, som er ubrukelig for Kubernetes selv, og for Helm vil den fungere som et signal for behovet for å oppdatere applikasjonen. Alternativer for å fylle ut merknadsverdien:
- Tilfeldig verdi ved å bruke standardfunksjonen -
{{ randAlphaNum 6 }}.
Det er et forbehold: etter hver distribusjon ved bruk av et diagram med en slik variabel, vil merknadsverdien 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. - Lim inn gjeldende dato og tid -
{{ .Release.Date }}.
En variant ligner på en tilfeldig verdi med en permanent unik variabel. - En mer korrekt måte er å bruke sjekksummer. Dette er SHA for bildet eller SHA for siste commit i git -
{{ .Values.sha }}.
De må telles og sendes til Helm-klienten på den som ringer, for eksempel i Jenkins. Hvis søknaden er endret, vil kontrollsummen endres. Derfor vil Helm kun oppdatere applikasjonen når det er nødvendig.
La oss oppsummere våre forsøk
- Helm gjør endringer på den minst invasive måten, så enhver endring på applikasjonsbildenivå i Docker Registry vil ikke resultere i en oppdatering: ingenting vil skje etter at kommandoen er utført.
- Ключ
--forcebrukes til å gjenopprette problematiske utgivelser og er ikke assosiert med tvungne oppdateringer. - Ключ
--recreate-podsvil kraftig oppdatere applikasjoner, men vil gjøre det på en vandalistisk måte: det vil brått slå av alle containere. Brukere vil lide av dette; du bør ikke gjøre dette i produksjonen. - Gjør endringer direkte i Kubernetes-klyngen ved å bruke kommandoen
kubectl editikke gjør det: vi bryter konsistensen, og oppførselen vil variere avhengig av versjonen av Helm. - Med utgivelsen av den nye versjonen av Helm har det dukket opp mange nyanser. Problemer i Helm-depotet er beskrevet i et tydelig språk, de vil hjelpe deg å forstå detaljene.
- Å legge til en redigerbar merknad til et diagram vil gjøre det mer fleksibelt. Dette vil tillate deg å rulle ut applikasjonen riktig, uten nedetid.
En "verdensfred"-tanke som fungerer på alle områder av livet: les bruksanvisningen før bruk, ikke etter. Bare med fullstendig informasjon vil det være mulig å bygge pålitelige systemer og gjøre brukerne fornøyde.
Andre relaterte lenker:
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