praxisbericht/Praxisbericht.tex

\documentclass[paper=a4,fontsize=12pt,ngerman]{scrartcl}

\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{graphicx}
\usepackage[ngerman]{babel}
\usepackage[autostyle=true]{csquotes} %biblatex german quoting
\usepackage{amsmath}
\usepackage{pifont} % ding55
\usepackage[a4paper,left=25mm,right=35mm,top=25mm,bottom=30mm]{geometry}
\usepackage{parskip}
\usepackage{comment} %dies ist ein kommentar
% tableau
\usepackage{booktabs}
\usepackage{multirow} % table stuff
\usepackage{tablefootnote} % table
\usepackage{diagbox}
\usepackage{caption}
\usepackage{url} %damit urls richtig formatted werden dürfen, müss \url{URL} usen
\usepackage{tikz}
\usetikzlibrary{shapes.geometric, arrows, positioning}
%\usepackage[colorlinks=false, hidelinks]{hyperref} % keine hyperrefs

\usepackage{listings} % code blocks
\usepackage{xcolor}

\usepackage[backend=biber, style=numeric, url=true]{biblatex} %URL in biblatex
\addbibresource{literatur.bib}
%\bibliography{literatur} %bibtex

\graphicspath{{graphics/}}

\definecolor{codegreen}{rgb}{0,0.6,0}
\definecolor{codegray}{rgb}{0.5,0.5,0.5}
\definecolor{codepurple}{rgb}{0.58,0,0.82}
\definecolor{backcolour}{rgb}{0.95,0.95,0.92}

\lstdefinestyle{mystyle}{
 backgroundcolor=\color{backcolour},
 commentstyle=\color{codegreen},
 keywordstyle=\color{magenta},
 numberstyle=\tiny\color{codegray},
 stringstyle=\color{codepurple},
 basicstyle=\ttfamily\footnotesize,
 breakatwhitespace=false,
 breaklines=true,
 captionpos=b,
 keepspaces=true,
 numbers=left,
 numbersep=5pt,
 showspaces=false,
 showstringspaces=false,
 showtabs=false,
 tabsize=2
}
\lstset{style=mystyle}

\newcommand{\cmark}{\ding{51}}
\newcommand{\xmark}{\ding{55}}

\begin{document}

\pagenumbering{roman}
\pagestyle{plain}

% Einbinden der Titelseite
\begin{titlepage}

	\linespread{1.5}

	\includegraphics[width=\linewidth]{htw_logo}

	\begin{center}
		\large
		\hfill
		\vfill
		\Large{\bfseries{Evaluation der Migration von Kubernetes}}

		von \\
		Tim Wall\\
		Mat. Nr. 5014365

		\vfill


		Ein wissenschaftlicher Bericht im Rahmen der Praxisphase\\
		an der htw saar im Studiengang Praktische Informatik\\
		in Kooperation mit der psb intralogistics GmbH

		\vfill
		\vfill

		Pirmasens, den \today
	\end{center}

\end{titlepage}

\clearpage
\tableofcontents

\clearpage

\section*{Vorwort}

Die Praxisphase ist ein Zeitraum innerhalb des Studiums, um eine Brücke zwischen dem theoretischen Unterricht und der praktischen Umsetzung in der Realität zu bilden. Planmäßig findet diese im sechsten Semester in den ersten 12 Wochen statt. Meine Praxisphase begann am 01.04 bei der psb intralogistics GmbH in Pirmasens, und dauert bis zum 24.06.

Innerhalb diesem Zeitraum wird mir Einblick in die Unternehmensstrutkur, deren Softwareschöpfungsprozess und eine eigene Projektarbeit gewährt. Auch werden außercurriculäre Inhalte und Soft Skills vermittelt. Somit wird fachliche, sowie persönliche Entwicklung gefördert.

Der Praxisbericht ist eines der resultierenden Elemente, in welchem das Unternehmen, der Arbeitsplatz, dessen Stellung, durchgeführte Aufgaben, gewonnene Erkenntnise und die unterliegende theoretische Basis dokumentiert, evaluiert und bewertet wird. 

