21 Juni 2024
Einstieg in Flux 2.0
| Kategorien: | credativ® Inside HowTos |
|---|
Was ist Flux?
Flux oder auch FluxCD ist ein selbst betiteltes GitOps Framework mit dem sich Deployments auch über Clustergrenzen hinweg automatisieren lassen. Es handelt sich dabei um eine Gruppe von 4 Kubernetes Operatoren welche das Deployment von Yaml-Manifesten und Helmcharts in ein Kubernetes Cluster managen. Hierbei ist der essentielle Punkt das ein oder mehrere Git-Repositories die Quelle der Deployments sind und keine Änderungen an den eigentlich Cluster-Ressourcen durchgeführt werden. Auch werden Änderungen an den Daten im Repository registriert und die Ressourcen im Cluster entsprechend aktualisiert. Flux legt dabei den Schwerpunkt auf ein simples Setup, unkomplizierte Komponenten und Performance. So sind die einzelnen Komponenten ressourcensparend implementiert und auch Komfortkomponenten wie z.B. eine WebUI ist nicht Teil des Setups, auch wenn hier Drittkomponenten verfügbar sind. Auf die einzelnen Operatoren gehen wir im Laufe des Artikels näher ein.
Bereits im Juli 2023 erschien Flux in Version 2.0 welche eine vollständige Überarbeitung darstellt, und wird mit jedem Release um vielfältige Features vor allem rund um das Handling von Helm-Deployments erweitert.
Das Announcement der aktuellsten Version 2.3.0 finden Sie hier.
Einen Artikel zu FluxCD 1 finden Sie unter ebenfalls in unserem Blog in dem wir die Vorgängerversion besprochen haben.
Was ist GitOps?
Der Begriff „GitOps“ wird verwendet, wenn zur Einrichtung und Wartung von Infrastruktur und Applikationen eines oder mehrere Code-Repositories (meist Git) als Grundlage dienen. In diesen werden z.B. die Kubernetes-Yamls verwaltet die auf dem einen oder anderen Weg in Kubernetes deployed werden sollen. Ein anderes Beispiel wären z.B. Ansible-Playbooks (kubespray, ansible-ceph) welche ebenfalls über ein Git-Repository versioniert werden können.
So ist jederzeit ersichtlich wer welche Änderung zu welchem Zeitpunkt durchgeführt hat und alte Stände können ohne Aufwand wieder hergestellt werden.
Gerade im Kubernetes-Umfeld gibt es zu den Repositories häufig noch eine Pipeline, welche die hinterlegten Daten verarbeitet und deployed. Als Alternative bieten sich hier natürlich Operatoren direkt in Kubernetes an, welche die Aufgaben einer separaten Pipeline übernehmen und speziell für die Wartung von Kubernetes-Deployments konzipiert sind. Hierzu zählen Lösungen wie z.B. Flux oder auch Argo CD.
Flux Komponenten
Wie bereits erwähnt besteht Flux aus verschiedenen Operatoren. Diese werden unabhängig voneinander entwickelt und haben jeweils einen dedizierten Zweck.
Source Controller
Dieser kümmert sich primär um das Einbinden und Verwalten von verschiedenen Artefakten. Dies können z.B. Git-Repositories, Helm-Repositories oder S3-Buckets sein. Es stellt dabei eine zentrale API dar mit welcher alle anderen Komponenten interagieren und die verschiedenen Artefakte nutzen können.
Eine allgemeine Übersicht der Funktion und Möglichkeiten findet sich in der Dokumentation des Operators.
Ein gängiges Beispiel wären hier die Helm-Repositories welche von Helm-Deployments des entsprechenden Controller genutzt werden können.
--- apiVersion: source.toolkit.fluxcd.io/v1beta2 kind: HelmRepository metadata: name: kubepromstack namespace: kubepromstack spec: interval: 1m0s url: https://prometheus-community.github.io/helm-charts
Es können jedoch auch Helmcharts in einer bestimmten Version mit eigenem Values-file als Artefakt (tar.gz) aus einem Repository erstellt werden und später in einem Helm-Release referenziert werden. Damit können die Charts zentral personalisiert und lokal gepflegt werden. Einzelne Nutzer müssen entsprechend nur noch kleinere Anpassungen vornehmen und benötigen z.B. keinen Zugriff auf überstehende Objekte. Das entsprechende Artefakt wird je nach Konfiguration selbstständig aktualisiert.
---
apiVersion: source.toolkit.fluxcd.io/v1
kind: HelmChart
metadata:
name: podinfo
namespace: default
spec:
interval: 5m0s
chart: podinfo
reconcileStrategy: ChartVersion
sourceRef:
kind: HelmRepository
name: podinfo
version: '5.*'
Helm-Controller
Dieser kümmert sich um das Deployment und die Überwachung von Workloads welche mittels Helm-Charts bereitgestellt werden. Hierbei benötigt es eine CRD für das Repository selbst (welches via Source-Controller gemanaged wird) und eine für das eigentliche Helm-Release welche dann die Definition und Konfiguration enthält.
Neben der Definition der zu nutzenden Version können auch diverse Optionen wie der Zielnamespace, der Serviceaccount welcher für das Deployment genutzt werden soll, ggf. eine dedizierte kubeconfig für andere Cluster auch eigene Values entweder inline oder per Configmap übergeben werden.
Diese Configmaps lassen sich hier auch ganz bequem via Configmap-Generator (ein Kustomize-Feature) erstellen und pflegen. Kustomize kümmert sich hier auch um die entsprechende Aktualisierung des Deployments sollte sich die values.yaml einmal im Repository ändern.
---
apiVersion: helm.toolkit.fluxcd.io/v2beta2
kind: HelmRelease
metadata:
name: kubepromstack
namespace: kubepromstack
spec:
install:
createNamespace: true
targetNamespace: kubepromstack
chart:
spec:
chart: kube-prometheus-stack
reconcileStrategy: ChartVersion
sourceRef:
kind: HelmRepository
name: kubepromstack
version: 55.8.2
valuesFrom:
- kind: ConfigMap
name: kubepromstack-values
interval: 1m0s
Daneben bietet der Helm-Controller auch Unterstützung für Helm-Tests, eine Drift-Detection um Abweichungen vom System zum gewünschten Deployment zu erkennen (inkl. optionaler Ignore-Regeln) und ein reichhaltiges Toolset um mit problematischen Helm-Deployments umzugehen. Diese Features wurden speziell in der Version 2.2 noch einmal ausgebaut.
Wird in der Version z.B. ein Asterisk für die Minor oder Major-Version genutzt, so aktualisiert Flux auch selbstständig das Release basierend auf der neuen Version sobald diese im Repository erkannt wurde.
Eine gute Übersicht wie der Helm-Controller in die anderen Komponenten eingebette ist findet sich in der Dokumentation.
Kustomize Controller
Dieser kümmert sich um die Ausführung der Anpassungen welche in den einzelnen Kustomize-Yamls definiert sind. Dies ist auch der Einstiegspunkt für das Git-Repository da alle Abhängigkeiten und Verknüpfungen innerhalb des Repository via kustomize.yamls definiert werden. Hierbei stehen auch alle Features die Kustomize für die einzelnen Deployments zur Verfügung. Dies beinhaltet u.a. Anpassungen der zu deployenden yaml-files wie auch Funktionen wie der Configmap- oder Secret-Generator.
Folgend ein Beispiel für die Navigation durch ein Git-Repository inkl. Configmap-Generator
---
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
name: infra
namespace: flux-system
spec:
interval: 1m0s
sourceRef:
kind: GitRepository
name: flux-system
path: ./infra
prune: true
wait: true
timeout: 5m0s
-- kustomization.yaml in ./infra/ apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization resources: - ingress - monitoring - gitops/weave-gitops-dashboard.yaml
-- kustomization.yaml in ./infra/ingress/ apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization resources: - helmrepo_ingress.yaml - helmrelease_ingress.yaml configMapGenerator: - name: ingress-values namespace: flux-system files: - values.yaml=custom_values.yaml configurations: - kustomizeconfig.yaml
Auch für den Kustomize Controller gibt es eine Übersicht in der Dokumentation.
Notification Controller
Über diesen werden je nach Konfiguration Notifications an verschiedene Endpoints gesandt. Dies kann Änderungen an den Sources, Probleme bei Deployments oder auch einfach generische Informationen beinhalten. Als Endpunkte können sowohl generische Webshooks dienen wie auch Integrationen in verschiedene Applikationen wie Slack, MS Teams, Discord oder Pagerduty.
Die Möglichkeiten der Integration und der Alerts werden dabei stetig erweitert und können für Details in der Dokumentation.
Fazit
Flux 2 ermöglicht eine einfache und strukturierte Einbindung verschiedener Ressourcen und hat einen starken Fokus auf Flexibilität und Skalierung.
Durch die Modularität und die mächtigen Möglichkeiten die durch Kustomize gegeben sind ist es auch problemlos möglich sehr individuelle Strukturen abzubilden. Dies war natürlich nur ein kleiner Einblick in die Möglichkeiten und es ist auf jeden Fall zu empfehlen sich in Abhängigkeit der eigenen Infrastruktur und Anforderungen tiefer mit den verschiedenen Optionen auseinanderzusetzen um eine passgenaue Lösung zu finden. Weiterführende Themen wie die Installation und Beispiele für die Strukturierung der Git-Repositories werden wir in folgenden Artikeln behandeln.
| Kategorien: | credativ® Inside HowTos |
|---|
über den Autor
Danilo Endesfelder
Berater
zur Person
Danilo ist seit 2016 Berater bei der credativ GmbH. Sein fachlicher Fokus liegt bei Containertechnologien wie Kubernetes, Podman, Docker und deren Ökosystem. Außerdem hat er Erfahrung mit Projekten und Schulungen im Bereich RDBMS (MySQL/Mariadb und PostgreSQL<sup>®</sup>). Seit 2015 ist er ebenfalls im Organisationsteam der deutschen PostgreSQL<sup>®</sup> Konferenz PGConf.DE.