CI/CD- en GitOps-disciplines met Kubernetes met Azure Arc

  • Artikel

Als cloudeigen constructie vereist Kubernetes een cloudeigen benadering voor implementatie en bewerkingen. Met GitOps declareert u de gewenste status van uw implementaties op basis van toepassingen in bestanden die zijn opgeslagen in Git-opslagplaatsen. Toepassingen hebben Kubernetes-objecten die ze moeten uitvoeren, waaronder implementaties, horizontale schaalaanpassing van pods, services en configuratie Kaarten. Kubernetes-operators worden uitgevoerd in de clusters en stemmen de status van elk cluster voortdurend af met de gewenste status die is gedeclareerd in uw Git-opslagplaats. Deze operators halen bestanden op uit uw Git-opslagplaatsen en passen de gewenste status toe op uw clusters. De operators zorgen er ook continu voor dat uw cluster de gewenste status heeft.

Door GitOps te implementeren, kunt u het volgende doen:

  • Verbeter de algehele zichtbaarheid van de status en configuratie van uw Kubernetes-cluster.
  • Zorg voor een eenvoudige controle- en versiegeschiedenis van wijzigingen in uw cluster via Git-wijzigingsgeschiedenis die laat zien wie wijzigingen heeft aangebracht, wanneer deze wijzigingen zijn aangebracht en waarom.
  • Corrigeer automatisch afwijkingen die zich in uw cluster kunnen voordoen.
  • Draai uw Kubernetes-configuratie terug naar een eerdere versie via Git-terugdraaiopdrachten of Git-terugdraaiopdrachten. Het opnieuw maken van clusterimplementaties voor scenario's voor herstel na noodgevallen wordt ook een snel, eenvoudig proces omdat de gewenste Clusterconfiguratie van Kubernetes is opgeslagen in Git.
  • Verbeter de beveiliging door het aantal serviceaccounts te verminderen dat nodig is om implementatiemachtigingen voor uw cluster te hebben.
  • Implementeer een CI/CD-pijplijn voor het implementeren van toepassingen in uw cluster.

GitOps in Kubernetes met Azure Arc maakt gebruik van een extensie waarmee Flux, een populaire opensource-hulpprogrammaset, wordt geïmplementeerd. Flux is een operator waarmee gitOps-configuratie-implementaties in uw cluster worden geautomatiseerd. Flux biedt ondersteuning voor algemene bestandsbronnen (Git-opslagplaatsen, Helm-opslagplaatsen, Buckets) en sjabloontypen (YAML, Helm en Kustomize). Flux biedt ook ondersteuning voor multitenancy- en implementatieafhankelijkheidsbeheer onder andere functies.

Architectuur

In de volgende diagrammen ziet u een conceptuele referentiearchitectuur waarin de installatie van de Flux-clusterextensie in een cluster, het GitOps-configuratieproces voor een Kubernetes-cluster met Azure Arc en GitOps Flow wordt gemarkeerd.

Inrichtingsproces voor Flux v2-clusterextensie:

Diagram that shows Flux extension installation.

GitOps-configuratieproces:

Diagram that shows how to configure GitOps.

GitOps Flow met een toepassingsupdate:

Diagram that shows a typical GitOps workflow.

Ontwerpoverwegingen

Bekijk de volgende ontwerpoverwegingen voor het implementeren van GitOps voor Kubernetes met Azure Arc.

Configuratie

Houd rekening met de verschillende configuratielagen in uw Kubernetes-cluster en de verantwoordelijkheden die betrokken zijn bij het inrichten ervan.

Configuratielagen

  • Toepassingsconfiguratie die nodig is om een toepassing en de bijbehorende Kubernetes-objecten te implementeren in het cluster, zoals implementatie-, service-, HPA- en ConfigMap-resources. Toepassingsconfiguraties worden doorgaans toegepast op een GitOps-configuratie op naamruimteniveau, waardoor de toepassingsonderdelen in slechts één naamruimte moeten worden geconfigureerd.
  • Clusterbrede configuratie voor het maken van Kubernetes-objecten, zoals naamruimten, serviceaccounts, rollen en rolbindingen en ander clusterbreed beleid.
  • Clusterbrede onderdelen, zoals een controller voor binnenkomend verkeer, bewaking en beveiligingsstack, en verschillende agents die in het cluster werken.

