CI/CD- och GitOps-discipliner med Azure Arc-aktiverade Kubernetes

  • Artikel

Som en molnbaserad konstruktion kräver Kubernetes en molnbaserad metod för distribution och åtgärder. Med GitOps deklarerar du önskat tillstånd för dina programbaserade distributioner i filer som lagras i Git-lagringsplatser. Program har Kubernetes-objekt som de behöver köra, som kan omfatta distributioner, horisontell podd-autoskalning, tjänster och konfiguration Kartor. Kubernetes-operatorer körs i klustren och avstäm kontinuerligt varje klusters tillstånd med önskat tillstånd som deklarerats i git-lagringsplatsen. Dessa operatorer hämtar filer från dina Git-lagringsplatser och tillämpar önskat tillstånd på dina kluster. Operatörerna ser också kontinuerligt till att klustret förblir i önskat tillstånd.

Genom att implementera GitOps kan du:

  • Förbättra den övergripande synligheten för kubernetes-klustertillståndet och konfigurationen.
  • Ha en enkel gransknings- och versionshistorik för ändringar i klustret via Git-ändringshistoriken som visar vem som gjorde ändringar, när dessa ändringar gjordes och varför.
  • Korrigera automatiskt drift som kan uppstå i klustret.
  • Återställ Kubernetes-konfigurationen till en tidigare version via Git-återställningskommandon eller Git-återställningskommandon. Att återskapa klusterdistributionen för haveriberedskapsscenarier blir också en snabb och enkel process eftersom den Kubernetes-klusterkonfiguration som du vill ha lagras i Git.
  • Förbättra säkerheten genom att minska antalet tjänstkonton som krävs för att ha distributionsbehörighet till klustret.
  • Implementera en CI/CD-pipeline för att distribuera program till klustret.

GitOps på Azure Arc-aktiverade Kubernetes använder ett tillägg som implementerar Flux, en populär verktygsuppsättning med öppen källkod. Flux är en operator som automatiserar GitOps-konfigurationsdistributioner i klustret. Flux har stöd för vanliga filkällor (Git-lagringsplatser, Helm-lagringsplatser, bucketar) och malltyper (YAML, Helm och Kustomize). Flux stöder även hantering av beroenden för flera innehavare och distribution bland andra funktioner.

Arkitektur

Följande diagram illustrerar en konceptuell referensarkitektur som visar installation av Flux-klustertillägget i ett kluster, GitOps-konfigurationsprocessen för ett Azure Arc-aktiverat Kubernetes-kluster och GitOps Flow.

Etableringsprocess för Flux v2-klustertillägg:

Diagram that shows Flux extension installation.

GitOps-konfigurationsprocess:

Diagram that shows how to configure GitOps.

GitOps Flow som visar en programuppdatering:

Diagram that shows a typical GitOps workflow.

Utformningsbeaktanden

Läs följande designöverväganden när du planerar att implementera GitOps för Azure Arc-aktiverade Kubernetes.

Konfiguration

Fundera över de olika konfigurationslagren i Kubernetes-klustret och de ansvarsområden som ingår i etableringen av dessa.

Konfigurationslager

  • Programkonfiguration som krävs för att distribuera ett program och dess relaterade Kubernetes-objekt till klustret, till exempel distributions-, tjänst-, HPA- och ConfigMap-resurser. Programkonfigurationer tillämpas vanligtvis på en GitOps-konfiguration på namnområdesnivå, vilket innebär att programkomponenterna endast får konfigureras i ett enda namnområde.
  • Klusteromfattande konfiguration för skapande av Kubernetes-objekt som namnområden, tjänstkonton, roller och rollbindningar och andra klusteromfattande principer.
  • Klusteromfattande komponenter, till exempel en ingångskontrollant, övervakning och säkerhetsstack och olika agenter som körs i klustret.

Ansvar

  • Programutvecklare ansvarar för att push-överföra källkoden, utlösa byggen och skapa containeravbildningar.
  • Programoperatörer ansvarar för att underhålla programdatabaser, konfigurationer, miljövariabler, appspecifika helm-diagram, Kustomizations osv.
  • Klusteroperatörer ansvarar för att konfigurera klusterbaslinjen. De tar vanligtvis hand om att konfigurera klusteromfattande komponenter och principer. De underhåller en Git-lagringsplatskatalog (eller flera kataloger) som innehåller vanliga infrastrukturverktyg som namnområden, tjänstkonton, rollbindningar, CRD:er, klusteromfattande principer, ingresskomponenter osv.

