Hinweis perev. : In der Kubernetes-Community gewinnt ein Trend namens GitOps an Popularität, wie wir persönlich beim Besuch der KubeCon Europe 2019 gesehen haben. Dieser Begriff wurde vor relativ kurzer Zeit vom Leiter von Weaveworks - Alexis Richardson - geprägt und bedeutet die Verwendung bekannter Tools für Entwickler (hauptsächlich Git, woher der Name selbst) zur Lösung von Betriebsproblemen. Insbesondere geht es darum, Kubernetes auszunutzen, indem seine Konfigurationen in Git gespeichert und Änderungen am Cluster automatisch eingeführt werden. Matthias Jg spricht in diesem Artikel über zwei Ansätze für diesen Rollout.
Letztes Jahr
(tatsächlich geschah dies offiziell im August 2017 - ungefähr übersetzt) wurde ein neuer Ansatz für die Bereitstellung von Anwendungen in Kubernetes vorgestellt. Es heißt GitOps und basiert auf der Grundidee, dass die Versionsverfolgung von Bereitstellungen in einer sicheren Git-Repository-Umgebung erfolgt.
Die Hauptvorteile dieses Ansatzes sind folgende :
- Versionierung von Bereitstellungen und Änderungsverlauf . Der Status des gesamten Clusters wird im Git-Repository gespeichert, und Bereitstellungen werden nur durch Commits aktualisiert. Darüber hinaus können alle Änderungen mithilfe des Festschreibungsverlaufs verfolgt werden.
- Kickbacks mit bekannten Git-Befehlen . Mit einem einfachen
git reset können Sie Änderungen in der Bereitstellung verwerfen. vergangene Zustände sind immer verfügbar. - Bereit Zugriffskontrolle . In der Regel enthält ein Git-System viele vertrauliche Daten, daher achten die meisten Unternehmen besonders auf deren Schutz. Dementsprechend erstreckt sich dieser Schutz auf Vorgänge mit Bereitstellungen.
- Richtlinien für Bereitstellungen . Die meisten Git-Systeme unterstützen zunächst Richtlinien für verschiedene Zweige. Beispielsweise können nur Pull-Anforderungen den Master aktualisieren, und ein anderes Mitglied des Teams muss die Änderungen überprüfen und akzeptieren. Wie bei der Zugriffssteuerung gelten für Bereitstellungsaktualisierungen dieselben Richtlinien.
Wie Sie sehen können, hat die GitOps-Methode viele Vorteile. Im vergangenen Jahr haben zwei Ansätze besondere Popularität erlangt. Einer basiert auf Push, der andere auf Pull. Bevor wir uns diese ansehen, schauen wir uns zunächst an, wie typische Kubernetes-Bereitstellungen aussehen.
Bereitstellungsmethoden
In den letzten Jahren wurden bei Kubernetes verschiedene Bereitstellungsmethoden und -tools eingerichtet:
- Basierend auf nativen Kubernetes / Kustomize-Vorlagen . Dies ist der einfachste Weg, um Anwendungen auf Kubernetes bereitzustellen. Der Entwickler erstellt die grundlegenden YAML-Dateien und wendet sie an. Um das ständige Umschreiben derselben Muster zu vermeiden, wurde Kustomize entwickelt (es verwandelt Kubernetes-Muster in Module). Hinweis perev. : Kustomize wurde mit der Veröffentlichung von Kubernetes 1.14 in kubectl integriert.
- Charts Helm . Mithilfe von Helmdiagrammen können Sie Sätze von Vorlagen, Init-Containern, Sidecar'ov usw. erstellen, mit denen Anwendungen mit flexibleren Konfigurationsoptionen als beim vorlagenbasierten Ansatz bereitgestellt werden. Diese Methode basiert auf YAML-Vorlagendateien. Helm füllt sie mit verschiedenen Parametern und sendet sie dann an Tiller, die Clusterkomponente, die sie im Cluster bereitstellt und Aktualisierungen und Rollbacks ermöglicht. Wichtig ist, dass Helm die erforderlichen Werte einfach in die Vorlagen einfügt und sie dann auf die gleiche Weise wie beim herkömmlichen Ansatz anwendet (weitere Informationen dazu, wie dies alles funktioniert und wie Sie es verwenden können, finden Sie in unserem Artikel über Helm - ca. .) . Es gibt eine Vielzahl von vorgefertigten Helmkarten, die eine Vielzahl von Aufgaben abdecken.
- Alternative Werkzeuge . Es gibt viele alternative Werkzeuge. Alle sind sich einig, dass sie einige Vorlagendateien in Kubernetes-freundliche YAML-Dateien umwandeln und sie dann anwenden.
In unserer Arbeit verwenden wir ständig Helm-Diagramme für wichtige Tools (da viele bereits bereit sind, was das Leben erheblich vereinfacht) und Kubernetes „saubere“ YAML-Dateien für die Bereitstellung unserer eigenen Anwendungen.
Ziehen und drücken
In einem meiner letzten Blog-Beiträge habe ich das
Weave Flux- Tool vorgestellt, mit dem Sie Vorlagen für das Git-Repository festschreiben und die Bereitstellung nach jedem Festschreibungs- oder Push-Container aktualisieren können. Meine Erfahrung zeigt, dass dieses Tool eines der Hauptinstrumente bei der Förderung des Pull-Ansatzes ist, daher werde ich häufig darauf verweisen. Wenn Sie mehr über die Verwendung erfahren möchten, finden Sie hier einen
Link zum Artikel .
NB! Alle Vorteile der Verwendung von GitOps bleiben für beide Ansätze erhalten.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-Registrierungsrepositorys überprüft. Wenn Änderungen an ihnen auftreten, wird der Status des Clusters intern aktualisiert. Es wird normalerweise angenommen, dass ein solcher Prozess sehr sicher ist, da kein externer Client Zugriff auf Clusteradministratorrechte hat.
Vorteile:- Kein externer Client hat das Recht, Änderungen am Cluster vorzunehmen. Alle Aktualisierungen werden von innen ausgeführt.
- Mit einigen Tools können Sie auch Aktualisierungen von Helm-Diagrammen synchronisieren und an einen Cluster binden.
- Die Docker-Registrierung kann nach neuen Versionen durchsucht werden. Wenn ein neues Image angezeigt wird, werden das Git-Repository und die Bereitstellung auf die neue Version aktualisiert.
- Pull-Tools können mit unterschiedlichen Git-Repositorys und Berechtigungen auf verschiedene Namespaces verteilt werden. Dank dessen ist es möglich, das Multitenant-Modell zu verwenden. Beispielsweise kann Team A den Namespace A verwenden, Team B den Namespace B und ein Infrastruktur-Team den globalen Speicherplatz.
- Werkzeuge sind in der Regel sehr leicht.
- In Kombination mit Tools wie der Bitnami Sealed Secrets- Anweisung können Geheimnisse verschlüsselt im Git-Repository gespeichert und im Cluster abgerufen werden.
- Es gibt keine Kommunikation mit CD-Pipelines, da Bereitstellungen innerhalb des Clusters erfolgen.
Nachteile :
- Das Verwalten von Bereitstellungsgeheimnissen aus Helmdiagrammen ist komplizierter als gewöhnlich, da Sie sie zuerst in beispielsweise versiegelten Geheimnissen generieren, dann mit einem internen Operator entschlüsseln müssen und erst danach für das Pull-Tool verfügbar werden. Anschließend können Sie die Version in Helm mit Werten in bereits bereitgestellten Geheimnissen starten. Am einfachsten ist es, ein Geheimnis mit allen für die Bereitstellung verwendeten Helmwerten zu erstellen, es zu entschlüsseln und in Git festzuschreiben.
- Bei Verwendung des Pull-Ansatzes sind Sie an Werkzeuge gebunden, die mit Pulls arbeiten. Dies schränkt die Möglichkeit ein, den Bereitstellungsbereitstellungsprozess im Cluster anzupassen. Die Arbeit mit Kustomize wird beispielsweise dadurch erschwert, dass es ausgeführt werden muss, bevor die endgültigen Vorlagen in Git eintreffen. Ich sage nicht, dass Sie keine einzelnen Tools verwenden können, aber sie sind schwieriger in den Bereitstellungsprozess zu integrieren.
Push-basierter Ansatz
Beim Push-Ansatz wird ein externes System (hauptsächlich CD-Pipelines) nach dem Festschreiben im Git-Repository oder bei erfolgreicher Ausführung der vorherigen CI-Pipeline mit der Bereitstellung im Cluster begonnen. Bei diesem Ansatz hat das System Zugriff auf den Cluster.
Vorteile :
- Die Sicherheit wird vom Git-Repository und der Build-Pipeline bestimmt.
- Das Bereitstellen von Helm-Diagrammen ist einfacher, Helm-Plugins werden unterstützt.
- Geheimnisse sind einfacher zu verwalten, da Geheimnisse in Pipelines verwendet und in Git in verschlüsselter Form gespeichert werden können (abhängig von den Vorlieben des Benutzers).
- Fehlende Bindung an ein bestimmtes Werkzeug, da jeder ihrer Typen verwendet werden kann.
- Aktualisierungen der Containerversion können von der Assembly-Pipeline ausgelöst werden.
Nachteile :
- Die Daten für den Zugriff auf den Cluster befinden sich im Build-System.
- Das Aktualisieren von Bereitstellungscontainern ist mit dem Pull-Prozess noch einfacher.
- Dies hängt stark vom CD-System ab, da die benötigten Pipelines wahrscheinlich ursprünglich für Gitlab Runners geschrieben wurden. Anschließend entscheidet sich das Team für den Wechsel zu Azure DevOps oder Jenkins. Sie müssen dann eine große Anzahl von Build-Pipelines migrieren.
Fazit: Push oder Pull?
Wie üblich hat jeder Ansatz seine Vor- und Nachteile. Einige Aufgaben sind mit der einen leichter zu erledigen und mit der anderen schwieriger. Zuerst habe ich Bereitstellungen manuell ausgegeben, aber nachdem ich auf mehrere Artikel über Weave Flux gestoßen war, habe ich beschlossen, GitOps-Prozesse für alle Projekte zu implementieren. Bei einfachen Vorlagen stellte sich heraus, dass dies einfach war, aber dann bekam ich Schwierigkeiten bei der Arbeit mit Helm-Diagrammen. Zu dieser Zeit bot Weave Flux nur eine rudimentäre Version des Helmdiagramm-Operators an, aber selbst jetzt sind einige Aufgaben komplizierter, da Geheimnisse manuell erstellt und angewendet werden müssen. Sie können sagen, dass der Pull-Ansatz viel sicherer ist, da die Cluster-Anmeldeinformationen außerhalb nicht verfügbar sind, und dies erhöht die Sicherheit so sehr, dass es zusätzlichen Aufwand kostet.
Nachdem ich ein bisschen nachgedacht hatte, kam ich zu dem unerwarteten Schluss, dass dies nicht so ist. Wenn wir über Komponenten sprechen, die maximalen Schutz erfordern, enthält diese Liste die Speicherung von Geheimnissen und CI / CD-Systemen sowie Git-Repositorys. Die darin enthaltenen Informationen sind sehr anfällig und benötigen maximalen Schutz. Wenn jemand Ihr Git-Repository betritt und den Code dort pushen kann, kann er außerdem alles bereitstellen, was er will (unabhängig vom gewählten Ansatz wird es Pull oder Push sein) und die Clustersysteme 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 abgestimmte Richtlinien und Sicherheitsmaßnahmen für Systeme dieses Typs verfügen und Cluster-Anmeldeinformationen nur als Geheimnisse in Pipes abgerufen werden, ist die zusätzliche Sicherheit des Pull-Ansatzes möglicherweise nicht so wertvoll wie ursprünglich beabsichtigt.
Wenn der Pull-Ansatz zeitaufwändiger ist und keinen Sicherheitsgewinn bringt, ist es dann nicht logisch, nur den Push-Ansatz zu verwenden? Aber vielleicht sagt jemand, dass Sie beim Push-Ansatz zu sehr an das CD-System gebunden sind, und vielleicht ist es besser, dies nicht zu tun, um Migrationen in Zukunft einfacher zu machen.
Meiner Meinung nach sollten Sie (wie immer) das verwenden, was für einen bestimmten Fall besser geeignet ist, oder kombinieren. Persönlich verwende ich beide Ansätze: Weave Flux für Pull-basierte Bereitstellungen, die hauptsächlich unsere eigenen Dienste umfassen, und einen Push-Ansatz mit Helm und Plugins, der die Anwendung von Helm-Diagrammen auf den Cluster vereinfacht und es Ihnen ermöglicht, auf einfache Weise Geheimnisse zu erstellen. Ich denke, es wird nie eine einzige Lösung geben, die für alle Fälle geeignet ist, da es immer viele Nuancen gibt und diese von der spezifischen Anwendung abhängen. Gleichzeitig empfehle ich GitOps sehr - es vereinfacht das Leben erheblich und verbessert die Sicherheit.
Ich hoffe, dass meine Erfahrung zu diesem Thema dazu beiträgt, festzustellen, welche Methode für Ihre Art der Bereitstellung besser geeignet ist, und ich freue mich über Ihre Meinung.
PS Hinweis vom Übersetzer
In den Minuspunkten des Pull-Modells gibt es einen Punkt darüber, dass es schwierig ist, gerenderte Manifeste in Git zu platzieren. Es gibt jedoch kein Minus, dass die CD-Pipeline im Pull-Modell getrennt vom Rollout lebt und tatsächlich zu einer
Pipeline für die Kategorie "
Kontinuierliches Anwenden " wird. Daher sind noch weitere Anstrengungen erforderlich, um ihren Status aus allen Bereitstellungen zu erfassen und irgendwie Zugriff auf die Protokolle / den Status zu gewähren, vorzugsweise in Bezug auf das CD-System.
In diesem Sinne können Sie mit dem Push-Modell zumindest eine gewisse Garantie für den Rollout geben, da die Lebensdauer der Pipeline der Rollout-Lebensdauer entsprechen kann.
Wir haben beide Modelle getestet und sind zu den gleichen Ergebnissen gekommen wie der Autor des Artikels:
- Das Pull-Modell eignet sich für uns zum Organisieren von Systemkomponentenaktualisierungen in einer großen Anzahl von Clustern (siehe Artikel über Addon-Operator ).
- Das GitLab CI-basierte Push-Modell eignet sich gut für die Einführung von Anwendungen mithilfe von Helm-Diagrammen. In diesem Rollout wird die Bereitstellung innerhalb der Pipelines mit dem werf- Tool überwacht. Übrigens haben wir im Rahmen unseres Projekts die ständigen „GitOps“ gehört, als wir an unserem Stand auf der KubeCon Europe'19 die dringenden Probleme der DevOps-Ingenieure besprochen haben.
PPS vom Übersetzer
Lesen Sie auch in unserem Blog: