Bewerken

GitOps voor Azure Kubernetes Service

Azure Kubernetes Service (AKS)
GitHub

GitOps is een set principes voor het werken en beheren van een softwaresysteem. In dit artikel worden technieken beschreven voor het gebruik van GitOps-principes om een AKS-cluster (Azure Kubernetes Services) te gebruiken en te beheren.

De Flux-, Argo CD-, OPA Gatekeeper-, Kubernetes- en Git-logo's zijn handelsmerken van hun respectieve bedrijven. Er wordt geen goedkeuring geïmpliceerd door het gebruik van deze markeringen.

Architectuur

Twee GitOps-operators die u met AKS kunt gebruiken, zijn Flux en Argo CD. Ze zijn beide ge graduated Cloud Native Computing Foundation -projecten (CNCF) en worden veel gebruikt. In de volgende scenario's ziet u manieren om ze te gebruiken.

Scenario 1: GitOps met Flux en AKS

Diagram van GitOps met Flux v2, GitHub en AKS.

Een Visio-bestand van deze architectuur downloaden.

Gegevensstroom voor scenario 1

Flux is een systeemeigen clusterextensie voor AKS. Clusterextensies bieden een platform voor het installeren en beheren van oplossingen op een AKS-cluster. U kunt Azure Portal, de Azure CLI of IaC-scripts (infrastructure as code), zoals Terraform- of Bicep-scripts, gebruiken om Flux in te schakelen als een extensie voor AKS. U kunt Azure Policy ook gebruiken om Flux v2-configuraties op schaal toe te passen op AKS-clusters. Zie Toepassingen consistent op schaal implementeren met flux v2-configuraties en Azure Policy voor meer informatie.

Flux kan Kubernetes-manifesten, Helm-grafieken en Kustomization-bestanden implementeren in AKS. Flux is een proces op basis van poll, zodat configuratiewijzigingen kunnen worden gedetecteerd, opgehaald en afgestemd zonder clustereindpunten beschikbaar te maken voor uw buildagents.

In dit scenario kunnen Kubernetes-beheerders Kubernetes-configuratieobjecten wijzigen, zoals geheimen en configuratie Kaarten en de wijzigingen rechtstreeks doorvoeren in een GitHub-opslagplaats.

De gegevensstroom voor dit scenario is:

  1. De ontwikkelaar doorvoert configuratiewijzigingen in de GitHub-opslagplaats.
  2. Flux detecteert configuratiedrift in de Git-opslagplaats en haalt de configuratiewijzigingen op.
  3. Flux afstemmen de status in het Kubernetes-cluster.

Alternatieven voor scenario 1

  • U kunt Flux gebruiken met andere Git-opslagplaatsen, zoals Azure DevOps, GitLab en BitBucket.
  • In plaats van Git-opslagplaatsen definieert Flux Bucket API een bron voor het produceren van een artefact voor objecten uit opslagoplossingen zoals Amazon S3 en Google Cloud Storage-buckets. U kunt ook een oplossing gebruiken die een S3-compatibele API heeft. Twee voorbeelden zijn Minio en Alibaba Cloud OSS, maar er zijn nog andere.
  • U kunt Flux ook configureren voor een Azure Blob Storage-container als bron voor het produceren van artefacten. Zie GitOps Flux v2-configuraties met AKS en Kubernetes met Azure Arc voor meer informatie.

Scenario 2: GitOps gebruiken met Flux, GitHub en AKS om CI/CD te implementeren

Diagram van het implementeren van CI/CD met behulp van GitOps met Flux, GitHub en AKS.

Een Visio-bestand van deze architectuur downloaden.

Gegevensstroom voor scenario 2