\vfill
\begin{minipage}[c]{0.49\textwidth}
	\begin{center}
		\noindent\rule{6cm}{0.3pt}\\
		Unterschrift Student
	\end{center}
\end{minipage}
\hfill
\begin{minipage}[c]{0.49\textwidth}
	\begin{center}
		\noindent\rule{6cm}{0.3pt}\\
		Unterschrift Unternehmen
	\end{center}
\end{minipage}
\vspace{1cm}

\newpage

\pagenumbering{arabic}

\section{Betrieb}

Die psb intralogistics GmbH mit Sitz in Pirmasens ist ein traditionsreiches, mittelständisches Familienunternehmen, das 1887 als Schlosserei gegründet wurde. Heute zählt es zu den führenden europäischen Anbietern von automatisierten Intralogistik-Gesamtsystemen. 

Das Unternehmen zeichnet sich durch eine sehr hohe vertikale Integration aus: Von der ersten Planung über die mechanische Produktion und Softwareentwicklung bis hin zur Montage und Wartung erfolgt alles \glqq{}aus ei(ge)ner Hand\grqq{}\cite{psbDasUnternehmen}. Das Unternehmen beschäftigt knapp unter 550 Mitarbeiter, darunter Ingenieure, Softwareentwickler, SPS-Programmierer, Fertigung, Montage, Materialbeschaffung, Logistik, Vertrieb, IP-Verwaltung (geistiges Eigentum) sowie Managementebene.

psb ist ein familiengeführtes Unternehmen, aktuell in der 4. Generation durch Werner Klein. Als mittelständisches Unternehmen wird auf kurze Entscheidungswege und ein Patensystem für neue Mitarbeiter gesetzt, um Know-how schnell zu vermitteln und Wissenssilos zu durchbrechen.

Lösungen sind auf jeden Kunden maßgeschneidert und verbinden Lagerung, Transport, Kommissionierung, Sortierung und Software zu einem einheitlichen Komplettsystem.

Je nach Größe der zu lagernden Elemente und des gewünschten Systems bietet psb vorgefertige Baukastensysteme, die individuell zugeschnitten werden. Als klassische Regalbediengeräte existieren der sprinter, gedacht für leichte Kartons, Kleinbehälter und Tablare, der runloader, gedacht für Kassetten oder Hängeware bis 300 kg Zuladung und der maxloader, gedacht für Paletten bis 1250 kg. Aber auch Shuttlesysteme wie der vario.sprinter, Paletten-Shuttles oder Mischsysteme wie Hängewaren-Shuttles werden zum Lagern angeboten.\\
Der Transport wird durch Rollbahnen, Mehrstrangförderern und einer breiten Auswahl an Verbindungsstücken realisiert.\\
Automatische Kommisionerung wird von autopick, einem KI-geführten, mit Vakuumsaugern ausgestatteten Roboterarm übernommen. Manuelle Kommisionerung erfolgt auftragsgerecht sequenziert durch rotapick-Systeme, im Gleichteilüberfluss durch Multi-Order-Stationen, Auftragsbasiert in 1-zu-1-Kommissionierung oder Flächendeckend mit Durchlaufregalen.\\
Die Orchestration der zuvor genannten Systeme und Module erfolgt durch eine in-house entwickelte Software-Suite mit dem Namen \textbf{selektron}, bestehend aus Warehouse Management System (WMS), Materialflusssteuerung (MFC), Anlagensteuerung (FLC), Visualisierung (SCADA), Produktionssteuerung und Anbindung an bestehende Kundensysteme, z.B. Enterprise Resource Planning (ERP), Produktionsplanung (PPS), Inventurverwaltung (WWS). Diese Suite wird mit einem 24/365 Service abgerundet, welcher durch Fernwartung schnelle Störungsbeseitung ermöglicht.

Im globalen Intralogistik-Markt hebt sich psb gegenüber den Big Player mit dem hohen Manufakturgrad, vertikaler Intergration und persöhnlicher Kundebetreuung ab.

\section{Arbeitsplatz}

