Redigera

GitOps för Azure Kubernetes Service

Azure Kubernetes Service (AKS)
GitHub

GitOps är en uppsättning principer för att använda och hantera ett programvarusystem. I den här artikeln beskrivs tekniker för att använda GitOps-principer för att driva och hantera ett AKS-kluster (Azure Kubernetes Services).

Logotyperna Flux, Argo CD, OPA Gatekeeper, Kubernetes och git är varumärken som tillhör respektive företag. Ingen bekräftelse understås av användningen av dessa märken.

Arkitektur

Två GitOps-operatorer som du kan använda med AKS är Flux och Argo CD. De är båda examensbaserade CNCF-projekt (Cloud Native Computing Foundation) och används i stor utsträckning. I följande scenarier visas olika sätt att använda dem.

Scenario 1: GitOps med Flux och AKS

Diagram över GitOps med Flux v2, GitHub och AKS.

Ladda ned en Visio-fil med den här arkitekturen.

Dataflöde för scenario 1

Flux är ett inbyggt klustertillägg till AKS. Klustertillägg ger en plattform för att installera och hantera lösningar i ett AKS-kluster. Du kan använda Skript för Azure-portalen, Azure CLI eller infrastruktur som kod (IaC), till exempel Terraform- eller Bicep-skript, för att aktivera Flux som ett tillägg till AKS. Du kan också använda Azure Policy för att tillämpa Flux v2-konfigurationer i stor skala på AKS-kluster. Mer information finns i Distribuera program konsekvent i stor skala med flux v2-konfigurationer och Azure Policy.

Flux kan distribuera Kubernetes-manifest, Helm-diagram och Kustomization-filer till AKS. Flux är en avsökningsbaserad process så att den kan identifiera, hämta och stämma av konfigurationsändringar utan att exponera klusterslutpunkter för dina byggagenter.

I det här scenariot kan Kubernetes-administratörer ändra Kubernetes-konfigurationsobjekt, till exempel hemligheter och konfiguration Kartor och checka in ändringarna direkt till en GitHub-lagringsplats.

Dataflödet för det här scenariot är:

  1. Utvecklaren genomför konfigurationsändringar på GitHub-lagringsplatsen.
  2. Flux identifierar konfigurationsavvikelsen på Git-lagringsplatsen och hämtar konfigurationsändringarna.
  3. Flux stämma av tillståndet i Kubernetes-klustret.

Alternativ för scenario 1

  • Du kan använda Flux med andra Git-lagringsplatser som Azure DevOps, GitLab och BitBucket.
  • I stället för Git-lagringsplatser definierar Flux Bucket API en källa för att skapa en artefakt för objekt från lagringslösningar som Amazon S3 och Google Cloud Storage-bucketar. Du kan också använda en lösning som har ett S3-kompatibelt API. Två exempel är Minio och Alibaba molnoperativsystem S, men det finns andra.
  • Du kan också konfigurera Flux mot en Azure Blob Storage-container som källa för att skapa artefakter. Mer information finns i GitOps Flux v2-konfigurationer med AKS och Azure Arc-aktiverade Kubernetes.

Scenario 2: Använda GitOps med Flux, GitHub och AKS för att implementera CI/CD

Diagram över implementering av CI/CD med hjälp av GitOps med Flux, GitHub och AKS.

Ladda ned en Visio-fil med den här arkitekturen.

Dataflöde för scenario 2

Det här scenariot är en pull-baserad DevOps-pipeline för ett typiskt webbprogram. Pipelinen använder GitHub Actions för bygge. För distribution använder den Flux som GitOps-operator för att hämta och synkronisera appen. Data flödar genom scenariot på följande sätt:

  1. Appkoden utvecklas med hjälp av en IDE, till exempel Visual Studio Code.
  2. Appkoden checkas in på en GitHub-lagringsplats.
  3. GitHub Actions skapar en containeravbildning från appkoden och skickar containeravbildningen till Azure Container Registry.
  4. GitHub Actions uppdaterar en Kubernetes-manifestdistributionsfil med den aktuella avbildningsversionen som baseras på versionsnumret för containeravbildningen i Azure Container Registry.
  5. Flux-operatorn identifierar konfigurationsavvikelsen på Git-lagringsplatsen och hämtar konfigurationsändringarna.
  6. Flux använder manifestfiler för att distribuera appen till AKS-klustret.

Scenario 3: GitOps med Argo CD, GitHub-lagringsplats och AKS

