CI/CD- und GitOps-Fachrichtungen mit Kubernetes mit Azure Arc-Unterstützung

  • Artikel

Als cloudnatives Konstrukt erfordert Kubernetes einen cloudnativen Ansatz für die Bereitstellung und den Betrieb. Bei der Verwendung von GitOps deklarieren Sie den gewünschten Zustand Ihrer anwendungsbasierten Bereitstellungen in Dateien, die in Git-Repositorys gespeichert werden. Anwendungen verfügen über Kubernetes-Objekte, die sie ausführen müssen. Dazu können Bereitstellungen, horizontale automatische Podskalierungen (Horizontal Pod Autoscaler, HPA), Dienste und ConfigMaps zählen. Kubernetes-Operatoren werden in den Clustern ausgeführt und stimmen den Zustand jedes Clusters kontinuierlich mit dem gewünschten Zustand ab, der in Ihrem Git-Repository deklariert ist. Diese Operatoren pullen Dateien aus den Git-Repositorys und wenden den gewünschten Zustand auf Ihre Cluster an. Außerdem stellen die Operatoren kontinuierlich sicher, dass sich Ihr Cluster im gewünschten Zustand befindet.

Die Implementierung von GitOps ermöglicht Ihnen Folgendes:

  • Verbessern der allgemeinen Sichtbarkeit des Zustands und der Konfiguration Ihres Kubernetes-Clusters.
  • Verfügbarkeit eines einfachen Überwachungsverlaufs und einer einfachen Versionsgeschichte der Änderungen an Ihrem Cluster über den Git-Änderungsverlauf, der zeigt, von wem, wann und aus welchem Grund die Änderungen vorgenommen wurden.
  • Automatische Korrektur der Datendrift, die in Ihrem Cluster auftreten kann.
  • Ausführen eines Rollbacks Ihrer Kubernetes-Konfiguration auf eine frühere Version mit den Befehlen „Git revert“ oder „Git rollback“. Zudem ist die erneute Erstellung der Clusterbereitstellung für Notfallwiederherstellungsszenarien schnell und einfach möglich, da Ihre gewünschte Kubernetes-Clusterkonfiguration in Git gespeichert ist.
  • Verbessern der Sicherheit durch Reduzieren der Anzahl von Dienstkonten, die über Bereitstellungsberechtigungen für Ihren Cluster verfügen müssen.
  • Implementieren einer CI/CD-Pipeline (Continuous Integration und Continuous Delivery) für die Bereitstellung von Anwendungen in Ihrem Cluster.

GitOps in Kubernetes mit Azure Arc-Unterstützung verwendet eine Erweiterung, die Flux implementiert, ein gängiges Open-Source-Toolset. Flux ist ein Operator, der GitOps-Konfigurationsbereitstellungen in Ihrem Cluster automatisiert. Das Tool bietet Unterstützung für gängige Dateiquellen (Git-Repositorys, Helm-Repositorys, Buckets) und Vorlagentypen (YAML, Helm und Kustomize). Flux unterstützt unter anderem auch Mehrinstanzenfähigkeit und die Verwaltung von Bereitstellungsabhängigkeiten.

Aufbau

Die folgenden Diagramme zeigen eine konzeptionelle Referenzarchitektur, in der die Installation bzw. Bereitstellung der Flux-Clustererweiterung in einem Cluster, der GitOps-Konfigurationsprozess für einen Kubernetes-Cluster mit Azure Arc-Unterstützung und der GitOps-Flow hervorgehoben sind.

Bereitstellungsprozess für die Flux v2-Clustererweiterung:

Diagram that shows Flux extension installation.

GitOps-Konfigurationsprozess:

Diagram that shows how to configure GitOps.

GitOps-Flow mit einem Anwendungsupdate:

Diagram that shows a typical GitOps workflow.

Überlegungen zum Entwurf

Prüfen Sie beim Planen der Implementierung von GitOps für Kubernetes mit Azure Arc-Unterstützung die folgenden Überlegungen zum Entwurf.

Konfiguration

Berücksichtigen Sie die verschiedenen Konfigurationsebenen in Ihrem Kubernetes-Cluster und die Zuständigkeiten im Zusammenhang mit ihrer Bereitstellung.