Der Firmenbereich besteht aus einem Verwaltungsgebäude und zwei Fabrikhallen. Das dreistöckige Verwaltungsgebäude besitzt im Erdgeschoss Kundenempfang, Human Resources, SPS-Entwicklung, UCM-Entwurf und Gesprächsräume für Kundentermine. Der erste Stock besteht aus dem IT-Bereich und der Projektabwicklung. Innerhalb der Projektabwicklung wird zwischen Steuerung, SCADA, Fördertechnik, Hängefördertechnik, Lagertechnik, Mechanischer Konstruktion, Elektrischer Konstruktion, Produktdesign, Service, Projektmanager, Dokumentation und den Software-Ingenieuren bestehend aus Warehouse Management, Material Flow, Nutzeroberfläche, Softwarewartung, unterschieden. Das oberste Stockwerk ist für den Vertrieb, Betriebsrat und Management vorgesehen.

Die Plätze sind nach Teams innerhalb Trennwänden gruppiert, um Kommunikationswege kurz zu halten, den Austausch zu fördern, jedoch bei Gesprächen andere Gruppen nicht zu belästigen, und bestehen aus jeweils vier bis fünf Leuten. Die Leute innerhalb eines Teams behandeln die gleichen Kundenprojekte. Diese \glqq{}Sitzverteilung\grqq{} ist trotzdessen nicht bindend und jeglich eine Empfehlung, um Kommunikation zwischen den Gruppen nicht zu blockieren. Die Gruppenbezeichnung PA INF GUI, kurz für Projektabwicklung Software-Engineering Graphical User Interface, welcher ich untergewiesen bin, ist auf 4 Teams verteilt.

Das Software-Engineering Department befindet sich im ersten Stock auf der Südseite, und wird mit einer Feuerschutztür von den anderen Projektabwicklung logisch getrennt. Bei Eintritt in die Abteilung wird man von den Meetingsräumen sowie darauffolgende Kücheneinheit und Sanitäranlagen begrüßt. Die Küchentheke besteht aus zwei Kaffeemaschinen, einem Wasserkocher, Kühlschrank sowie Spülmaschine und -becken. Direkt gegenüber befindet sich mein zugewiesener Arbeitsplatz, welcher mit einer Docking-Station meinen Arbeitslaptop mit Bildschirmen und Peripherie verbindet. Meine direkten Nachbarn befassen sich mit dem gleichen Themengebiet meiner Praxisphase und ermöglichen durch physische Nähe schnnelle, effiziente, E-Mail unabhängige Kollaboration und Problemlösung, besonders bei Trivialitäten. 

\section{Aufgabenbereich}

Mein Arbeitsplatz befindet sich im Herz der PA INF GUI. Während der Name auf alleiniges Ausarbeiten von grafischen Nutzeroberflächen (Graphical User Interface, kurz GUI) vermuten lässt, ist diese Abteilung auch für die Integration der verschiedenen Backends selektron WMS, selektron MFCS, selektron RPS zuständig. Dies wird mithilfe des in der Abteilung entwickelten Kernmodul der selektron-Suite, selektron core, bewältigt. selektron core besteht dabei aus den Komponenten Administration, API Gateway, Authentification, Authorisation und Discovery. Jedes der Backends besteht ebenfalls aus mehreren Komponenten. Diese werden jeweils für Kundensysteme vom Basis-Entwicklungsstand einzeln angepasst und zugeschnitten, damit es perfekt auf deren Anforderungen ausgelegt ist. Oft haben Kunden jedoch gleiche oder ähnliche Bedürfnisse, welche im aktuellen System bei jedem Kunden extra und damit mehrfach Implementiert werden. Diese Implementationen betreiben oft die gleiche Aufgabe, sind jedoch anders Entwickelt. Durch diese resultierenden Redundanzen steigt der Wartungsaufwand. Ebenfalls steigt der Aufwand, die zugeschnittenen Systeme bei dem Kunden zu konfigurieren und einzusetzen, da jeder Kunde eine einzigartige IT-Infrastruktur hat, wodurch das Deployment händisch mit einer Ansammlung von über die Jahre entwickelten und gewachsenen Skripten und viel Filigranarbeit durchzuführen ist. Dieses Händische Deployment senkt die Wartbarkeit, da über die Jahre immer wieder Updates, Migrationen und sonstige kurzfristige Änderungen auftreten, welche nur zum Teil dokumentiert, und damit schwer Nachvollziehbar sowie absolut nicht Auditierbar sind. Ebenfalls ist die Einarbeitung von Servicemitarbeitern aufwändig, da alles über das Terminal mit Skripten und Befehlen verwaltet werden muss, und nicht alle Fälle von diesen existierenden Skripten übernommen werden können. Diese Servicefälle müssen dann im Schlimmsten Fall bis zum nächsten Arbeitstag warten, was für den Kunden verlorene Zeit und damit verlorenes Geld bedeutet. Ebenfalls existiert im aktuellen System keine automatische Ausfallsicherheit, welche den Service bei trivialen Fällen entlasten könnte.