Dit scenario is een op pull gebaseerde DevOps-pijplijn voor een typische webtoepassing. De pijplijn maakt gebruik van GitHub Actions voor het bouwen. Voor implementatie wordt Flux gebruikt als gitOps-operator om de app op te halen en te synchroniseren. De gegevens stromen als volgt door het scenario:

  1. De app-code wordt ontwikkeld met behulp van een IDE, zoals Visual Studio Code.
  2. De app-code wordt doorgevoerd in een GitHub-opslagplaats.
  3. GitHub Actions bouwt een containerinstallatiekopieën van de app-code en pusht de containerinstallatiekopieën naar Azure Container Registry.
  4. GitHub Actions werkt een Kubernetes-manifestimplementatiebestand bij met de huidige installatiekopieënversie die is gebaseerd op het versienummer van de containerinstallatiekopieën in Azure Container Registry.
  5. De Flux-operator detecteert configuratiedrift in de Git-opslagplaats en haalt de configuratiewijzigingen op.
  6. Flux gebruikt manifestbestanden om de app te implementeren in het AKS-cluster.

Scenario 3: GitOps met Argo CD, GitHub-opslagplaats en AKS

Diagram van GitOps met Argo CD, GitHub en AKS.

Een Visio-bestand van deze architectuur downloaden.

Gegevensstroom voor scenario 3

In dit scenario kan de Kubernetes-beheerder Kubernetes-configuratieobjecten wijzigen, zoals geheimen en configuratie Kaarten en de wijzigingen rechtstreeks doorvoeren in de GitHub-opslagplaats.

De gegevensstroom voor dit scenario is:

  1. De Kubernetes-beheerder brengt configuratiewijzigingen aan in YAML-bestanden en voert de wijzigingen door in de GitHub-opslagplaats.
  2. Argo CD haalt de wijzigingen op uit de Git-opslagplaats.
  3. Argo CD stemt de configuratiewijzigingen in het AKS-cluster af.

Argo CD hoeft de gewenste doelstatus niet automatisch te synchroniseren met het AKS-cluster. Het wordt geïmplementeerd als een Kubernetes-controller die continu actieve toepassingen bewaakt. Hiermee wordt de huidige, livestatus van het AKS-cluster vergeleken met de gewenste doelstatus die is opgegeven in de Git-opslagplaats. Argo CD-rapporten en visualiseert de verschillen, terwijl faciliteiten worden geboden om de livestatus automatisch of handmatig te synchroniseren naar de gewenste doelstatus.

Argo CD biedt een gebruikersinterface op basis van een browser. U kunt deze gebruiken om toepassingsconfiguraties toe te voegen, de synchronisatiestatus met betrekking tot het cluster te observeren en synchronisatie te starten met het cluster. U kunt ook de Argo CD-opdrachtregel gebruiken om deze dingen te doen. Zowel de gebruikersinterface als de opdrachtregelinterface bieden functies om de geschiedenis van configuratiewijzigingen weer te geven en terug te keren naar een eerdere versie.

Standaard worden de Argo CD-gebruikersinterface en de API-server niet weergegeven. Voor toegang tot deze controller raden we u aan een toegangsbeheerobjectcontroller te maken die een intern IP-adres heeft. U kunt ook een interne load balancer gebruiken om ze beschikbaar te maken.

Alternatieven voor scenario 3

Elke opslagplaats die compatibel is met Git, met inbegrip van Azure DevOps, kan fungeren als de opslagplaats voor de configuratiebron.

Scenario 4: GitOps gebruiken met Argo CD, GitHub Actions en AKS om CI/CD te implementeren

Diagram van het implementeren van CI/CD met Behulp van GitOps met Argo CD, GitHub en AKS.

Een Visio-bestand van deze architectuur downloaden.

Gegevensstroom voor scenario 4

Dit scenario is een op pull gebaseerde DevOps-pijplijn voor een typische webtoepassing. De pijplijn maakt gebruik van GitHub Actions voor het bouwen. Voor implementatie wordt Argo CD gebruikt als gitops-operator om de app op te halen en te synchroniseren. De gegevens stromen als volgt door het scenario:

  1. De app-code wordt ontwikkeld met behulp van een IDE, zoals Visual Studio Code.
  2. De app-code wordt doorgevoerd in een GitHub-opslagplaats.
  3. GitHub Actions bouwt een containerinstallatiekopieën van de app-code en pusht de containerinstallatiekopieën naar Azure Container Registry.
  4. GitHub Actions werkt een Kubernetes-manifestimplementatiebestand bij met de huidige installatiekopieënversie die is gebaseerd op het versienummer van de containerinstallatiekopieën in Azure Container Registry.
  5. Argo CD haalt gegevens op uit de Git-opslagplaats.
  6. Argo CD implementeert de app in het AKS-cluster.

