Flux

Praxisbericht.tex

@@ -182,6 +182,17 @@ Eine weitere Anforderung ist eine Verwaltungsübersicht für das Kubernetes-Clus
 
 Kernbestandteil der mir initial gegebenen Anforderungsliste war die Evaluation der Nutzbarkeit von Kubernetes auf Windows-basierten Systemen. Während Kubernetes unterstützt, Worker-Nodes auf Windows laufen zu lassen, gibt es keine Control-Plane die für Windows konzipiert ist, da Windows im Umfeld der Containerisierung keine Vorteile gegenüber Linux bietet, und der Mehraufwand nicht rechtfertigbar ist. Die Problemstellung lässt sich trotzdem lösen, da der Windows-Kernel seit Windows 10 bzw. Windows-Server 2016 Hyper-V mitliefert\cite{windowsHyperVIntro}. Hyper-V ist Microsofts Type-1 (Bare-Metal) Hypervisor, vergleichbar mit Linux' KVM. Hypervisor sind Software, die es erlauben, auf Host-Systemen mehrere Virtuelle Maschinen (VMs), sogenannte Guest-Systeme, laufen zu lassen. Dabei unterscheidet man zwischen Type-1 und Type-2 Hypervisorn. Der Vorteil von Type-1 Hypervisorn ist, dass diese parallel zum Kernel laufen und unabhängig Userspace des Host-Systems sind, während Type-2 Hypervisor auf dem Host-Betriebssystem laufen. Damit sind Type-2 Hypervisor einfacher zu bedienen, jedoch langsamer und unsicherer. Der Clou ist, mithilfe von Hyper-V eine Linux-VM aufzusetzen auf welcher das Cluster läuft. Nachteil bei dieser Konfiguration ist, dass durch die Virtualisierung ein Performance-Overhead, besonders in I/O-Operationen entsteht, sowie dass Networking innerhalb Hyper-V sehr fragil ist, weswegen nur externe Switches wie erwartet funktionieren. Diese müssen jedoch innerhalb der Kundenfirewall als externes Gerät eingerichtet werden, was die Kundentoleranz maßgeblich senkt. Da ein nicht zu unterschätzender Anteil der Kunden auf Windows-basierte Serversysteme setzt, könnte dies eine große Einschränkung bei Portierung von selektron erweisen.
 