Konfigurationsebenen

  • Anwendungskonfiguration, die zum Bereitstellen einer Anwendung und der zugehörigen Kubernetes-Objekte im Cluster erforderlich ist, z. B. Bereitstellungs-, Dienst-, HPA- und ConfigMap-Ressourcen. Anwendungskonfigurationen werden in der Regel auf eine GitOps-Konfiguration auf Namespaceebene angewendet, sodass die Anwendungskomponenten nur in einem einzigen Namespace konfiguriert werden müssen.
  • Clusterweite Konfiguration für die Erstellung von Kubernetes-Objekten wie Namespaces, Dienstkonten (ServiceAccounts), Rollen und Rollenbindungen (RoleBindings) sowie anderen clusterweiten Richtlinien.
  • Clusterweite Komponenten, z. B. ein Eingangsdatencontroller, Überwachungs- und Sicherheitsstapel sowie verschiedene Agents, die im gesamten Cluster arbeiten.

Aufgaben

  • Anwendungsentwickler sind dafür verantwortlich, ihren Quellcode zu pushen, Builds auszulösen und Containerimages zu erstellen.
  • Anwendungsoperatoren sind für die Verwaltung der Anwendungsrepositorys, Konfigurationen, Umgebungsvariablen, App-spezifischen Helm-Charts, Kustomizations usw. verantwortlich.
  • Clusteroperatoren sind für die Einrichtung Ihrer Clusterbaseline verantwortlich. In der Regel richten sie clusterweite Komponenten und Richtlinien ein. Sie verwalten ein oder mehrere Git-Repositoryverzeichnisse, die allgemeine Infrastrukturtools enthalten, z. B. Namespaces, Dienstkonten, Rollenbindungen, benutzerdefinierten Ressourcendefinitionen (Custom Resource Definition, CRD), clusterweite Richtlinien, Eingangskomponenten usw.

Repository-Struktur

Erwägen Sie bei der Auswahl einer Git-Repositorystruktur Kompromisse. Die von Ihnen ausgewählte Struktur definiert den Zustand Ihres Kubernetes-Clusters, d. h. auch von Anwendungen und clusterweiten Komponenten. Je nachdem, welche Zuständigkeiten und Personas Sie ermitteln, ist es wichtig, die erforderliche Zusammenarbeit oder gewünschte Unabhängigkeit von Teams zu berücksichtigen, die für verschiedene Optionen für die Repositorystruktur notwendig sind.

Sie können für Ihre Coderepositorys eine beliebige Verzweigungsstrategie verwenden, da diese nur Ihren CI-Prozess (Continuous Integration) betrifft.

Erwägen Sie für Ihre GitOps-Konfigurationsrepositorys je nach geschäftlichen Anforderungen, Größe und Tools Ihrer Organisation die folgenden Strategien:

  • Einzelnes Repository (Verzweigung pro Umgebung):
    • Diese Strategie ermöglicht die größtmögliche Flexibilität beim Steuern der Git-Richtlinien und -Berechtigungen für jede Verzweigung, die eine Umgebung darstellt.
    • Der Nachteil besteht darin, dass gemeinsame Konfigurationen nicht zwischen Umgebungen geteilt werden, da Tools wie Kustomize nicht mit Git-Verzweigungen funktionieren.
  • Einzelnes Repository (Verzeichnis pro Umgebung):
    • Sie können diesen Ansatz mithilfe von Tools wie Kustomize implementieren. Er ermöglicht es Ihnen, eine Basiskonfiguration für Kubernetes-Objekte und eine Gruppe von Artefakten (d. h. Patches) für Ihre Umgebung zu definieren, die Konfigurationen in der Basis außer Kraft setzt.
    • Dieser Ansatz kann doppelte YAML-Dateien für die einzelnen Umgebungen reduzieren, schränkt aber auch die Konfigurationstrennung zwischen Umgebungen ein. Eine einzige Änderung am Repository kann sich auf alle Umgebungen gleichzeitig auswirken. Die Auswirkung von Änderungen an Basisverzeichnissen muss daher vollständig klar sein und besonders berücksichtigt werden.
  • Mehrere Repositorys (jeweils für einen bestimmten Zweck):
    • Diese Strategie kann verwendet werden, um Konfigurationsrepositorys für die einzelnen Anwendungen, Teams, Ebenen oder Mandanten zu trennen.
    • Bei diesem Ansatz haben Teams mehr Möglichkeiten zur unabhängigen Steuerung. Sie rücken damit jedoch von dem Prinzip ab, den Systemzustand zum Verbessern der zentralen Konfiguration, Sichtbarkeit und Steuerung von Bereitstellungen in einem Cluster in einem einzigen Repository zu definieren.
    • Das Einrichten mehrerer Repositorys sollte in Erwägung gezogen werden, wenn Mehrinstanzenfähigkeit erforderlich ist. Mithilfe der rollenbasierten Zugriffssteuerung (Role-Based Access Control, RBAC) und integrierten Sicherheitsfunktionen können die Konfigurationen beschränkt werden, die von Teams/Mandanten, die einem bestimmten Repository zugewiesen sind, angewendet werden können. Beispielsweise kann die Bereitstellung auf bestimmte Namespaces begrenzt werden.

