Sichere Rollouts mit Anthos Config Management

Dieses Dokument zeigt Clusteroperatoren und Plattformadministratoren, wie Sie mit Anthos Config Management Änderungen sicher in mehreren Umgebungen vornehmen können. Mit Anthos Config Management können Sie Fehler vermeiden, die sich gleichzeitig auf alle Ihre Umgebungen auswirken.

Mit Anthos Config Management können Sie einzelne Cluster, mehrmandantenfähige Cluster und Multi-Cluster-Kubernetes-Konfigurationen mithilfe von Dateien verwalten, die in einem Git-Repository gespeichert sind. Anthos Config Management kombiniert drei Technologien: Config Sync, Policy Controller und Config Connector. Config Sync überwacht Aktualisierungen aller Dateien im Git-Repository und wendet die Änderungen automatisch auf alle relevanten Cluster an. Policy Controller verwaltet und erzwingt Richtlinien für Objekte in Ihren Clustern. Config Connector verwendet zum Verwalten von Cloudressourcen benutzerdefinierte Ressourcen für Google Kubernetes Engine (GKE).

Config Sync-Konfigurationen können mehrere Dinge darstellen, darunter:

Anthos Config Management eignet sich besonders für die Bereitstellung von Konfigurationen, Richtlinien und Arbeitslasten, die zum Ausführen der Plattform erforderlich sind, die Sie auf Anthos aufbauen – z. B. Sicherheitsagenten, Überwachungsagenten und Zertifikatsmanager.

Obwohl Sie Anwendungen mit Anthos Config Management für Nutzer bereitstellen können, wird empfohlen, deren Releaselebenszyklus nicht mit dem zuvor veröffentlichten administrativen Arbeitslasten zu verknüpfen. Stattdessen empfehlen wir, ein Tool für die Anwendungsbereitstellung zu verwenden, z. B. ein Tool für die kontinuierliche Bereitstellung, damit Anwendungsteams ihren Releasezeitplans unter Kontrolle haben.

Anthos Config Management ist ein leistungsstarkes Produkt, das viele Elemente verwalten kann. Daher benötigen Sie Leitlinien, um Fehler zu vermeiden, die große Auswirkungen haben. In diesem Dokument werden mehrere Methoden zum Erstellen von Leitlinien beschrieben. Im ersten Abschnitt werden behandelte Rollouts vorgestellt, der zweite Abschnitt konzentriert sich auf Tests und Validierungen. Im dritten Abschnitt wird erläutert, wie Sie mit Policy Controller Leitlinien erstellen. Im vierten Abschnitt wird gezeigt, wie Sie Anthos Config Management-Bereitstellungen überwachen.

Sie können die meisten in diesem Dokument beschriebenen Methoden verwenden, auch wenn Sie nur Config Sync und nicht das vollständige Anthos Config Management-Produkt verwenden. Wenn Sie nicht das gesamte Anthos Config Management-Produkt verwenden, aber die Methoden in Bezug auf Policy Controller implementieren möchten, können Sie dies mit Gatekeeper tun. Ausnahmen von dieser Regel sind Methoden, die auf der Seite Anthos Config Management in der Google Cloud Console basieren, z. B. das Aktualisieren der Anthos Config Management-Konfiguration in der Google Cloud Console. Sie können auch mehrere der in diesem Dokument beschriebenen Methoden gleichzeitig verwenden. Im folgenden Abschnitt wird in einer Tabelle angegeben, welche Methoden für die gleichzeitige Verwendung kompatibel sind.

Gestaffelte Rollouts mit Anthos Config Management implementieren

In einer Multi-Cluster-Umgebung, die für Anthos-Nutzer üblich ist, empfehlen wir, eine Konfigurationsänderung nicht auf alle Cluster gleichzeitig anzuwenden. Ein gestaffelter Rollout, Cluster pro Cluster – oder sogar Namespace pro Namespace – ist, wenn Sie Namespaces als Grenze zwischen Anwendungen verwenden, viel sicherer, da dies die Absage von Fehlern reduziert.

Es gibt mehrere Möglichkeiten, gestaffelte Rollouts mit Anthos Config Management zu implementieren:

  • Verwenden Sie Git-Commits oder Tags, um die Änderungen, die Sie auf die Cluster anwenden möchten, manuell anzuwenden.
  • Verwenden Sie Git-Zweige, um die Änderungen automatisch anzuwenden, wenn die Änderungen zusammengeführt werden. Sie können für verschiedene Clustergruppen verschiedene Zweige verwenden.
  • Verwenden Sie die Objekte ClusterSelector und NamespaceSelector, um Änderungen selektiv auf Untergruppen von Clustern oder Namespaces anzuwenden.

Alle Methoden für gestaffelte Rollouts haben Vor- und Nachteile. Die folgende Tabelle zeigt, welche dieser Methoden Sie gleichzeitig verwenden können.

Sind X mit Y kompatibel? Git-Commits oder -Tags Git-Zweige Cluster selectors Namespace selectors
Git-Commits oder -Tags Nicht kompatibel Kompatibel Kompatibel
Git-Zweige Nicht kompatibel Kompatibel Kompatibel
Cluster selectors Kompatibel Kompatibel Kompatibel
Namespace selectors Kompatibel Kompatibel Kompatibel

