Flux¶

Installation¶

Die Installation von Flux erfolgt über ein Bootstrap-Skript, das von der offiziellen Flux-Website bereitgestellt wird. Dieses Skript installiert Flux auf Ihrem Kubernetes-Cluster und richtet die Verbindung zu Ihrem GitHub-Repository ein. Hier ist ein Beispiel, wie man Flux installieren und konfigurieren kann:

$ curl -s https://fluxcd.io/install.sh | sudo bash
$ export GITHUB_TOKEN=<gh-token> # siehe https://github.com/settings/personal-access-tokens
# Administration -> Access: Read-only
# Contents -> Access: Read and write
# Metadata -> Access: Read-only
$ flux bootstrap github --token-auth --owner=trutzio --repository=kubernetes-tutorial --branch=main --path=clusters/k3s/2026-04-28/
$ kubectl get all -n flux-system
$ flux get sources git
$ kubectl get gitrepositories -n flux-system

https://fluxcd.io/flux/installation/bootstrap/github/ enthält die Github PAT Berechtigungen, die benötigt werden.

Das rolldice Flux-HelmRelease¶

Zuerst erstellen wir ein GitRepository-Manifest, das Flux mitteilt, wo es die Helm-Charts für die Rolldice-Anwendung finden kann. Dieses Manifest verweist auf das GitHub-Repository, in dem die Helm-Charts gespeichert sind, und gibt an, wie oft Flux nach Änderungen suchen soll.

apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata:
  name: github