Weitere Möglichkeiten zur Strukturierung Ihres Repositorys finden Sie im Flux-Leitfaden.

Anwendungs- und Plattformkonfiguration

Plattformoperatoren und Anwendungsoperatoren stehen mehrere Optionen für die Verwaltung der Kubernetes-Konfiguration zur Verfügung:

  • Unformatierte Kubernetes-YAML-Dateien, die YAML-Spezifikationen für jedes von Ihnen bereitgestellte Kubernetes-API-Objekt darstellen, können für einzelne Umgebungen gut funktionieren. Der Nachteil bei der Verwendung von unformatierten YAML-Dateien besteht darin, dass Anpassungen schwierig werden, sobald Sie mehrere Umgebungen integrieren, da Sie dann YAML-Dateien duplizieren müssen und es keine gute Methode für die Wiederverwendung gibt.
  • Helm ist ein Paketverwaltungstool für Kubernetes-Objekte. Clusteroperatoren können diese Option verwenden, um Standardanwendungen von Drittanbietern zu installieren. Achten Sie darauf, dass Sie sich bei der Konfigurationsverwaltung für interne Anwendungen nicht zu sehr auf die Vorlagenerstellung stützen. Bei zunehmender Anzahl und Größe der Vorlagen kann die Verwaltung komplex werden.
    • Bei der Verwendung von Helm enthält Flux einen Helm-Controller, mit dem Sie Helm-Chartversionen deklarativ mit Kubernetes-Manifesten verwalten können. Sie können ein HelmRelease-Objekt erstellen, um diesen Prozess zu verwalten.
  • Kustomize ist ein natives Konfigurationsverwaltungstool von Kubernetes, mit dem die Anwendungskonfiguration ohne Verwendung von Vorlagen angepasst werden kann.
    • Wenn Sie Kustomize verwenden, enthält Flux einen spezialisierten Kustomize-Controller für die Ausführung von Continuous Delivery-Pipelines für Infrastruktur und Workloads, die mit Kubernetes-Manifesten definiert und mit Kustomize zusammengestellt wurden. Sie können ein Kustomization-Objekt erstellen, um diesen Prozess zu verwalten.
  • Bei der Verwendung von Kubernetes mit Azure Arc-Unterstützung müssen Sie den Lebenszyklus und die Unterstützung von Komponenten nicht selbst verwalten, sondern können stattdessen eine Liste verfügbarer Erweiterungen verwenden, die von Microsoft verwaltet und unterstützt werden. Diese Erweiterungen werden über Azure Resource Manager verwaltet. Für einige dieser Erweiterungen (z. B. Azure Key Vault-Geheimnisanbieter) sind Open-Source-Alternativen verfügbar. Die Verwaltung von Komponenten außerhalb des Erweiterungsprozesses bietet Ihnen mehr Kontrolle über die Komponenten, erfordert aber auch mehr Aufwand für die Unterstützungs- und Lebenszyklusverwaltung.