Diagram över GitOps med Argo CD, GitHub och AKS.

Ladda ned en Visio-fil med den här arkitekturen.

Dataflöde för scenario 3

I det här scenariot kan Kubernetes-administratören ändra Kubernetes-konfigurationsobjekt, till exempel hemligheter och konfiguration Kartor och checka in ändringarna direkt till GitHub-lagringsplatsen.

Dataflödet för det här scenariot är:

  1. Kubernetes-administratören gör konfigurationsändringar i YAML-filer och genomför ändringarna på GitHub-lagringsplatsen.
  2. Argo CD hämtar ändringarna från Git-lagringsplatsen.
  3. Argo CD stämma av konfigurationsändringarna till AKS-klustret.

Argo CD behöver inte automatiskt synkronisera önskat måltillstånd till AKS-klustret. Den implementeras som en Kubernetes-styrenhet som kontinuerligt övervakar program som körs. Den jämför aks-klustrets aktuella livetillstånd med det önskade måltillstånd som anges i Git-lagringsplatsen. Argo CD rapporterar och visualiserar skillnaderna, samtidigt som du tillhandahåller möjligheter att automatiskt eller manuellt synkronisera livetillståndet tillbaka till önskat måltillstånd.

Argo CD tillhandahåller ett webbläsarbaserat användargränssnitt. Du kan använda den för att lägga till programkonfigurationer, observera synkroniseringstillståndet med avseende på klustret och initiera synkronisering mot klustret. Du kan också använda Argo CD-kommandoraden för att göra dessa saker. Både användargränssnittet och kommandoradsgränssnittet innehåller funktioner för att visa historiken för konfigurationsändringar och återställa till en tidigare version.

Som standard exponeras inte Argo CD-användargränssnittet och API-servern. För att få åtkomst till dem rekommenderar vi att du skapar en ingresskontrollant som har en intern IP-adress. Du kan också använda en intern lastbalanserare för att exponera dem.

Alternativ för scenario 3

Alla lagringsplatser som är kompatibla med Git, inklusive Azure DevOps, kan fungera som lagringsplats för konfigurationskällan.

Scenario 4: Använda GitOps med Argo CD, GitHub Actions och AKS för att implementera CI/CD

Diagram över implementering av CI/CD med GitOps med Argo CD, GitHub och AKS.

Ladda ned en Visio-fil med den här arkitekturen.

Dataflöde för scenario 4

Det här scenariot är en pull-baserad DevOps-pipeline för ett typiskt webbprogram. Pipelinen använder GitHub Actions för bygge. För distribution använder den Argo CD som GitOps-operator för att hämta och synkronisera appen. Data flödar genom scenariot på följande sätt:

  1. Appkoden utvecklas med hjälp av en IDE, till exempel Visual Studio Code.
  2. Appkoden checkas in på en GitHub-lagringsplats.
  3. GitHub Actions skapar en containeravbildning från appkoden och skickar containeravbildningen till Azure Container Registry.
  4. GitHub Actions uppdaterar en Kubernetes-manifestdistributionsfil med den aktuella avbildningsversionen som baseras på versionsnumret för containeravbildningen i Azure Container Registry.
  5. Argo CD hämtar från Git-lagringsplatsen.
  6. Argo CD distribuerar appen till AKS-klustret.

Alternativ för scenario 4

Alla lagringsplatser som är kompatibla med Git, inklusive Azure DevOps, kan fungera som lagringsplats för konfigurationskällan.

Information om scenario

GitOps är en uppsättning principer för att använda och hantera ett programvarusystem.

  • Den använder källkontroll som en enda sanningskälla för systemet.
  • Den tillämpar utvecklingsmetoder som versionskontroll, samarbete, efterlevnad och kontinuerlig integrering/kontinuerlig distribution (CI/CD) på infrastrukturautomatisering.
  • Du kan tillämpa den på valfritt programvarusystem.

GitOps används ofta för Kubernetes-klusterhantering och programleverans. I den här artikeln beskrivs några vanliga alternativ för att använda GitOps tillsammans med ett AKS-kluster.

Enligt GitOps-principer måste det önskade tillståndet för ett GitOps-hanterat system vara:

  1. Deklarativ: Ett system som GitOps hanterar måste ha önskat tillstånd uttryckt deklarativt. Deklarationen lagras vanligtvis på en Git-lagringsplats.
  2. Versionshanterad och oföränderlig: Det önskade tillståndet lagras på ett sätt som framtvingar oföränderlighet och versionshantering och behåller en fullständig versionshistorik.
  3. Hämtas automatiskt: Programvaruagenter hämtar automatiskt önskade tillståndsdeklarationer från källan.
  4. Kontinuerligt avstämd: Programvaruagenter observerar kontinuerligt det faktiska systemtillståndet och försöker tillämpa önskat tillstånd.