Der folgende Entscheidungsbaum hilft Ihnen bei der Entscheidung, wann Sie eine der gestaffelten Rollout-Methoden verwenden sollten.

Entscheidungsbaum für Rollout-Methoden.

Git-Commits oder -Tags verwenden

Im Vergleich zu den anderen gestaffelten Rollout-Methoden bietet Git-Commits oder -Tags die größte Kontrolle und ist die sicherste. Über die Anthos Config Management-Konsole können Sie mehrere Cluster gleichzeitig aktualisieren. Verwenden Sie diese Methode, wenn Sie Änderungen einzeln auf Ihre Cluster anwenden möchten und genau steuern möchten, wann dies geschieht.

Bei dieser Methode „fixieren“ Sie jeden Cluster an eine bestimmte Version (entweder ein Commit oder ein Tag) Ihres Anthos Config Management-Repository. Diese Methode ähnelt der Verwendung des Git-Commits als Container-Image-Tag. Zum Implementieren dieser Methode geben Sie das Commit oder das Tag im Feld spec.git.syncRev der benutzerdefinierten Ressource ConfigManagement an. Wenn Sie Konfigurationen von mehreren Repositories synchronisieren, müssen Sie diese Methode aktualisieren, indem Sie die benutzerdefinierten Ressourcen RootSync und RepoSync aktualisieren. Weitere Informationen zu den Konfigurationsfeldern finden Sie unter Operator konfigurieren. Wenn Sie Ihre benutzerdefinierten ConfigManagement-Ressourcen mit einem Tool wie kustomize verwalten, können Sie die manuelle Umstellung auf Änderungen reduzieren. Mit einem solchen Tool müssen Sie den Parameter syncRev nur an einer Stelle ändern und dann die neue benutzerdefinierte ConfigManagement-Ressource in der von Ihnen ausgewählten Reihenfolge und Geschwindigkeit auf Ihre Cluster anwenden.

Wenn Sie Anthos Config Management (und nicht Config Sync) verwenden, können Sie auf die Anthos Config Management-Seite in der Google Cloud Console zugreifen. Auf dieser Seite können Sie den Parameter syncRev für mehrere Cluster gleichzeitig aktualisieren, die zur selben Flotte gehören. Wenn Sie die Anthos Config Management-Konfiguration über ein automatisiertes System aktualisieren, sollten Sie die Konfiguration nicht über die Konsole ändern.

Die folgende ConfigManagement-Definition konfiguriert beispielsweise Anthos Config Management für die Verwendung des Tags 1.2.3:

apiVersion: configmanagement.gke.io/v1
kind: ConfigManagement
metadata:
  name: config-management
spec:
  # clusterName is required and must be unique among all managed clusters
  clusterName: my-cluster
  git:
    syncRepo: git@example.com:anthos/config-management.git
    # Pin the cluster using a tag
    syncRev: 1.2.3
    secretType: ssh

Wenn Sie diese Konfiguration auf Ihren Cluster anwenden, verwendet Anthos Config Management das Tag 1.2.3 des Repositorys example.com:anthos/config-management.git.

Um einen Cluster zu aktualisieren, ändern Sie das Feld spec.git.syncRev in den neuen Wert für den Cluster. Auf diese Weise können Sie definieren, welche Cluster wann aktualisiert werden. Wenn Sie eine Änderung rückgängig machen möchten, ändern Sie das Feld spec.git.syncRev wieder in den vorherigen Wert.

Das folgende Diagramm veranschaulicht den Rollout-Prozess für diese Methode. Speichern Sie zuerst die Änderungen im Anthos Config Management-Repository. Anschließend aktualisieren Sie die ConfigManagement-Definitionen für alle Cluster:

Einführungsprozess für Git-Commits und -Tags

Wir empfehlen Folgendes:

  • Verwenden Sie Git-Commit-IDs anstelle von Tags. Durch die Art und Weise, wie Git funktioniert, gibt es eine Garantie, die sich niemals ändern wird. Ein git push --force kann beispielsweise das von Anthos Config Management verwendete Commit nicht ändern. Dieser Ansatz eignet sich für Prüfzwecke und um zu verfolgen, welches Commit Sie in Logs verwenden. Außerdem wird der Commit für IDs im Gegensatz zu Tags nicht ausgeführt.
  • Wenn Sie Git-Tags anstelle von Git-Commit-IDs verwenden und GitLab verwenden möchten, schützen Sie die Tags, damit sie nicht verschoben oder gelöscht werden. Die anderen Git-Lösungen haben diese Funktion nicht.
  • Wenn Sie mehrere Cluster gleichzeitig aktualisieren möchten, können Sie dies auf der Seite der Anthos Config Management-Konsole tun. Damit Sie mehrere Cluster gleichzeitig aktualisieren können, müssen sie Teil derselben Flotte und im selben Projekt sein.

Git-Zweige verwenden