Continuous Integration und Continuous Delivery (CI/CD)

In den folgenden Abschnitten finden Sie Überlegungen zum Aktualisierungsprozess für Ihre Anwendungspipeline und Komponenten.

Anwendungspipeline

  • Berücksichtigen Sie die Anwendungsbuilds, -tests und -validierungen, die Sie in Ihren CI-Prozess einbeziehen müssen. Dazu können das zum Erstellen eines Release Candidates (RC) für Umgebungsbereitstellungen erforderliche Linten und Testen im Zusammenhang mit der Sicherheit, Integration und Leistung zählen.
  • Sie können eine herkömmliche Push-Bereitstellungsmethode verwenden, um die Lücke zwischen einem Buildcontainerimage in Ihrer CI-Pipeline und dessen Bereitstellung in einem Cluster zu schließen, indem Sie die Kubernetes-API direkt in der Bereitstellungspipeline aufrufen.

Sie können manuelle Konfigurationsänderungen an Ihrem GitOps-Repository vermeiden, indem Sie Ihre CD-Pipeline als Dienstkonto ausführen, das über die Berechtigung zum Öffnen von Pull Requests (PRs) verfügt, oder eine neue Änderung des Containerimages direkt in einem Konfigurationsrepository committen. Durch diese Änderungen können auch alle YAML-Objekte bereitgestellt werden, die für Ihre Anwendung erforderlich sind.

Das folgende Prozessdiagramm veranschaulicht den herkömmlichen CI-Prozess für Anwendungen mit Änderungen, die GitOps unterstützen.

Diagram that shows the standard GitOps process.

Aktualisierungsprozess für clusterweite Komponenten

  • Clusteroperatoren müssen clusterweite Komponenten verwalten. Dieser Prozess geht daher wahrscheinlich nicht von der CD-Pipeline aus, die zum Bereitstellen Ihrer Anwendungen und Dienste verwendet wird. Erwägen Sie, einen spezifischen Höherstufungsprozess für Clusteroperatoren zu definieren, um einen problemlosen Übergang von Änderungen zwischen Umgebungen sicherzustellen.
  • Wenn Sie eine identische GitOps-Konfiguration im großen Stil auf Ihre Kubernetes-Cluster mit Azure Arc-Unterstützung anwenden müssen, sollten Sie ggf. eine Azure Policy-Richtlinie anwenden, die die Flux-Erweiterung automatisch installieren und die GitOps-Konfiguration auf vorhandene Kubernetes-Cluster mit Azure Arc-Unterstützung oder beim Onboarding in Azure Arc auf neue Cluster anwenden kann.

Beim Aktualisieren Ihrer Konfiguration möchten Sie wahrscheinlich überprüfen, ob Änderungen erfolgreich auf die gewünschte Umgebung angewendet wurden. Sie können Benachrichtigungen in Flux definieren, die in Ihre CI/CD-Tools, E-Mail oder ChatOps-Tools integriert werden und automatisch Benachrichtigungen über erfolgreiche Änderungen und Bereitstellungsfehler senden. Informationen zum Bereitstellungsstatus können Sie auch im Azure-Portal einsehen und über die „k8s-configuration“-Befehlszeilenschnittstelle sowie die ARM-API abrufen.

Sicherheitshinweise

Prüfen Sie beim Planen der Implementierung von GitOps für Kubernetes mit Azure Arc-Unterstützung die folgenden Überlegungen zur Sicherheit.

Repositoryauthentifizierung

  • Sie können ein öffentliches oder privates Git-Repository mit GitOps verwenden. Aufgrund der Sensibilität von Kubernetes-Konfigurationen empfehlen wir jedoch, ein privates Repository zu verwenden, das eine Authentifizierung mit einem SSH-Schlüssel oder API-Schlüssel erfordert. GitOps funktioniert auch mit Git-Repositorys, die nur innerhalb eines privaten Netzwerks zugänglich sind, solange Ihr Kubernetes-Cluster auf sie zugreifen kann. Dieses Setup schränkt jedoch Ihre Möglichkeit ein, cloudbasierte Git-Anbieter wie Azure Repos oder GitHub zu verwenden.
  • Sowohl HTTPS- als auch SSH-Protokolle bieten eine zuverlässige und sichere Verbindung, die Sie zum Herstellen einer Verbindung mit Ihrem Quellcodeverwaltungstool verwenden können. HTTPS ist jedoch häufig einfacher einzurichten und verwendet einen Port, bei dem es selten erforderlich ist, weitere Ports in Ihren Firewalls öffnen.

