Sichere Roll-outs mit Config Management

In diesem Dokument wird beschrieben, wie Clusteroperatoren und Plattformadministratoren mit Config Management Änderungen sicher in mehreren Umgebungen einführen können. Mit Config Management können Sie Fehler vermeiden, die alle Umgebungen gleichzeitig betreffen.

Mit Config Management können Sie einzelne Cluster, mehrmandantenfähige Cluster und mehrmandantenfähige Kubernetes-Konfigurationen mithilfe von Dateien verwalten, die in einem Git-Repository gespeichert sind. 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:

Config Management eignet sich besonders zum Bereitstellen von Konfigurationen, Richtlinien und Arbeitslasten, die zum Ausführen der Plattform erforderlich sind, die Sie auf GKE Enterprise erstellen, z. B. Sicherheits-Agents, Monitoring-Agents und Zertifikatmanager.

Obwohl Sie mit Config Management Anwendungen für Nutzer bereitstellen können, raten wir davon ab, ihren Release-Lebenszyklus mit dem Release-Lebenszyklus der oben genannten 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.

Config Management ist ein leistungsstarkes Produkt, mit dem viele Elemente verwaltet werden können. Daher benötigen Sie Sicherheitsvorkehrungen, um Fehler zu vermeiden, die erhebliche 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 beschrieben, wie Sie Config Management-Bereitstellungen überwachen.

Sie können die meisten der in diesem Dokument beschriebenen Methoden verwenden, auch wenn Sie nur Config Sync und nicht das vollständige Config Management-Produkt verwenden. Wenn Sie nicht das vollständige Config Management-Produkt verwenden, aber trotzdem die Methoden mit Policy Controller implementieren möchten, ist dies mit Gatekeeper möglich. Ausnahmen von dieser Regel sind Methoden, die auf der Seite „Config Management“ in der Google Cloud Console basieren, z. B. das Aktualisieren der 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 Roll-outs mit Config Management implementieren

In einer Multi-Cluster-Umgebung, die häufig für GKE Enterprise-Nutzer auftritt, raten wir davon ab, eine Konfigurationsänderung gleichzeitig auf alle Cluster 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 Roll-outs mit 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. Auf der Seite „Config Management“ in der Console 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 „pinnen“ Sie jeden Cluster an eine bestimmte Version (entweder einen Commit oder ein Tag) Ihres Config Management-Repositorys an. Diese Methode ähnelt der Verwendung des Git-Commits als Container-Image-Tag. Zum Implementieren dieser Methode geben Sie den Commit, das Tag oder den Hash im Feld spec.git.revision der benutzerdefinierten Ressource RootSync oder RepoSync an.

Wenn Sie Ihre benutzerdefinierten RootSync- oder RepoSync-Ressourcen mit einem Tool wie kustomize verwalten, können Sie den manuellen Aufwand für das Roll-out von Änderungen reduzieren. Bei einem solchen Tool müssen Sie den revision-Parameter nur an einer Stelle ändern und dann die neue benutzerdefinierte Ressource RootSync oder RepoSync in der von Ihnen gewählten Reihenfolge und Geschwindigkeit auf Ihre Cluster anwenden.

Wenn Sie Config Management (und nicht Config Sync) verwenden, haben Sie außerdem Zugriff auf die Seite „Config Management“ in der Google Cloud Console. Auf dieser Seite können Sie den Parameter revision für mehrere Cluster gleichzeitig aktualisieren, die zur selben Flotte gehören. Wenn Sie ein automatisiertes System zum Aktualisieren der Config Management-Konfiguration haben, raten wir davon ab, diese Konfiguration über die Console zu ändern.

Mit der folgenden RootSync-Definition wird Config Management beispielsweise für die Verwendung des Tags 1.2.3 konfiguriert:

apiVersion: configsync.gke.io/v1
kind: RootSync
metadata:
  name: root-sync
  namespace: config-management-system
spec:
  sourceType: git
  sourceFormat: unstructured
  git:
    repo: git@example.com:anthos/config-management.git
    revision: 1.2.3
    auth: ssh

Wenn Sie diese Konfiguration auf Ihren Cluster anwenden, verwendet 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.revision 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.revision wieder in den vorherigen Wert.

Das folgende Diagramm veranschaulicht den Rollout-Prozess für diese Methode. Zuerst führen Sie einen Commit für Änderungen im Config Management-Repository durch und aktualisieren dann die RootSync-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. Beispielsweise kann ein git push --force den von Config Management verwendeten 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 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 auf Cluster angewendet werden sollen, sobald diese in Ihrem Git-Repository zusammengeführt wurden, konfigurieren Sie Config Management so, dass Git-Branches anstelle von Commits oder Tags verwendet werden. Bei dieser Methode können Sie mehrere langlebige Zweige in Ihrem Git-Repository erstellen und Config Management in verschiedenen Clustern so konfigurieren, dass die Konfiguration aus verschiedenen Branches gelesen wird.

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 RootSync oder RepoSync, wobei das Feld spec.git.branch auf staging festgelegt ist. Erstellen Sie für Produktionscluster das Objekt RootSync oder RepoSync, wobei der Parameter spec.git.branch auf master festgelegt ist.