Wenn Änderungen an Clustern angewendet werden sollen, sobald sie in Ihrem Git-Repository zusammengeführt wurden, konfigurieren Sie Anthos Config Management so, dass es Git-Zweige anstelle von Commits oder Tags verwendet. Bei dieser Methode können Sie mehrere langlebige Zweige in Ihrem Git-Repository erstellen und Anthos Config Management in verschiedenen Clustern konfigurieren, um sie aus verschiedenen Zweige zu lesen.

Ein einfaches Muster hat beispielsweise zwei Zweige:

  • Ein staging-Zweig für Nicht-Produktionscluster.
  • Ein master-Zweig für Produktionscluster.

Erstellen Sie für Nicht-Produktionscluster das Objekt ConfigManagement, wobei das Feld spec.git.syncBranch auf staging eingestellt ist. Erstellen Sie für Produktionscluster das Objekt ConfigManagement mit dem Parameter spec.git.syncBranch auf master. Wenn Sie Konfigurationen von mehreren Repositories synchronisieren, müssen Sie diese Konfiguration stattdessen in den benutzerdefinierten Ressourcen RootSync und RepoSync vornehmen. Weitere Informationen finden Sie unter Operator konfigurieren.

Beispiel: Mit der folgenden ConfigManagement-Definition wird Anthos Config Management für die Verwendung des Zweigs master konfiguriert:

apiVersion: configmanagement.gke.io/v1
kind: ConfigManagement
metadata:
  name: config-management
spec:
  # clusterName is required and must be unique among all managed clusters
  clusterName: my-cluster
  git:
    syncRepo: git@example.com:anthos/config-management.git
    # This cluster will apply the configuration
    # available on the master branch.
    syncBranch: master
    secretType: ssh

Das folgende Diagramm veranschaulicht den Rollout-Prozess für diese Methode:

Einführungsprozess für Git-Zweige.

Sie können dieses Muster an bestimmte Anforderungen anpassen, indem Sie mehr als zwei Zweige verwenden oder Zweige verwenden, die nicht zu Umgebungen gehören. Wenn Sie eine Änderung rückgängig machen müssen, verwenden Sie den Befehl git revert, um ein neues Commit für denselben Zweig zu erstellen, der die Änderungen aus dem vorheriges Commit.

Wir empfehlen Folgendes:

  • Verwenden Sie bei der Arbeit mit mehreren Clustern mindestens zwei Git-Zweige, um zwischen Produktions- und Nicht-Produktionsclustern zu unterscheiden.
  • Bei den meisten Git-Lösungen können Sie die geschützten Zweige verwenden, um Löschungen oder nicht überprüfte Änderungen dieser Zweige zu verhindern. Weitere Informationen finden Sie in der Dokumentation zu GitHub, GitLab und Bitbucket.

ClusterSelector- und NamespaceSelector-Objekte verwenden

Git-Zweige sind eine gute Möglichkeit, eine gestaffelte Einführung von Änderungen in mehreren Clustern durchzuführen, die letztendlich alle dieselben Richtlinien haben. Wenn Sie eine Änderung jedoch nur für eine Teilmenge von Clustern oder Namespaces bereitstellen möchten, verwenden Sie die Objekte ClusterSelector und NamespaceSelector. Diese Objekte haben ein ähnliches Ziel: Sie können Objekte nur auf Cluster oder Namespaces mit bestimmten Labels anwenden.

Beispiel:

  • Mit ClusterSelector - Objekten können Sie je nach Land, in dem sie sich befinden, für verschiedene Compliance-Systeme unterschiedliche Richtlinien auf Cluster anwenden.
  • Mit NamespaceSelector-Objekten können Sie verschiedene Richtlinien auf Namespaces anwenden, die von einem internen Team und von einem externen Auftragnehmer verwendet werden.

Mit ClusterSelector - und NamespaceSelector - Objekten können Sie außerdem erweiterte Test- und Freigabemethoden implementieren, z. B.:

  • Canary-Releases von Richtlinien, mit denen Sie eine neue Richtlinie für eine kleine Anzahl von Clustern und Namespaces über einen längeren Zeitraum bereitstellen, um die Auswirkungen der Richtlinie zu untersuchen.
  • A/B-Tests, bei denen Sie verschiedene Versionen derselben Richtlinie in verschiedenen Clustern bereitstellen, um die Auswirkungen der Richtlinienversionen zu untersuchen und anschließend die beste Version für alle Bereitstellungen auszuwählen.

Stellen Sie sich beispielsweise eine Organisation mit mehreren Produktionsclustern vor. Das Plattformteam hat bereits zwei Kategorien von Produktionsclustern namens canary-prod und prod mit Anthos Config Management-, Cluster- und ClusterSelector-Objekten erstellt (siehe nur eine Teilmenge von Clustern konfigurieren).