Repository- und Verzweigungssicherheit

  • Legen Sie Verzweigungsberechtigungen und -richtlinien für Ihr Konfigurationsrepository fest. Das Git-Repository wird zum Kernstück Ihrer Kubernetes-Bereitstellungen. Daher ist es entscheidend, dass Sie Berechtigungen einrichten, um zu steuern, wer den Code in einer Verzweigung lesen und aktualisieren kann, und dass Sie Richtlinien zum Erzwingen von Codequalität und Change Management für Ihr Team implementieren. Andernfalls kann Ihr GitOps-Workflow Code senden, der nicht den Standards Ihrer Organisation entspricht.
  • Bei Bedarf können Sie Pull Request-Pipelines in Verbindung mit Ihren Verzweigungsrichtlinien verwenden, um YAML-Konfigurationen zu überprüfen und/oder Testumgebungen bereitzustellen. Gates tragen dazu bei, Konfigurationsfehler zu beseitigen und die Sicherheit und Zuverlässigkeit der Bereitstellung zu erhöhen.
  • Berücksichtigen Sie beim Zuweisen von Zugriffsberechtigungen, welche Benutzer in Ihrer Organisation über Lesezugriff auf das Repository, PR-Erstellungszugriff und PR-Genehmigungszugriff verfügen sollten.

Verwaltung von Geheimnissen

  • Vermeiden Sie es, Nur-Text- oder Base64-codierte Geheimnisse in Ihrem Git-Repository zu speichern. Erwägen Sie stattdessen die Verwendung eines externen Geheimnisanbieters wie Azure Key Vault. Mit dem Azure Key Vault-Anbieter für den Secrets Store CSI-Treiber können Sie mithilfe eines CSI-Volumes einen Azure-Schlüsseltresor als Geheimnisspeicher in einen Azure Kubernetes Service (AKS)-Cluster integrieren. Dieser Dienst ist über die Kubernetes-Erweiterung mit Azure Arc-Unterstützung verfügbar. HashiCorp Vault ist ein verwalteter Geheimnisanbieter eines Drittanbieters, den Sie alternativ verwenden können.
  • Eine weitere Alternative zum Verwalten von Geheimnissen ist die Verwendung von Bitnami Sealed Secrets, eine Lösung, die auf dem Konzept öffentlicher und privater Schlüssel beruht. Operatoren können ein unidirektionales verschlüsseltes Geheimnis mithilfe eines öffentlichen Schlüssels in Git speichern, das nur über den privaten Schlüssel entschlüsselt werden kann, der von einem SealedSecrets-Controller in Ihrem Cluster verwendet wird.

Entwurfsempfehlungen

Prüfen Sie beim Planen der Implementierung von GitOps für Kubernetes mit Azure Arc-Unterstützung die folgenden Empfehlungen zum Entwurf.

Das folgende Diagramm zeigt eine Referenzarchitektur, die die Zuständigkeiten, Repositorys und Pipelines veranschaulicht, die zum Implementieren eines GitOps-Prozesses mit der Kubernetes-Flux-Erweiterung mit Azure Arc-Unterstützung erforderlich sind.

Diagram that shows a GitOps Reference flow.

Repositorys