spec:
  interval: 1m # 12h
  url: https://github.com/trutzio/kubernetes-tutorial.git
  ref:
    branch: main
  ignore: |
    # exclude all
    /*
    # include charts directory
    !/src/apps/rolldice/helm/  

Das folgende HelmRelease-Manifest definiert das Deployment der Rolldice-Anwendung über Flux.

$ cd src/flux
$ kubectl apply -f github-gitrepository.yaml
$ flux get sources git -n default # oder
$ kubectl get gitrepositories
$ kubectl apply -f rolldice-helmrelease.yaml
$ flux get helmreleases -n default # oder
$ kubectl get helmreleases
$ kubectl describe helmrelease/rolldice
$ kubectl get all -l app.kubernetes.io/name=rolldice # pod ist nicht bereit, warum?
$ kubectl logs -l app.kubernetes.io/name=rolldice # fehlerhafte Version, da kein liveliness und readiness
$ # neue Version des Chats in Git pushen, damit Flux die Änderungen erkennt und das Deployment aktualisiert, die appVersion in Chart.yaml auf 1.0.1 erhöhen, damit Flux das Image mit liveliness und readiness aktualisiert
$ helm ls # perfekt, Flux erzeugt die korrekten Helm CRDs in Kubernetes
$ # http://apps.trutz.cloud/rolldice im Browser öffnen, um die Anwendung zu sehen

Flux Webhook-Receiver¶

Erzeuge zunächst ein zufälliges Secret für den Webhook-Receiver:

$ TOKEN=$(head -c 12 /dev/urandom | shasum | cut -d ' ' -f1)
$ echo $TOKEN
$ kubectl -n flux-system create secret generic webhook-token --from-literal=token=$TOKEN
$ kubectl -n flux-system get secrets
$ kubectl apply -f webhook-receiver-ingress.yaml
$ # webhook-receiver.trutz.cloud in DNS eintragen, damit die Ingress-Regel funktioniert
$ kubectl apply -f webhook-receiver.yaml
$ kubectl -n flux-system get receivers
$ kubectl -n flux-system describe receiver/webhook-receiver
$ # webhook in GitHub eintragen https://github.com/trutzio/kubernetes-tutorial/settings/hooks Achtung: Webhook Path: aus dem webhook-receiver.yaml nicht vergessen
$ vim github-gitrepository.yaml # interval auf 12h setzen, da das Webhook die Änderungen an Git erkennt und Flux das Deployment aktualisiert
$ kubectl apply -f github-gitrepository.yaml
$ # Änderung in Git im Helm Chart vornehmen, z.B. die appVersion in Chart.yaml auf 1.0.4 erhöhen

Trennung von Infrastruktur und Anwendung¶

In diesem Tutorial wurde die Infrastruktur der Anwendung (Helm-Skript) und die Anwendung selbst im selber Git-Repository gespeichert. In der Praxis ist es jedoch üblich, die Infrastruktur und die Anwendung in getrennten Git-Repositories zu speichern. Dies ermöglicht eine bessere Trennung von Verantwortlichkeiten und erleichtert die Verwaltung der Infrastruktur und der Anwendung.

Eine mögliche Struktur könnte wie folgt in einem einzigen Git-Repository aussehen:

├── develop
│   ├── integration (Entwicklungsumgebung)
│   │   ├── app1    (Helm Chart für App1)
│   │   ├── app2
│   │   └── app3
│   ├── testing     (Testumgebung für Tester)
│   │   ├── app1
│   │   ├── app2
│   │   └── app3
│   └── maintenance (Wartungsumgebung, Kopie der Produktionsumgebung)
│       ├── app1
│       ├── app2
│       └── app3
├── uat             (User Acceptance Testing, Abnahmeumgebung)
│    └─ default
│       ├── app1
│       ├── app2
│       └── app3
└── production      (Heilige Produktionsumgebung)
    └── default
        ├── app1
        ├── app2
        └── app3

In diesem Beispiel könnten develop, uat und production jeweils ein eigener Kubernetes-Cluster sein. Die Trennung zwischen integration, testing und maintenance innerhalb des develop-Clusters könnte auf Namespace-Ebene erfolgen, um verschiedene Umgebungen innerhalb desselben Clusters zu haben.

Das Ziel sollte sein, die Infrastruktur (Helm-Charts) auf allen Ebene gleich aussehen zu lassen (gleiche Helm Templates), die Unterschiede zwischen den Umgebungen sollten nur in den Werten (values.yaml) liegen, damit die Wartung der Infrastruktur einfacher wird. Man kann dann mit Git-Mitteln wie Branches, Pull Requests und Merge-Strategien arbeiten, um Änderungen an der Infrastruktur zu verwalten und sicherzustellen, dass sie ordnungsgemäß getestet und genehmigt werden, bevor sie in die Produktionsumgebung gelangen.

Beispiel: app1 wird auf der develop/integration-Umgebung entwickelt und auf Git-Push-basis in diese Umgebung via Pipelines deployed. Am Ende eines Sprints wird die app1-Anwendung in die develop/testing-Umgebung überführt und von den Testern getestet. Nach erfolgreichem Testen wird die app1-Anwendung in die uat/default-Umgebung überführt auf der sie die Abnahme erfolgt, z.B. durch das Testen des Product Owners oder durch die Enduser. Nach erfolgreicher Abnahme wird die app1-Anwendung in die production/default-Umgebung überführt und ist für die Enduser verfügbar. Gleichzeitig wird die app1-Anwendung in der develop/maintenance-Umgebung bereitgestellt, damit die Entwickler eine Wartungsumgebung haben für Hotfixes auf der Produktion.

Git Branches¶

Die Git-Branches der Anwendung (nicht der Infrastruktur) könnten wie folgt aussehen:

Branch develop entspricht der develop/integration-Umgebung, hier wird die Anwendung entwickelt und auf Git-Push-Basis in die develop/integration-Umgebung deployed
Branch release/v1.4 entspricht der develop/testing-Umgebung, hier werden die Änderungen von den Testern getestet
Tag v1.4.4 entspricht der uat/default-Umgebung, hier erfolgt die Abnahme durch den Product Owner oder die Enduser
Tag v1.4.4 und main-Branch entsprechen der production/default-Umgebung, hier ist die Anwendung deployed nach erfolgreicher Abnahme
Branch hotfix/v1.4.5 entspricht der develop/maintenance-Umgebung, hier werden Hotfixes auf der Produktion entwickelt, dieser Branch wird aus dem main-Branch abgezweigt