Lagringsplatsstruktur

Du måste göra vissa avvägningar när du väljer en Git-lagringsplatsstruktur. Den struktur du väljer definierar ditt Kubernetes-klustertillstånd, som omfattar program och klusteromfattande komponenter. Beroende på vilka ansvarsområden och personer du identifierar är det viktigt att överväga alla nödvändiga samarbeten eller teamoberoenden som krävs för de olika alternativen för lagringsplatsstrukturer.

Du kan använda valfri förgreningsstrategi som du vill för dina kodlagringsplatser, eftersom den endast används av din CI-process (Continuous Integration).

För dina GitOps-konfigurationslagringsplatser bör du överväga följande strategier utifrån organisationens affärsbehov, storlek och verktyg:

  • Enskild lagringsplats (gren per miljö):
    • Ger den största flexibiliteten för att styra Git-principer och -behörigheter för varje gren som representerar en miljö.
    • Nackdelen är att det inte finns någon delning av den gemensamma konfigurationen mellan miljöer, eftersom verktyg som Kustomize inte fungerar med Git-grenar.
  • Enskild lagringsplats (katalog per miljö):
    • Du kan implementera den här metoden med hjälp av verktyg som Kustomize, som gör att du kan definiera en baskonfiguration för Kubernetes-objekt och en uppsättning artefakter (dvs. korrigeringar) för din miljö som åsidosätter konfigurationer i basen.
    • Den här metoden kan minska duplicerade YAML-filer för varje miljö, men minskar även konfigurationsavgränsningen mellan miljöer. En enskild ändring av lagringsplatsen har potential att påverka alla miljöer samtidigt. Därför är det viktigt att du känner till effekten av ändringar i baskataloger och är försiktig när du gör ändringar.
  • Flera lagringsplatser (var och en används i ett särskilt syfte):
    • Det här kan vara ett sätt att separera konfigurationslagringsplatser för varje program, team, lager eller klientorganisation.
    • Detta gör det möjligt för team att ha mer oberoende kontroll men går bort från principen att definiera systemtillståndet på en enda lagringsplats för att förbättra den centrala konfigurationen, synligheten och kontrollen av distributioner till ett kluster.
    • Överväg att konfigurera flera lagringsplatser om du behöver flera klientorganisationer. Det finns inbyggd rollbaserad åtkomstkontroll (RBAC) och säkerhet som begränsar vilken konfiguration som ett team/en klientorganisation som har tilldelats till en specifik lagringsplats kan tillämpa. Det går till exempel att endast tillåta distribution till vissa namnområden.

Se fler sätt att strukturera lagringsplatsen i Flux-guiden.

Program- och plattformskonfiguration

Plattformsoperatörer och programoperatörer har flera alternativ för att hantera Kubernetes-konfiguration:

  • Råa Kubernetes YAML-filer som representerar YAML-specifikationer för varje Kubernetes API-objekt som du distribuerar kan fungera bra för enskilda miljöer. Nackdelen med att använda råa YAML-filer är att det blir svårt att anpassa när du börjar införliva flera miljöer, eftersom du sedan måste duplicera YAML-filer och det inte finns någon bra återanvändningsmetod.
  • Helm är ett pakethanteringsverktyg för Kubernetes-objekt. Det är ett giltigt alternativ som klusteroperatörer kan använda för att installera program från tredje part utanför hyllan. Se till att du inte använder mallar för mycket som ett konfigurationshanteringsverktyg för interna program, eftersom det kan bli komplext att hantera allt eftersom dina mallar växer.
    • Om du använder Helm innehåller Flux en Helm-kontrollant som låter dig deklarativt hantera Helm Chart-versioner med Kubernetes-manifest. Du kan skapa ett HelmRelease-objekt för att hantera den processen.
  • Kustomize är ett inbyggt Kubernetes-konfigurationshanteringsverktyg som introducerar ett mallfritt sätt att anpassa programkonfigurationen.
    • Om du använder Kustomize innehåller Flux en Kustomize-kontrollant som specialiserar sig på att köra pipelines för kontinuerlig leverans för infrastruktur och arbetsbelastningar som definierats med Kubernetes-manifest och monterats med Kustomize. Du kan skapa ett Kustomization-objekt för att hantera den processen.
  • Med Azure Arc-aktiverade Kubernetes kan du i stället för att behöva hantera livscykeln och stödet för komponenter själv använda en lista över tillgängliga tillägg som Microsoft hanterar och stöder. Dessa tillägg hanteras via Azure Resource Manager. Vissa av dessa tillägg, till exempel Azure Key Vault Secrets Provider, har öppen källkod alternativ. Att hantera komponenter utanför tilläggsprocessen ger dig mer kontroll över komponenterna, men kräver också mer omkostnader för support och livscykelhantering.

