Notera. transl.: I Kubernetes-communityt vinner en trend som kallas GitOps uppenbar popularitet, som vi personligen har sett, KubeCon Europe 2019. Denna term var relativt ny av chefen för Weaveworks - Alexis Richardson - och menar användningen av verktyg som är bekanta för utvecklare (främst Git, därav namnet) för att lösa driftsproblem. I synnerhet talar vi om driften av Kubernetes genom att lagra dess konfigurationer i Git och automatiskt rulla ut ändringar i klustret. Matthias Jg talar om två tillvägagångssätt för denna utrullning i den här artikeln.
Förra året (i själva verket hände detta formellt i augusti 2017 - cirka översättning) Det finns ett nytt tillvägagångssätt för att distribuera applikationer i Kubernetes. Det kallas GitOps, och det är baserat på den grundläggande idén att distributionsversioner spåras i den säkra miljön i ett Git-förråd.
De viktigaste fördelarna med detta tillvägagångssätt är följande::
- Distributionsversioner och ändringshistorik. Tillståndet för hela klustret lagras i ett Git-förråd, och distributioner uppdateras endast genom commits. Dessutom kan alla ändringar spåras med hjälp av commit-historiken.
- Återställer med välbekanta Git-kommandon. Enkel
git resetlåter dig återställa ändringar i driftsättningar; tidigare tillstånd är alltid tillgängliga. - Klar åtkomstkontroll. Vanligtvis innehåller ett Git-system mycket känslig data, så de flesta företag ägnar särskild uppmärksamhet åt att skydda den. Detta skydd gäller följaktligen även för insatser med insatser.
- Policyer för implementeringar. De flesta Git-system stöder gren-för-gren-policyer – till exempel kan endast pull-förfrågningar uppdatera master, och ändringar måste granskas och accepteras av en annan teammedlem. Som med åtkomstkontroll gäller samma principer för distributionsuppdateringar.
Som du kan se finns det många fördelar med GitOps-metoden. Under det senaste året har två tillvägagångssätt blivit särskilt populära. Den ena är push-baserad, den andra är pull-baserad. Innan vi tittar på dem, låt oss först titta på hur typiska Kubernetes-distributioner ser ut.
Implementeringsmetoder
Under de senaste åren har olika metoder och verktyg för implementeringar etablerats i Kubernetes:
- Baserat på inbyggda Kubernetes/Kustomize-mallar. Detta är det enklaste sättet att distribuera applikationer på Kubernetes. Utvecklaren skapar de grundläggande YAML-filerna och tillämpar dem. För att bli av med att ständigt skriva om samma mallar utvecklades Kustomize (det gör Kubernetes-mallar till moduler). Notera. transl.: Kustomize har integrerats i kubectl med .
- Hjälmdiagram. Styrdiagram låter dig skapa uppsättningar av mallar, init-behållare, sidvagnar, etc., som används för att distribuera applikationer med mer flexibla anpassningsalternativ än i ett mallbaserat tillvägagångssätt. Denna metod är baserad på mallade YAML-filer. Helm fyller dem med olika parametrar och skickar dem sedan till Tiller, en klusterkomponent som distribuerar dem till klustret och tillåter uppdateringar och återställningar. Det viktiga är att Helm i princip bara infogar de önskade värdena i mallarna och sedan tillämpar dem på samma sätt som det görs i den traditionella metoden (läs mer om hur det hela fungerar och hur du kan använda det i vår - cirka. översätt.). Det finns ett brett utbud av färdiga roderdiagram som täcker ett brett utbud av uppgifter.
- Alternativa verktyg. Det finns många alternativa verktyg. Gemensamt för dem alla är att de gör om några mallfiler till Kubernetes-läsbara YAML-filer och sedan använder dem.
I vårt arbete använder vi ständigt Helm-diagram för viktiga verktyg (eftersom de har många saker redan klara, vilket gör livet mycket lättare) och "rena" Kubernetes YAML-filer för att distribuera våra egna applikationer.
Dra tryck
I ett av mina senaste blogginlägg introducerade jag verktyget , som låter dig commitera mallar till Git-förvaret och uppdatera distributionen efter varje commit eller push av behållaren. Min erfarenhet visar att detta verktyg är ett av de viktigaste för att främja pull-metoden, så jag kommer ofta att hänvisa till det. Om du vill veta mer om hur du använder det, här .
OBS! Alla fördelar med att använda GitOps förblir desamma för båda tillvägagångssätten.
Dragbaserat tillvägagångssätt
Pullmetoden bygger på det faktum att alla ändringar tillämpas inifrån klustret. Det finns en operatör inuti klustret som regelbundet kontrollerar de associerade Git- och Docker Registry-förråden. Om några ändringar inträffar i dem uppdateras klustrets tillstånd internt. Denna process anses generellt vara mycket säker, eftersom ingen extern klient har åtkomst till klusteradministratörsrättigheter.
Fördelar:
- Ingen extern klient har rättigheter att göra ändringar i klustret; alla uppdateringar rullas ut inifrån.
- Vissa verktyg låter dig också synkronisera uppdateringar av Helm-diagram och länka dem till klustret.
- Docker Registry kan skannas efter nya versioner. Om en ny bild är tillgänglig uppdateras Git-förvaret och distributionen till den nya versionen.
- Pull-verktyg kan distribueras över olika namnområden med olika Git-förråd och behörigheter. Tack vare detta kan en multitenant-modell användas. Till exempel kan team A använda namnutrymme A, team B kan använda namnområde B och infrastrukturteamet kan använda globalt utrymme.
- Som regel är verktygen mycket lätta.
- Kombinerat med verktyg som operatör , kan hemligheter lagras krypterade i ett Git-förråd och hämtas in i klustret.
- Det finns ingen anslutning till CD-pipelines eftersom distributioner sker inom klustret.
Nackdelar:
- Att hantera distributionshemligheter från Helm-diagram är svårare än vanliga, eftersom de först måste genereras i form av, säg, förseglade hemligheter, sedan dekrypteras av en intern operatör, och först efter det blir de tillgängliga för pull-verktyget. Sedan kan du köra releasen i Helm med värdena i de redan utplacerade hemligheterna. Det enklaste sättet är att skapa en hemlighet med alla Helm-värden som används för distribution, dekryptera den och överlåta den till Git.
- När du tar en dragstrategi blir du bunden till dragverktyg. Detta begränsar möjligheten att anpassa distributionsprocessen i ett kluster. Till exempel är Kustomize komplicerat av det faktum att det måste köras innan de slutliga mallarna committeras till Git. Jag säger inte att du inte kan använda fristående verktyg, men de är svårare att integrera i din distributionsprocess.
Push-baserad tillvägagångssätt
I push-metoden lanserar ett externt system (främst CD-pipelines) distributioner till klustret efter en commit till Git-förvaret eller om den tidigare CI-pipelinen är framgångsrik. I detta tillvägagångssätt har systemet tillgång till klustret.
Fördelar:
- Säkerheten bestäms av Git-förvaret och byggpipeline.
- Att distribuera Helm-diagram är enklare och stöder Helm-plugins.
- Hemligheter är lättare att hantera eftersom hemligheter kan användas i pipelines och kan även lagras krypterade i Git (beroende på användarens preferenser).
- Det finns ingen koppling till ett specifikt verktyg, eftersom alla typer kan användas.
- Behållarversionsuppdateringar kan initieras av byggpipeline.
Nackdelar:
- Klustrets åtkomstdata finns i byggsystemet.
- Att uppdatera distributionsbehållare är fortfarande enklare med en pull-process.
- Stort beroende av CD-systemet, eftersom pipelines vi behöver ursprungligen kan ha skrivits för Gitlab Runners, och sedan beslutar teamet att flytta till Azure DevOps eller Jenkins... och kommer att behöva migrera ett stort antal byggpipelines.
Resultat: Push eller Pull?
Som vanligtvis är fallet har varje tillvägagångssätt sina för- och nackdelar. Vissa uppgifter är lättare att utföra med en och svårare med en annan. Först gjorde jag driftsättningar manuellt, men efter att jag stött på några artiklar om Weave Flux bestämde jag mig för att implementera GitOps-processer för alla projekt. För grundläggande mallar var detta enkelt, men sedan började jag stöta på svårigheter med Helm-diagram. På den tiden erbjöd Weave Flux bara en rudimentär version av Helm Chart Operator, men även nu är vissa uppgifter svårare på grund av behovet av att manuellt skapa hemligheter och tillämpa dem. Du kan hävda att pull-metoden är mycket säkrare eftersom klustrets referenser inte är tillgängliga utanför klustret, vilket gör det så mycket säkrare att det är värt den extra ansträngningen.
Efter lite funderande kom jag till den oväntade slutsatsen att det inte är så. Om vi talar om komponenter som kräver maximalt skydd kommer den här listan att innehålla hemlig lagring, CI/CD-system och Git-förråd. Informationen i dem är mycket sårbar och behöver maximalt skydd. Dessutom, om någon kommer in i ditt Git-förråd och kan pusha kod dit, kan de distribuera vad de vill (oavsett om det är pull eller push) och infiltrera klustrets system. De viktigaste komponenterna som behöver skyddas är alltså Git-förvaret och CI/CD-systemen, inte klustrets autentiseringsuppgifter. Om du har välkonfigurerade policyer och säkerhetskontroller för dessa typer av system, och klusterreferenser endast extraheras i pipelines som hemligheter, kanske den extra säkerheten med en pull-metod inte är så värdefull som man ursprungligen trodde.
Så om pull-metoden är mer arbetsintensiv och inte ger en säkerhetsfördel, är det inte logiskt att bara använda push-metoden? Men någon kan hävda att i push-metoden är du för bunden till CD-systemet och kanske är det bättre att inte göra detta så att det blir lättare att genomföra migrering i framtiden.
Enligt min åsikt (som alltid) bör du använda det som är mest lämpligt för ett särskilt fall eller kombinera. Personligen använder jag båda tillvägagångssätten: Weave Flux för pull-baserade implementeringar som mestadels inkluderar våra egna tjänster, och en push-metod med Helm och plugins, vilket gör det enkelt att applicera Helm-diagram på klustret och låter dig skapa hemligheter sömlöst. Jag tror att det aldrig kommer att finnas en enda lösning som passar alla fall, eftersom det alltid finns många nyanser och de beror på den specifika applikationen. Som sagt, jag rekommenderar varmt GitOps – det gör livet mycket enklare och förbättrar säkerheten.
Jag hoppas att min erfarenhet av det här ämnet hjälper dig att bestämma vilken metod som är mer lämplig för din typ av distribution, och jag skulle gärna höra din åsikt.
PS Anmärkning från översättaren
Nackdelen med pull-modellen är att det är svårt att lägga in renderade manifest i Git, men det finns ingen nackdel att CD-pipelinen i pull-modellen lever separat från utrullningen och i huvudsak blir en kategoripipeline Applicera kontinuerligt. Därför kommer ännu mer ansträngning att krävas för att samla in deras status från alla distributioner och på något sätt ge tillgång till loggar/status, helst med hänvisning till CD-systemet.
I denna mening tillåter push-modellen oss att tillhandahålla åtminstone några garantier för utbyggnad, eftersom rörledningens livslängd kan göras lika med utbyggnadens livslängd.
Vi provade båda modellerna och kom till samma slutsatser som artikelförfattaren:
- Pullmodellen är lämplig för oss att organisera uppdateringar av systemkomponenter på ett stort antal kluster (se. ).
- Push-modellen baserad på GitLab CI är väl lämpad för att rulla ut applikationer med hjälp av Helm-diagram. Samtidigt övervakas utrullningen av driftsättningar inom pipelines med hjälp av verktyget . Förresten, i samband med detta vårt projekt hörde vi det ständiga "GitOps" när vi diskuterade de akuta problemen för DevOps-ingenjörer i vår monter på KubeCon Europe'19.
PPS från översättaren
Läs även på vår blogg:
- «";
- «";
- «";
- «".
Endast registrerade användare kan delta i undersökningen. , Snälla du.
Använder du GitOps?
-
Ja, dra tillvägagångssätt
-
Ja, tryck
-
Ja, dra + tryck
-
Ja, något annat
-
Ingen
30 användare röstade. 10 användare avstod från att rösta.
Källa: will.com