Freigeben über

GitOps für Azure Kubernetes Service

Azure Kubernetes Service (AKS)
GitHub

GitOps ist eine Reihe von Prinzipien für den Betrieb und die Verwaltung eines Softwaresystems. In diesem Artikel wird beschrieben, wie Sie GitOps-Prinzipien verwenden, um einen Azure Kubernetes Services-Cluster (AKS) zu betreiben und zu verwalten.

Die Logos Flux, Argo CD, OPA Gatekeeper, Kubernetes und Git sind Marken ihrer jeweiligen Unternehmen. Die Verwendung dieser Marken impliziert keine Empfehlung.

Aufbau

Zwei GitOps-Operatoren, die Sie mit AKS verwenden können, sind Flux und Argo CD. Beide sind graduierte Projekte der Cloud Native Computing Foundation (CNCF) und sind weit verbreitet. Die folgenden Szenarien zeigen Möglichkeiten, sie zu verwenden.

Szenario 1: GitOps mit Flux und AKS

Diagramm von GitOps mit Flux v2, GitHub und AKS.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Datenfluss für Szenario 1

Flux ist eine Clustererweiterung , die nativ in AKS integriert wird. Eine Clustererweiterung bietet eine Plattform zum Installieren und Verwalten von Lösungen auf einem AKS-Cluster. Sie können Azure-Portal, Azure CLI oder IaC-Skripts (Infrastructure-as-Code) wie Terraform- oder Bicep-Skripts verwenden, um Flux als Erweiterung für AKS zu aktivieren. Sie können auch Azure Policy verwenden, um Flux v2-Konfigurationen im großen Stil auf AKS-Cluster anzuwenden. Weitere Informationen finden Sie unter Bereitstellen von Anwendungen im großen Maßstab mithilfe von Flux v2-Konfigurationen und Azure-Richtlinien.

Flux kann Kubernetes-Manifeste, Helm-Diagramme und Kustomization-Dateien in AKS bereitstellen. Flux ist ein umfragebasierter Prozess, mit dem Konfigurationsänderungen erkannt, gepullt und abgestimmt werden können, ohne Clusterendpunkte für Ihre Build-Agents verfügbar zu machen.

In diesem Szenario können Kubernetes-Administrator*innen Kubernetes-Konfigurationsobjekte wie Geheimnisse und ConfigMaps ändern und die Änderungen direkt in ein GitHub-Repository committen.

Der folgende Datenfluss entspricht dem vorherigen Diagramm:

  1. Der Entwickler committet Konfigurationsänderungen in das GitHub-Repository.

  2. Flux erkennt Konfigurationsdrift im Git-Repository und holt die geänderte Konfiguration.

  3. Flux stimmt den Zustand im Kubernetes-Cluster ab.

Alternativen für Szenario 1

  • Sie können Flux mit anderen Git-Repositorys wie Azure DevOps, GitLab und Bitbucket verwenden.

  • Anstelle von Git-Repositorys definiert die Flux Bucket-API eine Quelle, um ein Artefakt für Objekte aus Speicherlösungen wie Amazon S3 und Google Cloud Storage-Buckets zu erzeugen. Sie können auch eine Lösung mit einer S3-kompatiblen API verwenden. Zwei Beispiele sind MinIO und Alibaba Cloud Object Storage Service (OSS), aber es gibt andere Lösungen.

  • Sie können Flux auch für einen Azure Blob Storage-Container als Quelle zum Erstellen von Artefakten konfigurieren. Weitere Informationen finden Sie unter GitOps Flux v2-Konfigurationen mit AKS und Kubernetes mit Azure Arc-Unterstützung.

  • Flux v2 unterstützt Mehrinstanzenfähigkeit, indem separate Teams Workloads in einem einzigen freigegebenen Kubernetes-Cluster bereitstellen können. Mehrere Git-Repositorys, die jeweils einen anderen Mandanten darstellen, können mit dem Cluster synchronisiert werden. Um die Arbeitsauslastungsisolation zwischen Teams sicherzustellen, verfügt jedes Team möglicherweise über eigene Namespaces oder Namespaces innerhalb des AKS-Clusters, auf die der Zugriff über Rollenbasierte Zugriffssteuerungsrichtlinien (RBAC) von Kubernetes eingeschränkt ist.

  • Flux kann einen Cluster verwenden, um die Apps entweder im selben Cluster oder in anderen Clustern zu verwalten. Ein Hub-AKS-Cluster mit dem Flux-Operator verwaltet die GitOps-kontinuierliche Bereitstellung von Apps und Infrastrukturworkloads an mehrere Spoke-AKS-Cluster.