Verantwoordelijkheden

  • Toepassingsontwikkelaars zijn verantwoordelijk voor het pushen van hun broncode, het activeren van builds en het maken van containerinstallatiekopieën.
  • Toepassingsoperators zijn verantwoordelijk voor het onderhouden van de toepassingsopslagplaatsen, configuraties, omgevingsvariabelen, app-specifieke Helm-grafieken, Kustomizations, enzovoort.
  • Clusteroperators zijn verantwoordelijk voor het instellen van uw clusterbasislijn. Ze zijn gewoonlijk betrokken bij het instellen van onderdelen en beleidsregels voor het hele cluster. Ze onderhouden een Git-opslagplaatsmap of mappen met algemene infrastructuurhulpprogramma's zoals naamruimten, serviceaccounts, rolbindingen, CRD's, clusterbrede beleidsregels, onderdelen voor binnenkomend verkeer, enzovoort.

Structuur van de opslagplaats

Overweeg afwegingen bij het kiezen van een Structuur van een Git-opslagplaats. De structuur die u kiest, definieert de status van uw Kubernetes-cluster, inclusief toepassingen en onderdelen voor het hele cluster. Afhankelijk van de verantwoordelijkheden en persona's die u identificeert, is het belangrijk om rekening te houden met de benodigde samenwerking of gewenste teamonafhankelijkheid die nodig is voor verschillende opties voor opslagplaatsstructuur.

U kunt elke vertakkingsstrategie gebruiken die u voor uw codeopslagplaatsen wilt gebruiken, omdat deze alleen wordt gebruikt door uw CI-proces (Continuous Integration).

Houd voor uw GitOps-configuratieopslagplaatsen rekening met de volgende strategieën op basis van de bedrijfsbehoeften, grootte en hulpprogramma's van uw organisatie:

  • Eén opslagplaats (vertakking per omgeving):
    • Biedt de meeste flexibiliteit voor het beheren van Git-beleid en machtigingen voor elke vertakking die een omgeving vertegenwoordigt.
    • Het nadeel is dat er geen gedeelde algemene configuratie tussen omgevingen is, omdat hulpprogramma's zoals Kustomize niet werken met Git-vertakkingen.
  • Eén opslagplaats (map per omgeving):
    • U kunt deze aanpak implementeren met behulp van hulpprogramma's zoals Kustomize, waarmee u een basisconfiguratie kunt definiëren voor Kubernetes-objecten en een set artefacten (d.w.z. patches) voor uw omgeving die configuraties in de basis overschrijft.
    • Deze aanpak kan dubbele YAML-bestanden voor elke omgeving verminderen, maar vermindert ook de configuratiescheiding tussen omgevingen. Dankzij het aanbrengen van één wijziging in de opslagplaats kunnen alle omgevingen tegelijk te worden beïnvloed, dus het begrijpen van het effect van wijzigingen aan basismappen moet volledig worden begrepen en er moet terdege rekening mee worden gehouden.
  • Meerdere opslagplaatsen (elk voor een specifiek doel):
    • Dit kan worden gebruikt voor het scheiden van configuratieopslagplaatsen voor elke toepassing, elk team, elke laag of elke tenant.
    • Hierdoor kunnen teams meer onafhankelijk beheer hebben, maar het principe van het definiëren van uw systeemstatus in één opslagplaats verwijderen om de centrale configuratie, zichtbaarheid en controle van implementaties naar een cluster te verbeteren.
    • Het instellen van meerdere opslagplaatsen moet worden overwogen als er meerdere tenants nodig zijn. Er is op rollen gebaseerd toegangsbeheer (RBAC) en beveiliging ingebouwd om te beperken welke configuratie een team/tenant die aan een specifieke opslagplaats is toegewezen, kan toepassen, zoals alleen implementatie toestaan voor bepaalde naamruimten.

Meer manieren om uw opslagplaats te structureren vindt u in de Flux Guide (Flux-handleiding).

Toepassings- en platformconfiguratie

