Bemærk. overs.: I Kubernetes-fællesskabet vinder en trend kaldet GitOps indlysende popularitet, som vi personligt har set, KubeCon Europe 2019. Denne term var relativt ny af lederen af Weaveworks - Alexis Richardson - og betyder brugen af værktøjer, der er kendt for udviklere (primært Git, deraf navnet) til at løse driftsproblemer. Vi taler især om driften af Kubernetes ved at gemme dens konfigurationer i Git og automatisk udrulle ændringer til klyngen. Matthias Jg fortæller om to tilgange til denne udrulning i denne artikel.
Sidste år (faktisk skete dette formelt i august 2017 - ca. oversættelse) Der er en ny tilgang til implementering af applikationer i Kubernetes. Det kaldes GitOps, og det er baseret på den grundlæggende idé om, at implementeringsversioner spores i det sikre miljø i et Git-lager.
De vigtigste fordele ved denne tilgang er som følger::
- Implementeringsversionering og ændringshistorik. Hele klyngens tilstand er gemt i et Git-lager, og implementeringer opdateres kun gennem commits. Derudover kan alle ændringer spores ved hjælp af commit-historikken.
- Tilbageføringer ved hjælp af velkendte Git-kommandoer... Almindeligt
git resetgiver dig mulighed for at nulstille ændringer i implementeringer; tidligere stater er altid tilgængelige. - Klar adgangskontrol. Typisk indeholder et Git-system en masse følsomme data, så de fleste virksomheder er særligt opmærksomme på at beskytte dem. Derfor gælder denne beskyttelse også for operationer med indsættelser.
- Politikker for implementeringer. De fleste Git-systemer understøtter native branch-by-branch-politikker – for eksempel kan kun pull-anmodninger opdatere master, og ændringer skal gennemgås og accepteres af et andet teammedlem. Som med adgangskontrol gælder de samme politikker for implementeringsopdateringer.
Som du kan se, er der mange fordele ved GitOps-metoden. I løbet af det seneste år har to tilgange vundet særlig popularitet. Den ene er push-baseret, den anden er pull-baseret. Før vi ser på dem, lad os først se på, hvordan typiske Kubernetes-implementeringer ser ud.
Implementeringsmetoder
I de senere år er forskellige metoder og værktøjer til implementering blevet etableret i Kubernetes:
- Baseret på native Kubernetes/Kustomize-skabeloner. Dette er den nemmeste måde at implementere applikationer på Kubernetes. Udvikleren opretter de grundlæggende YAML-filer og anvender dem. For at slippe for konstant at omskrive de samme skabeloner blev Kustomize udviklet (det gør Kubernetes skabeloner til moduler). Bemærk. overs.: Kustomize er blevet integreret i kubectl med .
- Hjelmdiagrammer. Helm-diagrammer giver dig mulighed for at oprette sæt skabeloner, init-beholdere, sidevogne osv., som bruges til at implementere applikationer med mere fleksible tilpasningsmuligheder end i en skabelonbaseret tilgang. Denne metode er baseret på skabeloner af YAML-filer. Helm fylder dem med forskellige parametre og sender dem derefter til Tiller, en klyngekomponent, der implementerer dem til klyngen og tillader opdateringer og tilbagerulninger. Det vigtige er, at Helm i det væsentlige bare indsætter de ønskede værdier i skabelonerne og derefter anvender dem på samme måde, som det gøres i den traditionelle tilgang (læs mere om, hvordan det hele fungerer, og hvordan du kan bruge det i vores - ca. oversættelse). Der er en bred vifte af færdiglavede Helm-kort, der dækker en bred vifte 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 Kubernetes-læsbare YAML-filer og derefter bruger dem.
I vores arbejde bruger vi konstant Helm-diagrammer til vigtige værktøjer (da de allerede har mange ting klar, hvilket gør livet meget lettere) og "rene" Kubernetes YAML-filer til at implementere vores egne applikationer.
Træk skub
I et af mine seneste blogindlæg introducerede jeg værktøjet , som giver dig mulighed for at overføre skabeloner til Git-lageret og opdatere implementeringen efter hver commit eller push af containeren. Min erfaring viser, at dette værktøj er et af de vigtigste til at fremme pull-tilgangen, så jeg vil ofte henvise til det. Hvis du vil vide mere om, hvordan du bruger det, her .
NB! Alle fordelene ved at bruge GitOps forbliver de samme for begge tilgange.
Pull baseret tilgang
Pull-tilgangen er baseret på, at alle ændringer anvendes inde fra klyngen. Der er en operatør inde i klyngen, som regelmæssigt tjekker de tilknyttede Git og Docker Registry repositories. Hvis der sker ændringer i dem, opdateres klyngens tilstand internt. Denne proces anses generelt for at være meget sikker, da ingen ekstern klient har adgang til klyngeadministratorrettigheder.
Teknikere:
- Ingen ekstern klient har rettigheder til at foretage ændringer i klyngen; alle opdateringer rulles ud indefra.
- Nogle værktøjer giver dig også mulighed for at synkronisere Helm-diagramopdateringer og linke dem til klyngen.
- Docker Registry kan scannes for nye versioner. Hvis et nyt billede er tilgængeligt, opdateres Git-lageret og implementeringen til den nye version.
- Pull-værktøjer kan distribueres på tværs af forskellige navneområder med forskellige Git-depoter og tilladelser. Takket være dette kan en multitenant-model bruges. For eksempel kan team A bruge navneområde A, team B kan bruge navneområde B, og infrastrukturteamet kan bruge globalt rum.
- Som regel er værktøjerne meget lette.
- Kombineret med værktøjer såsom operatør , kan hemmeligheder gemmes krypteret i et Git-lager og hentes i klyngen.
- Der er ingen forbindelse til CD-pipelines, da installationer finder sted i klyngen.
Cons:
- Det er vanskeligere at administrere implementeringshemmeligheder fra Helm-diagrammer end almindelige, da de først skal genereres i form af f.eks. forseglede hemmeligheder, derefter dekrypteres af en intern operatør, og først derefter bliver de tilgængelige for pull-værktøjet. Så kan du køre udgivelsen i Helm med værdierne i de allerede implementerede hemmeligheder. Den nemmeste måde er at skabe en hemmelighed med alle de Helm-værdier, der bruges til implementering, dekryptere den og forpligte den til Git.
- Når du tager en pull-tilgang, bliver du bundet til pull-værktøjer. Dette begrænser muligheden for at tilpasse implementeringsprocessen i en klynge. For eksempel er Kustomize kompliceret af det faktum, at det skal køre, før de endelige skabeloner er forpligtet til Git. Jeg siger ikke, at du ikke kan bruge selvstændige værktøjer, men de er sværere at integrere i din implementeringsproces.
Push baseret tilgang
I push-tilgangen lancerer et eksternt system (hovedsagelig CD-pipelines) implementeringer til klyngen efter en commit til Git-lageret, eller hvis den tidligere CI-pipeline er vellykket. I denne tilgang har systemet adgang til klyngen.
Pros:
- Sikkerheden bestemmes af Git-lageret og build-pipeline.
- Det er nemmere at implementere Helm-diagrammer og understøtter Helm-plugins.
- Hemmeligheder er nemmere at administrere, fordi hemmeligheder kan bruges i pipelines og kan også gemmes krypteret i Git (afhængigt af brugerens præferencer).
- Der er ingen forbindelse til et specifikt værktøj, da enhver type kan bruges.
- Containerversionsopdateringer kan initieres af build-pipelinen.
Cons:
- Klyngeadgangsdataene er inde i byggesystemet.
- Opdatering af installationscontainere er stadig nemmere med en pull-proces.
- Stor afhængighed af CD-systemet, da de pipelines, vi har brug for, måske oprindeligt er skrevet til Gitlab Runners, og derefter beslutter teamet at flytte til Azure DevOps eller Jenkins... og bliver nødt til at migrere et stort antal byggepipelines.
Resultater: Skub eller træk?
Som det normalt er tilfældet, har hver tilgang sine fordele og ulemper. Nogle opgaver er nemmere at udføre med en og sværere med en anden. Først lavede jeg udrulninger manuelt, men efter at jeg stødte på et par artikler om Weave Flux, besluttede jeg at implementere GitOps-processer til alle projekter. For grundlæggende skabeloner var dette nemt, men så begyndte jeg at løbe ind i vanskeligheder med Helm-diagrammer. På det tidspunkt tilbød Weave Flux kun en rudimentær version af Helm Chart Operator, men selv nu er nogle opgaver vanskeligere på grund af behovet for manuelt at oprette hemmeligheder og anvende dem. Du kan argumentere for, at pull-tilgangen er meget mere sikker, fordi klyngens legitimationsoplysninger ikke er tilgængelige uden for klyngen, hvilket gør den så meget mere sikker, at den er den ekstra indsats værd.
Efter nogle overvejelser kom jeg til den uventede konklusion, at det ikke er tilfældet. Hvis vi taler om komponenter, der kræver maksimal beskyttelse, vil denne liste omfatte hemmelig lagring, CI/CD-systemer og Git-lagre. Informationen i dem er meget sårbar og har brug for maksimal beskyttelse. Derudover, hvis nogen kommer ind i dit Git-lager og kan skubbe kode der, kan de implementere, hvad de vil (uanset om det er pull eller push) og infiltrere klyngens systemer. De vigtigste komponenter, der skal beskyttes, er således Git-lageret og CI/CD-systemerne, ikke klyngens legitimationsoplysninger. Hvis du har velkonfigurerede politikker og sikkerhedskontroller for disse typer systemer, og klyngelegitimationsoplysninger kun udtrækkes i pipelines som hemmeligheder, er den ekstra sikkerhed ved en pull-tilgang muligvis ikke så værdifuld som oprindeligt antaget.
Så hvis pull-tilgangen er mere arbejdskrævende og ikke giver en sikkerhedsfordel, er det så ikke logisk kun at bruge push-tilgangen? Men nogen vil måske hævde, at du i push-tilgangen er for bundet til CD-systemet, og måske er det bedre ikke at gøre dette, så det bliver lettere at udføre migreringer i fremtiden.
Efter min mening (som altid) bør du bruge det, der er bedst egnet til en bestemt sag eller mejetærsker. Personligt bruger jeg begge tilgange: Weave Flux til pull-baserede implementeringer, der for det meste omfatter vores egne tjenester, og en push-tilgang med Helm og plugins, som gør det nemt at anvende Helm-diagrammer til klyngen og giver dig mulighed for at skabe hemmeligheder problemfrit. Jeg tror, der aldrig vil være en enkelt løsning, der passer til alle sager, fordi der altid er mange nuancer, og de afhænger af den specifikke anvendelse. Når det så er sagt, så anbefaler jeg varmt GitOps – det gør livet meget nemmere og forbedrer sikkerheden.
Jeg håber, at min erfaring med dette emne vil hjælpe dig med at beslutte, hvilken metode der er mere egnet til din type implementering, og jeg ville være glad for at høre din mening.
PS Notat fra oversætteren
Ulempen ved pull-modellen er, at det er svært at lægge gengivet manifester ind i Git, men der er ingen ulempe, at CD-pipelinen i pull-modellen lever adskilt fra udrulningen og i det væsentlige bliver en kategori-pipeline Kontinuerlig påfør. Derfor vil der kræves endnu mere indsats for at indsamle deres status fra alle implementeringer og på en eller anden måde give adgang til logs/status, helst med reference til CD-systemet.
I denne forstand giver push-modellen os mulighed for i det mindste at give nogle garantier for udrulning, fordi levetiden af rørledningen kan gøres lig med udrulningens levetid.
Vi prøvede begge modeller og kom til de samme konklusioner som forfatteren til artiklen:
- Pullmodellen er velegnet til, at vi kan organisere opdateringer af systemkomponenter på et stort antal klynger (se. ).
- Push-modellen baseret på GitLab CI er velegnet til udrulning af applikationer ved hjælp af Helm-diagrammer. Samtidig overvåges udrulningen af implementeringer i pipelines ved hjælp af værktøjet . Forresten, i forbindelse med dette vores projekt hørte vi det konstante "GitOps", da vi diskuterede de presserende problemer for DevOps-ingeniører på vores stand på KubeCon Europe'19.
PPS fra oversætter
Læs også på vores blog:
- «";
- «";
- «";
- «'.
Kun registrerede brugere kan deltage i undersøgelsen. , Vær venlig.
Bruger du GitOps?
-
Ja, træk tilgang
-
Ja, skub
-
Ja, træk + skub
-
Ja, noget andet
-
Nej
30 brugere stemte. 10 brugere undlod at stemme.
Kilde: www.habr.com