Szenario 2: Verwenden von GitOps mit Flux, GitHub und AKS zum Implementieren von CI/CD

Diagramm, das zeigt, wie CI/CD mithilfe von GitOps mit Flux, GitHub und AKS implementiert wird.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Datenfluss für Szenario 2

Bei diesem Szenario handelt es sich um eine pullbasierte DevOps-Pipeline für eine typische Webanwendung. Diese Pipeline verwendet GitHub Actions zum Erstellen. Für die Bereitstellung wird Flux als GitOps-Operator zum Pullen und Synchronisieren der App verwendet.

Der folgende Datenfluss entspricht dem vorherigen Diagramm:

  1. Der App-Code wird mithilfe einer integrierten Entwicklungsumgebung (Integrated Development Environment, IDE) wie Visual Studio Code entwickelt.

  2. Der App-Code wird in ein GitHub-Repository übertragen.

  3. GitHub Actions erstellt ein Containerimage aus dem App-Code und pusht das Containerimage an die Azure Container Registry-Instanz.

  4. GitHub Actions aktualisiert eine Kubernetes-Manifestbereitstellungsdatei mit der aktuellen Imageversion, die auf der Versionsnummer des Containerimages in der Containerregistrierung basiert.

  5. Der Flux-Operator erkennt Konfigurationsabweichungen im Git-Repository und pullt die Konfigurationsänderungen.

  6. Flux verwendet Manifestdateien, um die App im AKS-Cluster bereitzustellen.

Szenario 3: GitOps mit Argo CD, GitHub-Repository und AKS

Diagramm von GitOps mit Argo CD, GitHub und AKS.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Datenfluss für Szenario 3

Sie können Argo CD als Clustererweiterung in AKS aktivieren. In diesem Szenario können Kubernetes-Administrator*innen Kubernetes-Konfigurationsobjekte wie Geheimnisse und ConfigMaps ändern und die Änderungen direkt in das GitHub-Repository committen.

Der folgende Datenfluss entspricht dem vorherigen Diagramm:

  1. Kubernetes-Administrator*innen nehmen Konfigurationsänderungen in YAML-Dateien vor und committen die Änderungen an das GitHub-Repository.

  2. Argo CD pullt die Änderungen aus dem Git-Repository.

  3. Argo CD stimmt die Konfigurationsänderungen mit dem AKS-Cluster ab.

Argo CD muss den gewünschten Zielzustand nicht automatisch mit dem AKS-Cluster synchronisieren. Es wird als Kubernetes-Controller implementiert, der laufende Anwendungen kontinuierlich überwacht. Er vergleicht den aktuellen Livestatus des AKS-Clusters mit dem gewünschten Zielstatus, der im Git-Repository angegeben ist. Argo CD berichtet und visualisiert die Unterschiede und stellt Tools bereit, um den Livezustand automatisch oder manuell mit dem gewünschten Zielzustand zu synchronisieren.

Argo CD bietet eine browserbasierte Benutzeroberfläche. Sie können damit Anwendungskonfigurationen hinzufügen, den Synchronisierungsstatus in Bezug auf den Cluster beobachten und die Synchronisierung mit dem Cluster initiieren. Sie können auch die Befehlszeile "Argo CD" verwenden, um diese Aufgaben auszuführen. Sowohl die Benutzeroberfläche als auch die Befehlszeilenschnittstelle bieten Features zum Anzeigen des Verlaufs von Konfigurationsänderungen und zum Zurücksetzen auf eine frühere Version.

Standardmäßig werden die Argo CD-Benutzeroberfläche und der API-Server nicht verfügbar gemacht. Für den Zugriff darauf sollten Sie einen Eingangsdatencontroller erstellen, der über eine interne IP-Adresse verfügt. Sie können auch einen internen Lastenausgleich verwenden , um sie verfügbar zu machen.

Alternativen für Szenario 3

Jedes Repository, das mit Git kompatibel ist, einschließlich Azure DevOps, kann als Quellrepository für die Konfiguration dienen.

Szenario 4: Verwenden von GitOps mit Argo CD, GitHub Actions und AKS zum Implementieren von CI/CD

Diagramm, das zeigt, wie CI/CD mithilfe von GitOps mit Argo CD, GitHub und AKS implementiert wird.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Datenfluss für Szenario 4

