Bem. overs.: I Kubernetes-fællesskabet vinder en trend kaldet GitOps tydelig popularitet, hvilket vi personligt har erfaret, KubeCon Europe 2019. Denne betegnelse blev forholdsvis for nylig af lederen af Weaveworks — Alexis Richardson — og refererer til anvendelsen af velkendte værktøjer for udviklere (primært Git, hvilket også er grunden til navnet) til at løse driftsmæssige opgaver. Specifikt handler det om driften af Kubernetes ved at opbevare dets konfigurationer i Git og automatisk udrulning af ændringer til klusteret. Om to tilgange til denne udrulning fortæller Matthias Jg i denne artikel.
I sidste år (det skete faktisk formelt i august 2017 — bem. fra overs.) opstod der en ny tilgang til implementering af applikationer i Kubernetes. Den kaldes GitOps, og dens grundlæggende idé er, at versionskontrol af deployment'er foregår i et sikkert Git-repositorium.
De vigtigste fordele ved denne tilgang er som følger:
- Versionskontrol af deployment'er og ændringshistorik. Tilstanden for hele klusteret opbevares i et Git-repositorium, og deployment'er opdateres kun gennem commits. Desuden kan alle ændringer spores ved hjælp af commit-historikken.
- Tilbageførsel ved hjælp af velkendte Git-kommandoer. En simpel
git resetgør det muligt at nulstille ændringer i deployment'er; tidligere tilstande er altid tilgængelige. - Færdig adgangskontrol. Normalt indeholder Git-systemet mange følsomme data, derfor lægger de fleste virksomheder særlig vægt på dets sikkerhed. Følgelig gælder denne sikkerhed også for operationer med deployment'er.
- Politikker for udrulninger. De fleste Git-systemer understøtter oprindeligt politikker for forskellige grene — for eksempel kan kun pull requests opdatere master, og ændringer skal godkendes af et andet teammedlem. Som med adgangskontrol gælder de samme politikker også for opdateringer af deployment'er.
Som du kan se, har GitOps-metoden mange fordele. I det forgangne år har to tilgange opnået særlig popularitet. Den ene er baseret på push, den anden på pull. Før vi ser nærmere på dem, lad os først kigge på, hvordan typiske Kubernetes-deployment'er ser ud.
Metoder til implementering
I løbet af de seneste år er der i Kubernetes blevet etableret forskellige metoder og værktøjer til udrulninger:
- Baseret på Kubernetes/Kustomizes indfødte skabeloner. Det er den nemmeste måde at implementere applikationer i Kubernetes på. Udvikleren opretter grundlæggende YAML-filer og anvender dem. For at undgå konstant omlægning af de samme skabeloner blev Kustomize udviklet (det omdanner Kubernetes-skabeloner til moduler). Bem. overs.: Kustomize er blevet integreret i kubectl med .
- Helm Charts. Helm Charts muliggør oprettelse af sæt af skabeloner, init-containere, sidecar’er osv., der anvendes til deployment af applikationer med mere fleksible tilpasningsmuligheder end den skabelonbaserede tilgang. Fundamentet for denne metode er skabeloniserede YAML-filer. Helm udfylder dem med forskellige parametre og sender dem derefter til Tiller – en klyngekomponent, der implementerer dem i klyngen og muliggør opdateringer og tilbagerulninger. Det er vigtigt at bemærke, at Helm i bund og grund bare indsætter de nødvendige værdier i skabelonerne og anvender dem på samme måde som i den traditionelle tilgang. (læs mere om, hvordan det hele fungerer, og hvordan du kan bruge det, i vores — red. anm.). Der findes et stort udvalg af færdige Helm-charts, der dækker et bredt spektrum af opgaver.
- Alternative værktøjer. Der er mange alternative værktøjer. Fælles for dem alle er, at de omdanner nogle skabelonfiler til forståelige Kubernetes YAML-filer og derefter anvender dem.
I vores arbejde bruger vi konstant Helm-charts til vigtige værktøjer (da meget allerede er klar, hvilket gør livet betydeligt lettere) og «rene» YAML-filer fra Kubernetes til implementering af vores egne applikationer.
Pull & Push
I et af mine nylige blogindlæg præsenterede jeg et værktøj , der muliggør commit af skabeloner til et Git-repositorium og opdatering af deployment efter hver commit eller push af containeren. Min erfaring viser, at dette værktøj er et af de vigtigste i fremme af pull-tilgangen, så jeg vil ofte referere til det. Hvis du vil vide mere om, hvordan du bruger det, her er .
NB! Alle fordelene ved at bruge GitOps bevares for begge tilgange.
Pull-baseret tilgang
I kernen af pull-tilgangen ligger det faktum, at alle ændringer anvendes indefra klyngen. Inden i klyngen er der en operatør, der regelmæssigt tjekker de tilknyttede Git- og Docker Registry-repositorier. Hvis der sker ændringer i dem, opdateres klyngets tilstand indefra. Det betragtes generelt som en sikker proces, da ingen ekstern klient har adgang til administratorrettigheder i klyngen.
Fordele:
- Ingen ekstern klient har rettigheder til at foretage ændringer i klyngen; alle opdateringer anvendes indefra.
- Nogle værktøjer tillader også synkronisering af opdateringer af Helm-diagrammer og knytter dem til klyngen.
- Docker Registry kan scannes for nye versioner. Hvis der kommer et nyt billede, opdateres Git-repositoriet og deployment til den nye version.
- Pull-værktøjer kan distribueres på forskellige navnerum med forskellige Git-repositories og adgangsrettigheder. Dette muliggør en multitenant-model. For eksempel kan team A bruge navnerum A, team B navnerum B, mens teamet, der arbejder med infrastrukturen, kan bruge et globalt rum.
- Generelt er værktøjerne meget letvægts.
- I kombination med værktøjer som operatøren , kan hemmeligheder opbevares krypteret i Git-repositoriet og hentes inden i klyngen.
- Der er ingen forbindelse til CD-pipelines, da deployment finder sted inden i klyngen.
Ulemper:
- At administrere hemmeligheder for deployment fra Helm-diagrammer er mere komplekst end almindelige, da de først skal genereres som sealed secrets, derefter dechiffres af den interne operatør, hvorefter de bliver tilgængelige for pull-værktøjet. Derefter kan frigivelsen i Helm køres med værdierne fra de allerede deployerede hemmeligheder. Den enkleste måde er at oprette en hemmelighed med alle Helm-værdierne, der bruges til deployment, dechifrere den og committe den til Git.
- Ved at anvende pull-tilgangen er du bundet til værktøjer, der arbejder med pulls. Dette begrænser muligheden for at tilpasse deployment-processen i klyngen. For eksempel kompliceres arbejdet med Kustomize, da det skal udføres, før de endelige skabeloner går ind i Git. Jeg siger ikke, at man ikke kan bruge separate værktøjer, men de er sværere at integrere i deployment-processen.
Push-baseret tilgang
I push-tilgangen igangsætter det eksterne system (primært CD-pipelines) deployment i klyngen efter commit i Git-repositoriet eller i tilfælde af, at den foregående CI-pipeline er blevet udført med succes. I denne tilgang har systemet adgang til klyngen.
Fordele:
- Sikkerheden defineres af Git-repositoriet og bygge-pipelinen.
- Det er lettere at deployere Helm-charter, da der er støtte for Helm-plugins.
- Det er lettere at administrere hemmeligheder, da hemmeligheder kan anvendes i pipelines og også opbevares i Git i krypteret form (afhængigt af brugerens præferencer).
- Der er ingen binding til et specifikt værktøj, da man kan bruge enhver type.
- Opdateringer af container-versioner kan initieres af bygge-pipelinen.
Ulemper:
- Dataene til adgang til klyngen er inde i byggesystemet.
- Opdatering af container-deployments er stadig lettere at udføre med en pull-proces.
- Der er en stærk afhængighed af CD-systemet, da de nødvendige pipelines muligvis oprindeligt er skrevet til Gitlab Runners, og så beslutter teamet at skifte til Azure DevOps eller Jenkins... og skal migrere mange bygge-pipelines.
Sammenfatning: Push eller Pull?
Som vanligt er der fordele og ulemper ved hver tilgang. Nogle opgaver er lettere at udføre med den ene, mens det er sværere med den anden. I starten udførte jeg deployment manuelt, men efter at jeg stødte på nogle artikler om Weave Flux, besluttede jeg at implementere GitOps-processer for alle projekter. For de grundlæggende skabeloner var det nemt, men senere begyndte jeg at støde på udfordringer med Helm-diagrammer. På det tidspunkt tilbød Weave Flux kun en tidlig version af Helm Chart Operator, men selv nu er nogle opgaver mere komplekse på grund af behovet for manuelt at oprette hemmeligheder og anvende dem. Man kan sige, at pull-tilgangen er meget mere sikker, da klyngetræk-kontooplysningerne ikke er tilgængelige uden for det, hvilket øger sikkerheden så meget, at det er værd at gøre en ekstra indsats.
Efter lidt overvejelse nåede jeg til den overraskende konklusion, at det ikke er tilfældet. Når det kommer til komponenter, der kræver maksimal beskyttelse, vil en sådan liste inkludere hemmelighedslagre og CI/CD-systemer, Git-repositories. Oplysningerne i dem er meget sårbare og har brug for maksimal beskyttelse. Desuden, hvis en person får adgang til dit Git-repository og kan push'e kode der, vil de kunne deploy'e alt, hvad de ønsker (uanset om det er pull- eller push-tilgang), og infiltrere klyngens systemer. Derfor er de vigtigste komponenter, der kræver beskyttelse, Git-repositoryet og CI/CD-systemerne, ikke klyngetræk-kontooplysningerne. Hvis du har godt konfigurerede politikker og sikkerhedsforanstaltninger for sådanne systemer, og klyngetræk-kontooplysningerne kun trækkes ind i pipelines som hemmeligheder, kan den ekstra sikkerhed ved pull-tilgangen vise sig at være mindre værdifuld, end først antaget.
Så hvis pull-tilgangen er mere besværlig og ikke giver sikkerhedsfordele, er det så ikke logisk kun at bruge push-tilgangen? Men nogen kunne måske hævde, at i push-tilgangen er du for afhængig af CD-systemet, og det kan være bedre at undgå det for at gøre fremtidige migreringer lettere.
Efter min mening (som altid) bør man bruge det, der passer bedst til den konkrete situation, eller kombinere metoderne. Personligt anvender jeg begge tilgange: Weave Flux til deployment baseret på pull, som primært inkluderer vores egne tjenester, og push-tilgang med Helm og plugins, som forenkler anvendelsen af Helm-diagrammer til klyngen og gør det muligt at oprette hemmeligheder uden problemer. Jeg tror ikke, der nogensinde vil være én løsning, der passer til alle situationer, fordi der altid er mange nuancer, og de afhænger af den specifikke anvendelse. Jeg anbefaler bestemt GitOps - det letter livet og øger sikkerheden meget.
Jeg håber, at min erfaring inden for dette emne vil hjælpe dig med at beslutte, hvilken metode der passer bedst til din type deployment, og jeg vil være glad for at høre din mening.
P.S. Notat fra oversætteren
Ulempen ved pull-modellen er, at det er svært at lægge de rendere manifeste i Git, men der er ikke nogen ulempe ved, at CD-pipelinen i pull-modellen lever separat fra udrulningen og i virkeligheden bliver en pipeline af kategorien Continuous Apply. Derfor kræves der endnu mere arbejde for at indsamle status fra alle deployment og på en eller anden måde give adgang til logs/status, helst knyttet til CD-systemet.
I denne forstand gør push-modellen det muligt at give nogen garantier for udrulningen, fordi pipelinens levetid kan gøres lig med udrulningens levetid.
Vi har afprøvet begge modeller og er nået til de samme konklusioner som forfatteren af artiklen:
- Pull-modellen passer os til at organisere opdateringer af systemkomponenter på et stort antal klynger (se ).
- Push-modellen baseret på GitLab CI fungerer godt til udrulning af applikationer ved hjælp af Helm-diagrammer. Udrulningen af deployments i pipeline overvåges med værktøjet . For øvrigt hørte vi i forbindelse med dette projekt konstant "GitOps", når vi diskuterede presserende problemer for DevOps-ingeniører ved vores stand på KubeCon Europe'19.
P.P.S. fra oversætteren
Læs også på vores blog:
- «»;
- «»;
- «»;
- «».
Kun registrerede brugere kan deltage i undersøgelsen. , please.
Bruger du GitOps?
Ja, pull-tilgang
Ja, push
Ja, pull + push
Ja, noget andet
Nej
30 brugere har stemt. 10 brugere har afholdt sig fra at stemme.
Kilde: habr.com
