🥇GitOps: Vergleich von Pull- und Push-Methoden

Anmerkung des Übersetzers.: In der Kubernetes-Community gewinnt der Trend namens GitOps zunehmend an Beliebtheit, was wir persönlich festgestellt haben, bei KubeCon Europe 2019. Dieser Begriff wurde relativ neu von Alexis Richardson, dem Geschäftsführer von Weaveworks, geprägt und bedeutet die Anwendung von Werkzeugen, die Entwicklern vertraut sind (vor allem Git, daher der Name), zur Lösung von Betriebsaufgaben. 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 Bereitstellung berichtet Matthias Jg in diesem Artikel.

GitOps: Vergleich der Pull- und Push-Methoden

Im vergangenen Jahr (tatsächlich geschah dies formal im August 2017 – Anmerkung des Übersetzers) kam ein neuer Ansatz für die Bereitstellung von Anwendungen in Kubernetes auf. Er heißt GitOps und basiert auf der grundlegenden Vorstellung, dass die Versionierung der Deployments in einer sicheren Umgebung des Git-Repositories verfolgt wird.

Die wichtigsten Vorteile dieses Ansatzes sind:

Die Versionierung von Deployments und die Historie der Änderungen. 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 Historie der Commits nachverfolgt werden.
Rückrolls mit den gewohnten Git-Befehlen. Einfach git reset erlaubt das Zurücksetzen von Änderungen in den Deployments; frühere Zustände sind jederzeit verfügbar.
Fertige Zugriffskontrolle. In der Regel enthält das Git-System viele vertrauliche Daten, daher legen die meisten Unternehmen besonderen Wert auf dessen Sicherheit. Entsprechend erstreckt sich dieser Schutz auch auf die Operationen mit Deployments.
Richtlinien für Bereitstellungen. 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 genehmigt werden. Wie bei der Zugriffskontrolle gelten dieselben Richtlinien auch für die Aktualisierungen der Deployments.

Wie Sie sehen, bietet die GitOps-Methode zahlreiche Vorteile. Im vergangenen Jahr sind zwei Ansätze besonders populär geworden. Der eine basiert auf Push, der andere auf Pull. Bevor wir uns diese genauer ansehen, lassen Sie uns zunächst anschauen, wie typische Deployments in Kubernetes aussehen.

Methoden zur Bereitstellung

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

Basierend auf nativen Kubernetes-/Kustomize-Vorlagen. Dies ist der einfachste Weg, Anwendungen in Kubernetes bereitzustellen. Der Entwickler erstellt grundlegende YAML-Dateien und wendet sie an. Um das ständige Neubeschreiben derselben Vorlagen zu vermeiden, wurde Kustomize entwickelt (es verwandelt Kubernetes-Vorlagen in Module). Anmerkung des Übersetzers.: Kustomize wurde mit dem Release von Kubernetes 1.14.
Helm-Charts. Helm-Charts ermöglichen die Erstellung von Vorlagensets, Init-Containern, Sidecars usw., die für die Bereitstellung von Anwendungen mit flexibleren Anpassungsmöglichkeiten als beim vorlagenbasierten Ansatz verwendet werden. Das Fundament dieser Methode bilden templatisierte YAML-Dateien. Helm füllt sie mit verschiedenen Parametern aus und sendet sie dann an Tiller – die Cluster-Komponente, die sie im Cluster bereitstellt und Updates sowie Rollbacks ermöglicht. Wichtig ist, dass Helm im Wesentlichen einfach die erforderlichen Werte in die Vorlagen einfügt und diese dann auf die gleiche Weise anwendet, wie es im traditionellen Ansatz geschieht. (Mehr darüber, wie das alles funktioniert und wie man es verwenden kann, lesen Sie in unserem Artikel über Helm — Anm. d. Übersetzer). Es gibt eine große Vielfalt an verfügbaren Helm-Charts, die ein breites Spektrum von Aufgaben abdecken.
Alternative Werkzeuge. Es gibt viele alternative Werkzeuge. Alle vereint, dass sie bestimmte Template-Dateien in verständliche Kubernetes YAML-Dateien umwandeln und diese dann anwenden.

In unserer Arbeit nutzen wir ständig Helm-Charts für wichtige Tools (da sie viele bereits vorbereitete Elemente enthalten, die das Leben erheblich erleichtern) sowie „reine“ Kubernetes YAML-Dateien zur Bereitstellung unserer eigenen Anwendungen.

Pull & Push

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

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

Pull-basierter Ansatz

GitOps: Vergleich der Pull- und Push-Methoden