I GitOps använder infrastruktur som kod (IaC) kod för att deklarera önskat tillstånd för infrastrukturkomponenter som virtuella datorer, nätverk och brandväggar. Den här koden är versionskontrollerad och granskningsbar.

Kubernetes beskriver allt från klustertillstånd till programdistributioner deklarativt med manifest. GitOps för Kubernetes placerar den önskade klusterinfrastrukturens tillstånd under versionskontroll. En komponent i klustret, som vanligtvis kallas operator, synkroniserar kontinuerligt deklarativt tillstånd. Den här metoden gör det möjligt att granska och granska kodändringar som påverkar klustret. Det förbättrar säkerheten genom att stödja principen om lägsta behörighet.

GitOps-agenter stämmer kontinuerligt av systemtillståndet med önskat tillstånd som lagras i din kodlagringsplats. Vissa GitOps-agenter kan återställa åtgärder som utförs utanför klustret, till exempel manuellt skapande av Kubernetes-objekt. Antagningskontrollanter framtvingar till exempel principer för objekt under åtgärder för att skapa, uppdatera och ta bort. Du kan använda dem för att se till att distributionerna bara ändras om distributionskoden på källlagringsplatsen ändras.

Du kan kombinera verktyg för principhantering och tvingande med GitOps för att framtvinga principer och ge feedback om föreslagna principändringar. Du kan konfigurera aviseringar för olika team för att ge dem uppdaterad GitOps-status. Du kan till exempel skicka meddelanden om distributionsframgångar och avstämningsfel.

GitOps som enskild sanningskälla

GitOps ger konsekvens och standardisering av klustertillståndet och kan bidra till att förbättra säkerheten. Du kan också använda GitOps för att säkerställa konsekvent tillstånd i flera kluster. GitOps kan till exempel tillämpa samma konfiguration i primära kluster och haveriberedskapskluster (DR) eller i en grupp med kluster.

Om du vill framtvinga att endast GitOps kan ändra klustertillståndet kan du begränsa direkt åtkomst till klustret. Det finns olika sätt att göra detta, till exempel rollbaserad åtkomstkontroll i Azure (RBAC), antagningskontrollanter och andra verktyg.

Använda GitOps för att starta den inledande konfigurationen

Du kan behöva distribuera AKS-kluster som en del av baslinjekonfigurationen. Ett exempel är att du måste distribuera en uppsättning delade tjänster eller en konfiguration innan du distribuerar arbetsbelastningar. Dessa delade tjänster kan konfigurera AKS-tillägg som:

Du kan aktivera Flux som ett tillägg som tillämpas när du skapar ett AKS-kluster. Flux kan sedan starta baslinjekonfigurationen till klustret. Baslinjearkitekturen för ett AKS-kluster föreslår att du använder GitOps för bootstrapping. Om du använder Flux-tillägget kan du starta kluster mycket snart efter att du har distribuerat.

Andra GitOps-verktyg och tillägg

Du kan utöka de beskrivna scenarierna till andra GitOps-verktyg. Jenkins X är ett annat GitOps-verktyg som innehåller instruktioner för att integrera i Azure. Du kan använda progressiva leveransverktyg som Flagger för gradvis växling av produktionsarbetsbelastningar som distribueras via GitOps.

Potentiella användningsfall

Den här lösningen gynnar alla organisationer som vill ha fördelarna med att distribuera program och infrastruktur som kod, med en spårningslogg för varje ändring.

GitOps skyddar utvecklaren från komplexiteten i att hantera en containermiljö. Utvecklare kan fortsätta att arbeta med välbekanta verktyg som Git för att hantera uppdateringar och nya funktioner. På så sätt förbättrar GitOps utvecklarproduktiviteten.

Att tänka på

Dessa överväganden implementerar grundpelarna i Azure Well-Architected Framework, som är en uppsättning vägledande grundsatser som du kan använda för att förbättra kvaliteten på en arbetsbelastning. Mer information finns i Microsoft Azure Well-Architected Framework.

Tillförlitlighet