Platformoperators en toepassingsoperators hebben verschillende opties voor het beheren van de Kubernetes-configuratie:

  • Onbewerkte Kubernetes YAML-bestanden die YAML-specificaties vertegenwoordigen voor elk Kubernetes API-object dat u implementeert, kunnen goed werken voor één omgeving. Het nadeel van het gebruik van onbewerkte YAML-bestanden is dat het aanpassen moeilijk wordt wanneer u meerdere omgevingen gaat opnemen, omdat u vervolgens YAML-bestanden moet dupliceren en er geen goede methode is voor hergebruik.
  • Helm is een hulpprogramma voor pakketbeheer voor Kubernetes-objecten. Het is een geldige optie die clusteroperators kunnen gebruiken voor het installeren van externe toepassingen buiten de plank. Zorg ervoor dat u geen sjablonen te veel gebruikt als een configuratiebeheerprogramma voor interne toepassingen, omdat het complex kan worden om te beheren naarmate uw sjablonen toenemen.
    • Als u Helm gebruikt, bevat Flux een Helm-controller waarmee u declaratief Helm-grafiekreleases kunt beheren met Kubernetes-manifesten. U kunt een HelmRelease-object maken om dat proces te beheren.
  • Kustomize is een systeemeigen configuratiebeheerprogramma voor Kubernetes waarmee een sjabloonvrije manier wordt geïntroduceerd om de toepassingsconfiguratie aan te passen.
    • Als u Kustomize gebruikt, bevat Flux een Kustomize-controller die gespecialiseerd is in het uitvoeren van pijplijnen voor continue levering voor infrastructuur en workloads die zijn gedefinieerd met Kubernetes-manifesten en die zijn samengesteld met Kustomize. U kunt een Kustomization-object maken om dat proces te beheren.
  • Met Kubernetes met Azure Arc kunt u in plaats van de levenscyclus en ondersteuning van onderdelen zelf te beheren een lijst met beschikbare extensies gebruiken die Microsoft beheert en ondersteunt. Deze extensies worden beheerd via Azure Resource Manager. Sommige van deze extensies, zoals Azure Key Vault Secrets Provider, hebben opensource-alternatieven. Het beheren van onderdelen buiten het uitbreidingsproces biedt u meer controle over de onderdelen, maar vereist ook meer overhead voor ondersteuning en levenscyclusbeheer.

Stroom voor continue integratie en continue levering (CI/CD)

De volgende secties bevatten overwegingen voor het updateproces van uw toepassingspijplijn en onderdelen.

Toepassingspijplijn

  • Overweeg de toepassingsbuild, testen en validaties die u in uw CI-proces moet opnemen. Dit kunnen linting en tests omvatten met betrekking tot beveiliging, integratie en prestaties, die u nodig hebt om een releasekandidaat (RC) te maken voor omgevingsimplementaties.
  • U kunt een traditionele push-implementatiemethode gebruiken om de kloof tussen een buildcontainerinstallatiekopieën in uw CI-pijplijn en de implementatie ervan in een cluster te overbruggen door de Kubernetes-API rechtstreeks vanuit uw implementatiepijplijn aan te roepen.

