source + anfang 5

Praxisbericht.tex

@@ -24,8 +24,8 @@
 \usepackage{listings} % code blocks
 \usepackage{xcolor}
 
-%\usepackage[backend=biber, style=numeric, url=true]{biblatex} %URL in biblatex
-%\addbibresource{literatur.bib}
+\usepackage[backend=biber, style=numeric, url=true]{biblatex} %URL in biblatex
+\addbibresource{literatur.bib}
 %\bibliography{literatur} %bibtex
 
 \graphicspath{{graphics/}}
@@ -131,7 +131,7 @@ Der Praxisbericht ist eines der resultierenden Elemente, in welchem das Unterneh
 
 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{}. Das Unternehmen beschäftigt knapp unter 550 Mitarbeiter, darunter Ingenieure, Softwareentwickler, SPS-Programmierer, Fertigung, Montage, Materialbeschaffung, Logistik, Vertrieb, IP-Verwaltung (geistiges Eigentum) sowie Managementebene.
+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.
 
@@ -158,17 +158,26 @@ Mein Arbeitsplatz befindet sich im Herz der PA INF GUI. Während der Name auf al
 
 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 und 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.
+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}
+\section{Vorgehensweise}
+
+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} und zuletzt OKD, die Communitygetriebene Version von OpenShift ohne Enterprise-Support\cite{distroOKD}.
+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 übrig blieben. Da k3s mit einfacher Installation ü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.
+
+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.
+
+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, welcher Layer 7 HTTP 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. GatewayAPI ist genau wie Ingress ein Spec, welcher von GatewayControllern implementiert wird. Er lernt aus den Defiziten von Ingress und trennt Routen, Gateways und GatewayClasses voneinander. Ebenfalls erlaubt er nicht nur HTTP, sondern auch gRPC, TCP und UDP-Verbindungen.~~~~~~~~~~~~~~~~~~~~~~~~~
 
 
+wurde der Prozess der selektron
 
-\section{Erkenntnisse}
+Um Kubernetes-Erweiterungen und Module zu Testen, wurde auf einen iterativen Test-Berwertungszyklus zum systematischen Validieren gesetzt. Im Zentrum steht die schrittweise Integration einzelner Module in eine bestehende Test-Suite, gefolgt von einer detaillierten Analyse ihres Beitrags zum Gesamtsystem. 
 
+\section{Methodik Erkenntnisse} 
 
 
 \section{Evaluation}
@@ -176,6 +185,8 @@ Die gewonnenen Erkenntnisse dienen als Entscheidungsgrundlage für eine möglich
 
 \section{Fazit}
 
+\newpage
 
+\printbibliography%[title={Quellen}]
 
 \end{document}