Tillförlitlighet säkerställer att ditt program kan uppfylla de åtaganden som du gör gentemot dina kunder. Mer information finns i Översikt över tillförlitlighetspelare.

En av grundpelarna för tillförlitlighet är återhämtning. Målet med återhämtning är att kunna återställa programmet till ett fullt fungerande tillstånd efter fel. Om ett kluster blir otillgängligt kan GitOps snabbt skapa ett nytt. Den använder Git-lagringsplatsen som den enda sanningskällan för Kubernetes-konfiguration och programlogik. Den kan skapa och tillämpa klusterkonfigurationen och programdistributionen som en skalningsenhet och kan upprätta distributionsstämpelmönstret.

Säkerhet

Säkerhet ger garantier mot avsiktliga attacker och missbruk av dina värdefulla data och system. Mer information finns i Översikt över säkerhetspelare.

Med GitOps-metoden får enskilda utvecklare eller administratörer inte direkt åtkomst till Kubernetes-kluster för att tillämpa ändringar eller uppdateringar. I stället skickar användarna ändringar till en Git-lagringsplats och GitOps-operatorn (Flux eller Argo CD) läser ändringarna och tillämpar dem på klustret. Den här metoden följer bästa praxis för säkerhet med minsta möjliga behörighet genom att inte ge DevOps-team skrivbehörighet till Kubernetes-API:et. I diagnostik- eller felsökningsscenarier kan du bevilja klusterbehörigheter för en begränsad tid från fall till fall.

Utöver uppgiften att konfigurera lagringsplatsens behörigheter bör du överväga att implementera följande säkerhetsåtgärder i Git-lagringsplatser som synkroniseras med AKS-kluster:

  • Grenskydd: Skydda de grenar som representerar tillståndet för Kubernetes-kluster från att skicka ändringar direkt till dem. Använd pr för att göra ändringar och låt minst en annan person granska varje PR. Använd även PR:er för att utföra automatiska kontroller.
  • PR-granskning: Kräv att pr-begärandena har minst en granskare för att framtvinga principen med fyra ögon. Du kan också använda funktionen GitHub-kodägare för att definiera individer eller team som ansvarar för att granska specifika filer på en lagringsplats.
  • Oföränderlig historik: Tillåt endast nya incheckningar utöver befintliga ändringar. Oföränderlig historik är särskilt viktig för granskningsändamål.
  • Ytterligare säkerhetsåtgärder: Kräv att dina GitHub-användare aktiverar tvåfaktorautentisering. Tillåt också endast incheckningar som är signerade för att förhindra ändringar.

Kostnadsoptimering

Kostnadsoptimering handlar om att titta på sätt att minska onödiga utgifter och förbättra drifteffektiviteten. Mer information finns i Översikt över kostnadsoptimeringspelare.

  • På den kostnadsfria nivån erbjuder AKS kostnadsfri klusterhantering. Kostnaderna är begränsade till de beräknings-, lagrings- och nätverksresurser som AKS använder för att vara värd för noder.
  • GitHub erbjuder en kostnadsfri tjänst, men om du vill använda avancerade säkerhetsrelaterade funktioner som kodägare eller nödvändiga granskare behöver du teamplanen. Mer information finns på sidan med GitHub-priser.
  • Azure DevOps erbjuder en kostnadsfri nivå som du kan använda i vissa scenarier.
  • Normalt beräknar du kostnader med hjälp av priskalkylatorn för Azure.

Driftsäkerhet

Driftskvalitet omfattar de driftsprocesser som distribuerar ett program och håller det igång i produktion. Mer information finns i Översikt över grundpelare för driftskvalitet.

GitOps kan öka DevOps-produktiviteten. En av de mest användbara funktionerna är möjligheten att snabbt återställa ändringar som beter sig oväntat, bara genom att utföra Git-åtgärder. Incheckningsdiagrammet innehåller fortfarande alla incheckningar, så det kan hjälpa till med analysen efter döden.

GitOps-team hanterar ofta flera miljöer för samma program. Det är vanligt att ha flera steg i ett program som distribueras till olika Kubernetes-kluster eller namnområden. Git-lagringsplatsen, som är den enda sanningskällan, visar vilka versioner av program som för närvarande distribueras till ett kluster.

Distribuera ett scenario

Följande lista innehåller referenser för information om hur du distribuerar de fem scenarierna:

Deltagare

Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.

Huvudförfattare:

Om du vill se icke-offentliga LinkedIn-profiler loggar du in på LinkedIn.

Nästa steg