Jedes der zuvor genannten Module wurde innerhalb der letzten Jahre in Container-Images gebündelt und mit Containerverwaltungstools wie Docker oder Podman, als auch  durchgeführt, um das Deployment weitestgehend zu vereinfachen und Kunden-infrastruktur-unabhängiger zu gestalten. Trotzdessen bleiben ziemlich alle gennanten Probleme bestehen, da sie über die Containerisierung hinaus gehen.

Mein Aufgabenbereich, das Evaluieren von Kubernetes als Containerorchestrierung für den Software-Stack der psb, ist keine klassische Aufgabe im Bezug auf die Nutzeroberfläche, ist in der Firmenstruktur trotzdem dieser Abteilung untergliedert. Kubernetes führt im Kern, ähnlich wie Docker und Podman, Container aus, geht jedoch weit über das Ausführen sowie Verwalten von diesen hinaus und wird daher aus als Orchestration bezeichnet. Lastverteilung, Selbstheilung, Ausfallsicherheit, Koordination, Skalierungsmöglichkeiten beschreiben die Möglichkeiten, die Kubernetes im Kern bietet. Kubernetes ist jedoch leicht erweiterbar, wodurch auch Versionierung und Rollbacking über Helm, automatisches Deployment durch FluxCD und HTTP Routing über GatewayAPI abgedeckt sind. \textbf{TODO: POTENTIELLE SECRET-INJECTION MIT ESO} Da die Firma aktuell noch keine Forschung über Kubernetes außer dem Fakt, dass es existiert und die aktuelle Problemlage Lösen könnte, betrieben hat sollte dies meine Aufgabe werden. Das Ziel ist es, einen möglichst automatisch deploybares "Walking Skeleton" aus dem aktuellen Basisprojekt zu gestalten, und dabei die verschiedenen Funktionieren und Erweiterungen die Kubernetes liefert, zu analysieren wie diese funktionieren als auch zu überprüfen, ob diese konkret für das Projekt Sinn machen. Darüber hinaus soll geprüft werden, inwieweit Kubernetes eine Integration von Windows-basierten Systemen ermöglicht und welche technischen Einschränkungen dabei bestehen.

Die gewonnenen Erkenntnisse dienen als Entscheidungsgrundlage für eine mögliche Migraton der bestehenden Systemarchitektur hin zu einer Kubernetes-basierten Lösung.

\section{Methodik}

Während der gesamten Praxisphase wurde, soweit realisierbar, ein iterativer Zyklus verfolgt. Dieser beginnt initial mit der Discovery-Phase, in welcher neue Produkte identifiziert werden, die zu den gegebenen Zielen passen. Anschließend werden sie in einem Backlog festgehalten. Dieser wird in Absprache zwischen den Betriebsmitgliedern und mir geordnet.

Sofern ein Produkt die Spitze des Backlogs erreicht, startet die Forschungsphase, in der Eigenschaften über das Produkt und dessen Funktionsweise ermittelt wird. Sofern die Ziele des Produktes mit den Zielen des Betriebes übereinstimmen, wird das Produkt in die bestehende Testlandschaft integriert und Charakteristiken erarbeitet.

