Spring Boot auf SKE mit PostgreSQL Flex und Gateway API

Überblick

Diese Architektur überführt die VM-basierte Spring-Boot- und PostgreSQL-Quelle in eine Kubernetes-Laufzeit mit Managed-Datenbank auf STACKIT. Dasselbe Anwendungs-JAR bleibt erhalten, während sich Bereitstellung, Deployment, Traffic-Steuerung, Daten-Recovery und Betriebsverantwortung ändern.

Die Referenzbasis verwendet einen SKE-Worker und PostgreSQL Flex mit Envoy Gateway, STACKIT DNS und Observability. Die zusätzlichen Dienste und die Multi-Zonen-Topologie des nachfolgenden optionalen Erweiterungsmusters werden nicht bereitgestellt.

Einsatz

• Laufzeit standardisieren: Einen systemd-verwalteten Java-Prozess durch ein reproduzierbares Deployment mit Zustandsprüfungen ersetzen.
• Datenbankbetrieb verlagern: PostgreSQL in einen Managed Service überführen, ohne das Anwendungsschema neu zu entwerfen.
• Plattformwechsel kontrollieren: Rollout, Skalierung, Netzwerkzugriff und Recovery vor der Produktionsabnahme unabhängig qualifizieren.

Architekturdiagramm

Laufzeit- und Datengrenzen

Ein Init-Container prüft die Prüfsumme des auf einen Commit fixierten JARs, bevor Java startet. Anwendungscontainer sind austauschbar: Die maßgeblichen Albumdaten liegen in PostgreSQL Flex, nicht im Pod-Dateisystem oder auf einem Kubernetes PersistentVolume. Kubernetes Secrets liefern Datenbankzugangsdaten; eine externe Secret-Manager-Integration ist in dieser Basis nicht implementiert.

Die Flex-ACL verwendet standardmäßig die tatsächlichen SKE-Egress-CIDRs. Anwendung und Migrationsclient benötigen verschlüsselte Datenbankverbindungen. Der Migrationsclient verwendet eine isolierte Probedatenbank und ersetzt Anwendungsdaten erst nach expliziter Freigabe und verifiziertem Backup vor dem Cutover. Für den dumpbasierten Pfad sind weder eine Verbindung zur Datenbank der Quell-VM noch eine temporäre öffentliche Flex-ACL nötig.

Netzwerkverkehr und Observability

Terraform installiert Envoy Gateway und anschließend ein lokales Routing-Chart. Der Anwendungs-Service ist vom Typ ClusterIP; Envoy stellt den öffentlichen LoadBalancer bereit. SKE-verwaltetes ExternalDNS veröffentlicht den HTTPRoute-Hostnamen anhand der Gateway-Adresse. Dies ist Gateway API, kein älterer Ingress-Controller und kein separat bereitgestellter STACKIT Application Load Balancer Service.

HTTP ist der getestete Standard. Stellen Sie für HTTPS ein vertrauenswürdiges TLS-Secret bereit und konfigurieren Sie gateway_tls_secret_name nach dem Repository-Verfahren. Ausstellung und Erneuerung von Zertifikaten bleiben externe Aufgaben. Die separaten Metrik-Listener sind in der Referenz öffentlich und ohne Authentifizierung erreichbar; schützen Sie sie vor sensibler Nutzung.

Boot 2 Actuator bindet an das pod-lokale Loopback; der Metrikadapter veröffentlicht ausgewählte Messwerte. PostgreSQL-Exporter und SKE-Monitoring-Integration beliefern Observability. Terraform erstellt Grafana-Ordner und Dashboard. Dessen Verfügbarkeit allein weist jedoch weder Anwendungszustand noch durchgängiges Scraping oder funktionierende Alarmzustellung nach.

Entscheidungen zu Verfügbarkeit und Recovery

Die getestete Worker-Anzahl, der HTTP-Endpunkt und die Beispielanwendung bilden eine funktionale Basis, keine hochverfügbare Produktionsarchitektur. Wählen Sie eine unterstützte SKE-Version und passende Zonenkapazität. Bewerten Sie mehrere Worker, Zonenverteilung, Disruption Budgets, Replikasicherheit, Datenbankverfügbarkeit und das Traffic-Routing als separate Designentscheidungen mit Ausfalltests.

