🥇GitOps: Vergleich der Pull- und Push-Methoden

Hinweis.: In der Kubernetes-Community gewinnt der Trend namens GitOps zunehmend an Beliebtheit, was wir persönlich festgestellt haben, als wir die KubeCon Europe 2019 besucht haben. Dieser Begriff wurde relativ neu geschaffen von Alexis Richardson, dem Geschäftsführer von Weaveworks, und bezieht sich auf die Nutzung von gängigen Entwicklerwerkzeugen (vor allem Git, was auch den Namen erklärt) zur Lösung von Betriebsproblemen. Insbesondere geht es um den Betrieb von Kubernetes durch die Speicherung seiner Konfigurationen in Git und die automatische Bereitstellung von Änderungen im Cluster. Über zwei Ansätze zur Umsetzung berichtet Matthias Jg in diesem Artikel.

GitOps: Vergleich von Pull- und Push-Methoden

Im vergangenen Jahr (tatsächlich fand dies formell im August 2017 statt – Anmerkung des Übersetzers) erschien ein neuer Ansatz zur Bereitstellung von Anwendungen in Kubernetes. Dieser wird GitOps genannt und basiert auf der grundlegenden Vorstellung, dass die Versionsverfolgung von Deployments in einer sicheren Umgebung eines Git-Repositories erfolgt.

Die Hauptvorteile dieses Ansatzes sind folgende:

Versionskontrolle von Deployments und Änderungshistorie. Der Zustand des gesamten Clusters wird in einem Git-Repository gespeichert, und Deployments werden nur durch Commits aktualisiert. Darüber hinaus können alle Änderungen über die Commit-Historie überwacht werden.
Rollbacks mit den gewohnten Git-Befehlen. Einfach git reset erlaubt das Zurücksetzen von Änderungen in Deployments; frühere Zustände sind immer verfügbar.
Fertige Zugriffskontrolle. In der Regel enthält das Git-System viele vertrauliche Daten, weshalb die meisten Unternehmen besonderen Wert auf dessen Sicherheit legen. Entsprechend gilt dieser Schutz auch für Operationen mit Deployments.
Richtlinien für Deployments. Die meisten Git-Systeme unterstützen von Anfang an Richtlinien für verschiedene Branches - zum Beispiel dürfen nur Pull-Requests den Master aktualisieren, und Änderungen müssen von einem anderen Teammitglied überprüft und akzeptiert werden. Wie bei der Zugriffskontrolle gelten die gleichen Richtlinien für die Aktualisierungen von Deployments.

Wie Sie sehen, bietet die GitOps-Methode zahlreiche Vorteile. Im letzten Jahr haben sich zwei Ansätze besonders populär gemacht. Einer basiert auf Push, der andere auf Pull. Bevor wir diese näher betrachten, schauen wir uns zunächst an, wie typische Kubernetes-Deployments aussehen.

Bereitstellungsmethoden

In den letzten Jahren haben sich verschiedene Methoden und Werkzeuge für Deployments in Kubernetes etabliert:

Basierend auf nativen Vorlagen von Kubernetes/Kustomize. Dies ist der einfachste Weg, um Anwendungen in Kubernetes zu deployen. Der Entwickler erstellt grundlegende YAML-Dateien und wendet sie an. Um das ständige Neu schreiben der gleichen Vorlagen zu vermeiden, wurde Kustomize entwickelt (es verwandelt Kubernetes-Vorlagen in Module). Hinweis.: Kustomize wurde mit der Kubernetes-Version 1.14.
Helm Charts. Helm Charts ermöglichen die Erstellung von Vorlagensätzen, Init-Containern, Sidecars usw., die für das Deployment von Anwendungen mit flexibleren Konfigurationsmöglichkeiten verwendet werden als im vorlagenbasierten Ansatz. Die Grundlage dieser Methode bilden templatisierte YAML-Dateien. Helm füllt sie mit verschiedenen Parametern und sendet sie dann an Tiller — eine clusterbasierte Komponente, die sie im Cluster bereitstellt und Updates sowie Rollbacks ermöglicht. Wichtig ist, dass Helm im Grunde einfach die benötigten Werte in die Vorlagen einfügt und sie dann ebenso anwendet, wie es im traditionellen Ansatz gemacht wird. (mehr darüber, wie das alles funktioniert und wie man es verwenden kann, lesen Sie in unserem Artikel über Helm — Anmerkung des Übersetzers).. Es gibt eine Vielzahl von fertigen Helm-Charts, die ein breites Spektrum an Aufgaben abdecken.
Alternative Werkzeuge. Es gibt zahlreiche alternative Werkzeuge. Alle haben gemeinsam, dass sie bestimmte Vorlage-Dateien in verständliche Kubernetes-YAML-Dateien umwandeln und diese dann anwenden.

In unserer Arbeit verwenden wir ständig Helm-Charts für wichtige Werkzeuge (da sie viele Vorbereitungen bereits getroffen haben, was das Leben erheblich vereinfacht) und "reine" Kubernetes-YAML-Dateien, um unsere eigenen Anwendungen bereitzustellen.

Pull & Push