Diese Funktionsweisen und Charakteristiken werden im Firmeninternen Confluence-Board, einer kollaborativen Knowledgebase von Atlassian, dokumentiert. Folgend auf die Dokumentation wird eine Diskussion über die Integration des Produktes bei der finalen Migration besprochen. Sofern Alternativen zu den Produkt bestehen erfolgt ein Vergleich mit diesen. Somit wird Techstack-Creep, welches mit übermäßiger Komplexitat, Ineffizienzen und Sicherheitsrisiken verbunden ist, verhindert. Gleichzeitig wird garantiert, dass wertschöpfende Produkte nicht ausgelassen werden.

\section{Vorgehensweise}

\subsection{Distribution}
Initial wurde Forschung über die Funktionsweise von Kubernetes unternommen, da weder meine Betreuer, noch ich Wissen in diesem Bereich hatten. Dabei fiel zuerst Augenmerk darauf, dass es im Gegensatz zu Docker oder Podman nicht \glqq{}ein\grqq{} Kubernetes gibt, sondern verschiedene Distributionen\cite{distroList}, ähnlich wie bei Linux. Da die Logikcontroller der psb direkt im Lager On-Premise laufen, lassen sich schnell viele der Cloud-basierten Lösungen wie AWS EKS, Azure AKS oder Google GKE wegfiltern. Übrig bleiben die On-Premise oder Edge-Computing Distributionen. Diese Unterscheiden sich auch ähnlich wie Linux-Distributionen weniger darin, welche Software laufen kann, sondern in dem Standardumfang und bestimmten Unique Selling Points, wie einem einfachen Installationsprozess oder hohem Compliance-Grad out-of-the-box. Kandidaten sind Rancher k3s, eine Edge-Compute-Distribution mit Fokus auf Hauptspeichereffizienz auf Kosten einiger High-Availability-Funktionen, welche mit einem Befehl installierbar ist\cite{distroK3s}, Rancher RKE2, einer Distribution mit Fokus auf hohen Sicherheitsstandards, Compliance und Enterprise-Support\cite{distroRKE2}, RedHat OpenShift, eine allumfassende Plattform mit Kubernetes im Kern welche GitOps, CI/CD Pipelines, Infrastrukturmanagement, Monitoring und Enterprise-Support umfässt\cite{distroOpenShift}, OKD, die Communitygetriebene Version von OpenShift ohne Enterprise-Support\cite{distroOKD} und zuletzt kubeadm\cite{distroKubeadm}, welches den minimalen Kern von Kubernetes deployt und den Rest der Konfiguration dem Nutzer überlasst.
Für das Evaluieren wurde entschlossen, eine möglichst Originalgetreue Distribution von Kubernetes zu benutzen, wodurch OpenShift und OKD mit ihren meinungsstarken Standardkonfigurationen wegfallen und die Entwicklungen von Rancher sowie kubeadm übrig blieben. Da k3s mit einfacher Installation, besonders im Gegensatz zu kubeadm, überzeugt, wurde es als initiale Technische Grundlage ausgewählt, besonders mit dem Hintergedanken, dass für den Kubernetes-Kern geschriebene Komponenten auf jeder Distribution lauffähig sind. Diese Portabilität soll später ebenfalls erlauben, weitaus Kundensystem-agnostischer zu arbeiten.