Flöde för kontinuerlig integrering och kontinuerlig leverans (CI/CD)

Följande avsnitt innehåller överväganden för din programpipeline och processen för komponentuppdatering.

Programpipeline

  • Överväg att skapa, testa och validera program som du behöver inkludera i DIN CI-process. Dessa kan omfatta linting och testning som rör säkerhet, integrering och prestanda, som du behöver för att skapa en versionskandidat (RC) för miljödistributioner.
  • Du kan använda en traditionell push-distributionsmetod för att överbrygga klyftan mellan en byggcontaineravbildning i din CI-pipeline och dess distribution i ett kluster genom att anropa Kubernetes API direkt från distributionspipelinen.

För att undvika manuella konfigurationsändringar av gitops-lagringsplatsen kan du köra cd-pipelinen som ett tjänstkonto, som har behörighet att öppna pull-begäranden (PR) eller genomföra en ny ändring av containeravbildningen direkt till en konfigurationslagringsplats. Dessa ändringar kan också etablera alla YAML-objekt som krävs för ditt program.

Följande processdiagram illustrerar den traditionella program-CI-processen som ingår i ändringar som stöder GitOps.

Diagram that shows the standard GitOps process.

Process för klusteromfattande komponentuppdatering

  • Klusteroperatörer måste hantera klusteromfattande komponenter, så detta kommer sannolikt inte att komma från CD-pipelinen som används för att distribuera dina program och tjänster. Överväg att definiera en befordransprocess som är specifik för klusteroperatörer för att säkerställa att ändringar smidigt kan övergå från en miljö till en annan.
  • Om du behöver tillämpa identisk GitOps-konfiguration i stor skala på dina Azure Arc-aktiverade Kubernetes-kluster kan du överväga att tillämpa en Azure Policy som automatiskt kan installera Flux-tillägget och tillämpa GitOps-konfigurationen på befintliga Azure Arc-aktiverade Kubernetes-kluster eller på nya kluster när de registreras i Azure Arc.

När du uppdaterar konfigurationen vill du förmodligen kontrollera att ändringarna har tillämpats på önskad miljö. Du kan definiera meddelanden i Flux för att integrera med dina CI/CD-verktyg, e-post eller ChatOps-verktyg och automatiskt skicka ut aviseringar om lyckade ändringar och distributionsfel. Du kan också hitta information om distributionsstatus i Azure-portalen och via k8s-konfigurations-CLI- och ARM-API:et.

Säkerhetsfrågor

Granska följande säkerhetsöverväganden när du planerar att implementera GitOps för Azure Arc-aktiverade Kubernetes.

Autentisering av lagringsplats

  • Du kan använda en offentlig eller privat Git-lagringsplats med GitOps, men på grund av kubernetes-konfigurationernas känsliga karaktär rekommenderar vi att du använder en privat lagringsplats som kräver autentisering med SSH-nyckel eller API-nyckel. GitOps fungerar också med Git-lagringsplatser som endast är tillgängliga i ett privat nätverk så länge ditt Kubernetes-kluster kan komma åt det, men den här konfigurationen begränsar din möjlighet att använda molnbaserade Git-leverantörer som Azure Repos eller GitHub.
  • Både HTTPS- och SSH-protokoll erbjuder en tillförlitlig och säker anslutning som du kan använda för att ansluta till källkontrollverktyget. HTTPS är dock ofta enklare att konfigurera och använder en port som sällan kräver att du öppnar fler portar i brandväggarna.