In einem meiner letzten Blogbeiträge habe ich ein Werkzeug vorgestellt Weave Flux, das es ermöglicht, Vorlagen in ein Git-Repository zu committen und das Deployment nach jedem Commit oder Push des Containers zu aktualisieren. Meine Erfahrung zeigt, dass dieses Werkzeug eines der wichtigsten im Bereich der Förderung des Pull-Ansatzes ist, deshalb werde ich häufig darauf verweisen. Wenn Sie mehr darüber erfahren möchten, wie man es verwendet, hier ist der Link zum Artikel.

NB! Alle Vorteile der Nutzung von GitOps bleiben für beide Ansätze erhalten.

Pull-basierter Ansatz

GitOps: Vergleich von Pull- und Push-Methoden

Der Pull-Ansatz basiert auf der Tatsache, dass alle Änderungen intern im Cluster angewendet werden. Im Cluster gibt es einen Operator, der regelmäßig die verbundenen Git-Repositorys und das Docker-Registry überprüft. Wenn Änderungen festgestellt werden, wird der Zustand des Clusters intern aktualisiert. Dieser Prozess gilt im Allgemeinen als sehr sicher, da kein externer Client Administratorrechte für das Cluster hat.

Vorteile:

Kein externer Client hat das Recht, Änderungen am Cluster vorzunehmen; alle Updates werden intern angewendet.
Einige Werkzeuge ermöglichen zudem die Synchronisierung von Helm-Charts und deren Anbindung an das Cluster.
Das Docker-Registry kann auf neue Versionen gescannt werden. Wenn ein neues Image verfügbar ist, werden das Git-Repository und das Deployment auf die neue Version aktualisiert.
Pull-Tools können in verschiedenen Namespaces mit unterschiedlichen Git-Repositories und Zugriffsrechten verteilt werden. Dadurch lässt sich ein multitenant-Modell umsetzen. Zum Beispiel kann Team A den Namespace A nutzen, Team B den Namespace B und das Infrastrukturteam kann den globalen Namespace verwenden.
In der Regel sind die Tools sehr leichtgewichtig.
In Kombination mit Tools wie dem Operator Bitnami Sealed Secrets, können Geheimnisse verschlüsselt im Git-Repository gespeichert und innerhalb des Clusters abgerufen werden.
Es besteht keine Verbindung zu CD-Pipelines, da die Bereitstellungen innerhalb des Clusters erfolgen.

Nachteile:

Die Verwaltung von Geheimnissen in Helm-Charts ist komplexer als bei herkömmlichen, da sie zunächst als so genannte sealed secrets generiert, dann von einem internen Operator entschlüsselt werden müssen und erst danach für das Pull-Tool verfügbar sind. Anschließend kann der Release in Helm mit den Werten aus den bereits implementierten Geheimnissen gestartet werden. Der einfachste Weg besteht darin, ein Geheimnis mit allen Helm-Werten, die für das Deployment verwendet werden, zu erstellen, es zu entschlüsseln und in Git zu committen.
Wenn Sie einen Pull-Ansatz anwenden, sind Sie an Tools gebunden, die mit Pulls arbeiten. Dies schränkt die Möglichkeit ein, den Deployment-Prozess im Cluster anzupassen. Zum Beispiel wird die Arbeit mit Kustomize dadurch erschwert, dass sie vor dem Zeitpunkt bearbeitet werden muss, an dem die endgültigen Vorlagen in Git eingehen. Ich sage nicht, dass separate Tools nicht verwendet werden können, aber sie sind schwieriger in den Deployment-Prozess zu integrieren.

Push-basierten Ansatz

GitOps: Vergleich von Pull- und Push-Methoden

Im Push-Ansatz initiiert ein externes System (vorwiegend CD-Pipelines) die Bereitstellungen im Cluster nach einem Commit im Git-Repository oder nach erfolgreichem Abschluss der vorherigen CI-Pipeline. In diesem Ansatz hat das System Zugriff auf das Cluster.

Vorteile:

Die Sicherheit wird durch das Git-Repository und die Build-Pipeline bestimmt.
Helm-Charts lassen sich einfacher bereitstellen, und es gibt Unterstützung für Helm-Plugins.
Die Verwaltung von Geheimnissen ist einfacher, da Geheimnisse in Pipelines angewendet und je nach Benutzerpräferenz verschlüsselt im Git gespeichert werden können.
Es gibt keine Bindung an ein spezifisches Tool, da verschiedene Typen verwendet werden können.
Container-Versionen können über die Build-Pipeline aktualisiert werden.

Nachteile:

Zugangsdaten zum Cluster befinden sich innerhalb des Build-Systems.
Das Aktualisieren von Containern in Deployments ist mit dem Pull-Prozess weiterhin einfacher.
Es besteht eine starke Abhängigkeit von der CD-System, da die benötigten Pipelines möglicherweise ursprünglich für Gitlab Runners geschrieben wurden und das Team dann entscheidet, zu Azure DevOps oder Jenkins zu wechseln… was eine Migration einer großen Anzahl von Build-Pipelines erforderlich macht.

Fazit: Push oder Pull?