\subsection{Graylog}
Nach der Wahl der Distribution folgte das Einarbeiten in Kubernetes. Dabei wurde mit den kompletten Grundlagen begonnen: wie bediene ich das Kommandozeilentool \texttt{kubectl}, was ist ein Pod, wie ist er definiert, wie binden Services sich an Pods, et cetera. Gleichzeitig wurde meiner ersten Aufgabe nachgegegangen, das Monitoring-Tool Graylog, welches selektron benutzt, um alle Logs der verschiedenen Services zusammenzuführen, auf Kubernetes zu portieren, um praktische Erfahrung zu sammeln. Währenddessen wurde ein Nachschlagewerk geschrieben und gepflegt, um diese Daten zusammengefasst an einer Stelle zu haben. Schnell wurde klar, das Kubernetes Komponenten manuell schreiben und verwalten möglich ist, jedoch Limitationen aufweist. Ein Kernnachteil ist, dass \texttt{kubectl apply} nur Komponenten hinzufügen, aber nicht löschen kann, und man somit nichtmehr definierte Komponenten selbst verwalten muss. Darauf folgt das benutzen von Helm als Paketmanager, welches Charts definiert. Charts sind Sammlungen an Komponentendefinitionsvorlagen, die mit einer Values-Datei zu vollwertigen Kubernetes-Komponentendefinitionen werden, um als konfigurierten Release auf das Cluster gespielt zu werden. Dies hat den Vorteil, dass Helm-Charts mit einem Befehl installiert, geupgraded und deinstalliert werden können und eine Versionierung zwischen den Releases existiert die Rollbacks ermöglicht. Glücklicherweise pflegen die Entwickler von Graylog ebenfalls solch einen Chart, wodurch ich von meiner spartanischen Erstimplementation auf eine allumfassend bessere Version wechseln konnte. Bei der Installation hatte ich gleichzeitig das erste mal Kontakt mit Operatoren, konkret dem vom Graylog-Helm-Chart genutzten MongoDB-Operator. Operatoren sind Kubernetes-Erweiterungen bestehend aus Custom-Resource-Definitions (kurz CRDs) und mindestens einem Pod, welcher Instanzen der definierten CRDs (Custom Resources, CRs) überwacht, und daraufhin das Cluster entsprechend bedient. Der MongoDB Operator überwacht z.B. das Cluster nach MongoDB-Komponenten, in welchen eine Datenbank definiert wird, und erstellt daraufhin dynamisch die Datenbank nach den Anforderungen. Falls die Komponente editiert oder gelöscht wird, wird die dadurch erstellte Datenbank dementsprechend editiert oder gelöscht. Somit Verwaltet der Operator den Lebenszyklus der angefragten Resource, und der anfragende Service muss sich nicht um die genaue Implementation, sondern nur den Finalzustand kümmern. Dieser Ansatz wird \glqq{}Infrastructure as Code\grqq{} genannt, da Infrastruktur (in diesem Fall Datenbanken) mithilfe von Code statt manueller Prozesse bereitgestellt wird, und somit Konsistenz, Auditierbarkeit, Transparenz und Skalierbarkeit gewährt.

\subsection{GatewayAPI}
Nachdem Graylog auf dem Cluster lief, war es jedoch noch nicht von extern erreichbar. Dafür ist Ingress zuständig. Ingress ist ein Spec, verwaltet von dem Kubernetes-Team\cite{k8sIngress}, welcher Layer 7 HTTP/S Routing erlaubt. Dieser Spec wird von IngressControllern implementiert, z.B. nginx oder Traefik. Da selektron jedoch nicht nur Layer 7, sondern auch Layer 4 Routing benötigt, um mit der SPS im Lager zu kommunizieren, wurde auf Ingress' Nachfolger, GatewayAPI gesetzt\cite{k8sGatewayAPI}. GatewayAPI ist genau wie Ingress ein Spec, welcher von extern programmierten GatewayControllern, z.B. Istio oder Traefik, implementiert wird. Er lernt aus den Defiziten von Ingress und trennt Routen, Gateways und GatewayClasses voneinander. Ebenfalls erlaubt er nicht nur HTTP/S, sondern auch gRPC, TCP und UDP-Verbindungen.
Da Graylogs Chart aktuell nativ kein GatewayAPI unterstützt, wurde außerhalb des Charts die Notwendige HTTPRoute deklariert. Um abschließend Graylog mit einer externen Startroutine zu konfigurieren wurde ein Kubernetes Job geschrieben, welcher alle notwendigen Eingabequellen mit passendem Port einrichtet.

