Uni/praxisbericht
2
0
Fork 0
Code Issues Activity

HA cnpg longhorn

Browse Source
This commit is contained in:
Tim Wall
2026-06-08 15:02:38 +02:00
parent 1a11a8fb19
commit f0c2cf105e
1 changed files with 3 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
Praxisbericht.tex
View File

@@ -215,9 +215,11 @@ Die Image-Automation-Pipeline\cite{fluxImagePipeline} besteht aus dem \texttt{im
Mithilfe der beiden Pipelines kann FluxCD einen massiven Teil des Deployments übernehmen und gleichzeitig die Synchronisation der wunschkonfiguration aus einer gewählten Quelle und dem Clusterstatus übernehmen, um undokumentierte Zugriffe zu verhindern und einen höheren Transparenzgrad zu gewährleisten. Mithilfe der beiden Pipelines kann FluxCD einen massiven Teil des Deployments übernehmen und gleichzeitig die Synchronisation der wunschkonfiguration aus einer gewählten Quelle und dem Clusterstatus übernehmen, um undokumentierte Zugriffe zu verhindern und einen höheren Transparenzgrad zu gewährleisten.
\subsection{Secrets Operator} \subsection{High Availability, Longhorn und CloudNativePG}
Viele der Kunden sind an zunehmend an Ausfallsicherheit interessiert. Sofern eine Distribution ein High-Availability Control-Plane zur Verfügung stellt, ist dies für das Cluster realisierbar. Für einfache stateless Workloads, also Software die keine Daten zwischenspeichern muss, ist die Realisierung trivial: sie muss auf mehrere Nodes verteilt werden, und im Falle eines Ausfalls realisiert Kubernetes durch Health-Checks dass der Workload nichtmehr Aufnahmefähig ist und verschiebt die Anfragen. Bei Stateful Workloads wie Datenbanken ist der Prozess komplexer. Da bei einem Ausfall des Workloads oder der Node die an den Workload gebundenen Daten nichtmehr aufrufbar sind dürfen die Daten nicht nur an einem lokalen Punkt gespeichert werden. Dafür existieren Distributed Storage Provider. Ein Distributed Storage Provider kümmert sich um die Duplizierung von Daten innerhalb eines Clusters nach vorgeschriebenen Regeln, Realisiert in \texttt{StorageClass}-Objekten. Longhorn ist solch ein beliebter und einfach zu bedienender Distributed-Storage Provider, welcher die Replikation der Daten auf Clusterebene übernimmt, damit bei einem Ausfall von einer Node der Workload trotzdem mit minimalen bis keinem Datenverlust auf eine andere Node übergeben werden kann. Alternativ dazu gibt es auch Workloads, welche von sich aus die Replikation übernehmen können. Diese sind dem vorherigen darin Überlegen, dass die Software die Datenreplikation besser steuern kann, wodurch die Wahrscheinlichkeit für invalide Daten sinkt. Dazu gehört auch PostgreSQL, die Datenbank welche psb-intern genutzt wird. Da das Replizieren über Primary \& Secondary Datenbanken übernommen wird welche manuell zugewiesen werden müssen, bietet es sich an die Provision dieser von einem Operator zu übernehmen. CloudNativePG (kurz CNPG), ist ein Kubernetes-Operator, welcher die Provision von High-Availability Postgres-Datenbanken mit Failover bei Ausfall übernehmen kann, und somit perfekt geeignet ist. CNPG selbst braucht dabei keinen Distributed Storage da es durch die Anwendungsinterne Replikationslogik den Speicher verteilt.
Mit der Kombination aus Longhorn und CNPG können somit Stateful Workloads Highly-Available gemacht werden, um Ausfälle der Produktion zu vermeiden.
\subsection{Airgap-Installation} \subsection{Airgap-Installation}