Kubernetes

Dieses Kapitel skizziert den geplanten Aufbau von Business Flies im Kubernetes-Cluster. Die Struktur orientiert sich am Deployment der ETE-Anwendung: gemeinsame Kustomize-Basisressourcen werden durch umgebungsspezifische Overlays für Integration und Produktion ergänzt.

Die beschriebenen Namen und Parameter sind ein erster Planungsstand. Sie werden mit der tatsächlichen Implementierung abgeglichen und anschließend verbindlich dokumentiert.

Geplante Workloads

Workload	Aufgabe	Betriebsart
bflies-frontend	Auslieferung der Vue-3-Anwendung	Zustandsloses Deployment
bflies-backend	Spring-Boot-API und Fachlogik	Zustandsloses Deployment
bflies-mysql	Relationale Datenbank	Zustandsbehaftetes Deployment mit Persistent Volume
bflies-flyway	Kontrollierte Datenbankmigration	Job pro Release beziehungsweise Migration

Keycloak wird als vorhandener zentraler Identitätsdienst verwendet und gehört nicht zum Business-Flies-Deployment.

Umgebungen

Analog zu ETE werden genau zwei getrennte Zielumgebungen aufgebaut:

Umgebung	Namespace	Zweck
INT	bflies-int	Integrationstests, technische Prüfung und fachliche Abnahme
PROD	bflies-prod	Produktionsbetrieb

Die Administration erfolgt über Rancher im Projekt bflies.

INT und PROD erhalten jeweils einen eigenen Namespace, eigene Konfigurationen und Secrets, eigene Workloads, eigene Ingress-Ziele sowie einen getrennten persistenten Datenbankspeicher. Ressourcen oder Daten werden nicht zwischen den Umgebungen geteilt.

Die Kustomize-Basis enthält die gemeinsamen Objekte. Overlays setzen insbesondere Namespace, Namenspräfix, Labels, Images, Hosts, Konfigurationsdateien und Ressourcenlimits.

src/deployment/k8s/
|-- base/
|   |-- deployments
|   |-- services
|   |-- ingresses
|   `-- kustomization.yaml
`-- overlays/
    |-- int/
    |   |-- config
    |   |-- resource patches
    |   `-- kustomization.yaml
    `-- prod/
        |-- config
        |-- resource patches
        `-- kustomization.yaml

Erwartete Kubernetes-Objekte

Objektart	Erwartete Instanzen
Namespace	Je einer für INT und PROD
ConfigMap	Frontend-, Backend- und MySQL-Konfiguration
Secret	Backend-, Datenbank- und gegebenenfalls Registry-Zugangsdaten
Deployment	Frontend, Backend und MySQL
Service	Frontend, Backend und MySQL
Ingress	Frontend und Backend
PersistentVolume	Dauerhafter Datenbankspeicher je Umgebung
PersistentVolumeClaim	Bindung des Datenbankspeichers im Namespace
Job	Flyway-Migration vor einem Backend-Rollout
NetworkPolicy	Begrenzung der erlaubten Netzwerkpfade

Deployment

Rancher

• Erstellung eines neuen Projektes bflies in der Rancher UI.
• Erstellung zweier Namespaces bflies-int und bflies-prod im neuen Projekt.

Persistent Volume

• Erstellung eines neuen LUNs für das PersistentVolume, mit dem die Datenbank betrieben werden soll.
• Erstellung eines PersistentVolumeClaim pro Umgebung mit Verbindung zur PV.

Datenbank

• Deployment des Secret
• Deployment der ConfigMap
• Ausrollen des Deployment
• Das Service Objekt für den Zugriff im Cluster einrichten
• Anschließend Dump aus PROD zurücksichern

Unterkapitel

• Namespace
• ConfigMap
• Secret
• Deployment
• Service
• Ingress
• PersistentVolume
• PersistentVolumeClaim
• Job
• NetworkPolicy

Noch zu entscheiden

• konkrete Cluster- und Storage-Klasse beziehungsweise iSCSI-Zuordnung,
• produktive Hostnamen und Kontextpfade,
• Datenbankimage und Datenbankversion,
• Secret-Verwaltung im Cluster,
• Ausführungsmodell und Fehlerbehandlung des Flyway-Jobs,
• initiale CPU-/Memory-Werte und Skalierungsgrenzen,
• Notwendigkeit eines externen Datenbankzugangs per NodePort.