\subsection{selektron}
Nachdem Graylog auf dem Cluster lief und ein initiales Verständnis für Kubernetes existierte, wurde sich der Portierung selektron auf einen Helm-Chart gewidmet. Als Grundlage für die Portierung wurde die Konfiguration eines Kundensystems übernommen. Während die Portierung schnell verlief, gab es eine Liste an Fehlern zu bewältigen. Da der selektron-Chart in einen anderen Namespace als Graylog deployed wird, war initiale Kommunikation zwischen den beiden Applikationen nicht möglich. Ein \texttt{ExternalName} Service wurde genutzt, um die Brücke zwischen den Namespaces zu bilden. Ebenfalls hat der Discovery- und Load-Balancing-Service, basierend auf Spring Boots Netflix Eureka, mit der Kubernetes Service-Schicht nicht kooperiert, da diese Domain-Namen und Container trennt, Eureka jedoch erwartet das jeder Container einen eigenen Domain-Namen hat. Glücklicherweise erlaubt Eureka für eine Entkopplung der beiden Komponenten. Grundsätzlich ist jedoch Eureka im Falle der Portierung von selektron auf Kubernetes nichtmehr von Nöten, da der komplette Aufgabenbereich von Kubernetes Service-Schicht bereits übernommen wird. Da es sich um einen Prototypen handelt, bleibt dieses Modul jedoch bestehen.

Generell ist der selektron-Chart Modular aufgebaut und erlaubt in einer Zentralen Datei das Ändern aller relevanten Parametern. Durch die hohe Konfigurabilität und Helms Unterstützung von \glqq{}Overlays\grqq{}, partiellen Konfigurationsdateien welche mit der Kern-Konfiguration zusammengeführt werden, um Wiederholungen zu vermeiden, können Änderungen einfach und gezielt vorgenommen werden. 

\subsection{Nutzeroberfläche}
Eine weitere Anforderung ist eine Verwaltungsübersicht für das Kubernetes-Cluster, da Werkzeuge wie \texttt{kubectl} und \texttt{Helm} zwar alle Funktionalitäten von Kubernetes abdecken, sich jedoch Personalschulung als aufwändig erweist und der Aufwand für simple und repetetive Aufgaben größer ist als Notwendig. Als Visualisierung wurde sich auf Headlamp\cite{uiHeadlamp}, den offiziellen Nachfolger des Kubernetes-Dashboards\cite{uiHeadlampDeprecated} und k9s\cite{uiK9s}, ein grafisches Kommandozeilentool geeinigt. k9s ist dabei besonders auf Geschwindigkeit und Tastaturbasiertes bedienen getrimmt, vergleichbar mit dem Text-Editor vim, und umfässt eher Aufgaben im Bereich des Developments von einzelnen Komponenten auf dem Cluster (Komponenten anzeigen \& editieren, Logs durchforsten). Headlamp bringt dagegen mehr Bedienkomfort, eine Standardmäßige Auflistung aller existierenden Kubernetes-Komponenten und CRDs (anstatt k9s' Such-basiertes Modell zur Komponentenauswahl), eine Map, welche existierende Komponenten miteinander Verbindet um sie Logisch zu gruppieren, und Plugin-Support. Da beide mit Kubeconfigs arbeiten, sind sie sofern \texttt{kubectl} eingerichtet ist, ohne weiteren Konfigurationsaufwand benutzbar. Besonders Headlamp hat für Überzeugung im Team gesorgt, da es auch ohne Kubernetes-Grundlagen vergleichsweise sehr einfach zu bedienen ist.

Eine klassische Serviceaufgabe wäre das Neustarten und Stoppen von Containern. Was mit dem originalen Setup mit einer Ansammlung fehleranfälliger Skripte ablief, kann somit über eine Nutzerfreundliche Oberfläche mit wenigen Clicks realisiert werden.

\textbf{TODO: VIELLEICHT PANEL FÜR RESTART ETC IN HEADLAMP / RADAR}

\subsection{Windows}
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.

\subsection{GitOps \& FluxCD}
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. 



\section{Evaluation}

Innerhalb der Praxisphase wurde eine modulares, funktionales, auditierbares, ausfallsicheres, einfacher Bedienbares Deployment von selektron auf Basis von Kubernetes ausgearbeitet. Mit Ausnahme der nativen Lauffähigkeit auf Windows wurden alle Ziele erreicht. Das zukünftige Ziel, das Cluster ohne Internetzugang aufzusetzen, ist Thema für eine folgende wissenschaftliche Arbeit im Firmenkontext.

\section{Fazit}

\newpage

\printbibliography%[title={Quellen}]

\end{document}