Der Datenbank-Rollback stellt das Ziel vor dem Cutover wieder her; Managed-Flex-Backups dienen der Service-Recovery. Keiner der beiden Wege leitet Benutzer automatisch zur Quell-VM zurück. Definieren Sie Schreibverantwortung, Befugnis zur Traffic-Umschaltung, Rollback-Deadline, Aufbewahrung und Recovery-Ziele vor der Migration.

Optionales Erweiterungsmuster

Das folgende umfassendere Design zeigt mögliche Ergänzungen, keine vom Referenz-Terraform erstellten Ressourcen. Weitere Node Pools, Topologieregeln, persistente Volumes, RabbitMQ, Object Storage und Secret Manager benötigen eigene Implementierung, Verantwortlichkeiten und Validierung. Nutzen Sie sie nur bei nachgewiesener Workload-Anforderung; leiten Sie aus dem Diagramm keine Hochverfügbarkeit ab.

Designprinzipien

• Freigaben für Laufzeit und Datenmigration entkoppeln: Datenbankmigration und Laufzeit-Rollout unabhängig validieren.
• Secret-Bereitstellung explizit entwerfen: Die Referenz nutzt Kubernetes Secrets und geschützten Terraform-State; bei Bedarf eine geprüfte externe Secret-Integration ergänzen.
• Observability-Labels und Dashboards standardisieren: Betrieb und Incident-Behandlung über Anwendungen hinweg vereinheitlichen.
• RabbitMQ bewusst optional halten: Nur bei Bedarf an asynchroner Integration oder Pufferung ergänzen.
• Verfügbarkeit separat qualifizieren: Ein Multi-Zonen-Design benötigt geeignete Worker-Kapazität, Platzierungsregeln, Disruption Budgets und Ausfalltests für Anwendung und Datenbank; die Basis aktiviert dies nicht.

Weiterführendes

Cloud Framework Spring Boot mit Terraform auf eine neue Plattform umstellen Den ausführbaren Workflow für Bereitstellung, Quellnachweise, Probe, Cutover und Rollback dieser Architektur nutzen. Seite öffnen

Repository

Code & Registry github.com STACKIT CMF Replatform Spring Boot Kubernetes Repository Repository öffnen

1. Datei aus dem Beispiel kopieren: cp env.tfvars.example env.tfvars
2. Erforderliche Werte für Identität und Projekt setzen:

service_account_key_path    = "/path/to/stackit-sa-key.json"
create_project              = true
target_project_owner_email  = "owner@sa.stackit.cloud"
parent_container_id         = "cmf-parent-container-id"
ske_cluster_name            = "rpltfk8s01"
observability_instance_name = "cmf-rpltf-observability"
dns_zone_name               = "cmf-example.runs.onstackit.cloud"
dns_zone_display_name       = "cmf-example"

3. Zielarchitektur-Flags setzen:

observability_enabled         = true
create_observability_instance = true
dns_enabled                   = true
create_dns_zone               = true
deploy_workload               = true
enable_postgres_flex          = true
enable_springboot_hpa         = false
enable_load_generator         = false
springboot_replicas           = 1
deploy_postgres_migration_job = false
create_grafana_dashboard     = true

4. Optionaler CMF-Flag-Wrapper (flags.env):

setup_project=true
setup_observability=true
setup_database=true
setup_workload=true
setup_loadgen=false
setup_dns=true

5. Ausführen:

terraform init
terraform validate
terraform plan -var-file=env.tfvars -out=tfplan
terraform apply tfplan

Erwartetes Ergebnis: springboot_url erreicht die Anwendung über das Gateway, die Anwendung nutzt PostgreSQL Flex und grafana_dashboard_url öffnet das verwaltete Dashboard. Die Bereitstellung importiert keine Quelldaten. Führen Sie nach der Zielvalidierung den separaten Probe- und Cutover-Workflow aus; lassen Sie HPA während der gesamten Migration deaktiviert.

Code & Registry github.com Implementierte Topologie und Voraussetzungen Genaue Ressourcendefinitionen und betriebliche Grenzen im Spring-Boot-Replatform-Repository prüfen. Repository öffnen