Als u handmatige configuratiewijzigingen in uw GitOps-opslagplaats wilt voorkomen, kunt u uw CD-pijplijn uitvoeren als een serviceaccount, dat gemachtigd is om pull-aanvragen (PULL's) te openen of een nieuwe containerinstallatiekopie rechtstreeks in een configuratieopslagplaats doorvoeren. Deze wijzigingen kunnen ook alle YAML-objecten inrichten die vereist zijn voor uw toepassing.

Het volgende procesdiagram illustreert het traditionele CI-proces van de toepassing dat is opgenomen in wijzigingen die GitOps ondersteunen.

Diagram that shows the standard GitOps process.

Updateproces voor clusterbrede onderdelen

  • Clusteroperators moeten clusterbrede onderdelen beheren, dus dit is waarschijnlijk niet afkomstig van de CD-pijplijn die wordt gebruikt voor het implementeren van uw toepassingen en services. Overweeg om een promotieproces te definiëren dat specifiek is voor clusteroperators om ervoor te zorgen dat wijzigingen soepel kunnen worden overgestapt van de ene omgeving naar de andere.
  • Als u een identieke GitOps-configuratie op schaal wilt toepassen op uw Kubernetes-clusters met Azure Arc, kunt u overwegen een Azure Policy toe te passen waarmee de Flux-extensie automatisch kan worden geïnstalleerd en uw GitOps-configuratie kunt toepassen op bestaande Kubernetes-clusters met Azure Arc of op nieuwe clusters wanneer ze worden geïmplementeerd in Azure Arc.

Wanneer u uw configuratie bijwerkt, wilt u waarschijnlijk controleren of wijzigingen zijn toegepast op de gewenste omgeving. U kunt meldingen in Flux definiëren om te integreren met uw CI/CD-hulpprogramma's, e-mail of ChatOps-hulpprogramma's en automatisch waarschuwingen verzenden met betrekking tot geslaagde wijzigingen en implementatiefouten. U kunt ook informatie over de implementatiestatus vinden in Azure Portal en via de K8s-configuratie-CLI en ARM-API.

Beveiligingsoverwegingen

Bekijk de volgende beveiligingsoverwegingen bij het implementeren van GitOps voor Kubernetes met Azure Arc.

Verificatie van opslagplaats

  • U kunt een openbare of persoonlijke Git-opslagplaats gebruiken met GitOps, maar vanwege de gevoelige aard van Kubernetes-configuraties raden we u aan een privéopslagplaats te gebruiken waarvoor verificatie is vereist door SSH-sleutel of API-sleutel. GitOps werken ook met Git-opslagplaatsen die alleen toegankelijk zijn binnen een privénetwerk zolang uw Kubernetes-cluster er toegang toe heeft, maar deze instelling beperkt uw mogelijkheid om cloudgebaseerde Git-providers, zoals Azure-opslagplaatsen of GitHub, te gebruiken.
  • Zowel HTTPS- als SSH-protocollen bieden een betrouwbare en beveiligde verbinding die u kunt gebruiken om verbinding te maken met uw hulpprogramma voor broncodebeheer. HTTPS is echter vaak eenvoudiger in te stellen en gebruikt een poort waarvoor u zelden meer poorten in uw firewalls moet openen.

Opslagplaats- en vertakkingsbeveiliging

  • Stel vertakkingsmachtigingen en -beleidsregels in voor uw configuratieopslagplaats. Naarmate uw Git-opslagplaats het centrale onderdeel van uw Kubernetes-implementaties wordt, is het essentieel dat u machtigingen instelt om te bepalen wie de code in een vertakking kan lezen en bijwerken en dat u beleid implementeert om de codekwaliteit en wijzigingsbeheer van uw team af te dwingen. Anders kan uw GitOps-werkstroom code verzenden die niet voldoet aan de standaarden van uw organisatie.
  • Pull-aanvraagpijplijnen (PR) kunnen werken met uw vertakkingsbeleid om de YAML-configuratie te valideren en/of testomgevingen indien nodig te implementeren. Gates helpen configuratiefouten te elimineren en de implementatiebeveiliging en het vertrouwen te vergroten.
  • Wanneer u toegangsmachtigingen toewijst, moet u overwegen welke gebruikers in uw organisatie leestoegang moeten hebben tot de opslagplaats, toegang voor het maken van pull-aanvraag en goedkeuringstoegang voor pull-aanvraag.

Geheimenbeheer

  • Vermijd het opslaan van tekst zonder opmaak of met base64 gecodeerde geheimen in uw Git-opslagplaats. In plaats daarvan kunt u overwegen een externe geheimenprovider zoals Azure Key Vault te gebruiken. Met de Azure Key Vault-provider voor geheimenarchief CSI-stuurprogramma kunt u een Azure-sleutelkluis integreren als een geheimenarchief met een AKS-cluster (Azure Kubernetes Service) met behulp van een CSI-volume. Deze service is beschikbaar via de Kubernetes-extensie met Azure Arc. HashiCorp Vault is een alternatief voor beheerde geheimproviders van derden.
  • Een andere alternatieve manier om geheimen te beheren, is door bitnami's verzegelde geheimen te gebruiken, die worden beheerd vanuit het concept van openbare en persoonlijke sleutels. Hierdoor kunnen operators een versleuteld geheim in één richting opslaan met behulp van een openbare sleutel in Git, die alleen kunnen worden ontsleuteld via de persoonlijke sleutel, die wordt gebruikt door een SealedSecrets-controller die in uw cluster wordt uitgevoerd.

Ontwerpaanaanvelingen

Bekijk de volgende ontwerpaanbevelingen voor het implementeren van GitOps voor Kubernetes met Azure Arc.

Het volgende diagram bevat referentiearchitectuur die de verantwoordelijkheden, opslagplaatsen en pijplijnen illustreert die nodig zijn om een GitOps-proces te implementeren met behulp van de Kubernetes Flux-extensie met Azure Arc.

Diagram that shows a GitOps Reference flow.

Opslagplaatsen

Er zijn drie Git-opslagplaatsen opgenomen in het ontwerp:

  • Opslagplaats voor toepassingscode
    • In deze opslagplaats worden toepassingscode en eventuele pijplijndefinities en configuratiescripts opgeslagen.
    • Gebruik een vertakkingsstrategie voor ontwikkeling die gemakkelijk te begrijpen is en beperkt het aantal ongewenste langlopende vertakkingen.
  • Opslagplaats voor toepassingsconfiguratie
    • In deze opslagplaats worden toepassingsconfiguraties opgeslagen, waaronder Kubernetes-objecten zoals Config Kaarten, Deployments, Services en HPA-objecten. Structureer deze opslagplaats met verschillende directory's voor elke toepassing. Flux synchroniseert wijzigingen vanuit deze opslagplaats en doelbranch naar uw cluster.
    • Hulpprogramma's opnemen waarmee ontwikkelaars en operators van toepassingen eenvoudiger initiële configuraties per omgeving kunnen bouwen. Toepassingsoperators moeten een Kubernetes-specifieke toepassingsconfiguratie definiëren die gebruikmaakt van pakketbeheerders zoals Helm of configuratiehulpprogramma's zoals Kustomize om de configuratie eenvoudiger te maken.
    • Maak een vertakking die elk omgevingstype vertegenwoordigt. Hiermee kunt u nauwkeurig controle houden over wijzigingen in elke specifieke omgeving, zoals niet-prod- en productieomgevingen.
    • Wanneer een toepassing wordt geïmplementeerd in een bepaalde naamruimte, gebruikt u de functie voor het bereik van de naamruimte in de GitOps-configuratie om alleen de configuratie voor een bepaalde naamruimte af te dwingen.
  • Clusterbrede configuratieopslagplaats
    • Definieer clusterbrede onderdelen, zoals toegangscontroller, naamruimten, RBAC, bewaking en beveiligingsstack voor clusteroperatorbeheer. Flux synchroniseert wijzigingen uit deze opslagplaats en doelbranch naar uw cluster.
    • Structureer deze opslagplaats met verschillende mappen die verschillende onderdelen vertegenwoordigen.
    • Maak een vertakking die elk omgevingstype vertegenwoordigt. Hiermee kunt u nauwkeurig controle houden over wijzigingen in elke specifieke omgeving, zoals niet-prod- en productieomgevingen.
    • Clusteroperators moeten pakketbeheerders zoals Helm of configuratiehulpprogramma's zoals Kustomize-overlays gebruiken om de configuratie eenvoudiger te maken.

CI/CD- en configuratie-updateproces

Updates voor CI/CD- en containerinstallatiekopieën

  • CI-pijplijn
    • Ontwikkelteams moeten een CI-pijplijn definiëren via een proces dat het bouwen, linten, testen en pushen van een toepassing naar uw containerregister omvat.
  • CD-pijplijn
    • Maak een CD-pijplijn waarop een script wordt uitgevoerd dat is gericht op wijzigingen in uw toepassingsconfiguratieopslagplaats. Met dit script maakt u een tijdelijke vertakking die afkomstig is van uw doelomgeving, wijzigt u de versie van de installatiekopietag, voert u de wijziging door en opent u een pull-aanvraag voor uw doelomgevingsbranch. Deze CD-pijplijn kan omgevingsfasen hebben met de juiste omgevingsvariabelen om de juiste GitOps-configuratieopslagplaats en vertakking te richten.
    • Definieer handmatige goedkeuringsstappen voor omgevingsfasen om ongewenste pull-aanvragen te beperken tot alle omgevingen.
  • Schakel vertakkingsbeleidsregels in uw opslagplaats voor toepassingsconfiguratie in om peerbeoordeling of goedkeuringen voor omgevingen af te dwingen. Dit kan betrekking hebben op een minimum aantal vereiste beoordelingen of een automatische goedkeuring voor lagere omgevingen. Overweeg ook integraties en goedkeuringen van derden indien nodig om te voldoen aan de standaarden van uw organisatie.

Updates voor clusterbrede en toepassingsconfiguratie

  • Clusteroperators en toepassingsoperators definiëren elke configuratie in hun respectieve configuratieopslagplaatsen. Deze gebruikers hebben geen pijplijnhulpprogramma's nodig om configuraties te pushen. Ze gebruiken in plaats daarvan systeemeigen Git-doorvoer- en PR-processen om een configuratie te definiëren en wijzigingen naar een vertakking te pushen die een omgeving vertegenwoordigen.
  • Voor nieuwe configuratiedefinities definieert u eerst de configuratie in lagere omgevingen, zoals Dev, en promoveert u vervolgens naar hogere omgevingen via samenvoegingen en pull-aanvragen. Kersenkie configuratie-updates die specifiek zijn voor bepaalde omgevingen, indien nodig.

Feedback en waarschuwingen

  • Configureer Flux-meldingen om te waarschuwen wanneer GitOps-configuraties niet kunnen synchroniseren of fouten veroorzaken. Toepassingsoperators moeten waarschuwingen configureren om te bepalen wanneer een toepassingsimplementatie is geslaagd en in orde is. Clusteroperators moeten waarschuwingen configureren om te bepalen wanneer afstemming van clusterbrede onderdelen is mislukt en wanneer er synchronisatieproblemen zijn met uw Git-opslagplaats.
  • Implementeer GitOps Verbinding maken or om feedback van de Flux-agent te integreren in uw CI/CD-hulpprogramma's.

Aanbevelingen voor beveiliging

  • Bekijk de aanbevelingen voor governance en beveiliging voor uw Kubernetes-clusters met Azure Arc.
  • Vermijd ongewenste toegang tot clusterconfiguraties met behulp van een persoonlijke Git-opslagplaats met verificatie en autorisatie die u kunt gebruiken om een configuratieopslagplaats te definiëren.
  • Open uw Git-opslagplaats via het SSH-protocol en een SSH-sleutel als uw Git-provider deze ondersteunt. Als SSH onbruikbaar is vanwege uitgaande connectiviteitsbeperkingen of als uw Git-provider de vereiste SSH-bibliotheken niet ondersteunt, gebruikt u een toegewezen serviceaccount en koppelt u een API-sleutel aan dat account voor Flux. Als u een alternatief voor SSH nodig hebt bij het gebruik van GitHub, kunt u een persoonlijk toegangstoken voor verificatie maken.
  • Configureer vertakkingsbeleid en machtigingen die overeenkomen met de verantwoordelijkheden van uw cluster. Stel een minimum aantal revisoren in om wijzigingen goed te keuren.
  • Configureer een PR-pijplijn om YAML-configuraties en -syntaxis te valideren en eventueel een Kubernetes-testcluster te implementeren. Stel een vertakkingsbeleid in waarvoor deze pijplijn moet worden uitgevoerd voordat een samenvoeging kan worden geaccepteerd.
  • Implementeer geheimen met behulp van de Azure Key Vault-provider voor het CSI-stuurprogramma Secrets Store, waardoor de integratie van een Azure Key Vault als geheimenarchief mogelijk is met een Kubernetes-cluster met Azure Arc via een CSI-volume.
  • De Flux-extensie ondersteunt configuraties voor naamruimte en clusterbereik. Kies het bereik van de naamruimte wanneer uw configuratie geen toegang mag hebben buiten één naamruimte.

Volgende stappen

Zie de volgende artikelen voor meer informatie over uw hybride en multicloudcloudcloudtraject.