Lagringsplats och grensäkerhet

  • Ange grenbehörigheter och principer på konfigurationslagringsplatsen. När din Git-lagringsplats blir den centrala delen av dina Kubernetes-distributioner är det viktigt att du konfigurerar behörigheter för att styra vem som kan läsa och uppdatera koden i en gren och att du implementerar principer för att framtvinga teamets kodkvalitet och ändringshantering. Annars kan ditt GitOps-arbetsflöde skicka kod som inte uppfyller organisationens standarder.
  • Pull-begärandepipelines (PR) kan fungera med dina grenprinciper för att verifiera YAML-konfigurationen och/eller distribuera testmiljöer efter behov. Grindar hjälper till att eliminera konfigurationsfel och öka distributionens säkerhet och förtroende.
  • När du tilldelar åtkomstbehörigheter bör du överväga vilka användare i din organisation som ska ha läsåtkomst till lagringsplatsen, åtkomst till skapande av PR och åtkomst till PR-godkännande.

Hemlighetshantering

  • Undvik att lagra oformaterad text eller base64-kodade hemligheter på din Git-lagringsplats. Överväg i stället att använda en extern hemlighetsprovider, till exempel Azure Key Vault. Med Azure Key Vault-providern för Secrets Store CSI-drivrutinen kan du integrera ett Azure-nyckelvalv som ett hemlighetslager med ett AkS-kluster (Azure Kubernetes Service) med hjälp av en CSI-volym. Den här tjänsten är tillgänglig via Det Azure Arc-aktiverade Kubernetes-tillägget. HashiCorp Vault är ett alternativ för en tredjepartshanterad hemlighetsprovider.
  • Ett annat alternativt sätt att hantera hemligheter är att använda Bitnami's Sealed Secrets, som drivs från begreppet offentliga och privata nycklar. Detta gör att operatörer kan lagra en enkelriktad krypterad hemlighet med hjälp av en offentlig nyckel i Git, som bara kan dekrypteras via den privata nyckeln, som används av en SealedSecrets-styrenhet som körs i klustret.

Designrekommendationer

Läs följande designrekommendationer när du planerar att implementera GitOps för Azure Arc-aktiverade Kubernetes.

Följande diagram innehåller referensarkitektur som illustrerar de ansvarsområden, lagringsplatser och pipelines som behövs för att implementera en GitOps-process med hjälp av Azure Arc-aktiverat Kubernetes Flux-tillägg.

Diagram that shows a GitOps Reference flow.

Centrallager

Tre Git-lagringsplatser ingår i designen:

  • Lagringsplats för programkod
    • Den här lagringsplatsen lagrar programkod och alla pipelinedefinitioner och konfigurationsskript.
    • Använd en utvecklingsstrategi för förgrening som är lätt att förstå och begränsar antalet oönskade långvariga grenar.
  • Lagringsplats för programkonfiguration
    • Den här lagringsplatsen lagrar programkonfigurationer, inklusive Kubernetes-objekt som Config Kartor, Distributioner, Tjänster och HPA-objekt. Strukturera den här lagringsplatsen med olika kataloger för varje program. Flux synkroniserar ändringar från den här lagringsplatsen och målgrenen till klustret.
    • Använd verktyg som gör det enklare för programutvecklare och operatörer att skapa inledande konfigurationer per miljö. Programoperatörer bör definiera en Kubernetes-specifik programkonfiguration som använder pakethanterare som Helm eller konfigurationsverktyg som Kustomize för att göra konfigurationen enklare.
    • Skapa en gren som representerar varje miljötyp. Detta möjliggör detaljerad kontroll av ändringar i varje specifik miljö, till exempel icke-prod- och produktionsmiljöer.
    • När ett program distribueras till ett visst namnområde använder du namnområdesomfångsfunktionen i GitOps-konfigurationen för att framtvinga konfiguration för endast ett visst namnområde.
  • Klusteromfattande konfigurationslagringsplats
    • Definiera klusteromfattande komponenter som ingresskontrollant, namnrymder, RBAC, övervakning och säkerhetsstacken för hantering av klusteroperatorer. Flux synkroniserar ändringar från den här lagringsplatsen och målgrenen till klustret.
    • Strukturera den här lagringsplatsen med olika kataloger som representerar olika komponenter.
    • Skapa en gren som representerar varje miljötyp. Detta möjliggör detaljerad kontroll av ändringar i varje specifik miljö, till exempel icke-prod- och produktionsmiljöer.
    • Klusteroperatörer bör använda pakethanterare som Helm eller konfigurationsverktyg som Kustomize-överlägg för att göra konfigurationen enklare.

CI/CD- och konfigurationsuppdateringsprocess

