diff --git a/Praxisbericht.tex b/Praxisbericht.tex index bb52619..13819f2 100644 --- a/Praxisbericht.tex +++ b/Praxisbericht.tex @@ -170,12 +170,12 @@ Für das Evaluieren wurde entschlossen, eine möglichst Originalgetreue Distribu 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.~~~~~~~~~~~~~~~~~~~~~~~~~ +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. +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. -wurde der Prozess der selektron - -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. +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. \section{Methodik Erkenntnisse} diff --git a/literatur.bib b/literatur.bib index db53d5e..7fe5657 100644 --- a/literatur.bib +++ b/literatur.bib @@ -37,6 +37,22 @@ urldate = {2026-04-29} } +@online{k8sIngress, + author = {Kubernetes}, + title = {\glqq Ingress\grqq}, + url = {https://kubernetes.io/docs/concepts/services-networking/ingress/}, + urldate = {2026-05-04}, + date = {2025-11-24} +} + +@online{k8sGatewayAPI, + author = {Kubernetes SIG-Network}, + title = {\glqq Introduction: Kubernetes Gateway API\grqq}, + url = {https://gateway-api.sigs.k8s.io/}, + urldate = {2026-05-07}, +} + + @misc{rsFaq, author = {Rust Community}, title = {\glqq Frequently Asked Questions\grqq},