Bearbeiten

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: GitOps mit Flux v2, GitHub und AKS

Laden Sie eine Visio-Datei dieser Architektur herunter.

Datenfluss für Szenario 1

Flux ist eine native Clustererweiterung für AKS. Clustererweiterungen bieten eine Plattform zum Installieren und Verwalten von Lösungen in 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 Konsistentes Bereitstellen von Anwendungen im großen Stil mithilfe von Flux v2-Konfigurationen und Azure Policy.

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 Datenfluss für dieses Szenario lautet:

  1. Der Entwickler committet Konfigurationsänderungen in das GitHub-Repository.
  2. Flux erkennt Konfigurationsabweichungen im Git-Repository und pullt die Konfigurationsänderungen.
  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 zum Erstellen eines Artefakts für Objekte aus Speicherlösungen wie Amazon S3 und Google Cloud Storage-Buckets. Sie können auch eine Lösung mit einer S3-kompatiblen API verwenden. Zwei Beispiele sind Minio und Alibaba Cloud OSS, aber es gibt noch andere.
  • 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.

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

Diagramm: Implementierung von CI/CD unter Verwendung von GitOps mit Flux, GitHub und AKS

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. Die Daten durchlaufen das Szenario wie folgt:

  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 pusht das Containerimage an die Azure Container Registry-Instanz.
  4. GitHub Actions aktualisiert eine Kubernetes-Manifestbereitstellungsdatei mit der aktuellen Imageversion basierend auf der Versionsnummer des Containerimages in der Azure Container Registry.
  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: GitOps mit Argo CD, GitHub und AKS

Laden Sie eine Visio-Datei dieser Architektur herunter.