Alternatieven voor scenario 4

Elke opslagplaats die compatibel is met Git, met inbegrip van Azure DevOps, kan fungeren als de opslagplaats voor de configuratiebron.

Scenariodetails

GitOps is een set principes voor het werken en beheren van een softwaresysteem.

  • Het maakt gebruik van broncodebeheer als de enige bron van waarheid voor het systeem.
  • Het past ontwikkelprocedures toe, zoals versiebeheer, samenwerking, naleving en continue integratie/continue implementatie (CI/CD) voor infrastructuurautomatisering.
  • U kunt het toepassen op elk softwaresysteem.

GitOps wordt vaak gebruikt voor Kubernetes-clusterbeheer en toepassingslevering. In dit artikel worden enkele algemene opties beschreven voor het gebruik van GitOps samen met een AKS-cluster.

Volgens gitOps-principes moet de gewenste status van een door GitOps beheerd systeem het volgende zijn:

  1. Declaratief: een systeem dat door GitOps wordt beheerd, moet de gewenste status declaratief hebben uitgedrukt. De declaratie wordt doorgaans opgeslagen in een Git-opslagplaats.
  2. Versiebeheer en onveranderbaar: de gewenste status wordt opgeslagen op een manier die onveranderbaarheid en versiebeheer afdwingt en een volledige versiegeschiedenis behoudt.
  3. Automatisch opgehaald: Softwareagenten halen automatisch de gewenste statusdeclaraties van de bron op.
  4. Continu afgestemd: Softwareagenten observeren continu de werkelijke systeemstatus en proberen de gewenste status toe te passen.