Das Plattformteam möchte eine Richtlinie mit Policy Controller bereitstellen, um das Vorhandensein eines Teamlabels für Namespaces zu erzwingen, um zu ermitteln, zu welchem Team der jeweilige Namespace gehört. Sie haben bereits eine Version dieser Richtlinie im Probelaufmodus eingeführt und möchten sie jetzt für eine kleine Anzahl von Clustern erzwingen. Mit ClusterSelector-Objekten erstellen sie zwei verschiedene K8sRequiredLabels-Ressourcen, die auf verschiedene Cluster angewendet werden.

  • Die Ressource K8sRequiredLabels wird auf Cluster vom Typ prod angewendet, wobei der Parameter enforcementAction auf dryrun gesetzt ist:

    apiVersion: constraints.gatekeeper.sh/v1beta1
    kind: K8sRequiredLabels
    metadata:
      name: ns-must-have-team
      annotations:
        configmanagement.gke.io/cluster-selector: prod
    Spec:
      enforcementAction: dryrun
      match:
        kinds:
          - apiGroups: [""]
            kinds: ["Namespace"]
      parameters:
        labels:
          - key: "team"
    
  • Die Ressource K8sRequiredLabels wird auf Cluster vom Typ canary-prod ohne den Parameter enforcementAction angewendet, was bedeutet, dass die Richtlinie tatsächlich erzwungen wird:

    apiVersion: constraints.gatekeeper.sh/v1beta1
    kind: K8sRequiredLabels
    metadata:
      name: ns-must-have-team
      annotations:
        configmanagement.gke.io/cluster-selector: canary-prod
    spec:
      match:
        kinds:
          - apiGroups: [""]
        kinds: ["Namespace"]
      parameters:
        labels:
          - key: "team"
    

Mit der Annotation configmanagement.gke.io/cluster-selector kann das Team die Richtlinie nur in Clustern vom Typ canary-prod erzwingen. Dadurch wird verhindert, dass unbeabsichtigte Nebenwirkungen an die gesamte Produktionsumgebung weitergegeben werden. Weitere Informationen zur Probelauffunktion von Policy Controller finden Sie unter Einschränkungen erstellen.

Wir empfehlen Folgendes:

  • Verwenden Sie die Objekte ClusterSelector und NamespaceSelector, wenn Sie eine Konfigurationsänderung nur auf eine Teilmenge von Clustern oder Namespaces anwenden möchten – entweder unbegrenzt oder eine lange Zeit.
  • Wenn Sie eine Änderung mithilfe von Selectors bereitstellen, sollten Sie sehr vorsichtig sein. Wenn Sie Git-Commits verwenden, wirkt sich jeder Fehler nur auf jeweils einen Cluster aus, da Sie den Cluster nach Cluster bereitstellen. Wenn Sie jedoch den Git-Zweig verwenden, kann sich jeder Fehler auf alle Cluster auswirken, die diesen Zweig verwenden. Wenn Sie Selectors verwenden, kann sich ein Fehler auf alle Cluster gleichzeitig auswirken.

Rezensionen, Tests und Validierungen implementieren

Ein Vorteil von Anthos Config Management ist, dass alles deklarativ verwaltet wird - Kubernetes-Ressourcen, Cloudressourcen und Richtlinien. Das bedeutet, dass Dateien in einem Versionsverwaltungssystem für Ressourcen die Ressourcen darstellen (im Fall von Anthos Config Management). Mit diesem Feature können Sie Entwicklungsworkflows implementieren, die Sie bereits für den Quellcode einer Anwendung verwenden: Überprüfungen und automatisierte Tests.

Rezensionen implementieren

Da Anthos Config Management auf Git basiert, können Sie Ihre bevorzugte Git-Lösung zum Hosten des Anthos Config Management-Repositorys verwenden. Ihre Git-Lösung verfügt wahrscheinlich über eine Funktion zur Codeüberprüfung, mit der Sie Änderungen prüfen können, die an dem Anthos Config Management-Repository vorgenommen wurden.

Die Best Practices für die Überprüfung von Änderungen am Anthos Config Management-Repository sind die gleichen wie bei einer normalen Codeüberprüfung:

Aufgrund der Vertraulichkeit der Anthos Config Management-Codebasis sollten Sie außerdem, wenn möglich, mit den folgenden Konfigurationen Ihre Git-Lösung erstellen:

Mit diesen verschiedenen Funktionen können Sie Genehmigungen für jede Änderungsanfrage an die Anthos Config Management-Codebasis erzwingen. Beispielsweise können Sie sicherstellen, dass jede Änderung von mindestens einem Mitglied des Plattformteams, das den Cluster verwaltet, und von einem Mitglied des Sicherheitsteams, der sich in für die Definition und Implementierung von Sicherheitsrichtlinien.

Wir empfehlen Folgendes:

  • Erzwingen Sie Peer-Reviews im Anthos Config Management-Repository und schützen Sie die von Ihren Clustern verwendeten Git-Zweigs.

Automatisierte Tests implementieren

Eine gängige Best Practice beim Arbeiten in einer Codebasis besteht darin, die Continuous Integration zu implementieren. Dies bedeutet, dass Sie automatisierte Tests konfigurieren, die ausgeführt werden, wenn eine Änderungsanfrage erstellt oder aktualisiert wird. Mit automatisierten Tests können viele Fehler erkannt werden, bevor ein Mitarbeiter die Änderungsanfrage überprüft. Dadurch wird die Feedbackschleife für den Entwickler verschärft. Sie können dieselbe Idee mit denselben Tools für das Anthos Config Management-Repository implementieren.