Der Entwurf umfass drei Git-Repositorys:

  • Repository für Anwendungscode
    • In diesem Repository werden Anwendungscode und alle Skripts für die Pipelinedefinition und -konfiguration gespeichert.
    • Verwenden Sie eine Verzweigungsstrategie, die einfach zu verstehen ist und die Anzahl unerwünschter zeitintensiver Verzweigungen beschränkt.
  • Repository für die Anwendungskonfiguration
    • In diesem Repository werden Anwendungskonfigurationen gespeichert, einschließlich Kubernetes-Objekte wie ConfigMaps, Bereitstellungen, Dienste und HPA-Objekte. Strukturieren Sie dieses Repository mit unterschiedlichen Verzeichnissen für jede Anwendung. Flux synchronisiert Änderungen aus diesem Repository und der Zielverzweigung mit Ihrem Cluster.
    • Integrieren Sie Tools, die es Anwendungsentwicklern und -operatoren erleichtern, die anfänglichen Konfigurationen pro Umgebung zu erstellen. Anwendungsoperatoren sollten eine spezielle Kubernetes-Anwendungskonfiguration definieren, die Paket-Manager wie Helm oder Konfigurationstools wie Kustomize verwendet, um die Konfiguration zu vereinfachen.
    • Erstellen Sie eine Verzweigung für jeden Umgebungstyp. Dies ermöglicht eine differenzierte Steuerung von Änderungen in jeder einzelnen Umgebung, z. B. Nicht-Produktionsumgebungen und Produktionsumgebungen.
    • Wenn eine Anwendung in einem bestimmten Namespace bereitgestellt wird, verwenden Sie das Feature für den Namespacebereich in der GitOps-Konfiguration, um die Konfiguration nur für einen bestimmten Namespace zu erzwingen.
  • Repository für die clusterweite Konfiguration
    • Definieren Sie clusterweite Komponenten wie Eingangsdatencontroller, Namespaces, rollenbasierte Zugriffssteuerung, Überwachungs- und Sicherheitsstapel für die Clusteroperatorverwaltung. Flux synchronisiert Änderungen aus diesem Repository und der Zielverzweigung mit Ihrem Cluster.
    • Strukturieren Sie dieses Repository mit verschiedenen Verzeichnissen, die unterschiedliche Komponenten darstellen.
    • Erstellen Sie eine Verzweigung für jeden Umgebungstyp. Dies ermöglicht eine differenzierte Steuerung von Änderungen in jeder einzelnen Umgebung, z. B. Nicht-Produktionsumgebungen und Produktionsumgebungen.
    • Clusteroperatoren sollten Paket-Manager wie Helm oder Konfigurationstools wie Kustomize-Überlagerungen verwenden, um die Konfiguration zu vereinfachen.

Aktualisierungsprozess für CI/CD und Konfigurationen

CI/CD- und Containerimageaktualisierungen

  • CI-Pipeline
    • Entwicklerteams sollten einen CI-Pipelineprozess definieren, der das Erstellen, Linten, Testen und Pushen einer Anwendung an Ihre Containerregistrierung umfasst.
  • CD-Pipeline
    • Erstellen Sie eine CD-Pipeline, die ein Skript für Änderungen an Ihrem Anwendungskonfigurationsrepository ausführt. Dieses Skript erstellt anhand Ihrer Zielumgebung eine temporäre Verzweigung, nimmt eine Änderung an der Imagetagversion vor, committet die Änderung und öffnet einen Pull Request für Ihre Zielumgebungsverzweigung. Diese CD-Pipeline kann über Umgebungsphasen mit entsprechenden Umgebungsvariablen verfügen, um das richtige GitOps-Konfigurationsrepository und die richtige Verzweigung als Ziel festzulegen.
    • Definieren Sie manuelle Genehmigungsschritte für Umgebungsphasen, um unerwünschte Pull Requests an alle Umgebungen zu beschränken.
  • Aktivieren Sie Verzweigungsrichtlinien für Ihr Anwendungskonfigurationsrepository, um Peer Reviews oder Genehmigungen für Umgebungen zu erzwingen. Diese Richtlinien können eine Mindestanzahl erforderlicher Überprüfungen oder eine automatische Genehmigung für niedrigere Umgebungen umfassen. Erwägen Sie ggf. auch Drittanbieterintegrationen und Genehmigungen von Dritten, um die Standards Ihrer Organisation zu erfüllen.