Der Ansatz des Pull-Systems basiert auf der Tatsache, dass alle Änderungen aus dem Inneren des Clusters angewendet werden. Innerhalb des Clusters gibt es einen Operator, der regelmäßig die verbundenen Git- und Docker-Registry-Repositories überprüft. Wenn dort Änderungen auftreten, wird der Zustand des Clusters von innen aktualisiert. Man geht normalerweise davon aus, dass ein solches Verfahren recht sicher ist, da kein externes Client-System Administratorrechte für das Cluster hat.

Vorteile:

Kein externes Client-System hat das Recht, Änderungen am Cluster vorzunehmen; alle Aktualisierungen werden von innen angewendet.
Einige Werkzeuge ermöglichen es auch, Updates von Helm-Charts zu synchronisieren und sie mit dem Cluster zu verknüpfen.
Die Docker-Registry kann auf neue Versionen gescannt werden. Wenn ein neues Image verfügbar wird, werden das Git-Repository und das Deployment auf die neue Version aktualisiert.
Pull-Tools können über verschiedene Namensräume mit unterschiedlichen Git-Repositories und Zugriffsrechten verteilt werden. Dadurch kann ein Multi-Tenant-Modell implementiert werden. Zum Beispiel kann Team A den Namensraum A verwenden, Team B den Namensraum B, während das Infrastrukturteam den globalen Namensraum nutzen kann.
In der Regel sind die Tools sehr leichtgewichtig.
In Kombination mit Werkzeugen wie dem Operator Bitnami Sealed Secrets, können Geheimnisse in verschlüsselter Form im Git-Repository gespeichert und im Cluster abgerufen werden.
Es besteht keine Verbindung zu CD-Pipelines, da die Deployments innerhalb des Clusters stattfinden.

Nachteile:

Die Verwaltung der Geheimnisse von Deployments aus Helm-Charts ist komplizierter als bei normalen Geheimnissen, da sie zunächst in Form von beispielsweise sealed secrets generiert und dann vom internen Operator entschlüsselt werden müssen, bevor sie für das Pull-Tool verfügbar sind. Anschließend kann ein Release in Helm mit den Werten der bereits bereitgestellten Geheimnisse gestartet werden. Der einfachste Weg besteht darin, ein Geheimnis mit allen Helm-Werten zu erstellen, die für das Deployment verwendet werden, es zu entschlüsseln und in Git zu committen.
Bei der Anwendung des Pull-Ansatzes sind Sie an Werkzeuge gebunden, die mit Pulls arbeiten. Dies schränkt die Möglichkeit ein, den Bereitstellungsprozess von Deployments im Cluster anzupassen. Zum Beispiel wird die Arbeit mit Kustomize dadurch erschwert, dass es vor dem Eintreffen der endgültigen Vorlagen in Git ausgeführt werden muss. Ich sage nicht, dass man keine separaten Werkzeuge verwenden kann, aber sie sind schwieriger in den Bereitstellungsprozess zu integrieren.

Push-basierter Ansatz

GitOps: Vergleich der Pull- und Push-Methoden

Im Push-Ansatz startet ein externes System (hauptsächlich CD-Pipelines) die Bereitstellungen im Cluster nach dem Commit im Git-Repository oder im Falle eines erfolgreichen Abschlusses der vorherigen CI-Pipeline. In diesem Ansatz hat das System Zugriff auf den Cluster.

Vorteile:

Die Sicherheit wird durch das Git-Repository und die Build-Pipeline definiert.
Das Bereitstellen von Helm-Charts ist einfacher, da es Unterstützung für Helm-Plugins gibt.
Das Verwalten von Geheimnissen ist einfacher, da Geheimnisse in den Pipelines angewendet und auch verschlüsselt in Git gespeichert werden können (je nach den Vorlieben des Benutzers).
Keine Bindung an ein bestimmtes Werkzeug, da verschiedene Arten verwendet werden können.
Container-Versionen können durch die Build-Pipeline aktualisiert werden.

Nachteile:

Die Daten für den Zugriff auf den Cluster befinden sich im Build-System.
Die Aktualisierung von Container-Deployments ist weiterhin einfacher mit dem Pull-Prozess.
Starke Abhängigkeit vom CD-System, da die benötigten Pipelines möglicherweise ursprünglich für Gitlab Runners geschrieben wurden, und das Team dann beschließt, auf Azure DevOps oder Jenkins umzusteigen... und eine Migration einer großen Anzahl von Build-Pipelines erforderlich ist.

Fazit: Push oder Pull?