Ein guter Ausgangspunkt hierfür ist beispielsweise, den nomos vet-Befehl bei neuen Änderungen automatisch auszuführen. Mit diesem Befehl wird überprüft, ob die Syntax Ihres Anthos Config Management-Repository gültig ist. Sie können diesen Test mithilfe von Cloud Build implementieren. Folgen Sie dazu der Anleitung Konfigurationen prüfen. Sie können Cloud Build mit den folgenden Optionen integrieren:

Wie Sie in der Anleitung Konfigurationen überprüfen sehen können, wird der Test mit einem Container-Image durchgeführt. Daher können Sie den Test in jeder Continuous Integration-Lösung implementieren, die Container ausführt, nicht nur in Cloud Build. Insbesondere können Sie sie mit GitLab CI gemäß dem diesem Beispiel implementieren, das auch Tests für Policy Controller enthält.

Wenn Sie die Feedback Loop noch stärker eingrenzen möchten, können Sie den Befehl nomos vet als Git-Pre-Commit-Hook ausführen. Ein Nachteil ist, dass einige Nutzer möglicherweise keinen Zugriff auf die von Anthos Config Management verwalteten Kubernetes-Cluster haben und unter Umständen nicht die vollständige Validierung von ihrer Workstation aus ausführen können. Führen Sie den Befehl nomos vet --clusters "" aus, um die Validierung auf semantische und syntaktische Prüfungen einzuschränken.

Sie können jeden anderen Test implementieren, der Ihrer Meinung nach erforderlich ist oder nützlich ist. Wenn Sie Policy Controller verwenden, können Sie automatisierte Tests von vorgeschlagenen Änderungen anhand der Richtlinien implementieren (siehe Änderungen an Richtlinien des Policy Controllers testen).

Wir empfehlen Folgendes:

  • Tests in einer CI-Pipeline implementieren. Führen Sie mindestens den Befehl nomos vet für alle vorgeschlagenen Änderungen aus.

Policy Controller verwenden

Policy Controller ist ein dynamischer Admission-Controller von Kubernetes. Wenn Sie Policy Controller installieren und konfigurieren, kann Kubernetes Änderungen ablehnen, die nicht den vordefinierten Regeln entsprechen. Diese werden als Richtlinien bezeichnet.

Im Folgenden finden Sie zwei Beispiele für Anwendungsfälle des Richtliniencontrollers:

  • Einsetzen bestimmter Labels für Kubernetes-Objekte erzwingen.
  • Das Erstellen von privilegierten Pods verhindern.

Für die Implementierung der am häufigsten verwendeten Richtlinien steht eine Bibliothek mit Richtlinienvorlagen zur Verfügung, aber Sie können auch eine eigene Sprache mit dem Namen Rego erstellen. Mit Policy Controller können Sie beispielsweise die Hostnamen einschränken, die Nutzer in einem Ingress konfigurieren können. Weitere Informationen finden Sie in dieser Anleitung.

Wie Config Sync ist auch der Policy Controller Teil des Anthos Config Management-Produkts. Policy Controller und Config Sync haben unterschiedliche, sich jedoch ergänzende Anwendungsfälle:

  • Config Sync ist ein Tool im GitOps-Stil, mit dem Sie jedes Kubernetes-Objekt erstellen können, möglicherweise in mehreren Clustern gleichzeitig. Wie in der Einführung erwähnt, ist Config Sync besonders nützlich für die Verwaltung von Richtlinien.
  • Mit Policy Controller können Sie Richtlinien für Objekte definieren, die in Kubernetes erstellt werden können. Sie definieren diese Richtlinien in benutzerdefinierten Ressourcen, die Kubernetes-Objekte selbst sind.

Die vorherigen Features erstellen eine bidirektionale Beziehung zwischen den beiden Anwendungen. Sie können mit Config Sync die Richtlinien erstellen, die vom Policy Controller erzwungen werden. Außerdem können Sie diese Richtlinien verwenden, um genau zu steuern, welche Objekte von Config Sync oder einem anderen Prozess erstellt werden können (siehe Abbildung), wie im folgenden Diagramm dargestellt:

Config Sync und Policy Controller.

Das Git-Repository, Config Sync, Policy Controller, Kubernetes, ein Continuous-Deployment-System (CD) und alle Nutzer interagieren auf folgende Weise miteinander:

  • Nutzer interagieren mit dem Git-Repository von Anthos Config Management, um Kubernetes-Objekte zu erstellen, zu aktualisieren oder zu löschen.
  • Config Sync liest die Konfiguration aus dem Anthos Config Management Git-Repository.
  • Config Sync interagiert mit dem Kubernetes API-Server, um Objekte zu erstellen, die Richtlinien für den Policy Controller enthalten.
  • Das CD-System interagiert auch mit dem Kubernetes API-Server, um Objekte zu erstellen. Sie kann Einschränkungen für den Policy Controller erstellen. Wir empfehlen Ihnen jedoch, für diesen Anwendungsfall Anthos Config Management zu verwenden, da Sie damit an einem zentralen Ort die Verwaltung und den Test der Einschränkungen verwalten können.
  • Der Kubernetes API-Server akzeptiert oder lehnt die Erstellung von Objekten von Config Sync und vom CD-System auf der Grundlage der Antwort von Policy Controller ab.
  • Der Policy Controller gibt diese Antwort basierend auf den Richtlinien aus, die er vom Kubernetes API-Server liest.