CI/CD- och containeravbildningsuppdateringar

  • CI-pipeline
    • Utvecklingsteam bör definiera en CI-pipeline genom en process som omfattar att skapa, linta, testa och push-överföra ett program till ditt containerregister.
  • CD-pipeline
    • Skapa en CD-pipeline som kör ett skript som riktar in sig på ändringar mot programkonfigurationslagringsplatsen. Det här skriptet skapar en tillfällig gren som kommer från målmiljön, gör en ändring i avbildningstaggversionen, genomför ändringen och öppnar en pull-begäran mot målmiljögrenen. Den här CD-pipelinen kan ha miljösteg med lämpliga miljövariabler som mål för rätt GitOps-konfigurationslagringsplats och -gren.
    • Definiera manuella godkännandesteg för miljösteg för att begränsa oönskade pull-begäranden till alla miljöer.
  • Aktivera grenprinciper på programkonfigurationslagringsplatsen för att framtvinga peer-granskning eller godkännanden för miljöer. Detta kan omfatta ett minsta antal nödvändiga granskningar eller ett automatiskt godkännande för lägre miljöer. Överväg även integreringar och godkännanden från tredje part efter behov för att uppfylla organisationens standarder.

Konfigurationsuppdateringar för hela klustret och program

  • Klusteroperatorer och programoperatörer definierar var och en konfiguration i sina respektive konfigurationslagringsplatser. Dessa användare behöver inte pipelineverktyg för att push-överföra konfigurationer. De använder i stället interna Git-inchecknings- och PR-processer för att definiera en konfiguration och skicka ändringar till en gren som representerar en miljö.
  • För nya konfigurationsdefinitioner börjar du med att definiera konfigurationen i lägre miljöer, till exempel Dev, och höjer sedan upp till högre miljöer genom sammanslagningar och pull-begäranden. Cherry-pick-konfigurationsuppdateringar som är specifika för vissa miljöer efter behov.

Feedback och aviseringar

  • Konfigurera Flux-meddelanden att avisera när GitOps-konfigurationer inte kan synkroniseras eller utlöser fel. Programoperatörer bör konfigurera aviseringar för att avgöra när en programdistribution har lyckats och är felfri. Klusteroperatörer bör konfigurera aviseringar för att avgöra när klusteromfattande komponentavstämning har misslyckats och när det finns synkroniseringsproblem med din Git-lagringsplats.
  • Implementera GitOps Anslut or för att integrera feedback från Flux-agenten till CI/CD-verktygen.

Säkerhetsrekommendationer

  • Granska styrnings - och säkerhetsrekommendationerna för dina Azure Arc-aktiverade Kubernetes-kluster.
  • Undvik oönskad åtkomst till alla klusterkonfigurationer genom att använda en privat Git-lagringsplats med autentisering och auktorisering som du kan använda för att definiera valfri konfigurationslagringsplats.
  • Få åtkomst till din Git-lagringsplats via SSH-protokollet och en SSH-nyckel om Git-providern stöder den. Om SSH inte kan användas på grund av begränsningar för utgående anslutningar, eller om git-providern inte stöder de nödvändiga SSH-biblioteken, använder du ett dedikerat tjänstkonto och associerar en API-nyckel med det kontot som Flux ska använda. Om du behöver ett alternativ till SSH när du använder GitHub kan du skapa en personlig åtkomsttoken för autentisering.
  • Konfigurera grenprinciper och behörigheter som matchar ansvaret för klustret. Ange ett minsta antal granskare för att godkänna ändringar.
  • Konfigurera en PR-pipeline för att verifiera YAML-konfigurationer och syntax och om du vill distribuera ett Kubernetes-testkluster. Konfigurera en grenprincip som kräver att den här pipelinen körs innan någon sammanslagning kan accepteras.
  • Implementera hemligheter med hjälp av Azure Key Vault-providern för Secrets Store CSI-drivrutinen, vilket möjliggör integrering av ett Azure Key Vault som ett hemlighetslager med ett Azure Arc-aktiverat Kubernetes-kluster via en CSI-volym.
  • Flux-tillägget stöder namnområdes- och klusteromfattningskonfigurationer. Välj namnområdesomfånget när konfigurationen inte ska ha åtkomst utöver ett enda namnområde.

Nästa steg

Mer information om din hybrid- och molnresa med flera moln finns i följande artiklar.