Wie so oft hat jede Herangehensweise ihre Vor- und Nachteile. Einige Aufgaben lassen sich leichter mit einer Methode umsetzen, während andere eine andere Vorgehensweise erfordern. Zunächst habe ich Deployments manuell durchgeführt, aber nachdem ich auf einige Artikel über Weave Flux gestoßen bin, entschied ich mich, GitOps-Prozesse für alle Projekte einzuführen. Für die grundlegenden Templates war das einfach, doch dann stieß ich auf Herausforderungen im Umgang mit Helm-Charts. Zu dieser Zeit bot Weave Flux nur eine sehr rudimentäre Version des Helm Chart Operators an, aber selbst jetzt sind einige Aufgaben komplizierter, da man Geheimnisse manuell erstellen und anwenden muss. Man könnte sagen, dass der Pull-Ansatz viel sicherer ist, da die Cluster-Zugangsdaten außerhalb des Clusters nicht zugänglich sind, was die Sicherheit so sehr erhöht, dass sich der zusätzliche Aufwand lohnt.

Nach einigem Nachdenken bin ich zu einer unerwarteten Erkenntnis gekommen: Das ist nicht der Fall. Wenn man an die Komponenten denkt, die maximalen Schutz benötigen, würden Geheimspeicher und CI/CD-Systeme sowie Git-Repositories zu dieser Liste gehören. Die Informationen innerhalb dieser Systeme sind äußerst anfällig und benötigen den besten Schutz. Darüber hinaus, wenn jemand in Ihr Git-Repository eindringt und dort Code pushen kann, dann kann er alles bereitstellen, was er möchte (unabhängig davon, ob es sich um einen Pull- oder Push-Ansatz handelt) und in die Cluster-Systeme eindringen. Somit sind die wichtigsten Komponenten, die Schutz benötigen, das Git-Repository und die CI/CD-Systeme, nicht die Anmeldeinformationen des Clusters. Wenn Sie gut konfigurierte Sicherheitsrichtlinien und -maßnahmen für solche Systeme haben und die Anmeldeinformationen des Clusters nur in Form von Geheimnissen in die Pipelines einfließen, könnte die zusätzliche Sicherheit des Pull-Ansatzes weniger wertvoll sein als ursprünglich gedacht.

Wenn der Pull-Ansatz also arbeitsintensiver ist und keinen Sicherheitsgewinn bringt, wäre es dann nicht logisch, nur den Push-Ansatz zu verwenden? Aber jemand könnte argumentieren, dass man im Push-Ansatz zu sehr an ein CD-System gebunden ist und es möglicherweise besser ist, dies nicht zu tun, um zukünftige Migrationen zu erleichtern.

Meiner Meinung nach (wie immer) sollte man das verwenden, was am besten zum konkreten Fall passt, oder kombinieren. Persönlich nutze ich beide Ansätze: Weave Flux für Pull-basierte Deployments, die hauptsächlich unsere eigenen Dienste umfassen, und den Push-Ansatz mit Helm und Plugins, die die Anwendung von Helm-Charts im Cluster vereinfachen und die Erstellung von Secrets problemlos ermöglichen. Ich glaube, es wird nie eine universelle Lösung für alle Fälle geben, da es immer viele Nuancen gibt, die vom spezifischen Anwendungsfall abhängen. Dabei empfehle ich nachdrücklich GitOps – es erleichtert das Leben enorm und erhöht die Sicherheit.

Ich hoffe, dass meine Erfahrungen zu diesem Thema Ihnen helfen, zu entscheiden, welcher Ansatz am besten für Ihre Art von Deployments geeignet ist, und ich freue mich darauf, Ihre Meinung zu erfahren.

P.S. Hinweis des Übersetzers

Ein Nachteil des Pull-Modells ist, dass es schwierig ist, gerenderte Manifeste in Git abzulegen. Ein Vorteil ist jedoch, dass die CD-Pipeline im Pull-Modell unabhängig vom Rollout existiert und im Grunde zu einer Pipeline der Kategorie wird. Continuous ApplyDaher sind noch mehr Anstrengungen erforderlich, um den Status aller Deployments zu sammeln und einen Zugang zu Logs/Status zu gewähren, idealerweise verknüpft mit dem CD-System.

In diesem Sinne ermöglicht das Push-Modell zumindest gewisse Garantien für das Rollout, da die Lebensdauer der Pipeline mit der des Rollouts übereinstimmen kann.

Wir haben beide Modelle getestet und sind zu denselben Schlussfolgerungen gekommen wie der Autor des Artikels:

Das Pull-Modell eignet sich für die Aktualisierung von Systemkomponenten auf einer großen Anzahl von Clustern (siehe Artikel über den Addon-Operator).
Das Push-Modell basierend auf GitLab CI eignet sich gut für das Rollout von Anwendungen mithilfe von Helm-Charts. Dabei wird das Rollout der Deployments im Rahmen der Pipelines mit dem Tool überwacht werf. Übrigens hörten wir in diesem Projekt ständig den Begriff „GitOps“, als wir über die aktuellen Herausforderungen von DevOps-Ingenieuren an unserem Stand auf der KubeCon Europe’19 diskutierten.