Clusterweite Aktualisierungen und Anwendungskonfigurationsaktualisierungen

  • Clusteroperatoren und Anwendungsoperatoren definieren jede Konfiguration in ihren jeweiligen Konfigurationsrepositorys. Diese Benutzer benötigen keine Pipelinetools zum Pushen von Konfigurationen. Stattdessen verwenden sie native Git-Commit- und PR-Prozesse, um eine Konfiguration zu definieren und Änderungen an eine Verzweigung zu pushen, die eine Umgebung darstellt.
  • Beginnen Sie bei neuen Konfigurationsdefinitionen mit dem Definieren der Konfiguration in niedrigeren Umgebungen (z. B. Entwicklung), und stufen Sie dann durch Zusammenführungen und Pull Requests auf höhere Umgebungen hoch. Führen Sie bei Bedarf Cherry-Pick-Konfigurationsaktualisierungen für bestimmte Umgebungen durch.

Feedback und Benachrichtigungen

  • Konfigurieren Sie Flux-Benachrichtigungen, damit Sie eine Warnung erhalten, wenn GitOps-Konfigurationen nicht synchronisiert werden konnten oder Fehler aufgetreten sind. Anwendungsoperatoren sollten Benachrichtigungen konfigurieren, damit sie informiert werden, wenn eine Anwendungsbereitstellung erfolgreich war und fehlerfrei ist. Clusteroperatoren sollten Benachrichtigungen konfigurieren, damit sie über Fehler bei der clusterweiten Abstimmung von Komponenten und Probleme bei der Synchronisierung mit dem Git-Repository informiert werden.
  • Implementieren Sie den GitOps-Connector, um Feedback vom Flux-Agent in Ihre CI/CD-Tools zu integrieren.

Sicherheitsempfehlungen

  • Prüfen Sie die Governance- und Sicherheitsempfehlungen für Ihre Kubernetes-Cluster mit Azure Arc-Unterstützung.
  • Vermeiden Sie unerwünschten Zugriff auf Clusterkonfigurationen, indem Sie ein privates Git-Repository mit Authentifizierung und Autorisierung nutzen, das Sie zum Definieren beliebiger Konfigurationsrepositorys verwenden können.
  • Greifen Sie über das SSH-Protokoll und einen SSH-Schlüssel auf Ihr Git-Repository zu, sofern Ihr Git-Anbieter dies unterstützt. Wenn SSH aufgrund von Einschränkungen bezüglich der ausgehenden Konnektivität nicht verfügbar ist oder Ihr Git-Anbieter die erforderlichen SSH-Bibliotheken nicht unterstützt, verwenden Sie ein dediziertes Dienstkonto, und ordnen Sie diesem einen API-Schlüssel für die Verwendung durch Flux zu. Falls Sie bei der Verwendung von GitHub eine Alternative zu SSH benötigen, können Sie für die Authentifizierung ein persönliches Zugriffstoken erstellen.
  • Konfigurieren Sie Verzweigungsrichtlinien und -berechtigungen, die den Zuständigkeiten für Ihren Cluster entsprechen. Legen Sie für die Genehmigung von Änderungen eine Mindestanzahl von Prüfern fest.
  • Konfigurieren Sie eine PR-Pipeline, um YAML-Konfigurationen und die Syntax zu überprüfen, und stellen Sie optional einen Kubernetes-Testcluster bereit. Richten Sie eine Verzweigungsrichtlinie ein, die die erfolgreiche Ausführung dieser Pipeline erfordert, bevor Zusammenführungen akzeptiert werden.
  • Implementieren Sie Geheimnisse mit dem Azure Key Vault-Anbieter für den Secrets Store CSI-Treiber, der Ihnen über ein CSI-Volume die Integration einer Azure Key Vault-Instanz als Geheimnisspeicher in einem Kubernetes-Cluster mit Azure Arc-Unterstützung ermöglicht.
  • Die Flux-Erweiterung unterstützt Konfigurationen im Namespace- und Clusterbereich. Wählen Sie den Namespacebereich aus, falls Ihre Konfiguration nicht über Zugriff verfügen soll, der über einen einzelnen Namespace hinausgeht.

Nächste Schritte

Weitere Informationen zu Ihrer Hybrid- und Multi-Cloud-Umgebung finden Sie in den folgenden Artikeln.