Das folgende Diagramm veranschaulicht diese Interaktionen:

Interaktionen zwischen Git-Repository, Config Sync, Policy Controller, Kubernetes, einem kontinuierlichen Bereitstellungssystem und Nutzern.

Policy Controller kann Richtlinienverstößen verhindern, die menschliche Prüfer und automatisierte Tests maskieren. So können Sie ihn als letzte Verteidigungslinie für Ihre Kubernetes-Cluster betrachten. Policy Controller wird auch nützlicher, wenn die Anzahl der Prüfer für Anthos Config Management steigt. Aufgrund des Problems des Social Loafings gilt: Je mehr Prüfer Sie haben, desto unwahrscheinlicher ist es, dass sie die in Ihrer Organisation definierten Regeln konsistent anwenden.

Änderungen an Policy Controller-Richtlinien testen

Wenn Sie Policy Controller verwenden, können Sie Ihrer CI-Pipeline einige Schritte hinzufügen, um vorgeschlagene Änderungen automatisch an Richtlinien zu testen (siehe Automatisierte Tests implementieren). Durch die Automatisierung der Tests können die Person, die die Änderung vornimmt, schneller und sichtbares Feedback gegeben. Wenn Sie die Änderungen nicht mit den Richtlinien in der Pipeline für die kontinuierliche Integration testen, müssen Sie sich auf das System verlassen, das unter Rollouts überwachen beschrieben wird, um über Anthos informiert zu werden. Config Management-Synchronisierungsfehler. Beim Testen der Änderungen gegen die Richtlinien werden die Verstöße gegen die Person, die die Änderung vorgeschlagen hat, deutlich und frühzeitig zur Verfügung gestellt.

Sie können diesen Test in Cloud Build implementieren, indem Sie der Anleitung Policy Controller in einer CI-Pipeline verwenden folgen. Wie schon unter Automatisierte Tests implementieren erwähnt, können Sie Cloud Build in GitHub und Bitbucket integrieren. Sie können diesen Test auch mit GitLab CI implementieren. Ein Implementierungsbeispiel finden Sie in diesem Repository.

Wir empfehlen Folgendes:

  • Wenn Sie Policy Controller verwenden, validieren Sie die vorgeschlagenen Änderungen mit ihren Richtlinien in Ihrer CI-Pipeline.

Rollouts überwachen

Auch wenn Sie alle Guard-Funktionen implementieren, die in diesem Dokument behandelt werden, können Fehler auftreten. Im Folgenden sind zwei häufig auftretende Fehlertypen aufgeführt:

  • Fehler, die für Config Sync selbst kein Problem darstellen, aber verhindern, dass Ihre Arbeitslasten ordnungsgemäß funktionieren, z. B. eine zu restriktive NetworkPolicy, die die Kommunikation von Komponenten Ihrer Arbeitslast verhindert.
  • Fehler, die Config Sync unmöglich macht, Änderungen auf einen Cluster anzuwenden, z. B. ein ungültiges Kubernetes-Manifest oder ein von einem Admission-Controller abgelehntes Objekt. Mit den oben beschriebenen Methoden sollten die meisten dieser Fehler abgefangen werden.

Die Ermittlung der Fehler, die im ersten Punkt beschrieben wurden, ist auf der Ebene von Anthos Config Management fast unmöglich, da dies den Status jeder Ihrer Arbeitslasten erfordert. Aus diesem Grund sollten diese Fehler am besten von Ihrem bestehenden Überwachungssystem erkannt werden, das Sie benachrichtigt, wenn eine Anwendung fehlerhaft ist.

Das Erkennen der im zweiten vorangegangenen Punkt beschriebenen Fehler, die selten auftreten sollten, wenn Sie alle Leitplanken implementiert haben, erfordern eine spezielle Einrichtung. Standardmäßig schreibt Anthos Config Management Fehler in seine Logs, die Sie standardmäßig in Cloud Logging finden. Die Fehler werden auch auf der Anthos Config Management-Konsolenseite angezeigt. Weder Logs noch die Konsole sind in der Regel ausreichend, um Fehler zu erkennen, da sie wahrscheinlich nicht immer überwacht werden. Die einfachste Möglichkeit, die Fehlererkennung zu automatisieren, besteht in der Ausführung des nomos status-Befehls. Dieser gibt an, ob ein Fehler in einem Cluster aufgetreten ist.

Sie können auch eine fortgeschrittenere Lösung mit automatischen Warnungen für Fehler einrichten. Anthos Config Management stellt Messwerte im Prometheus-Format bereit. Sie können diese Messwerte mit Prometheus extrahieren, den Import von Prometheus-Messwerten in Cloud Monitoring konfigurieren oder eine beliebige Überwachungslösung verwenden, die mit dem Prometheus-Format kompatibel ist. Weitere Informationen finden Sie unter Anthos Config Management überwachen.

