diff --git a/Praxisbericht.tex b/Praxisbericht.tex index 06d9c20..7db7d67 100644 --- a/Praxisbericht.tex +++ b/Praxisbericht.tex @@ -10,6 +10,7 @@ \usepackage[a4paper,left=25mm,right=35mm,top=25mm,bottom=30mm]{geometry} \usepackage{parskip} \usepackage{comment} %dies ist ein kommentar +\usepackage{wrapfig2} % tableau \usepackage{booktabs} \usepackage{multirow} % table stuff @@ -194,16 +195,8 @@ 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 es 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 \textit{Hyper-V} mitliefert\cite{windowsHyperVIntro}. Hyper-V ist Microsofts Type-1 (Bare-Metal) \textit{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 Betriebssystem laufen und daher unabhängig von dem Geschehen auf dem Host-System operieren, während Type-2 Hypervisor auf dem Host-Betriebssystem laufen. Damit sind Type-2 Hypervisor trivialer zu installieren und bedienen, jedoch langsamer. 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 von Hardware ein Performance-Verlust, sogenannter \textit{Overhead}, entsteht. Dieser ist besonders in I/O-Operationen, also dem Lesen und Schreiben von Daten, spürbar. Auch ist Networking innerhalb Hyper-V sehr fragil, sofern keine Hyper-V External Switches verwendet werden. 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 der vollständigen Migration von selektron erweisen. Somit bleibt Hyper-V eine Zwischenlösung. \subsection{GitOps \& FluxCD} -\textit{Drift} beschreibt Änderungen an der Server-Konfiguration, welche undokumentiert sind, ähnlich wie bei der Bootsfahrt, bei der unbekannte oder ungeplante Änderungen vom Kurs als Drift bezeichnet werden. Um zu verhindern, dass Drift entsteht, benötigt man eine Wahrheitsquelle. Das Konzept von \textit{GitOps} verfolgt den Ansatz, eine Git-Repository als Wahrheitsquelle zu definieren. Diese Git-Repository beschreibt den Wunschzustand der gesamten Infrastruktur. Operatoren auf dem Cluster synchronisieren die laufende Umgebung in definierten Abständen mit dem Wunschzustand. Dieser Vorgang ist dabei Teil des \textit{CI/CD-Prozess} (Continous Integration, Continous Delivery), konkret übernimmt es den Delivery-Aspekt, das Ausrollen von Änderungen auf dem Deployment-Server. Anders als bei einer klassischen CD-Pipeline, bei der Push-basiert von einem Build-Server auf den Deployment-Server (hier das Cluster) deployt wird, wird bei der GitOps-Pipeline Pull-basiert von einem auf dem Deployment-Server laufenden Operator in Intervallen die Git-Repository nach Änderungen überwacht, und im Falle einer Differenz zwischen Repository-Zustand und Server-Zustand die notwendigen Änderungen vorgenommen. Diesen Prozess nennt man \textit{Synchronisation} oder \textit{Reconciliation}. Somit sind Serverzustand und Git-Zustand äquivalent. Zusätzlich sind Änderungen auditierbar (Wer hat etwas geändert), differenzierbar (Was wurde genau geändert) und im Falle eines Problems zurücksetzbar. Dabei wurde sich für \textit{FluxCD}\cite{fluxCNCF} entschieden, eine der GitOps-Implmentationen für Kubernetes. Eine mögliche Alternative ist \textit{ArgoCD}, welches von Haus aus eine Nutzeroberfläche und weitere fortgeschrittene Features bietet, jedoch ist FluxCD weniger resourcenintensiv, nativer in das Kubernetes-Tooling verzahnt und integriert mit einem existierenden Headlamp-Plugin\cite{fluxHeadlampPlugin} nativ in die gewünschte Übersicht. Dabei hat FluxCD zwei für selektron relevante Pipelines: die GitOps-Pipeline und die Image-Controller-Pipeline. - -Die \textit{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 Git-, Helm- oder OCI-Repositories und speichert sie als Cluster-lokales Artefakt.\\ -Der \texttt{kustomize-controller}\cite{fluxKustomizeController} sucht nach auf dem Cluster existierenden Komponenten des Typs \texttt{Kustomization}, einer CR von FluxCD. In gewählten Abständen führt der Controller auf dem gegebenen Pfad einen \textit{Kustomize}-Befehl aus, produziert, ähnlich wie Helm, Manifest-Dateien, vergleicht diese mit den aktuellen Stand, und wendet sie bei Änderungen an. Damit wird nach jedem Intervall jeglicher Drift in den Konfigurationsdateien überschrieben. Die Kustomization-Komponente kann mit Parameter \texttt{prune} alle unter das Kustomization fallenden, nicht mehr existierenden, Komponenten automatisch aufräumen. Mit weiteren Parametern ist es möglich, die Kustomization so zu gestalten, dass alle Komponenten bereit sein müssen, 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 \textit{Image-Automation-Pipeline}\cite{fluxImagePipeline} besteht aus dem \texttt{image-reflector-controller}, welcher Container-Images überwacht und deren Metadaten speichert. Er wertet mit nutzerdefinierten Regeln die gespeicherten Metadaten aus, und entscheidet welches das zu benutzende Image 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 automatisieren und gleichzeitig die Synchronisation der Wunschkonfiguration aus einer gewählten Quelle und dem Clusterstatus übernehmen, um undokumentierte Zugriffe zurückzusetzen und einen höheren Transparenzgrad zu gewährleisten. +\textit{Drift} beschreibt Änderungen an der Server-Konfiguration, welche undokumentiert sind, ähnlich wie bei der Bootsfahrt, bei der unbekannte oder ungeplante Änderungen vom Kurs als Drift bezeichnet werden. Um zu verhindern, dass Drift entsteht, benötigt man eine Wahrheitsquelle. Das Konzept von \textit{GitOps} verfolgt den Ansatz, eine Git-Repository als Wahrheitsquelle zu definieren. Diese Git-Repository beschreibt den Wunschzustand der gesamten Infrastruktur. Operatoren auf dem Cluster synchronisieren die laufende Umgebung in definierten Abständen mit dem Wunschzustand. Dieser Vorgang ist dabei Teil des \textit{CI/CD-Prozess} (Continous Integration, Continous Delivery), konkret übernimmt es den Delivery-Aspekt, das Ausrollen von Änderungen auf dem Deployment-Server. Anders als bei einer klassischen CD-Pipeline, bei der Push-basiert von einem Build-Server auf den Deployment-Server (hier das Cluster) deployt wird, wird bei der GitOps-Pipeline Pull-basiert von einem auf dem Deployment-Server laufenden Operator in Intervallen die Git-Repository nach Änderungen überwacht, und im Falle einer Differenz zwischen Repository-Zustand und Server-Zustand die notwendigen Änderungen vorgenommen. Diesen Prozess nennt man \textit{Synchronisation} oder \textit{Reconciliation}. Somit sind Serverzustand und Git-Zustand äquivalent. Zusätzlich sind Änderungen auditierbar (Wer hat etwas geändert), differenzierbar (Was wurde genau geändert) und im Falle eines Problems zurücksetzbar. Dabei wurde sich für \textit{FluxCD}\cite{fluxCNCF} entschieden, eine der GitOps-Implmentationen für Kubernetes. Eine mögliche Alternative ist \textit{ArgoCD}, welches von Haus aus eine Nutzeroberfläche und weitere fortgeschrittene Features bietet, jedoch ist FluxCD weniger resourcenintensiv, nativer in das Kubernetes-Tooling verzahnt und integriert mit einem existierenden Headlamp-Plugin\cite{fluxHeadlampPlugin} nativ in die gewünschte Übersicht. +Mithilfe FluxCD wird ein Großteil des Deployments automatisiert, dabei höhere Transparenz erreicht und gleichzeitig undokumentierte Zugriffe vermieden. \subsection{Hochverfügbarkeit, Longhorn und CloudNativePG} @@ -232,7 +225,7 @@ Während Helm und FluxCD für ein einfaches Deployment sorgen, und cert-manager \subsection{Airgap-Installation} -Viele der Kunden haben strikte IT-Infrastrukturregeln, in welchem Zugang in das Internet stark beschränkt bis komplett deaktiviert ist. Dafür ist es notwendig, dass das komplette System ohne Internet aufgesetzt werden kann. Da Kubernetes eine Cloud-Native Lösung ist, stehen Probleme wie dieses nicht auf der Prioritätsliste der Kernentwickler, jedoch existieren Lösungen. Deren Ansätze fallen jedoch außerhalb des Zeitrahmens der Praxisphase und werden in der auf der Praxisphase aufbauenden Bachelorarbeit abgehandelt. +Viele der Kunden haben strikte IT-Infrastrukturregeln, in welchem Zugang in das Internet stark beschränkt bis komplett deaktiviert ist. Dafür ist es notwendig, dass das komplette System ohne Internet aufgesetzt werden kann. Da Kubernetes eine Cloud-Native Lösung ist, stehen Probleme wie dieses nicht auf der Prioritätsliste der Kernentwickler, jedoch existieren Lösungen. Deren Ansätze fallen jedoch außerhalb des Zeitrahmens der Praxisphase und werden in einer auf der Praxisphase aufbauenden Bachelorarbeit abgehandelt. \section{Evaluation}