Datenfluss für Szenario 3

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 Datenfluss für dieses Szenario lautet:

  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. Es vergleicht den aktuellen Livestatus des AKS-Clusters mit dem gewünschten Zielzustand, der im Git-Repository angegeben ist. Argo CD meldet und visualisiert die Unterschiede und stellt gleichzeitig Funktionen bereit, um den Livezustand automatisch oder manuell wieder 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. Dazu können Sie auch die Argo CD-Befehlszeile verwenden. 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. Alternativ können Sie 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: Implementierung von CI/CD unter Verwendung von GitOps mit Argo CD, GitHub und AKS

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. Die Daten durchlaufen das Szenario wie folgt:

  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 pusht das Containerimage an die Azure Container Registry-Instanz.
  4. GitHub Actions aktualisiert eine Kubernetes-Manifestbereitstellungsdatei mit der aktuellen Imageversion basierend auf der Versionsnummer des Containerimages in der Azure Container Registry.
  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.
  • Es wendet Entwicklungsmethoden wie Versionskontrolle, Zusammenarbeit, Compliance und Continuous Integration/Continuous Deployment (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. In diesem Artikel werden einige allgemeine Optionen für die Verwendung von GitOps zusammen mit einem AKS-Cluster beschrieben.

Gemäß den GitOps-Prinzipien muss der gewünschte Zustand eines von GitOps verwalteten Systems wie folgt lauten:

  1. Deklarativ: Für ein Von GitOps verwaltetes System muss der gewünschte Zustand deklarativ ausgedrückt werden. Die Deklaration wird in der Regel in einem Git-Repository gespeichert.
  2. Versioniert und unveränderlich: Der gewünschte Zustand wird auf eine Weise gespeichert, die Unveränderlichkeit und Versionsverwaltung erzwingt und einen vollständigen Versionsverlauf beibehält.
  3. Automatisch gepullt: Software-Agents pullen automatisch die gewünschten Zustandsdeklarationen aus der Quelle.
  4. Kontinuierlich abgestimmt: Software-Agents beobachten kontinuierlich den tatsächlichen Systemzustand und versuchen, den gewünschten Zustand anzuwenden.

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

Kubernetes beschreibt alles vom Clusterzustand bis hin zu Anwendungsbereitstellungen deklarativ mit Manifesten. GitOps für Kubernetes platziert den gewünschten Zustand der Clusterinfrastruktur in der Versionskontrolle. Eine Komponente im Cluster, die normalerweise 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. Dies erhöht die Sicherheit, indem das Prinzip der geringsten Rechte 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. Zugangscontroller erzwingen beispielsweise Richtlinien für Objekte während 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 verschiedene Teams konfigurieren, um ihnen den aktuellen GitOps-Status bereitzustellen. Sie können beispielsweise Benachrichtigungen über erfolgreiche Bereitstellungen und Abstimmungsfehler senden.

GitOps als einzelne Wahrheitsinstanz

GitOps bietet Konsistenz und Standardisierung des Clusterstatus und kann zur Verbesserung der Sicherheit beitragen. Sie können gitOps auch verwenden, um einen konsistenten Zustand für mehrere Cluster sicherzustellen. GitOps kann beispielsweise dieselbe Konfiguration für primäre Cluster und Notfallwiederherstellungen (DR) oder für eine Farm von Clustern anwenden.

Wenn Sie erzwingen möchten, dass nur GitOps den Clusterstatus ändern kann, können Sie den direkten Zugriff auf den Cluster einschränken. Es gibt hierzu verschiedene Möglichkeiten, einschließlich der rollenbasierten Zugriffssteuerung (Role-Based Access Control, RBAC) in Azure, Zugangscontrollern und anderer Tools.

Verwenden von GitOps zum Bootstrap der Erstkonfiguration

Es ist möglich, dass AKS-Cluster als Teil der Baselinekonfiguration bereitgestellt werden müssen. Ein Beispiel ist, dass Sie eine Reihe von freigegebenen Diensten oder eine Konfiguration bereitstellen müssen, bevor Sie Workloads bereitstellen. Diese freigegebenen Dienste können AKS-Add-Ons konfigurieren, z. B.:

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 Baselinearchitektur für einen AKS-Cluster empfiehlt die Verwendung von GitOps für das Bootstrapping. Wenn Sie die Flux-Erweiterung verwenden, können Sie sehr bald nach der Bereitstellung einen Bootstrap für Cluster ausführen.

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 ist für alle Organisationen von Nutzen, die die Vorteile der Bereitstellung von Anwendungen und Infrastruktur als Code mit einem Überwachungspfad jeder Änderung nutzen möchten.

GitOps schützt den Entwickler vor der Komplexität der Verwaltung einer Containerumgebung. Entwickler können weiterhin mit vertrauten Tools wie Git arbeiten, um Updates und neue Features zu verwalten. Auf diese Weise steigert GitOps die Produktivität von Entwicklern.

Ü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 Microsoft Azure Well-Architected Framework.

Zuverlässigkeit

Zuverlässigkeit stellt sicher, dass Ihre Anwendung Ihre Verpflichtungen gegenüber den Kunden erfüllen kann. Weitere Informationen finden Sie in der Überblick über die Säule „Zuverlässigkeit“.

Eine der wichtigsten Säulen der Zuverlässigkeit ist Resilienz. Das Ziel der Resilienz besteht darin, nach einem Ausfall wieder die volle Funktionsfähigkeit einer Anwendung herzustellen. Wenn ein Cluster nicht mehr verfügbar ist, kann GitOps schnell einen neuen Cluster erstellen. Das Git-Repository wird als einzelne Wahrheitsinstanz für die Kubernetes-Konfiguration und Anwendungslogik verwendet. Es kann die Clusterkonfiguration und Anwendungsbereitstellung als Skalierungseinheit erstellen und anwenden und das Bereitstellungsstempelmuster festlegen.

Sicherheit

Sicherheit bietet Schutz vor vorsätzlichen Angriffen und dem Missbrauch Ihrer wertvollen Daten und Systeme. Weitere Informationen finden Sie unter Übersicht über die Säule „Sicherheit“.

Mit dem GitOps-Ansatz greifen einzelne Entwickler oder Administratoren nicht direkt auf die Kubernetes-Cluster zu, um Änderungen oder Updates anzuwenden. Stattdessen pushen Benutzer*innen Änderungen in ein Git-Repository, und der GitOps-Operator (Flux oder Argo CD) liest sie 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.

Neben der Einrichtung 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 PRs, um Änderungen vorzunehmen, und lassen Sie mindestens eine andere Person jeden PR überprüfen. Verwenden Sie PRs auch, um automatische Überprüfungen durchzuführen.
  • PR-Überprüfung: PRs müssen mindestens einen Prüfer haben, um das Vier-Augen-Prinzip umzusetzen. 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. Lassen Sie außerdem nur signierte Commits zu, um Änderungen zu verhindern.

Kostenoptimierung

Bei der Kostenoptimierung geht es um die Suche nach Möglichkeiten, unnötige Ausgaben zu reduzieren und die Betriebseffizienz zu verbessern. Weitere Informationen finden Sie unter Übersicht über die Säule „Kostenoptimierung“.

  • Im kostenlosen Tarif bietet AKS eine kostenlose Clusterverwaltung. Die Kosten sind auf die Compute-, Speicher- und Netzwerkressourcen beschränkt, die AKS zum Hosten von Knoten verwendet.
  • GitHub bietet einen kostenlosen Dienst, aber um erweiterte sicherheitsbezogene Funktionen wie Codebesitzer oder erforderliche Prüfer zu verwenden, benötigen Sie den Teamplan. Weitere Informationen finden Sie auf der Seite Preisübersicht für GitHub.
  • Azure DevOps bietet einen kostenlosen Tarif, den Sie für einige Szenarien verwenden können.
  • Verwenden Sie den Azure-Preisrechner, um die voraussichtlichen Kosten zu ermitteln.

Optimaler Betrieb

Die Säule „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 Übersicht über die Säule „Optimaler Betrieb“.

GitOps kann die Produktivität von DevOps steigern. Eines der nützlichsten Features ist die Möglichkeit, Änderungen, die sich unerwartet verhalten, schnell rückgängig zu machen, indem Sie nur Git-Vorgänge ausführen. Das Commit-Diagramm enthält weiterhin alle Commits, sodass es bei der Analyse zur Nachbereitung hilfreich sein 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

Die folgende Liste enthält Verweise für Informationen zur Bereitstellung der fünf Szenarien:

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautor:

Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.

Nächste Schritte