Wenn die Anthos Config Management-Messwerte in Ihrem Überwachungssystem vorhanden sind, erstellen Sie eine Benachrichtigung, um informiert zu werden, wenn der Messwert gkeconfig_monitor_errors größer als 0 ist. Weitere Informationen finden Sie unter Benachrichtigungsrichtlinien für Cloud Monitoring verwalten oder Benachrichtigungsregeln für Prometheus.

Zusammenfassung der Mechanismen für sichere Rollouts mit Anthos Config Management

In der folgenden Tabelle sind die verschiedenen Mechanismen zusammengefasst, die zuvor in diesem Dokument beschrieben wurden. Keiner dieser Mechanismen ist exklusiv. Sie können einige oder alle Elemente für unterschiedliche Zwecke verwenden.

Mechanismus Einsatzmöglichkeit Nicht geeignet für Anwendungsbeispiel
Git-Commit-IDs und -Tags Verwenden Sie bestimmte Git-Commit-IDs oder -Tags, um genau zu steuern, auf welche Clusteränderungen angewendet werden. Verwenden Sie keine Git-Commit-IDs oder -Tags für langlebige Unterschiede zwischen Clustern. Verwenden Sie Clusterselektoren. Alle Cluster sind so konfiguriert, dass das Git-Commit 12345 angewendet wird. Sie nehmen eine Änderung mit einem neuen Commit (abcdef) vor, den Sie testen möchten. Sie ändern die Konfiguration eines einzelnen Clusters, um dieses neue Commit zum Validieren der Änderung zu verwenden.
Git-Zweige Verwenden Sie mehrere Git-Zweige, wenn Sie dieselbe Änderung in mehreren Umgebungen bereitstellen möchten: in der anderen. Verwenden Sie nicht mehrere Git-Zweige für langlebige Unterschiede zwischen Clustern. Die Zweige unterscheiden sich erheblich und werden nur schwer zusammengeführt. Führen Sie zuerst die Änderung im Staging-Zweig zusammen, wo sie von Staging-Clustern übernommen wird.
Führen Sie dann die Änderung im Master-Zweig zusammen, wo sie von Produktionsclustern übernommen wird.
Cluster-Selektoren und Namespace-Selektoren Verwenden Sie Selektoren für langlebige Unterschiede zwischen Clustern und Namespaces. Verwenden Sie keine Selektoren für einen bereitgestellten Rollout in mehreren Umgebungen. Wenn Sie eine Änderung zuerst im Staging testen und dann in der Produktion bereitstellen möchten, verwenden Sie separate Git-Zweigen. Wenn die Anwendungsteams vollen Zugriff auf Entwicklungscluster, aber Lesezugriff auf Produktionscluster benötigen, verwenden Sie das Objekt ClusterSelector, um die richtigen RBAC-Richtlinien nur auf die relevanten Cluster anzuwenden.
Rezensionen anderer Nutzer Achten Sie darauf, dass die relevanten Teams die Änderungen genehmigen. Prüfer erfassen nicht alle Fehler, insbesondere Elemente wie Syntaxfehler. Ihre Organisation verlangt, dass das Sicherheitsteam Konfigurationsänderungen überprüfen muss, die mehrere Systeme betreffen. Ein Mitglied des Sicherheitsteams muss die Änderungen überprüfen.
Automatisierte Tests in der CI-Pipeline Verwenden Sie automatisierte Tests, um Fehler in Änderungsvorschlägen zu erkennen. Automatisierte Tests können Prüfer nicht vollständig ersetzen. Beide verwenden. Das Ausführen des Befehls nomos vet für alle vorgeschlagenen Änderungen bestätigt, dass das Repository eine gültige Anthos Config Management-Konfiguration ist.
Policy Controller Sie können organisationsweite Richtlinien erzwingen und Leitlinien direkt auf der Kubernetes API-Serverebene implementieren. Policy Controller kann nicht zum Erstellen, Aktualisieren oder Löschen von Richtlinien verwendet werden (dies ist die Rolle von Anthos Config Management). Policy Controller kann nur Richtlinien erzwingen. Das Sicherheitsteam verwendet Anthos Config Management, um eine Policy Controller-Einschränkung zu erstellen, um zu verhindern, dass Nutzer privilegierte Container erstellen, auch in Namespaces, die direkt von den Anwendungsteams verwaltet werden.
Änderungen an Policy Controller-Einschränkungen testen. Achten Sie darauf, dass der Policy Controller keine Änderungen ablehnt, wenn Anthos Config Management sie anwendet. Das Testen von Einschränkungen des Policy Controllers in einer Continuous Integration-Pipeline stellt kein Ersatz für die Aktivierung des Policy Controllers für die Cluster dar. Jeder Namespace muss ein "Team" -Label haben, um seinen Inhaber zu identifizieren. Ein Nutzer möchte einen neuen Namespace erstellen und hat vergessen, dieses Label in der vorgeschlagenen Änderung hinzuzufügen. Die CI-Pipeline erfasst den Fehler, bevor ein Mensch die Änderung überprüft.
Überwachen Sie Synchronisierungsfehler Anthos Config Management übernimmt Änderungen tatsächlich auf Ihre Cluster. Synchronisierungsfehler treten nur auf, wenn Anthos Config Management ein ungültiges Repository anwendet oder der Kubernetes API-Server einige der Objekte ablehnt. Wenn Sie nicht alle Einschränkungen in den Policy Controller-Richtlinien codiert haben, werden Ressourcen, die gegen diese Einschränkungen verstoßen, nicht erkannt. Ein Nutzer umgeht Ihre Tests und Überprüfungen und übergibt eine ungültige Änderung an das Anthos Config Management-Repository. Diese Änderung kann nicht auf Ihre Cluster angewendet werden. Wenn Sie Synchronisierungsfehler überwachen, werden Sie benachrichtigt, wenn ein Fehler auftritt.

