Notiz. übersetzen: In der Kubernetes-Community erfreut sich ein Trend namens GitOps offensichtlich zunehmender Beliebtheit, wie wir persönlich gesehen haben. KubeCon Europe 2019. Dieser Begriff war relativ neu vom Leiter von Weaveworks – Alexis Richardson – und bedeutet die Verwendung von Tools, die Entwicklern bekannt sind (hauptsächlich Git, daher der Name), zur Lösung betrieblicher Probleme. Dabei geht es insbesondere um den Betrieb von Kubernetes durch die Speicherung seiner Konfigurationen in Git und die automatische Ausrollung von Änderungen im Cluster. Matthias Jg spricht in diesem Artikel über zwei Ansätze für diesen Rollout.
Im vergangenen Jahr (Tatsächlich geschah dies offiziell im August 2017 – ca. übersetzt.) Es gibt einen neuen Ansatz für die Bereitstellung von Anwendungen in Kubernetes. Es heißt GitOps und basiert auf der Grundidee, dass Bereitstellungsversionen in der sicheren Umgebung eines Git-Repositorys verfolgt werden.
Die Hauptvorteile dieses Ansatzes sind folgende::
- Bereitstellungsversionierung und Änderungsverlauf. Der Status des gesamten Clusters wird in einem Git-Repository gespeichert und Bereitstellungen werden nur durch Commits aktualisiert. Darüber hinaus können alle Änderungen anhand der Commit-Historie nachverfolgt werden.
- Rollbacks mit bekannten Git-Befehlen... Einfach
git resetermöglicht Ihnen, Änderungen in Bereitstellungen zurückzusetzen; Vergangene Zustände sind immer verfügbar. - Bereite Zugangskontrolle vor. Typischerweise enthält ein Git-System viele sensible Daten, daher legen die meisten Unternehmen besonderen Wert auf deren Schutz. Dementsprechend gilt dieser Schutz auch für Einsätze mit Einsätzen.
- Richtlinien für Bereitstellungen. Die meisten Git-Systeme unterstützen nativ Branch-by-Branch-Richtlinien – zum Beispiel können nur Pull-Requests den Master aktualisieren, und Änderungen müssen von einem anderen Teammitglied überprüft und akzeptiert werden. Wie bei der Zugriffskontrolle gelten für Bereitstellungsaktualisierungen dieselben Richtlinien.
Wie Sie sehen, bietet die GitOps-Methode viele Vorteile. Im vergangenen Jahr haben zwei Ansätze besonders an Popularität gewonnen. Das eine ist Push-basiert, das andere Pull-basiert. Bevor wir sie uns ansehen, werfen wir zunächst einen Blick darauf, wie typische Kubernetes-Bereitstellungen aussehen.
Bereitstellungsmethoden
In den letzten Jahren haben sich in Kubernetes verschiedene Methoden und Tools für Deployments etabliert:
- Basierend auf nativen Kubernetes/Kustomize-Vorlagen. Dies ist die einfachste Möglichkeit, Anwendungen auf Kubernetes bereitzustellen. Der Entwickler erstellt die grundlegenden YAML-Dateien und wendet sie an. Um das ständige Umschreiben derselben Vorlagen zu vermeiden, wurde Kustomize entwickelt (es wandelt Kubernetes-Vorlagen in Module um). Notiz. übersetzen: Kustomize wurde mit in kubectl integriert .
- Helmkarten. Mit Helm-Diagrammen können Sie Sätze von Vorlagen, Init-Containern, Sidecars usw. erstellen, die zur Bereitstellung von Anwendungen mit flexibleren Anpassungsoptionen als bei einem vorlagenbasierten Ansatz verwendet werden. Diese Methode basiert auf YAML-Vorlagendateien. Helm füllt sie mit verschiedenen Parametern und sendet sie dann an Tiller, eine Cluster-Komponente, die sie im Cluster bereitstellt und Updates und Rollbacks ermöglicht. Wichtig ist, dass Helm im Wesentlichen nur die gewünschten Werte in die Vorlagen einfügt und diese dann auf die gleiche Weise anwendet, wie es beim herkömmlichen Ansatz der Fall ist (Lesen Sie mehr darüber, wie das alles funktioniert und wie Sie es nutzen können in unserem - ca. übersetzt). Es gibt eine Vielzahl vorgefertigter Helm-Diagramme, die ein breites Aufgabenspektrum abdecken.
- Alternative Tools. Es gibt viele alternative Tools. Allen gemeinsam ist, dass sie einige Vorlagendateien in für Kubernetes lesbare YAML-Dateien umwandeln und diese dann verwenden.
Bei unserer Arbeit verwenden wir ständig Helm-Charts für wichtige Tools (da viele Dinge bereits bereit sind, was das Leben viel einfacher macht) und „reine“ Kubernetes-YAML-Dateien für die Bereitstellung unserer eigenen Anwendungen.
Ziehen drücken
In einem meiner letzten Blogbeiträge habe ich das Tool vorgestellt , mit dem Sie Vorlagen in das Git-Repository übertragen und die Bereitstellung nach jedem Commit oder Push des Containers aktualisieren können. Meine Erfahrung zeigt, dass dieses Tool eines der wichtigsten Instrumente zur Förderung des Pull-Ansatzes ist, daher werde ich oft darauf zurückgreifen. Wenn Sie mehr über die Verwendung erfahren möchten, klicken Sie hier .
NB! Alle Vorteile der Verwendung von GitOps bleiben für beide Ansätze gleich.
Pull-basierter Ansatz
Der Pull-Ansatz basiert auf der Tatsache, dass alle Änderungen innerhalb des Clusters angewendet werden. Innerhalb des Clusters gibt es einen Operator, der regelmäßig die zugehörigen Git- und Docker Registry-Repositorys überprüft. Wenn an ihnen Änderungen auftreten, wird der Status des Clusters intern aktualisiert. Dieser Vorgang gilt allgemein als sehr sicher, da kein externer Client Zugriff auf Cluster-Administratorrechte hat.
Profis:
- Kein externer Client hat das Recht, Änderungen am Cluster vorzunehmen; alle Aktualisierungen werden von innen heraus ausgerollt.
- Mit einigen Tools können Sie auch Helm-Chart-Updates synchronisieren und mit dem Cluster verknüpfen.
- Docker Registry kann nach neuen Versionen durchsucht werden. Wenn ein neues Image verfügbar ist, werden das Git-Repository und die Bereitstellung auf die neue Version aktualisiert.
- Pull-Tools können über verschiedene Namespaces mit unterschiedlichen Git-Repositorys und Berechtigungen verteilt werden. Dadurch kann ein Multitenant-Modell genutzt werden. Beispielsweise könnte Team A Namespace A verwenden, Team B könnte Namespace B verwenden und das Infrastrukturteam könnte globalen Speicherplatz verwenden.
- In der Regel sind die Werkzeuge sehr leicht.
- Kombiniert mit Tools wie Operator können Geheimnisse verschlüsselt in einem Git-Repository gespeichert und innerhalb des Clusters abgerufen werden.
- Es besteht keine Verbindung zu CD-Pipelines, da Bereitstellungen innerhalb des Clusters erfolgen.
Cons:
- Die Verwaltung von Bereitstellungsgeheimnissen aus Helm-Diagrammen ist schwieriger als bei normalen, da sie zunächst beispielsweise in Form versiegelter Geheimnisse generiert, dann von einem internen Operator entschlüsselt werden müssen und erst danach für das Pull-Tool verfügbar sind. Anschließend können Sie die Veröffentlichung in Helm mit den Werten in den bereits bereitgestellten Geheimnissen ausführen. Der einfachste Weg besteht darin, ein Geheimnis mit allen für die Bereitstellung verwendeten Helm-Werten zu erstellen, es zu entschlüsseln und an Git zu übergeben.
- Wenn Sie einen Pull-Ansatz wählen, sind Sie an Pull-Tools gebunden. Dies schränkt die Möglichkeit ein, den Bereitstellungsprozess in einem Cluster anzupassen. Kustomize ist beispielsweise dadurch kompliziert, dass es ausgeführt werden muss, bevor die endgültigen Vorlagen an Git übergeben werden. Ich sage nicht, dass Sie keine eigenständigen Tools verwenden können, aber es ist schwieriger, sie in Ihren Bereitstellungsprozess zu integrieren.
Push-basierter Ansatz
Beim Push-Ansatz startet ein externes System (hauptsächlich CD-Pipelines) Bereitstellungen für den Cluster, nachdem ein Commit in das Git-Repository erfolgt ist oder wenn die vorherige CI-Pipeline erfolgreich war. Bei diesem Ansatz hat das System Zugriff auf den Cluster.
Pros:
- Die Sicherheit wird durch das Git-Repository und die Build-Pipeline bestimmt.
- Die Bereitstellung von Helm-Charts ist einfacher und unterstützt Helm-Plugins.
- Secrets sind einfacher zu verwalten, da Secrets in Pipelines verwendet und auch verschlüsselt in Git gespeichert werden können (abhängig von den Präferenzen des Benutzers).
- Es besteht keine Bindung an ein bestimmtes Werkzeug, da jeder Typ verwendet werden kann.
- Aktualisierungen der Containerversion können von der Build-Pipeline initiiert werden.
Cons:
- Die Cluster-Zugriffsdaten liegen im Build-System.
- Das Aktualisieren von Bereitstellungscontainern ist mit einem Pull-Prozess noch einfacher.
- Starke Abhängigkeit vom CD-System, da die von uns benötigten Pipelines möglicherweise ursprünglich für Gitlab Runners geschrieben wurden und sich das Team dann für den Wechsel zu Azure DevOps oder Jenkins entscheidet ... und eine große Anzahl von Build-Pipelines migrieren muss.
Ergebnisse: Push oder Pull?
Wie so oft hat jeder Ansatz seine Vor- und Nachteile. Manche Aufgaben sind mit dem einen einfacher und mit dem anderen schwieriger zu erledigen. Zuerst habe ich die Bereitstellung manuell durchgeführt, aber nachdem ich auf einige Artikel über Weave Flux gestoßen bin, habe ich beschlossen, GitOps-Prozesse für alle Projekte zu implementieren. Bei einfachen Vorlagen war das einfach, aber dann bekam ich Schwierigkeiten mit Helm-Diagrammen. Damals bot Weave Flux nur eine rudimentäre Version des Helm Chart Operators an, aber auch heute noch sind einige Aufgaben schwieriger, da Geheimnisse manuell erstellt und angewendet werden müssen. Man könnte argumentieren, dass der Pull-Ansatz viel sicherer ist, da auf die Anmeldeinformationen des Clusters außerhalb des Clusters nicht zugegriffen werden kann, was ihn so viel sicherer macht, dass sich der zusätzliche Aufwand lohnt.
Nach einigem Nachdenken kam ich zu dem unerwarteten Schluss, dass dem nicht so ist. Wenn wir über Komponenten sprechen, die maximalen Schutz erfordern, umfasst diese Liste geheime Speicher, CI/CD-Systeme und Git-Repositorys. Die darin enthaltenen Informationen sind sehr anfällig und benötigen maximalen Schutz. Wenn außerdem jemand in Ihr Git-Repository gelangt und dort Code pushen kann, kann er alles bereitstellen, was er möchte (sei es Pull oder Push) und die Systeme des Clusters infiltrieren. Daher sind die wichtigsten Komponenten, die geschützt werden müssen, das Git-Repository und die CI/CD-Systeme, nicht die Cluster-Anmeldeinformationen. Wenn Sie über gut konfigurierte Richtlinien und Sicherheitskontrollen für diese Art von Systemen verfügen und Cluster-Anmeldeinformationen nur als Geheimnisse in Pipelines extrahiert werden, ist die zusätzliche Sicherheit eines Pull-Ansatzes möglicherweise nicht so wertvoll wie ursprünglich angenommen.
Wenn also der Pull-Ansatz arbeitsintensiver ist und keinen Sicherheitsvorteil bietet, ist es dann nicht logisch, nur den Push-Ansatz zu verwenden? Aber jemand könnte argumentieren, dass man beim Push-Ansatz zu sehr an das CD-System gebunden ist und es vielleicht besser ist, dies nicht zu tun, damit es in Zukunft einfacher ist, Migrationen durchzuführen.
Meiner Meinung nach sollte man (wie immer) das verwenden, was für den jeweiligen Fall am besten geeignet ist, bzw. kombinieren. Persönlich verwende ich beide Ansätze: Weave Flux für Pull-basierte Bereitstellungen, die größtenteils unsere eigenen Dienste umfassen, und einen Push-Ansatz mit Helm und Plugins, der es einfach macht, Helm-Charts auf den Cluster anzuwenden und es Ihnen ermöglicht, nahtlos Geheimnisse zu erstellen. Ich denke, dass es nie eine einheitliche Lösung geben wird, die für alle Fälle geeignet ist, da es immer viele Nuancen gibt und diese von der konkreten Anwendung abhängen. Trotzdem kann ich GitOps wärmstens empfehlen – es macht das Leben viel einfacher und verbessert die Sicherheit.
Ich hoffe, dass meine Erfahrung zu diesem Thema Ihnen bei der Entscheidung helfen wird, welche Methode für Ihre Art des Einsatzes besser geeignet ist, und würde mich über Ihre Meinung freuen.
PS-Hinweis des Übersetzers
Der Nachteil des Pull-Modells besteht darin, dass es schwierig ist, gerenderte Manifeste in Git einzufügen. Es besteht jedoch kein Nachteil darin, dass die CD-Pipeline im Pull-Modell getrennt vom Rollout existiert und im Wesentlichen zu einer Kategorie-Pipeline wird Kontinuierliche Bewerbung. Daher wird noch mehr Aufwand erforderlich sein, um deren Status von allen Bereitstellungen zu erfassen und irgendwie Zugriff auf Protokolle/Status bereitzustellen, vorzugsweise mit Bezug auf das CD-System.
In diesem Sinne ermöglicht uns das Push-Modell, zumindest einige Garantien für den Rollout zu bieten, da die Lebensdauer der Pipeline der Lebensdauer des Rollouts angeglichen werden kann.
Wir haben beide Modelle ausprobiert und sind zu den gleichen Ergebnissen gekommen wie der Autor des Artikels:
- Das Pull-Modell eignet sich für uns, um Updates von Systemkomponenten auf einer großen Anzahl von Clustern zu organisieren (siehe. ).
- Das auf GitLab CI basierende Push-Modell eignet sich gut zum Ausrollen von Anwendungen mithilfe von Helm-Charts. Gleichzeitig wird mit dem Tool der Rollout von Deployments innerhalb von Pipelines überwacht . Übrigens haben wir im Rahmen unseres Projekts das ständige „GitOps“ gehört, als wir an unserem Stand auf der KubeCon Europe'19 über die drängenden Probleme der DevOps-Ingenieure diskutierten.
PPS vom Übersetzer
Lesen Sie auch auf unserem Blog:
- «";
- «";
- «";
- «".
An der Umfrage können nur registrierte Benutzer teilnehmen. bitte.
Verwenden Sie GitOps?
-
Ja, Pull-Ansatz
-
Ja, drücken
-
Ja, ziehen + drücken
-
Ja, etwas anderes
-
Nein
30 Benutzer haben abgestimmt. 10 Benutzer enthielten sich der Stimme.
Source: habr.com