Bei diesem Szenario handelt es sich um eine pullbasierte DevOps-Pipeline für eine typische Webanwendung. Diese Pipeline verwendet GitHub Actions zum Erstellen. Für die Bereitstellung wird Argo CD als GitOps-Operator zum Pullen und Synchronisieren der App verwendet.

Der folgende Datenfluss entspricht dem vorherigen Diagramm:

  1. Der App-Code wird mithilfe einer IDE wie Visual Studio Code entwickelt.

  2. Der App-Code wird in ein GitHub-Repository übertragen.

  3. GitHub Actions erstellt ein Containerimage aus dem App-Code und verschiebt das Containerimage in die Containerregistrierung.

  4. GitHub Actions aktualisiert eine Kubernetes-Manifestbereitstellungsdatei mit der aktuellen Imageversion, die auf der Versionsnummer des Containerimages in der Containerregistrierung basiert.

  5. Argo CD pullt aus dem Git-Repository.

  6. Argo CD stellt die App im AKS-Cluster bereit.

Alternativen für Szenario 4

Jedes Repository, das mit Git kompatibel ist, einschließlich Azure DevOps, kann als Quellrepository für die Konfiguration dienen.

Szenariodetails

GitOps ist eine Reihe von Prinzipien für den Betrieb und die Verwaltung eines Softwaresystems.

  • Es verwendet die Quellcodeverwaltung als einzelne Wahrheitsinstanz für das System.

  • Sie wendet Entwicklungspraktiken wie Versionssteuerung, Zusammenarbeit, Compliance und kontinuierliche Integration und kontinuierliche Bereitstellung (CI/CD) auf die Infrastrukturautomatisierung an.

  • Sie können es auf ein beliebiges Softwaresystem anwenden.

GitOps wird oft für die Kubernetes-Clusterverwaltung und Anwendungsbereitstellung verwendet.

Nach GitOps-Prinzipien muss der gewünschte Zustand eines gitOps-verwalteten Systems die folgenden Kriterien erfüllen:

  • Deklaratorisch: Ein Von GitOps verwaltetes System muss den gewünschten Zustand deklarativ ausgedrückt haben. Die Deklaration wird in der Regel in einem Git-Repository gespeichert.

  • Versioniert und unveränderlich: Der gewünschte Zustand wird so gespeichert, dass Unveränderlichkeit und Versionierung gewährleistet sind und ein vollständiger Versionsverlauf beibehalten wird.

  • Automatisch gezogen: Software-Agents rufen automatisch die gewünschten Zustandsdeklarationen aus der Quelle ab.

  • Kontinuierlich abgestimmt: Software-Agents beobachten kontinuierlich den tatsächlichen Systemzustand und versuchen, den gewünschten Zustand anzuwenden.

In GitOps verwendet IaC Code, um den gewünschten Zustand von Infrastrukturkomponenten wie virtuellen Computern (VMs), Netzwerken und Firewalls zu deklarieren. Dieser Code ist versionsgesteuert und prüfbar.

Kubernetes beschreibt alles vom Clusterstatus bis hin zu Anwendungsbereitstellungen deklarativ mithilfe von Manifesten. GitOps für Kubernetes platziert den gewünschten Zustand der Clusterinfrastruktur in der Versionskontrolle. Eine Komponente im Cluster, die in der Regel als Operator bezeichnet wird, synchronisiert kontinuierlich den deklarativen Zustand. Dieser Ansatz ermöglicht, Codeänderungen, die sich auf den Cluster auswirken, zu überprüfen und zu überwachen. Es verbessert die Sicherheit, indem das Prinzip der minimalen Rechte (PoLP) unterstützt wird.

GitOps-Agents stimmen den Systemzustand kontinuierlich mit dem gewünschten Zustand ab, der in Ihrem Coderepository gespeichert ist. Einige GitOps-Agents können Vorgänge zurücksetzen, die außerhalb des Clusters ausgeführt werden, z. B. die manuelle Erstellung von Kubernetes-Objekten. Beispielsweise erzwingen Admission Controller Richtlinien für Objekte bei Erstellungs-, Aktualisierungs- und Löschvorgängen. Sie können damit sicherstellen, dass sich Bereitstellungen nur ändern, wenn sich der Bereitstellungscode im Quellrepository ändert.

Sie können Tools zur Verwaltung und Erzwingung von Richtlinien mit GitOps kombinieren, um Richtlinien zu erzwingen und Feedback zu vorgeschlagenen Richtlinienänderungen zu geben. Sie können Benachrichtigungen für einzelne Teams konfigurieren, um sie über den aktuellen GitOps-Status zu informieren. Sie können beispielsweise Benachrichtigungen über erfolgreiche Bereitstellungen und Abstimmungsfehler senden.

GitOps als einzelne Wahrheitsinstanz

GitOps bietet Konsistenz und Standardisierung des Clusterzustands und kann zur Verbesserung der Sicherheit beitragen. Sie können gitOps auch verwenden, um einen konsistenten Zustand für mehrere Cluster sicherzustellen. GitOps kann z. B. die gleiche Konfiguration für primäre und Notfallwiederherstellungs-Cluster (DR-Cluster) oder über eine Farm von Clustern anwenden.

Um GitOps als einzige Methode zum Ändern des Clusterzustands zu erzwingen, beschränken Sie den direkten Zugriff auf den Cluster. Um diese Konfiguration festzulegen, verwenden Sie die rollenbasierte Zugriffskontrolle (Azure RBAC), Admissionscontroller oder andere Tools.

Verwenden von GitOps zum Bootstrap der Erstkonfiguration

Manchmal ist eine AKS-Clusterbereitstellung als Teil der Basiskonfiguration erforderlich. Beispielsweise müssen Sie vor der Bereitstellung von Anwendungsworkloads möglicherweise gemeinsame Dienste oder Konfigurationen auf Systemebene bereitstellen. Diese gemeinsamen Dienste können die folgenden Add-Ons und Tools konfigurieren:

Sie können Flux als Erweiterung aktivieren, die beim Erstellen eines AKS-Clusters angewendet wird. Flux kann dann den Bootstrap für die Baselinekonfiguration im Cluster ausführen. Die Basisarchitektur für einen AKS-Cluster empfiehlt, GitOps für bootstrapping zu verwenden. Wenn Sie die Flux-Erweiterung verwenden, sind die Cluster kurz nach der Bereitstellung bereit zum Bootstrapping.

Andere GitOps-Tools und Add-Ons

Sie können die beschriebenen Szenarien auf andere GitOps-Tools erweitern. Jenkins X ist ein weiteres GitOps-Tool, das Anweisungen zur Integration in Azure bereitstellt. Sie können Tools für die progressive Bereitstellung wie Flagger für die schrittweise Verschiebung von Produktionsworkloads verwenden, die über GitOps bereitgestellt werden.

Mögliche Anwendungsfälle

Diese Lösung kommt Organisationen zugute, die Anwendungen und IaC bereitstellen und einen Prüfpfad für jede Änderung verwalten möchten.

GitOps vereinfacht die Containerverwaltung für Entwickler, wodurch die Produktivität verbessert wird. Entwickler können weiterhin mit vertrauten Tools wie Git arbeiten, um Updates und neue Features zu verwalten.

Überlegungen

Diese Überlegungen bilden die Säulen des Azure Well-Architected Framework, einer Reihe von Leitprinzipien, die Sie zur Verbesserung der Qualität eines Workloads verwenden können. Weitere Informationen finden Sie unter Well-Architected Framework.

Zuverlässigkeit

Zuverlässigkeit trägt dazu bei, dass Ihre Anwendung die Verpflichtungen erfüllen kann, die Sie für Ihre Kunden vornehmen. Weitere Informationen finden Sie unter Erstellen einer Checkliste zur Überprüfung der Zuverlässigkeit.

Wenn ein Cluster nicht verfügbar ist, sollte GitOps als Teil der Erstellung eines neuen Clusters verwendet werden. Das Git-Repository wird als einzelne Wahrheitsinstanz für die Kubernetes-Konfiguration und Anwendungslogik verwendet. Sie kann die Clusterkonfiguration und Anwendungsbereitstellung als Skalierungseinheit erstellen und anwenden und das Bereitstellungsstempel-Muster einrichten.

Sicherheit

Sicherheit bietet Sicherheitsmaßnahmen gegen bewusste Angriffe und den Missbrauch Ihrer wertvollen Daten und Systeme. Weitere Informationen finden Sie unter Erstellen einer Checkliste zur Überprüfung der Sicherheit.

Mit dem GitOps-Ansatz greifen einzelne Entwickler oder Administratoren nicht direkt auf die Kubernetes-Cluster zu, um Änderungen oder Updates anzuwenden. Stattdessen pusht der Benutzer Änderungen an ein Git-Repository und den GitOps-Operator, z. B. Flux oder Argo CD, liest die Änderungen und wendet sie auf den Cluster an. Dieser Ansatz folgt der bewährten Sicherheitsmethode der geringsten Berechtigungen, indem DevOps-Teams keine Schreibberechtigungen für die Kubernetes-API erteilt werden. In Diagnose- oder Problembehandlungsszenarien können Sie Clusterberechtigungen für einen begrenzten Zeitraum von Fall zu Fall gewähren.