Wie üblich hat jeder Ansatz seine eigenen Vor- und Nachteile. Einige Aufgaben lassen sich mit dem einen Ansatz leichter umsetzen, mit dem anderen hingegen schwieriger. Zu Beginn habe ich die Bereitstellungen manuell durchgeführt, aber nachdem ich auf einige Artikel über Weave Flux gestoßen bin, beschloss ich, GitOps-Prozesse für alle Projekte einzuführen. Für grundlegende Vorlagen stellte sich das als einfach heraus, aber später begann ich, Schwierigkeiten im Umgang mit Helm-Charts zu haben. Zu dieser Zeit bot Weave Flux nur eine embryonale Version des Helm Chart Operators an, aber selbst jetzt sind einige Aufgaben schwieriger, da man Geheimnisse manuell erstellen und anwenden muss. Man könnte sagen, dass der Pull-Ansatz viel sicherer ist, da die Cluster-Anmeldeinformationen außerhalb des Clusters nicht zugänglich sind, was die Sicherheit so sehr erhöht, dass es die zusätzlichen Anstrengungen wert ist.

Nach ein wenig Überlegung kam ich zu dem unerwarteten Schluss, dass dem nicht so ist. Wenn es um Komponenten geht, die maximale Sicherheit erfordern, gehören zu dieser Liste Geheimnis-Speichersysteme und CI/CD-Systeme sowie Git-Repositories. Die Informationen in ihnen sind ziemlich anfällig und benötigen maximalen Schutz. Darüber hinaus, wenn jemand in Ihr Git-Repository eindringt und in der Lage ist, dort Code zu pushen, kann er alles bereitstellen, was er möchte (unabhängig davon, ob es sich um einen Pull- oder Push-Ansatz handelt) und in die Systeme des Clusters eindringen. Daher sind die wichtigsten Komponenten, die Schutz benötigen, das Git-Repository und die CI/CD-Systeme, nicht die Cluster-Anmeldeinformationen. Wenn Sie Sicherheitsrichtlinien und -maßnahmen für solche Systeme gut eingerichtet haben und die Cluster-Anmeldeinformationen in Pipelines nur als Geheimnisse abgerufen werden, könnte die zusätzliche Sicherheit des Pull-Ansatzes weniger wertvoll sein als zunächst angenommen.

Also, wenn der Pull-Ansatz arbeitsintensiver ist und keinen Sicherheitsvorteil bietet, wäre es dann nicht sinnvoll, nur den Push-Ansatz zu verwenden? Aber jemand könnte argumentieren, dass man im Push-Ansatz zu sehr an das CD-System gebunden ist und es möglicherweise besser wäre, das nicht zu tun, um in Zukunft Migrationen zu erleichtern.

Meiner Meinung nach (wie immer) sollten wir das verwenden, was am besten zum jeweiligen Fall passt, oder beides kombinieren. Persönlich nutze ich beide Ansätze: Weave Flux für Pull-basierte Deployments, die überwiegend unsere eigenen Services einbeziehen, und den Push-Ansatz mit Helm und Plugins, der es vereinfacht, Helm-Charts an den Cluster anzuwenden und Sekrete problemlos zu erstellen. Ich denke, es wird niemals eine universelle Lösung geben, die für alle Fälle geeignet ist, da es immer viele Nuancen gibt, die von der konkreten Anwendung abhängen. Dabei empfehle ich dringend GitOps – es erleichtert das Leben erheblich und verbessert die Sicherheit.

Ich hoffe, dass meine Erfahrungen zu diesem Thema Ihnen helfen, zu entscheiden, welche Methode 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 zu legen, es gibt jedoch keinen Nachteil, dass die CD-Pipeline im Pull-Modell separat vom Deployment existiert und somit zu einer Pipeline der Kategorie wird Continuous Apply. Daher wird es noch mehr Aufwand erfordern, um den Status aller Deployments zu sammeln und irgendwie Zugriff auf Logs/Status zu gewähren, wobei dies idealerweise an das CD-System gebunden sein sollte.

In dieser Hinsicht ermöglicht das Push-Modell, zumindest gewisse Garantien für das Deployment zu geben, da die Lebensdauer der Pipeline gleich der Lebensdauer des Deployments sein kann.

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

Das Pull-Modell eignet sich für die Organisation von Aktualisierungen systemrelevanter Komponenten in einer großen Anzahl von Clustern (siehe den Artikel über den Addon-Operator).
Das Push-Modell auf Basis GitLab CI eignet sich gut für Deployments von Anwendungen mithilfe von Helm-Charts. Dabei wird der Deployment-Prozess im Rahmen der Pipelines mit dem Tool werfverfolgt. Übrigens hörten wir im Kontext dieses Projekts ständig "GitOps", als wir die dringenden Probleme der DevOps-Ingenieure an unserem Stand auf der KubeCon Europe'19 diskutierten.