Beispiel für eine Rollout-Strategie

In diesem Abschnitt werden die in diesem Artikel vorgestellten Konzepte verwendet, um eine End-to-End-Einführungsstrategie für alle Cluster in Ihrer Organisation zu erstellen. Bei dieser Strategie wird davon ausgegangen, dass Sie separate Flotten für Entwicklung, Staging und Produktion haben (siehe Flottenbeispiel 1 – Ansatz 1).

In diesem Szenario konfigurieren Sie jeden Cluster für die Synchronisierung mit dem Anthos Config Management Git-Repository mit einem bestimmten Git-Commit. Die Bereitstellung einer Änderung in einer bestimmten Flotte umfasst vier Schritte:

  1. Sie aktualisieren einen einzelnen (den „Canary“)-Cluster in der Flotte, um das neue Commit zuerst zu verwenden.
  2. Sie prüfen, ob alles erwartungsgemäß funktioniert. Führen Sie dazu Tests aus und überwachen Sie den Rollout.
  3. Sie aktualisieren die übrigen Cluster in der Flotte.
  4. Sie prüfen noch einmal, ob alles wie erwartet funktioniert.

Wenn Sie eine Änderung in allen Clustern bereitstellen möchten, wiederholen Sie diesen Vorgang für jede Flotte. Sie können diese Methode technisch auf jedem Git-Commit anwenden. Wir empfehlen Ihnen aber, den folgenden Prozess zu folgen, um Probleme frühzeitig während der Prüfung zu identifizieren:

  1. Wenn jemand eine Änderungsanfrage im Git-Repository von Anthos Config Management öffnet, stellen Sie diese Änderung für einen der Entwicklungscluster bereit.
  2. Wenn die Änderungsanfrage akzeptiert und in Ihrem Hauptzweig zusammengeführt wurde, führen Sie das vollständige Deployment für alle Flotten wie oben beschrieben aus.

Auch wenn einige Änderungen möglicherweise nur auf eine bestimmte Flotte ausgerichtet sind, empfehlen wir, alle Änderungen erst später für alle Flotten bereitzustellen. Diese Strategie beseitigt das Problem der Verfolgung, welche Flotte mit welchem Commit synchronisiert werden soll. Achten Sie besonders auf die Änderungen, die nur auf die Produktionsflotte ausgerichtet sind, da in früheren Flotten keine ordnungsgemäßen Tests möglich waren. Dies bedeutet beispielsweise, dass Sie länger warten müssen, bis Probleme zwischen der Bereitstellung in den Canary-Clustern und den übrigen Clustern auftreten.

Zusammenfassend sieht eine vollständige End-to-End-Bereitstellung folgendermaßen aus:

  1. Ein Änderungsantrag wird geöffnet.
  2. Automatisierte Tests und Validierungen werden durchgeführt und eine manuelle Prüfung wird durchgeführt.
  3. Sie lösen einen Job manuell aus, um die Änderung für den Canary-Cluster in der Entwicklungsflotte bereitzustellen. In diesem Cluster werden automatische End-to-End-Tests ausgeführt.
  4. Wenn alles in Ordnung ist, führen Sie die Änderungsanfrage im Hauptzweig zusammen.
  5. Die Zusammenführung löst einen automatisierten Job aus, um den neuen Zweigspitzen-Commit für den Canary-Cluster in der Entwicklungsflotte bereitzustellen. In diesem Cluster werden automatische End-to-End-Tests ausgeführt, um mögliche Inkompatibilitäten zwischen zwei Änderungsanfragen zu ermitteln, die erstellt und etwa zeitgleich erstellt wurden.
  6. Die folgenden Jobs werden nacheinander ausgeführt (Sie lösen sie manuell oder nach einer vordefinierten Zeit aus, um Nutzerberichte über Regressionen zu ermöglichen):
    1. In allen Clustern der Entwicklungsflotte bereitstellen.
    2. Tests und Validierungen in den Clustern der Entwicklungsflotte ausführen.
    3. Im Canary-Cluster der Staging-Flotte bereitstellen.
    4. Tests und Validierungen im Canary-Cluster der Staging-Flotte durchführen.
    5. In allen Clustern der Staging-Flotte bereitstellen.
    6. Tests und Validierungen in den Clustern der Staging-Flotte ausführen.
    7. Im Canary-Cluster der Produktionsflotte bereitstellen.
    8. Tests und Validierungen im Canary-Cluster des Produktionsflotte ausführen.
    9. In allen Clustern der Produktionsflotte bereitstellen.
    10. Tests und Validierungen in den Clustern der Produktionsflotte ausführen.

Vollständiger Einführungsprozess.

Nächste Schritte