+Um zu verhindern, dass die Server-Konfiguration undokumentiert Verändert wird, existiert das Konzept von GitOps: eine oder mehrere Git-Repositories zählen als Wahrheitsquelle und definieren den Wunschzustand der gesamten Infrastruktur, und Operatoren synchronisieren die laufende Umgebung ständig mit diesem Zustand. Dieser Vorgang ist dabei Teil der CI/CD (Continous Integration, Continous Delivery) Pipeline, konkret übernimmt es den CD-Teil. Anders als bei einer klassischen CD-Pipeline, bei der Push-basiert von einem Build-Server auf den Deployment-Server deployt wird, wird bei der GitOps-Pipeline Pull-basiert von einem auf dem Deployment-Server laufenden Operator in Intervallen die Git-Repo nach Änderungen überwacht, und im Falle einer Differenz zwischen Repository-Zustand und Server-Zustand die notwendigen Änderungen vorgenommen. Diesen Prozess nennt man reconciliation. Somit sind Serverzustand und Git-Zustand synchronisiert, Änderungen am Server auditierbar (Wer hat etwas geändert), differenzierbar (Was wurde genau geändert), rollbackbar im Falle eines Problems und reproduzierbar. Dabei setzen wir auf FluxCD, eine CNCF Graduated\cite{fluxCNCF} GitOps Implementation für Kubernetes. Eine Mögliche Alternative ist ArgoCD, welches von Haus aus eine UI bietet, jedoch ist FluxCD nativer in das Kubernetes-Tooling integriert, benutzt Kubernetes-natives RBAC und integriert mit Headlamp-Plugin\cite{fluxHeadlampPlugin} nativ in die gewünschte Übersicht. Dabei hat Flux zwei für selektron relevante Pipelines: die GitOps Pipeline und die Image-Controller-Pipeline.
+
+Die GitOps Pipeline besteht aus \texttt{source-controller}, \texttt{kustomize-controller} und \texttt{helm-controller}.\\
+Der \texttt{source-controller}\cite{fluxSourceController} überprüft in Gegebenem Intervall Angegebene Quellen wie \texttt{GitRepository}, \texttt{HelmRepository} oder \texttt{OCIRepository} und speichert sie als Cluster-lokales Artifact.\\
+Der \texttt{kustomize-controller}\cite{fluxKustomizeController} sucht nach auf dem Cluster existierenden Komponenten des Typs \texttt{Kustomization}. Sofern das in der Komponente definierte Intervall abgelaufen ist oder die Quelle, die vom Source-Controller überwacht wird, sich geändert hat, führt der Controller auf dem gegebenen Pfad einen Kustomize-Befehl aus, produziert .yaml Dateien, checkt diese gegen den aktuellen Stand, und wendet sie bei Änderungen an. Damit wird nach jedem Intervall jeglicher Drift überschrieben. Die Kustomization-Komponente kann mit Parameter \texttt{prune} alle unter das Kustomization fallenden nichtmehr existierenden Komponenten automatisch aufräumen. Mit Parameter \texttt{wait} oder \texttt{healthChecks} wartet die Kustomization bis alle bzw. die unter \texttt{healthChecks} definierten Komponenten bereit sind, bevor die Kustomization selbst als Bereit gilt. Somit fallen Fehlkonfigurationen schneller auf.\\
+Der \texttt{helm-controller}\cite{fluxHelmController} greift analog zum Kustomize-Controller bei \texttt{HelmRelease}s statt \texttt{Kustomization}s, und setzt dabei Helm-Charts automatisch mit den gegebenen Values auf.
+
+Die Image-Automation-Pipeline\cite{fluxImagePipeline} besteht aus dem \texttt{image-reflector-controller}, welcher \texttt{ImageRepository}s überwacht und deren Metadaten speichert. Er wertet mit einer \texttt{ImagePolicy} die gespeicherten Metadaten aus, und entscheidet welches der zu benutzende Tag ist. Mithilfe des \texttt{image-automation-controller}s und einer \texttt{ImageUpdateAutomation}-Komponente wird in einer Angegebenen Git-Repository der zu benutzende Tag committed. Somit übernimmt im Falle von Image-Updates FluxCD automatisch die Migration.
+
+Mithilfe der beiden Pipelines kann FluxCD einen massiven Teil des Deployments übernehmen. Ob FluxCD jedoch genutzt wird bleibt abzuwarten, da es permanenten Zugriff auf die Angegebenen Repositories braucht um nützlich zu sein, jedoch viele Kunden einen Möglichst abgeschotteten Server haben möchten. 
+
 
 Eine klassische Serviceaufgabe wäre das Neustarten und Stoppen von Containern.
 

literatur.bib

@@ -81,6 +81,50 @@
 	date = {2025-08-05}
 }
 
+@online{fluxCNCF,
+	author = {Cloud Native Computing Foundation},
+	title = {\glqq Flux | CNCF\grqq},
+	url = {https://www.cncf.io/projects/flux/},
+	urldate = {2026-05-08},
+	year = 2026
+}
+@online{fluxHeadlampPlugin,
+	author = {Headlamp},
+	title = {\glqq headlamp\_flux 0.6.0\grqq},
+	url = {https://artifacthub.io/packages/headlamp/headlamp-plugins/headlamp_flux},
+	urldate = {2026-05-08},
+	date = {2024-11-07}
+}
+@online{fluxSourceController,
+	author = {Flux},
+	title = {\glqq Source Controller | Flux\grqq},
+	url = {https://fluxcd.io/flux/components/source/},
+	urldate = {2026-05-08},
+	date = {2025-09-23}
+}
+@online{fluxKustomizeController,
+	author = {Flux},
+	title = {\glqq Kustomize Controller | Flux\grqq},
+	url = {https://fluxcd.io/flux/components/kustomize/},
+	urldate = {2026-05-08},
+	date = {2023-05-24}
+}
+@online{fluxHelmController,
+	author = {Flux},
+	title = {\glqq Helm Controller | Flux\grqq},
+	url = {https://fluxcd.io/flux/components/helm/},
+	urldate = {2026-05-08},
+	date = {2022-08-30}
+}
+@online{fluxImagePipeline,
+	author = {Flux},
+	title = {\glqq Image reflector and automation controllers | Flux\grqq},
+	url = {https://fluxcd.io/flux/components/image/},
+	urldate = {2026-05-08},
+	date = {2022-08-30}
+}
+
+
 
 @misc{rsFaq,
 	author  = {Rust Community},