Mit der folgenden RootSync-Definition wird Config Management beispielsweise für die Verwendung des Zweigs master konfiguriert:

apiVersion: configsync.gke.io/v1
kind: RootSync
metadata:
  name: root-sync
  namespace: config-management-system
spec:
  git:
    repo: git@example.com:anthos/config-management.git
    branch: master
    auth: 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 mit Config Management-, Cluster- und ClusterSelector-Objekten bereits zwei Kategorien von Produktionsclustern erstellt: canary-prod und prod (siehe ClusterSelectors verwenden).

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 Config Management besteht darin, dass alles deklarativ verwaltet wird – Kubernetes-Ressourcen, Cloud-Ressourcen und Richtlinien. Das bedeutet, dass Dateien in einem Versionsverwaltungssystem die Ressourcen darstellen (Git-Dateien im Fall von 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 Config Management auf Git basiert, können Sie das Config Management-Repository mit Ihrer bevorzugten Git-Lösung hosten. Ihre Git-Lösung verfügt wahrscheinlich über ein Codeüberprüfungsfeature, mit dem Sie Änderungen am Config Management-Repository überprüfen können.

Die Best Practices zum Überprüfen von Änderungen am Config Management-Repository entsprechen denen bei einer normalen Codeüberprüfung:

Aufgrund der Vertraulichkeit der Config Management-Codebasis empfehlen wir außerdem, nach Möglichkeit für Ihre Git-Lösung die folgenden Konfigurationen zu erstellen:

Mit diesen verschiedenen Features können Sie Genehmigungen für jede Änderungsanfrage an die 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 für das Config Management-Repository und schützen Sie die Git-Zweige, die von Ihren Clustern verwendet werden.

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 die gleiche Idee mit denselben Tools für das Config Management-Repository umsetzen.

Ein guter Ausgangspunkt hierfür ist beispielsweise, den nomos vet-Befehl bei neuen Änderungen automatisch auszuführen. Dieser Befehl prüft, ob die Syntax des Config Management-Repositorys 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 besteht darin, dass einige Nutzer möglicherweise keinen Zugriff auf die von Config Management verwalteten Kubernetes-Cluster haben und die vollständige Validierung von ihrer Workstation aus nicht 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 Policy Controller Teil des 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 Config Management-Git-Repository, um Kubernetes-Objekte zu erstellen, zu aktualisieren oder zu löschen.
  • Config Sync liest seine Konfiguration aus dem 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 jedoch, für diesen Anwendungsfall Config Management zu verwenden, da Sie die Einschränkungen an einem zentralen Ort verwalten und testen 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 Config Management wächst. 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 anhand der Richtlinien in der CI-Pipeline testen, müssen Sie sich darauf verlassen, dass das unter Rollouts überwachen beschriebene System über Config Management-Synchronisierungsfehler informiert wird. 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.

Auf der Ebene von Config Management ist es fast unmöglich, die im ersten vorherigen Punkt beschriebenen Fehler zu erkennen, da Sie dazu den Status jeder Ihrer Arbeitslasten kennen müssen. 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 Config Management Fehler in die Logs, die standardmäßig in Cloud Logging zu finden sind. Fehler werden auch auf der Seite Config Management-Konsole angezeigt. Weder Logs noch die Console 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. Config Management stellt Messwerte im Prometheus-Format zur Verfügung. Weitere Informationen finden Sie unter Config Management überwachen.

Wenn sich die Config Management-Messwerte in Ihrem Monitoringsystem befinden, 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 Roll-outs mit 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. Wenn Sie einen nomos vet-Befehl für alle vorgeschlagenen Änderungen ausführen, bestätigen Sie, dass das Repository eine gültige 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 Config Management). Policy Controller kann nur Richtlinien erzwingen. Das Sicherheitsteam verwendet 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 Policy Controller Änderungen nicht ablehnt, wenn sie von Config Management angewendet werden. 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 Prüfen Sie, ob Config Management Änderungen tatsächlich auf Ihre Cluster anwendet. Synchronisierungsfehler treten nur auf, wenn Config Management versucht, ein ungültiges Repository anzuwenden, oder wenn 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 alle Ihre Tests und überprüft sie und führt eine ungültige Änderung am Config Management-Repository durch. 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 Config Management Git-Repository mithilfe eines bestimmten Git-Commits. 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 ein Nutzer eine Änderungsanfrage im Config Management-Git-Repository öffnet, stellen Sie diese Änderung in einem 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