In GitOps gebruikt infrastructuur als code (IaC) code om de gewenste status van infrastructuuronderdelen zoals virtuele machines (VM's), netwerken en firewalls te declareren. Deze code is versiebeheerd en controleerbaar.

Kubernetes beschrijft alles van clusterstatus tot toepassingsimplementaties declaratief met manifesten. GitOps voor Kubernetes plaatst de gewenste status van de clusterinfrastructuur onder versiebeheer. Een onderdeel in het cluster, meestal een operator genoemd, synchroniseert continu de declaratieve status. Met deze methode kunt u codewijzigingen controleren en controleren die van invloed zijn op het cluster. Het verbetert de beveiliging door het principe van minimale bevoegdheden te ondersteunen.

GitOps-agents stemmen de systeemstatus continu af met de gewenste status die is opgeslagen in uw codeopslagplaats. Sommige GitOps-agents kunnen bewerkingen die buiten het cluster worden uitgevoerd, herstellen, zoals het handmatig maken van Kubernetes-objecten. Toegangscontrollers dwingt bijvoorbeeld beleidsregels af voor objecten tijdens het maken, bijwerken en verwijderen van bewerkingen. U kunt deze gebruiken om ervoor te zorgen dat implementaties alleen worden gewijzigd als de implementatiecode in de bronopslagplaats wordt gewijzigd.

U kunt hulpprogramma's voor beleidsbeheer en afdwinging combineren met GitOps om beleid af te dwingen en feedback te geven voor voorgestelde beleidswijzigingen. U kunt meldingen voor verschillende teams zo configureren dat ze de bijgewerkte GitOps-status hebben. U kunt bijvoorbeeld meldingen verzenden over geslaagde implementaties en afstemmingsfouten.

GitOps als de enige bron van waarheid

GitOps biedt consistentie en standaardisatie van de clusterstatus en kan helpen de beveiliging te verbeteren. U kunt GitOps ook gebruiken om een consistente status in meerdere clusters te garanderen. GitOps kan bijvoorbeeld dezelfde configuratie toepassen op primaire en noodherstelclusters of in een farm met clusters.

Als u wilt afdwingen dat alleen GitOps de clusterstatus kan wijzigen, kunt u directe toegang tot het cluster beperken. Er zijn verschillende manieren om dit te doen, waaronder op rollen gebaseerd toegangsbeheer (RBAC) van Azure, toegangscontrollers en andere hulpprogramma's.

GitOps gebruiken om de eerste configuratie te bootstrapen

Het is mogelijk om AKS-clusters te implementeren als onderdeel van de basislijnconfiguratie. Een voorbeeld is dat u een set gedeelde services of een configuratie moet implementeren voordat u workloads implementeert. Deze gedeelde services kunnen AKS-invoegtoepassingen configureren, zoals:

U kunt Flux inschakelen als een extensie die wordt toegepast wanneer u een AKS-cluster maakt. Flux kan vervolgens de basislijnconfiguratie naar het cluster bootstrapen. De basislijnarchitectuur voor een AKS-cluster stelt voor het gebruik van GitOps voor bootstrapping te gebruiken. Als u de Flux-extensie gebruikt, kunt u clusters zeer snel na de implementatie bootstrapen.

Andere GitOps-hulpprogramma's en invoegtoepassingen

U kunt de beschreven scenario's uitbreiden naar andere GitOps-hulpprogramma's. Jenkins X is een ander GitOps-hulpprogramma dat instructies biedt voor integratie met Azure. U kunt hulpprogramma's voor progressieve levering, zoals Flagger , gebruiken voor geleidelijke verschuiving van productieworkloads die zijn geïmplementeerd via GitOps.

Potentiële gebruikscases

Deze oplossing profiteert van elke organisatie die de voordelen van het implementeren van toepassingen en infrastructuur als code wil, met een audittrail van elke wijziging.

GitOps beschermt de ontwikkelaar van de complexiteit van het beheren van een containeromgeving. Ontwikkelaars kunnen blijven werken met vertrouwde hulpprogramma's zoals Git om updates en nieuwe functies te beheren. Op deze manier verbetert GitOps de productiviteit van ontwikkelaars.

Overwegingen

Met deze overwegingen worden de pijlers van het Azure Well-Architected Framework geïmplementeerd. Dit is een set richtlijnen die u kunt gebruiken om de kwaliteit van een workload te verbeteren. Zie Microsoft Azure Well-Architected Framework voor meer informatie.

Betrouwbaarheid

Betrouwbaarheid zorgt ervoor dat uw toepassing kan voldoen aan de toezeggingen die u aan uw klanten hebt gedaan. Zie Overzicht van de betrouwbaarheidspijler voor meer informatie.

Een van de belangrijkste pijlers van betrouwbaarheid is tolerantie. Het doel van flexibiliteit is ervoor te zorgen dat de toepassing na een storing weer volledig functioneert. Als een cluster niet meer beschikbaar is, kan GitOps snel een nieuw cluster maken. De Git-opslagplaats wordt gebruikt als de enige bron van waarheid voor Kubernetes-configuratie- en toepassingslogica. Hiermee kunt u de clusterconfiguratie en toepassingsimplementatie maken en toepassen als een schaaleenheid en het implementatiestempelpatroon instellen.

Beveiliging

Beveiliging biedt garanties tegen opzettelijke aanvallen en misbruik van uw waardevolle gegevens en systemen. Zie Overzicht van de beveiligingspijler voor meer informatie.

Met de GitOps-benadering hebben individuele ontwikkelaars of beheerders niet rechtstreeks toegang tot de Kubernetes-clusters om wijzigingen of updates toe te passen. In plaats daarvan pushen gebruikers wijzigingen naar een Git-opslagplaats en de GitOps-operator (Flux of Argo CD) leest de wijzigingen en past deze toe op het cluster. Deze benadering volgt de best practice voor beveiliging van minimale bevoegdheden door DevOps-teams schrijfmachtigingen voor de Kubernetes-API niet te geven. In diagnostische scenario's of scenario's voor probleemoplossing kunt u clustermachtigingen gedurende een beperkte periode per geval verlenen.

Afgezien van de taak voor het instellen van opslagplaatsmachtigingen, kunt u overwegen de volgende beveiligingsmaatregelen te implementeren in Git-opslagplaatsen die worden gesynchroniseerd met AKS-clusters:

  • Vertakkingsbeveiliging: beveilig de vertakkingen die de status van de Kubernetes-clusters vertegenwoordigen, zodat wijzigingen rechtstreeks naar deze clusters worden gepusht. Gebruik PULL's om wijzigingen aan te brengen en laat ten minste één andere persoon elke pull-aanvraag controleren. Gebruik ook PULL's om automatische controles uit te voeren.
  • PR-beoordeling: vereisen dat PULL's ten minste één revisor hebben om het principe van vier ogen af te dwingen. U kunt ook de functie Voor eigenaren van GitHub-code gebruiken om personen of teams te definiëren die verantwoordelijk zijn voor het controleren van specifieke bestanden in een opslagplaats.
  • Onveranderbare geschiedenis: alleen nieuwe doorvoeringen toestaan boven op bestaande wijzigingen. Onveranderbare geschiedenis is vooral belangrijk voor controledoeleinden.
  • Verdere beveiligingsmaatregelen: vereist dat uw GitHub-gebruikers tweeledige verificatie activeren. Sta ook alleen doorvoeringen toe die zijn ondertekend, om wijzigingen te voorkomen.

Kostenoptimalisatie

Kostenoptimalisatie gaat over manieren om onnodige uitgaven te verminderen en operationele efficiëntie te verbeteren. Zie Overzicht van de pijler kostenoptimalisatie voor meer informatie.

  • In de gratis laag biedt AKS gratis clusterbeheer. De kosten zijn beperkt tot de reken-, opslag- en netwerkresources die AKS gebruikt voor het hosten van knooppunten.
  • GitHub biedt een gratis service, maar als u geavanceerde beveiligingsfuncties zoals code-eigenaren of vereiste revisoren wilt gebruiken, hebt u het teamplan nodig. Zie de gitHub-pagina met prijzen voor meer informatie.
  • Azure DevOps biedt een gratis laag die u voor sommige scenario's kunt gebruiken.
  • Gebruik de Azure-prijscalculator om een schatting van de kosten te maken.

Operationele uitmuntendheid

Operationele uitmuntendheid omvat de operationele processen die een toepassing implementeren en deze in productie houden. Zie Overzicht van de operationele uitmuntendheidpijler voor meer informatie.

GitOps kan de DevOps-productiviteit verhogen. Een van de handigste functies is de mogelijkheid om snel wijzigingen terug te draaien die onverwacht werken, alleen door Git-bewerkingen uit te voeren. De doorvoergrafiek bevat nog steeds alle doorvoeringen, zodat deze kan helpen bij de post-mortemanalyse.

GitOps-teams beheren vaak meerdere omgevingen voor dezelfde toepassing. Het is gebruikelijk dat er verschillende fasen van een toepassing zijn die zijn geïmplementeerd in verschillende Kubernetes-clusters of -naamruimten. De Git-opslagplaats, die de enige bron van waarheid is, laat zien welke versies van toepassingen momenteel in een cluster worden geïmplementeerd.

Een scenario implementeren

De volgende lijst bevat verwijzingen naar informatie over het implementeren van de vijf scenario's:

  • Scenario 1: Zie zelfstudie: Toepassingen implementeren met GitOps met Flux v2 met Flux v2 voor hulp bij het gebruik van GitOps met Flux v2. Zie de referentie-implementatie voor de AKS-basislijn voor een voorbeeld van het gebruik van de Flux-extensie om de implementatie van AKS-clusters te bootstrapen.
  • Scenario 2: Voor hulp bij het gebruik van GitOps met Flux v2 op AKS voor het implementeren van toepassingen en voor het implementeren van CI/CD, raadpleegt u: Zelfstudie: CI/CD implementeren met GitOps (Flux v2).
  • Scenario's 3 en 4: Zie het pull-gebaseerde CI/CD-scenario in AKS-basislijnautomatisering voor stapsgewijze instructies voor het implementeren van een voorbeeldworkload met Argo CD en AKS.

Medewerkers

Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.

Hoofdauteur:

Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.

Volgende stappen