Zusätzlich zum Konfigurieren von Repositoryberechtigungen sollten Sie die folgenden Sicherheitsmaßnahmen in Git-Repositorys implementieren, die mit AKS-Clustern synchronisiert werden:

  • Branch-Schutz: Schützen Sie die Branches, die den Zustand der Kubernetes-Cluster darstellen, davor, dass Änderungen direkt an sie gepusht werden. Verwenden Sie Pull-Requests (PRs), um Änderungen vorzunehmen und lassen Sie mindestens eine andere Person jede PR überprüfen. Verwenden Sie auch PRs, um automatische Prüfungen durchzuführen.

  • PR Review: Fordern Sie, dass PRs mindestens einen Prüfer haben, um das Vier-Augen-Prinzip durchzusetzen. Sie können auch das Feature GitHub Codebesitzer verwenden, um Einzelpersonen oder Teams zu definieren, die für die Überprüfung bestimmter Dateien in einem Repository verantwortlich sind.

  • Unveränderlicher Verlauf: Lassen Sie neue Commits nur über vorhandene Änderungen hinaus zu. Unveränderlicher Verlauf ist für Überwachungszwecke besonders wichtig.

  • Weitere Sicherheitsmaßnahmen: Fordern Sie ihre GitHub-Benutzer*innen auf, die zweistufige Authentifizierung zu aktivieren. Nur Commits zulassen, die signiert sind, um Änderungen zu verhindern.

Kostenoptimierung

Die Kostenoptimierung konzentriert sich auf Möglichkeiten, unnötige Ausgaben zu reduzieren und die betriebliche Effizienz zu verbessern. Weitere Informationen finden Sie unter Erstellen einer Checkliste zur Überprüfung der Kostenoptimierung.

  • Die kostenlose AKS-Stufe bietet kostenlose Clusterverwaltung. Die Kosten sind auf die Compute-, Speicher- und Netzwerkressourcen beschränkt, die AKS zum Hosten von Knoten verwendet. Die kostenlose AKS-Stufe enthält keine Vereinbarung zum Servicelevel (Service Level Agreement, SLA) und wird für Produktionsworkloads nicht empfohlen.

  • GitHub bietet einen kostenlosen Dienst, aber um erweiterte sicherheitsbezogene Features wie Codebesitzer oder erforderliche Prüfer zu verwenden, benötigen Sie den Teamplan. Weitere Informationen finden Sie unter GitHub-Preise.

  • Azure DevOps bietet eine kostenlose Stufe, die Sie für einige Szenarien verwenden können.

  • Verwenden Sie den Azure-Preisrechner, um die voraussichtlichen Kosten zu ermitteln.

Operative Exzellenz

„Optimaler Betrieb“ deckt die Betriebsprozesse ab, die für die Bereitstellung einer Anwendung und deren Ausführung in der Produktion sorgen. Weitere Informationen finden Sie unter Checkliste für die Designüberprüfung zur betrieblichen Exzellenz.

GitOps kann die Produktivität von DevOps steigern. Eines der nützlichsten Features ist die Möglichkeit, änderungen schnell rückgängig zu machen, die sich unerwartet verhalten, indem Git-Vorgänge ausgeführt werden. Das Commitdiagramm enthält weiterhin alle Commits, sodass es bei der retrospektiven Analyse helfen kann.

GitOps-Teams verwalten häufig mehrere Umgebungen für dieselbe Anwendung. Es ist üblich, über mehrere Phasen einer Anwendung zu verfügen, die in verschiedenen Kubernetes-Clustern oder -Namespaces bereitgestellt werden. Das Git-Repository, das die einzige Quelle der Wahrheit ist, zeigt, welche Versionen von Anwendungen derzeit in einem Cluster bereitgestellt werden.

Bereitstellen eines Szenarios

Weitere Informationen zur Bereitstellung der fünf Szenarien finden Sie in den folgenden Ressourcen:

Beitragende

Microsoft verwaltet diesen Artikel. Die folgenden Mitwirkenden haben diesen Artikel geschrieben.

Hauptautor:

Um nicht-öffentliche LinkedIn-Profile anzuzeigen, melden Sie sich bei LinkedIn an.

Nächste Schritte