Replatform to STACKIT: Spring Boot auf SKE und PostgreSQL Flex

Spring-Boot-Replatform mit SKE, PostgreSQL Flex, Gateway API, DNS und Observability entwerfen und die getestete Basis von künftigen Erweiterungen klar trennen.

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

STACKIT

Der souveräne europäische Cloud-Anbieter hinter dem Framework, mit IaaS und PaaS aus deutschen und österreichischen Rechenzentren und voller Unabhängigkeit.

Ü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

Repository

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

Datei aus dem Beispiel kopieren: cp env.tfvars.example env.tfvars
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"

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

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

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

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

LIVE

Referenzimplementierung

Migration design-and-mobilize use-cases runnable-example replatform kubernetes terraform ske spring-boot postgresql

Spring Boot mit Terraform von der VM auf Kubernetes umstellen

STACKIT

Dasselbe Spring-Boot-JAR auf STACKIT Kubernetes betreiben: mit PostgreSQL Flex, Gateway API, DNS, Managed Telemetry sowie geprobtem Daten-Cutover und Rollback.

Code & Registry github.com STACKIT Spring Boot Kubernetes Replatform Repository Terraform, Gateway API, PostgreSQL-Migration und Observability der in diesem Asset verwendeten Implementierung öffnen. Repository öffnen

STACKIT

Der souveräne europäische Cloud-Anbieter hinter dem Framework, mit IaaS und PaaS aus deutschen und österreichischen Rechenzentren und voller Unabhängigkeit.

Überblick

Dieses Asset wendet das Migration Framework auf ein Replatform von Spring Boot und PostgreSQL an: Die Anwendung wechselt vom VM-Service zu STACKIT Kubernetes Engine (SKE), die Datenbank von selbstverwaltetem PostgreSQL zu STACKIT PostgreSQL Flex. Geschäftsfunktion und Anwendungs-JAR bleiben unverändert; die Betriebsmodelle für Laufzeit und Datenbank ändern sich.

Referenzimplementierung

Das Referenzrepository ist die maßgebliche Quelle für Terraform, Helm-Charts, fest versionierte Artefakte, Migrationsskripte und Validierung. Verwenden Sie einen geprüften Stand mit den hier beschriebenen Gateway-API- und scripts/migrate_postgres.py-Workflows. Ein älterer Stand mit direktem Datenbank-Import-Job implementiert dieses Verfahren nicht.

Replatform-Scope in diesem Asset

Laufzeit: Dasselbe Spring-Music-JAR mit Spring Boot 2.4.0 läuft auf Java 11 in einem Kubernetes-Deployment statt unter systemd.
Daten: PostgreSQL Flex stellt getrennte Anwendungs- und Probedatenbanken bereit; JDBC- und Migrationsclients benötigen TLS.
Netzwerkverkehr: Envoy Gateway, Gateway API HTTPRoutes und SKE-verwaltetes ExternalDNS ersetzen den VM-Endpunkt.
Betrieb: Kubernetes-Zustands- und Ressourcenkontrollen ersetzen das Host-Service-Management; Managed Telemetry erfasst Cluster-, Anwendungs- und Datenbanksignale.
Migration: Quellnachweise, isolierte Probe, explizit freigegebener Cutover und verifizierter Datenbank-Rollback bleiben von der Infrastrukturbereitstellung getrennt.

Cloud Foundry, Object Storage, die Zerlegung in Microservices und Anwendungsmodernisierung sind nicht Teil dieser Implementierung. Die alte Beispielanwendung demonstriert einen Plattformwechsel; sie ist keine Empfehlung, einen nicht mehr unterstützten Anwendungsstack produktiv einzusetzen.

Architekturdiagramm der Referenz

Prüfen Sie das Architektur-Asset vor der Wahl von Kapazität und Netzwerkkontrollen. Es trennt die implementierte Topologie von Produktionserweiterungen wie öffentlichem HTTPS, hochverfügbaren Workern und geschützten Metriken.

Cloud Framework Spring Boot auf SKE mit PostgreSQL Flex und Gateway API Implementierte Topologie, Laufzeit- und Datengrenzen sowie separat zu qualifizierende Produktionserweiterungen prüfen. Seite öffnen

End-to-End-Ablauf

Replatform-Eignung, Quellkompatibilität, Landing-Zone-Bereitschaft und Verantwortlichkeiten bestätigen.
Einen vertrauenswürdigen PostgreSQL-Dump und ein Integritätsmanifest unabhängig vom Ziel vorbereiten.
Terraform für SKE, PostgreSQL Flex, Gateway, DNS, Workload und Observability prüfen und anwenden.
Das Ziel validieren und den finalen Quelldump in der isolierten Probedatenbank testen.
Quellschreibzugriffe einfrieren, Ausfallzeit freigeben und den kontrollierten Cutover mit geschütztem Zielbackup ausführen.
Anwendungs- und Datennachweise abnehmen oder den Zielzustand vor dem Cutover wiederherstellen; den Client-Traffic nach dem freigegebenen Betreiberverfahren umschalten.
Nachweise während der Stabilisierung aufbewahren und repräsentative Telemetrie für spätere Optimierung nutzen.

Arbeitsumgebung für den Walkthrough vorbereiten

Verwenden Sie eine isolierte Linux-Laborumgebung mit Git, Terraform, kubectl, curl, jq, getent, Python ab Version 3.11 sowie PostgreSQL-Server- und Client-Werkzeugen. Die Rehost-Beispielskripte benötigen außerdem runuser, sha256sum, ein Betriebssystemkonto postgres und Root-Rechte, um eine temporäre lokale Datenbank zu erstellen und zu prüfen. Führen Sie die Beispielbefehle in dieser vorbereiteten Laborumgebung aus, nicht auf einem produktiven Datenbankhost. Die privaten Artefakte müssen für den Migrationsbediener lesbar bleiben; machen Sie sie nicht für alle Benutzer lesbar.

Beziehen Sie geprüfte Commit-IDs beider Repositorys vom Referenz-Maintainer und exportieren Sie diese vorab als REHOST_REVISION und REPLATFORM_REVISION. Der Replatform-Stand muss Gateway API und den freigabegesteuerten Migrationsworkflow enthalten. Setzen Sie nicht voraus, dass der Remote-Standardbranch bereits die lokal getestete Implementierung enthält. Ist der freigegebene Stand nicht verfügbar, beschaffen Sie ihn vor dem Walkthrough.

Ersetzen Sie beide Platzhalter durch die freigegebenen vollständigen Commit-IDs mit jeweils 40 Zeichen und setzen Sie diese im selben Bash-Terminal:

export REHOST_REVISION="REPLACE_WITH_REVIEWED_REHOST_COMMIT_ID"
export REPLATFORM_REVISION="REPLACE_WITH_REVIEWED_REPLATFORM_COMMIT_ID"

Führen Sie den folgenden Block vollständig aus einem leeren Arbeitsverzeichnis aus. Die if-Prüfung lehnt fehlende, leere oder falsch formatierte IDs einschließlich unveränderter Platzhalter ab. Jedes && führt den nächsten Befehl nur nach Erfolg des vorherigen aus. Git prüft die Verfügbarkeit der Commits; die Formatprüfung allein bestätigt weder Freigabe noch Repository-Inhalt.

if [[ ! ${REHOST_REVISION:-} =~ ^[0-9a-fA-F]{40}$ ||
      ! ${REPLATFORM_REVISION:-} =~ ^[0-9a-fA-F]{40}$ ]]; then
  printf '%s\n' "Set both revision variables to reviewed full 40-character commit IDs." >&2
  false
else
  umask 077 &&
    git clone https://github.com/stackitcloud/stackit-cmf-Rehost-springboot.git &&
    git clone https://github.com/stackitcloud/stackit-cmf-replatform-springboot-k8s.git &&
    git -C stackit-cmf-Rehost-springboot checkout --detach "$REHOST_REVISION" &&
    git -C stackit-cmf-replatform-springboot-k8s checkout --detach "$REPLATFORM_REVISION" &&
    test -f stackit-cmf-replatform-springboot-k8s/scripts/migrate_postgres.py &&
    test -f stackit-cmf-replatform-springboot-k8s/scripts/validate_gateway.sh &&
    cd stackit-cmf-replatform-springboot-k8s &&
    printf '%s\n' "Workspace ready. Continue from this Replatform checkout." || {
      printf '%s\n' "Preparation failed. Resolve the error before continuing." >&2
      false
    }
fi

Fahren Sie erst nach der Meldung Workspace ready fort. Bei Fehlern bleibt das Terminal offen; weitere Vorbereitungsbefehle werden übersprungen. Vorhandene oder teilweise geklonte Verzeichnisse werden weder entfernt noch überschrieben: Prüfen Sie diese und bewahren Sie lokale Änderungen, bevor Sie es in einem neuen leeren Arbeitsverzeichnis erneut versuchen. Nach Erfolg befindet sich das Terminal für die nächsten Schritte im Replatform-Checkout.

Nutzen Sie ein freigegebenes STACKIT Projekt, einen Service Account, DNS-Delegation, SKE-Kapazität und ein geschütztes Terraform-Backend. Beziehen Sie Zugangsdaten über den freigegebenen Secret-Kanal, niemals aus diesem Trail. Die folgenden Befehle setzen diese Verzeichnisstruktur und eine geprüfte Konfiguration voraus; sie belegen keinen validierten Greenfield-Produktionsaufbau.

Quellnachweise vorbereiten

Qualifizieren Sie einen konsistenten Quelldump und sein Manifest, bevor Daten in den Migrationsworkflow eingehen.

Die Rehost-Referenz liefert scripts/create_source_dump.sh und scripts/validate_source_dump.sh für ihr reproduzierbares Beispiel. Führen Sie diese im Rehost-Repository aus. Dessen Verzeichnis artifacts liefert source-postgresql.dump und source-postgresql.manifest an den Replatform-Workflow. Das Manifest erfasst Version 1, table=public.album, row_count, album_fingerprint und dump_sha256.

Führen Sie ausschließlich für das reproduzierbare Beispiel die folgenden Befehle vom Replatform-Checkout in der vorbereiteten Laborumgebung aus. Die Skripte erstellen aus dem versionierten Beispiel-SQL eine temporäre PostgreSQL-Instanz, exportieren sie und führen einen unabhängigen Test-Restore aus. Verwenden Sie ein frisches Artefaktverzeichnis; überschreiben Sie keine Nachweise einer bereits laufenden Migration.

umask 077
pushd ../stackit-cmf-Rehost-springboot
bash scripts/create_source_dump.sh
bash scripts/validate_source_dump.sh
popd

Erwartet wird eine erfolgreiche Validierung von acht Zeilen mit passendem Fingerprint. Diese Befehle lesen keine Quell-VM aus. Verwenden Sie für Probe und Cutover genau diese Artefakte weiter.

Ersetzen Sie für eine reale Quelle den Beispielgenerator durch ein freigegebenes Exportverfahren: Frieren Sie alle Schreibzugriffe ein und leiten Sie Dump im Custom-Format und Manifest aus demselben konsistenten Quellsnapshot ab. Das generierte Beispiel mit acht Alben ist kein Export einer beliebigen laufenden VM. Prüfen Sie vor dem Export PostgreSQL-Kompatibilität, Erweiterungen, Eigentümerschaft und Schemaabhängigkeiten.

Stellen Sie nur vertrauenswürdige Dumps wieder her, da sie SQL ausführen. Diese Implementierung migriert das Anwendungsschema public und prüft public.album; von Flex verwaltete Schemas sind bewusst ausgeschlossen. Andere Workloads benötigen eigene Invarianten und einen angepassten Schemaumfang.

Code & Registry github.com Spring-Boot-Rehost-Quelle und Beispielexport Das Rehost-Repository liefert dasselbe Anwendungsartefakt und reproduzierbare Werkzeuge für PostgreSQL-Quellnachweise. Repository öffnen

Ziel bereitstellen

Stellen Sie das Ziel aus einem geprüften Plan mit expliziten Angaben zu Projekt, Kapazität, Zugriff und DNS bereit.

Verwenden Sie Terraform, kubectl, curl, jq, getent und Python ab Version 3.11 unter Linux. Kopieren Sie env.tfvars.example nach env.tfvars und passen Sie die tatsächlichen Variablen dieser Datei an. Behalten Sie die getestete Provider-Lockdatei und unveränderliche Image- und JAR-Referenzen bei. Bestätigen Sie vor dem Plan die Verfügbarkeit der SKE-Version, Node-Pool-Kapazität, Projektberechtigungen und DNS-Delegation.

Aus der STACKIT-DokuLifecycle of Kubernetes Engine › Kubernetes end-of-life datesStand der Quelle 24.08.2026 · übernommen 05.10.2026

Starting with Kubernetes v1.33, we remove minor versions on the patch day that precedes the upstream maintenance end-of-life (EOL) date. The following table below lists the upstream EOL date for each Kubernetes minor version and the corresponding expiration date in SKE:

Seitlich wischen, um die ganze Tabelle zu sehen

Kubernetes minor version	End-of-life date	Expiration in SKE
v1.32	2026-02-28	2026-04-15
v1.33	2026-06-28	2026-06-10
v1.34	2026-10-27	2026-10-14
v1.35	2027-02-28	2027-02-10

Please refer to the official Kubernetes Release History for up-to-date announcements of new versions.

Was ist das?

Dieser Abschnitt wird mehrmals am Tag automatisch aus der STACKIT-Doku übernommen. Hier lässt er sich nicht ändern. Änderungen gehören in die STACKIT-Doku.

Bevorzugen Sie ein freigegebenes Application-Landing-Zone-Projekt. Setzen Sie create_project = false und geben Sie Projekt-ID und Pfad zum Service-Account-Schlüssel an. Die alternative Projekterstellung setzt einen freigegebenen übergeordneten Container und Berechtigungen voraus; sie ersetzt keine Landing-Zone-Governance. Zugangsdaten, State, gespeicherte Pläne und Migrationsnachweise gehören nie in die Versionsverwaltung.

Erstellen Sie für einen neuen Checkout die private Variablendatei, ohne eine vorhandene zu überschreiben:

umask 077
test -e env.tfvars || cp env.tfvars.example env.tfvars
chmod 600 env.tfvars

Bearbeiten Sie diese Datei vor dem Plan: Tragen Sie freigegebenes Projekt und Service-Account-Pfad, Region, unterstützte SKE-Version, verfügbaren Node-Pool-Flavor samt Zone und delegierte DNS-Einstellungen aus dem Repository-Beispiel ein. Prüfen Sie Backend-Zugriff und Sperren, Quotas, Kosten sowie die Grenzen von HTTP und öffentlichen Metriken. Die folgenden Funktionsschalter bilden keine vollständige Umgebungskonfiguration.

Einheitliche Automatisierungs-Flags

Der optionale gemeinsame Wrapper bildet setup_project, setup_observability, setup_database, setup_workload, setup_loadgen und setup_dns auf die Terraform-Schalter des Repositorys ab. Sie wählen ausschließlich den Bereitstellungsumfang: Das Aktivieren der Datenbank erlaubt keinen Datenaustausch und ersetzt niemals die separate Migrationsfreigabe.

Minimale Zielkonfiguration

Diese Werte aktivieren den vollständigen Workload- und Datenbankpfad. Sie ergänzen die Angaben zu Projekt, Region, Node Pool und DNS im Repository-Beispiel, ersetzen sie aber nicht.

deploy_workload                   = true
dns_enabled                       = true
enable_postgres_flex              = true
postgres_flex_target_database     = "springmusic"
postgres_flex_target_app_acl_cidrs = []
observability_enabled             = true
create_observability_instance     = true
create_grafana_dashboard          = true
enable_springboot_hpa              = false
enable_load_generator             = false
deploy_postgres_migration_job      = false

Lassen Sie HPA und Lastgenerierung während der Migration deaktiviert. Wählen Sie Alarmeinstellungen bewusst; die Alarmzustellung wurde im End-to-End-Test nicht validiert. springboot_image wählt die Java-Laufzeit, nicht ein beliebiges vorgefertigtes Anwendungsimage. Der Init-Container lädt das auf einen Commit fixierte Rehost-JAR und prüft vor dem Start seinen SHA-256-Wert. Spiegeln Sie unveränderliche Artefakte für die Produktion in freigegebene Artefakt- und Image-Dienste.

Führen Sie die Befehle im Replatform-Repository aus und prüfen Sie den gespeicherten Plan vor dem Apply:

umask 077
terraform init
terraform validate
terraform plan -var-file=env.tfvars -out=tfplan
terraform apply tfplan
bash scripts/validate_gateway.sh

Zugriffskontrolle und temporäre ACL-Erweiterung für Migration

Bei leeren Anwendungs-ACL-Eingaben verwendet Terraform die tatsächlichen Egress-CIDRs des SKE-Clusters für PostgreSQL Flex. Explizite Anwendungs- oder ältere ACL-Werte überschreiben diesen Standard und müssen geprüft werden. Erlauben Sie nicht 0.0.0.0/0.

Der temporäre PostgreSQL-Client läuft in SKE und erhält den Dump über kubectl. Er verbindet sich nicht direkt mit der Quell-VM; weder Quell- noch Arbeitsplatz-CIDRs benötigen temporären Flex-Zugriff. JDBC und Datenbankwerkzeuge verwenden sslmode=require: Das erzwingt Verschlüsselung, bietet aber nicht die Hostnamenprüfung von verify-full. Schützen Sie Zugangsdaten in Kubernetes Secrets und im Terraform-Backend und validieren Sie bei Bedarf eine stärkere Zertifikatsprüfung.

Migration proben

Stellen Sie den finalen Dump in der isolierten Probedatenbank wieder her und verlangen Sie passende Nachweise, die jünger als 24 Stunden sind.

Führen Sie nach dem Infrastruktur-Apply einen isolierten Restore in springmusic_rehearsal aus. Passen Sie das Quellverzeichnis an die freigegebenen Artefakte an und halten Sie den Nachweispfad privat.

python3 scripts/migrate_postgres.py rehearse \
  --artifacts ../stackit-cmf-Rehost-springboot/artifacts \
  --evidence .tmp/migration-run

Die Probe validiert Manifest, Dump-Prüfsumme, Zielidentität, Zeilenanzahl und Fingerprint, ohne die Anwendungsdatenbank zu ersetzen. Proben Sie nach dem Schreibstopp auf der Quelle erneut mit dem finalen Dump. Der Cutover verlangt passende Nachweise, die jünger als 24 Stunden sind. Eine erfolgreiche Probe mit einem älteren oder anderen Dump gibt die finale Eingabe nicht frei.

Option: VM-PostgreSQL nach PostgreSQL Flex migrieren

Der alte Pfad deploy_postgres_migration_job = true wird durch die Validierung gesperrt. Nutzen Sie stattdessen den freigabegesteuerten Workflow. Stoppen Sie HPA, Lastgenerierung und alle anderen Zielschreiber. Pausieren Sie Terraform- und GitOps-Reconciliation, solange das Skript die Replikazahl steuert. Seine lokale Sperre schützt nur einen Checkout, nicht vor gleichzeitigen Bedienern auf unterschiedlichen Rechnern.

python3 scripts/migrate_postgres.py cutover \
  --artifacts ../stackit-cmf-Rehost-springboot/artifacts \
  --evidence .tmp/migration-run \
  --source-write-frozen --confirm-target springmusic

Das Quellschreibstopp-Flag ist eine Bestätigung des Betreibers, keine automatische Abschaltung der Quelle. Der Cutover skaliert die Anwendung auf null, sichert das Ziel vor dem Cutover und prüft die Sicherung per Prüfsumme. Er weist ihre Wiederherstellbarkeit in der Probedatenbank nach und stellt erst dann die Quelle transaktional wieder her. Vor dem Wiederanlauf mit ursprünglicher Replikazahl werden die Daten geprüft. Bei Fehlern bleibt die Anwendung zur Untersuchung gestoppt. Bewahren Sie Nachweisjournal und Backup auf; überschreiben Sie sie nicht für einen erneuten Versuch.

Validieren und zurückrollen

Vergleichen Sie Datenbanknachweise mit dem Quellmanifest, prüfen Sie das Anwendungsverhalten über das Gateway und bestätigen Sie den Zustand beider Metrik-Jobs. Traffic-Umschaltung und fachliche Abnahme bleiben Betreiberaufgaben; das Skript ändert den Endpunkt der Quellanwendung nicht.

So stellen Sie die geschützte Zieldatenbank aus der Zeit vor dem Cutover wieder her:

python3 scripts/migrate_postgres.py rollback \
  --evidence .tmp/migration-run --confirm-target springmusic

Der Rollback prüft Zielidentität und Backup-Integrität, sichert das aktuelle Ziel separat, stellt die ursprünglichen Daten wieder her und verifiziert vor dem Wiederanlauf deren Fingerprint. Schreibzugriffe nach dem Cutover werden nicht zusammengeführt; bewahren Sie den Dump vor dem Rollback für einen expliziten Abgleich auf. Dies ist ein Zieldatenbank-Rollback, kein automatischer Failback zur Quell-VM.

Datenbank-Metriken in Observability sichtbar machen

Terraform verwaltet den Grafana-Ordner SCF Replatform und das Dashboard mit acht Panels an der vorhandenen Datenquelle Thanos. Öffnen Sie es über grafana_dashboard_url. Cluster-CPU, Cluster-Speicher, laufende Pods, Anwendungsanfragen sowie PostgreSQL-Zustand und -Auslastung unterstützen Abnahme und spätere Optimierung. Ein manueller Dashboard-Import ist nicht nötig.

Anwendungsmetriken stammen aus dem pod-lokalen Boot-2-Actuator über den Metrikadapter auf Port 9090; der PostgreSQL-Exporter nutzt Port 9187. Prüfen Sie beide tatsächlichen Scrape-Ergebnisse, nicht nur die Dashboard-Darstellung. Fehlende Telemetrie ist ein Untersuchungsgrund, niemals der Nachweis fehlender Last.

Validierung mit kubectl

Exportieren Sie eine kurzlebige Kubeconfig mit privaten Berechtigungen und prüfen Sie den Standard-Namespace der Referenz:

umask 077
mkdir -p .tmp
terraform output -raw kubeconfig > .tmp/replatform.kubeconfig
export KUBECONFIG="$PWD/.tmp/replatform.kubeconfig"
kubectl get deploy,svc,pods -n springboot
kubectl get gateway,httproute -n springboot
kubectl rollout status deployment/springboot -n springboot
bash scripts/validate_gateway.sh

Der Gateway-Validator prüft Akzeptanz, aufgelöste Routenreferenzen, DNS und Anwendungsantwort. Entfernen Sie die lokale Kubeconfig nach Gebrauch und beziehen Sie nach Ablauf eine neue. Ein erfolgreicher Rollout allein ist keine Daten- oder fachliche Abnahme.

Grenze zwischen Backup und Recovery

Trennen Sie Migrations-Rollback von Flex-Service-Recovery und bewahren Sie geschützte Nachweise außerhalb kurzlebiger Ausführungsumgebungen auf.

Die Flex-Aufbewahrung wird explizit konfiguriert; der Standard dieser Referenz beträgt 32 Tage. Managed-Datenbankbackups und der Migrationsdump vor dem Cutover dienen unterschiedlichen Zwecken. Die Probe mit Letzterem weist weder Managed-Service-Restore noch Point-in-Time-Recovery oder Disaster Recovery der Anwendung nach. Benennen Sie Recovery-Verantwortliche und testen Sie den benötigten Service-Recovery-Pfad separat.

Bewahren Sie geschützte Nachweise und Backups bis zum Ende des Rollback-Fensters außerhalb eines kurzlebigen Dev Containers auf. Prüfen Sie nach einem abgebrochenen Migrationsprozess verbliebene Pods mit Präfix springmusic-migration-*, bevor Sie fortfahren; starten Sie ein ungeprüftes Ziel nicht durch Terraform neu.

Was dieses Asset zeigt

Dieses Asset zeigt, wie das Anwendungsverhalten beim Wechsel der Betriebsmodelle für Laufzeit und Datenbank erhalten bleibt:

Plattformwechsel: Dasselbe Spring-Boot-JAR auf SKE betreiben, über TLS mit PostgreSQL Flex verbinden und über Gateway API und DNS erreichbar machen.
Kontrollierte Datenmigration: Quelldump und Manifest qualifizieren, einen isolierten Restore proben und vor dem Cutover eine explizite Freigabe sowie ein verifiziertes Zielbackup verlangen. Bei erforderlichem Rollback den Zielzustand vor dem Cutover wiederherstellen.
Unabhängige Validierung: Datenintegrität, Anwendungsantworten, Gateway- und DNS-Bereitschaft sowie tatsächliche Scrape-Ergebnisse prüfen. Den Terraform-Plan auf unerklärte Drift prüfen, statt erfolgreiche Bereitstellung als Migrationsabnahme zu behandeln.
Wiederholbare Observability: Observability-Integration und Grafana-Dashboard mit acht Panels durch Terraform verwalten. Anwendungs- und Datenbanksignale für Abnahme, Stabilisierung und spätere Optimierung nutzen.

Nicht abgedeckt

Diese Nachweise bestätigen weder einen vollständigen Greenfield-Durchlauf noch eine Migration aus einer produktiven Live-Quelle, unterbrechungsfreien Betrieb, Hochverfügbarkeit, öffentliches Gateway-TLS, interaktiven IDP-Login, Alarmzustellung oder Managed-Flex-Recovery. Der getestete Ein-Worker-Aufbau mit HTTP stellt Metriken ohne Authentifizierung bereit; erfüllen Sie die Produktionsanforderungen vor der Verwendung sensibler Daten. Aktualisieren Sie die Beispielanwendung und validieren Sie eine geeignete unterstützte Kubernetes-Version als separate kontrollierte Änderungen.

Code & Registry github.com Referenzkonfiguration, Skripte und Validierungsnachweise Das Repository-README und die versionierte Implementierung liefern genaue Voraussetzungen, Variablen, Befehle und Recovery-Grenzen. Repository öffnen

STEP

Labor und Repositorys vorbereiten

Migration design-and-mobilize use-cases runnable-example replatform kubernetes terraform ske spring-boot postgresql

Spring Boot mit Terraform von der VM auf Kubernetes umstellen

STACKIT

Dasselbe Spring-Boot-JAR auf STACKIT Kubernetes betreiben: mit PostgreSQL Flex, Gateway API, DNS, Managed Telemetry sowie geprobtem Daten-Cutover und Rollback.

Code & Registry github.com STACKIT Spring Boot Kubernetes Replatform Repository Terraform, Gateway API, PostgreSQL-Migration und Observability der in diesem Asset verwendeten Implementierung öffnen. Repository öffnen

STACKIT

Der souveräne europäische Cloud-Anbieter hinter dem Framework, mit IaaS und PaaS aus deutschen und österreichischen Rechenzentren und voller Unabhängigkeit.

Überblick

Dieses Asset wendet das Migration Framework auf ein Replatform von Spring Boot und PostgreSQL an: Die Anwendung wechselt vom VM-Service zu STACKIT Kubernetes Engine (SKE), die Datenbank von selbstverwaltetem PostgreSQL zu STACKIT PostgreSQL Flex. Geschäftsfunktion und Anwendungs-JAR bleiben unverändert; die Betriebsmodelle für Laufzeit und Datenbank ändern sich.

Referenzimplementierung

Das Referenzrepository ist die maßgebliche Quelle für Terraform, Helm-Charts, fest versionierte Artefakte, Migrationsskripte und Validierung. Verwenden Sie einen geprüften Stand mit den hier beschriebenen Gateway-API- und scripts/migrate_postgres.py-Workflows. Ein älterer Stand mit direktem Datenbank-Import-Job implementiert dieses Verfahren nicht.

Replatform-Scope in diesem Asset

Laufzeit: Dasselbe Spring-Music-JAR mit Spring Boot 2.4.0 läuft auf Java 11 in einem Kubernetes-Deployment statt unter systemd.
Daten: PostgreSQL Flex stellt getrennte Anwendungs- und Probedatenbanken bereit; JDBC- und Migrationsclients benötigen TLS.
Netzwerkverkehr: Envoy Gateway, Gateway API HTTPRoutes und SKE-verwaltetes ExternalDNS ersetzen den VM-Endpunkt.
Betrieb: Kubernetes-Zustands- und Ressourcenkontrollen ersetzen das Host-Service-Management; Managed Telemetry erfasst Cluster-, Anwendungs- und Datenbanksignale.
Migration: Quellnachweise, isolierte Probe, explizit freigegebener Cutover und verifizierter Datenbank-Rollback bleiben von der Infrastrukturbereitstellung getrennt.

Cloud Foundry, Object Storage, die Zerlegung in Microservices und Anwendungsmodernisierung sind nicht Teil dieser Implementierung. Die alte Beispielanwendung demonstriert einen Plattformwechsel; sie ist keine Empfehlung, einen nicht mehr unterstützten Anwendungsstack produktiv einzusetzen.

Architekturdiagramm der Referenz

Prüfen Sie das Architektur-Asset vor der Wahl von Kapazität und Netzwerkkontrollen. Es trennt die implementierte Topologie von Produktionserweiterungen wie öffentlichem HTTPS, hochverfügbaren Workern und geschützten Metriken.

Cloud Framework Spring Boot auf SKE mit PostgreSQL Flex und Gateway API Implementierte Topologie, Laufzeit- und Datengrenzen sowie separat zu qualifizierende Produktionserweiterungen prüfen. Seite öffnen

End-to-End-Ablauf

Replatform-Eignung, Quellkompatibilität, Landing-Zone-Bereitschaft und Verantwortlichkeiten bestätigen.
Einen vertrauenswürdigen PostgreSQL-Dump und ein Integritätsmanifest unabhängig vom Ziel vorbereiten.
Terraform für SKE, PostgreSQL Flex, Gateway, DNS, Workload und Observability prüfen und anwenden.
Das Ziel validieren und den finalen Quelldump in der isolierten Probedatenbank testen.
Quellschreibzugriffe einfrieren, Ausfallzeit freigeben und den kontrollierten Cutover mit geschütztem Zielbackup ausführen.
Anwendungs- und Datennachweise abnehmen oder den Zielzustand vor dem Cutover wiederherstellen; den Client-Traffic nach dem freigegebenen Betreiberverfahren umschalten.
Nachweise während der Stabilisierung aufbewahren und repräsentative Telemetrie für spätere Optimierung nutzen.

Arbeitsumgebung für den Walkthrough vorbereiten

Verwenden Sie eine isolierte Linux-Laborumgebung mit Git, Terraform, kubectl, curl, jq, getent, Python ab Version 3.11 sowie PostgreSQL-Server- und Client-Werkzeugen. Die Rehost-Beispielskripte benötigen außerdem runuser, sha256sum, ein Betriebssystemkonto postgres und Root-Rechte, um eine temporäre lokale Datenbank zu erstellen und zu prüfen. Führen Sie die Beispielbefehle in dieser vorbereiteten Laborumgebung aus, nicht auf einem produktiven Datenbankhost. Die privaten Artefakte müssen für den Migrationsbediener lesbar bleiben; machen Sie sie nicht für alle Benutzer lesbar.

Beziehen Sie geprüfte Commit-IDs beider Repositorys vom Referenz-Maintainer und exportieren Sie diese vorab als REHOST_REVISION und REPLATFORM_REVISION. Der Replatform-Stand muss Gateway API und den freigabegesteuerten Migrationsworkflow enthalten. Setzen Sie nicht voraus, dass der Remote-Standardbranch bereits die lokal getestete Implementierung enthält. Ist der freigegebene Stand nicht verfügbar, beschaffen Sie ihn vor dem Walkthrough.

Ersetzen Sie beide Platzhalter durch die freigegebenen vollständigen Commit-IDs mit jeweils 40 Zeichen und setzen Sie diese im selben Bash-Terminal:

export REHOST_REVISION="REPLACE_WITH_REVIEWED_REHOST_COMMIT_ID"
export REPLATFORM_REVISION="REPLACE_WITH_REVIEWED_REPLATFORM_COMMIT_ID"

Führen Sie den folgenden Block vollständig aus einem leeren Arbeitsverzeichnis aus. Die if-Prüfung lehnt fehlende, leere oder falsch formatierte IDs einschließlich unveränderter Platzhalter ab. Jedes && führt den nächsten Befehl nur nach Erfolg des vorherigen aus. Git prüft die Verfügbarkeit der Commits; die Formatprüfung allein bestätigt weder Freigabe noch Repository-Inhalt.

if [[ ! ${REHOST_REVISION:-} =~ ^[0-9a-fA-F]{40}$ ||
      ! ${REPLATFORM_REVISION:-} =~ ^[0-9a-fA-F]{40}$ ]]; then
  printf '%s\n' "Set both revision variables to reviewed full 40-character commit IDs." >&2
  false
else
  umask 077 &&
    git clone https://github.com/stackitcloud/stackit-cmf-Rehost-springboot.git &&
    git clone https://github.com/stackitcloud/stackit-cmf-replatform-springboot-k8s.git &&
    git -C stackit-cmf-Rehost-springboot checkout --detach "$REHOST_REVISION" &&
    git -C stackit-cmf-replatform-springboot-k8s checkout --detach "$REPLATFORM_REVISION" &&
    test -f stackit-cmf-replatform-springboot-k8s/scripts/migrate_postgres.py &&
    test -f stackit-cmf-replatform-springboot-k8s/scripts/validate_gateway.sh &&
    cd stackit-cmf-replatform-springboot-k8s &&
    printf '%s\n' "Workspace ready. Continue from this Replatform checkout." || {
      printf '%s\n' "Preparation failed. Resolve the error before continuing." >&2
      false
    }
fi

Fahren Sie erst nach der Meldung Workspace ready fort. Bei Fehlern bleibt das Terminal offen; weitere Vorbereitungsbefehle werden übersprungen. Vorhandene oder teilweise geklonte Verzeichnisse werden weder entfernt noch überschrieben: Prüfen Sie diese und bewahren Sie lokale Änderungen, bevor Sie es in einem neuen leeren Arbeitsverzeichnis erneut versuchen. Nach Erfolg befindet sich das Terminal für die nächsten Schritte im Replatform-Checkout.

Nutzen Sie ein freigegebenes STACKIT Projekt, einen Service Account, DNS-Delegation, SKE-Kapazität und ein geschütztes Terraform-Backend. Beziehen Sie Zugangsdaten über den freigegebenen Secret-Kanal, niemals aus diesem Trail. Die folgenden Befehle setzen diese Verzeichnisstruktur und eine geprüfte Konfiguration voraus; sie belegen keinen validierten Greenfield-Produktionsaufbau.

Quellnachweise vorbereiten

Qualifizieren Sie einen konsistenten Quelldump und sein Manifest, bevor Daten in den Migrationsworkflow eingehen.

Die Rehost-Referenz liefert scripts/create_source_dump.sh und scripts/validate_source_dump.sh für ihr reproduzierbares Beispiel. Führen Sie diese im Rehost-Repository aus. Dessen Verzeichnis artifacts liefert source-postgresql.dump und source-postgresql.manifest an den Replatform-Workflow. Das Manifest erfasst Version 1, table=public.album, row_count, album_fingerprint und dump_sha256.

Führen Sie ausschließlich für das reproduzierbare Beispiel die folgenden Befehle vom Replatform-Checkout in der vorbereiteten Laborumgebung aus. Die Skripte erstellen aus dem versionierten Beispiel-SQL eine temporäre PostgreSQL-Instanz, exportieren sie und führen einen unabhängigen Test-Restore aus. Verwenden Sie ein frisches Artefaktverzeichnis; überschreiben Sie keine Nachweise einer bereits laufenden Migration.

umask 077
pushd ../stackit-cmf-Rehost-springboot
bash scripts/create_source_dump.sh
bash scripts/validate_source_dump.sh
popd

Erwartet wird eine erfolgreiche Validierung von acht Zeilen mit passendem Fingerprint. Diese Befehle lesen keine Quell-VM aus. Verwenden Sie für Probe und Cutover genau diese Artefakte weiter.

Ersetzen Sie für eine reale Quelle den Beispielgenerator durch ein freigegebenes Exportverfahren: Frieren Sie alle Schreibzugriffe ein und leiten Sie Dump im Custom-Format und Manifest aus demselben konsistenten Quellsnapshot ab. Das generierte Beispiel mit acht Alben ist kein Export einer beliebigen laufenden VM. Prüfen Sie vor dem Export PostgreSQL-Kompatibilität, Erweiterungen, Eigentümerschaft und Schemaabhängigkeiten.

Stellen Sie nur vertrauenswürdige Dumps wieder her, da sie SQL ausführen. Diese Implementierung migriert das Anwendungsschema public und prüft public.album; von Flex verwaltete Schemas sind bewusst ausgeschlossen. Andere Workloads benötigen eigene Invarianten und einen angepassten Schemaumfang.

Code & Registry github.com Spring-Boot-Rehost-Quelle und Beispielexport Das Rehost-Repository liefert dasselbe Anwendungsartefakt und reproduzierbare Werkzeuge für PostgreSQL-Quellnachweise. Repository öffnen

Ziel bereitstellen

Stellen Sie das Ziel aus einem geprüften Plan mit expliziten Angaben zu Projekt, Kapazität, Zugriff und DNS bereit.

Verwenden Sie Terraform, kubectl, curl, jq, getent und Python ab Version 3.11 unter Linux. Kopieren Sie env.tfvars.example nach env.tfvars und passen Sie die tatsächlichen Variablen dieser Datei an. Behalten Sie die getestete Provider-Lockdatei und unveränderliche Image- und JAR-Referenzen bei. Bestätigen Sie vor dem Plan die Verfügbarkeit der SKE-Version, Node-Pool-Kapazität, Projektberechtigungen und DNS-Delegation.

Aus der STACKIT-DokuLifecycle of Kubernetes Engine › Kubernetes end-of-life datesStand der Quelle 24.08.2026 · übernommen 05.10.2026

Starting with Kubernetes v1.33, we remove minor versions on the patch day that precedes the upstream maintenance end-of-life (EOL) date. The following table below lists the upstream EOL date for each Kubernetes minor version and the corresponding expiration date in SKE:

Seitlich wischen, um die ganze Tabelle zu sehen

Kubernetes minor version	End-of-life date	Expiration in SKE
v1.32	2026-02-28	2026-04-15
v1.33	2026-06-28	2026-06-10
v1.34	2026-10-27	2026-10-14
v1.35	2027-02-28	2027-02-10

Please refer to the official Kubernetes Release History for up-to-date announcements of new versions.

Was ist das?

Dieser Abschnitt wird mehrmals am Tag automatisch aus der STACKIT-Doku übernommen. Hier lässt er sich nicht ändern. Änderungen gehören in die STACKIT-Doku.

Bevorzugen Sie ein freigegebenes Application-Landing-Zone-Projekt. Setzen Sie create_project = false und geben Sie Projekt-ID und Pfad zum Service-Account-Schlüssel an. Die alternative Projekterstellung setzt einen freigegebenen übergeordneten Container und Berechtigungen voraus; sie ersetzt keine Landing-Zone-Governance. Zugangsdaten, State, gespeicherte Pläne und Migrationsnachweise gehören nie in die Versionsverwaltung.

Erstellen Sie für einen neuen Checkout die private Variablendatei, ohne eine vorhandene zu überschreiben:

umask 077
test -e env.tfvars || cp env.tfvars.example env.tfvars
chmod 600 env.tfvars

Bearbeiten Sie diese Datei vor dem Plan: Tragen Sie freigegebenes Projekt und Service-Account-Pfad, Region, unterstützte SKE-Version, verfügbaren Node-Pool-Flavor samt Zone und delegierte DNS-Einstellungen aus dem Repository-Beispiel ein. Prüfen Sie Backend-Zugriff und Sperren, Quotas, Kosten sowie die Grenzen von HTTP und öffentlichen Metriken. Die folgenden Funktionsschalter bilden keine vollständige Umgebungskonfiguration.

Einheitliche Automatisierungs-Flags

Der optionale gemeinsame Wrapper bildet setup_project, setup_observability, setup_database, setup_workload, setup_loadgen und setup_dns auf die Terraform-Schalter des Repositorys ab. Sie wählen ausschließlich den Bereitstellungsumfang: Das Aktivieren der Datenbank erlaubt keinen Datenaustausch und ersetzt niemals die separate Migrationsfreigabe.

Minimale Zielkonfiguration

Diese Werte aktivieren den vollständigen Workload- und Datenbankpfad. Sie ergänzen die Angaben zu Projekt, Region, Node Pool und DNS im Repository-Beispiel, ersetzen sie aber nicht.

deploy_workload                   = true
dns_enabled                       = true
enable_postgres_flex              = true
postgres_flex_target_database     = "springmusic"
postgres_flex_target_app_acl_cidrs = []
observability_enabled             = true
create_observability_instance     = true
create_grafana_dashboard          = true
enable_springboot_hpa              = false
enable_load_generator             = false
deploy_postgres_migration_job      = false

Lassen Sie HPA und Lastgenerierung während der Migration deaktiviert. Wählen Sie Alarmeinstellungen bewusst; die Alarmzustellung wurde im End-to-End-Test nicht validiert. springboot_image wählt die Java-Laufzeit, nicht ein beliebiges vorgefertigtes Anwendungsimage. Der Init-Container lädt das auf einen Commit fixierte Rehost-JAR und prüft vor dem Start seinen SHA-256-Wert. Spiegeln Sie unveränderliche Artefakte für die Produktion in freigegebene Artefakt- und Image-Dienste.

Führen Sie die Befehle im Replatform-Repository aus und prüfen Sie den gespeicherten Plan vor dem Apply:

umask 077
terraform init
terraform validate
terraform plan -var-file=env.tfvars -out=tfplan
terraform apply tfplan
bash scripts/validate_gateway.sh

Zugriffskontrolle und temporäre ACL-Erweiterung für Migration

Bei leeren Anwendungs-ACL-Eingaben verwendet Terraform die tatsächlichen Egress-CIDRs des SKE-Clusters für PostgreSQL Flex. Explizite Anwendungs- oder ältere ACL-Werte überschreiben diesen Standard und müssen geprüft werden. Erlauben Sie nicht 0.0.0.0/0.

Der temporäre PostgreSQL-Client läuft in SKE und erhält den Dump über kubectl. Er verbindet sich nicht direkt mit der Quell-VM; weder Quell- noch Arbeitsplatz-CIDRs benötigen temporären Flex-Zugriff. JDBC und Datenbankwerkzeuge verwenden sslmode=require: Das erzwingt Verschlüsselung, bietet aber nicht die Hostnamenprüfung von verify-full. Schützen Sie Zugangsdaten in Kubernetes Secrets und im Terraform-Backend und validieren Sie bei Bedarf eine stärkere Zertifikatsprüfung.

Migration proben

Stellen Sie den finalen Dump in der isolierten Probedatenbank wieder her und verlangen Sie passende Nachweise, die jünger als 24 Stunden sind.

Führen Sie nach dem Infrastruktur-Apply einen isolierten Restore in springmusic_rehearsal aus. Passen Sie das Quellverzeichnis an die freigegebenen Artefakte an und halten Sie den Nachweispfad privat.

python3 scripts/migrate_postgres.py rehearse \
  --artifacts ../stackit-cmf-Rehost-springboot/artifacts \
  --evidence .tmp/migration-run

Die Probe validiert Manifest, Dump-Prüfsumme, Zielidentität, Zeilenanzahl und Fingerprint, ohne die Anwendungsdatenbank zu ersetzen. Proben Sie nach dem Schreibstopp auf der Quelle erneut mit dem finalen Dump. Der Cutover verlangt passende Nachweise, die jünger als 24 Stunden sind. Eine erfolgreiche Probe mit einem älteren oder anderen Dump gibt die finale Eingabe nicht frei.

Option: VM-PostgreSQL nach PostgreSQL Flex migrieren

Der alte Pfad deploy_postgres_migration_job = true wird durch die Validierung gesperrt. Nutzen Sie stattdessen den freigabegesteuerten Workflow. Stoppen Sie HPA, Lastgenerierung und alle anderen Zielschreiber. Pausieren Sie Terraform- und GitOps-Reconciliation, solange das Skript die Replikazahl steuert. Seine lokale Sperre schützt nur einen Checkout, nicht vor gleichzeitigen Bedienern auf unterschiedlichen Rechnern.

python3 scripts/migrate_postgres.py cutover \
  --artifacts ../stackit-cmf-Rehost-springboot/artifacts \
  --evidence .tmp/migration-run \
  --source-write-frozen --confirm-target springmusic

Das Quellschreibstopp-Flag ist eine Bestätigung des Betreibers, keine automatische Abschaltung der Quelle. Der Cutover skaliert die Anwendung auf null, sichert das Ziel vor dem Cutover und prüft die Sicherung per Prüfsumme. Er weist ihre Wiederherstellbarkeit in der Probedatenbank nach und stellt erst dann die Quelle transaktional wieder her. Vor dem Wiederanlauf mit ursprünglicher Replikazahl werden die Daten geprüft. Bei Fehlern bleibt die Anwendung zur Untersuchung gestoppt. Bewahren Sie Nachweisjournal und Backup auf; überschreiben Sie sie nicht für einen erneuten Versuch.

Validieren und zurückrollen

Vergleichen Sie Datenbanknachweise mit dem Quellmanifest, prüfen Sie das Anwendungsverhalten über das Gateway und bestätigen Sie den Zustand beider Metrik-Jobs. Traffic-Umschaltung und fachliche Abnahme bleiben Betreiberaufgaben; das Skript ändert den Endpunkt der Quellanwendung nicht.

So stellen Sie die geschützte Zieldatenbank aus der Zeit vor dem Cutover wieder her:

python3 scripts/migrate_postgres.py rollback \
  --evidence .tmp/migration-run --confirm-target springmusic

Der Rollback prüft Zielidentität und Backup-Integrität, sichert das aktuelle Ziel separat, stellt die ursprünglichen Daten wieder her und verifiziert vor dem Wiederanlauf deren Fingerprint. Schreibzugriffe nach dem Cutover werden nicht zusammengeführt; bewahren Sie den Dump vor dem Rollback für einen expliziten Abgleich auf. Dies ist ein Zieldatenbank-Rollback, kein automatischer Failback zur Quell-VM.

Datenbank-Metriken in Observability sichtbar machen

Terraform verwaltet den Grafana-Ordner SCF Replatform und das Dashboard mit acht Panels an der vorhandenen Datenquelle Thanos. Öffnen Sie es über grafana_dashboard_url. Cluster-CPU, Cluster-Speicher, laufende Pods, Anwendungsanfragen sowie PostgreSQL-Zustand und -Auslastung unterstützen Abnahme und spätere Optimierung. Ein manueller Dashboard-Import ist nicht nötig.

Anwendungsmetriken stammen aus dem pod-lokalen Boot-2-Actuator über den Metrikadapter auf Port 9090; der PostgreSQL-Exporter nutzt Port 9187. Prüfen Sie beide tatsächlichen Scrape-Ergebnisse, nicht nur die Dashboard-Darstellung. Fehlende Telemetrie ist ein Untersuchungsgrund, niemals der Nachweis fehlender Last.

Validierung mit kubectl

Exportieren Sie eine kurzlebige Kubeconfig mit privaten Berechtigungen und prüfen Sie den Standard-Namespace der Referenz:

umask 077
mkdir -p .tmp
terraform output -raw kubeconfig > .tmp/replatform.kubeconfig
export KUBECONFIG="$PWD/.tmp/replatform.kubeconfig"
kubectl get deploy,svc,pods -n springboot
kubectl get gateway,httproute -n springboot
kubectl rollout status deployment/springboot -n springboot
bash scripts/validate_gateway.sh

Der Gateway-Validator prüft Akzeptanz, aufgelöste Routenreferenzen, DNS und Anwendungsantwort. Entfernen Sie die lokale Kubeconfig nach Gebrauch und beziehen Sie nach Ablauf eine neue. Ein erfolgreicher Rollout allein ist keine Daten- oder fachliche Abnahme.

Grenze zwischen Backup und Recovery

Trennen Sie Migrations-Rollback von Flex-Service-Recovery und bewahren Sie geschützte Nachweise außerhalb kurzlebiger Ausführungsumgebungen auf.

Die Flex-Aufbewahrung wird explizit konfiguriert; der Standard dieser Referenz beträgt 32 Tage. Managed-Datenbankbackups und der Migrationsdump vor dem Cutover dienen unterschiedlichen Zwecken. Die Probe mit Letzterem weist weder Managed-Service-Restore noch Point-in-Time-Recovery oder Disaster Recovery der Anwendung nach. Benennen Sie Recovery-Verantwortliche und testen Sie den benötigten Service-Recovery-Pfad separat.

Bewahren Sie geschützte Nachweise und Backups bis zum Ende des Rollback-Fensters außerhalb eines kurzlebigen Dev Containers auf. Prüfen Sie nach einem abgebrochenen Migrationsprozess verbliebene Pods mit Präfix springmusic-migration-*, bevor Sie fortfahren; starten Sie ein ungeprüftes Ziel nicht durch Terraform neu.

Was dieses Asset zeigt

Dieses Asset zeigt, wie das Anwendungsverhalten beim Wechsel der Betriebsmodelle für Laufzeit und Datenbank erhalten bleibt:

Plattformwechsel: Dasselbe Spring-Boot-JAR auf SKE betreiben, über TLS mit PostgreSQL Flex verbinden und über Gateway API und DNS erreichbar machen.
Kontrollierte Datenmigration: Quelldump und Manifest qualifizieren, einen isolierten Restore proben und vor dem Cutover eine explizite Freigabe sowie ein verifiziertes Zielbackup verlangen. Bei erforderlichem Rollback den Zielzustand vor dem Cutover wiederherstellen.
Unabhängige Validierung: Datenintegrität, Anwendungsantworten, Gateway- und DNS-Bereitschaft sowie tatsächliche Scrape-Ergebnisse prüfen. Den Terraform-Plan auf unerklärte Drift prüfen, statt erfolgreiche Bereitstellung als Migrationsabnahme zu behandeln.
Wiederholbare Observability: Observability-Integration und Grafana-Dashboard mit acht Panels durch Terraform verwalten. Anwendungs- und Datenbanksignale für Abnahme, Stabilisierung und spätere Optimierung nutzen.

Nicht abgedeckt

Diese Nachweise bestätigen weder einen vollständigen Greenfield-Durchlauf noch eine Migration aus einer produktiven Live-Quelle, unterbrechungsfreien Betrieb, Hochverfügbarkeit, öffentliches Gateway-TLS, interaktiven IDP-Login, Alarmzustellung oder Managed-Flex-Recovery. Der getestete Ein-Worker-Aufbau mit HTTP stellt Metriken ohne Authentifizierung bereit; erfüllen Sie die Produktionsanforderungen vor der Verwendung sensibler Daten. Aktualisieren Sie die Beispielanwendung und validieren Sie eine geeignete unterstützte Kubernetes-Version als separate kontrollierte Änderungen.

Code & Registry github.com Referenzkonfiguration, Skripte und Validierungsnachweise Das Repository-README und die versionierte Implementierung liefern genaue Voraussetzungen, Variablen, Befehle und Recovery-Grenzen. Repository öffnen

SAFE

Quellnachweise vorbereiten

Migration design-and-mobilize use-cases runnable-example replatform kubernetes terraform ske spring-boot postgresql

Spring Boot mit Terraform von der VM auf Kubernetes umstellen

STACKIT

Dasselbe Spring-Boot-JAR auf STACKIT Kubernetes betreiben: mit PostgreSQL Flex, Gateway API, DNS, Managed Telemetry sowie geprobtem Daten-Cutover und Rollback.

Code & Registry github.com STACKIT Spring Boot Kubernetes Replatform Repository Terraform, Gateway API, PostgreSQL-Migration und Observability der in diesem Asset verwendeten Implementierung öffnen. Repository öffnen

STACKIT

Der souveräne europäische Cloud-Anbieter hinter dem Framework, mit IaaS und PaaS aus deutschen und österreichischen Rechenzentren und voller Unabhängigkeit.

Überblick

Dieses Asset wendet das Migration Framework auf ein Replatform von Spring Boot und PostgreSQL an: Die Anwendung wechselt vom VM-Service zu STACKIT Kubernetes Engine (SKE), die Datenbank von selbstverwaltetem PostgreSQL zu STACKIT PostgreSQL Flex. Geschäftsfunktion und Anwendungs-JAR bleiben unverändert; die Betriebsmodelle für Laufzeit und Datenbank ändern sich.

Referenzimplementierung

Das Referenzrepository ist die maßgebliche Quelle für Terraform, Helm-Charts, fest versionierte Artefakte, Migrationsskripte und Validierung. Verwenden Sie einen geprüften Stand mit den hier beschriebenen Gateway-API- und scripts/migrate_postgres.py-Workflows. Ein älterer Stand mit direktem Datenbank-Import-Job implementiert dieses Verfahren nicht.

Replatform-Scope in diesem Asset

Laufzeit: Dasselbe Spring-Music-JAR mit Spring Boot 2.4.0 läuft auf Java 11 in einem Kubernetes-Deployment statt unter systemd.
Daten: PostgreSQL Flex stellt getrennte Anwendungs- und Probedatenbanken bereit; JDBC- und Migrationsclients benötigen TLS.
Netzwerkverkehr: Envoy Gateway, Gateway API HTTPRoutes und SKE-verwaltetes ExternalDNS ersetzen den VM-Endpunkt.
Betrieb: Kubernetes-Zustands- und Ressourcenkontrollen ersetzen das Host-Service-Management; Managed Telemetry erfasst Cluster-, Anwendungs- und Datenbanksignale.
Migration: Quellnachweise, isolierte Probe, explizit freigegebener Cutover und verifizierter Datenbank-Rollback bleiben von der Infrastrukturbereitstellung getrennt.

Cloud Foundry, Object Storage, die Zerlegung in Microservices und Anwendungsmodernisierung sind nicht Teil dieser Implementierung. Die alte Beispielanwendung demonstriert einen Plattformwechsel; sie ist keine Empfehlung, einen nicht mehr unterstützten Anwendungsstack produktiv einzusetzen.

Architekturdiagramm der Referenz

Prüfen Sie das Architektur-Asset vor der Wahl von Kapazität und Netzwerkkontrollen. Es trennt die implementierte Topologie von Produktionserweiterungen wie öffentlichem HTTPS, hochverfügbaren Workern und geschützten Metriken.

Cloud Framework Spring Boot auf SKE mit PostgreSQL Flex und Gateway API Implementierte Topologie, Laufzeit- und Datengrenzen sowie separat zu qualifizierende Produktionserweiterungen prüfen. Seite öffnen

End-to-End-Ablauf

Replatform-Eignung, Quellkompatibilität, Landing-Zone-Bereitschaft und Verantwortlichkeiten bestätigen.
Einen vertrauenswürdigen PostgreSQL-Dump und ein Integritätsmanifest unabhängig vom Ziel vorbereiten.
Terraform für SKE, PostgreSQL Flex, Gateway, DNS, Workload und Observability prüfen und anwenden.
Das Ziel validieren und den finalen Quelldump in der isolierten Probedatenbank testen.
Quellschreibzugriffe einfrieren, Ausfallzeit freigeben und den kontrollierten Cutover mit geschütztem Zielbackup ausführen.
Anwendungs- und Datennachweise abnehmen oder den Zielzustand vor dem Cutover wiederherstellen; den Client-Traffic nach dem freigegebenen Betreiberverfahren umschalten.
Nachweise während der Stabilisierung aufbewahren und repräsentative Telemetrie für spätere Optimierung nutzen.

Arbeitsumgebung für den Walkthrough vorbereiten

Verwenden Sie eine isolierte Linux-Laborumgebung mit Git, Terraform, kubectl, curl, jq, getent, Python ab Version 3.11 sowie PostgreSQL-Server- und Client-Werkzeugen. Die Rehost-Beispielskripte benötigen außerdem runuser, sha256sum, ein Betriebssystemkonto postgres und Root-Rechte, um eine temporäre lokale Datenbank zu erstellen und zu prüfen. Führen Sie die Beispielbefehle in dieser vorbereiteten Laborumgebung aus, nicht auf einem produktiven Datenbankhost. Die privaten Artefakte müssen für den Migrationsbediener lesbar bleiben; machen Sie sie nicht für alle Benutzer lesbar.

Beziehen Sie geprüfte Commit-IDs beider Repositorys vom Referenz-Maintainer und exportieren Sie diese vorab als REHOST_REVISION und REPLATFORM_REVISION. Der Replatform-Stand muss Gateway API und den freigabegesteuerten Migrationsworkflow enthalten. Setzen Sie nicht voraus, dass der Remote-Standardbranch bereits die lokal getestete Implementierung enthält. Ist der freigegebene Stand nicht verfügbar, beschaffen Sie ihn vor dem Walkthrough.

Ersetzen Sie beide Platzhalter durch die freigegebenen vollständigen Commit-IDs mit jeweils 40 Zeichen und setzen Sie diese im selben Bash-Terminal:

export REHOST_REVISION="REPLACE_WITH_REVIEWED_REHOST_COMMIT_ID"
export REPLATFORM_REVISION="REPLACE_WITH_REVIEWED_REPLATFORM_COMMIT_ID"

Führen Sie den folgenden Block vollständig aus einem leeren Arbeitsverzeichnis aus. Die if-Prüfung lehnt fehlende, leere oder falsch formatierte IDs einschließlich unveränderter Platzhalter ab. Jedes && führt den nächsten Befehl nur nach Erfolg des vorherigen aus. Git prüft die Verfügbarkeit der Commits; die Formatprüfung allein bestätigt weder Freigabe noch Repository-Inhalt.

if [[ ! ${REHOST_REVISION:-} =~ ^[0-9a-fA-F]{40}$ ||
      ! ${REPLATFORM_REVISION:-} =~ ^[0-9a-fA-F]{40}$ ]]; then
  printf '%s\n' "Set both revision variables to reviewed full 40-character commit IDs." >&2
  false
else
  umask 077 &&
    git clone https://github.com/stackitcloud/stackit-cmf-Rehost-springboot.git &&
    git clone https://github.com/stackitcloud/stackit-cmf-replatform-springboot-k8s.git &&
    git -C stackit-cmf-Rehost-springboot checkout --detach "$REHOST_REVISION" &&
    git -C stackit-cmf-replatform-springboot-k8s checkout --detach "$REPLATFORM_REVISION" &&
    test -f stackit-cmf-replatform-springboot-k8s/scripts/migrate_postgres.py &&
    test -f stackit-cmf-replatform-springboot-k8s/scripts/validate_gateway.sh &&
    cd stackit-cmf-replatform-springboot-k8s &&
    printf '%s\n' "Workspace ready. Continue from this Replatform checkout." || {
      printf '%s\n' "Preparation failed. Resolve the error before continuing." >&2
      false
    }
fi

Fahren Sie erst nach der Meldung Workspace ready fort. Bei Fehlern bleibt das Terminal offen; weitere Vorbereitungsbefehle werden übersprungen. Vorhandene oder teilweise geklonte Verzeichnisse werden weder entfernt noch überschrieben: Prüfen Sie diese und bewahren Sie lokale Änderungen, bevor Sie es in einem neuen leeren Arbeitsverzeichnis erneut versuchen. Nach Erfolg befindet sich das Terminal für die nächsten Schritte im Replatform-Checkout.

Nutzen Sie ein freigegebenes STACKIT Projekt, einen Service Account, DNS-Delegation, SKE-Kapazität und ein geschütztes Terraform-Backend. Beziehen Sie Zugangsdaten über den freigegebenen Secret-Kanal, niemals aus diesem Trail. Die folgenden Befehle setzen diese Verzeichnisstruktur und eine geprüfte Konfiguration voraus; sie belegen keinen validierten Greenfield-Produktionsaufbau.

Quellnachweise vorbereiten

Qualifizieren Sie einen konsistenten Quelldump und sein Manifest, bevor Daten in den Migrationsworkflow eingehen.

Die Rehost-Referenz liefert scripts/create_source_dump.sh und scripts/validate_source_dump.sh für ihr reproduzierbares Beispiel. Führen Sie diese im Rehost-Repository aus. Dessen Verzeichnis artifacts liefert source-postgresql.dump und source-postgresql.manifest an den Replatform-Workflow. Das Manifest erfasst Version 1, table=public.album, row_count, album_fingerprint und dump_sha256.

Führen Sie ausschließlich für das reproduzierbare Beispiel die folgenden Befehle vom Replatform-Checkout in der vorbereiteten Laborumgebung aus. Die Skripte erstellen aus dem versionierten Beispiel-SQL eine temporäre PostgreSQL-Instanz, exportieren sie und führen einen unabhängigen Test-Restore aus. Verwenden Sie ein frisches Artefaktverzeichnis; überschreiben Sie keine Nachweise einer bereits laufenden Migration.

umask 077
pushd ../stackit-cmf-Rehost-springboot
bash scripts/create_source_dump.sh
bash scripts/validate_source_dump.sh
popd

Erwartet wird eine erfolgreiche Validierung von acht Zeilen mit passendem Fingerprint. Diese Befehle lesen keine Quell-VM aus. Verwenden Sie für Probe und Cutover genau diese Artefakte weiter.

Ersetzen Sie für eine reale Quelle den Beispielgenerator durch ein freigegebenes Exportverfahren: Frieren Sie alle Schreibzugriffe ein und leiten Sie Dump im Custom-Format und Manifest aus demselben konsistenten Quellsnapshot ab. Das generierte Beispiel mit acht Alben ist kein Export einer beliebigen laufenden VM. Prüfen Sie vor dem Export PostgreSQL-Kompatibilität, Erweiterungen, Eigentümerschaft und Schemaabhängigkeiten.

Stellen Sie nur vertrauenswürdige Dumps wieder her, da sie SQL ausführen. Diese Implementierung migriert das Anwendungsschema public und prüft public.album; von Flex verwaltete Schemas sind bewusst ausgeschlossen. Andere Workloads benötigen eigene Invarianten und einen angepassten Schemaumfang.

Code & Registry github.com Spring-Boot-Rehost-Quelle und Beispielexport Das Rehost-Repository liefert dasselbe Anwendungsartefakt und reproduzierbare Werkzeuge für PostgreSQL-Quellnachweise. Repository öffnen

Ziel bereitstellen

Stellen Sie das Ziel aus einem geprüften Plan mit expliziten Angaben zu Projekt, Kapazität, Zugriff und DNS bereit.

Verwenden Sie Terraform, kubectl, curl, jq, getent und Python ab Version 3.11 unter Linux. Kopieren Sie env.tfvars.example nach env.tfvars und passen Sie die tatsächlichen Variablen dieser Datei an. Behalten Sie die getestete Provider-Lockdatei und unveränderliche Image- und JAR-Referenzen bei. Bestätigen Sie vor dem Plan die Verfügbarkeit der SKE-Version, Node-Pool-Kapazität, Projektberechtigungen und DNS-Delegation.

Aus der STACKIT-DokuLifecycle of Kubernetes Engine › Kubernetes end-of-life datesStand der Quelle 24.08.2026 · übernommen 05.10.2026

Starting with Kubernetes v1.33, we remove minor versions on the patch day that precedes the upstream maintenance end-of-life (EOL) date. The following table below lists the upstream EOL date for each Kubernetes minor version and the corresponding expiration date in SKE:

Seitlich wischen, um die ganze Tabelle zu sehen

Kubernetes minor version	End-of-life date	Expiration in SKE
v1.32	2026-02-28	2026-04-15
v1.33	2026-06-28	2026-06-10
v1.34	2026-10-27	2026-10-14
v1.35	2027-02-28	2027-02-10

Please refer to the official Kubernetes Release History for up-to-date announcements of new versions.

Was ist das?

Dieser Abschnitt wird mehrmals am Tag automatisch aus der STACKIT-Doku übernommen. Hier lässt er sich nicht ändern. Änderungen gehören in die STACKIT-Doku.

Bevorzugen Sie ein freigegebenes Application-Landing-Zone-Projekt. Setzen Sie create_project = false und geben Sie Projekt-ID und Pfad zum Service-Account-Schlüssel an. Die alternative Projekterstellung setzt einen freigegebenen übergeordneten Container und Berechtigungen voraus; sie ersetzt keine Landing-Zone-Governance. Zugangsdaten, State, gespeicherte Pläne und Migrationsnachweise gehören nie in die Versionsverwaltung.

Erstellen Sie für einen neuen Checkout die private Variablendatei, ohne eine vorhandene zu überschreiben:

umask 077
test -e env.tfvars || cp env.tfvars.example env.tfvars
chmod 600 env.tfvars

Bearbeiten Sie diese Datei vor dem Plan: Tragen Sie freigegebenes Projekt und Service-Account-Pfad, Region, unterstützte SKE-Version, verfügbaren Node-Pool-Flavor samt Zone und delegierte DNS-Einstellungen aus dem Repository-Beispiel ein. Prüfen Sie Backend-Zugriff und Sperren, Quotas, Kosten sowie die Grenzen von HTTP und öffentlichen Metriken. Die folgenden Funktionsschalter bilden keine vollständige Umgebungskonfiguration.

Einheitliche Automatisierungs-Flags

Der optionale gemeinsame Wrapper bildet setup_project, setup_observability, setup_database, setup_workload, setup_loadgen und setup_dns auf die Terraform-Schalter des Repositorys ab. Sie wählen ausschließlich den Bereitstellungsumfang: Das Aktivieren der Datenbank erlaubt keinen Datenaustausch und ersetzt niemals die separate Migrationsfreigabe.

Minimale Zielkonfiguration

Diese Werte aktivieren den vollständigen Workload- und Datenbankpfad. Sie ergänzen die Angaben zu Projekt, Region, Node Pool und DNS im Repository-Beispiel, ersetzen sie aber nicht.

deploy_workload                   = true
dns_enabled                       = true
enable_postgres_flex              = true
postgres_flex_target_database     = "springmusic"
postgres_flex_target_app_acl_cidrs = []
observability_enabled             = true
create_observability_instance     = true
create_grafana_dashboard          = true
enable_springboot_hpa              = false
enable_load_generator             = false
deploy_postgres_migration_job      = false

Lassen Sie HPA und Lastgenerierung während der Migration deaktiviert. Wählen Sie Alarmeinstellungen bewusst; die Alarmzustellung wurde im End-to-End-Test nicht validiert. springboot_image wählt die Java-Laufzeit, nicht ein beliebiges vorgefertigtes Anwendungsimage. Der Init-Container lädt das auf einen Commit fixierte Rehost-JAR und prüft vor dem Start seinen SHA-256-Wert. Spiegeln Sie unveränderliche Artefakte für die Produktion in freigegebene Artefakt- und Image-Dienste.

Führen Sie die Befehle im Replatform-Repository aus und prüfen Sie den gespeicherten Plan vor dem Apply:

umask 077
terraform init
terraform validate
terraform plan -var-file=env.tfvars -out=tfplan
terraform apply tfplan
bash scripts/validate_gateway.sh

Zugriffskontrolle und temporäre ACL-Erweiterung für Migration

Bei leeren Anwendungs-ACL-Eingaben verwendet Terraform die tatsächlichen Egress-CIDRs des SKE-Clusters für PostgreSQL Flex. Explizite Anwendungs- oder ältere ACL-Werte überschreiben diesen Standard und müssen geprüft werden. Erlauben Sie nicht 0.0.0.0/0.

Der temporäre PostgreSQL-Client läuft in SKE und erhält den Dump über kubectl. Er verbindet sich nicht direkt mit der Quell-VM; weder Quell- noch Arbeitsplatz-CIDRs benötigen temporären Flex-Zugriff. JDBC und Datenbankwerkzeuge verwenden sslmode=require: Das erzwingt Verschlüsselung, bietet aber nicht die Hostnamenprüfung von verify-full. Schützen Sie Zugangsdaten in Kubernetes Secrets und im Terraform-Backend und validieren Sie bei Bedarf eine stärkere Zertifikatsprüfung.

Migration proben

Stellen Sie den finalen Dump in der isolierten Probedatenbank wieder her und verlangen Sie passende Nachweise, die jünger als 24 Stunden sind.

Führen Sie nach dem Infrastruktur-Apply einen isolierten Restore in springmusic_rehearsal aus. Passen Sie das Quellverzeichnis an die freigegebenen Artefakte an und halten Sie den Nachweispfad privat.

python3 scripts/migrate_postgres.py rehearse \
  --artifacts ../stackit-cmf-Rehost-springboot/artifacts \
  --evidence .tmp/migration-run

Die Probe validiert Manifest, Dump-Prüfsumme, Zielidentität, Zeilenanzahl und Fingerprint, ohne die Anwendungsdatenbank zu ersetzen. Proben Sie nach dem Schreibstopp auf der Quelle erneut mit dem finalen Dump. Der Cutover verlangt passende Nachweise, die jünger als 24 Stunden sind. Eine erfolgreiche Probe mit einem älteren oder anderen Dump gibt die finale Eingabe nicht frei.

Option: VM-PostgreSQL nach PostgreSQL Flex migrieren

Der alte Pfad deploy_postgres_migration_job = true wird durch die Validierung gesperrt. Nutzen Sie stattdessen den freigabegesteuerten Workflow. Stoppen Sie HPA, Lastgenerierung und alle anderen Zielschreiber. Pausieren Sie Terraform- und GitOps-Reconciliation, solange das Skript die Replikazahl steuert. Seine lokale Sperre schützt nur einen Checkout, nicht vor gleichzeitigen Bedienern auf unterschiedlichen Rechnern.

python3 scripts/migrate_postgres.py cutover \
  --artifacts ../stackit-cmf-Rehost-springboot/artifacts \
  --evidence .tmp/migration-run \
  --source-write-frozen --confirm-target springmusic

Das Quellschreibstopp-Flag ist eine Bestätigung des Betreibers, keine automatische Abschaltung der Quelle. Der Cutover skaliert die Anwendung auf null, sichert das Ziel vor dem Cutover und prüft die Sicherung per Prüfsumme. Er weist ihre Wiederherstellbarkeit in der Probedatenbank nach und stellt erst dann die Quelle transaktional wieder her. Vor dem Wiederanlauf mit ursprünglicher Replikazahl werden die Daten geprüft. Bei Fehlern bleibt die Anwendung zur Untersuchung gestoppt. Bewahren Sie Nachweisjournal und Backup auf; überschreiben Sie sie nicht für einen erneuten Versuch.

Validieren und zurückrollen

Vergleichen Sie Datenbanknachweise mit dem Quellmanifest, prüfen Sie das Anwendungsverhalten über das Gateway und bestätigen Sie den Zustand beider Metrik-Jobs. Traffic-Umschaltung und fachliche Abnahme bleiben Betreiberaufgaben; das Skript ändert den Endpunkt der Quellanwendung nicht.

So stellen Sie die geschützte Zieldatenbank aus der Zeit vor dem Cutover wieder her:

python3 scripts/migrate_postgres.py rollback \
  --evidence .tmp/migration-run --confirm-target springmusic

Der Rollback prüft Zielidentität und Backup-Integrität, sichert das aktuelle Ziel separat, stellt die ursprünglichen Daten wieder her und verifiziert vor dem Wiederanlauf deren Fingerprint. Schreibzugriffe nach dem Cutover werden nicht zusammengeführt; bewahren Sie den Dump vor dem Rollback für einen expliziten Abgleich auf. Dies ist ein Zieldatenbank-Rollback, kein automatischer Failback zur Quell-VM.

Datenbank-Metriken in Observability sichtbar machen

Terraform verwaltet den Grafana-Ordner SCF Replatform und das Dashboard mit acht Panels an der vorhandenen Datenquelle Thanos. Öffnen Sie es über grafana_dashboard_url. Cluster-CPU, Cluster-Speicher, laufende Pods, Anwendungsanfragen sowie PostgreSQL-Zustand und -Auslastung unterstützen Abnahme und spätere Optimierung. Ein manueller Dashboard-Import ist nicht nötig.

Anwendungsmetriken stammen aus dem pod-lokalen Boot-2-Actuator über den Metrikadapter auf Port 9090; der PostgreSQL-Exporter nutzt Port 9187. Prüfen Sie beide tatsächlichen Scrape-Ergebnisse, nicht nur die Dashboard-Darstellung. Fehlende Telemetrie ist ein Untersuchungsgrund, niemals der Nachweis fehlender Last.

Validierung mit kubectl

Exportieren Sie eine kurzlebige Kubeconfig mit privaten Berechtigungen und prüfen Sie den Standard-Namespace der Referenz:

umask 077
mkdir -p .tmp
terraform output -raw kubeconfig > .tmp/replatform.kubeconfig
export KUBECONFIG="$PWD/.tmp/replatform.kubeconfig"
kubectl get deploy,svc,pods -n springboot
kubectl get gateway,httproute -n springboot
kubectl rollout status deployment/springboot -n springboot
bash scripts/validate_gateway.sh

Der Gateway-Validator prüft Akzeptanz, aufgelöste Routenreferenzen, DNS und Anwendungsantwort. Entfernen Sie die lokale Kubeconfig nach Gebrauch und beziehen Sie nach Ablauf eine neue. Ein erfolgreicher Rollout allein ist keine Daten- oder fachliche Abnahme.

Grenze zwischen Backup und Recovery

Trennen Sie Migrations-Rollback von Flex-Service-Recovery und bewahren Sie geschützte Nachweise außerhalb kurzlebiger Ausführungsumgebungen auf.

Die Flex-Aufbewahrung wird explizit konfiguriert; der Standard dieser Referenz beträgt 32 Tage. Managed-Datenbankbackups und der Migrationsdump vor dem Cutover dienen unterschiedlichen Zwecken. Die Probe mit Letzterem weist weder Managed-Service-Restore noch Point-in-Time-Recovery oder Disaster Recovery der Anwendung nach. Benennen Sie Recovery-Verantwortliche und testen Sie den benötigten Service-Recovery-Pfad separat.

Bewahren Sie geschützte Nachweise und Backups bis zum Ende des Rollback-Fensters außerhalb eines kurzlebigen Dev Containers auf. Prüfen Sie nach einem abgebrochenen Migrationsprozess verbliebene Pods mit Präfix springmusic-migration-*, bevor Sie fortfahren; starten Sie ein ungeprüftes Ziel nicht durch Terraform neu.

Was dieses Asset zeigt

Dieses Asset zeigt, wie das Anwendungsverhalten beim Wechsel der Betriebsmodelle für Laufzeit und Datenbank erhalten bleibt:

Plattformwechsel: Dasselbe Spring-Boot-JAR auf SKE betreiben, über TLS mit PostgreSQL Flex verbinden und über Gateway API und DNS erreichbar machen.
Kontrollierte Datenmigration: Quelldump und Manifest qualifizieren, einen isolierten Restore proben und vor dem Cutover eine explizite Freigabe sowie ein verifiziertes Zielbackup verlangen. Bei erforderlichem Rollback den Zielzustand vor dem Cutover wiederherstellen.
Unabhängige Validierung: Datenintegrität, Anwendungsantworten, Gateway- und DNS-Bereitschaft sowie tatsächliche Scrape-Ergebnisse prüfen. Den Terraform-Plan auf unerklärte Drift prüfen, statt erfolgreiche Bereitstellung als Migrationsabnahme zu behandeln.
Wiederholbare Observability: Observability-Integration und Grafana-Dashboard mit acht Panels durch Terraform verwalten. Anwendungs- und Datenbanksignale für Abnahme, Stabilisierung und spätere Optimierung nutzen.

Nicht abgedeckt

Diese Nachweise bestätigen weder einen vollständigen Greenfield-Durchlauf noch eine Migration aus einer produktiven Live-Quelle, unterbrechungsfreien Betrieb, Hochverfügbarkeit, öffentliches Gateway-TLS, interaktiven IDP-Login, Alarmzustellung oder Managed-Flex-Recovery. Der getestete Ein-Worker-Aufbau mit HTTP stellt Metriken ohne Authentifizierung bereit; erfüllen Sie die Produktionsanforderungen vor der Verwendung sensibler Daten. Aktualisieren Sie die Beispielanwendung und validieren Sie eine geeignete unterstützte Kubernetes-Version als separate kontrollierte Änderungen.

Code & Registry github.com Referenzkonfiguration, Skripte und Validierungsnachweise Das Repository-README und die versionierte Implementierung liefern genaue Voraussetzungen, Variablen, Befehle und Recovery-Grenzen. Repository öffnen

STEP

Zielparameter konfigurieren

Migration design-and-mobilize use-cases runnable-example replatform kubernetes terraform ske spring-boot postgresql

Spring Boot mit Terraform von der VM auf Kubernetes umstellen

STACKIT

Dasselbe Spring-Boot-JAR auf STACKIT Kubernetes betreiben: mit PostgreSQL Flex, Gateway API, DNS, Managed Telemetry sowie geprobtem Daten-Cutover und Rollback.

Code & Registry github.com STACKIT Spring Boot Kubernetes Replatform Repository Terraform, Gateway API, PostgreSQL-Migration und Observability der in diesem Asset verwendeten Implementierung öffnen. Repository öffnen

STACKIT

Der souveräne europäische Cloud-Anbieter hinter dem Framework, mit IaaS und PaaS aus deutschen und österreichischen Rechenzentren und voller Unabhängigkeit.

Überblick

Dieses Asset wendet das Migration Framework auf ein Replatform von Spring Boot und PostgreSQL an: Die Anwendung wechselt vom VM-Service zu STACKIT Kubernetes Engine (SKE), die Datenbank von selbstverwaltetem PostgreSQL zu STACKIT PostgreSQL Flex. Geschäftsfunktion und Anwendungs-JAR bleiben unverändert; die Betriebsmodelle für Laufzeit und Datenbank ändern sich.

Referenzimplementierung

Das Referenzrepository ist die maßgebliche Quelle für Terraform, Helm-Charts, fest versionierte Artefakte, Migrationsskripte und Validierung. Verwenden Sie einen geprüften Stand mit den hier beschriebenen Gateway-API- und scripts/migrate_postgres.py-Workflows. Ein älterer Stand mit direktem Datenbank-Import-Job implementiert dieses Verfahren nicht.

Replatform-Scope in diesem Asset

Laufzeit: Dasselbe Spring-Music-JAR mit Spring Boot 2.4.0 läuft auf Java 11 in einem Kubernetes-Deployment statt unter systemd.
Daten: PostgreSQL Flex stellt getrennte Anwendungs- und Probedatenbanken bereit; JDBC- und Migrationsclients benötigen TLS.
Netzwerkverkehr: Envoy Gateway, Gateway API HTTPRoutes und SKE-verwaltetes ExternalDNS ersetzen den VM-Endpunkt.
Betrieb: Kubernetes-Zustands- und Ressourcenkontrollen ersetzen das Host-Service-Management; Managed Telemetry erfasst Cluster-, Anwendungs- und Datenbanksignale.
Migration: Quellnachweise, isolierte Probe, explizit freigegebener Cutover und verifizierter Datenbank-Rollback bleiben von der Infrastrukturbereitstellung getrennt.

Cloud Foundry, Object Storage, die Zerlegung in Microservices und Anwendungsmodernisierung sind nicht Teil dieser Implementierung. Die alte Beispielanwendung demonstriert einen Plattformwechsel; sie ist keine Empfehlung, einen nicht mehr unterstützten Anwendungsstack produktiv einzusetzen.

Architekturdiagramm der Referenz

Prüfen Sie das Architektur-Asset vor der Wahl von Kapazität und Netzwerkkontrollen. Es trennt die implementierte Topologie von Produktionserweiterungen wie öffentlichem HTTPS, hochverfügbaren Workern und geschützten Metriken.

Cloud Framework Spring Boot auf SKE mit PostgreSQL Flex und Gateway API Implementierte Topologie, Laufzeit- und Datengrenzen sowie separat zu qualifizierende Produktionserweiterungen prüfen. Seite öffnen

End-to-End-Ablauf

Replatform-Eignung, Quellkompatibilität, Landing-Zone-Bereitschaft und Verantwortlichkeiten bestätigen.
Einen vertrauenswürdigen PostgreSQL-Dump und ein Integritätsmanifest unabhängig vom Ziel vorbereiten.
Terraform für SKE, PostgreSQL Flex, Gateway, DNS, Workload und Observability prüfen und anwenden.
Das Ziel validieren und den finalen Quelldump in der isolierten Probedatenbank testen.
Quellschreibzugriffe einfrieren, Ausfallzeit freigeben und den kontrollierten Cutover mit geschütztem Zielbackup ausführen.
Anwendungs- und Datennachweise abnehmen oder den Zielzustand vor dem Cutover wiederherstellen; den Client-Traffic nach dem freigegebenen Betreiberverfahren umschalten.
Nachweise während der Stabilisierung aufbewahren und repräsentative Telemetrie für spätere Optimierung nutzen.

Arbeitsumgebung für den Walkthrough vorbereiten

Verwenden Sie eine isolierte Linux-Laborumgebung mit Git, Terraform, kubectl, curl, jq, getent, Python ab Version 3.11 sowie PostgreSQL-Server- und Client-Werkzeugen. Die Rehost-Beispielskripte benötigen außerdem runuser, sha256sum, ein Betriebssystemkonto postgres und Root-Rechte, um eine temporäre lokale Datenbank zu erstellen und zu prüfen. Führen Sie die Beispielbefehle in dieser vorbereiteten Laborumgebung aus, nicht auf einem produktiven Datenbankhost. Die privaten Artefakte müssen für den Migrationsbediener lesbar bleiben; machen Sie sie nicht für alle Benutzer lesbar.

Beziehen Sie geprüfte Commit-IDs beider Repositorys vom Referenz-Maintainer und exportieren Sie diese vorab als REHOST_REVISION und REPLATFORM_REVISION. Der Replatform-Stand muss Gateway API und den freigabegesteuerten Migrationsworkflow enthalten. Setzen Sie nicht voraus, dass der Remote-Standardbranch bereits die lokal getestete Implementierung enthält. Ist der freigegebene Stand nicht verfügbar, beschaffen Sie ihn vor dem Walkthrough.

Ersetzen Sie beide Platzhalter durch die freigegebenen vollständigen Commit-IDs mit jeweils 40 Zeichen und setzen Sie diese im selben Bash-Terminal:

export REHOST_REVISION="REPLACE_WITH_REVIEWED_REHOST_COMMIT_ID"
export REPLATFORM_REVISION="REPLACE_WITH_REVIEWED_REPLATFORM_COMMIT_ID"

Führen Sie den folgenden Block vollständig aus einem leeren Arbeitsverzeichnis aus. Die if-Prüfung lehnt fehlende, leere oder falsch formatierte IDs einschließlich unveränderter Platzhalter ab. Jedes && führt den nächsten Befehl nur nach Erfolg des vorherigen aus. Git prüft die Verfügbarkeit der Commits; die Formatprüfung allein bestätigt weder Freigabe noch Repository-Inhalt.

if [[ ! ${REHOST_REVISION:-} =~ ^[0-9a-fA-F]{40}$ ||
      ! ${REPLATFORM_REVISION:-} =~ ^[0-9a-fA-F]{40}$ ]]; then
  printf '%s\n' "Set both revision variables to reviewed full 40-character commit IDs." >&2
  false
else
  umask 077 &&
    git clone https://github.com/stackitcloud/stackit-cmf-Rehost-springboot.git &&
    git clone https://github.com/stackitcloud/stackit-cmf-replatform-springboot-k8s.git &&
    git -C stackit-cmf-Rehost-springboot checkout --detach "$REHOST_REVISION" &&
    git -C stackit-cmf-replatform-springboot-k8s checkout --detach "$REPLATFORM_REVISION" &&
    test -f stackit-cmf-replatform-springboot-k8s/scripts/migrate_postgres.py &&
    test -f stackit-cmf-replatform-springboot-k8s/scripts/validate_gateway.sh &&
    cd stackit-cmf-replatform-springboot-k8s &&
    printf '%s\n' "Workspace ready. Continue from this Replatform checkout." || {
      printf '%s\n' "Preparation failed. Resolve the error before continuing." >&2
      false
    }
fi

Fahren Sie erst nach der Meldung Workspace ready fort. Bei Fehlern bleibt das Terminal offen; weitere Vorbereitungsbefehle werden übersprungen. Vorhandene oder teilweise geklonte Verzeichnisse werden weder entfernt noch überschrieben: Prüfen Sie diese und bewahren Sie lokale Änderungen, bevor Sie es in einem neuen leeren Arbeitsverzeichnis erneut versuchen. Nach Erfolg befindet sich das Terminal für die nächsten Schritte im Replatform-Checkout.

Nutzen Sie ein freigegebenes STACKIT Projekt, einen Service Account, DNS-Delegation, SKE-Kapazität und ein geschütztes Terraform-Backend. Beziehen Sie Zugangsdaten über den freigegebenen Secret-Kanal, niemals aus diesem Trail. Die folgenden Befehle setzen diese Verzeichnisstruktur und eine geprüfte Konfiguration voraus; sie belegen keinen validierten Greenfield-Produktionsaufbau.

Quellnachweise vorbereiten

Qualifizieren Sie einen konsistenten Quelldump und sein Manifest, bevor Daten in den Migrationsworkflow eingehen.

Die Rehost-Referenz liefert scripts/create_source_dump.sh und scripts/validate_source_dump.sh für ihr reproduzierbares Beispiel. Führen Sie diese im Rehost-Repository aus. Dessen Verzeichnis artifacts liefert source-postgresql.dump und source-postgresql.manifest an den Replatform-Workflow. Das Manifest erfasst Version 1, table=public.album, row_count, album_fingerprint und dump_sha256.

Führen Sie ausschließlich für das reproduzierbare Beispiel die folgenden Befehle vom Replatform-Checkout in der vorbereiteten Laborumgebung aus. Die Skripte erstellen aus dem versionierten Beispiel-SQL eine temporäre PostgreSQL-Instanz, exportieren sie und führen einen unabhängigen Test-Restore aus. Verwenden Sie ein frisches Artefaktverzeichnis; überschreiben Sie keine Nachweise einer bereits laufenden Migration.

umask 077
pushd ../stackit-cmf-Rehost-springboot
bash scripts/create_source_dump.sh
bash scripts/validate_source_dump.sh
popd

Erwartet wird eine erfolgreiche Validierung von acht Zeilen mit passendem Fingerprint. Diese Befehle lesen keine Quell-VM aus. Verwenden Sie für Probe und Cutover genau diese Artefakte weiter.

Ersetzen Sie für eine reale Quelle den Beispielgenerator durch ein freigegebenes Exportverfahren: Frieren Sie alle Schreibzugriffe ein und leiten Sie Dump im Custom-Format und Manifest aus demselben konsistenten Quellsnapshot ab. Das generierte Beispiel mit acht Alben ist kein Export einer beliebigen laufenden VM. Prüfen Sie vor dem Export PostgreSQL-Kompatibilität, Erweiterungen, Eigentümerschaft und Schemaabhängigkeiten.

Stellen Sie nur vertrauenswürdige Dumps wieder her, da sie SQL ausführen. Diese Implementierung migriert das Anwendungsschema public und prüft public.album; von Flex verwaltete Schemas sind bewusst ausgeschlossen. Andere Workloads benötigen eigene Invarianten und einen angepassten Schemaumfang.

Code & Registry github.com Spring-Boot-Rehost-Quelle und Beispielexport Das Rehost-Repository liefert dasselbe Anwendungsartefakt und reproduzierbare Werkzeuge für PostgreSQL-Quellnachweise. Repository öffnen

Ziel bereitstellen

Stellen Sie das Ziel aus einem geprüften Plan mit expliziten Angaben zu Projekt, Kapazität, Zugriff und DNS bereit.

Verwenden Sie Terraform, kubectl, curl, jq, getent und Python ab Version 3.11 unter Linux. Kopieren Sie env.tfvars.example nach env.tfvars und passen Sie die tatsächlichen Variablen dieser Datei an. Behalten Sie die getestete Provider-Lockdatei und unveränderliche Image- und JAR-Referenzen bei. Bestätigen Sie vor dem Plan die Verfügbarkeit der SKE-Version, Node-Pool-Kapazität, Projektberechtigungen und DNS-Delegation.

Aus der STACKIT-DokuLifecycle of Kubernetes Engine › Kubernetes end-of-life datesStand der Quelle 24.08.2026 · übernommen 05.10.2026

Starting with Kubernetes v1.33, we remove minor versions on the patch day that precedes the upstream maintenance end-of-life (EOL) date. The following table below lists the upstream EOL date for each Kubernetes minor version and the corresponding expiration date in SKE:

Seitlich wischen, um die ganze Tabelle zu sehen

Kubernetes minor version	End-of-life date	Expiration in SKE
v1.32	2026-02-28	2026-04-15
v1.33	2026-06-28	2026-06-10
v1.34	2026-10-27	2026-10-14
v1.35	2027-02-28	2027-02-10

Please refer to the official Kubernetes Release History for up-to-date announcements of new versions.

Was ist das?

Dieser Abschnitt wird mehrmals am Tag automatisch aus der STACKIT-Doku übernommen. Hier lässt er sich nicht ändern. Änderungen gehören in die STACKIT-Doku.

Bevorzugen Sie ein freigegebenes Application-Landing-Zone-Projekt. Setzen Sie create_project = false und geben Sie Projekt-ID und Pfad zum Service-Account-Schlüssel an. Die alternative Projekterstellung setzt einen freigegebenen übergeordneten Container und Berechtigungen voraus; sie ersetzt keine Landing-Zone-Governance. Zugangsdaten, State, gespeicherte Pläne und Migrationsnachweise gehören nie in die Versionsverwaltung.

Erstellen Sie für einen neuen Checkout die private Variablendatei, ohne eine vorhandene zu überschreiben:

umask 077
test -e env.tfvars || cp env.tfvars.example env.tfvars
chmod 600 env.tfvars

Bearbeiten Sie diese Datei vor dem Plan: Tragen Sie freigegebenes Projekt und Service-Account-Pfad, Region, unterstützte SKE-Version, verfügbaren Node-Pool-Flavor samt Zone und delegierte DNS-Einstellungen aus dem Repository-Beispiel ein. Prüfen Sie Backend-Zugriff und Sperren, Quotas, Kosten sowie die Grenzen von HTTP und öffentlichen Metriken. Die folgenden Funktionsschalter bilden keine vollständige Umgebungskonfiguration.

Einheitliche Automatisierungs-Flags

Der optionale gemeinsame Wrapper bildet setup_project, setup_observability, setup_database, setup_workload, setup_loadgen und setup_dns auf die Terraform-Schalter des Repositorys ab. Sie wählen ausschließlich den Bereitstellungsumfang: Das Aktivieren der Datenbank erlaubt keinen Datenaustausch und ersetzt niemals die separate Migrationsfreigabe.

Minimale Zielkonfiguration

Diese Werte aktivieren den vollständigen Workload- und Datenbankpfad. Sie ergänzen die Angaben zu Projekt, Region, Node Pool und DNS im Repository-Beispiel, ersetzen sie aber nicht.

deploy_workload                   = true
dns_enabled                       = true
enable_postgres_flex              = true
postgres_flex_target_database     = "springmusic"
postgres_flex_target_app_acl_cidrs = []
observability_enabled             = true
create_observability_instance     = true
create_grafana_dashboard          = true
enable_springboot_hpa              = false
enable_load_generator             = false
deploy_postgres_migration_job      = false

Lassen Sie HPA und Lastgenerierung während der Migration deaktiviert. Wählen Sie Alarmeinstellungen bewusst; die Alarmzustellung wurde im End-to-End-Test nicht validiert. springboot_image wählt die Java-Laufzeit, nicht ein beliebiges vorgefertigtes Anwendungsimage. Der Init-Container lädt das auf einen Commit fixierte Rehost-JAR und prüft vor dem Start seinen SHA-256-Wert. Spiegeln Sie unveränderliche Artefakte für die Produktion in freigegebene Artefakt- und Image-Dienste.

Führen Sie die Befehle im Replatform-Repository aus und prüfen Sie den gespeicherten Plan vor dem Apply:

umask 077
terraform init
terraform validate
terraform plan -var-file=env.tfvars -out=tfplan
terraform apply tfplan
bash scripts/validate_gateway.sh

Zugriffskontrolle und temporäre ACL-Erweiterung für Migration

Bei leeren Anwendungs-ACL-Eingaben verwendet Terraform die tatsächlichen Egress-CIDRs des SKE-Clusters für PostgreSQL Flex. Explizite Anwendungs- oder ältere ACL-Werte überschreiben diesen Standard und müssen geprüft werden. Erlauben Sie nicht 0.0.0.0/0.

Der temporäre PostgreSQL-Client läuft in SKE und erhält den Dump über kubectl. Er verbindet sich nicht direkt mit der Quell-VM; weder Quell- noch Arbeitsplatz-CIDRs benötigen temporären Flex-Zugriff. JDBC und Datenbankwerkzeuge verwenden sslmode=require: Das erzwingt Verschlüsselung, bietet aber nicht die Hostnamenprüfung von verify-full. Schützen Sie Zugangsdaten in Kubernetes Secrets und im Terraform-Backend und validieren Sie bei Bedarf eine stärkere Zertifikatsprüfung.

Migration proben

Stellen Sie den finalen Dump in der isolierten Probedatenbank wieder her und verlangen Sie passende Nachweise, die jünger als 24 Stunden sind.

Führen Sie nach dem Infrastruktur-Apply einen isolierten Restore in springmusic_rehearsal aus. Passen Sie das Quellverzeichnis an die freigegebenen Artefakte an und halten Sie den Nachweispfad privat.

python3 scripts/migrate_postgres.py rehearse \
  --artifacts ../stackit-cmf-Rehost-springboot/artifacts \
  --evidence .tmp/migration-run

Die Probe validiert Manifest, Dump-Prüfsumme, Zielidentität, Zeilenanzahl und Fingerprint, ohne die Anwendungsdatenbank zu ersetzen. Proben Sie nach dem Schreibstopp auf der Quelle erneut mit dem finalen Dump. Der Cutover verlangt passende Nachweise, die jünger als 24 Stunden sind. Eine erfolgreiche Probe mit einem älteren oder anderen Dump gibt die finale Eingabe nicht frei.

Option: VM-PostgreSQL nach PostgreSQL Flex migrieren

Der alte Pfad deploy_postgres_migration_job = true wird durch die Validierung gesperrt. Nutzen Sie stattdessen den freigabegesteuerten Workflow. Stoppen Sie HPA, Lastgenerierung und alle anderen Zielschreiber. Pausieren Sie Terraform- und GitOps-Reconciliation, solange das Skript die Replikazahl steuert. Seine lokale Sperre schützt nur einen Checkout, nicht vor gleichzeitigen Bedienern auf unterschiedlichen Rechnern.

python3 scripts/migrate_postgres.py cutover \
  --artifacts ../stackit-cmf-Rehost-springboot/artifacts \
  --evidence .tmp/migration-run \
  --source-write-frozen --confirm-target springmusic

Das Quellschreibstopp-Flag ist eine Bestätigung des Betreibers, keine automatische Abschaltung der Quelle. Der Cutover skaliert die Anwendung auf null, sichert das Ziel vor dem Cutover und prüft die Sicherung per Prüfsumme. Er weist ihre Wiederherstellbarkeit in der Probedatenbank nach und stellt erst dann die Quelle transaktional wieder her. Vor dem Wiederanlauf mit ursprünglicher Replikazahl werden die Daten geprüft. Bei Fehlern bleibt die Anwendung zur Untersuchung gestoppt. Bewahren Sie Nachweisjournal und Backup auf; überschreiben Sie sie nicht für einen erneuten Versuch.

Validieren und zurückrollen

Vergleichen Sie Datenbanknachweise mit dem Quellmanifest, prüfen Sie das Anwendungsverhalten über das Gateway und bestätigen Sie den Zustand beider Metrik-Jobs. Traffic-Umschaltung und fachliche Abnahme bleiben Betreiberaufgaben; das Skript ändert den Endpunkt der Quellanwendung nicht.

So stellen Sie die geschützte Zieldatenbank aus der Zeit vor dem Cutover wieder her:

python3 scripts/migrate_postgres.py rollback \
  --evidence .tmp/migration-run --confirm-target springmusic

Der Rollback prüft Zielidentität und Backup-Integrität, sichert das aktuelle Ziel separat, stellt die ursprünglichen Daten wieder her und verifiziert vor dem Wiederanlauf deren Fingerprint. Schreibzugriffe nach dem Cutover werden nicht zusammengeführt; bewahren Sie den Dump vor dem Rollback für einen expliziten Abgleich auf. Dies ist ein Zieldatenbank-Rollback, kein automatischer Failback zur Quell-VM.

Datenbank-Metriken in Observability sichtbar machen

Terraform verwaltet den Grafana-Ordner SCF Replatform und das Dashboard mit acht Panels an der vorhandenen Datenquelle Thanos. Öffnen Sie es über grafana_dashboard_url. Cluster-CPU, Cluster-Speicher, laufende Pods, Anwendungsanfragen sowie PostgreSQL-Zustand und -Auslastung unterstützen Abnahme und spätere Optimierung. Ein manueller Dashboard-Import ist nicht nötig.

Anwendungsmetriken stammen aus dem pod-lokalen Boot-2-Actuator über den Metrikadapter auf Port 9090; der PostgreSQL-Exporter nutzt Port 9187. Prüfen Sie beide tatsächlichen Scrape-Ergebnisse, nicht nur die Dashboard-Darstellung. Fehlende Telemetrie ist ein Untersuchungsgrund, niemals der Nachweis fehlender Last.

Validierung mit kubectl

Exportieren Sie eine kurzlebige Kubeconfig mit privaten Berechtigungen und prüfen Sie den Standard-Namespace der Referenz:

umask 077
mkdir -p .tmp
terraform output -raw kubeconfig > .tmp/replatform.kubeconfig
export KUBECONFIG="$PWD/.tmp/replatform.kubeconfig"
kubectl get deploy,svc,pods -n springboot
kubectl get gateway,httproute -n springboot
kubectl rollout status deployment/springboot -n springboot
bash scripts/validate_gateway.sh

Der Gateway-Validator prüft Akzeptanz, aufgelöste Routenreferenzen, DNS und Anwendungsantwort. Entfernen Sie die lokale Kubeconfig nach Gebrauch und beziehen Sie nach Ablauf eine neue. Ein erfolgreicher Rollout allein ist keine Daten- oder fachliche Abnahme.

Grenze zwischen Backup und Recovery

Trennen Sie Migrations-Rollback von Flex-Service-Recovery und bewahren Sie geschützte Nachweise außerhalb kurzlebiger Ausführungsumgebungen auf.

Die Flex-Aufbewahrung wird explizit konfiguriert; der Standard dieser Referenz beträgt 32 Tage. Managed-Datenbankbackups und der Migrationsdump vor dem Cutover dienen unterschiedlichen Zwecken. Die Probe mit Letzterem weist weder Managed-Service-Restore noch Point-in-Time-Recovery oder Disaster Recovery der Anwendung nach. Benennen Sie Recovery-Verantwortliche und testen Sie den benötigten Service-Recovery-Pfad separat.

Bewahren Sie geschützte Nachweise und Backups bis zum Ende des Rollback-Fensters außerhalb eines kurzlebigen Dev Containers auf. Prüfen Sie nach einem abgebrochenen Migrationsprozess verbliebene Pods mit Präfix springmusic-migration-*, bevor Sie fortfahren; starten Sie ein ungeprüftes Ziel nicht durch Terraform neu.

Was dieses Asset zeigt

Dieses Asset zeigt, wie das Anwendungsverhalten beim Wechsel der Betriebsmodelle für Laufzeit und Datenbank erhalten bleibt:

Plattformwechsel: Dasselbe Spring-Boot-JAR auf SKE betreiben, über TLS mit PostgreSQL Flex verbinden und über Gateway API und DNS erreichbar machen.
Kontrollierte Datenmigration: Quelldump und Manifest qualifizieren, einen isolierten Restore proben und vor dem Cutover eine explizite Freigabe sowie ein verifiziertes Zielbackup verlangen. Bei erforderlichem Rollback den Zielzustand vor dem Cutover wiederherstellen.
Unabhängige Validierung: Datenintegrität, Anwendungsantworten, Gateway- und DNS-Bereitschaft sowie tatsächliche Scrape-Ergebnisse prüfen. Den Terraform-Plan auf unerklärte Drift prüfen, statt erfolgreiche Bereitstellung als Migrationsabnahme zu behandeln.
Wiederholbare Observability: Observability-Integration und Grafana-Dashboard mit acht Panels durch Terraform verwalten. Anwendungs- und Datenbanksignale für Abnahme, Stabilisierung und spätere Optimierung nutzen.

Nicht abgedeckt

Diese Nachweise bestätigen weder einen vollständigen Greenfield-Durchlauf noch eine Migration aus einer produktiven Live-Quelle, unterbrechungsfreien Betrieb, Hochverfügbarkeit, öffentliches Gateway-TLS, interaktiven IDP-Login, Alarmzustellung oder Managed-Flex-Recovery. Der getestete Ein-Worker-Aufbau mit HTTP stellt Metriken ohne Authentifizierung bereit; erfüllen Sie die Produktionsanforderungen vor der Verwendung sensibler Daten. Aktualisieren Sie die Beispielanwendung und validieren Sie eine geeignete unterstützte Kubernetes-Version als separate kontrollierte Änderungen.

Code & Registry github.com Referenzkonfiguration, Skripte und Validierungsnachweise Das Repository-README und die versionierte Implementierung liefern genaue Voraussetzungen, Variablen, Befehle und Recovery-Grenzen. Repository öffnen

BASE

Ziel bereitstellen

Migration design-and-mobilize use-cases runnable-example replatform kubernetes terraform ske spring-boot postgresql

Spring Boot mit Terraform von der VM auf Kubernetes umstellen

STACKIT

Dasselbe Spring-Boot-JAR auf STACKIT Kubernetes betreiben: mit PostgreSQL Flex, Gateway API, DNS, Managed Telemetry sowie geprobtem Daten-Cutover und Rollback.

Code & Registry github.com STACKIT Spring Boot Kubernetes Replatform Repository Terraform, Gateway API, PostgreSQL-Migration und Observability der in diesem Asset verwendeten Implementierung öffnen. Repository öffnen

STACKIT

Der souveräne europäische Cloud-Anbieter hinter dem Framework, mit IaaS und PaaS aus deutschen und österreichischen Rechenzentren und voller Unabhängigkeit.

Überblick

Dieses Asset wendet das Migration Framework auf ein Replatform von Spring Boot und PostgreSQL an: Die Anwendung wechselt vom VM-Service zu STACKIT Kubernetes Engine (SKE), die Datenbank von selbstverwaltetem PostgreSQL zu STACKIT PostgreSQL Flex. Geschäftsfunktion und Anwendungs-JAR bleiben unverändert; die Betriebsmodelle für Laufzeit und Datenbank ändern sich.

Referenzimplementierung

Das Referenzrepository ist die maßgebliche Quelle für Terraform, Helm-Charts, fest versionierte Artefakte, Migrationsskripte und Validierung. Verwenden Sie einen geprüften Stand mit den hier beschriebenen Gateway-API- und scripts/migrate_postgres.py-Workflows. Ein älterer Stand mit direktem Datenbank-Import-Job implementiert dieses Verfahren nicht.

Replatform-Scope in diesem Asset

Laufzeit: Dasselbe Spring-Music-JAR mit Spring Boot 2.4.0 läuft auf Java 11 in einem Kubernetes-Deployment statt unter systemd.
Daten: PostgreSQL Flex stellt getrennte Anwendungs- und Probedatenbanken bereit; JDBC- und Migrationsclients benötigen TLS.
Netzwerkverkehr: Envoy Gateway, Gateway API HTTPRoutes und SKE-verwaltetes ExternalDNS ersetzen den VM-Endpunkt.
Betrieb: Kubernetes-Zustands- und Ressourcenkontrollen ersetzen das Host-Service-Management; Managed Telemetry erfasst Cluster-, Anwendungs- und Datenbanksignale.
Migration: Quellnachweise, isolierte Probe, explizit freigegebener Cutover und verifizierter Datenbank-Rollback bleiben von der Infrastrukturbereitstellung getrennt.

Cloud Foundry, Object Storage, die Zerlegung in Microservices und Anwendungsmodernisierung sind nicht Teil dieser Implementierung. Die alte Beispielanwendung demonstriert einen Plattformwechsel; sie ist keine Empfehlung, einen nicht mehr unterstützten Anwendungsstack produktiv einzusetzen.

Architekturdiagramm der Referenz

Prüfen Sie das Architektur-Asset vor der Wahl von Kapazität und Netzwerkkontrollen. Es trennt die implementierte Topologie von Produktionserweiterungen wie öffentlichem HTTPS, hochverfügbaren Workern und geschützten Metriken.

Cloud Framework Spring Boot auf SKE mit PostgreSQL Flex und Gateway API Implementierte Topologie, Laufzeit- und Datengrenzen sowie separat zu qualifizierende Produktionserweiterungen prüfen. Seite öffnen

End-to-End-Ablauf

Replatform-Eignung, Quellkompatibilität, Landing-Zone-Bereitschaft und Verantwortlichkeiten bestätigen.
Einen vertrauenswürdigen PostgreSQL-Dump und ein Integritätsmanifest unabhängig vom Ziel vorbereiten.
Terraform für SKE, PostgreSQL Flex, Gateway, DNS, Workload und Observability prüfen und anwenden.
Das Ziel validieren und den finalen Quelldump in der isolierten Probedatenbank testen.
Quellschreibzugriffe einfrieren, Ausfallzeit freigeben und den kontrollierten Cutover mit geschütztem Zielbackup ausführen.
Anwendungs- und Datennachweise abnehmen oder den Zielzustand vor dem Cutover wiederherstellen; den Client-Traffic nach dem freigegebenen Betreiberverfahren umschalten.
Nachweise während der Stabilisierung aufbewahren und repräsentative Telemetrie für spätere Optimierung nutzen.

Arbeitsumgebung für den Walkthrough vorbereiten

Verwenden Sie eine isolierte Linux-Laborumgebung mit Git, Terraform, kubectl, curl, jq, getent, Python ab Version 3.11 sowie PostgreSQL-Server- und Client-Werkzeugen. Die Rehost-Beispielskripte benötigen außerdem runuser, sha256sum, ein Betriebssystemkonto postgres und Root-Rechte, um eine temporäre lokale Datenbank zu erstellen und zu prüfen. Führen Sie die Beispielbefehle in dieser vorbereiteten Laborumgebung aus, nicht auf einem produktiven Datenbankhost. Die privaten Artefakte müssen für den Migrationsbediener lesbar bleiben; machen Sie sie nicht für alle Benutzer lesbar.

Beziehen Sie geprüfte Commit-IDs beider Repositorys vom Referenz-Maintainer und exportieren Sie diese vorab als REHOST_REVISION und REPLATFORM_REVISION. Der Replatform-Stand muss Gateway API und den freigabegesteuerten Migrationsworkflow enthalten. Setzen Sie nicht voraus, dass der Remote-Standardbranch bereits die lokal getestete Implementierung enthält. Ist der freigegebene Stand nicht verfügbar, beschaffen Sie ihn vor dem Walkthrough.

Ersetzen Sie beide Platzhalter durch die freigegebenen vollständigen Commit-IDs mit jeweils 40 Zeichen und setzen Sie diese im selben Bash-Terminal:

export REHOST_REVISION="REPLACE_WITH_REVIEWED_REHOST_COMMIT_ID"
export REPLATFORM_REVISION="REPLACE_WITH_REVIEWED_REPLATFORM_COMMIT_ID"

Führen Sie den folgenden Block vollständig aus einem leeren Arbeitsverzeichnis aus. Die if-Prüfung lehnt fehlende, leere oder falsch formatierte IDs einschließlich unveränderter Platzhalter ab. Jedes && führt den nächsten Befehl nur nach Erfolg des vorherigen aus. Git prüft die Verfügbarkeit der Commits; die Formatprüfung allein bestätigt weder Freigabe noch Repository-Inhalt.

if [[ ! ${REHOST_REVISION:-} =~ ^[0-9a-fA-F]{40}$ ||
      ! ${REPLATFORM_REVISION:-} =~ ^[0-9a-fA-F]{40}$ ]]; then
  printf '%s\n' "Set both revision variables to reviewed full 40-character commit IDs." >&2
  false
else
  umask 077 &&
    git clone https://github.com/stackitcloud/stackit-cmf-Rehost-springboot.git &&
    git clone https://github.com/stackitcloud/stackit-cmf-replatform-springboot-k8s.git &&
    git -C stackit-cmf-Rehost-springboot checkout --detach "$REHOST_REVISION" &&
    git -C stackit-cmf-replatform-springboot-k8s checkout --detach "$REPLATFORM_REVISION" &&
    test -f stackit-cmf-replatform-springboot-k8s/scripts/migrate_postgres.py &&
    test -f stackit-cmf-replatform-springboot-k8s/scripts/validate_gateway.sh &&
    cd stackit-cmf-replatform-springboot-k8s &&
    printf '%s\n' "Workspace ready. Continue from this Replatform checkout." || {
      printf '%s\n' "Preparation failed. Resolve the error before continuing." >&2
      false
    }
fi

Fahren Sie erst nach der Meldung Workspace ready fort. Bei Fehlern bleibt das Terminal offen; weitere Vorbereitungsbefehle werden übersprungen. Vorhandene oder teilweise geklonte Verzeichnisse werden weder entfernt noch überschrieben: Prüfen Sie diese und bewahren Sie lokale Änderungen, bevor Sie es in einem neuen leeren Arbeitsverzeichnis erneut versuchen. Nach Erfolg befindet sich das Terminal für die nächsten Schritte im Replatform-Checkout.

Nutzen Sie ein freigegebenes STACKIT Projekt, einen Service Account, DNS-Delegation, SKE-Kapazität und ein geschütztes Terraform-Backend. Beziehen Sie Zugangsdaten über den freigegebenen Secret-Kanal, niemals aus diesem Trail. Die folgenden Befehle setzen diese Verzeichnisstruktur und eine geprüfte Konfiguration voraus; sie belegen keinen validierten Greenfield-Produktionsaufbau.

Quellnachweise vorbereiten

Qualifizieren Sie einen konsistenten Quelldump und sein Manifest, bevor Daten in den Migrationsworkflow eingehen.

Die Rehost-Referenz liefert scripts/create_source_dump.sh und scripts/validate_source_dump.sh für ihr reproduzierbares Beispiel. Führen Sie diese im Rehost-Repository aus. Dessen Verzeichnis artifacts liefert source-postgresql.dump und source-postgresql.manifest an den Replatform-Workflow. Das Manifest erfasst Version 1, table=public.album, row_count, album_fingerprint und dump_sha256.

Führen Sie ausschließlich für das reproduzierbare Beispiel die folgenden Befehle vom Replatform-Checkout in der vorbereiteten Laborumgebung aus. Die Skripte erstellen aus dem versionierten Beispiel-SQL eine temporäre PostgreSQL-Instanz, exportieren sie und führen einen unabhängigen Test-Restore aus. Verwenden Sie ein frisches Artefaktverzeichnis; überschreiben Sie keine Nachweise einer bereits laufenden Migration.

umask 077
pushd ../stackit-cmf-Rehost-springboot
bash scripts/create_source_dump.sh
bash scripts/validate_source_dump.sh
popd

Erwartet wird eine erfolgreiche Validierung von acht Zeilen mit passendem Fingerprint. Diese Befehle lesen keine Quell-VM aus. Verwenden Sie für Probe und Cutover genau diese Artefakte weiter.

Ersetzen Sie für eine reale Quelle den Beispielgenerator durch ein freigegebenes Exportverfahren: Frieren Sie alle Schreibzugriffe ein und leiten Sie Dump im Custom-Format und Manifest aus demselben konsistenten Quellsnapshot ab. Das generierte Beispiel mit acht Alben ist kein Export einer beliebigen laufenden VM. Prüfen Sie vor dem Export PostgreSQL-Kompatibilität, Erweiterungen, Eigentümerschaft und Schemaabhängigkeiten.

Stellen Sie nur vertrauenswürdige Dumps wieder her, da sie SQL ausführen. Diese Implementierung migriert das Anwendungsschema public und prüft public.album; von Flex verwaltete Schemas sind bewusst ausgeschlossen. Andere Workloads benötigen eigene Invarianten und einen angepassten Schemaumfang.

Code & Registry github.com Spring-Boot-Rehost-Quelle und Beispielexport Das Rehost-Repository liefert dasselbe Anwendungsartefakt und reproduzierbare Werkzeuge für PostgreSQL-Quellnachweise. Repository öffnen

Ziel bereitstellen

Stellen Sie das Ziel aus einem geprüften Plan mit expliziten Angaben zu Projekt, Kapazität, Zugriff und DNS bereit.

Verwenden Sie Terraform, kubectl, curl, jq, getent und Python ab Version 3.11 unter Linux. Kopieren Sie env.tfvars.example nach env.tfvars und passen Sie die tatsächlichen Variablen dieser Datei an. Behalten Sie die getestete Provider-Lockdatei und unveränderliche Image- und JAR-Referenzen bei. Bestätigen Sie vor dem Plan die Verfügbarkeit der SKE-Version, Node-Pool-Kapazität, Projektberechtigungen und DNS-Delegation.

Aus der STACKIT-DokuLifecycle of Kubernetes Engine › Kubernetes end-of-life datesStand der Quelle 24.08.2026 · übernommen 05.10.2026

Starting with Kubernetes v1.33, we remove minor versions on the patch day that precedes the upstream maintenance end-of-life (EOL) date. The following table below lists the upstream EOL date for each Kubernetes minor version and the corresponding expiration date in SKE:

Seitlich wischen, um die ganze Tabelle zu sehen

Kubernetes minor version	End-of-life date	Expiration in SKE
v1.32	2026-02-28	2026-04-15
v1.33	2026-06-28	2026-06-10
v1.34	2026-10-27	2026-10-14
v1.35	2027-02-28	2027-02-10

Please refer to the official Kubernetes Release History for up-to-date announcements of new versions.

Was ist das?

Dieser Abschnitt wird mehrmals am Tag automatisch aus der STACKIT-Doku übernommen. Hier lässt er sich nicht ändern. Änderungen gehören in die STACKIT-Doku.

Bevorzugen Sie ein freigegebenes Application-Landing-Zone-Projekt. Setzen Sie create_project = false und geben Sie Projekt-ID und Pfad zum Service-Account-Schlüssel an. Die alternative Projekterstellung setzt einen freigegebenen übergeordneten Container und Berechtigungen voraus; sie ersetzt keine Landing-Zone-Governance. Zugangsdaten, State, gespeicherte Pläne und Migrationsnachweise gehören nie in die Versionsverwaltung.

Erstellen Sie für einen neuen Checkout die private Variablendatei, ohne eine vorhandene zu überschreiben:

umask 077
test -e env.tfvars || cp env.tfvars.example env.tfvars
chmod 600 env.tfvars

Bearbeiten Sie diese Datei vor dem Plan: Tragen Sie freigegebenes Projekt und Service-Account-Pfad, Region, unterstützte SKE-Version, verfügbaren Node-Pool-Flavor samt Zone und delegierte DNS-Einstellungen aus dem Repository-Beispiel ein. Prüfen Sie Backend-Zugriff und Sperren, Quotas, Kosten sowie die Grenzen von HTTP und öffentlichen Metriken. Die folgenden Funktionsschalter bilden keine vollständige Umgebungskonfiguration.

Einheitliche Automatisierungs-Flags

Der optionale gemeinsame Wrapper bildet setup_project, setup_observability, setup_database, setup_workload, setup_loadgen und setup_dns auf die Terraform-Schalter des Repositorys ab. Sie wählen ausschließlich den Bereitstellungsumfang: Das Aktivieren der Datenbank erlaubt keinen Datenaustausch und ersetzt niemals die separate Migrationsfreigabe.

Minimale Zielkonfiguration

Diese Werte aktivieren den vollständigen Workload- und Datenbankpfad. Sie ergänzen die Angaben zu Projekt, Region, Node Pool und DNS im Repository-Beispiel, ersetzen sie aber nicht.

deploy_workload                   = true
dns_enabled                       = true
enable_postgres_flex              = true
postgres_flex_target_database     = "springmusic"
postgres_flex_target_app_acl_cidrs = []
observability_enabled             = true
create_observability_instance     = true
create_grafana_dashboard          = true
enable_springboot_hpa              = false
enable_load_generator             = false
deploy_postgres_migration_job      = false

Lassen Sie HPA und Lastgenerierung während der Migration deaktiviert. Wählen Sie Alarmeinstellungen bewusst; die Alarmzustellung wurde im End-to-End-Test nicht validiert. springboot_image wählt die Java-Laufzeit, nicht ein beliebiges vorgefertigtes Anwendungsimage. Der Init-Container lädt das auf einen Commit fixierte Rehost-JAR und prüft vor dem Start seinen SHA-256-Wert. Spiegeln Sie unveränderliche Artefakte für die Produktion in freigegebene Artefakt- und Image-Dienste.

Führen Sie die Befehle im Replatform-Repository aus und prüfen Sie den gespeicherten Plan vor dem Apply:

umask 077
terraform init
terraform validate
terraform plan -var-file=env.tfvars -out=tfplan
terraform apply tfplan
bash scripts/validate_gateway.sh

Zugriffskontrolle und temporäre ACL-Erweiterung für Migration

Bei leeren Anwendungs-ACL-Eingaben verwendet Terraform die tatsächlichen Egress-CIDRs des SKE-Clusters für PostgreSQL Flex. Explizite Anwendungs- oder ältere ACL-Werte überschreiben diesen Standard und müssen geprüft werden. Erlauben Sie nicht 0.0.0.0/0.

Der temporäre PostgreSQL-Client läuft in SKE und erhält den Dump über kubectl. Er verbindet sich nicht direkt mit der Quell-VM; weder Quell- noch Arbeitsplatz-CIDRs benötigen temporären Flex-Zugriff. JDBC und Datenbankwerkzeuge verwenden sslmode=require: Das erzwingt Verschlüsselung, bietet aber nicht die Hostnamenprüfung von verify-full. Schützen Sie Zugangsdaten in Kubernetes Secrets und im Terraform-Backend und validieren Sie bei Bedarf eine stärkere Zertifikatsprüfung.

Migration proben

Stellen Sie den finalen Dump in der isolierten Probedatenbank wieder her und verlangen Sie passende Nachweise, die jünger als 24 Stunden sind.

Führen Sie nach dem Infrastruktur-Apply einen isolierten Restore in springmusic_rehearsal aus. Passen Sie das Quellverzeichnis an die freigegebenen Artefakte an und halten Sie den Nachweispfad privat.

python3 scripts/migrate_postgres.py rehearse \
  --artifacts ../stackit-cmf-Rehost-springboot/artifacts \
  --evidence .tmp/migration-run

Die Probe validiert Manifest, Dump-Prüfsumme, Zielidentität, Zeilenanzahl und Fingerprint, ohne die Anwendungsdatenbank zu ersetzen. Proben Sie nach dem Schreibstopp auf der Quelle erneut mit dem finalen Dump. Der Cutover verlangt passende Nachweise, die jünger als 24 Stunden sind. Eine erfolgreiche Probe mit einem älteren oder anderen Dump gibt die finale Eingabe nicht frei.

Option: VM-PostgreSQL nach PostgreSQL Flex migrieren

Der alte Pfad deploy_postgres_migration_job = true wird durch die Validierung gesperrt. Nutzen Sie stattdessen den freigabegesteuerten Workflow. Stoppen Sie HPA, Lastgenerierung und alle anderen Zielschreiber. Pausieren Sie Terraform- und GitOps-Reconciliation, solange das Skript die Replikazahl steuert. Seine lokale Sperre schützt nur einen Checkout, nicht vor gleichzeitigen Bedienern auf unterschiedlichen Rechnern.

python3 scripts/migrate_postgres.py cutover \
  --artifacts ../stackit-cmf-Rehost-springboot/artifacts \
  --evidence .tmp/migration-run \
  --source-write-frozen --confirm-target springmusic

Das Quellschreibstopp-Flag ist eine Bestätigung des Betreibers, keine automatische Abschaltung der Quelle. Der Cutover skaliert die Anwendung auf null, sichert das Ziel vor dem Cutover und prüft die Sicherung per Prüfsumme. Er weist ihre Wiederherstellbarkeit in der Probedatenbank nach und stellt erst dann die Quelle transaktional wieder her. Vor dem Wiederanlauf mit ursprünglicher Replikazahl werden die Daten geprüft. Bei Fehlern bleibt die Anwendung zur Untersuchung gestoppt. Bewahren Sie Nachweisjournal und Backup auf; überschreiben Sie sie nicht für einen erneuten Versuch.

Validieren und zurückrollen

Vergleichen Sie Datenbanknachweise mit dem Quellmanifest, prüfen Sie das Anwendungsverhalten über das Gateway und bestätigen Sie den Zustand beider Metrik-Jobs. Traffic-Umschaltung und fachliche Abnahme bleiben Betreiberaufgaben; das Skript ändert den Endpunkt der Quellanwendung nicht.

So stellen Sie die geschützte Zieldatenbank aus der Zeit vor dem Cutover wieder her:

python3 scripts/migrate_postgres.py rollback \
  --evidence .tmp/migration-run --confirm-target springmusic

Der Rollback prüft Zielidentität und Backup-Integrität, sichert das aktuelle Ziel separat, stellt die ursprünglichen Daten wieder her und verifiziert vor dem Wiederanlauf deren Fingerprint. Schreibzugriffe nach dem Cutover werden nicht zusammengeführt; bewahren Sie den Dump vor dem Rollback für einen expliziten Abgleich auf. Dies ist ein Zieldatenbank-Rollback, kein automatischer Failback zur Quell-VM.

Datenbank-Metriken in Observability sichtbar machen

Terraform verwaltet den Grafana-Ordner SCF Replatform und das Dashboard mit acht Panels an der vorhandenen Datenquelle Thanos. Öffnen Sie es über grafana_dashboard_url. Cluster-CPU, Cluster-Speicher, laufende Pods, Anwendungsanfragen sowie PostgreSQL-Zustand und -Auslastung unterstützen Abnahme und spätere Optimierung. Ein manueller Dashboard-Import ist nicht nötig.

Anwendungsmetriken stammen aus dem pod-lokalen Boot-2-Actuator über den Metrikadapter auf Port 9090; der PostgreSQL-Exporter nutzt Port 9187. Prüfen Sie beide tatsächlichen Scrape-Ergebnisse, nicht nur die Dashboard-Darstellung. Fehlende Telemetrie ist ein Untersuchungsgrund, niemals der Nachweis fehlender Last.

Validierung mit kubectl

Exportieren Sie eine kurzlebige Kubeconfig mit privaten Berechtigungen und prüfen Sie den Standard-Namespace der Referenz:

umask 077
mkdir -p .tmp
terraform output -raw kubeconfig > .tmp/replatform.kubeconfig
export KUBECONFIG="$PWD/.tmp/replatform.kubeconfig"
kubectl get deploy,svc,pods -n springboot
kubectl get gateway,httproute -n springboot
kubectl rollout status deployment/springboot -n springboot
bash scripts/validate_gateway.sh

Der Gateway-Validator prüft Akzeptanz, aufgelöste Routenreferenzen, DNS und Anwendungsantwort. Entfernen Sie die lokale Kubeconfig nach Gebrauch und beziehen Sie nach Ablauf eine neue. Ein erfolgreicher Rollout allein ist keine Daten- oder fachliche Abnahme.

Grenze zwischen Backup und Recovery

Trennen Sie Migrations-Rollback von Flex-Service-Recovery und bewahren Sie geschützte Nachweise außerhalb kurzlebiger Ausführungsumgebungen auf.

Die Flex-Aufbewahrung wird explizit konfiguriert; der Standard dieser Referenz beträgt 32 Tage. Managed-Datenbankbackups und der Migrationsdump vor dem Cutover dienen unterschiedlichen Zwecken. Die Probe mit Letzterem weist weder Managed-Service-Restore noch Point-in-Time-Recovery oder Disaster Recovery der Anwendung nach. Benennen Sie Recovery-Verantwortliche und testen Sie den benötigten Service-Recovery-Pfad separat.

Bewahren Sie geschützte Nachweise und Backups bis zum Ende des Rollback-Fensters außerhalb eines kurzlebigen Dev Containers auf. Prüfen Sie nach einem abgebrochenen Migrationsprozess verbliebene Pods mit Präfix springmusic-migration-*, bevor Sie fortfahren; starten Sie ein ungeprüftes Ziel nicht durch Terraform neu.

Was dieses Asset zeigt

Dieses Asset zeigt, wie das Anwendungsverhalten beim Wechsel der Betriebsmodelle für Laufzeit und Datenbank erhalten bleibt:

Plattformwechsel: Dasselbe Spring-Boot-JAR auf SKE betreiben, über TLS mit PostgreSQL Flex verbinden und über Gateway API und DNS erreichbar machen.
Kontrollierte Datenmigration: Quelldump und Manifest qualifizieren, einen isolierten Restore proben und vor dem Cutover eine explizite Freigabe sowie ein verifiziertes Zielbackup verlangen. Bei erforderlichem Rollback den Zielzustand vor dem Cutover wiederherstellen.
Unabhängige Validierung: Datenintegrität, Anwendungsantworten, Gateway- und DNS-Bereitschaft sowie tatsächliche Scrape-Ergebnisse prüfen. Den Terraform-Plan auf unerklärte Drift prüfen, statt erfolgreiche Bereitstellung als Migrationsabnahme zu behandeln.
Wiederholbare Observability: Observability-Integration und Grafana-Dashboard mit acht Panels durch Terraform verwalten. Anwendungs- und Datenbanksignale für Abnahme, Stabilisierung und spätere Optimierung nutzen.

Nicht abgedeckt

Diese Nachweise bestätigen weder einen vollständigen Greenfield-Durchlauf noch eine Migration aus einer produktiven Live-Quelle, unterbrechungsfreien Betrieb, Hochverfügbarkeit, öffentliches Gateway-TLS, interaktiven IDP-Login, Alarmzustellung oder Managed-Flex-Recovery. Der getestete Ein-Worker-Aufbau mit HTTP stellt Metriken ohne Authentifizierung bereit; erfüllen Sie die Produktionsanforderungen vor der Verwendung sensibler Daten. Aktualisieren Sie die Beispielanwendung und validieren Sie eine geeignete unterstützte Kubernetes-Version als separate kontrollierte Änderungen.

Code & Registry github.com Referenzkonfiguration, Skripte und Validierungsnachweise Das Repository-README und die versionierte Implementierung liefern genaue Voraussetzungen, Variablen, Befehle und Recovery-Grenzen. Repository öffnen

SAFE

Datenbankzugriffsgrenzen prüfen

Migration design-and-mobilize use-cases runnable-example replatform kubernetes terraform ske spring-boot postgresql

Spring Boot mit Terraform von der VM auf Kubernetes umstellen

STACKIT

Dasselbe Spring-Boot-JAR auf STACKIT Kubernetes betreiben: mit PostgreSQL Flex, Gateway API, DNS, Managed Telemetry sowie geprobtem Daten-Cutover und Rollback.

Code & Registry github.com STACKIT Spring Boot Kubernetes Replatform Repository Terraform, Gateway API, PostgreSQL-Migration und Observability der in diesem Asset verwendeten Implementierung öffnen. Repository öffnen

STACKIT

Der souveräne europäische Cloud-Anbieter hinter dem Framework, mit IaaS und PaaS aus deutschen und österreichischen Rechenzentren und voller Unabhängigkeit.

Überblick

Dieses Asset wendet das Migration Framework auf ein Replatform von Spring Boot und PostgreSQL an: Die Anwendung wechselt vom VM-Service zu STACKIT Kubernetes Engine (SKE), die Datenbank von selbstverwaltetem PostgreSQL zu STACKIT PostgreSQL Flex. Geschäftsfunktion und Anwendungs-JAR bleiben unverändert; die Betriebsmodelle für Laufzeit und Datenbank ändern sich.

Referenzimplementierung

Das Referenzrepository ist die maßgebliche Quelle für Terraform, Helm-Charts, fest versionierte Artefakte, Migrationsskripte und Validierung. Verwenden Sie einen geprüften Stand mit den hier beschriebenen Gateway-API- und scripts/migrate_postgres.py-Workflows. Ein älterer Stand mit direktem Datenbank-Import-Job implementiert dieses Verfahren nicht.

Replatform-Scope in diesem Asset

Laufzeit: Dasselbe Spring-Music-JAR mit Spring Boot 2.4.0 läuft auf Java 11 in einem Kubernetes-Deployment statt unter systemd.
Daten: PostgreSQL Flex stellt getrennte Anwendungs- und Probedatenbanken bereit; JDBC- und Migrationsclients benötigen TLS.
Netzwerkverkehr: Envoy Gateway, Gateway API HTTPRoutes und SKE-verwaltetes ExternalDNS ersetzen den VM-Endpunkt.
Betrieb: Kubernetes-Zustands- und Ressourcenkontrollen ersetzen das Host-Service-Management; Managed Telemetry erfasst Cluster-, Anwendungs- und Datenbanksignale.
Migration: Quellnachweise, isolierte Probe, explizit freigegebener Cutover und verifizierter Datenbank-Rollback bleiben von der Infrastrukturbereitstellung getrennt.

Cloud Foundry, Object Storage, die Zerlegung in Microservices und Anwendungsmodernisierung sind nicht Teil dieser Implementierung. Die alte Beispielanwendung demonstriert einen Plattformwechsel; sie ist keine Empfehlung, einen nicht mehr unterstützten Anwendungsstack produktiv einzusetzen.

Architekturdiagramm der Referenz

Prüfen Sie das Architektur-Asset vor der Wahl von Kapazität und Netzwerkkontrollen. Es trennt die implementierte Topologie von Produktionserweiterungen wie öffentlichem HTTPS, hochverfügbaren Workern und geschützten Metriken.

Cloud Framework Spring Boot auf SKE mit PostgreSQL Flex und Gateway API Implementierte Topologie, Laufzeit- und Datengrenzen sowie separat zu qualifizierende Produktionserweiterungen prüfen. Seite öffnen

End-to-End-Ablauf

Replatform-Eignung, Quellkompatibilität, Landing-Zone-Bereitschaft und Verantwortlichkeiten bestätigen.
Einen vertrauenswürdigen PostgreSQL-Dump und ein Integritätsmanifest unabhängig vom Ziel vorbereiten.
Terraform für SKE, PostgreSQL Flex, Gateway, DNS, Workload und Observability prüfen und anwenden.
Das Ziel validieren und den finalen Quelldump in der isolierten Probedatenbank testen.
Quellschreibzugriffe einfrieren, Ausfallzeit freigeben und den kontrollierten Cutover mit geschütztem Zielbackup ausführen.
Anwendungs- und Datennachweise abnehmen oder den Zielzustand vor dem Cutover wiederherstellen; den Client-Traffic nach dem freigegebenen Betreiberverfahren umschalten.
Nachweise während der Stabilisierung aufbewahren und repräsentative Telemetrie für spätere Optimierung nutzen.

Arbeitsumgebung für den Walkthrough vorbereiten

Verwenden Sie eine isolierte Linux-Laborumgebung mit Git, Terraform, kubectl, curl, jq, getent, Python ab Version 3.11 sowie PostgreSQL-Server- und Client-Werkzeugen. Die Rehost-Beispielskripte benötigen außerdem runuser, sha256sum, ein Betriebssystemkonto postgres und Root-Rechte, um eine temporäre lokale Datenbank zu erstellen und zu prüfen. Führen Sie die Beispielbefehle in dieser vorbereiteten Laborumgebung aus, nicht auf einem produktiven Datenbankhost. Die privaten Artefakte müssen für den Migrationsbediener lesbar bleiben; machen Sie sie nicht für alle Benutzer lesbar.

Beziehen Sie geprüfte Commit-IDs beider Repositorys vom Referenz-Maintainer und exportieren Sie diese vorab als REHOST_REVISION und REPLATFORM_REVISION. Der Replatform-Stand muss Gateway API und den freigabegesteuerten Migrationsworkflow enthalten. Setzen Sie nicht voraus, dass der Remote-Standardbranch bereits die lokal getestete Implementierung enthält. Ist der freigegebene Stand nicht verfügbar, beschaffen Sie ihn vor dem Walkthrough.

Ersetzen Sie beide Platzhalter durch die freigegebenen vollständigen Commit-IDs mit jeweils 40 Zeichen und setzen Sie diese im selben Bash-Terminal:

export REHOST_REVISION="REPLACE_WITH_REVIEWED_REHOST_COMMIT_ID"
export REPLATFORM_REVISION="REPLACE_WITH_REVIEWED_REPLATFORM_COMMIT_ID"

Führen Sie den folgenden Block vollständig aus einem leeren Arbeitsverzeichnis aus. Die if-Prüfung lehnt fehlende, leere oder falsch formatierte IDs einschließlich unveränderter Platzhalter ab. Jedes && führt den nächsten Befehl nur nach Erfolg des vorherigen aus. Git prüft die Verfügbarkeit der Commits; die Formatprüfung allein bestätigt weder Freigabe noch Repository-Inhalt.

if [[ ! ${REHOST_REVISION:-} =~ ^[0-9a-fA-F]{40}$ ||
      ! ${REPLATFORM_REVISION:-} =~ ^[0-9a-fA-F]{40}$ ]]; then
  printf '%s\n' "Set both revision variables to reviewed full 40-character commit IDs." >&2
  false
else
  umask 077 &&
    git clone https://github.com/stackitcloud/stackit-cmf-Rehost-springboot.git &&
    git clone https://github.com/stackitcloud/stackit-cmf-replatform-springboot-k8s.git &&
    git -C stackit-cmf-Rehost-springboot checkout --detach "$REHOST_REVISION" &&
    git -C stackit-cmf-replatform-springboot-k8s checkout --detach "$REPLATFORM_REVISION" &&
    test -f stackit-cmf-replatform-springboot-k8s/scripts/migrate_postgres.py &&
    test -f stackit-cmf-replatform-springboot-k8s/scripts/validate_gateway.sh &&
    cd stackit-cmf-replatform-springboot-k8s &&
    printf '%s\n' "Workspace ready. Continue from this Replatform checkout." || {
      printf '%s\n' "Preparation failed. Resolve the error before continuing." >&2
      false
    }
fi

Fahren Sie erst nach der Meldung Workspace ready fort. Bei Fehlern bleibt das Terminal offen; weitere Vorbereitungsbefehle werden übersprungen. Vorhandene oder teilweise geklonte Verzeichnisse werden weder entfernt noch überschrieben: Prüfen Sie diese und bewahren Sie lokale Änderungen, bevor Sie es in einem neuen leeren Arbeitsverzeichnis erneut versuchen. Nach Erfolg befindet sich das Terminal für die nächsten Schritte im Replatform-Checkout.

Nutzen Sie ein freigegebenes STACKIT Projekt, einen Service Account, DNS-Delegation, SKE-Kapazität und ein geschütztes Terraform-Backend. Beziehen Sie Zugangsdaten über den freigegebenen Secret-Kanal, niemals aus diesem Trail. Die folgenden Befehle setzen diese Verzeichnisstruktur und eine geprüfte Konfiguration voraus; sie belegen keinen validierten Greenfield-Produktionsaufbau.

Quellnachweise vorbereiten

Qualifizieren Sie einen konsistenten Quelldump und sein Manifest, bevor Daten in den Migrationsworkflow eingehen.

Die Rehost-Referenz liefert scripts/create_source_dump.sh und scripts/validate_source_dump.sh für ihr reproduzierbares Beispiel. Führen Sie diese im Rehost-Repository aus. Dessen Verzeichnis artifacts liefert source-postgresql.dump und source-postgresql.manifest an den Replatform-Workflow. Das Manifest erfasst Version 1, table=public.album, row_count, album_fingerprint und dump_sha256.

Führen Sie ausschließlich für das reproduzierbare Beispiel die folgenden Befehle vom Replatform-Checkout in der vorbereiteten Laborumgebung aus. Die Skripte erstellen aus dem versionierten Beispiel-SQL eine temporäre PostgreSQL-Instanz, exportieren sie und führen einen unabhängigen Test-Restore aus. Verwenden Sie ein frisches Artefaktverzeichnis; überschreiben Sie keine Nachweise einer bereits laufenden Migration.

umask 077
pushd ../stackit-cmf-Rehost-springboot
bash scripts/create_source_dump.sh
bash scripts/validate_source_dump.sh
popd

Erwartet wird eine erfolgreiche Validierung von acht Zeilen mit passendem Fingerprint. Diese Befehle lesen keine Quell-VM aus. Verwenden Sie für Probe und Cutover genau diese Artefakte weiter.

Ersetzen Sie für eine reale Quelle den Beispielgenerator durch ein freigegebenes Exportverfahren: Frieren Sie alle Schreibzugriffe ein und leiten Sie Dump im Custom-Format und Manifest aus demselben konsistenten Quellsnapshot ab. Das generierte Beispiel mit acht Alben ist kein Export einer beliebigen laufenden VM. Prüfen Sie vor dem Export PostgreSQL-Kompatibilität, Erweiterungen, Eigentümerschaft und Schemaabhängigkeiten.

Stellen Sie nur vertrauenswürdige Dumps wieder her, da sie SQL ausführen. Diese Implementierung migriert das Anwendungsschema public und prüft public.album; von Flex verwaltete Schemas sind bewusst ausgeschlossen. Andere Workloads benötigen eigene Invarianten und einen angepassten Schemaumfang.

Code & Registry github.com Spring-Boot-Rehost-Quelle und Beispielexport Das Rehost-Repository liefert dasselbe Anwendungsartefakt und reproduzierbare Werkzeuge für PostgreSQL-Quellnachweise. Repository öffnen

Ziel bereitstellen

Stellen Sie das Ziel aus einem geprüften Plan mit expliziten Angaben zu Projekt, Kapazität, Zugriff und DNS bereit.

Verwenden Sie Terraform, kubectl, curl, jq, getent und Python ab Version 3.11 unter Linux. Kopieren Sie env.tfvars.example nach env.tfvars und passen Sie die tatsächlichen Variablen dieser Datei an. Behalten Sie die getestete Provider-Lockdatei und unveränderliche Image- und JAR-Referenzen bei. Bestätigen Sie vor dem Plan die Verfügbarkeit der SKE-Version, Node-Pool-Kapazität, Projektberechtigungen und DNS-Delegation.

Aus der STACKIT-DokuLifecycle of Kubernetes Engine › Kubernetes end-of-life datesStand der Quelle 24.08.2026 · übernommen 05.10.2026

Starting with Kubernetes v1.33, we remove minor versions on the patch day that precedes the upstream maintenance end-of-life (EOL) date. The following table below lists the upstream EOL date for each Kubernetes minor version and the corresponding expiration date in SKE:

Seitlich wischen, um die ganze Tabelle zu sehen

Kubernetes minor version	End-of-life date	Expiration in SKE
v1.32	2026-02-28	2026-04-15
v1.33	2026-06-28	2026-06-10
v1.34	2026-10-27	2026-10-14
v1.35	2027-02-28	2027-02-10

Please refer to the official Kubernetes Release History for up-to-date announcements of new versions.

Was ist das?

Dieser Abschnitt wird mehrmals am Tag automatisch aus der STACKIT-Doku übernommen. Hier lässt er sich nicht ändern. Änderungen gehören in die STACKIT-Doku.

Bevorzugen Sie ein freigegebenes Application-Landing-Zone-Projekt. Setzen Sie create_project = false und geben Sie Projekt-ID und Pfad zum Service-Account-Schlüssel an. Die alternative Projekterstellung setzt einen freigegebenen übergeordneten Container und Berechtigungen voraus; sie ersetzt keine Landing-Zone-Governance. Zugangsdaten, State, gespeicherte Pläne und Migrationsnachweise gehören nie in die Versionsverwaltung.

Erstellen Sie für einen neuen Checkout die private Variablendatei, ohne eine vorhandene zu überschreiben:

umask 077
test -e env.tfvars || cp env.tfvars.example env.tfvars
chmod 600 env.tfvars

Bearbeiten Sie diese Datei vor dem Plan: Tragen Sie freigegebenes Projekt und Service-Account-Pfad, Region, unterstützte SKE-Version, verfügbaren Node-Pool-Flavor samt Zone und delegierte DNS-Einstellungen aus dem Repository-Beispiel ein. Prüfen Sie Backend-Zugriff und Sperren, Quotas, Kosten sowie die Grenzen von HTTP und öffentlichen Metriken. Die folgenden Funktionsschalter bilden keine vollständige Umgebungskonfiguration.

Einheitliche Automatisierungs-Flags

Der optionale gemeinsame Wrapper bildet setup_project, setup_observability, setup_database, setup_workload, setup_loadgen und setup_dns auf die Terraform-Schalter des Repositorys ab. Sie wählen ausschließlich den Bereitstellungsumfang: Das Aktivieren der Datenbank erlaubt keinen Datenaustausch und ersetzt niemals die separate Migrationsfreigabe.

Minimale Zielkonfiguration

Diese Werte aktivieren den vollständigen Workload- und Datenbankpfad. Sie ergänzen die Angaben zu Projekt, Region, Node Pool und DNS im Repository-Beispiel, ersetzen sie aber nicht.

deploy_workload                   = true
dns_enabled                       = true
enable_postgres_flex              = true
postgres_flex_target_database     = "springmusic"
postgres_flex_target_app_acl_cidrs = []
observability_enabled             = true
create_observability_instance     = true
create_grafana_dashboard          = true
enable_springboot_hpa              = false
enable_load_generator             = false
deploy_postgres_migration_job      = false

Lassen Sie HPA und Lastgenerierung während der Migration deaktiviert. Wählen Sie Alarmeinstellungen bewusst; die Alarmzustellung wurde im End-to-End-Test nicht validiert. springboot_image wählt die Java-Laufzeit, nicht ein beliebiges vorgefertigtes Anwendungsimage. Der Init-Container lädt das auf einen Commit fixierte Rehost-JAR und prüft vor dem Start seinen SHA-256-Wert. Spiegeln Sie unveränderliche Artefakte für die Produktion in freigegebene Artefakt- und Image-Dienste.

Führen Sie die Befehle im Replatform-Repository aus und prüfen Sie den gespeicherten Plan vor dem Apply:

umask 077
terraform init
terraform validate
terraform plan -var-file=env.tfvars -out=tfplan
terraform apply tfplan
bash scripts/validate_gateway.sh

Zugriffskontrolle und temporäre ACL-Erweiterung für Migration

Bei leeren Anwendungs-ACL-Eingaben verwendet Terraform die tatsächlichen Egress-CIDRs des SKE-Clusters für PostgreSQL Flex. Explizite Anwendungs- oder ältere ACL-Werte überschreiben diesen Standard und müssen geprüft werden. Erlauben Sie nicht 0.0.0.0/0.

Der temporäre PostgreSQL-Client läuft in SKE und erhält den Dump über kubectl. Er verbindet sich nicht direkt mit der Quell-VM; weder Quell- noch Arbeitsplatz-CIDRs benötigen temporären Flex-Zugriff. JDBC und Datenbankwerkzeuge verwenden sslmode=require: Das erzwingt Verschlüsselung, bietet aber nicht die Hostnamenprüfung von verify-full. Schützen Sie Zugangsdaten in Kubernetes Secrets und im Terraform-Backend und validieren Sie bei Bedarf eine stärkere Zertifikatsprüfung.

Migration proben

Stellen Sie den finalen Dump in der isolierten Probedatenbank wieder her und verlangen Sie passende Nachweise, die jünger als 24 Stunden sind.

Führen Sie nach dem Infrastruktur-Apply einen isolierten Restore in springmusic_rehearsal aus. Passen Sie das Quellverzeichnis an die freigegebenen Artefakte an und halten Sie den Nachweispfad privat.

python3 scripts/migrate_postgres.py rehearse \
  --artifacts ../stackit-cmf-Rehost-springboot/artifacts \
  --evidence .tmp/migration-run

Die Probe validiert Manifest, Dump-Prüfsumme, Zielidentität, Zeilenanzahl und Fingerprint, ohne die Anwendungsdatenbank zu ersetzen. Proben Sie nach dem Schreibstopp auf der Quelle erneut mit dem finalen Dump. Der Cutover verlangt passende Nachweise, die jünger als 24 Stunden sind. Eine erfolgreiche Probe mit einem älteren oder anderen Dump gibt die finale Eingabe nicht frei.

Option: VM-PostgreSQL nach PostgreSQL Flex migrieren

Der alte Pfad deploy_postgres_migration_job = true wird durch die Validierung gesperrt. Nutzen Sie stattdessen den freigabegesteuerten Workflow. Stoppen Sie HPA, Lastgenerierung und alle anderen Zielschreiber. Pausieren Sie Terraform- und GitOps-Reconciliation, solange das Skript die Replikazahl steuert. Seine lokale Sperre schützt nur einen Checkout, nicht vor gleichzeitigen Bedienern auf unterschiedlichen Rechnern.

python3 scripts/migrate_postgres.py cutover \
  --artifacts ../stackit-cmf-Rehost-springboot/artifacts \
  --evidence .tmp/migration-run \
  --source-write-frozen --confirm-target springmusic

Das Quellschreibstopp-Flag ist eine Bestätigung des Betreibers, keine automatische Abschaltung der Quelle. Der Cutover skaliert die Anwendung auf null, sichert das Ziel vor dem Cutover und prüft die Sicherung per Prüfsumme. Er weist ihre Wiederherstellbarkeit in der Probedatenbank nach und stellt erst dann die Quelle transaktional wieder her. Vor dem Wiederanlauf mit ursprünglicher Replikazahl werden die Daten geprüft. Bei Fehlern bleibt die Anwendung zur Untersuchung gestoppt. Bewahren Sie Nachweisjournal und Backup auf; überschreiben Sie sie nicht für einen erneuten Versuch.

Validieren und zurückrollen

Vergleichen Sie Datenbanknachweise mit dem Quellmanifest, prüfen Sie das Anwendungsverhalten über das Gateway und bestätigen Sie den Zustand beider Metrik-Jobs. Traffic-Umschaltung und fachliche Abnahme bleiben Betreiberaufgaben; das Skript ändert den Endpunkt der Quellanwendung nicht.

So stellen Sie die geschützte Zieldatenbank aus der Zeit vor dem Cutover wieder her:

python3 scripts/migrate_postgres.py rollback \
  --evidence .tmp/migration-run --confirm-target springmusic

Der Rollback prüft Zielidentität und Backup-Integrität, sichert das aktuelle Ziel separat, stellt die ursprünglichen Daten wieder her und verifiziert vor dem Wiederanlauf deren Fingerprint. Schreibzugriffe nach dem Cutover werden nicht zusammengeführt; bewahren Sie den Dump vor dem Rollback für einen expliziten Abgleich auf. Dies ist ein Zieldatenbank-Rollback, kein automatischer Failback zur Quell-VM.

Datenbank-Metriken in Observability sichtbar machen

Terraform verwaltet den Grafana-Ordner SCF Replatform und das Dashboard mit acht Panels an der vorhandenen Datenquelle Thanos. Öffnen Sie es über grafana_dashboard_url. Cluster-CPU, Cluster-Speicher, laufende Pods, Anwendungsanfragen sowie PostgreSQL-Zustand und -Auslastung unterstützen Abnahme und spätere Optimierung. Ein manueller Dashboard-Import ist nicht nötig.

Anwendungsmetriken stammen aus dem pod-lokalen Boot-2-Actuator über den Metrikadapter auf Port 9090; der PostgreSQL-Exporter nutzt Port 9187. Prüfen Sie beide tatsächlichen Scrape-Ergebnisse, nicht nur die Dashboard-Darstellung. Fehlende Telemetrie ist ein Untersuchungsgrund, niemals der Nachweis fehlender Last.

Validierung mit kubectl

Exportieren Sie eine kurzlebige Kubeconfig mit privaten Berechtigungen und prüfen Sie den Standard-Namespace der Referenz:

umask 077
mkdir -p .tmp
terraform output -raw kubeconfig > .tmp/replatform.kubeconfig
export KUBECONFIG="$PWD/.tmp/replatform.kubeconfig"
kubectl get deploy,svc,pods -n springboot
kubectl get gateway,httproute -n springboot
kubectl rollout status deployment/springboot -n springboot
bash scripts/validate_gateway.sh

Der Gateway-Validator prüft Akzeptanz, aufgelöste Routenreferenzen, DNS und Anwendungsantwort. Entfernen Sie die lokale Kubeconfig nach Gebrauch und beziehen Sie nach Ablauf eine neue. Ein erfolgreicher Rollout allein ist keine Daten- oder fachliche Abnahme.

Grenze zwischen Backup und Recovery

Trennen Sie Migrations-Rollback von Flex-Service-Recovery und bewahren Sie geschützte Nachweise außerhalb kurzlebiger Ausführungsumgebungen auf.

Die Flex-Aufbewahrung wird explizit konfiguriert; der Standard dieser Referenz beträgt 32 Tage. Managed-Datenbankbackups und der Migrationsdump vor dem Cutover dienen unterschiedlichen Zwecken. Die Probe mit Letzterem weist weder Managed-Service-Restore noch Point-in-Time-Recovery oder Disaster Recovery der Anwendung nach. Benennen Sie Recovery-Verantwortliche und testen Sie den benötigten Service-Recovery-Pfad separat.

Bewahren Sie geschützte Nachweise und Backups bis zum Ende des Rollback-Fensters außerhalb eines kurzlebigen Dev Containers auf. Prüfen Sie nach einem abgebrochenen Migrationsprozess verbliebene Pods mit Präfix springmusic-migration-*, bevor Sie fortfahren; starten Sie ein ungeprüftes Ziel nicht durch Terraform neu.

Was dieses Asset zeigt

Dieses Asset zeigt, wie das Anwendungsverhalten beim Wechsel der Betriebsmodelle für Laufzeit und Datenbank erhalten bleibt:

Plattformwechsel: Dasselbe Spring-Boot-JAR auf SKE betreiben, über TLS mit PostgreSQL Flex verbinden und über Gateway API und DNS erreichbar machen.
Kontrollierte Datenmigration: Quelldump und Manifest qualifizieren, einen isolierten Restore proben und vor dem Cutover eine explizite Freigabe sowie ein verifiziertes Zielbackup verlangen. Bei erforderlichem Rollback den Zielzustand vor dem Cutover wiederherstellen.
Unabhängige Validierung: Datenintegrität, Anwendungsantworten, Gateway- und DNS-Bereitschaft sowie tatsächliche Scrape-Ergebnisse prüfen. Den Terraform-Plan auf unerklärte Drift prüfen, statt erfolgreiche Bereitstellung als Migrationsabnahme zu behandeln.
Wiederholbare Observability: Observability-Integration und Grafana-Dashboard mit acht Panels durch Terraform verwalten. Anwendungs- und Datenbanksignale für Abnahme, Stabilisierung und spätere Optimierung nutzen.

Nicht abgedeckt

Diese Nachweise bestätigen weder einen vollständigen Greenfield-Durchlauf noch eine Migration aus einer produktiven Live-Quelle, unterbrechungsfreien Betrieb, Hochverfügbarkeit, öffentliches Gateway-TLS, interaktiven IDP-Login, Alarmzustellung oder Managed-Flex-Recovery. Der getestete Ein-Worker-Aufbau mit HTTP stellt Metriken ohne Authentifizierung bereit; erfüllen Sie die Produktionsanforderungen vor der Verwendung sensibler Daten. Aktualisieren Sie die Beispielanwendung und validieren Sie eine geeignete unterstützte Kubernetes-Version als separate kontrollierte Änderungen.

Code & Registry github.com Referenzkonfiguration, Skripte und Validierungsnachweise Das Repository-README und die versionierte Implementierung liefern genaue Voraussetzungen, Variablen, Befehle und Recovery-Grenzen. Repository öffnen

STEP

kubectl einrichten und Ziel validieren

Migration design-and-mobilize use-cases runnable-example replatform kubernetes terraform ske spring-boot postgresql

Spring Boot mit Terraform von der VM auf Kubernetes umstellen

STACKIT

Dasselbe Spring-Boot-JAR auf STACKIT Kubernetes betreiben: mit PostgreSQL Flex, Gateway API, DNS, Managed Telemetry sowie geprobtem Daten-Cutover und Rollback.

Code & Registry github.com STACKIT Spring Boot Kubernetes Replatform Repository Terraform, Gateway API, PostgreSQL-Migration und Observability der in diesem Asset verwendeten Implementierung öffnen. Repository öffnen

STACKIT

Der souveräne europäische Cloud-Anbieter hinter dem Framework, mit IaaS und PaaS aus deutschen und österreichischen Rechenzentren und voller Unabhängigkeit.

Überblick

Dieses Asset wendet das Migration Framework auf ein Replatform von Spring Boot und PostgreSQL an: Die Anwendung wechselt vom VM-Service zu STACKIT Kubernetes Engine (SKE), die Datenbank von selbstverwaltetem PostgreSQL zu STACKIT PostgreSQL Flex. Geschäftsfunktion und Anwendungs-JAR bleiben unverändert; die Betriebsmodelle für Laufzeit und Datenbank ändern sich.

Referenzimplementierung

Das Referenzrepository ist die maßgebliche Quelle für Terraform, Helm-Charts, fest versionierte Artefakte, Migrationsskripte und Validierung. Verwenden Sie einen geprüften Stand mit den hier beschriebenen Gateway-API- und scripts/migrate_postgres.py-Workflows. Ein älterer Stand mit direktem Datenbank-Import-Job implementiert dieses Verfahren nicht.

Replatform-Scope in diesem Asset

Laufzeit: Dasselbe Spring-Music-JAR mit Spring Boot 2.4.0 läuft auf Java 11 in einem Kubernetes-Deployment statt unter systemd.
Daten: PostgreSQL Flex stellt getrennte Anwendungs- und Probedatenbanken bereit; JDBC- und Migrationsclients benötigen TLS.
Netzwerkverkehr: Envoy Gateway, Gateway API HTTPRoutes und SKE-verwaltetes ExternalDNS ersetzen den VM-Endpunkt.
Betrieb: Kubernetes-Zustands- und Ressourcenkontrollen ersetzen das Host-Service-Management; Managed Telemetry erfasst Cluster-, Anwendungs- und Datenbanksignale.
Migration: Quellnachweise, isolierte Probe, explizit freigegebener Cutover und verifizierter Datenbank-Rollback bleiben von der Infrastrukturbereitstellung getrennt.

Cloud Foundry, Object Storage, die Zerlegung in Microservices und Anwendungsmodernisierung sind nicht Teil dieser Implementierung. Die alte Beispielanwendung demonstriert einen Plattformwechsel; sie ist keine Empfehlung, einen nicht mehr unterstützten Anwendungsstack produktiv einzusetzen.

Architekturdiagramm der Referenz

Prüfen Sie das Architektur-Asset vor der Wahl von Kapazität und Netzwerkkontrollen. Es trennt die implementierte Topologie von Produktionserweiterungen wie öffentlichem HTTPS, hochverfügbaren Workern und geschützten Metriken.

Cloud Framework Spring Boot auf SKE mit PostgreSQL Flex und Gateway API Implementierte Topologie, Laufzeit- und Datengrenzen sowie separat zu qualifizierende Produktionserweiterungen prüfen. Seite öffnen

End-to-End-Ablauf

Replatform-Eignung, Quellkompatibilität, Landing-Zone-Bereitschaft und Verantwortlichkeiten bestätigen.
Einen vertrauenswürdigen PostgreSQL-Dump und ein Integritätsmanifest unabhängig vom Ziel vorbereiten.
Terraform für SKE, PostgreSQL Flex, Gateway, DNS, Workload und Observability prüfen und anwenden.
Das Ziel validieren und den finalen Quelldump in der isolierten Probedatenbank testen.
Quellschreibzugriffe einfrieren, Ausfallzeit freigeben und den kontrollierten Cutover mit geschütztem Zielbackup ausführen.
Anwendungs- und Datennachweise abnehmen oder den Zielzustand vor dem Cutover wiederherstellen; den Client-Traffic nach dem freigegebenen Betreiberverfahren umschalten.
Nachweise während der Stabilisierung aufbewahren und repräsentative Telemetrie für spätere Optimierung nutzen.

Arbeitsumgebung für den Walkthrough vorbereiten

Verwenden Sie eine isolierte Linux-Laborumgebung mit Git, Terraform, kubectl, curl, jq, getent, Python ab Version 3.11 sowie PostgreSQL-Server- und Client-Werkzeugen. Die Rehost-Beispielskripte benötigen außerdem runuser, sha256sum, ein Betriebssystemkonto postgres und Root-Rechte, um eine temporäre lokale Datenbank zu erstellen und zu prüfen. Führen Sie die Beispielbefehle in dieser vorbereiteten Laborumgebung aus, nicht auf einem produktiven Datenbankhost. Die privaten Artefakte müssen für den Migrationsbediener lesbar bleiben; machen Sie sie nicht für alle Benutzer lesbar.

Beziehen Sie geprüfte Commit-IDs beider Repositorys vom Referenz-Maintainer und exportieren Sie diese vorab als REHOST_REVISION und REPLATFORM_REVISION. Der Replatform-Stand muss Gateway API und den freigabegesteuerten Migrationsworkflow enthalten. Setzen Sie nicht voraus, dass der Remote-Standardbranch bereits die lokal getestete Implementierung enthält. Ist der freigegebene Stand nicht verfügbar, beschaffen Sie ihn vor dem Walkthrough.

Ersetzen Sie beide Platzhalter durch die freigegebenen vollständigen Commit-IDs mit jeweils 40 Zeichen und setzen Sie diese im selben Bash-Terminal:

export REHOST_REVISION="REPLACE_WITH_REVIEWED_REHOST_COMMIT_ID"
export REPLATFORM_REVISION="REPLACE_WITH_REVIEWED_REPLATFORM_COMMIT_ID"

Führen Sie den folgenden Block vollständig aus einem leeren Arbeitsverzeichnis aus. Die if-Prüfung lehnt fehlende, leere oder falsch formatierte IDs einschließlich unveränderter Platzhalter ab. Jedes && führt den nächsten Befehl nur nach Erfolg des vorherigen aus. Git prüft die Verfügbarkeit der Commits; die Formatprüfung allein bestätigt weder Freigabe noch Repository-Inhalt.

if [[ ! ${REHOST_REVISION:-} =~ ^[0-9a-fA-F]{40}$ ||
      ! ${REPLATFORM_REVISION:-} =~ ^[0-9a-fA-F]{40}$ ]]; then
  printf '%s\n' "Set both revision variables to reviewed full 40-character commit IDs." >&2
  false
else
  umask 077 &&
    git clone https://github.com/stackitcloud/stackit-cmf-Rehost-springboot.git &&
    git clone https://github.com/stackitcloud/stackit-cmf-replatform-springboot-k8s.git &&
    git -C stackit-cmf-Rehost-springboot checkout --detach "$REHOST_REVISION" &&
    git -C stackit-cmf-replatform-springboot-k8s checkout --detach "$REPLATFORM_REVISION" &&
    test -f stackit-cmf-replatform-springboot-k8s/scripts/migrate_postgres.py &&
    test -f stackit-cmf-replatform-springboot-k8s/scripts/validate_gateway.sh &&
    cd stackit-cmf-replatform-springboot-k8s &&
    printf '%s\n' "Workspace ready. Continue from this Replatform checkout." || {
      printf '%s\n' "Preparation failed. Resolve the error before continuing." >&2
      false
    }
fi

Fahren Sie erst nach der Meldung Workspace ready fort. Bei Fehlern bleibt das Terminal offen; weitere Vorbereitungsbefehle werden übersprungen. Vorhandene oder teilweise geklonte Verzeichnisse werden weder entfernt noch überschrieben: Prüfen Sie diese und bewahren Sie lokale Änderungen, bevor Sie es in einem neuen leeren Arbeitsverzeichnis erneut versuchen. Nach Erfolg befindet sich das Terminal für die nächsten Schritte im Replatform-Checkout.

Nutzen Sie ein freigegebenes STACKIT Projekt, einen Service Account, DNS-Delegation, SKE-Kapazität und ein geschütztes Terraform-Backend. Beziehen Sie Zugangsdaten über den freigegebenen Secret-Kanal, niemals aus diesem Trail. Die folgenden Befehle setzen diese Verzeichnisstruktur und eine geprüfte Konfiguration voraus; sie belegen keinen validierten Greenfield-Produktionsaufbau.

Quellnachweise vorbereiten

Qualifizieren Sie einen konsistenten Quelldump und sein Manifest, bevor Daten in den Migrationsworkflow eingehen.

Die Rehost-Referenz liefert scripts/create_source_dump.sh und scripts/validate_source_dump.sh für ihr reproduzierbares Beispiel. Führen Sie diese im Rehost-Repository aus. Dessen Verzeichnis artifacts liefert source-postgresql.dump und source-postgresql.manifest an den Replatform-Workflow. Das Manifest erfasst Version 1, table=public.album, row_count, album_fingerprint und dump_sha256.

Führen Sie ausschließlich für das reproduzierbare Beispiel die folgenden Befehle vom Replatform-Checkout in der vorbereiteten Laborumgebung aus. Die Skripte erstellen aus dem versionierten Beispiel-SQL eine temporäre PostgreSQL-Instanz, exportieren sie und führen einen unabhängigen Test-Restore aus. Verwenden Sie ein frisches Artefaktverzeichnis; überschreiben Sie keine Nachweise einer bereits laufenden Migration.

umask 077
pushd ../stackit-cmf-Rehost-springboot
bash scripts/create_source_dump.sh
bash scripts/validate_source_dump.sh
popd

Erwartet wird eine erfolgreiche Validierung von acht Zeilen mit passendem Fingerprint. Diese Befehle lesen keine Quell-VM aus. Verwenden Sie für Probe und Cutover genau diese Artefakte weiter.

Ersetzen Sie für eine reale Quelle den Beispielgenerator durch ein freigegebenes Exportverfahren: Frieren Sie alle Schreibzugriffe ein und leiten Sie Dump im Custom-Format und Manifest aus demselben konsistenten Quellsnapshot ab. Das generierte Beispiel mit acht Alben ist kein Export einer beliebigen laufenden VM. Prüfen Sie vor dem Export PostgreSQL-Kompatibilität, Erweiterungen, Eigentümerschaft und Schemaabhängigkeiten.

Stellen Sie nur vertrauenswürdige Dumps wieder her, da sie SQL ausführen. Diese Implementierung migriert das Anwendungsschema public und prüft public.album; von Flex verwaltete Schemas sind bewusst ausgeschlossen. Andere Workloads benötigen eigene Invarianten und einen angepassten Schemaumfang.

Code & Registry github.com Spring-Boot-Rehost-Quelle und Beispielexport Das Rehost-Repository liefert dasselbe Anwendungsartefakt und reproduzierbare Werkzeuge für PostgreSQL-Quellnachweise. Repository öffnen

Ziel bereitstellen

Stellen Sie das Ziel aus einem geprüften Plan mit expliziten Angaben zu Projekt, Kapazität, Zugriff und DNS bereit.

Verwenden Sie Terraform, kubectl, curl, jq, getent und Python ab Version 3.11 unter Linux. Kopieren Sie env.tfvars.example nach env.tfvars und passen Sie die tatsächlichen Variablen dieser Datei an. Behalten Sie die getestete Provider-Lockdatei und unveränderliche Image- und JAR-Referenzen bei. Bestätigen Sie vor dem Plan die Verfügbarkeit der SKE-Version, Node-Pool-Kapazität, Projektberechtigungen und DNS-Delegation.

Aus der STACKIT-DokuLifecycle of Kubernetes Engine › Kubernetes end-of-life datesStand der Quelle 24.08.2026 · übernommen 05.10.2026

Starting with Kubernetes v1.33, we remove minor versions on the patch day that precedes the upstream maintenance end-of-life (EOL) date. The following table below lists the upstream EOL date for each Kubernetes minor version and the corresponding expiration date in SKE:

Seitlich wischen, um die ganze Tabelle zu sehen

Kubernetes minor version	End-of-life date	Expiration in SKE
v1.32	2026-02-28	2026-04-15
v1.33	2026-06-28	2026-06-10
v1.34	2026-10-27	2026-10-14
v1.35	2027-02-28	2027-02-10

Please refer to the official Kubernetes Release History for up-to-date announcements of new versions.

Was ist das?

Dieser Abschnitt wird mehrmals am Tag automatisch aus der STACKIT-Doku übernommen. Hier lässt er sich nicht ändern. Änderungen gehören in die STACKIT-Doku.

Bevorzugen Sie ein freigegebenes Application-Landing-Zone-Projekt. Setzen Sie create_project = false und geben Sie Projekt-ID und Pfad zum Service-Account-Schlüssel an. Die alternative Projekterstellung setzt einen freigegebenen übergeordneten Container und Berechtigungen voraus; sie ersetzt keine Landing-Zone-Governance. Zugangsdaten, State, gespeicherte Pläne und Migrationsnachweise gehören nie in die Versionsverwaltung.

Erstellen Sie für einen neuen Checkout die private Variablendatei, ohne eine vorhandene zu überschreiben:

umask 077
test -e env.tfvars || cp env.tfvars.example env.tfvars
chmod 600 env.tfvars

Bearbeiten Sie diese Datei vor dem Plan: Tragen Sie freigegebenes Projekt und Service-Account-Pfad, Region, unterstützte SKE-Version, verfügbaren Node-Pool-Flavor samt Zone und delegierte DNS-Einstellungen aus dem Repository-Beispiel ein. Prüfen Sie Backend-Zugriff und Sperren, Quotas, Kosten sowie die Grenzen von HTTP und öffentlichen Metriken. Die folgenden Funktionsschalter bilden keine vollständige Umgebungskonfiguration.

Einheitliche Automatisierungs-Flags

Der optionale gemeinsame Wrapper bildet setup_project, setup_observability, setup_database, setup_workload, setup_loadgen und setup_dns auf die Terraform-Schalter des Repositorys ab. Sie wählen ausschließlich den Bereitstellungsumfang: Das Aktivieren der Datenbank erlaubt keinen Datenaustausch und ersetzt niemals die separate Migrationsfreigabe.

Minimale Zielkonfiguration

Diese Werte aktivieren den vollständigen Workload- und Datenbankpfad. Sie ergänzen die Angaben zu Projekt, Region, Node Pool und DNS im Repository-Beispiel, ersetzen sie aber nicht.

deploy_workload                   = true
dns_enabled                       = true
enable_postgres_flex              = true
postgres_flex_target_database     = "springmusic"
postgres_flex_target_app_acl_cidrs = []
observability_enabled             = true
create_observability_instance     = true
create_grafana_dashboard          = true
enable_springboot_hpa              = false
enable_load_generator             = false
deploy_postgres_migration_job      = false

Lassen Sie HPA und Lastgenerierung während der Migration deaktiviert. Wählen Sie Alarmeinstellungen bewusst; die Alarmzustellung wurde im End-to-End-Test nicht validiert. springboot_image wählt die Java-Laufzeit, nicht ein beliebiges vorgefertigtes Anwendungsimage. Der Init-Container lädt das auf einen Commit fixierte Rehost-JAR und prüft vor dem Start seinen SHA-256-Wert. Spiegeln Sie unveränderliche Artefakte für die Produktion in freigegebene Artefakt- und Image-Dienste.

Führen Sie die Befehle im Replatform-Repository aus und prüfen Sie den gespeicherten Plan vor dem Apply:

umask 077
terraform init
terraform validate
terraform plan -var-file=env.tfvars -out=tfplan
terraform apply tfplan
bash scripts/validate_gateway.sh

Zugriffskontrolle und temporäre ACL-Erweiterung für Migration

Bei leeren Anwendungs-ACL-Eingaben verwendet Terraform die tatsächlichen Egress-CIDRs des SKE-Clusters für PostgreSQL Flex. Explizite Anwendungs- oder ältere ACL-Werte überschreiben diesen Standard und müssen geprüft werden. Erlauben Sie nicht 0.0.0.0/0.

Der temporäre PostgreSQL-Client läuft in SKE und erhält den Dump über kubectl. Er verbindet sich nicht direkt mit der Quell-VM; weder Quell- noch Arbeitsplatz-CIDRs benötigen temporären Flex-Zugriff. JDBC und Datenbankwerkzeuge verwenden sslmode=require: Das erzwingt Verschlüsselung, bietet aber nicht die Hostnamenprüfung von verify-full. Schützen Sie Zugangsdaten in Kubernetes Secrets und im Terraform-Backend und validieren Sie bei Bedarf eine stärkere Zertifikatsprüfung.

Migration proben

Stellen Sie den finalen Dump in der isolierten Probedatenbank wieder her und verlangen Sie passende Nachweise, die jünger als 24 Stunden sind.

Führen Sie nach dem Infrastruktur-Apply einen isolierten Restore in springmusic_rehearsal aus. Passen Sie das Quellverzeichnis an die freigegebenen Artefakte an und halten Sie den Nachweispfad privat.

python3 scripts/migrate_postgres.py rehearse \
  --artifacts ../stackit-cmf-Rehost-springboot/artifacts \
  --evidence .tmp/migration-run

Die Probe validiert Manifest, Dump-Prüfsumme, Zielidentität, Zeilenanzahl und Fingerprint, ohne die Anwendungsdatenbank zu ersetzen. Proben Sie nach dem Schreibstopp auf der Quelle erneut mit dem finalen Dump. Der Cutover verlangt passende Nachweise, die jünger als 24 Stunden sind. Eine erfolgreiche Probe mit einem älteren oder anderen Dump gibt die finale Eingabe nicht frei.

Option: VM-PostgreSQL nach PostgreSQL Flex migrieren

Der alte Pfad deploy_postgres_migration_job = true wird durch die Validierung gesperrt. Nutzen Sie stattdessen den freigabegesteuerten Workflow. Stoppen Sie HPA, Lastgenerierung und alle anderen Zielschreiber. Pausieren Sie Terraform- und GitOps-Reconciliation, solange das Skript die Replikazahl steuert. Seine lokale Sperre schützt nur einen Checkout, nicht vor gleichzeitigen Bedienern auf unterschiedlichen Rechnern.

python3 scripts/migrate_postgres.py cutover \
  --artifacts ../stackit-cmf-Rehost-springboot/artifacts \
  --evidence .tmp/migration-run \
  --source-write-frozen --confirm-target springmusic

Das Quellschreibstopp-Flag ist eine Bestätigung des Betreibers, keine automatische Abschaltung der Quelle. Der Cutover skaliert die Anwendung auf null, sichert das Ziel vor dem Cutover und prüft die Sicherung per Prüfsumme. Er weist ihre Wiederherstellbarkeit in der Probedatenbank nach und stellt erst dann die Quelle transaktional wieder her. Vor dem Wiederanlauf mit ursprünglicher Replikazahl werden die Daten geprüft. Bei Fehlern bleibt die Anwendung zur Untersuchung gestoppt. Bewahren Sie Nachweisjournal und Backup auf; überschreiben Sie sie nicht für einen erneuten Versuch.

Validieren und zurückrollen

Vergleichen Sie Datenbanknachweise mit dem Quellmanifest, prüfen Sie das Anwendungsverhalten über das Gateway und bestätigen Sie den Zustand beider Metrik-Jobs. Traffic-Umschaltung und fachliche Abnahme bleiben Betreiberaufgaben; das Skript ändert den Endpunkt der Quellanwendung nicht.

So stellen Sie die geschützte Zieldatenbank aus der Zeit vor dem Cutover wieder her:

python3 scripts/migrate_postgres.py rollback \
  --evidence .tmp/migration-run --confirm-target springmusic

Der Rollback prüft Zielidentität und Backup-Integrität, sichert das aktuelle Ziel separat, stellt die ursprünglichen Daten wieder her und verifiziert vor dem Wiederanlauf deren Fingerprint. Schreibzugriffe nach dem Cutover werden nicht zusammengeführt; bewahren Sie den Dump vor dem Rollback für einen expliziten Abgleich auf. Dies ist ein Zieldatenbank-Rollback, kein automatischer Failback zur Quell-VM.

Datenbank-Metriken in Observability sichtbar machen

Terraform verwaltet den Grafana-Ordner SCF Replatform und das Dashboard mit acht Panels an der vorhandenen Datenquelle Thanos. Öffnen Sie es über grafana_dashboard_url. Cluster-CPU, Cluster-Speicher, laufende Pods, Anwendungsanfragen sowie PostgreSQL-Zustand und -Auslastung unterstützen Abnahme und spätere Optimierung. Ein manueller Dashboard-Import ist nicht nötig.

Anwendungsmetriken stammen aus dem pod-lokalen Boot-2-Actuator über den Metrikadapter auf Port 9090; der PostgreSQL-Exporter nutzt Port 9187. Prüfen Sie beide tatsächlichen Scrape-Ergebnisse, nicht nur die Dashboard-Darstellung. Fehlende Telemetrie ist ein Untersuchungsgrund, niemals der Nachweis fehlender Last.

Validierung mit kubectl

Exportieren Sie eine kurzlebige Kubeconfig mit privaten Berechtigungen und prüfen Sie den Standard-Namespace der Referenz:

umask 077
mkdir -p .tmp
terraform output -raw kubeconfig > .tmp/replatform.kubeconfig
export KUBECONFIG="$PWD/.tmp/replatform.kubeconfig"
kubectl get deploy,svc,pods -n springboot
kubectl get gateway,httproute -n springboot
kubectl rollout status deployment/springboot -n springboot
bash scripts/validate_gateway.sh

Der Gateway-Validator prüft Akzeptanz, aufgelöste Routenreferenzen, DNS und Anwendungsantwort. Entfernen Sie die lokale Kubeconfig nach Gebrauch und beziehen Sie nach Ablauf eine neue. Ein erfolgreicher Rollout allein ist keine Daten- oder fachliche Abnahme.

Grenze zwischen Backup und Recovery

Trennen Sie Migrations-Rollback von Flex-Service-Recovery und bewahren Sie geschützte Nachweise außerhalb kurzlebiger Ausführungsumgebungen auf.

Die Flex-Aufbewahrung wird explizit konfiguriert; der Standard dieser Referenz beträgt 32 Tage. Managed-Datenbankbackups und der Migrationsdump vor dem Cutover dienen unterschiedlichen Zwecken. Die Probe mit Letzterem weist weder Managed-Service-Restore noch Point-in-Time-Recovery oder Disaster Recovery der Anwendung nach. Benennen Sie Recovery-Verantwortliche und testen Sie den benötigten Service-Recovery-Pfad separat.

Bewahren Sie geschützte Nachweise und Backups bis zum Ende des Rollback-Fensters außerhalb eines kurzlebigen Dev Containers auf. Prüfen Sie nach einem abgebrochenen Migrationsprozess verbliebene Pods mit Präfix springmusic-migration-*, bevor Sie fortfahren; starten Sie ein ungeprüftes Ziel nicht durch Terraform neu.

Was dieses Asset zeigt

Dieses Asset zeigt, wie das Anwendungsverhalten beim Wechsel der Betriebsmodelle für Laufzeit und Datenbank erhalten bleibt:

Plattformwechsel: Dasselbe Spring-Boot-JAR auf SKE betreiben, über TLS mit PostgreSQL Flex verbinden und über Gateway API und DNS erreichbar machen.
Kontrollierte Datenmigration: Quelldump und Manifest qualifizieren, einen isolierten Restore proben und vor dem Cutover eine explizite Freigabe sowie ein verifiziertes Zielbackup verlangen. Bei erforderlichem Rollback den Zielzustand vor dem Cutover wiederherstellen.
Unabhängige Validierung: Datenintegrität, Anwendungsantworten, Gateway- und DNS-Bereitschaft sowie tatsächliche Scrape-Ergebnisse prüfen. Den Terraform-Plan auf unerklärte Drift prüfen, statt erfolgreiche Bereitstellung als Migrationsabnahme zu behandeln.
Wiederholbare Observability: Observability-Integration und Grafana-Dashboard mit acht Panels durch Terraform verwalten. Anwendungs- und Datenbanksignale für Abnahme, Stabilisierung und spätere Optimierung nutzen.

Nicht abgedeckt

Diese Nachweise bestätigen weder einen vollständigen Greenfield-Durchlauf noch eine Migration aus einer produktiven Live-Quelle, unterbrechungsfreien Betrieb, Hochverfügbarkeit, öffentliches Gateway-TLS, interaktiven IDP-Login, Alarmzustellung oder Managed-Flex-Recovery. Der getestete Ein-Worker-Aufbau mit HTTP stellt Metriken ohne Authentifizierung bereit; erfüllen Sie die Produktionsanforderungen vor der Verwendung sensibler Daten. Aktualisieren Sie die Beispielanwendung und validieren Sie eine geeignete unterstützte Kubernetes-Version als separate kontrollierte Änderungen.

Code & Registry github.com Referenzkonfiguration, Skripte und Validierungsnachweise Das Repository-README und die versionierte Implementierung liefern genaue Voraussetzungen, Variablen, Befehle und Recovery-Grenzen. Repository öffnen

OPS

Telemetriepfad prüfen

Migration design-and-mobilize use-cases runnable-example replatform kubernetes terraform ske spring-boot postgresql

Spring Boot mit Terraform von der VM auf Kubernetes umstellen

STACKIT

Dasselbe Spring-Boot-JAR auf STACKIT Kubernetes betreiben: mit PostgreSQL Flex, Gateway API, DNS, Managed Telemetry sowie geprobtem Daten-Cutover und Rollback.

Code & Registry github.com STACKIT Spring Boot Kubernetes Replatform Repository Terraform, Gateway API, PostgreSQL-Migration und Observability der in diesem Asset verwendeten Implementierung öffnen. Repository öffnen

STACKIT

Der souveräne europäische Cloud-Anbieter hinter dem Framework, mit IaaS und PaaS aus deutschen und österreichischen Rechenzentren und voller Unabhängigkeit.

Überblick

Dieses Asset wendet das Migration Framework auf ein Replatform von Spring Boot und PostgreSQL an: Die Anwendung wechselt vom VM-Service zu STACKIT Kubernetes Engine (SKE), die Datenbank von selbstverwaltetem PostgreSQL zu STACKIT PostgreSQL Flex. Geschäftsfunktion und Anwendungs-JAR bleiben unverändert; die Betriebsmodelle für Laufzeit und Datenbank ändern sich.

Referenzimplementierung

Das Referenzrepository ist die maßgebliche Quelle für Terraform, Helm-Charts, fest versionierte Artefakte, Migrationsskripte und Validierung. Verwenden Sie einen geprüften Stand mit den hier beschriebenen Gateway-API- und scripts/migrate_postgres.py-Workflows. Ein älterer Stand mit direktem Datenbank-Import-Job implementiert dieses Verfahren nicht.

Replatform-Scope in diesem Asset

Laufzeit: Dasselbe Spring-Music-JAR mit Spring Boot 2.4.0 läuft auf Java 11 in einem Kubernetes-Deployment statt unter systemd.
Daten: PostgreSQL Flex stellt getrennte Anwendungs- und Probedatenbanken bereit; JDBC- und Migrationsclients benötigen TLS.
Netzwerkverkehr: Envoy Gateway, Gateway API HTTPRoutes und SKE-verwaltetes ExternalDNS ersetzen den VM-Endpunkt.
Betrieb: Kubernetes-Zustands- und Ressourcenkontrollen ersetzen das Host-Service-Management; Managed Telemetry erfasst Cluster-, Anwendungs- und Datenbanksignale.
Migration: Quellnachweise, isolierte Probe, explizit freigegebener Cutover und verifizierter Datenbank-Rollback bleiben von der Infrastrukturbereitstellung getrennt.

Cloud Foundry, Object Storage, die Zerlegung in Microservices und Anwendungsmodernisierung sind nicht Teil dieser Implementierung. Die alte Beispielanwendung demonstriert einen Plattformwechsel; sie ist keine Empfehlung, einen nicht mehr unterstützten Anwendungsstack produktiv einzusetzen.

Architekturdiagramm der Referenz

Prüfen Sie das Architektur-Asset vor der Wahl von Kapazität und Netzwerkkontrollen. Es trennt die implementierte Topologie von Produktionserweiterungen wie öffentlichem HTTPS, hochverfügbaren Workern und geschützten Metriken.

Cloud Framework Spring Boot auf SKE mit PostgreSQL Flex und Gateway API Implementierte Topologie, Laufzeit- und Datengrenzen sowie separat zu qualifizierende Produktionserweiterungen prüfen. Seite öffnen

End-to-End-Ablauf

Replatform-Eignung, Quellkompatibilität, Landing-Zone-Bereitschaft und Verantwortlichkeiten bestätigen.
Einen vertrauenswürdigen PostgreSQL-Dump und ein Integritätsmanifest unabhängig vom Ziel vorbereiten.
Terraform für SKE, PostgreSQL Flex, Gateway, DNS, Workload und Observability prüfen und anwenden.
Das Ziel validieren und den finalen Quelldump in der isolierten Probedatenbank testen.
Quellschreibzugriffe einfrieren, Ausfallzeit freigeben und den kontrollierten Cutover mit geschütztem Zielbackup ausführen.
Anwendungs- und Datennachweise abnehmen oder den Zielzustand vor dem Cutover wiederherstellen; den Client-Traffic nach dem freigegebenen Betreiberverfahren umschalten.
Nachweise während der Stabilisierung aufbewahren und repräsentative Telemetrie für spätere Optimierung nutzen.

Arbeitsumgebung für den Walkthrough vorbereiten

Verwenden Sie eine isolierte Linux-Laborumgebung mit Git, Terraform, kubectl, curl, jq, getent, Python ab Version 3.11 sowie PostgreSQL-Server- und Client-Werkzeugen. Die Rehost-Beispielskripte benötigen außerdem runuser, sha256sum, ein Betriebssystemkonto postgres und Root-Rechte, um eine temporäre lokale Datenbank zu erstellen und zu prüfen. Führen Sie die Beispielbefehle in dieser vorbereiteten Laborumgebung aus, nicht auf einem produktiven Datenbankhost. Die privaten Artefakte müssen für den Migrationsbediener lesbar bleiben; machen Sie sie nicht für alle Benutzer lesbar.

Beziehen Sie geprüfte Commit-IDs beider Repositorys vom Referenz-Maintainer und exportieren Sie diese vorab als REHOST_REVISION und REPLATFORM_REVISION. Der Replatform-Stand muss Gateway API und den freigabegesteuerten Migrationsworkflow enthalten. Setzen Sie nicht voraus, dass der Remote-Standardbranch bereits die lokal getestete Implementierung enthält. Ist der freigegebene Stand nicht verfügbar, beschaffen Sie ihn vor dem Walkthrough.

Ersetzen Sie beide Platzhalter durch die freigegebenen vollständigen Commit-IDs mit jeweils 40 Zeichen und setzen Sie diese im selben Bash-Terminal:

export REHOST_REVISION="REPLACE_WITH_REVIEWED_REHOST_COMMIT_ID"
export REPLATFORM_REVISION="REPLACE_WITH_REVIEWED_REPLATFORM_COMMIT_ID"

Führen Sie den folgenden Block vollständig aus einem leeren Arbeitsverzeichnis aus. Die if-Prüfung lehnt fehlende, leere oder falsch formatierte IDs einschließlich unveränderter Platzhalter ab. Jedes && führt den nächsten Befehl nur nach Erfolg des vorherigen aus. Git prüft die Verfügbarkeit der Commits; die Formatprüfung allein bestätigt weder Freigabe noch Repository-Inhalt.

if [[ ! ${REHOST_REVISION:-} =~ ^[0-9a-fA-F]{40}$ ||
      ! ${REPLATFORM_REVISION:-} =~ ^[0-9a-fA-F]{40}$ ]]; then
  printf '%s\n' "Set both revision variables to reviewed full 40-character commit IDs." >&2
  false
else
  umask 077 &&
    git clone https://github.com/stackitcloud/stackit-cmf-Rehost-springboot.git &&
    git clone https://github.com/stackitcloud/stackit-cmf-replatform-springboot-k8s.git &&
    git -C stackit-cmf-Rehost-springboot checkout --detach "$REHOST_REVISION" &&
    git -C stackit-cmf-replatform-springboot-k8s checkout --detach "$REPLATFORM_REVISION" &&
    test -f stackit-cmf-replatform-springboot-k8s/scripts/migrate_postgres.py &&
    test -f stackit-cmf-replatform-springboot-k8s/scripts/validate_gateway.sh &&
    cd stackit-cmf-replatform-springboot-k8s &&
    printf '%s\n' "Workspace ready. Continue from this Replatform checkout." || {
      printf '%s\n' "Preparation failed. Resolve the error before continuing." >&2
      false
    }
fi

Fahren Sie erst nach der Meldung Workspace ready fort. Bei Fehlern bleibt das Terminal offen; weitere Vorbereitungsbefehle werden übersprungen. Vorhandene oder teilweise geklonte Verzeichnisse werden weder entfernt noch überschrieben: Prüfen Sie diese und bewahren Sie lokale Änderungen, bevor Sie es in einem neuen leeren Arbeitsverzeichnis erneut versuchen. Nach Erfolg befindet sich das Terminal für die nächsten Schritte im Replatform-Checkout.

Nutzen Sie ein freigegebenes STACKIT Projekt, einen Service Account, DNS-Delegation, SKE-Kapazität und ein geschütztes Terraform-Backend. Beziehen Sie Zugangsdaten über den freigegebenen Secret-Kanal, niemals aus diesem Trail. Die folgenden Befehle setzen diese Verzeichnisstruktur und eine geprüfte Konfiguration voraus; sie belegen keinen validierten Greenfield-Produktionsaufbau.

Quellnachweise vorbereiten

Qualifizieren Sie einen konsistenten Quelldump und sein Manifest, bevor Daten in den Migrationsworkflow eingehen.

Die Rehost-Referenz liefert scripts/create_source_dump.sh und scripts/validate_source_dump.sh für ihr reproduzierbares Beispiel. Führen Sie diese im Rehost-Repository aus. Dessen Verzeichnis artifacts liefert source-postgresql.dump und source-postgresql.manifest an den Replatform-Workflow. Das Manifest erfasst Version 1, table=public.album, row_count, album_fingerprint und dump_sha256.

Führen Sie ausschließlich für das reproduzierbare Beispiel die folgenden Befehle vom Replatform-Checkout in der vorbereiteten Laborumgebung aus. Die Skripte erstellen aus dem versionierten Beispiel-SQL eine temporäre PostgreSQL-Instanz, exportieren sie und führen einen unabhängigen Test-Restore aus. Verwenden Sie ein frisches Artefaktverzeichnis; überschreiben Sie keine Nachweise einer bereits laufenden Migration.

umask 077
pushd ../stackit-cmf-Rehost-springboot
bash scripts/create_source_dump.sh
bash scripts/validate_source_dump.sh
popd

Erwartet wird eine erfolgreiche Validierung von acht Zeilen mit passendem Fingerprint. Diese Befehle lesen keine Quell-VM aus. Verwenden Sie für Probe und Cutover genau diese Artefakte weiter.

Ersetzen Sie für eine reale Quelle den Beispielgenerator durch ein freigegebenes Exportverfahren: Frieren Sie alle Schreibzugriffe ein und leiten Sie Dump im Custom-Format und Manifest aus demselben konsistenten Quellsnapshot ab. Das generierte Beispiel mit acht Alben ist kein Export einer beliebigen laufenden VM. Prüfen Sie vor dem Export PostgreSQL-Kompatibilität, Erweiterungen, Eigentümerschaft und Schemaabhängigkeiten.

Stellen Sie nur vertrauenswürdige Dumps wieder her, da sie SQL ausführen. Diese Implementierung migriert das Anwendungsschema public und prüft public.album; von Flex verwaltete Schemas sind bewusst ausgeschlossen. Andere Workloads benötigen eigene Invarianten und einen angepassten Schemaumfang.

Code & Registry github.com Spring-Boot-Rehost-Quelle und Beispielexport Das Rehost-Repository liefert dasselbe Anwendungsartefakt und reproduzierbare Werkzeuge für PostgreSQL-Quellnachweise. Repository öffnen

Ziel bereitstellen

Stellen Sie das Ziel aus einem geprüften Plan mit expliziten Angaben zu Projekt, Kapazität, Zugriff und DNS bereit.

Verwenden Sie Terraform, kubectl, curl, jq, getent und Python ab Version 3.11 unter Linux. Kopieren Sie env.tfvars.example nach env.tfvars und passen Sie die tatsächlichen Variablen dieser Datei an. Behalten Sie die getestete Provider-Lockdatei und unveränderliche Image- und JAR-Referenzen bei. Bestätigen Sie vor dem Plan die Verfügbarkeit der SKE-Version, Node-Pool-Kapazität, Projektberechtigungen und DNS-Delegation.

Aus der STACKIT-DokuLifecycle of Kubernetes Engine › Kubernetes end-of-life datesStand der Quelle 24.08.2026 · übernommen 05.10.2026

Starting with Kubernetes v1.33, we remove minor versions on the patch day that precedes the upstream maintenance end-of-life (EOL) date. The following table below lists the upstream EOL date for each Kubernetes minor version and the corresponding expiration date in SKE:

Seitlich wischen, um die ganze Tabelle zu sehen

Kubernetes minor version	End-of-life date	Expiration in SKE
v1.32	2026-02-28	2026-04-15
v1.33	2026-06-28	2026-06-10
v1.34	2026-10-27	2026-10-14
v1.35	2027-02-28	2027-02-10

Please refer to the official Kubernetes Release History for up-to-date announcements of new versions.

Was ist das?

Dieser Abschnitt wird mehrmals am Tag automatisch aus der STACKIT-Doku übernommen. Hier lässt er sich nicht ändern. Änderungen gehören in die STACKIT-Doku.

Bevorzugen Sie ein freigegebenes Application-Landing-Zone-Projekt. Setzen Sie create_project = false und geben Sie Projekt-ID und Pfad zum Service-Account-Schlüssel an. Die alternative Projekterstellung setzt einen freigegebenen übergeordneten Container und Berechtigungen voraus; sie ersetzt keine Landing-Zone-Governance. Zugangsdaten, State, gespeicherte Pläne und Migrationsnachweise gehören nie in die Versionsverwaltung.

Erstellen Sie für einen neuen Checkout die private Variablendatei, ohne eine vorhandene zu überschreiben:

umask 077
test -e env.tfvars || cp env.tfvars.example env.tfvars
chmod 600 env.tfvars

Bearbeiten Sie diese Datei vor dem Plan: Tragen Sie freigegebenes Projekt und Service-Account-Pfad, Region, unterstützte SKE-Version, verfügbaren Node-Pool-Flavor samt Zone und delegierte DNS-Einstellungen aus dem Repository-Beispiel ein. Prüfen Sie Backend-Zugriff und Sperren, Quotas, Kosten sowie die Grenzen von HTTP und öffentlichen Metriken. Die folgenden Funktionsschalter bilden keine vollständige Umgebungskonfiguration.

Einheitliche Automatisierungs-Flags

Der optionale gemeinsame Wrapper bildet setup_project, setup_observability, setup_database, setup_workload, setup_loadgen und setup_dns auf die Terraform-Schalter des Repositorys ab. Sie wählen ausschließlich den Bereitstellungsumfang: Das Aktivieren der Datenbank erlaubt keinen Datenaustausch und ersetzt niemals die separate Migrationsfreigabe.

Minimale Zielkonfiguration

Diese Werte aktivieren den vollständigen Workload- und Datenbankpfad. Sie ergänzen die Angaben zu Projekt, Region, Node Pool und DNS im Repository-Beispiel, ersetzen sie aber nicht.

deploy_workload                   = true
dns_enabled                       = true
enable_postgres_flex              = true
postgres_flex_target_database     = "springmusic"
postgres_flex_target_app_acl_cidrs = []
observability_enabled             = true
create_observability_instance     = true
create_grafana_dashboard          = true
enable_springboot_hpa              = false
enable_load_generator             = false
deploy_postgres_migration_job      = false

Lassen Sie HPA und Lastgenerierung während der Migration deaktiviert. Wählen Sie Alarmeinstellungen bewusst; die Alarmzustellung wurde im End-to-End-Test nicht validiert. springboot_image wählt die Java-Laufzeit, nicht ein beliebiges vorgefertigtes Anwendungsimage. Der Init-Container lädt das auf einen Commit fixierte Rehost-JAR und prüft vor dem Start seinen SHA-256-Wert. Spiegeln Sie unveränderliche Artefakte für die Produktion in freigegebene Artefakt- und Image-Dienste.

Führen Sie die Befehle im Replatform-Repository aus und prüfen Sie den gespeicherten Plan vor dem Apply:

umask 077
terraform init
terraform validate
terraform plan -var-file=env.tfvars -out=tfplan
terraform apply tfplan
bash scripts/validate_gateway.sh

Zugriffskontrolle und temporäre ACL-Erweiterung für Migration

Bei leeren Anwendungs-ACL-Eingaben verwendet Terraform die tatsächlichen Egress-CIDRs des SKE-Clusters für PostgreSQL Flex. Explizite Anwendungs- oder ältere ACL-Werte überschreiben diesen Standard und müssen geprüft werden. Erlauben Sie nicht 0.0.0.0/0.

Der temporäre PostgreSQL-Client läuft in SKE und erhält den Dump über kubectl. Er verbindet sich nicht direkt mit der Quell-VM; weder Quell- noch Arbeitsplatz-CIDRs benötigen temporären Flex-Zugriff. JDBC und Datenbankwerkzeuge verwenden sslmode=require: Das erzwingt Verschlüsselung, bietet aber nicht die Hostnamenprüfung von verify-full. Schützen Sie Zugangsdaten in Kubernetes Secrets und im Terraform-Backend und validieren Sie bei Bedarf eine stärkere Zertifikatsprüfung.

Migration proben

Stellen Sie den finalen Dump in der isolierten Probedatenbank wieder her und verlangen Sie passende Nachweise, die jünger als 24 Stunden sind.

Führen Sie nach dem Infrastruktur-Apply einen isolierten Restore in springmusic_rehearsal aus. Passen Sie das Quellverzeichnis an die freigegebenen Artefakte an und halten Sie den Nachweispfad privat.

python3 scripts/migrate_postgres.py rehearse \
  --artifacts ../stackit-cmf-Rehost-springboot/artifacts \
  --evidence .tmp/migration-run

Die Probe validiert Manifest, Dump-Prüfsumme, Zielidentität, Zeilenanzahl und Fingerprint, ohne die Anwendungsdatenbank zu ersetzen. Proben Sie nach dem Schreibstopp auf der Quelle erneut mit dem finalen Dump. Der Cutover verlangt passende Nachweise, die jünger als 24 Stunden sind. Eine erfolgreiche Probe mit einem älteren oder anderen Dump gibt die finale Eingabe nicht frei.

Option: VM-PostgreSQL nach PostgreSQL Flex migrieren

Der alte Pfad deploy_postgres_migration_job = true wird durch die Validierung gesperrt. Nutzen Sie stattdessen den freigabegesteuerten Workflow. Stoppen Sie HPA, Lastgenerierung und alle anderen Zielschreiber. Pausieren Sie Terraform- und GitOps-Reconciliation, solange das Skript die Replikazahl steuert. Seine lokale Sperre schützt nur einen Checkout, nicht vor gleichzeitigen Bedienern auf unterschiedlichen Rechnern.

python3 scripts/migrate_postgres.py cutover \
  --artifacts ../stackit-cmf-Rehost-springboot/artifacts \
  --evidence .tmp/migration-run \
  --source-write-frozen --confirm-target springmusic

Das Quellschreibstopp-Flag ist eine Bestätigung des Betreibers, keine automatische Abschaltung der Quelle. Der Cutover skaliert die Anwendung auf null, sichert das Ziel vor dem Cutover und prüft die Sicherung per Prüfsumme. Er weist ihre Wiederherstellbarkeit in der Probedatenbank nach und stellt erst dann die Quelle transaktional wieder her. Vor dem Wiederanlauf mit ursprünglicher Replikazahl werden die Daten geprüft. Bei Fehlern bleibt die Anwendung zur Untersuchung gestoppt. Bewahren Sie Nachweisjournal und Backup auf; überschreiben Sie sie nicht für einen erneuten Versuch.

Validieren und zurückrollen

Vergleichen Sie Datenbanknachweise mit dem Quellmanifest, prüfen Sie das Anwendungsverhalten über das Gateway und bestätigen Sie den Zustand beider Metrik-Jobs. Traffic-Umschaltung und fachliche Abnahme bleiben Betreiberaufgaben; das Skript ändert den Endpunkt der Quellanwendung nicht.

So stellen Sie die geschützte Zieldatenbank aus der Zeit vor dem Cutover wieder her:

python3 scripts/migrate_postgres.py rollback \
  --evidence .tmp/migration-run --confirm-target springmusic

Der Rollback prüft Zielidentität und Backup-Integrität, sichert das aktuelle Ziel separat, stellt die ursprünglichen Daten wieder her und verifiziert vor dem Wiederanlauf deren Fingerprint. Schreibzugriffe nach dem Cutover werden nicht zusammengeführt; bewahren Sie den Dump vor dem Rollback für einen expliziten Abgleich auf. Dies ist ein Zieldatenbank-Rollback, kein automatischer Failback zur Quell-VM.

Datenbank-Metriken in Observability sichtbar machen

Terraform verwaltet den Grafana-Ordner SCF Replatform und das Dashboard mit acht Panels an der vorhandenen Datenquelle Thanos. Öffnen Sie es über grafana_dashboard_url. Cluster-CPU, Cluster-Speicher, laufende Pods, Anwendungsanfragen sowie PostgreSQL-Zustand und -Auslastung unterstützen Abnahme und spätere Optimierung. Ein manueller Dashboard-Import ist nicht nötig.

Anwendungsmetriken stammen aus dem pod-lokalen Boot-2-Actuator über den Metrikadapter auf Port 9090; der PostgreSQL-Exporter nutzt Port 9187. Prüfen Sie beide tatsächlichen Scrape-Ergebnisse, nicht nur die Dashboard-Darstellung. Fehlende Telemetrie ist ein Untersuchungsgrund, niemals der Nachweis fehlender Last.

Validierung mit kubectl

Exportieren Sie eine kurzlebige Kubeconfig mit privaten Berechtigungen und prüfen Sie den Standard-Namespace der Referenz:

umask 077
mkdir -p .tmp
terraform output -raw kubeconfig > .tmp/replatform.kubeconfig
export KUBECONFIG="$PWD/.tmp/replatform.kubeconfig"
kubectl get deploy,svc,pods -n springboot
kubectl get gateway,httproute -n springboot
kubectl rollout status deployment/springboot -n springboot
bash scripts/validate_gateway.sh

Der Gateway-Validator prüft Akzeptanz, aufgelöste Routenreferenzen, DNS und Anwendungsantwort. Entfernen Sie die lokale Kubeconfig nach Gebrauch und beziehen Sie nach Ablauf eine neue. Ein erfolgreicher Rollout allein ist keine Daten- oder fachliche Abnahme.

Grenze zwischen Backup und Recovery

Trennen Sie Migrations-Rollback von Flex-Service-Recovery und bewahren Sie geschützte Nachweise außerhalb kurzlebiger Ausführungsumgebungen auf.

Die Flex-Aufbewahrung wird explizit konfiguriert; der Standard dieser Referenz beträgt 32 Tage. Managed-Datenbankbackups und der Migrationsdump vor dem Cutover dienen unterschiedlichen Zwecken. Die Probe mit Letzterem weist weder Managed-Service-Restore noch Point-in-Time-Recovery oder Disaster Recovery der Anwendung nach. Benennen Sie Recovery-Verantwortliche und testen Sie den benötigten Service-Recovery-Pfad separat.

Bewahren Sie geschützte Nachweise und Backups bis zum Ende des Rollback-Fensters außerhalb eines kurzlebigen Dev Containers auf. Prüfen Sie nach einem abgebrochenen Migrationsprozess verbliebene Pods mit Präfix springmusic-migration-*, bevor Sie fortfahren; starten Sie ein ungeprüftes Ziel nicht durch Terraform neu.

Was dieses Asset zeigt

Dieses Asset zeigt, wie das Anwendungsverhalten beim Wechsel der Betriebsmodelle für Laufzeit und Datenbank erhalten bleibt:

Plattformwechsel: Dasselbe Spring-Boot-JAR auf SKE betreiben, über TLS mit PostgreSQL Flex verbinden und über Gateway API und DNS erreichbar machen.
Kontrollierte Datenmigration: Quelldump und Manifest qualifizieren, einen isolierten Restore proben und vor dem Cutover eine explizite Freigabe sowie ein verifiziertes Zielbackup verlangen. Bei erforderlichem Rollback den Zielzustand vor dem Cutover wiederherstellen.
Unabhängige Validierung: Datenintegrität, Anwendungsantworten, Gateway- und DNS-Bereitschaft sowie tatsächliche Scrape-Ergebnisse prüfen. Den Terraform-Plan auf unerklärte Drift prüfen, statt erfolgreiche Bereitstellung als Migrationsabnahme zu behandeln.
Wiederholbare Observability: Observability-Integration und Grafana-Dashboard mit acht Panels durch Terraform verwalten. Anwendungs- und Datenbanksignale für Abnahme, Stabilisierung und spätere Optimierung nutzen.

Nicht abgedeckt

Diese Nachweise bestätigen weder einen vollständigen Greenfield-Durchlauf noch eine Migration aus einer produktiven Live-Quelle, unterbrechungsfreien Betrieb, Hochverfügbarkeit, öffentliches Gateway-TLS, interaktiven IDP-Login, Alarmzustellung oder Managed-Flex-Recovery. Der getestete Ein-Worker-Aufbau mit HTTP stellt Metriken ohne Authentifizierung bereit; erfüllen Sie die Produktionsanforderungen vor der Verwendung sensibler Daten. Aktualisieren Sie die Beispielanwendung und validieren Sie eine geeignete unterstützte Kubernetes-Version als separate kontrollierte Änderungen.

Code & Registry github.com Referenzkonfiguration, Skripte und Validierungsnachweise Das Repository-README und die versionierte Implementierung liefern genaue Voraussetzungen, Variablen, Befehle und Recovery-Grenzen. Repository öffnen

STEP

Proben und freigeben

Überblick

Dieses Asset wendet das Migration Framework auf ein Replatform von Spring Boot und PostgreSQL an: Die Anwendung wechselt vom VM-Service zu STACKIT Kubernetes Engine (SKE), die Datenbank von selbstverwaltetem PostgreSQL zu STACKIT PostgreSQL Flex. Geschäftsfunktion und Anwendungs-JAR bleiben unverändert; die Betriebsmodelle für Laufzeit und Datenbank ändern sich.

Referenzimplementierung

Das Referenzrepository ist die maßgebliche Quelle für Terraform, Helm-Charts, fest versionierte Artefakte, Migrationsskripte und Validierung. Verwenden Sie einen geprüften Stand mit den hier beschriebenen Gateway-API- und scripts/migrate_postgres.py-Workflows. Ein älterer Stand mit direktem Datenbank-Import-Job implementiert dieses Verfahren nicht.

Code & Registry github.com STACKIT Spring Boot Kubernetes Replatform Repository Terraform, Gateway API, PostgreSQL-Migration und Observability der in diesem Asset verwendeten Implementierung öffnen. Repository öffnen

Replatform-Scope in diesem Asset

Laufzeit: Dasselbe Spring-Music-JAR mit Spring Boot 2.4.0 läuft auf Java 11 in einem Kubernetes-Deployment statt unter systemd.
Daten: PostgreSQL Flex stellt getrennte Anwendungs- und Probedatenbanken bereit; JDBC- und Migrationsclients benötigen TLS.
Netzwerkverkehr: Envoy Gateway, Gateway API HTTPRoutes und SKE-verwaltetes ExternalDNS ersetzen den VM-Endpunkt.
Betrieb: Kubernetes-Zustands- und Ressourcenkontrollen ersetzen das Host-Service-Management; Managed Telemetry erfasst Cluster-, Anwendungs- und Datenbanksignale.
Migration: Quellnachweise, isolierte Probe, explizit freigegebener Cutover und verifizierter Datenbank-Rollback bleiben von der Infrastrukturbereitstellung getrennt.

Cloud Foundry, Object Storage, die Zerlegung in Microservices und Anwendungsmodernisierung sind nicht Teil dieser Implementierung. Die alte Beispielanwendung demonstriert einen Plattformwechsel; sie ist keine Empfehlung, einen nicht mehr unterstützten Anwendungsstack produktiv einzusetzen.

Architekturdiagramm der Referenz

Prüfen Sie das Architektur-Asset vor der Wahl von Kapazität und Netzwerkkontrollen. Es trennt die implementierte Topologie von Produktionserweiterungen wie öffentlichem HTTPS, hochverfügbaren Workern und geschützten Metriken.

Cloud Framework Spring Boot auf SKE mit PostgreSQL Flex und Gateway API Implementierte Topologie, Laufzeit- und Datengrenzen sowie separat zu qualifizierende Produktionserweiterungen prüfen. Seite öffnen

End-to-End-Ablauf

Replatform-Eignung, Quellkompatibilität, Landing-Zone-Bereitschaft und Verantwortlichkeiten bestätigen.
Einen vertrauenswürdigen PostgreSQL-Dump und ein Integritätsmanifest unabhängig vom Ziel vorbereiten.
Terraform für SKE, PostgreSQL Flex, Gateway, DNS, Workload und Observability prüfen und anwenden.
Das Ziel validieren und den finalen Quelldump in der isolierten Probedatenbank testen.
Quellschreibzugriffe einfrieren, Ausfallzeit freigeben und den kontrollierten Cutover mit geschütztem Zielbackup ausführen.
Anwendungs- und Datennachweise abnehmen oder den Zielzustand vor dem Cutover wiederherstellen; den Client-Traffic nach dem freigegebenen Betreiberverfahren umschalten.
Nachweise während der Stabilisierung aufbewahren und repräsentative Telemetrie für spätere Optimierung nutzen.

Arbeitsumgebung für den Walkthrough vorbereiten

Verwenden Sie eine isolierte Linux-Laborumgebung mit Git, Terraform, kubectl, curl, jq, getent, Python ab Version 3.11 sowie PostgreSQL-Server- und Client-Werkzeugen. Die Rehost-Beispielskripte benötigen außerdem runuser, sha256sum, ein Betriebssystemkonto postgres und Root-Rechte, um eine temporäre lokale Datenbank zu erstellen und zu prüfen. Führen Sie die Beispielbefehle in dieser vorbereiteten Laborumgebung aus, nicht auf einem produktiven Datenbankhost. Die privaten Artefakte müssen für den Migrationsbediener lesbar bleiben; machen Sie sie nicht für alle Benutzer lesbar.

Beziehen Sie geprüfte Commit-IDs beider Repositorys vom Referenz-Maintainer und exportieren Sie diese vorab als REHOST_REVISION und REPLATFORM_REVISION. Der Replatform-Stand muss Gateway API und den freigabegesteuerten Migrationsworkflow enthalten. Setzen Sie nicht voraus, dass der Remote-Standardbranch bereits die lokal getestete Implementierung enthält. Ist der freigegebene Stand nicht verfügbar, beschaffen Sie ihn vor dem Walkthrough.

Ersetzen Sie beide Platzhalter durch die freigegebenen vollständigen Commit-IDs mit jeweils 40 Zeichen und setzen Sie diese im selben Bash-Terminal:

export REHOST_REVISION="REPLACE_WITH_REVIEWED_REHOST_COMMIT_ID"
export REPLATFORM_REVISION="REPLACE_WITH_REVIEWED_REPLATFORM_COMMIT_ID"

Führen Sie den folgenden Block vollständig aus einem leeren Arbeitsverzeichnis aus. Die if-Prüfung lehnt fehlende, leere oder falsch formatierte IDs einschließlich unveränderter Platzhalter ab. Jedes && führt den nächsten Befehl nur nach Erfolg des vorherigen aus. Git prüft die Verfügbarkeit der Commits; die Formatprüfung allein bestätigt weder Freigabe noch Repository-Inhalt.

if [[ ! ${REHOST_REVISION:-} =~ ^[0-9a-fA-F]{40}$ ||
      ! ${REPLATFORM_REVISION:-} =~ ^[0-9a-fA-F]{40}$ ]]; then
  printf '%s\n' "Set both revision variables to reviewed full 40-character commit IDs." >&2
  false
else
  umask 077 &&
    git clone https://github.com/stackitcloud/stackit-cmf-Rehost-springboot.git &&
    git clone https://github.com/stackitcloud/stackit-cmf-replatform-springboot-k8s.git &&
    git -C stackit-cmf-Rehost-springboot checkout --detach "$REHOST_REVISION" &&
    git -C stackit-cmf-replatform-springboot-k8s checkout --detach "$REPLATFORM_REVISION" &&
    test -f stackit-cmf-replatform-springboot-k8s/scripts/migrate_postgres.py &&
    test -f stackit-cmf-replatform-springboot-k8s/scripts/validate_gateway.sh &&
    cd stackit-cmf-replatform-springboot-k8s &&
    printf '%s\n' "Workspace ready. Continue from this Replatform checkout." || {
      printf '%s\n' "Preparation failed. Resolve the error before continuing." >&2
      false
    }
fi

Fahren Sie erst nach der Meldung Workspace ready fort. Bei Fehlern bleibt das Terminal offen; weitere Vorbereitungsbefehle werden übersprungen. Vorhandene oder teilweise geklonte Verzeichnisse werden weder entfernt noch überschrieben: Prüfen Sie diese und bewahren Sie lokale Änderungen, bevor Sie es in einem neuen leeren Arbeitsverzeichnis erneut versuchen. Nach Erfolg befindet sich das Terminal für die nächsten Schritte im Replatform-Checkout.

Nutzen Sie ein freigegebenes STACKIT Projekt, einen Service Account, DNS-Delegation, SKE-Kapazität und ein geschütztes Terraform-Backend. Beziehen Sie Zugangsdaten über den freigegebenen Secret-Kanal, niemals aus diesem Trail. Die folgenden Befehle setzen diese Verzeichnisstruktur und eine geprüfte Konfiguration voraus; sie belegen keinen validierten Greenfield-Produktionsaufbau.

Quellnachweise vorbereiten

Qualifizieren Sie einen konsistenten Quelldump und sein Manifest, bevor Daten in den Migrationsworkflow eingehen.

Die Rehost-Referenz liefert scripts/create_source_dump.sh und scripts/validate_source_dump.sh für ihr reproduzierbares Beispiel. Führen Sie diese im Rehost-Repository aus. Dessen Verzeichnis artifacts liefert source-postgresql.dump und source-postgresql.manifest an den Replatform-Workflow. Das Manifest erfasst Version 1, table=public.album, row_count, album_fingerprint und dump_sha256.

Führen Sie ausschließlich für das reproduzierbare Beispiel die folgenden Befehle vom Replatform-Checkout in der vorbereiteten Laborumgebung aus. Die Skripte erstellen aus dem versionierten Beispiel-SQL eine temporäre PostgreSQL-Instanz, exportieren sie und führen einen unabhängigen Test-Restore aus. Verwenden Sie ein frisches Artefaktverzeichnis; überschreiben Sie keine Nachweise einer bereits laufenden Migration.

umask 077
pushd ../stackit-cmf-Rehost-springboot
bash scripts/create_source_dump.sh
bash scripts/validate_source_dump.sh
popd

Erwartet wird eine erfolgreiche Validierung von acht Zeilen mit passendem Fingerprint. Diese Befehle lesen keine Quell-VM aus. Verwenden Sie für Probe und Cutover genau diese Artefakte weiter.

Ersetzen Sie für eine reale Quelle den Beispielgenerator durch ein freigegebenes Exportverfahren: Frieren Sie alle Schreibzugriffe ein und leiten Sie Dump im Custom-Format und Manifest aus demselben konsistenten Quellsnapshot ab. Das generierte Beispiel mit acht Alben ist kein Export einer beliebigen laufenden VM. Prüfen Sie vor dem Export PostgreSQL-Kompatibilität, Erweiterungen, Eigentümerschaft und Schemaabhängigkeiten.

Stellen Sie nur vertrauenswürdige Dumps wieder her, da sie SQL ausführen. Diese Implementierung migriert das Anwendungsschema public und prüft public.album; von Flex verwaltete Schemas sind bewusst ausgeschlossen. Andere Workloads benötigen eigene Invarianten und einen angepassten Schemaumfang.

Code & Registry github.com Spring-Boot-Rehost-Quelle und Beispielexport Das Rehost-Repository liefert dasselbe Anwendungsartefakt und reproduzierbare Werkzeuge für PostgreSQL-Quellnachweise. Repository öffnen

Ziel bereitstellen

Stellen Sie das Ziel aus einem geprüften Plan mit expliziten Angaben zu Projekt, Kapazität, Zugriff und DNS bereit.

Verwenden Sie Terraform, kubectl, curl, jq, getent und Python ab Version 3.11 unter Linux. Kopieren Sie env.tfvars.example nach env.tfvars und passen Sie die tatsächlichen Variablen dieser Datei an. Behalten Sie die getestete Provider-Lockdatei und unveränderliche Image- und JAR-Referenzen bei. Bestätigen Sie vor dem Plan die Verfügbarkeit der SKE-Version, Node-Pool-Kapazität, Projektberechtigungen und DNS-Delegation.

Aus der STACKIT-DokuLifecycle of Kubernetes Engine › Kubernetes end-of-life datesStand der Quelle 24.08.2026 · übernommen 05.10.2026

Starting with Kubernetes v1.33, we remove minor versions on the patch day that precedes the upstream maintenance end-of-life (EOL) date. The following table below lists the upstream EOL date for each Kubernetes minor version and the corresponding expiration date in SKE:

Seitlich wischen, um die ganze Tabelle zu sehen

Kubernetes minor version	End-of-life date	Expiration in SKE
v1.32	2026-02-28	2026-04-15
v1.33	2026-06-28	2026-06-10
v1.34	2026-10-27	2026-10-14
v1.35	2027-02-28	2027-02-10

Please refer to the official Kubernetes Release History for up-to-date announcements of new versions.

Was ist das?

Dieser Abschnitt wird mehrmals am Tag automatisch aus der STACKIT-Doku übernommen. Hier lässt er sich nicht ändern. Änderungen gehören in die STACKIT-Doku.

Bevorzugen Sie ein freigegebenes Application-Landing-Zone-Projekt. Setzen Sie create_project = false und geben Sie Projekt-ID und Pfad zum Service-Account-Schlüssel an. Die alternative Projekterstellung setzt einen freigegebenen übergeordneten Container und Berechtigungen voraus; sie ersetzt keine Landing-Zone-Governance. Zugangsdaten, State, gespeicherte Pläne und Migrationsnachweise gehören nie in die Versionsverwaltung.

Erstellen Sie für einen neuen Checkout die private Variablendatei, ohne eine vorhandene zu überschreiben:

umask 077
test -e env.tfvars || cp env.tfvars.example env.tfvars
chmod 600 env.tfvars

Bearbeiten Sie diese Datei vor dem Plan: Tragen Sie freigegebenes Projekt und Service-Account-Pfad, Region, unterstützte SKE-Version, verfügbaren Node-Pool-Flavor samt Zone und delegierte DNS-Einstellungen aus dem Repository-Beispiel ein. Prüfen Sie Backend-Zugriff und Sperren, Quotas, Kosten sowie die Grenzen von HTTP und öffentlichen Metriken. Die folgenden Funktionsschalter bilden keine vollständige Umgebungskonfiguration.

Einheitliche Automatisierungs-Flags

Der optionale gemeinsame Wrapper bildet setup_project, setup_observability, setup_database, setup_workload, setup_loadgen und setup_dns auf die Terraform-Schalter des Repositorys ab. Sie wählen ausschließlich den Bereitstellungsumfang: Das Aktivieren der Datenbank erlaubt keinen Datenaustausch und ersetzt niemals die separate Migrationsfreigabe.

Minimale Zielkonfiguration

Diese Werte aktivieren den vollständigen Workload- und Datenbankpfad. Sie ergänzen die Angaben zu Projekt, Region, Node Pool und DNS im Repository-Beispiel, ersetzen sie aber nicht.

deploy_workload                   = true
dns_enabled                       = true
enable_postgres_flex              = true
postgres_flex_target_database     = "springmusic"
postgres_flex_target_app_acl_cidrs = []
observability_enabled             = true
create_observability_instance     = true
create_grafana_dashboard          = true
enable_springboot_hpa              = false
enable_load_generator             = false
deploy_postgres_migration_job      = false

Lassen Sie HPA und Lastgenerierung während der Migration deaktiviert. Wählen Sie Alarmeinstellungen bewusst; die Alarmzustellung wurde im End-to-End-Test nicht validiert. springboot_image wählt die Java-Laufzeit, nicht ein beliebiges vorgefertigtes Anwendungsimage. Der Init-Container lädt das auf einen Commit fixierte Rehost-JAR und prüft vor dem Start seinen SHA-256-Wert. Spiegeln Sie unveränderliche Artefakte für die Produktion in freigegebene Artefakt- und Image-Dienste.

Führen Sie die Befehle im Replatform-Repository aus und prüfen Sie den gespeicherten Plan vor dem Apply:

umask 077
terraform init
terraform validate
terraform plan -var-file=env.tfvars -out=tfplan
terraform apply tfplan
bash scripts/validate_gateway.sh

Zugriffskontrolle und temporäre ACL-Erweiterung für Migration

Bei leeren Anwendungs-ACL-Eingaben verwendet Terraform die tatsächlichen Egress-CIDRs des SKE-Clusters für PostgreSQL Flex. Explizite Anwendungs- oder ältere ACL-Werte überschreiben diesen Standard und müssen geprüft werden. Erlauben Sie nicht 0.0.0.0/0.

Der temporäre PostgreSQL-Client läuft in SKE und erhält den Dump über kubectl. Er verbindet sich nicht direkt mit der Quell-VM; weder Quell- noch Arbeitsplatz-CIDRs benötigen temporären Flex-Zugriff. JDBC und Datenbankwerkzeuge verwenden sslmode=require: Das erzwingt Verschlüsselung, bietet aber nicht die Hostnamenprüfung von verify-full. Schützen Sie Zugangsdaten in Kubernetes Secrets und im Terraform-Backend und validieren Sie bei Bedarf eine stärkere Zertifikatsprüfung.

Migration proben

Stellen Sie den finalen Dump in der isolierten Probedatenbank wieder her und verlangen Sie passende Nachweise, die jünger als 24 Stunden sind.

Führen Sie nach dem Infrastruktur-Apply einen isolierten Restore in springmusic_rehearsal aus. Passen Sie das Quellverzeichnis an die freigegebenen Artefakte an und halten Sie den Nachweispfad privat.

python3 scripts/migrate_postgres.py rehearse \
  --artifacts ../stackit-cmf-Rehost-springboot/artifacts \
  --evidence .tmp/migration-run

Die Probe validiert Manifest, Dump-Prüfsumme, Zielidentität, Zeilenanzahl und Fingerprint, ohne die Anwendungsdatenbank zu ersetzen. Proben Sie nach dem Schreibstopp auf der Quelle erneut mit dem finalen Dump. Der Cutover verlangt passende Nachweise, die jünger als 24 Stunden sind. Eine erfolgreiche Probe mit einem älteren oder anderen Dump gibt die finale Eingabe nicht frei.

Option: VM-PostgreSQL nach PostgreSQL Flex migrieren

Der alte Pfad deploy_postgres_migration_job = true wird durch die Validierung gesperrt. Nutzen Sie stattdessen den freigabegesteuerten Workflow. Stoppen Sie HPA, Lastgenerierung und alle anderen Zielschreiber. Pausieren Sie Terraform- und GitOps-Reconciliation, solange das Skript die Replikazahl steuert. Seine lokale Sperre schützt nur einen Checkout, nicht vor gleichzeitigen Bedienern auf unterschiedlichen Rechnern.

python3 scripts/migrate_postgres.py cutover \
  --artifacts ../stackit-cmf-Rehost-springboot/artifacts \
  --evidence .tmp/migration-run \
  --source-write-frozen --confirm-target springmusic

Das Quellschreibstopp-Flag ist eine Bestätigung des Betreibers, keine automatische Abschaltung der Quelle. Der Cutover skaliert die Anwendung auf null, sichert das Ziel vor dem Cutover und prüft die Sicherung per Prüfsumme. Er weist ihre Wiederherstellbarkeit in der Probedatenbank nach und stellt erst dann die Quelle transaktional wieder her. Vor dem Wiederanlauf mit ursprünglicher Replikazahl werden die Daten geprüft. Bei Fehlern bleibt die Anwendung zur Untersuchung gestoppt. Bewahren Sie Nachweisjournal und Backup auf; überschreiben Sie sie nicht für einen erneuten Versuch.

Validieren und zurückrollen

Vergleichen Sie Datenbanknachweise mit dem Quellmanifest, prüfen Sie das Anwendungsverhalten über das Gateway und bestätigen Sie den Zustand beider Metrik-Jobs. Traffic-Umschaltung und fachliche Abnahme bleiben Betreiberaufgaben; das Skript ändert den Endpunkt der Quellanwendung nicht.

So stellen Sie die geschützte Zieldatenbank aus der Zeit vor dem Cutover wieder her:

python3 scripts/migrate_postgres.py rollback \
  --evidence .tmp/migration-run --confirm-target springmusic

Der Rollback prüft Zielidentität und Backup-Integrität, sichert das aktuelle Ziel separat, stellt die ursprünglichen Daten wieder her und verifiziert vor dem Wiederanlauf deren Fingerprint. Schreibzugriffe nach dem Cutover werden nicht zusammengeführt; bewahren Sie den Dump vor dem Rollback für einen expliziten Abgleich auf. Dies ist ein Zieldatenbank-Rollback, kein automatischer Failback zur Quell-VM.

Datenbank-Metriken in Observability sichtbar machen

Terraform verwaltet den Grafana-Ordner SCF Replatform und das Dashboard mit acht Panels an der vorhandenen Datenquelle Thanos. Öffnen Sie es über grafana_dashboard_url. Cluster-CPU, Cluster-Speicher, laufende Pods, Anwendungsanfragen sowie PostgreSQL-Zustand und -Auslastung unterstützen Abnahme und spätere Optimierung. Ein manueller Dashboard-Import ist nicht nötig.

Anwendungsmetriken stammen aus dem pod-lokalen Boot-2-Actuator über den Metrikadapter auf Port 9090; der PostgreSQL-Exporter nutzt Port 9187. Prüfen Sie beide tatsächlichen Scrape-Ergebnisse, nicht nur die Dashboard-Darstellung. Fehlende Telemetrie ist ein Untersuchungsgrund, niemals der Nachweis fehlender Last.

Validierung mit kubectl

Exportieren Sie eine kurzlebige Kubeconfig mit privaten Berechtigungen und prüfen Sie den Standard-Namespace der Referenz:

umask 077
mkdir -p .tmp
terraform output -raw kubeconfig > .tmp/replatform.kubeconfig
export KUBECONFIG="$PWD/.tmp/replatform.kubeconfig"
kubectl get deploy,svc,pods -n springboot
kubectl get gateway,httproute -n springboot
kubectl rollout status deployment/springboot -n springboot
bash scripts/validate_gateway.sh

Der Gateway-Validator prüft Akzeptanz, aufgelöste Routenreferenzen, DNS und Anwendungsantwort. Entfernen Sie die lokale Kubeconfig nach Gebrauch und beziehen Sie nach Ablauf eine neue. Ein erfolgreicher Rollout allein ist keine Daten- oder fachliche Abnahme.

Grenze zwischen Backup und Recovery

Trennen Sie Migrations-Rollback von Flex-Service-Recovery und bewahren Sie geschützte Nachweise außerhalb kurzlebiger Ausführungsumgebungen auf.

Die Flex-Aufbewahrung wird explizit konfiguriert; der Standard dieser Referenz beträgt 32 Tage. Managed-Datenbankbackups und der Migrationsdump vor dem Cutover dienen unterschiedlichen Zwecken. Die Probe mit Letzterem weist weder Managed-Service-Restore noch Point-in-Time-Recovery oder Disaster Recovery der Anwendung nach. Benennen Sie Recovery-Verantwortliche und testen Sie den benötigten Service-Recovery-Pfad separat.

Bewahren Sie geschützte Nachweise und Backups bis zum Ende des Rollback-Fensters außerhalb eines kurzlebigen Dev Containers auf. Prüfen Sie nach einem abgebrochenen Migrationsprozess verbliebene Pods mit Präfix springmusic-migration-*, bevor Sie fortfahren; starten Sie ein ungeprüftes Ziel nicht durch Terraform neu.

Was dieses Asset zeigt

Dieses Asset zeigt, wie das Anwendungsverhalten beim Wechsel der Betriebsmodelle für Laufzeit und Datenbank erhalten bleibt:

Plattformwechsel: Dasselbe Spring-Boot-JAR auf SKE betreiben, über TLS mit PostgreSQL Flex verbinden und über Gateway API und DNS erreichbar machen.
Kontrollierte Datenmigration: Quelldump und Manifest qualifizieren, einen isolierten Restore proben und vor dem Cutover eine explizite Freigabe sowie ein verifiziertes Zielbackup verlangen. Bei erforderlichem Rollback den Zielzustand vor dem Cutover wiederherstellen.
Unabhängige Validierung: Datenintegrität, Anwendungsantworten, Gateway- und DNS-Bereitschaft sowie tatsächliche Scrape-Ergebnisse prüfen. Den Terraform-Plan auf unerklärte Drift prüfen, statt erfolgreiche Bereitstellung als Migrationsabnahme zu behandeln.
Wiederholbare Observability: Observability-Integration und Grafana-Dashboard mit acht Panels durch Terraform verwalten. Anwendungs- und Datenbanksignale für Abnahme, Stabilisierung und spätere Optimierung nutzen.

Nicht abgedeckt

Diese Nachweise bestätigen weder einen vollständigen Greenfield-Durchlauf noch eine Migration aus einer produktiven Live-Quelle, unterbrechungsfreien Betrieb, Hochverfügbarkeit, öffentliches Gateway-TLS, interaktiven IDP-Login, Alarmzustellung oder Managed-Flex-Recovery. Der getestete Ein-Worker-Aufbau mit HTTP stellt Metriken ohne Authentifizierung bereit; erfüllen Sie die Produktionsanforderungen vor der Verwendung sensibler Daten. Aktualisieren Sie die Beispielanwendung und validieren Sie eine geeignete unterstützte Kubernetes-Version als separate kontrollierte Änderungen.

Code & Registry github.com Referenzkonfiguration, Skripte und Validierungsnachweise Das Repository-README und die versionierte Implementierung liefern genaue Voraussetzungen, Variablen, Befehle und Recovery-Grenzen. Repository öffnen

Anwendungsfall

Überführen Sie die Spring-Music-Anwendung von einer VM zu STACKIT Kubernetes Engine und ihre Daten von selbstverwaltetem PostgreSQL zu PostgreSQL Flex. Behalten Sie Anwendungs-JAR und fachliches Verhalten bei und führen Sie Kubernetes-Deployment, Gateway API, DNS und Managed Observability ein.

Dieses Runbook beschreibt die Freigaben und die betriebliche Reihenfolge rund um die Befehle von scripts/migrate_postgres.py im Referenzrepository. Infrastrukturbereitstellung und Datenbankaustausch sind getrennte Vorgänge. Ein erfolgreiches Terraform-Apply ist keine Migrationsabnahme.

Umfang und Annahmen

Die Referenz migriert das Schema public und validiert public.album anhand von Zeilenanzahl und deterministischem Fingerprint. Die getestete Eingabe ist das Rehost-Beispiel mit acht Alben, kein Export einer Live-Quelle. Ein realer Workload benötigt einen eigenen kompatiblen Export, eine Schemabewertung, fachliche Tests und Recovery-Ziele. Geben Sie Ausfallzeit frei: Dies ist eine Migration mit Schreibstopp und Dump/Restore, keine Replikation oder unterbrechungsfreie Umschaltung.

Das Ziel verwendet eine eigene Anwendungs- und Probedatenbank, Datenbankverbindungen mit TLS-Pflicht und einen temporären clusterinternen Migrationsclient. Das Skript stoppt weder Quellschreiber noch schaltet es Client-Traffic um, konfiguriert öffentliches TLS oder automatisiert den Failback zur Quelle. Diese Aufgaben liegen beim Betreiber.

Rollen und Verantwortlichkeiten

Seitlich wischen, um die ganze Tabelle zu sehen

Rolle	Verantwortete Entscheidung oder Nachweis
Migrationsleitung	Zeitfenster, Kontrollpunkte, Go/No-Go-Befugnis, Rollback-Deadline und Incident-Koordination
Anwendungsverantwortliche	Vollständige Erfassung der Schreiber, Quellschreibstopp, fachliche Abnahme und Abgleich von Schreibzugriffen nach dem Cutover
Plattform-Engineering	Freigegebener Terraform-Plan, SKE-Zugriff, Gateway- und DNS-Bereitschaft, pausierte Reconciliation
Datenbankverantwortliche	Konsistente Quellnachweise, Probe, geschütztes Backup, Restore-Integrität und Rollback-Ausführung
Betriebsverantwortliche	Telemetrie, Incident-Zuweisung, Recovery-Verantwortung, Aufbewahrung und Ende der Stabilisierung

Entscheidungs- und Freigabepunkte der Migration

Bereit zur Migration: Zieldesign, Zugriffsgrenzen, Ausfallzeit, Verantwortlichkeiten und messbare Abnahmekriterien vor Beginn des Fensters freigeben.
Bereit zum Cutover: Quellschreibzugriffe einfrieren und einen konsistenten finalen Dump mit passenden, aktuellen Probenachweisen verlangen. Infrastruktur-Bereitschaft allein erlaubt keinen Datenaustausch.
Geschützte Ausführung: Konkurrierende Schreiber und Reconciliation ausschließen, das Zielbackup vor dem Cutover nachweisen und den transaktionalen Restore vor dem Workload-Neustart validieren.
Abnehmen oder wiederherstellen: Übereinstimmende Daten, erfolgreiche fachliche Abläufe, funktionierenden Client-Traffic und tatsächliche Telemetrie verlangen. Rollback vor der Deadline entscheiden; Quell-Failback und Abgleich späterer Schreibzugriffe bleiben separate Entscheidungen.
Bereit für den Betrieb: Nachweise und Recovery-Verantwortung übergeben, den Workload stabilisieren und Automatisierung bewusst wieder aufnehmen. Kapazitäts- und HPA-Experimente gehören in ein späteres Änderungsfenster.

Diese Freigabepunkte erläutern das Kontrollmodell. Die folgenden Abschnitte liefern das ausführbare Verfahren und die Nachweisanforderungen für den technischen Walkthrough.

Prüfungen vor der Migration

Bestätigen Sie Schreibkontrolle, pausierte Reconciliation, Verantwortlichkeiten, Abnahmekriterien und Rollback-Deadline.

Quellbaseline: JAR-Prüfsumme, Java- und PostgreSQL-Versionen, Schemaabhängigkeiten, Datenmenge und Änderungsrate, geplante Jobs, Integrationen und Recovery-Ziele erfassen.
Quellnachweise: Vertrauenswürdigen Dump und Manifest aus einem konsistenten Snapshot validieren; Prüfsumme, erwartete Zeilenanzahl und Fingerprint dokumentieren. Den finalen Dump nach dem Schreibstopp proben.
Zielbereitschaft: Geprüftes Infrastruktur-Apply abschließen; SKE-Kapazität, Artefaktzugriff, Flex-Konnektivität und ACLs, Gateway-Zustände, DNS, Anwendungsantworten und beide Metrik-Jobs prüfen.
Zugriff und Sicherheit: Kubeconfig und Berechtigungen prüfen, State und Pläne schützen, Secrets und Nachweise einschränken sowie HTTP- und öffentliche Metrikgrenzen passend zur Datenklassifikation auflösen.
Schreibkontrolle: HPA und Lastgenerierung deaktivieren, weitere Zielschreiber stoppen sowie Terraform, GitOps und geplante Deployment-Jobs während der Migration pausieren. Das Ziel für genau einen Betreiberworkflow reservieren.
Recovery-Bereitschaft: Zielidentität, Nachweisort, geschützten Backup-Speicher außerhalb des Containers, Rollback-Befugnis, Deadline, Traffic-Umschaltung und Quellaufbewahrung vereinbaren.
Abnahme: Erlaubte Ausfallzeit, Dateninvarianten, fachliche Tests, Fehler- und Latenzgrenzen sowie Reaktion auf fehlende Telemetrie vor Beginn des Fensters festlegen.

Ablaufplan für das Cutover-Fenster

Phase 1: Quelle und Ziel vorbereiten

Freigegebenen Codestand, Variablendatei, Projekt, Cluster, Namespace und Zieldatenbank bestätigen.
Das Ziel über einen geprüften gespeicherten Terraform-Plan bereitstellen; fachfremden Ressourcenaustausch ablehnen.
bash scripts/validate_gateway.sh ausführen und Workload-Rollout sowie PostgreSQL-Konnektivität prüfen.
Quellnachweise und Ausgangsverhalten des Ziels erfassen. Ein Ziel mit Initialdaten ist kein abgenommenes migriertes Ziel.
enable_springboot_hpa = false, enable_load_generator = false und deploy_postgres_migration_job = false setzen; diese Einstellungen vor dem Pausieren der Infrastrukturautomatisierung anwenden.

Phase 2: Schreibzugriffe einfrieren und proben

Go/No-Go-Freigabe einholen und alle Quellschreiber einschließlich Integrationen und Hintergrundjobs einfrieren.
Finalen konsistenten Dump und Manifest über das freigegebene Quellverfahren exportieren.
Die Probe im Replatform-Repository mit dem freigegebenen Artefaktverzeichnis ausführen:

python3 scripts/migrate_postgres.py rehearse \
  --artifacts ../stackit-cmf-Rehost-springboot/artifacts \
  --evidence .tmp/migration-run

Übereinstimmende Prüfsumme, Zeilenanzahl, Fingerprint und Zielidentität verlangen; die unveränderte Anwendungsdatenbank bestätigen.
Bestätigen, dass die erfolgreiche Probe jünger als 24 Stunden und der finale Dump unverändert ist. Veraltete oder unpassende Nachweise ablehnen.

Phase 3: Cutover und Freigabe

Quellschreibstopp, Ausschluss weiterer Zielschreiber, pausierte Reconciliation, Entscheidungsfrist und verfügbaren Nachweisspeicher erneut bestätigen.
Den explizit bestätigten Cutover ausführen:

python3 scripts/migrate_postgres.py cutover \
  --artifacts ../stackit-cmf-Rehost-springboot/artifacts \
  --evidence .tmp/migration-run \
  --source-write-frozen --confirm-target springmusic

Verlangen, dass das Skript die Anwendungsreplikas stoppt, den Zieldump vor dem Cutover sichert und dessen Restore in der Probedatenbank vor dem Quellimport nachweist.
Erfolgreichen transaktionalen Quellrestore und Datenprüfungen verlangen, bevor das Skript die ursprüngliche Replikazahl wiederherstellt. Eine nach einem Fehler gestoppte Anwendung untersuchen; nicht mit Terraform übersteuern.
Technische und fachliche Validierung abschließen und anschließend den Client-Traffic nach dem freigegebenen Betreiberverfahren umschalten. Den neuen Clientpfad und den fortbestehenden Quellschreibstopp prüfen.
Abnahme und Schreibverantwortung dokumentieren. Nach Skriptende und korrekter Replikazahl einen Terraform-Plan auf Drift prüfen und eine reine Kubeconfig-Aktualisierung in Outputs erklären; während der Abnahme keine fachfremden Änderungen anwenden.

Validierungscheckliste

Nehmen Sie nur mit übereinstimmenden Datennachweisen, erfolgreichen Clientanfragen, gesunder Laufzeit und tatsächlicher Telemetrie ab.

Seitlich wischen, um die ganze Tabelle zu sehen

Freigabepunkt	Erforderlicher Nachweis
Datenintegrität	Prüfsumme des Quellmanifests, erwartete Anzahl und Fingerprint stimmen mit dem wiederhergestellten Ziel überein; das Migrationsjournal benennt das richtige Projekt und die Datenbank
Laufzeit	Ursprüngliche Replikazahl wiederhergestellt, gesunder Rollout, keine unerklärten Neustarts oder Verbindungsfehler
Netzwerkverkehr	Gateway akzeptiert, HTTPRoute-Referenzen aufgelöst, DNS entspricht dem Gateway, tatsächliche Clientanfragen erreichen das beabsichtigte Ziel
Fachliches Verhalten	Migrierte Alben sichtbar und freigegebene Benutzerabläufe erfolgreich; Schreibtests besitzen einen vereinbarten Bereinigungs- und Abgleichplan
Datenbanktransport	Anwendung und Migration verlangen TLS; ACL erlaubt nur freigegebenes SKE-Egress oder explizit genehmigte Ausnahmen
Observability	Beide Scrape-Jobs liefern tatsächliche `up=1`-Messwerte, der Exporter meldet Datenbankzustand und Dashboard-Werte entsprechen dem Workload
Recovery	Backup vor dem Cutover, Prüfsumme, ursprünglicher Fingerprint und Journal privat aufbewahrt und in geschützten dauerhaften Speicher kopiert
Konfiguration	Geprüfter Plan nach der Migration ohne unerklärte Ressourcendrift; Betriebszustände von Quelle und Ziel dokumentiert

Ein erfolgreicher öffentlicher HTTP-Aufruf erfüllt allein keine produktive HTTPS-Anforderung. Das Beispiel-Dashboard ersetzt keine unabhängige fachliche, Latenzperzentil-, Fehlerraten- oder Recovery-Validierung.

Rollback-Kriterien und Schritte

Stellen Sie bei einem freigegebenen Auslöser das geschützte Ziel wieder her; gleichen Sie Schreibzugriffe nach dem Cutover ab und entscheiden Sie den Quell-Failback separat.

Rollback-Auslöser

Treffen Sie die vereinbarte Entscheidung vor der Deadline, wenn Dateninvarianten verletzt sind, ein kritischer fachlicher Ablauf nicht im Fehlerbehebungsfenster wiederhergestellt werden kann, Zielinstabilität die Abnahmegrenzen überschreitet oder keine vertrauenswürdige Telemetrie festgestellt werden kann. Bewahren Sie Migrationsjournal und Logs auf.

Rollback der Zieldatenbank

Clientschreibzugriffe stoppen oder isolieren und automatische Reconciliation pausiert lassen. Rollback-Befugnis und Zielidentität bestätigen.
Das geschützte Ziel vor dem Cutover mit dem ursprünglichen Nachweisverzeichnis wiederherstellen:

python3 scripts/migrate_postgres.py rollback \
  --evidence .tmp/migration-run --confirm-target springmusic

Validierung der Backup-Prüfsumme, einen separaten Dump des aktuellen Ziels vor dem Rollback und Übereinstimmung des ursprünglichen Datenfingerprints vor dem Neustart verlangen.
Gateway-Erreichbarkeit, Anwendungsverhalten und wiederhergestellten Zielzustand prüfen. Nicht annehmen, dass dieser Zustand die neuesten Quelldaten enthält.
Alle Schreibzugriffe nach dem Cutover im Dump vor dem Rollback für einen expliziten Abgleich bewahren. Sie werden nicht automatisch in die wiederhergestellten Daten übernommen.

Quell-Failback und unterbrochene Läufe

Die Rückkehr der Benutzer zur VM ist eine separate Entscheidung: Quellintegrität bestätigen, angenommene Zielschreibzugriffe abgleichen, Client-Traffic nach dem freigegebenen Verfahren umleiten und genau einer Seite Schreibzugriffe erlauben. Der Restore des Ziels vor dem Cutover allein führt diese Schritte nicht aus.

Schlägt der Cutover fehl, bevor ein gültiges Backup dokumentiert ist, prüfen Sie Journal und Datenbank gemeinsam mit den Datenbankverantwortlichen. Überschreiben Sie niemals das Nachweisverzeichnis und starten Sie den Cutover nicht blind erneut. Prüfen Sie nach einem beendeten Prozess verbliebene Pods mit Präfix springmusic-migration-* und das gestoppte Deployment, bevor Sie fortfahren. Die lokale Migrationssperre koordiniert keine unterschiedlichen Ausführungshosts.

Übergabe an den Betrieb

Übergeben Sie Konfiguration, Abnahmenachweise, Dashboards, Incident-Verantwortung und Entscheidungen zur Quellaufbewahrung.

Übergeben Sie den geprüften Konfigurationsstand, Workload- und Gateway-Inventar, Quellmanifest, Migrationsjournal, Backup-Orte, Abnahmeergebnisse, Dashboard-URL und Rollback-Entscheidung. Halten Sie Zugangsdaten aus dem Übergabedokument heraus und verweisen Sie auf den freigegebenen Secret-Speicher.

Vereinbaren Sie ein zum Workload passendes anfängliches Stabilisierungsfenster von 24 bis 72 Stunden. Benennen Sie Incident- und Datenbank-Recovery-Verantwortliche, bestätigen Sie Aufbewahrungs- und Restore-Verfahren und testen Sie Alarmzustellung, bevor Sie sich darauf verlassen. Flex-Backups ergänzen Migrationsdumps; ein verifizierter Dump-Rollback ist kein Nachweis für Managed-Service-Recovery.

Beenden Sie die Stabilisierung nur bei dauerhaft gesundem fachlichem Verhalten, vollständiger Telemetrie, ohne ungelöste kritische Probleme und mit Betriebsfreigabe. Nehmen Sie pausierte Automatisierung bewusst wieder auf. Bewahren Sie Quelldaten und geschützte Nachweise auf, bis die vereinbarten Aufbewahrungs- und Abgleichkriterien die Stilllegung erlauben. Beginnen Sie HPA- und Kapazitätsexperimente erst nach der Stabilisierung in einem separaten Änderungsfenster.

Vorlage für das Nachweisprotokoll

Seitlich wischen, um die ganze Tabelle zu sehen

Kontrollpunkt	Verantwortliche Rolle	Zeitstempel	Ergebnis	Nachweisreferenz
Ziel und Clientpfad bereit	Plattform-Engineering	JJJJ-MM-TT HH:MM	Bestanden/Fehlgeschlagen	Geschützter Eintrag
Quellschreibstopp und finaler Export	Anwendungs- und Datenbankverantwortliche	JJJJ-MM-TT HH:MM	Bestanden/Fehlgeschlagen	Manifest und Freigabe
Finale Probe abgenommen	Datenbankverantwortliche	JJJJ-MM-TT HH:MM	Bestanden/Fehlgeschlagen	Probejournal
Backup vor dem Cutover nachgewiesen	Datenbankverantwortliche	JJJJ-MM-TT HH:MM	Bestanden/Fehlgeschlagen	Backup-Prüfsumme und Restore-Ergebnis
Cutover und Integrität abgenommen	Datenbankverantwortliche	JJJJ-MM-TT HH:MM	Bestanden/Fehlgeschlagen	Migrationsjournal
Fachlichkeit und Netzwerkverkehr abgenommen	Anwendungsverantwortliche	JJJJ-MM-TT HH:MM	Bestanden/Fehlgeschlagen	Test- und Routing-Nachweise
Drift und Telemetrie geprüft	Plattform-Engineering	JJJJ-MM-TT HH:MM	Bestanden/Fehlgeschlagen	Plan- und Metriknachweise
Übergabe oder Rollback abgeschlossen	Migrationsleitung	JJJJ-MM-TT HH:MM	Bestanden/Fehlgeschlagen	Unterzeichnete Entscheidung

Code & Registry github.com Ausführbarer Migrations- und Recovery-Workflow Das Referenzrepository liefert genaue Befehlsvoraussetzungen, Nachweisformate, Schutzmechanismen und Validierungsumfang. Repository öffnen

LIVE

Cutover ausführen

Migration design-and-mobilize use-cases replatform spring-boot postgresql ske cutover migration

Spring Boot und PostgreSQL auf SKE und PostgreSQL Flex umstellen

STACKIT

Spring-Boot-Replatform kontrolliert umsetzen: mit Quellnachweisen, isolierter PostgreSQL-Probe, freigegebenem Cutover, geprüftem Rollback und Betriebsübergabe.

Code & Registry github.com Ausführbarer Migrations- und Recovery-Workflow Das Referenzrepository liefert genaue Befehlsvoraussetzungen, Nachweisformate, Schutzmechanismen und Validierungsumfang. Repository öffnen

STACKIT

Der souveräne europäische Cloud-Anbieter hinter dem Framework, mit IaaS und PaaS aus deutschen und österreichischen Rechenzentren und voller Unabhängigkeit.

Anwendungsfall

Überführen Sie die Spring-Music-Anwendung von einer VM zu STACKIT Kubernetes Engine und ihre Daten von selbstverwaltetem PostgreSQL zu PostgreSQL Flex. Behalten Sie Anwendungs-JAR und fachliches Verhalten bei und führen Sie Kubernetes-Deployment, Gateway API, DNS und Managed Observability ein.

Dieses Runbook beschreibt die Freigaben und die betriebliche Reihenfolge rund um die Befehle von scripts/migrate_postgres.py im Referenzrepository. Infrastrukturbereitstellung und Datenbankaustausch sind getrennte Vorgänge. Ein erfolgreiches Terraform-Apply ist keine Migrationsabnahme.

Umfang und Annahmen

Die Referenz migriert das Schema public und validiert public.album anhand von Zeilenanzahl und deterministischem Fingerprint. Die getestete Eingabe ist das Rehost-Beispiel mit acht Alben, kein Export einer Live-Quelle. Ein realer Workload benötigt einen eigenen kompatiblen Export, eine Schemabewertung, fachliche Tests und Recovery-Ziele. Geben Sie Ausfallzeit frei: Dies ist eine Migration mit Schreibstopp und Dump/Restore, keine Replikation oder unterbrechungsfreie Umschaltung.

Das Ziel verwendet eine eigene Anwendungs- und Probedatenbank, Datenbankverbindungen mit TLS-Pflicht und einen temporären clusterinternen Migrationsclient. Das Skript stoppt weder Quellschreiber noch schaltet es Client-Traffic um, konfiguriert öffentliches TLS oder automatisiert den Failback zur Quelle. Diese Aufgaben liegen beim Betreiber.

Rollen und Verantwortlichkeiten

Seitlich wischen, um die ganze Tabelle zu sehen

Rolle	Verantwortete Entscheidung oder Nachweis
Migrationsleitung	Zeitfenster, Kontrollpunkte, Go/No-Go-Befugnis, Rollback-Deadline und Incident-Koordination
Anwendungsverantwortliche	Vollständige Erfassung der Schreiber, Quellschreibstopp, fachliche Abnahme und Abgleich von Schreibzugriffen nach dem Cutover
Plattform-Engineering	Freigegebener Terraform-Plan, SKE-Zugriff, Gateway- und DNS-Bereitschaft, pausierte Reconciliation
Datenbankverantwortliche	Konsistente Quellnachweise, Probe, geschütztes Backup, Restore-Integrität und Rollback-Ausführung
Betriebsverantwortliche	Telemetrie, Incident-Zuweisung, Recovery-Verantwortung, Aufbewahrung und Ende der Stabilisierung

Entscheidungs- und Freigabepunkte der Migration

Bereit zur Migration: Zieldesign, Zugriffsgrenzen, Ausfallzeit, Verantwortlichkeiten und messbare Abnahmekriterien vor Beginn des Fensters freigeben.
Bereit zum Cutover: Quellschreibzugriffe einfrieren und einen konsistenten finalen Dump mit passenden, aktuellen Probenachweisen verlangen. Infrastruktur-Bereitschaft allein erlaubt keinen Datenaustausch.
Geschützte Ausführung: Konkurrierende Schreiber und Reconciliation ausschließen, das Zielbackup vor dem Cutover nachweisen und den transaktionalen Restore vor dem Workload-Neustart validieren.
Abnehmen oder wiederherstellen: Übereinstimmende Daten, erfolgreiche fachliche Abläufe, funktionierenden Client-Traffic und tatsächliche Telemetrie verlangen. Rollback vor der Deadline entscheiden; Quell-Failback und Abgleich späterer Schreibzugriffe bleiben separate Entscheidungen.
Bereit für den Betrieb: Nachweise und Recovery-Verantwortung übergeben, den Workload stabilisieren und Automatisierung bewusst wieder aufnehmen. Kapazitäts- und HPA-Experimente gehören in ein späteres Änderungsfenster.

Diese Freigabepunkte erläutern das Kontrollmodell. Die folgenden Abschnitte liefern das ausführbare Verfahren und die Nachweisanforderungen für den technischen Walkthrough.

Prüfungen vor der Migration

Bestätigen Sie Schreibkontrolle, pausierte Reconciliation, Verantwortlichkeiten, Abnahmekriterien und Rollback-Deadline.

Quellbaseline: JAR-Prüfsumme, Java- und PostgreSQL-Versionen, Schemaabhängigkeiten, Datenmenge und Änderungsrate, geplante Jobs, Integrationen und Recovery-Ziele erfassen.
Quellnachweise: Vertrauenswürdigen Dump und Manifest aus einem konsistenten Snapshot validieren; Prüfsumme, erwartete Zeilenanzahl und Fingerprint dokumentieren. Den finalen Dump nach dem Schreibstopp proben.
Zielbereitschaft: Geprüftes Infrastruktur-Apply abschließen; SKE-Kapazität, Artefaktzugriff, Flex-Konnektivität und ACLs, Gateway-Zustände, DNS, Anwendungsantworten und beide Metrik-Jobs prüfen.
Zugriff und Sicherheit: Kubeconfig und Berechtigungen prüfen, State und Pläne schützen, Secrets und Nachweise einschränken sowie HTTP- und öffentliche Metrikgrenzen passend zur Datenklassifikation auflösen.
Schreibkontrolle: HPA und Lastgenerierung deaktivieren, weitere Zielschreiber stoppen sowie Terraform, GitOps und geplante Deployment-Jobs während der Migration pausieren. Das Ziel für genau einen Betreiberworkflow reservieren.
Recovery-Bereitschaft: Zielidentität, Nachweisort, geschützten Backup-Speicher außerhalb des Containers, Rollback-Befugnis, Deadline, Traffic-Umschaltung und Quellaufbewahrung vereinbaren.
Abnahme: Erlaubte Ausfallzeit, Dateninvarianten, fachliche Tests, Fehler- und Latenzgrenzen sowie Reaktion auf fehlende Telemetrie vor Beginn des Fensters festlegen.

Ablaufplan für das Cutover-Fenster

Phase 1: Quelle und Ziel vorbereiten

Freigegebenen Codestand, Variablendatei, Projekt, Cluster, Namespace und Zieldatenbank bestätigen.
Das Ziel über einen geprüften gespeicherten Terraform-Plan bereitstellen; fachfremden Ressourcenaustausch ablehnen.
bash scripts/validate_gateway.sh ausführen und Workload-Rollout sowie PostgreSQL-Konnektivität prüfen.
Quellnachweise und Ausgangsverhalten des Ziels erfassen. Ein Ziel mit Initialdaten ist kein abgenommenes migriertes Ziel.
enable_springboot_hpa = false, enable_load_generator = false und deploy_postgres_migration_job = false setzen; diese Einstellungen vor dem Pausieren der Infrastrukturautomatisierung anwenden.

Phase 2: Schreibzugriffe einfrieren und proben

Go/No-Go-Freigabe einholen und alle Quellschreiber einschließlich Integrationen und Hintergrundjobs einfrieren.
Finalen konsistenten Dump und Manifest über das freigegebene Quellverfahren exportieren.
Die Probe im Replatform-Repository mit dem freigegebenen Artefaktverzeichnis ausführen:

python3 scripts/migrate_postgres.py rehearse \
  --artifacts ../stackit-cmf-Rehost-springboot/artifacts \
  --evidence .tmp/migration-run

Übereinstimmende Prüfsumme, Zeilenanzahl, Fingerprint und Zielidentität verlangen; die unveränderte Anwendungsdatenbank bestätigen.
Bestätigen, dass die erfolgreiche Probe jünger als 24 Stunden und der finale Dump unverändert ist. Veraltete oder unpassende Nachweise ablehnen.

Phase 3: Cutover und Freigabe

Quellschreibstopp, Ausschluss weiterer Zielschreiber, pausierte Reconciliation, Entscheidungsfrist und verfügbaren Nachweisspeicher erneut bestätigen.
Den explizit bestätigten Cutover ausführen:

python3 scripts/migrate_postgres.py cutover \
  --artifacts ../stackit-cmf-Rehost-springboot/artifacts \
  --evidence .tmp/migration-run \
  --source-write-frozen --confirm-target springmusic

Verlangen, dass das Skript die Anwendungsreplikas stoppt, den Zieldump vor dem Cutover sichert und dessen Restore in der Probedatenbank vor dem Quellimport nachweist.
Erfolgreichen transaktionalen Quellrestore und Datenprüfungen verlangen, bevor das Skript die ursprüngliche Replikazahl wiederherstellt. Eine nach einem Fehler gestoppte Anwendung untersuchen; nicht mit Terraform übersteuern.
Technische und fachliche Validierung abschließen und anschließend den Client-Traffic nach dem freigegebenen Betreiberverfahren umschalten. Den neuen Clientpfad und den fortbestehenden Quellschreibstopp prüfen.
Abnahme und Schreibverantwortung dokumentieren. Nach Skriptende und korrekter Replikazahl einen Terraform-Plan auf Drift prüfen und eine reine Kubeconfig-Aktualisierung in Outputs erklären; während der Abnahme keine fachfremden Änderungen anwenden.

Validierungscheckliste

Nehmen Sie nur mit übereinstimmenden Datennachweisen, erfolgreichen Clientanfragen, gesunder Laufzeit und tatsächlicher Telemetrie ab.

Seitlich wischen, um die ganze Tabelle zu sehen

Freigabepunkt	Erforderlicher Nachweis
Datenintegrität	Prüfsumme des Quellmanifests, erwartete Anzahl und Fingerprint stimmen mit dem wiederhergestellten Ziel überein; das Migrationsjournal benennt das richtige Projekt und die Datenbank
Laufzeit	Ursprüngliche Replikazahl wiederhergestellt, gesunder Rollout, keine unerklärten Neustarts oder Verbindungsfehler
Netzwerkverkehr	Gateway akzeptiert, HTTPRoute-Referenzen aufgelöst, DNS entspricht dem Gateway, tatsächliche Clientanfragen erreichen das beabsichtigte Ziel
Fachliches Verhalten	Migrierte Alben sichtbar und freigegebene Benutzerabläufe erfolgreich; Schreibtests besitzen einen vereinbarten Bereinigungs- und Abgleichplan
Datenbanktransport	Anwendung und Migration verlangen TLS; ACL erlaubt nur freigegebenes SKE-Egress oder explizit genehmigte Ausnahmen
Observability	Beide Scrape-Jobs liefern tatsächliche `up=1`-Messwerte, der Exporter meldet Datenbankzustand und Dashboard-Werte entsprechen dem Workload
Recovery	Backup vor dem Cutover, Prüfsumme, ursprünglicher Fingerprint und Journal privat aufbewahrt und in geschützten dauerhaften Speicher kopiert
Konfiguration	Geprüfter Plan nach der Migration ohne unerklärte Ressourcendrift; Betriebszustände von Quelle und Ziel dokumentiert

Ein erfolgreicher öffentlicher HTTP-Aufruf erfüllt allein keine produktive HTTPS-Anforderung. Das Beispiel-Dashboard ersetzt keine unabhängige fachliche, Latenzperzentil-, Fehlerraten- oder Recovery-Validierung.

Rollback-Kriterien und Schritte

Stellen Sie bei einem freigegebenen Auslöser das geschützte Ziel wieder her; gleichen Sie Schreibzugriffe nach dem Cutover ab und entscheiden Sie den Quell-Failback separat.

Rollback-Auslöser

Treffen Sie die vereinbarte Entscheidung vor der Deadline, wenn Dateninvarianten verletzt sind, ein kritischer fachlicher Ablauf nicht im Fehlerbehebungsfenster wiederhergestellt werden kann, Zielinstabilität die Abnahmegrenzen überschreitet oder keine vertrauenswürdige Telemetrie festgestellt werden kann. Bewahren Sie Migrationsjournal und Logs auf.

Rollback der Zieldatenbank

Clientschreibzugriffe stoppen oder isolieren und automatische Reconciliation pausiert lassen. Rollback-Befugnis und Zielidentität bestätigen.
Das geschützte Ziel vor dem Cutover mit dem ursprünglichen Nachweisverzeichnis wiederherstellen:

python3 scripts/migrate_postgres.py rollback \
  --evidence .tmp/migration-run --confirm-target springmusic

Validierung der Backup-Prüfsumme, einen separaten Dump des aktuellen Ziels vor dem Rollback und Übereinstimmung des ursprünglichen Datenfingerprints vor dem Neustart verlangen.
Gateway-Erreichbarkeit, Anwendungsverhalten und wiederhergestellten Zielzustand prüfen. Nicht annehmen, dass dieser Zustand die neuesten Quelldaten enthält.
Alle Schreibzugriffe nach dem Cutover im Dump vor dem Rollback für einen expliziten Abgleich bewahren. Sie werden nicht automatisch in die wiederhergestellten Daten übernommen.

Quell-Failback und unterbrochene Läufe

Die Rückkehr der Benutzer zur VM ist eine separate Entscheidung: Quellintegrität bestätigen, angenommene Zielschreibzugriffe abgleichen, Client-Traffic nach dem freigegebenen Verfahren umleiten und genau einer Seite Schreibzugriffe erlauben. Der Restore des Ziels vor dem Cutover allein führt diese Schritte nicht aus.

Schlägt der Cutover fehl, bevor ein gültiges Backup dokumentiert ist, prüfen Sie Journal und Datenbank gemeinsam mit den Datenbankverantwortlichen. Überschreiben Sie niemals das Nachweisverzeichnis und starten Sie den Cutover nicht blind erneut. Prüfen Sie nach einem beendeten Prozess verbliebene Pods mit Präfix springmusic-migration-* und das gestoppte Deployment, bevor Sie fortfahren. Die lokale Migrationssperre koordiniert keine unterschiedlichen Ausführungshosts.

Übergabe an den Betrieb

Übergeben Sie Konfiguration, Abnahmenachweise, Dashboards, Incident-Verantwortung und Entscheidungen zur Quellaufbewahrung.

Übergeben Sie den geprüften Konfigurationsstand, Workload- und Gateway-Inventar, Quellmanifest, Migrationsjournal, Backup-Orte, Abnahmeergebnisse, Dashboard-URL und Rollback-Entscheidung. Halten Sie Zugangsdaten aus dem Übergabedokument heraus und verweisen Sie auf den freigegebenen Secret-Speicher.

Vereinbaren Sie ein zum Workload passendes anfängliches Stabilisierungsfenster von 24 bis 72 Stunden. Benennen Sie Incident- und Datenbank-Recovery-Verantwortliche, bestätigen Sie Aufbewahrungs- und Restore-Verfahren und testen Sie Alarmzustellung, bevor Sie sich darauf verlassen. Flex-Backups ergänzen Migrationsdumps; ein verifizierter Dump-Rollback ist kein Nachweis für Managed-Service-Recovery.

Beenden Sie die Stabilisierung nur bei dauerhaft gesundem fachlichem Verhalten, vollständiger Telemetrie, ohne ungelöste kritische Probleme und mit Betriebsfreigabe. Nehmen Sie pausierte Automatisierung bewusst wieder auf. Bewahren Sie Quelldaten und geschützte Nachweise auf, bis die vereinbarten Aufbewahrungs- und Abgleichkriterien die Stilllegung erlauben. Beginnen Sie HPA- und Kapazitätsexperimente erst nach der Stabilisierung in einem separaten Änderungsfenster.

Vorlage für das Nachweisprotokoll

Seitlich wischen, um die ganze Tabelle zu sehen

Kontrollpunkt	Verantwortliche Rolle	Zeitstempel	Ergebnis	Nachweisreferenz
Ziel und Clientpfad bereit	Plattform-Engineering	JJJJ-MM-TT HH:MM	Bestanden/Fehlgeschlagen	Geschützter Eintrag
Quellschreibstopp und finaler Export	Anwendungs- und Datenbankverantwortliche	JJJJ-MM-TT HH:MM	Bestanden/Fehlgeschlagen	Manifest und Freigabe
Finale Probe abgenommen	Datenbankverantwortliche	JJJJ-MM-TT HH:MM	Bestanden/Fehlgeschlagen	Probejournal
Backup vor dem Cutover nachgewiesen	Datenbankverantwortliche	JJJJ-MM-TT HH:MM	Bestanden/Fehlgeschlagen	Backup-Prüfsumme und Restore-Ergebnis
Cutover und Integrität abgenommen	Datenbankverantwortliche	JJJJ-MM-TT HH:MM	Bestanden/Fehlgeschlagen	Migrationsjournal
Fachlichkeit und Netzwerkverkehr abgenommen	Anwendungsverantwortliche	JJJJ-MM-TT HH:MM	Bestanden/Fehlgeschlagen	Test- und Routing-Nachweise
Drift und Telemetrie geprüft	Plattform-Engineering	JJJJ-MM-TT HH:MM	Bestanden/Fehlgeschlagen	Plan- und Metriknachweise
Übergabe oder Rollback abgeschlossen	Migrationsleitung	JJJJ-MM-TT HH:MM	Bestanden/Fehlgeschlagen	Unterzeichnete Entscheidung

SAFE

Validieren oder zurückrollen

Anwendungsfall

Überführen Sie die Spring-Music-Anwendung von einer VM zu STACKIT Kubernetes Engine und ihre Daten von selbstverwaltetem PostgreSQL zu PostgreSQL Flex. Behalten Sie Anwendungs-JAR und fachliches Verhalten bei und führen Sie Kubernetes-Deployment, Gateway API, DNS und Managed Observability ein.

Dieses Runbook beschreibt die Freigaben und die betriebliche Reihenfolge rund um die Befehle von scripts/migrate_postgres.py im Referenzrepository. Infrastrukturbereitstellung und Datenbankaustausch sind getrennte Vorgänge. Ein erfolgreiches Terraform-Apply ist keine Migrationsabnahme.

Umfang und Annahmen

Die Referenz migriert das Schema public und validiert public.album anhand von Zeilenanzahl und deterministischem Fingerprint. Die getestete Eingabe ist das Rehost-Beispiel mit acht Alben, kein Export einer Live-Quelle. Ein realer Workload benötigt einen eigenen kompatiblen Export, eine Schemabewertung, fachliche Tests und Recovery-Ziele. Geben Sie Ausfallzeit frei: Dies ist eine Migration mit Schreibstopp und Dump/Restore, keine Replikation oder unterbrechungsfreie Umschaltung.

Das Ziel verwendet eine eigene Anwendungs- und Probedatenbank, Datenbankverbindungen mit TLS-Pflicht und einen temporären clusterinternen Migrationsclient. Das Skript stoppt weder Quellschreiber noch schaltet es Client-Traffic um, konfiguriert öffentliches TLS oder automatisiert den Failback zur Quelle. Diese Aufgaben liegen beim Betreiber.

Rollen und Verantwortlichkeiten

Seitlich wischen, um die ganze Tabelle zu sehen

Rolle	Verantwortete Entscheidung oder Nachweis
Migrationsleitung	Zeitfenster, Kontrollpunkte, Go/No-Go-Befugnis, Rollback-Deadline und Incident-Koordination
Anwendungsverantwortliche	Vollständige Erfassung der Schreiber, Quellschreibstopp, fachliche Abnahme und Abgleich von Schreibzugriffen nach dem Cutover
Plattform-Engineering	Freigegebener Terraform-Plan, SKE-Zugriff, Gateway- und DNS-Bereitschaft, pausierte Reconciliation
Datenbankverantwortliche	Konsistente Quellnachweise, Probe, geschütztes Backup, Restore-Integrität und Rollback-Ausführung
Betriebsverantwortliche	Telemetrie, Incident-Zuweisung, Recovery-Verantwortung, Aufbewahrung und Ende der Stabilisierung

Entscheidungs- und Freigabepunkte der Migration

Bereit zur Migration: Zieldesign, Zugriffsgrenzen, Ausfallzeit, Verantwortlichkeiten und messbare Abnahmekriterien vor Beginn des Fensters freigeben.
Bereit zum Cutover: Quellschreibzugriffe einfrieren und einen konsistenten finalen Dump mit passenden, aktuellen Probenachweisen verlangen. Infrastruktur-Bereitschaft allein erlaubt keinen Datenaustausch.
Geschützte Ausführung: Konkurrierende Schreiber und Reconciliation ausschließen, das Zielbackup vor dem Cutover nachweisen und den transaktionalen Restore vor dem Workload-Neustart validieren.
Abnehmen oder wiederherstellen: Übereinstimmende Daten, erfolgreiche fachliche Abläufe, funktionierenden Client-Traffic und tatsächliche Telemetrie verlangen. Rollback vor der Deadline entscheiden; Quell-Failback und Abgleich späterer Schreibzugriffe bleiben separate Entscheidungen.
Bereit für den Betrieb: Nachweise und Recovery-Verantwortung übergeben, den Workload stabilisieren und Automatisierung bewusst wieder aufnehmen. Kapazitäts- und HPA-Experimente gehören in ein späteres Änderungsfenster.

Diese Freigabepunkte erläutern das Kontrollmodell. Die folgenden Abschnitte liefern das ausführbare Verfahren und die Nachweisanforderungen für den technischen Walkthrough.

Prüfungen vor der Migration

Bestätigen Sie Schreibkontrolle, pausierte Reconciliation, Verantwortlichkeiten, Abnahmekriterien und Rollback-Deadline.

Quellbaseline: JAR-Prüfsumme, Java- und PostgreSQL-Versionen, Schemaabhängigkeiten, Datenmenge und Änderungsrate, geplante Jobs, Integrationen und Recovery-Ziele erfassen.
Quellnachweise: Vertrauenswürdigen Dump und Manifest aus einem konsistenten Snapshot validieren; Prüfsumme, erwartete Zeilenanzahl und Fingerprint dokumentieren. Den finalen Dump nach dem Schreibstopp proben.
Zielbereitschaft: Geprüftes Infrastruktur-Apply abschließen; SKE-Kapazität, Artefaktzugriff, Flex-Konnektivität und ACLs, Gateway-Zustände, DNS, Anwendungsantworten und beide Metrik-Jobs prüfen.
Zugriff und Sicherheit: Kubeconfig und Berechtigungen prüfen, State und Pläne schützen, Secrets und Nachweise einschränken sowie HTTP- und öffentliche Metrikgrenzen passend zur Datenklassifikation auflösen.
Schreibkontrolle: HPA und Lastgenerierung deaktivieren, weitere Zielschreiber stoppen sowie Terraform, GitOps und geplante Deployment-Jobs während der Migration pausieren. Das Ziel für genau einen Betreiberworkflow reservieren.
Recovery-Bereitschaft: Zielidentität, Nachweisort, geschützten Backup-Speicher außerhalb des Containers, Rollback-Befugnis, Deadline, Traffic-Umschaltung und Quellaufbewahrung vereinbaren.
Abnahme: Erlaubte Ausfallzeit, Dateninvarianten, fachliche Tests, Fehler- und Latenzgrenzen sowie Reaktion auf fehlende Telemetrie vor Beginn des Fensters festlegen.

Ablaufplan für das Cutover-Fenster

Phase 1: Quelle und Ziel vorbereiten

Freigegebenen Codestand, Variablendatei, Projekt, Cluster, Namespace und Zieldatenbank bestätigen.
Das Ziel über einen geprüften gespeicherten Terraform-Plan bereitstellen; fachfremden Ressourcenaustausch ablehnen.
bash scripts/validate_gateway.sh ausführen und Workload-Rollout sowie PostgreSQL-Konnektivität prüfen.
Quellnachweise und Ausgangsverhalten des Ziels erfassen. Ein Ziel mit Initialdaten ist kein abgenommenes migriertes Ziel.
enable_springboot_hpa = false, enable_load_generator = false und deploy_postgres_migration_job = false setzen; diese Einstellungen vor dem Pausieren der Infrastrukturautomatisierung anwenden.

Phase 2: Schreibzugriffe einfrieren und proben

Go/No-Go-Freigabe einholen und alle Quellschreiber einschließlich Integrationen und Hintergrundjobs einfrieren.
Finalen konsistenten Dump und Manifest über das freigegebene Quellverfahren exportieren.
Die Probe im Replatform-Repository mit dem freigegebenen Artefaktverzeichnis ausführen:

python3 scripts/migrate_postgres.py rehearse \
  --artifacts ../stackit-cmf-Rehost-springboot/artifacts \
  --evidence .tmp/migration-run

Übereinstimmende Prüfsumme, Zeilenanzahl, Fingerprint und Zielidentität verlangen; die unveränderte Anwendungsdatenbank bestätigen.
Bestätigen, dass die erfolgreiche Probe jünger als 24 Stunden und der finale Dump unverändert ist. Veraltete oder unpassende Nachweise ablehnen.

Phase 3: Cutover und Freigabe

Quellschreibstopp, Ausschluss weiterer Zielschreiber, pausierte Reconciliation, Entscheidungsfrist und verfügbaren Nachweisspeicher erneut bestätigen.
Den explizit bestätigten Cutover ausführen:

python3 scripts/migrate_postgres.py cutover \
  --artifacts ../stackit-cmf-Rehost-springboot/artifacts \
  --evidence .tmp/migration-run \
  --source-write-frozen --confirm-target springmusic

Verlangen, dass das Skript die Anwendungsreplikas stoppt, den Zieldump vor dem Cutover sichert und dessen Restore in der Probedatenbank vor dem Quellimport nachweist.
Erfolgreichen transaktionalen Quellrestore und Datenprüfungen verlangen, bevor das Skript die ursprüngliche Replikazahl wiederherstellt. Eine nach einem Fehler gestoppte Anwendung untersuchen; nicht mit Terraform übersteuern.
Technische und fachliche Validierung abschließen und anschließend den Client-Traffic nach dem freigegebenen Betreiberverfahren umschalten. Den neuen Clientpfad und den fortbestehenden Quellschreibstopp prüfen.
Abnahme und Schreibverantwortung dokumentieren. Nach Skriptende und korrekter Replikazahl einen Terraform-Plan auf Drift prüfen und eine reine Kubeconfig-Aktualisierung in Outputs erklären; während der Abnahme keine fachfremden Änderungen anwenden.

Validierungscheckliste

Nehmen Sie nur mit übereinstimmenden Datennachweisen, erfolgreichen Clientanfragen, gesunder Laufzeit und tatsächlicher Telemetrie ab.

Seitlich wischen, um die ganze Tabelle zu sehen

Freigabepunkt	Erforderlicher Nachweis
Datenintegrität	Prüfsumme des Quellmanifests, erwartete Anzahl und Fingerprint stimmen mit dem wiederhergestellten Ziel überein; das Migrationsjournal benennt das richtige Projekt und die Datenbank
Laufzeit	Ursprüngliche Replikazahl wiederhergestellt, gesunder Rollout, keine unerklärten Neustarts oder Verbindungsfehler
Netzwerkverkehr	Gateway akzeptiert, HTTPRoute-Referenzen aufgelöst, DNS entspricht dem Gateway, tatsächliche Clientanfragen erreichen das beabsichtigte Ziel
Fachliches Verhalten	Migrierte Alben sichtbar und freigegebene Benutzerabläufe erfolgreich; Schreibtests besitzen einen vereinbarten Bereinigungs- und Abgleichplan
Datenbanktransport	Anwendung und Migration verlangen TLS; ACL erlaubt nur freigegebenes SKE-Egress oder explizit genehmigte Ausnahmen
Observability	Beide Scrape-Jobs liefern tatsächliche `up=1`-Messwerte, der Exporter meldet Datenbankzustand und Dashboard-Werte entsprechen dem Workload
Recovery	Backup vor dem Cutover, Prüfsumme, ursprünglicher Fingerprint und Journal privat aufbewahrt und in geschützten dauerhaften Speicher kopiert
Konfiguration	Geprüfter Plan nach der Migration ohne unerklärte Ressourcendrift; Betriebszustände von Quelle und Ziel dokumentiert

Ein erfolgreicher öffentlicher HTTP-Aufruf erfüllt allein keine produktive HTTPS-Anforderung. Das Beispiel-Dashboard ersetzt keine unabhängige fachliche, Latenzperzentil-, Fehlerraten- oder Recovery-Validierung.

Rollback-Kriterien und Schritte

Stellen Sie bei einem freigegebenen Auslöser das geschützte Ziel wieder her; gleichen Sie Schreibzugriffe nach dem Cutover ab und entscheiden Sie den Quell-Failback separat.

Rollback-Auslöser

Treffen Sie die vereinbarte Entscheidung vor der Deadline, wenn Dateninvarianten verletzt sind, ein kritischer fachlicher Ablauf nicht im Fehlerbehebungsfenster wiederhergestellt werden kann, Zielinstabilität die Abnahmegrenzen überschreitet oder keine vertrauenswürdige Telemetrie festgestellt werden kann. Bewahren Sie Migrationsjournal und Logs auf.

Rollback der Zieldatenbank

Clientschreibzugriffe stoppen oder isolieren und automatische Reconciliation pausiert lassen. Rollback-Befugnis und Zielidentität bestätigen.
Das geschützte Ziel vor dem Cutover mit dem ursprünglichen Nachweisverzeichnis wiederherstellen:

python3 scripts/migrate_postgres.py rollback \
  --evidence .tmp/migration-run --confirm-target springmusic

Validierung der Backup-Prüfsumme, einen separaten Dump des aktuellen Ziels vor dem Rollback und Übereinstimmung des ursprünglichen Datenfingerprints vor dem Neustart verlangen.
Gateway-Erreichbarkeit, Anwendungsverhalten und wiederhergestellten Zielzustand prüfen. Nicht annehmen, dass dieser Zustand die neuesten Quelldaten enthält.
Alle Schreibzugriffe nach dem Cutover im Dump vor dem Rollback für einen expliziten Abgleich bewahren. Sie werden nicht automatisch in die wiederhergestellten Daten übernommen.

Quell-Failback und unterbrochene Läufe

Die Rückkehr der Benutzer zur VM ist eine separate Entscheidung: Quellintegrität bestätigen, angenommene Zielschreibzugriffe abgleichen, Client-Traffic nach dem freigegebenen Verfahren umleiten und genau einer Seite Schreibzugriffe erlauben. Der Restore des Ziels vor dem Cutover allein führt diese Schritte nicht aus.

Schlägt der Cutover fehl, bevor ein gültiges Backup dokumentiert ist, prüfen Sie Journal und Datenbank gemeinsam mit den Datenbankverantwortlichen. Überschreiben Sie niemals das Nachweisverzeichnis und starten Sie den Cutover nicht blind erneut. Prüfen Sie nach einem beendeten Prozess verbliebene Pods mit Präfix springmusic-migration-* und das gestoppte Deployment, bevor Sie fortfahren. Die lokale Migrationssperre koordiniert keine unterschiedlichen Ausführungshosts.

Übergabe an den Betrieb

Übergeben Sie Konfiguration, Abnahmenachweise, Dashboards, Incident-Verantwortung und Entscheidungen zur Quellaufbewahrung.

Übergeben Sie den geprüften Konfigurationsstand, Workload- und Gateway-Inventar, Quellmanifest, Migrationsjournal, Backup-Orte, Abnahmeergebnisse, Dashboard-URL und Rollback-Entscheidung. Halten Sie Zugangsdaten aus dem Übergabedokument heraus und verweisen Sie auf den freigegebenen Secret-Speicher.

Vereinbaren Sie ein zum Workload passendes anfängliches Stabilisierungsfenster von 24 bis 72 Stunden. Benennen Sie Incident- und Datenbank-Recovery-Verantwortliche, bestätigen Sie Aufbewahrungs- und Restore-Verfahren und testen Sie Alarmzustellung, bevor Sie sich darauf verlassen. Flex-Backups ergänzen Migrationsdumps; ein verifizierter Dump-Rollback ist kein Nachweis für Managed-Service-Recovery.

Beenden Sie die Stabilisierung nur bei dauerhaft gesundem fachlichem Verhalten, vollständiger Telemetrie, ohne ungelöste kritische Probleme und mit Betriebsfreigabe. Nehmen Sie pausierte Automatisierung bewusst wieder auf. Bewahren Sie Quelldaten und geschützte Nachweise auf, bis die vereinbarten Aufbewahrungs- und Abgleichkriterien die Stilllegung erlauben. Beginnen Sie HPA- und Kapazitätsexperimente erst nach der Stabilisierung in einem separaten Änderungsfenster.

Vorlage für das Nachweisprotokoll

Seitlich wischen, um die ganze Tabelle zu sehen

Kontrollpunkt	Verantwortliche Rolle	Zeitstempel	Ergebnis	Nachweisreferenz
Ziel und Clientpfad bereit	Plattform-Engineering	JJJJ-MM-TT HH:MM	Bestanden/Fehlgeschlagen	Geschützter Eintrag
Quellschreibstopp und finaler Export	Anwendungs- und Datenbankverantwortliche	JJJJ-MM-TT HH:MM	Bestanden/Fehlgeschlagen	Manifest und Freigabe
Finale Probe abgenommen	Datenbankverantwortliche	JJJJ-MM-TT HH:MM	Bestanden/Fehlgeschlagen	Probejournal
Backup vor dem Cutover nachgewiesen	Datenbankverantwortliche	JJJJ-MM-TT HH:MM	Bestanden/Fehlgeschlagen	Backup-Prüfsumme und Restore-Ergebnis
Cutover und Integrität abgenommen	Datenbankverantwortliche	JJJJ-MM-TT HH:MM	Bestanden/Fehlgeschlagen	Migrationsjournal
Fachlichkeit und Netzwerkverkehr abgenommen	Anwendungsverantwortliche	JJJJ-MM-TT HH:MM	Bestanden/Fehlgeschlagen	Test- und Routing-Nachweise
Drift und Telemetrie geprüft	Plattform-Engineering	JJJJ-MM-TT HH:MM	Bestanden/Fehlgeschlagen	Plan- und Metriknachweise
Übergabe oder Rollback abgeschlossen	Migrationsleitung	JJJJ-MM-TT HH:MM	Bestanden/Fehlgeschlagen	Unterzeichnete Entscheidung

Code & Registry github.com Ausführbarer Migrations- und Recovery-Workflow Das Referenzrepository liefert genaue Befehlsvoraussetzungen, Nachweisformate, Schutzmechanismen und Validierungsumfang. Repository öffnen

Anwendungsfall

Überführen Sie die Spring-Music-Anwendung von einer VM zu STACKIT Kubernetes Engine und ihre Daten von selbstverwaltetem PostgreSQL zu PostgreSQL Flex. Behalten Sie Anwendungs-JAR und fachliches Verhalten bei und führen Sie Kubernetes-Deployment, Gateway API, DNS und Managed Observability ein.

Dieses Runbook beschreibt die Freigaben und die betriebliche Reihenfolge rund um die Befehle von scripts/migrate_postgres.py im Referenzrepository. Infrastrukturbereitstellung und Datenbankaustausch sind getrennte Vorgänge. Ein erfolgreiches Terraform-Apply ist keine Migrationsabnahme.

Umfang und Annahmen

Die Referenz migriert das Schema public und validiert public.album anhand von Zeilenanzahl und deterministischem Fingerprint. Die getestete Eingabe ist das Rehost-Beispiel mit acht Alben, kein Export einer Live-Quelle. Ein realer Workload benötigt einen eigenen kompatiblen Export, eine Schemabewertung, fachliche Tests und Recovery-Ziele. Geben Sie Ausfallzeit frei: Dies ist eine Migration mit Schreibstopp und Dump/Restore, keine Replikation oder unterbrechungsfreie Umschaltung.

Das Ziel verwendet eine eigene Anwendungs- und Probedatenbank, Datenbankverbindungen mit TLS-Pflicht und einen temporären clusterinternen Migrationsclient. Das Skript stoppt weder Quellschreiber noch schaltet es Client-Traffic um, konfiguriert öffentliches TLS oder automatisiert den Failback zur Quelle. Diese Aufgaben liegen beim Betreiber.

Rollen und Verantwortlichkeiten

Seitlich wischen, um die ganze Tabelle zu sehen

Rolle	Verantwortete Entscheidung oder Nachweis
Migrationsleitung	Zeitfenster, Kontrollpunkte, Go/No-Go-Befugnis, Rollback-Deadline und Incident-Koordination
Anwendungsverantwortliche	Vollständige Erfassung der Schreiber, Quellschreibstopp, fachliche Abnahme und Abgleich von Schreibzugriffen nach dem Cutover
Plattform-Engineering	Freigegebener Terraform-Plan, SKE-Zugriff, Gateway- und DNS-Bereitschaft, pausierte Reconciliation
Datenbankverantwortliche	Konsistente Quellnachweise, Probe, geschütztes Backup, Restore-Integrität und Rollback-Ausführung
Betriebsverantwortliche	Telemetrie, Incident-Zuweisung, Recovery-Verantwortung, Aufbewahrung und Ende der Stabilisierung

Entscheidungs- und Freigabepunkte der Migration

Bereit zur Migration: Zieldesign, Zugriffsgrenzen, Ausfallzeit, Verantwortlichkeiten und messbare Abnahmekriterien vor Beginn des Fensters freigeben.
Bereit zum Cutover: Quellschreibzugriffe einfrieren und einen konsistenten finalen Dump mit passenden, aktuellen Probenachweisen verlangen. Infrastruktur-Bereitschaft allein erlaubt keinen Datenaustausch.
Geschützte Ausführung: Konkurrierende Schreiber und Reconciliation ausschließen, das Zielbackup vor dem Cutover nachweisen und den transaktionalen Restore vor dem Workload-Neustart validieren.
Abnehmen oder wiederherstellen: Übereinstimmende Daten, erfolgreiche fachliche Abläufe, funktionierenden Client-Traffic und tatsächliche Telemetrie verlangen. Rollback vor der Deadline entscheiden; Quell-Failback und Abgleich späterer Schreibzugriffe bleiben separate Entscheidungen.
Bereit für den Betrieb: Nachweise und Recovery-Verantwortung übergeben, den Workload stabilisieren und Automatisierung bewusst wieder aufnehmen. Kapazitäts- und HPA-Experimente gehören in ein späteres Änderungsfenster.

Diese Freigabepunkte erläutern das Kontrollmodell. Die folgenden Abschnitte liefern das ausführbare Verfahren und die Nachweisanforderungen für den technischen Walkthrough.

Prüfungen vor der Migration

Bestätigen Sie Schreibkontrolle, pausierte Reconciliation, Verantwortlichkeiten, Abnahmekriterien und Rollback-Deadline.

Quellbaseline: JAR-Prüfsumme, Java- und PostgreSQL-Versionen, Schemaabhängigkeiten, Datenmenge und Änderungsrate, geplante Jobs, Integrationen und Recovery-Ziele erfassen.
Quellnachweise: Vertrauenswürdigen Dump und Manifest aus einem konsistenten Snapshot validieren; Prüfsumme, erwartete Zeilenanzahl und Fingerprint dokumentieren. Den finalen Dump nach dem Schreibstopp proben.
Zielbereitschaft: Geprüftes Infrastruktur-Apply abschließen; SKE-Kapazität, Artefaktzugriff, Flex-Konnektivität und ACLs, Gateway-Zustände, DNS, Anwendungsantworten und beide Metrik-Jobs prüfen.
Zugriff und Sicherheit: Kubeconfig und Berechtigungen prüfen, State und Pläne schützen, Secrets und Nachweise einschränken sowie HTTP- und öffentliche Metrikgrenzen passend zur Datenklassifikation auflösen.
Schreibkontrolle: HPA und Lastgenerierung deaktivieren, weitere Zielschreiber stoppen sowie Terraform, GitOps und geplante Deployment-Jobs während der Migration pausieren. Das Ziel für genau einen Betreiberworkflow reservieren.
Recovery-Bereitschaft: Zielidentität, Nachweisort, geschützten Backup-Speicher außerhalb des Containers, Rollback-Befugnis, Deadline, Traffic-Umschaltung und Quellaufbewahrung vereinbaren.
Abnahme: Erlaubte Ausfallzeit, Dateninvarianten, fachliche Tests, Fehler- und Latenzgrenzen sowie Reaktion auf fehlende Telemetrie vor Beginn des Fensters festlegen.

Ablaufplan für das Cutover-Fenster

Phase 1: Quelle und Ziel vorbereiten

Freigegebenen Codestand, Variablendatei, Projekt, Cluster, Namespace und Zieldatenbank bestätigen.
Das Ziel über einen geprüften gespeicherten Terraform-Plan bereitstellen; fachfremden Ressourcenaustausch ablehnen.
bash scripts/validate_gateway.sh ausführen und Workload-Rollout sowie PostgreSQL-Konnektivität prüfen.
Quellnachweise und Ausgangsverhalten des Ziels erfassen. Ein Ziel mit Initialdaten ist kein abgenommenes migriertes Ziel.
enable_springboot_hpa = false, enable_load_generator = false und deploy_postgres_migration_job = false setzen; diese Einstellungen vor dem Pausieren der Infrastrukturautomatisierung anwenden.

Phase 2: Schreibzugriffe einfrieren und proben

Go/No-Go-Freigabe einholen und alle Quellschreiber einschließlich Integrationen und Hintergrundjobs einfrieren.
Finalen konsistenten Dump und Manifest über das freigegebene Quellverfahren exportieren.
Die Probe im Replatform-Repository mit dem freigegebenen Artefaktverzeichnis ausführen:

python3 scripts/migrate_postgres.py rehearse \
  --artifacts ../stackit-cmf-Rehost-springboot/artifacts \
  --evidence .tmp/migration-run

Übereinstimmende Prüfsumme, Zeilenanzahl, Fingerprint und Zielidentität verlangen; die unveränderte Anwendungsdatenbank bestätigen.
Bestätigen, dass die erfolgreiche Probe jünger als 24 Stunden und der finale Dump unverändert ist. Veraltete oder unpassende Nachweise ablehnen.

Phase 3: Cutover und Freigabe

Quellschreibstopp, Ausschluss weiterer Zielschreiber, pausierte Reconciliation, Entscheidungsfrist und verfügbaren Nachweisspeicher erneut bestätigen.
Den explizit bestätigten Cutover ausführen:

python3 scripts/migrate_postgres.py cutover \
  --artifacts ../stackit-cmf-Rehost-springboot/artifacts \
  --evidence .tmp/migration-run \
  --source-write-frozen --confirm-target springmusic

Verlangen, dass das Skript die Anwendungsreplikas stoppt, den Zieldump vor dem Cutover sichert und dessen Restore in der Probedatenbank vor dem Quellimport nachweist.
Erfolgreichen transaktionalen Quellrestore und Datenprüfungen verlangen, bevor das Skript die ursprüngliche Replikazahl wiederherstellt. Eine nach einem Fehler gestoppte Anwendung untersuchen; nicht mit Terraform übersteuern.
Technische und fachliche Validierung abschließen und anschließend den Client-Traffic nach dem freigegebenen Betreiberverfahren umschalten. Den neuen Clientpfad und den fortbestehenden Quellschreibstopp prüfen.
Abnahme und Schreibverantwortung dokumentieren. Nach Skriptende und korrekter Replikazahl einen Terraform-Plan auf Drift prüfen und eine reine Kubeconfig-Aktualisierung in Outputs erklären; während der Abnahme keine fachfremden Änderungen anwenden.

Validierungscheckliste

Nehmen Sie nur mit übereinstimmenden Datennachweisen, erfolgreichen Clientanfragen, gesunder Laufzeit und tatsächlicher Telemetrie ab.

Seitlich wischen, um die ganze Tabelle zu sehen

Freigabepunkt	Erforderlicher Nachweis
Datenintegrität	Prüfsumme des Quellmanifests, erwartete Anzahl und Fingerprint stimmen mit dem wiederhergestellten Ziel überein; das Migrationsjournal benennt das richtige Projekt und die Datenbank
Laufzeit	Ursprüngliche Replikazahl wiederhergestellt, gesunder Rollout, keine unerklärten Neustarts oder Verbindungsfehler
Netzwerkverkehr	Gateway akzeptiert, HTTPRoute-Referenzen aufgelöst, DNS entspricht dem Gateway, tatsächliche Clientanfragen erreichen das beabsichtigte Ziel
Fachliches Verhalten	Migrierte Alben sichtbar und freigegebene Benutzerabläufe erfolgreich; Schreibtests besitzen einen vereinbarten Bereinigungs- und Abgleichplan
Datenbanktransport	Anwendung und Migration verlangen TLS; ACL erlaubt nur freigegebenes SKE-Egress oder explizit genehmigte Ausnahmen
Observability	Beide Scrape-Jobs liefern tatsächliche `up=1`-Messwerte, der Exporter meldet Datenbankzustand und Dashboard-Werte entsprechen dem Workload
Recovery	Backup vor dem Cutover, Prüfsumme, ursprünglicher Fingerprint und Journal privat aufbewahrt und in geschützten dauerhaften Speicher kopiert
Konfiguration	Geprüfter Plan nach der Migration ohne unerklärte Ressourcendrift; Betriebszustände von Quelle und Ziel dokumentiert

Ein erfolgreicher öffentlicher HTTP-Aufruf erfüllt allein keine produktive HTTPS-Anforderung. Das Beispiel-Dashboard ersetzt keine unabhängige fachliche, Latenzperzentil-, Fehlerraten- oder Recovery-Validierung.

Rollback-Kriterien und Schritte

Stellen Sie bei einem freigegebenen Auslöser das geschützte Ziel wieder her; gleichen Sie Schreibzugriffe nach dem Cutover ab und entscheiden Sie den Quell-Failback separat.

Rollback-Auslöser

Treffen Sie die vereinbarte Entscheidung vor der Deadline, wenn Dateninvarianten verletzt sind, ein kritischer fachlicher Ablauf nicht im Fehlerbehebungsfenster wiederhergestellt werden kann, Zielinstabilität die Abnahmegrenzen überschreitet oder keine vertrauenswürdige Telemetrie festgestellt werden kann. Bewahren Sie Migrationsjournal und Logs auf.

Rollback der Zieldatenbank

Clientschreibzugriffe stoppen oder isolieren und automatische Reconciliation pausiert lassen. Rollback-Befugnis und Zielidentität bestätigen.
Das geschützte Ziel vor dem Cutover mit dem ursprünglichen Nachweisverzeichnis wiederherstellen:

python3 scripts/migrate_postgres.py rollback \
  --evidence .tmp/migration-run --confirm-target springmusic

Validierung der Backup-Prüfsumme, einen separaten Dump des aktuellen Ziels vor dem Rollback und Übereinstimmung des ursprünglichen Datenfingerprints vor dem Neustart verlangen.
Gateway-Erreichbarkeit, Anwendungsverhalten und wiederhergestellten Zielzustand prüfen. Nicht annehmen, dass dieser Zustand die neuesten Quelldaten enthält.
Alle Schreibzugriffe nach dem Cutover im Dump vor dem Rollback für einen expliziten Abgleich bewahren. Sie werden nicht automatisch in die wiederhergestellten Daten übernommen.

Quell-Failback und unterbrochene Läufe

Die Rückkehr der Benutzer zur VM ist eine separate Entscheidung: Quellintegrität bestätigen, angenommene Zielschreibzugriffe abgleichen, Client-Traffic nach dem freigegebenen Verfahren umleiten und genau einer Seite Schreibzugriffe erlauben. Der Restore des Ziels vor dem Cutover allein führt diese Schritte nicht aus.

Schlägt der Cutover fehl, bevor ein gültiges Backup dokumentiert ist, prüfen Sie Journal und Datenbank gemeinsam mit den Datenbankverantwortlichen. Überschreiben Sie niemals das Nachweisverzeichnis und starten Sie den Cutover nicht blind erneut. Prüfen Sie nach einem beendeten Prozess verbliebene Pods mit Präfix springmusic-migration-* und das gestoppte Deployment, bevor Sie fortfahren. Die lokale Migrationssperre koordiniert keine unterschiedlichen Ausführungshosts.

Übergabe an den Betrieb

Übergeben Sie Konfiguration, Abnahmenachweise, Dashboards, Incident-Verantwortung und Entscheidungen zur Quellaufbewahrung.

Übergeben Sie den geprüften Konfigurationsstand, Workload- und Gateway-Inventar, Quellmanifest, Migrationsjournal, Backup-Orte, Abnahmeergebnisse, Dashboard-URL und Rollback-Entscheidung. Halten Sie Zugangsdaten aus dem Übergabedokument heraus und verweisen Sie auf den freigegebenen Secret-Speicher.

Vereinbaren Sie ein zum Workload passendes anfängliches Stabilisierungsfenster von 24 bis 72 Stunden. Benennen Sie Incident- und Datenbank-Recovery-Verantwortliche, bestätigen Sie Aufbewahrungs- und Restore-Verfahren und testen Sie Alarmzustellung, bevor Sie sich darauf verlassen. Flex-Backups ergänzen Migrationsdumps; ein verifizierter Dump-Rollback ist kein Nachweis für Managed-Service-Recovery.

Beenden Sie die Stabilisierung nur bei dauerhaft gesundem fachlichem Verhalten, vollständiger Telemetrie, ohne ungelöste kritische Probleme und mit Betriebsfreigabe. Nehmen Sie pausierte Automatisierung bewusst wieder auf. Bewahren Sie Quelldaten und geschützte Nachweise auf, bis die vereinbarten Aufbewahrungs- und Abgleichkriterien die Stilllegung erlauben. Beginnen Sie HPA- und Kapazitätsexperimente erst nach der Stabilisierung in einem separaten Änderungsfenster.

Vorlage für das Nachweisprotokoll

Seitlich wischen, um die ganze Tabelle zu sehen

Kontrollpunkt	Verantwortliche Rolle	Zeitstempel	Ergebnis	Nachweisreferenz
Ziel und Clientpfad bereit	Plattform-Engineering	JJJJ-MM-TT HH:MM	Bestanden/Fehlgeschlagen	Geschützter Eintrag
Quellschreibstopp und finaler Export	Anwendungs- und Datenbankverantwortliche	JJJJ-MM-TT HH:MM	Bestanden/Fehlgeschlagen	Manifest und Freigabe
Finale Probe abgenommen	Datenbankverantwortliche	JJJJ-MM-TT HH:MM	Bestanden/Fehlgeschlagen	Probejournal
Backup vor dem Cutover nachgewiesen	Datenbankverantwortliche	JJJJ-MM-TT HH:MM	Bestanden/Fehlgeschlagen	Backup-Prüfsumme und Restore-Ergebnis
Cutover und Integrität abgenommen	Datenbankverantwortliche	JJJJ-MM-TT HH:MM	Bestanden/Fehlgeschlagen	Migrationsjournal
Fachlichkeit und Netzwerkverkehr abgenommen	Anwendungsverantwortliche	JJJJ-MM-TT HH:MM	Bestanden/Fehlgeschlagen	Test- und Routing-Nachweise
Drift und Telemetrie geprüft	Plattform-Engineering	JJJJ-MM-TT HH:MM	Bestanden/Fehlgeschlagen	Plan- und Metriknachweise
Übergabe oder Rollback abgeschlossen	Migrationsleitung	JJJJ-MM-TT HH:MM	Bestanden/Fehlgeschlagen	Unterzeichnete Entscheidung

Code & Registry github.com Ausführbarer Migrations- und Recovery-Workflow Das Referenzrepository liefert genaue Befehlsvoraussetzungen, Nachweisformate, Schutzmechanismen und Validierungsumfang. Repository öffnen

GOAL

Referenzimplementierung stabilisieren

Anwendungsfall

Überführen Sie die Spring-Music-Anwendung von einer VM zu STACKIT Kubernetes Engine und ihre Daten von selbstverwaltetem PostgreSQL zu PostgreSQL Flex. Behalten Sie Anwendungs-JAR und fachliches Verhalten bei und führen Sie Kubernetes-Deployment, Gateway API, DNS und Managed Observability ein.

Dieses Runbook beschreibt die Freigaben und die betriebliche Reihenfolge rund um die Befehle von scripts/migrate_postgres.py im Referenzrepository. Infrastrukturbereitstellung und Datenbankaustausch sind getrennte Vorgänge. Ein erfolgreiches Terraform-Apply ist keine Migrationsabnahme.

Umfang und Annahmen

Die Referenz migriert das Schema public und validiert public.album anhand von Zeilenanzahl und deterministischem Fingerprint. Die getestete Eingabe ist das Rehost-Beispiel mit acht Alben, kein Export einer Live-Quelle. Ein realer Workload benötigt einen eigenen kompatiblen Export, eine Schemabewertung, fachliche Tests und Recovery-Ziele. Geben Sie Ausfallzeit frei: Dies ist eine Migration mit Schreibstopp und Dump/Restore, keine Replikation oder unterbrechungsfreie Umschaltung.

Das Ziel verwendet eine eigene Anwendungs- und Probedatenbank, Datenbankverbindungen mit TLS-Pflicht und einen temporären clusterinternen Migrationsclient. Das Skript stoppt weder Quellschreiber noch schaltet es Client-Traffic um, konfiguriert öffentliches TLS oder automatisiert den Failback zur Quelle. Diese Aufgaben liegen beim Betreiber.

Rollen und Verantwortlichkeiten

Seitlich wischen, um die ganze Tabelle zu sehen

Rolle	Verantwortete Entscheidung oder Nachweis
Migrationsleitung	Zeitfenster, Kontrollpunkte, Go/No-Go-Befugnis, Rollback-Deadline und Incident-Koordination
Anwendungsverantwortliche	Vollständige Erfassung der Schreiber, Quellschreibstopp, fachliche Abnahme und Abgleich von Schreibzugriffen nach dem Cutover
Plattform-Engineering	Freigegebener Terraform-Plan, SKE-Zugriff, Gateway- und DNS-Bereitschaft, pausierte Reconciliation
Datenbankverantwortliche	Konsistente Quellnachweise, Probe, geschütztes Backup, Restore-Integrität und Rollback-Ausführung
Betriebsverantwortliche	Telemetrie, Incident-Zuweisung, Recovery-Verantwortung, Aufbewahrung und Ende der Stabilisierung

Entscheidungs- und Freigabepunkte der Migration

Bereit zur Migration: Zieldesign, Zugriffsgrenzen, Ausfallzeit, Verantwortlichkeiten und messbare Abnahmekriterien vor Beginn des Fensters freigeben.
Bereit zum Cutover: Quellschreibzugriffe einfrieren und einen konsistenten finalen Dump mit passenden, aktuellen Probenachweisen verlangen. Infrastruktur-Bereitschaft allein erlaubt keinen Datenaustausch.
Geschützte Ausführung: Konkurrierende Schreiber und Reconciliation ausschließen, das Zielbackup vor dem Cutover nachweisen und den transaktionalen Restore vor dem Workload-Neustart validieren.
Abnehmen oder wiederherstellen: Übereinstimmende Daten, erfolgreiche fachliche Abläufe, funktionierenden Client-Traffic und tatsächliche Telemetrie verlangen. Rollback vor der Deadline entscheiden; Quell-Failback und Abgleich späterer Schreibzugriffe bleiben separate Entscheidungen.
Bereit für den Betrieb: Nachweise und Recovery-Verantwortung übergeben, den Workload stabilisieren und Automatisierung bewusst wieder aufnehmen. Kapazitäts- und HPA-Experimente gehören in ein späteres Änderungsfenster.

Diese Freigabepunkte erläutern das Kontrollmodell. Die folgenden Abschnitte liefern das ausführbare Verfahren und die Nachweisanforderungen für den technischen Walkthrough.

Prüfungen vor der Migration

Bestätigen Sie Schreibkontrolle, pausierte Reconciliation, Verantwortlichkeiten, Abnahmekriterien und Rollback-Deadline.

Quellbaseline: JAR-Prüfsumme, Java- und PostgreSQL-Versionen, Schemaabhängigkeiten, Datenmenge und Änderungsrate, geplante Jobs, Integrationen und Recovery-Ziele erfassen.
Quellnachweise: Vertrauenswürdigen Dump und Manifest aus einem konsistenten Snapshot validieren; Prüfsumme, erwartete Zeilenanzahl und Fingerprint dokumentieren. Den finalen Dump nach dem Schreibstopp proben.
Zielbereitschaft: Geprüftes Infrastruktur-Apply abschließen; SKE-Kapazität, Artefaktzugriff, Flex-Konnektivität und ACLs, Gateway-Zustände, DNS, Anwendungsantworten und beide Metrik-Jobs prüfen.
Zugriff und Sicherheit: Kubeconfig und Berechtigungen prüfen, State und Pläne schützen, Secrets und Nachweise einschränken sowie HTTP- und öffentliche Metrikgrenzen passend zur Datenklassifikation auflösen.
Schreibkontrolle: HPA und Lastgenerierung deaktivieren, weitere Zielschreiber stoppen sowie Terraform, GitOps und geplante Deployment-Jobs während der Migration pausieren. Das Ziel für genau einen Betreiberworkflow reservieren.
Recovery-Bereitschaft: Zielidentität, Nachweisort, geschützten Backup-Speicher außerhalb des Containers, Rollback-Befugnis, Deadline, Traffic-Umschaltung und Quellaufbewahrung vereinbaren.
Abnahme: Erlaubte Ausfallzeit, Dateninvarianten, fachliche Tests, Fehler- und Latenzgrenzen sowie Reaktion auf fehlende Telemetrie vor Beginn des Fensters festlegen.

Ablaufplan für das Cutover-Fenster

Phase 1: Quelle und Ziel vorbereiten

Freigegebenen Codestand, Variablendatei, Projekt, Cluster, Namespace und Zieldatenbank bestätigen.
Das Ziel über einen geprüften gespeicherten Terraform-Plan bereitstellen; fachfremden Ressourcenaustausch ablehnen.
bash scripts/validate_gateway.sh ausführen und Workload-Rollout sowie PostgreSQL-Konnektivität prüfen.
Quellnachweise und Ausgangsverhalten des Ziels erfassen. Ein Ziel mit Initialdaten ist kein abgenommenes migriertes Ziel.
enable_springboot_hpa = false, enable_load_generator = false und deploy_postgres_migration_job = false setzen; diese Einstellungen vor dem Pausieren der Infrastrukturautomatisierung anwenden.

Phase 2: Schreibzugriffe einfrieren und proben

Go/No-Go-Freigabe einholen und alle Quellschreiber einschließlich Integrationen und Hintergrundjobs einfrieren.
Finalen konsistenten Dump und Manifest über das freigegebene Quellverfahren exportieren.
Die Probe im Replatform-Repository mit dem freigegebenen Artefaktverzeichnis ausführen:

python3 scripts/migrate_postgres.py rehearse \
  --artifacts ../stackit-cmf-Rehost-springboot/artifacts \
  --evidence .tmp/migration-run

Übereinstimmende Prüfsumme, Zeilenanzahl, Fingerprint und Zielidentität verlangen; die unveränderte Anwendungsdatenbank bestätigen.
Bestätigen, dass die erfolgreiche Probe jünger als 24 Stunden und der finale Dump unverändert ist. Veraltete oder unpassende Nachweise ablehnen.

Phase 3: Cutover und Freigabe

Quellschreibstopp, Ausschluss weiterer Zielschreiber, pausierte Reconciliation, Entscheidungsfrist und verfügbaren Nachweisspeicher erneut bestätigen.
Den explizit bestätigten Cutover ausführen:

python3 scripts/migrate_postgres.py cutover \
  --artifacts ../stackit-cmf-Rehost-springboot/artifacts \
  --evidence .tmp/migration-run \
  --source-write-frozen --confirm-target springmusic

Verlangen, dass das Skript die Anwendungsreplikas stoppt, den Zieldump vor dem Cutover sichert und dessen Restore in der Probedatenbank vor dem Quellimport nachweist.
Erfolgreichen transaktionalen Quellrestore und Datenprüfungen verlangen, bevor das Skript die ursprüngliche Replikazahl wiederherstellt. Eine nach einem Fehler gestoppte Anwendung untersuchen; nicht mit Terraform übersteuern.
Technische und fachliche Validierung abschließen und anschließend den Client-Traffic nach dem freigegebenen Betreiberverfahren umschalten. Den neuen Clientpfad und den fortbestehenden Quellschreibstopp prüfen.
Abnahme und Schreibverantwortung dokumentieren. Nach Skriptende und korrekter Replikazahl einen Terraform-Plan auf Drift prüfen und eine reine Kubeconfig-Aktualisierung in Outputs erklären; während der Abnahme keine fachfremden Änderungen anwenden.

Validierungscheckliste

Nehmen Sie nur mit übereinstimmenden Datennachweisen, erfolgreichen Clientanfragen, gesunder Laufzeit und tatsächlicher Telemetrie ab.

Seitlich wischen, um die ganze Tabelle zu sehen

Freigabepunkt	Erforderlicher Nachweis
Datenintegrität	Prüfsumme des Quellmanifests, erwartete Anzahl und Fingerprint stimmen mit dem wiederhergestellten Ziel überein; das Migrationsjournal benennt das richtige Projekt und die Datenbank
Laufzeit	Ursprüngliche Replikazahl wiederhergestellt, gesunder Rollout, keine unerklärten Neustarts oder Verbindungsfehler
Netzwerkverkehr	Gateway akzeptiert, HTTPRoute-Referenzen aufgelöst, DNS entspricht dem Gateway, tatsächliche Clientanfragen erreichen das beabsichtigte Ziel
Fachliches Verhalten	Migrierte Alben sichtbar und freigegebene Benutzerabläufe erfolgreich; Schreibtests besitzen einen vereinbarten Bereinigungs- und Abgleichplan
Datenbanktransport	Anwendung und Migration verlangen TLS; ACL erlaubt nur freigegebenes SKE-Egress oder explizit genehmigte Ausnahmen
Observability	Beide Scrape-Jobs liefern tatsächliche `up=1`-Messwerte, der Exporter meldet Datenbankzustand und Dashboard-Werte entsprechen dem Workload
Recovery	Backup vor dem Cutover, Prüfsumme, ursprünglicher Fingerprint und Journal privat aufbewahrt und in geschützten dauerhaften Speicher kopiert
Konfiguration	Geprüfter Plan nach der Migration ohne unerklärte Ressourcendrift; Betriebszustände von Quelle und Ziel dokumentiert

Ein erfolgreicher öffentlicher HTTP-Aufruf erfüllt allein keine produktive HTTPS-Anforderung. Das Beispiel-Dashboard ersetzt keine unabhängige fachliche, Latenzperzentil-, Fehlerraten- oder Recovery-Validierung.

Rollback-Kriterien und Schritte

Stellen Sie bei einem freigegebenen Auslöser das geschützte Ziel wieder her; gleichen Sie Schreibzugriffe nach dem Cutover ab und entscheiden Sie den Quell-Failback separat.

Rollback-Auslöser

Treffen Sie die vereinbarte Entscheidung vor der Deadline, wenn Dateninvarianten verletzt sind, ein kritischer fachlicher Ablauf nicht im Fehlerbehebungsfenster wiederhergestellt werden kann, Zielinstabilität die Abnahmegrenzen überschreitet oder keine vertrauenswürdige Telemetrie festgestellt werden kann. Bewahren Sie Migrationsjournal und Logs auf.

Rollback der Zieldatenbank

Clientschreibzugriffe stoppen oder isolieren und automatische Reconciliation pausiert lassen. Rollback-Befugnis und Zielidentität bestätigen.
Das geschützte Ziel vor dem Cutover mit dem ursprünglichen Nachweisverzeichnis wiederherstellen:

python3 scripts/migrate_postgres.py rollback \
  --evidence .tmp/migration-run --confirm-target springmusic

Validierung der Backup-Prüfsumme, einen separaten Dump des aktuellen Ziels vor dem Rollback und Übereinstimmung des ursprünglichen Datenfingerprints vor dem Neustart verlangen.
Gateway-Erreichbarkeit, Anwendungsverhalten und wiederhergestellten Zielzustand prüfen. Nicht annehmen, dass dieser Zustand die neuesten Quelldaten enthält.
Alle Schreibzugriffe nach dem Cutover im Dump vor dem Rollback für einen expliziten Abgleich bewahren. Sie werden nicht automatisch in die wiederhergestellten Daten übernommen.

Quell-Failback und unterbrochene Läufe

Die Rückkehr der Benutzer zur VM ist eine separate Entscheidung: Quellintegrität bestätigen, angenommene Zielschreibzugriffe abgleichen, Client-Traffic nach dem freigegebenen Verfahren umleiten und genau einer Seite Schreibzugriffe erlauben. Der Restore des Ziels vor dem Cutover allein führt diese Schritte nicht aus.

Schlägt der Cutover fehl, bevor ein gültiges Backup dokumentiert ist, prüfen Sie Journal und Datenbank gemeinsam mit den Datenbankverantwortlichen. Überschreiben Sie niemals das Nachweisverzeichnis und starten Sie den Cutover nicht blind erneut. Prüfen Sie nach einem beendeten Prozess verbliebene Pods mit Präfix springmusic-migration-* und das gestoppte Deployment, bevor Sie fortfahren. Die lokale Migrationssperre koordiniert keine unterschiedlichen Ausführungshosts.

Übergabe an den Betrieb

Übergeben Sie Konfiguration, Abnahmenachweise, Dashboards, Incident-Verantwortung und Entscheidungen zur Quellaufbewahrung.

Übergeben Sie den geprüften Konfigurationsstand, Workload- und Gateway-Inventar, Quellmanifest, Migrationsjournal, Backup-Orte, Abnahmeergebnisse, Dashboard-URL und Rollback-Entscheidung. Halten Sie Zugangsdaten aus dem Übergabedokument heraus und verweisen Sie auf den freigegebenen Secret-Speicher.

Vereinbaren Sie ein zum Workload passendes anfängliches Stabilisierungsfenster von 24 bis 72 Stunden. Benennen Sie Incident- und Datenbank-Recovery-Verantwortliche, bestätigen Sie Aufbewahrungs- und Restore-Verfahren und testen Sie Alarmzustellung, bevor Sie sich darauf verlassen. Flex-Backups ergänzen Migrationsdumps; ein verifizierter Dump-Rollback ist kein Nachweis für Managed-Service-Recovery.

Beenden Sie die Stabilisierung nur bei dauerhaft gesundem fachlichem Verhalten, vollständiger Telemetrie, ohne ungelöste kritische Probleme und mit Betriebsfreigabe. Nehmen Sie pausierte Automatisierung bewusst wieder auf. Bewahren Sie Quelldaten und geschützte Nachweise auf, bis die vereinbarten Aufbewahrungs- und Abgleichkriterien die Stilllegung erlauben. Beginnen Sie HPA- und Kapazitätsexperimente erst nach der Stabilisierung in einem separaten Änderungsfenster.

Vorlage für das Nachweisprotokoll

Seitlich wischen, um die ganze Tabelle zu sehen

Kontrollpunkt	Verantwortliche Rolle	Zeitstempel	Ergebnis	Nachweisreferenz
Ziel und Clientpfad bereit	Plattform-Engineering	JJJJ-MM-TT HH:MM	Bestanden/Fehlgeschlagen	Geschützter Eintrag
Quellschreibstopp und finaler Export	Anwendungs- und Datenbankverantwortliche	JJJJ-MM-TT HH:MM	Bestanden/Fehlgeschlagen	Manifest und Freigabe
Finale Probe abgenommen	Datenbankverantwortliche	JJJJ-MM-TT HH:MM	Bestanden/Fehlgeschlagen	Probejournal
Backup vor dem Cutover nachgewiesen	Datenbankverantwortliche	JJJJ-MM-TT HH:MM	Bestanden/Fehlgeschlagen	Backup-Prüfsumme und Restore-Ergebnis
Cutover und Integrität abgenommen	Datenbankverantwortliche	JJJJ-MM-TT HH:MM	Bestanden/Fehlgeschlagen	Migrationsjournal
Fachlichkeit und Netzwerkverkehr abgenommen	Anwendungsverantwortliche	JJJJ-MM-TT HH:MM	Bestanden/Fehlgeschlagen	Test- und Routing-Nachweise
Drift und Telemetrie geprüft	Plattform-Engineering	JJJJ-MM-TT HH:MM	Bestanden/Fehlgeschlagen	Plan- und Metriknachweise
Übergabe oder Rollback abgeschlossen	Migrationsleitung	JJJJ-MM-TT HH:MM	Bestanden/Fehlgeschlagen	Unterzeichnete Entscheidung

Code & Registry github.com Ausführbarer Migrations- und Recovery-Workflow Das Referenzrepository liefert genaue Befehlsvoraussetzungen, Nachweisformate, Schutzmechanismen und Validierungsumfang. Repository öffnen

Überblick

Dieses Asset wendet das Migration Framework auf ein Replatform von Spring Boot und PostgreSQL an: Die Anwendung wechselt vom VM-Service zu STACKIT Kubernetes Engine (SKE), die Datenbank von selbstverwaltetem PostgreSQL zu STACKIT PostgreSQL Flex. Geschäftsfunktion und Anwendungs-JAR bleiben unverändert; die Betriebsmodelle für Laufzeit und Datenbank ändern sich.

Referenzimplementierung

Das Referenzrepository ist die maßgebliche Quelle für Terraform, Helm-Charts, fest versionierte Artefakte, Migrationsskripte und Validierung. Verwenden Sie einen geprüften Stand mit den hier beschriebenen Gateway-API- und scripts/migrate_postgres.py-Workflows. Ein älterer Stand mit direktem Datenbank-Import-Job implementiert dieses Verfahren nicht.

Code & Registry github.com STACKIT Spring Boot Kubernetes Replatform Repository Terraform, Gateway API, PostgreSQL-Migration und Observability der in diesem Asset verwendeten Implementierung öffnen. Repository öffnen

Replatform-Scope in diesem Asset

Laufzeit: Dasselbe Spring-Music-JAR mit Spring Boot 2.4.0 läuft auf Java 11 in einem Kubernetes-Deployment statt unter systemd.
Daten: PostgreSQL Flex stellt getrennte Anwendungs- und Probedatenbanken bereit; JDBC- und Migrationsclients benötigen TLS.
Netzwerkverkehr: Envoy Gateway, Gateway API HTTPRoutes und SKE-verwaltetes ExternalDNS ersetzen den VM-Endpunkt.
Betrieb: Kubernetes-Zustands- und Ressourcenkontrollen ersetzen das Host-Service-Management; Managed Telemetry erfasst Cluster-, Anwendungs- und Datenbanksignale.
Migration: Quellnachweise, isolierte Probe, explizit freigegebener Cutover und verifizierter Datenbank-Rollback bleiben von der Infrastrukturbereitstellung getrennt.

Cloud Foundry, Object Storage, die Zerlegung in Microservices und Anwendungsmodernisierung sind nicht Teil dieser Implementierung. Die alte Beispielanwendung demonstriert einen Plattformwechsel; sie ist keine Empfehlung, einen nicht mehr unterstützten Anwendungsstack produktiv einzusetzen.

Architekturdiagramm der Referenz

Prüfen Sie das Architektur-Asset vor der Wahl von Kapazität und Netzwerkkontrollen. Es trennt die implementierte Topologie von Produktionserweiterungen wie öffentlichem HTTPS, hochverfügbaren Workern und geschützten Metriken.

Cloud Framework Spring Boot auf SKE mit PostgreSQL Flex und Gateway API Implementierte Topologie, Laufzeit- und Datengrenzen sowie separat zu qualifizierende Produktionserweiterungen prüfen. Seite öffnen

End-to-End-Ablauf

Replatform-Eignung, Quellkompatibilität, Landing-Zone-Bereitschaft und Verantwortlichkeiten bestätigen.
Einen vertrauenswürdigen PostgreSQL-Dump und ein Integritätsmanifest unabhängig vom Ziel vorbereiten.
Terraform für SKE, PostgreSQL Flex, Gateway, DNS, Workload und Observability prüfen und anwenden.
Das Ziel validieren und den finalen Quelldump in der isolierten Probedatenbank testen.
Quellschreibzugriffe einfrieren, Ausfallzeit freigeben und den kontrollierten Cutover mit geschütztem Zielbackup ausführen.
Anwendungs- und Datennachweise abnehmen oder den Zielzustand vor dem Cutover wiederherstellen; den Client-Traffic nach dem freigegebenen Betreiberverfahren umschalten.
Nachweise während der Stabilisierung aufbewahren und repräsentative Telemetrie für spätere Optimierung nutzen.

Arbeitsumgebung für den Walkthrough vorbereiten

Verwenden Sie eine isolierte Linux-Laborumgebung mit Git, Terraform, kubectl, curl, jq, getent, Python ab Version 3.11 sowie PostgreSQL-Server- und Client-Werkzeugen. Die Rehost-Beispielskripte benötigen außerdem runuser, sha256sum, ein Betriebssystemkonto postgres und Root-Rechte, um eine temporäre lokale Datenbank zu erstellen und zu prüfen. Führen Sie die Beispielbefehle in dieser vorbereiteten Laborumgebung aus, nicht auf einem produktiven Datenbankhost. Die privaten Artefakte müssen für den Migrationsbediener lesbar bleiben; machen Sie sie nicht für alle Benutzer lesbar.

Beziehen Sie geprüfte Commit-IDs beider Repositorys vom Referenz-Maintainer und exportieren Sie diese vorab als REHOST_REVISION und REPLATFORM_REVISION. Der Replatform-Stand muss Gateway API und den freigabegesteuerten Migrationsworkflow enthalten. Setzen Sie nicht voraus, dass der Remote-Standardbranch bereits die lokal getestete Implementierung enthält. Ist der freigegebene Stand nicht verfügbar, beschaffen Sie ihn vor dem Walkthrough.

Ersetzen Sie beide Platzhalter durch die freigegebenen vollständigen Commit-IDs mit jeweils 40 Zeichen und setzen Sie diese im selben Bash-Terminal:

export REHOST_REVISION="REPLACE_WITH_REVIEWED_REHOST_COMMIT_ID"
export REPLATFORM_REVISION="REPLACE_WITH_REVIEWED_REPLATFORM_COMMIT_ID"

Führen Sie den folgenden Block vollständig aus einem leeren Arbeitsverzeichnis aus. Die if-Prüfung lehnt fehlende, leere oder falsch formatierte IDs einschließlich unveränderter Platzhalter ab. Jedes && führt den nächsten Befehl nur nach Erfolg des vorherigen aus. Git prüft die Verfügbarkeit der Commits; die Formatprüfung allein bestätigt weder Freigabe noch Repository-Inhalt.

if [[ ! ${REHOST_REVISION:-} =~ ^[0-9a-fA-F]{40}$ ||
      ! ${REPLATFORM_REVISION:-} =~ ^[0-9a-fA-F]{40}$ ]]; then
  printf '%s\n' "Set both revision variables to reviewed full 40-character commit IDs." >&2
  false
else
  umask 077 &&
    git clone https://github.com/stackitcloud/stackit-cmf-Rehost-springboot.git &&
    git clone https://github.com/stackitcloud/stackit-cmf-replatform-springboot-k8s.git &&
    git -C stackit-cmf-Rehost-springboot checkout --detach "$REHOST_REVISION" &&
    git -C stackit-cmf-replatform-springboot-k8s checkout --detach "$REPLATFORM_REVISION" &&
    test -f stackit-cmf-replatform-springboot-k8s/scripts/migrate_postgres.py &&
    test -f stackit-cmf-replatform-springboot-k8s/scripts/validate_gateway.sh &&
    cd stackit-cmf-replatform-springboot-k8s &&
    printf '%s\n' "Workspace ready. Continue from this Replatform checkout." || {
      printf '%s\n' "Preparation failed. Resolve the error before continuing." >&2
      false
    }
fi

Fahren Sie erst nach der Meldung Workspace ready fort. Bei Fehlern bleibt das Terminal offen; weitere Vorbereitungsbefehle werden übersprungen. Vorhandene oder teilweise geklonte Verzeichnisse werden weder entfernt noch überschrieben: Prüfen Sie diese und bewahren Sie lokale Änderungen, bevor Sie es in einem neuen leeren Arbeitsverzeichnis erneut versuchen. Nach Erfolg befindet sich das Terminal für die nächsten Schritte im Replatform-Checkout.

Nutzen Sie ein freigegebenes STACKIT Projekt, einen Service Account, DNS-Delegation, SKE-Kapazität und ein geschütztes Terraform-Backend. Beziehen Sie Zugangsdaten über den freigegebenen Secret-Kanal, niemals aus diesem Trail. Die folgenden Befehle setzen diese Verzeichnisstruktur und eine geprüfte Konfiguration voraus; sie belegen keinen validierten Greenfield-Produktionsaufbau.

Quellnachweise vorbereiten

Qualifizieren Sie einen konsistenten Quelldump und sein Manifest, bevor Daten in den Migrationsworkflow eingehen.

Die Rehost-Referenz liefert scripts/create_source_dump.sh und scripts/validate_source_dump.sh für ihr reproduzierbares Beispiel. Führen Sie diese im Rehost-Repository aus. Dessen Verzeichnis artifacts liefert source-postgresql.dump und source-postgresql.manifest an den Replatform-Workflow. Das Manifest erfasst Version 1, table=public.album, row_count, album_fingerprint und dump_sha256.

Führen Sie ausschließlich für das reproduzierbare Beispiel die folgenden Befehle vom Replatform-Checkout in der vorbereiteten Laborumgebung aus. Die Skripte erstellen aus dem versionierten Beispiel-SQL eine temporäre PostgreSQL-Instanz, exportieren sie und führen einen unabhängigen Test-Restore aus. Verwenden Sie ein frisches Artefaktverzeichnis; überschreiben Sie keine Nachweise einer bereits laufenden Migration.

umask 077
pushd ../stackit-cmf-Rehost-springboot
bash scripts/create_source_dump.sh
bash scripts/validate_source_dump.sh
popd

Erwartet wird eine erfolgreiche Validierung von acht Zeilen mit passendem Fingerprint. Diese Befehle lesen keine Quell-VM aus. Verwenden Sie für Probe und Cutover genau diese Artefakte weiter.

Ersetzen Sie für eine reale Quelle den Beispielgenerator durch ein freigegebenes Exportverfahren: Frieren Sie alle Schreibzugriffe ein und leiten Sie Dump im Custom-Format und Manifest aus demselben konsistenten Quellsnapshot ab. Das generierte Beispiel mit acht Alben ist kein Export einer beliebigen laufenden VM. Prüfen Sie vor dem Export PostgreSQL-Kompatibilität, Erweiterungen, Eigentümerschaft und Schemaabhängigkeiten.

Stellen Sie nur vertrauenswürdige Dumps wieder her, da sie SQL ausführen. Diese Implementierung migriert das Anwendungsschema public und prüft public.album; von Flex verwaltete Schemas sind bewusst ausgeschlossen. Andere Workloads benötigen eigene Invarianten und einen angepassten Schemaumfang.

Code & Registry github.com Spring-Boot-Rehost-Quelle und Beispielexport Das Rehost-Repository liefert dasselbe Anwendungsartefakt und reproduzierbare Werkzeuge für PostgreSQL-Quellnachweise. Repository öffnen

Ziel bereitstellen

Stellen Sie das Ziel aus einem geprüften Plan mit expliziten Angaben zu Projekt, Kapazität, Zugriff und DNS bereit.

Verwenden Sie Terraform, kubectl, curl, jq, getent und Python ab Version 3.11 unter Linux. Kopieren Sie env.tfvars.example nach env.tfvars und passen Sie die tatsächlichen Variablen dieser Datei an. Behalten Sie die getestete Provider-Lockdatei und unveränderliche Image- und JAR-Referenzen bei. Bestätigen Sie vor dem Plan die Verfügbarkeit der SKE-Version, Node-Pool-Kapazität, Projektberechtigungen und DNS-Delegation.

Aus der STACKIT-DokuLifecycle of Kubernetes Engine › Kubernetes end-of-life datesStand der Quelle 24.08.2026 · übernommen 05.10.2026

Starting with Kubernetes v1.33, we remove minor versions on the patch day that precedes the upstream maintenance end-of-life (EOL) date. The following table below lists the upstream EOL date for each Kubernetes minor version and the corresponding expiration date in SKE:

Seitlich wischen, um die ganze Tabelle zu sehen

Kubernetes minor version	End-of-life date	Expiration in SKE
v1.32	2026-02-28	2026-04-15
v1.33	2026-06-28	2026-06-10
v1.34	2026-10-27	2026-10-14
v1.35	2027-02-28	2027-02-10

Please refer to the official Kubernetes Release History for up-to-date announcements of new versions.

Was ist das?

Dieser Abschnitt wird mehrmals am Tag automatisch aus der STACKIT-Doku übernommen. Hier lässt er sich nicht ändern. Änderungen gehören in die STACKIT-Doku.

Bevorzugen Sie ein freigegebenes Application-Landing-Zone-Projekt. Setzen Sie create_project = false und geben Sie Projekt-ID und Pfad zum Service-Account-Schlüssel an. Die alternative Projekterstellung setzt einen freigegebenen übergeordneten Container und Berechtigungen voraus; sie ersetzt keine Landing-Zone-Governance. Zugangsdaten, State, gespeicherte Pläne und Migrationsnachweise gehören nie in die Versionsverwaltung.

Erstellen Sie für einen neuen Checkout die private Variablendatei, ohne eine vorhandene zu überschreiben:

umask 077
test -e env.tfvars || cp env.tfvars.example env.tfvars
chmod 600 env.tfvars

Bearbeiten Sie diese Datei vor dem Plan: Tragen Sie freigegebenes Projekt und Service-Account-Pfad, Region, unterstützte SKE-Version, verfügbaren Node-Pool-Flavor samt Zone und delegierte DNS-Einstellungen aus dem Repository-Beispiel ein. Prüfen Sie Backend-Zugriff und Sperren, Quotas, Kosten sowie die Grenzen von HTTP und öffentlichen Metriken. Die folgenden Funktionsschalter bilden keine vollständige Umgebungskonfiguration.

Einheitliche Automatisierungs-Flags

Der optionale gemeinsame Wrapper bildet setup_project, setup_observability, setup_database, setup_workload, setup_loadgen und setup_dns auf die Terraform-Schalter des Repositorys ab. Sie wählen ausschließlich den Bereitstellungsumfang: Das Aktivieren der Datenbank erlaubt keinen Datenaustausch und ersetzt niemals die separate Migrationsfreigabe.

Minimale Zielkonfiguration

Diese Werte aktivieren den vollständigen Workload- und Datenbankpfad. Sie ergänzen die Angaben zu Projekt, Region, Node Pool und DNS im Repository-Beispiel, ersetzen sie aber nicht.

deploy_workload                   = true
dns_enabled                       = true
enable_postgres_flex              = true
postgres_flex_target_database     = "springmusic"
postgres_flex_target_app_acl_cidrs = []
observability_enabled             = true
create_observability_instance     = true
create_grafana_dashboard          = true
enable_springboot_hpa              = false
enable_load_generator             = false
deploy_postgres_migration_job      = false

Lassen Sie HPA und Lastgenerierung während der Migration deaktiviert. Wählen Sie Alarmeinstellungen bewusst; die Alarmzustellung wurde im End-to-End-Test nicht validiert. springboot_image wählt die Java-Laufzeit, nicht ein beliebiges vorgefertigtes Anwendungsimage. Der Init-Container lädt das auf einen Commit fixierte Rehost-JAR und prüft vor dem Start seinen SHA-256-Wert. Spiegeln Sie unveränderliche Artefakte für die Produktion in freigegebene Artefakt- und Image-Dienste.

Führen Sie die Befehle im Replatform-Repository aus und prüfen Sie den gespeicherten Plan vor dem Apply:

umask 077
terraform init
terraform validate
terraform plan -var-file=env.tfvars -out=tfplan
terraform apply tfplan
bash scripts/validate_gateway.sh

Zugriffskontrolle und temporäre ACL-Erweiterung für Migration

Bei leeren Anwendungs-ACL-Eingaben verwendet Terraform die tatsächlichen Egress-CIDRs des SKE-Clusters für PostgreSQL Flex. Explizite Anwendungs- oder ältere ACL-Werte überschreiben diesen Standard und müssen geprüft werden. Erlauben Sie nicht 0.0.0.0/0.

Der temporäre PostgreSQL-Client läuft in SKE und erhält den Dump über kubectl. Er verbindet sich nicht direkt mit der Quell-VM; weder Quell- noch Arbeitsplatz-CIDRs benötigen temporären Flex-Zugriff. JDBC und Datenbankwerkzeuge verwenden sslmode=require: Das erzwingt Verschlüsselung, bietet aber nicht die Hostnamenprüfung von verify-full. Schützen Sie Zugangsdaten in Kubernetes Secrets und im Terraform-Backend und validieren Sie bei Bedarf eine stärkere Zertifikatsprüfung.

Migration proben

Stellen Sie den finalen Dump in der isolierten Probedatenbank wieder her und verlangen Sie passende Nachweise, die jünger als 24 Stunden sind.

Führen Sie nach dem Infrastruktur-Apply einen isolierten Restore in springmusic_rehearsal aus. Passen Sie das Quellverzeichnis an die freigegebenen Artefakte an und halten Sie den Nachweispfad privat.

python3 scripts/migrate_postgres.py rehearse \
  --artifacts ../stackit-cmf-Rehost-springboot/artifacts \
  --evidence .tmp/migration-run

Die Probe validiert Manifest, Dump-Prüfsumme, Zielidentität, Zeilenanzahl und Fingerprint, ohne die Anwendungsdatenbank zu ersetzen. Proben Sie nach dem Schreibstopp auf der Quelle erneut mit dem finalen Dump. Der Cutover verlangt passende Nachweise, die jünger als 24 Stunden sind. Eine erfolgreiche Probe mit einem älteren oder anderen Dump gibt die finale Eingabe nicht frei.

Option: VM-PostgreSQL nach PostgreSQL Flex migrieren

Der alte Pfad deploy_postgres_migration_job = true wird durch die Validierung gesperrt. Nutzen Sie stattdessen den freigabegesteuerten Workflow. Stoppen Sie HPA, Lastgenerierung und alle anderen Zielschreiber. Pausieren Sie Terraform- und GitOps-Reconciliation, solange das Skript die Replikazahl steuert. Seine lokale Sperre schützt nur einen Checkout, nicht vor gleichzeitigen Bedienern auf unterschiedlichen Rechnern.

python3 scripts/migrate_postgres.py cutover \
  --artifacts ../stackit-cmf-Rehost-springboot/artifacts \
  --evidence .tmp/migration-run \
  --source-write-frozen --confirm-target springmusic

Das Quellschreibstopp-Flag ist eine Bestätigung des Betreibers, keine automatische Abschaltung der Quelle. Der Cutover skaliert die Anwendung auf null, sichert das Ziel vor dem Cutover und prüft die Sicherung per Prüfsumme. Er weist ihre Wiederherstellbarkeit in der Probedatenbank nach und stellt erst dann die Quelle transaktional wieder her. Vor dem Wiederanlauf mit ursprünglicher Replikazahl werden die Daten geprüft. Bei Fehlern bleibt die Anwendung zur Untersuchung gestoppt. Bewahren Sie Nachweisjournal und Backup auf; überschreiben Sie sie nicht für einen erneuten Versuch.

Validieren und zurückrollen

Vergleichen Sie Datenbanknachweise mit dem Quellmanifest, prüfen Sie das Anwendungsverhalten über das Gateway und bestätigen Sie den Zustand beider Metrik-Jobs. Traffic-Umschaltung und fachliche Abnahme bleiben Betreiberaufgaben; das Skript ändert den Endpunkt der Quellanwendung nicht.

So stellen Sie die geschützte Zieldatenbank aus der Zeit vor dem Cutover wieder her:

python3 scripts/migrate_postgres.py rollback \
  --evidence .tmp/migration-run --confirm-target springmusic

Der Rollback prüft Zielidentität und Backup-Integrität, sichert das aktuelle Ziel separat, stellt die ursprünglichen Daten wieder her und verifiziert vor dem Wiederanlauf deren Fingerprint. Schreibzugriffe nach dem Cutover werden nicht zusammengeführt; bewahren Sie den Dump vor dem Rollback für einen expliziten Abgleich auf. Dies ist ein Zieldatenbank-Rollback, kein automatischer Failback zur Quell-VM.

Datenbank-Metriken in Observability sichtbar machen

Terraform verwaltet den Grafana-Ordner SCF Replatform und das Dashboard mit acht Panels an der vorhandenen Datenquelle Thanos. Öffnen Sie es über grafana_dashboard_url. Cluster-CPU, Cluster-Speicher, laufende Pods, Anwendungsanfragen sowie PostgreSQL-Zustand und -Auslastung unterstützen Abnahme und spätere Optimierung. Ein manueller Dashboard-Import ist nicht nötig.

Anwendungsmetriken stammen aus dem pod-lokalen Boot-2-Actuator über den Metrikadapter auf Port 9090; der PostgreSQL-Exporter nutzt Port 9187. Prüfen Sie beide tatsächlichen Scrape-Ergebnisse, nicht nur die Dashboard-Darstellung. Fehlende Telemetrie ist ein Untersuchungsgrund, niemals der Nachweis fehlender Last.

Validierung mit kubectl

Exportieren Sie eine kurzlebige Kubeconfig mit privaten Berechtigungen und prüfen Sie den Standard-Namespace der Referenz:

umask 077
mkdir -p .tmp
terraform output -raw kubeconfig > .tmp/replatform.kubeconfig
export KUBECONFIG="$PWD/.tmp/replatform.kubeconfig"
kubectl get deploy,svc,pods -n springboot
kubectl get gateway,httproute -n springboot
kubectl rollout status deployment/springboot -n springboot
bash scripts/validate_gateway.sh

Der Gateway-Validator prüft Akzeptanz, aufgelöste Routenreferenzen, DNS und Anwendungsantwort. Entfernen Sie die lokale Kubeconfig nach Gebrauch und beziehen Sie nach Ablauf eine neue. Ein erfolgreicher Rollout allein ist keine Daten- oder fachliche Abnahme.

Grenze zwischen Backup und Recovery

Trennen Sie Migrations-Rollback von Flex-Service-Recovery und bewahren Sie geschützte Nachweise außerhalb kurzlebiger Ausführungsumgebungen auf.

Die Flex-Aufbewahrung wird explizit konfiguriert; der Standard dieser Referenz beträgt 32 Tage. Managed-Datenbankbackups und der Migrationsdump vor dem Cutover dienen unterschiedlichen Zwecken. Die Probe mit Letzterem weist weder Managed-Service-Restore noch Point-in-Time-Recovery oder Disaster Recovery der Anwendung nach. Benennen Sie Recovery-Verantwortliche und testen Sie den benötigten Service-Recovery-Pfad separat.

Bewahren Sie geschützte Nachweise und Backups bis zum Ende des Rollback-Fensters außerhalb eines kurzlebigen Dev Containers auf. Prüfen Sie nach einem abgebrochenen Migrationsprozess verbliebene Pods mit Präfix springmusic-migration-*, bevor Sie fortfahren; starten Sie ein ungeprüftes Ziel nicht durch Terraform neu.

Was dieses Asset zeigt

Dieses Asset zeigt, wie das Anwendungsverhalten beim Wechsel der Betriebsmodelle für Laufzeit und Datenbank erhalten bleibt:

Plattformwechsel: Dasselbe Spring-Boot-JAR auf SKE betreiben, über TLS mit PostgreSQL Flex verbinden und über Gateway API und DNS erreichbar machen.
Kontrollierte Datenmigration: Quelldump und Manifest qualifizieren, einen isolierten Restore proben und vor dem Cutover eine explizite Freigabe sowie ein verifiziertes Zielbackup verlangen. Bei erforderlichem Rollback den Zielzustand vor dem Cutover wiederherstellen.
Unabhängige Validierung: Datenintegrität, Anwendungsantworten, Gateway- und DNS-Bereitschaft sowie tatsächliche Scrape-Ergebnisse prüfen. Den Terraform-Plan auf unerklärte Drift prüfen, statt erfolgreiche Bereitstellung als Migrationsabnahme zu behandeln.
Wiederholbare Observability: Observability-Integration und Grafana-Dashboard mit acht Panels durch Terraform verwalten. Anwendungs- und Datenbanksignale für Abnahme, Stabilisierung und spätere Optimierung nutzen.

Nicht abgedeckt

Diese Nachweise bestätigen weder einen vollständigen Greenfield-Durchlauf noch eine Migration aus einer produktiven Live-Quelle, unterbrechungsfreien Betrieb, Hochverfügbarkeit, öffentliches Gateway-TLS, interaktiven IDP-Login, Alarmzustellung oder Managed-Flex-Recovery. Der getestete Ein-Worker-Aufbau mit HTTP stellt Metriken ohne Authentifizierung bereit; erfüllen Sie die Produktionsanforderungen vor der Verwendung sensibler Daten. Aktualisieren Sie die Beispielanwendung und validieren Sie eine geeignete unterstützte Kubernetes-Version als separate kontrollierte Änderungen.

Code & Registry github.com Referenzkonfiguration, Skripte und Validierungsnachweise Das Repository-README und die versionierte Implementierung liefern genaue Voraussetzungen, Variablen, Befehle und Recovery-Grenzen. Repository öffnen

OPS

Nachgewiesene Ergebnisse und offene Grenzen

Überblick

Dieses Asset wendet das Migration Framework auf ein Replatform von Spring Boot und PostgreSQL an: Die Anwendung wechselt vom VM-Service zu STACKIT Kubernetes Engine (SKE), die Datenbank von selbstverwaltetem PostgreSQL zu STACKIT PostgreSQL Flex. Geschäftsfunktion und Anwendungs-JAR bleiben unverändert; die Betriebsmodelle für Laufzeit und Datenbank ändern sich.

Referenzimplementierung

Das Referenzrepository ist die maßgebliche Quelle für Terraform, Helm-Charts, fest versionierte Artefakte, Migrationsskripte und Validierung. Verwenden Sie einen geprüften Stand mit den hier beschriebenen Gateway-API- und scripts/migrate_postgres.py-Workflows. Ein älterer Stand mit direktem Datenbank-Import-Job implementiert dieses Verfahren nicht.

Code & Registry github.com STACKIT Spring Boot Kubernetes Replatform Repository Terraform, Gateway API, PostgreSQL-Migration und Observability der in diesem Asset verwendeten Implementierung öffnen. Repository öffnen

Replatform-Scope in diesem Asset

Laufzeit: Dasselbe Spring-Music-JAR mit Spring Boot 2.4.0 läuft auf Java 11 in einem Kubernetes-Deployment statt unter systemd.
Daten: PostgreSQL Flex stellt getrennte Anwendungs- und Probedatenbanken bereit; JDBC- und Migrationsclients benötigen TLS.
Netzwerkverkehr: Envoy Gateway, Gateway API HTTPRoutes und SKE-verwaltetes ExternalDNS ersetzen den VM-Endpunkt.
Betrieb: Kubernetes-Zustands- und Ressourcenkontrollen ersetzen das Host-Service-Management; Managed Telemetry erfasst Cluster-, Anwendungs- und Datenbanksignale.
Migration: Quellnachweise, isolierte Probe, explizit freigegebener Cutover und verifizierter Datenbank-Rollback bleiben von der Infrastrukturbereitstellung getrennt.

Cloud Foundry, Object Storage, die Zerlegung in Microservices und Anwendungsmodernisierung sind nicht Teil dieser Implementierung. Die alte Beispielanwendung demonstriert einen Plattformwechsel; sie ist keine Empfehlung, einen nicht mehr unterstützten Anwendungsstack produktiv einzusetzen.

Architekturdiagramm der Referenz

Prüfen Sie das Architektur-Asset vor der Wahl von Kapazität und Netzwerkkontrollen. Es trennt die implementierte Topologie von Produktionserweiterungen wie öffentlichem HTTPS, hochverfügbaren Workern und geschützten Metriken.

Cloud Framework Spring Boot auf SKE mit PostgreSQL Flex und Gateway API Implementierte Topologie, Laufzeit- und Datengrenzen sowie separat zu qualifizierende Produktionserweiterungen prüfen. Seite öffnen

End-to-End-Ablauf

Replatform-Eignung, Quellkompatibilität, Landing-Zone-Bereitschaft und Verantwortlichkeiten bestätigen.
Einen vertrauenswürdigen PostgreSQL-Dump und ein Integritätsmanifest unabhängig vom Ziel vorbereiten.
Terraform für SKE, PostgreSQL Flex, Gateway, DNS, Workload und Observability prüfen und anwenden.
Das Ziel validieren und den finalen Quelldump in der isolierten Probedatenbank testen.
Quellschreibzugriffe einfrieren, Ausfallzeit freigeben und den kontrollierten Cutover mit geschütztem Zielbackup ausführen.
Anwendungs- und Datennachweise abnehmen oder den Zielzustand vor dem Cutover wiederherstellen; den Client-Traffic nach dem freigegebenen Betreiberverfahren umschalten.
Nachweise während der Stabilisierung aufbewahren und repräsentative Telemetrie für spätere Optimierung nutzen.

Arbeitsumgebung für den Walkthrough vorbereiten

Verwenden Sie eine isolierte Linux-Laborumgebung mit Git, Terraform, kubectl, curl, jq, getent, Python ab Version 3.11 sowie PostgreSQL-Server- und Client-Werkzeugen. Die Rehost-Beispielskripte benötigen außerdem runuser, sha256sum, ein Betriebssystemkonto postgres und Root-Rechte, um eine temporäre lokale Datenbank zu erstellen und zu prüfen. Führen Sie die Beispielbefehle in dieser vorbereiteten Laborumgebung aus, nicht auf einem produktiven Datenbankhost. Die privaten Artefakte müssen für den Migrationsbediener lesbar bleiben; machen Sie sie nicht für alle Benutzer lesbar.

Beziehen Sie geprüfte Commit-IDs beider Repositorys vom Referenz-Maintainer und exportieren Sie diese vorab als REHOST_REVISION und REPLATFORM_REVISION. Der Replatform-Stand muss Gateway API und den freigabegesteuerten Migrationsworkflow enthalten. Setzen Sie nicht voraus, dass der Remote-Standardbranch bereits die lokal getestete Implementierung enthält. Ist der freigegebene Stand nicht verfügbar, beschaffen Sie ihn vor dem Walkthrough.

Ersetzen Sie beide Platzhalter durch die freigegebenen vollständigen Commit-IDs mit jeweils 40 Zeichen und setzen Sie diese im selben Bash-Terminal:

export REHOST_REVISION="REPLACE_WITH_REVIEWED_REHOST_COMMIT_ID"
export REPLATFORM_REVISION="REPLACE_WITH_REVIEWED_REPLATFORM_COMMIT_ID"

Führen Sie den folgenden Block vollständig aus einem leeren Arbeitsverzeichnis aus. Die if-Prüfung lehnt fehlende, leere oder falsch formatierte IDs einschließlich unveränderter Platzhalter ab. Jedes && führt den nächsten Befehl nur nach Erfolg des vorherigen aus. Git prüft die Verfügbarkeit der Commits; die Formatprüfung allein bestätigt weder Freigabe noch Repository-Inhalt.

if [[ ! ${REHOST_REVISION:-} =~ ^[0-9a-fA-F]{40}$ ||
      ! ${REPLATFORM_REVISION:-} =~ ^[0-9a-fA-F]{40}$ ]]; then
  printf '%s\n' "Set both revision variables to reviewed full 40-character commit IDs." >&2
  false
else
  umask 077 &&
    git clone https://github.com/stackitcloud/stackit-cmf-Rehost-springboot.git &&
    git clone https://github.com/stackitcloud/stackit-cmf-replatform-springboot-k8s.git &&
    git -C stackit-cmf-Rehost-springboot checkout --detach "$REHOST_REVISION" &&
    git -C stackit-cmf-replatform-springboot-k8s checkout --detach "$REPLATFORM_REVISION" &&
    test -f stackit-cmf-replatform-springboot-k8s/scripts/migrate_postgres.py &&
    test -f stackit-cmf-replatform-springboot-k8s/scripts/validate_gateway.sh &&
    cd stackit-cmf-replatform-springboot-k8s &&
    printf '%s\n' "Workspace ready. Continue from this Replatform checkout." || {
      printf '%s\n' "Preparation failed. Resolve the error before continuing." >&2
      false
    }
fi

Fahren Sie erst nach der Meldung Workspace ready fort. Bei Fehlern bleibt das Terminal offen; weitere Vorbereitungsbefehle werden übersprungen. Vorhandene oder teilweise geklonte Verzeichnisse werden weder entfernt noch überschrieben: Prüfen Sie diese und bewahren Sie lokale Änderungen, bevor Sie es in einem neuen leeren Arbeitsverzeichnis erneut versuchen. Nach Erfolg befindet sich das Terminal für die nächsten Schritte im Replatform-Checkout.

Nutzen Sie ein freigegebenes STACKIT Projekt, einen Service Account, DNS-Delegation, SKE-Kapazität und ein geschütztes Terraform-Backend. Beziehen Sie Zugangsdaten über den freigegebenen Secret-Kanal, niemals aus diesem Trail. Die folgenden Befehle setzen diese Verzeichnisstruktur und eine geprüfte Konfiguration voraus; sie belegen keinen validierten Greenfield-Produktionsaufbau.

Quellnachweise vorbereiten

Qualifizieren Sie einen konsistenten Quelldump und sein Manifest, bevor Daten in den Migrationsworkflow eingehen.

Die Rehost-Referenz liefert scripts/create_source_dump.sh und scripts/validate_source_dump.sh für ihr reproduzierbares Beispiel. Führen Sie diese im Rehost-Repository aus. Dessen Verzeichnis artifacts liefert source-postgresql.dump und source-postgresql.manifest an den Replatform-Workflow. Das Manifest erfasst Version 1, table=public.album, row_count, album_fingerprint und dump_sha256.

Führen Sie ausschließlich für das reproduzierbare Beispiel die folgenden Befehle vom Replatform-Checkout in der vorbereiteten Laborumgebung aus. Die Skripte erstellen aus dem versionierten Beispiel-SQL eine temporäre PostgreSQL-Instanz, exportieren sie und führen einen unabhängigen Test-Restore aus. Verwenden Sie ein frisches Artefaktverzeichnis; überschreiben Sie keine Nachweise einer bereits laufenden Migration.

umask 077
pushd ../stackit-cmf-Rehost-springboot
bash scripts/create_source_dump.sh
bash scripts/validate_source_dump.sh
popd

Erwartet wird eine erfolgreiche Validierung von acht Zeilen mit passendem Fingerprint. Diese Befehle lesen keine Quell-VM aus. Verwenden Sie für Probe und Cutover genau diese Artefakte weiter.

Ersetzen Sie für eine reale Quelle den Beispielgenerator durch ein freigegebenes Exportverfahren: Frieren Sie alle Schreibzugriffe ein und leiten Sie Dump im Custom-Format und Manifest aus demselben konsistenten Quellsnapshot ab. Das generierte Beispiel mit acht Alben ist kein Export einer beliebigen laufenden VM. Prüfen Sie vor dem Export PostgreSQL-Kompatibilität, Erweiterungen, Eigentümerschaft und Schemaabhängigkeiten.

Stellen Sie nur vertrauenswürdige Dumps wieder her, da sie SQL ausführen. Diese Implementierung migriert das Anwendungsschema public und prüft public.album; von Flex verwaltete Schemas sind bewusst ausgeschlossen. Andere Workloads benötigen eigene Invarianten und einen angepassten Schemaumfang.

Code & Registry github.com Spring-Boot-Rehost-Quelle und Beispielexport Das Rehost-Repository liefert dasselbe Anwendungsartefakt und reproduzierbare Werkzeuge für PostgreSQL-Quellnachweise. Repository öffnen

Ziel bereitstellen

Stellen Sie das Ziel aus einem geprüften Plan mit expliziten Angaben zu Projekt, Kapazität, Zugriff und DNS bereit.

Verwenden Sie Terraform, kubectl, curl, jq, getent und Python ab Version 3.11 unter Linux. Kopieren Sie env.tfvars.example nach env.tfvars und passen Sie die tatsächlichen Variablen dieser Datei an. Behalten Sie die getestete Provider-Lockdatei und unveränderliche Image- und JAR-Referenzen bei. Bestätigen Sie vor dem Plan die Verfügbarkeit der SKE-Version, Node-Pool-Kapazität, Projektberechtigungen und DNS-Delegation.

Aus der STACKIT-DokuLifecycle of Kubernetes Engine › Kubernetes end-of-life datesStand der Quelle 24.08.2026 · übernommen 05.10.2026

Starting with Kubernetes v1.33, we remove minor versions on the patch day that precedes the upstream maintenance end-of-life (EOL) date. The following table below lists the upstream EOL date for each Kubernetes minor version and the corresponding expiration date in SKE:

Seitlich wischen, um die ganze Tabelle zu sehen

Kubernetes minor version	End-of-life date	Expiration in SKE
v1.32	2026-02-28	2026-04-15
v1.33	2026-06-28	2026-06-10
v1.34	2026-10-27	2026-10-14
v1.35	2027-02-28	2027-02-10

Please refer to the official Kubernetes Release History for up-to-date announcements of new versions.

Was ist das?

Dieser Abschnitt wird mehrmals am Tag automatisch aus der STACKIT-Doku übernommen. Hier lässt er sich nicht ändern. Änderungen gehören in die STACKIT-Doku.

Bevorzugen Sie ein freigegebenes Application-Landing-Zone-Projekt. Setzen Sie create_project = false und geben Sie Projekt-ID und Pfad zum Service-Account-Schlüssel an. Die alternative Projekterstellung setzt einen freigegebenen übergeordneten Container und Berechtigungen voraus; sie ersetzt keine Landing-Zone-Governance. Zugangsdaten, State, gespeicherte Pläne und Migrationsnachweise gehören nie in die Versionsverwaltung.

Erstellen Sie für einen neuen Checkout die private Variablendatei, ohne eine vorhandene zu überschreiben:

umask 077
test -e env.tfvars || cp env.tfvars.example env.tfvars
chmod 600 env.tfvars

Bearbeiten Sie diese Datei vor dem Plan: Tragen Sie freigegebenes Projekt und Service-Account-Pfad, Region, unterstützte SKE-Version, verfügbaren Node-Pool-Flavor samt Zone und delegierte DNS-Einstellungen aus dem Repository-Beispiel ein. Prüfen Sie Backend-Zugriff und Sperren, Quotas, Kosten sowie die Grenzen von HTTP und öffentlichen Metriken. Die folgenden Funktionsschalter bilden keine vollständige Umgebungskonfiguration.

Einheitliche Automatisierungs-Flags

Der optionale gemeinsame Wrapper bildet setup_project, setup_observability, setup_database, setup_workload, setup_loadgen und setup_dns auf die Terraform-Schalter des Repositorys ab. Sie wählen ausschließlich den Bereitstellungsumfang: Das Aktivieren der Datenbank erlaubt keinen Datenaustausch und ersetzt niemals die separate Migrationsfreigabe.

Minimale Zielkonfiguration

Diese Werte aktivieren den vollständigen Workload- und Datenbankpfad. Sie ergänzen die Angaben zu Projekt, Region, Node Pool und DNS im Repository-Beispiel, ersetzen sie aber nicht.

deploy_workload                   = true
dns_enabled                       = true
enable_postgres_flex              = true
postgres_flex_target_database     = "springmusic"
postgres_flex_target_app_acl_cidrs = []
observability_enabled             = true
create_observability_instance     = true
create_grafana_dashboard          = true
enable_springboot_hpa              = false
enable_load_generator             = false
deploy_postgres_migration_job      = false

Lassen Sie HPA und Lastgenerierung während der Migration deaktiviert. Wählen Sie Alarmeinstellungen bewusst; die Alarmzustellung wurde im End-to-End-Test nicht validiert. springboot_image wählt die Java-Laufzeit, nicht ein beliebiges vorgefertigtes Anwendungsimage. Der Init-Container lädt das auf einen Commit fixierte Rehost-JAR und prüft vor dem Start seinen SHA-256-Wert. Spiegeln Sie unveränderliche Artefakte für die Produktion in freigegebene Artefakt- und Image-Dienste.

Führen Sie die Befehle im Replatform-Repository aus und prüfen Sie den gespeicherten Plan vor dem Apply:

umask 077
terraform init
terraform validate
terraform plan -var-file=env.tfvars -out=tfplan
terraform apply tfplan
bash scripts/validate_gateway.sh

Zugriffskontrolle und temporäre ACL-Erweiterung für Migration

Bei leeren Anwendungs-ACL-Eingaben verwendet Terraform die tatsächlichen Egress-CIDRs des SKE-Clusters für PostgreSQL Flex. Explizite Anwendungs- oder ältere ACL-Werte überschreiben diesen Standard und müssen geprüft werden. Erlauben Sie nicht 0.0.0.0/0.

Der temporäre PostgreSQL-Client läuft in SKE und erhält den Dump über kubectl. Er verbindet sich nicht direkt mit der Quell-VM; weder Quell- noch Arbeitsplatz-CIDRs benötigen temporären Flex-Zugriff. JDBC und Datenbankwerkzeuge verwenden sslmode=require: Das erzwingt Verschlüsselung, bietet aber nicht die Hostnamenprüfung von verify-full. Schützen Sie Zugangsdaten in Kubernetes Secrets und im Terraform-Backend und validieren Sie bei Bedarf eine stärkere Zertifikatsprüfung.

Migration proben

Stellen Sie den finalen Dump in der isolierten Probedatenbank wieder her und verlangen Sie passende Nachweise, die jünger als 24 Stunden sind.

Führen Sie nach dem Infrastruktur-Apply einen isolierten Restore in springmusic_rehearsal aus. Passen Sie das Quellverzeichnis an die freigegebenen Artefakte an und halten Sie den Nachweispfad privat.

python3 scripts/migrate_postgres.py rehearse \
  --artifacts ../stackit-cmf-Rehost-springboot/artifacts \
  --evidence .tmp/migration-run

Die Probe validiert Manifest, Dump-Prüfsumme, Zielidentität, Zeilenanzahl und Fingerprint, ohne die Anwendungsdatenbank zu ersetzen. Proben Sie nach dem Schreibstopp auf der Quelle erneut mit dem finalen Dump. Der Cutover verlangt passende Nachweise, die jünger als 24 Stunden sind. Eine erfolgreiche Probe mit einem älteren oder anderen Dump gibt die finale Eingabe nicht frei.

Option: VM-PostgreSQL nach PostgreSQL Flex migrieren

Der alte Pfad deploy_postgres_migration_job = true wird durch die Validierung gesperrt. Nutzen Sie stattdessen den freigabegesteuerten Workflow. Stoppen Sie HPA, Lastgenerierung und alle anderen Zielschreiber. Pausieren Sie Terraform- und GitOps-Reconciliation, solange das Skript die Replikazahl steuert. Seine lokale Sperre schützt nur einen Checkout, nicht vor gleichzeitigen Bedienern auf unterschiedlichen Rechnern.

python3 scripts/migrate_postgres.py cutover \
  --artifacts ../stackit-cmf-Rehost-springboot/artifacts \
  --evidence .tmp/migration-run \
  --source-write-frozen --confirm-target springmusic

Das Quellschreibstopp-Flag ist eine Bestätigung des Betreibers, keine automatische Abschaltung der Quelle. Der Cutover skaliert die Anwendung auf null, sichert das Ziel vor dem Cutover und prüft die Sicherung per Prüfsumme. Er weist ihre Wiederherstellbarkeit in der Probedatenbank nach und stellt erst dann die Quelle transaktional wieder her. Vor dem Wiederanlauf mit ursprünglicher Replikazahl werden die Daten geprüft. Bei Fehlern bleibt die Anwendung zur Untersuchung gestoppt. Bewahren Sie Nachweisjournal und Backup auf; überschreiben Sie sie nicht für einen erneuten Versuch.

Validieren und zurückrollen

Vergleichen Sie Datenbanknachweise mit dem Quellmanifest, prüfen Sie das Anwendungsverhalten über das Gateway und bestätigen Sie den Zustand beider Metrik-Jobs. Traffic-Umschaltung und fachliche Abnahme bleiben Betreiberaufgaben; das Skript ändert den Endpunkt der Quellanwendung nicht.

So stellen Sie die geschützte Zieldatenbank aus der Zeit vor dem Cutover wieder her:

python3 scripts/migrate_postgres.py rollback \
  --evidence .tmp/migration-run --confirm-target springmusic

Der Rollback prüft Zielidentität und Backup-Integrität, sichert das aktuelle Ziel separat, stellt die ursprünglichen Daten wieder her und verifiziert vor dem Wiederanlauf deren Fingerprint. Schreibzugriffe nach dem Cutover werden nicht zusammengeführt; bewahren Sie den Dump vor dem Rollback für einen expliziten Abgleich auf. Dies ist ein Zieldatenbank-Rollback, kein automatischer Failback zur Quell-VM.

Datenbank-Metriken in Observability sichtbar machen

Terraform verwaltet den Grafana-Ordner SCF Replatform und das Dashboard mit acht Panels an der vorhandenen Datenquelle Thanos. Öffnen Sie es über grafana_dashboard_url. Cluster-CPU, Cluster-Speicher, laufende Pods, Anwendungsanfragen sowie PostgreSQL-Zustand und -Auslastung unterstützen Abnahme und spätere Optimierung. Ein manueller Dashboard-Import ist nicht nötig.

Anwendungsmetriken stammen aus dem pod-lokalen Boot-2-Actuator über den Metrikadapter auf Port 9090; der PostgreSQL-Exporter nutzt Port 9187. Prüfen Sie beide tatsächlichen Scrape-Ergebnisse, nicht nur die Dashboard-Darstellung. Fehlende Telemetrie ist ein Untersuchungsgrund, niemals der Nachweis fehlender Last.

Validierung mit kubectl

Exportieren Sie eine kurzlebige Kubeconfig mit privaten Berechtigungen und prüfen Sie den Standard-Namespace der Referenz:

umask 077
mkdir -p .tmp
terraform output -raw kubeconfig > .tmp/replatform.kubeconfig
export KUBECONFIG="$PWD/.tmp/replatform.kubeconfig"
kubectl get deploy,svc,pods -n springboot
kubectl get gateway,httproute -n springboot
kubectl rollout status deployment/springboot -n springboot
bash scripts/validate_gateway.sh

Der Gateway-Validator prüft Akzeptanz, aufgelöste Routenreferenzen, DNS und Anwendungsantwort. Entfernen Sie die lokale Kubeconfig nach Gebrauch und beziehen Sie nach Ablauf eine neue. Ein erfolgreicher Rollout allein ist keine Daten- oder fachliche Abnahme.

Grenze zwischen Backup und Recovery

Trennen Sie Migrations-Rollback von Flex-Service-Recovery und bewahren Sie geschützte Nachweise außerhalb kurzlebiger Ausführungsumgebungen auf.

Die Flex-Aufbewahrung wird explizit konfiguriert; der Standard dieser Referenz beträgt 32 Tage. Managed-Datenbankbackups und der Migrationsdump vor dem Cutover dienen unterschiedlichen Zwecken. Die Probe mit Letzterem weist weder Managed-Service-Restore noch Point-in-Time-Recovery oder Disaster Recovery der Anwendung nach. Benennen Sie Recovery-Verantwortliche und testen Sie den benötigten Service-Recovery-Pfad separat.

Bewahren Sie geschützte Nachweise und Backups bis zum Ende des Rollback-Fensters außerhalb eines kurzlebigen Dev Containers auf. Prüfen Sie nach einem abgebrochenen Migrationsprozess verbliebene Pods mit Präfix springmusic-migration-*, bevor Sie fortfahren; starten Sie ein ungeprüftes Ziel nicht durch Terraform neu.

Was dieses Asset zeigt

Dieses Asset zeigt, wie das Anwendungsverhalten beim Wechsel der Betriebsmodelle für Laufzeit und Datenbank erhalten bleibt:

Plattformwechsel: Dasselbe Spring-Boot-JAR auf SKE betreiben, über TLS mit PostgreSQL Flex verbinden und über Gateway API und DNS erreichbar machen.
Kontrollierte Datenmigration: Quelldump und Manifest qualifizieren, einen isolierten Restore proben und vor dem Cutover eine explizite Freigabe sowie ein verifiziertes Zielbackup verlangen. Bei erforderlichem Rollback den Zielzustand vor dem Cutover wiederherstellen.
Unabhängige Validierung: Datenintegrität, Anwendungsantworten, Gateway- und DNS-Bereitschaft sowie tatsächliche Scrape-Ergebnisse prüfen. Den Terraform-Plan auf unerklärte Drift prüfen, statt erfolgreiche Bereitstellung als Migrationsabnahme zu behandeln.
Wiederholbare Observability: Observability-Integration und Grafana-Dashboard mit acht Panels durch Terraform verwalten. Anwendungs- und Datenbanksignale für Abnahme, Stabilisierung und spätere Optimierung nutzen.

Nicht abgedeckt

Diese Nachweise bestätigen weder einen vollständigen Greenfield-Durchlauf noch eine Migration aus einer produktiven Live-Quelle, unterbrechungsfreien Betrieb, Hochverfügbarkeit, öffentliches Gateway-TLS, interaktiven IDP-Login, Alarmzustellung oder Managed-Flex-Recovery. Der getestete Ein-Worker-Aufbau mit HTTP stellt Metriken ohne Authentifizierung bereit; erfüllen Sie die Produktionsanforderungen vor der Verwendung sensibler Daten. Aktualisieren Sie die Beispielanwendung und validieren Sie eine geeignete unterstützte Kubernetes-Version als separate kontrollierte Änderungen.

Code & Registry github.com Referenzkonfiguration, Skripte und Validierungsnachweise Das Repository-README und die versionierte Implementierung liefern genaue Voraussetzungen, Variablen, Befehle und Recovery-Grenzen. Repository öffnen

Überblick

Dieses Asset wendet das Migration Framework auf ein Replatform von Spring Boot und PostgreSQL an: Die Anwendung wechselt vom VM-Service zu STACKIT Kubernetes Engine (SKE), die Datenbank von selbstverwaltetem PostgreSQL zu STACKIT PostgreSQL Flex. Geschäftsfunktion und Anwendungs-JAR bleiben unverändert; die Betriebsmodelle für Laufzeit und Datenbank ändern sich.

Referenzimplementierung

Das Referenzrepository ist die maßgebliche Quelle für Terraform, Helm-Charts, fest versionierte Artefakte, Migrationsskripte und Validierung. Verwenden Sie einen geprüften Stand mit den hier beschriebenen Gateway-API- und scripts/migrate_postgres.py-Workflows. Ein älterer Stand mit direktem Datenbank-Import-Job implementiert dieses Verfahren nicht.

Code & Registry github.com STACKIT Spring Boot Kubernetes Replatform Repository Terraform, Gateway API, PostgreSQL-Migration und Observability der in diesem Asset verwendeten Implementierung öffnen. Repository öffnen

Replatform-Scope in diesem Asset

Laufzeit: Dasselbe Spring-Music-JAR mit Spring Boot 2.4.0 läuft auf Java 11 in einem Kubernetes-Deployment statt unter systemd.
Daten: PostgreSQL Flex stellt getrennte Anwendungs- und Probedatenbanken bereit; JDBC- und Migrationsclients benötigen TLS.
Netzwerkverkehr: Envoy Gateway, Gateway API HTTPRoutes und SKE-verwaltetes ExternalDNS ersetzen den VM-Endpunkt.
Betrieb: Kubernetes-Zustands- und Ressourcenkontrollen ersetzen das Host-Service-Management; Managed Telemetry erfasst Cluster-, Anwendungs- und Datenbanksignale.
Migration: Quellnachweise, isolierte Probe, explizit freigegebener Cutover und verifizierter Datenbank-Rollback bleiben von der Infrastrukturbereitstellung getrennt.

Cloud Foundry, Object Storage, die Zerlegung in Microservices und Anwendungsmodernisierung sind nicht Teil dieser Implementierung. Die alte Beispielanwendung demonstriert einen Plattformwechsel; sie ist keine Empfehlung, einen nicht mehr unterstützten Anwendungsstack produktiv einzusetzen.

Architekturdiagramm der Referenz

Prüfen Sie das Architektur-Asset vor der Wahl von Kapazität und Netzwerkkontrollen. Es trennt die implementierte Topologie von Produktionserweiterungen wie öffentlichem HTTPS, hochverfügbaren Workern und geschützten Metriken.

Cloud Framework Spring Boot auf SKE mit PostgreSQL Flex und Gateway API Implementierte Topologie, Laufzeit- und Datengrenzen sowie separat zu qualifizierende Produktionserweiterungen prüfen. Seite öffnen

End-to-End-Ablauf

Replatform-Eignung, Quellkompatibilität, Landing-Zone-Bereitschaft und Verantwortlichkeiten bestätigen.
Einen vertrauenswürdigen PostgreSQL-Dump und ein Integritätsmanifest unabhängig vom Ziel vorbereiten.
Terraform für SKE, PostgreSQL Flex, Gateway, DNS, Workload und Observability prüfen und anwenden.
Das Ziel validieren und den finalen Quelldump in der isolierten Probedatenbank testen.
Quellschreibzugriffe einfrieren, Ausfallzeit freigeben und den kontrollierten Cutover mit geschütztem Zielbackup ausführen.
Anwendungs- und Datennachweise abnehmen oder den Zielzustand vor dem Cutover wiederherstellen; den Client-Traffic nach dem freigegebenen Betreiberverfahren umschalten.
Nachweise während der Stabilisierung aufbewahren und repräsentative Telemetrie für spätere Optimierung nutzen.

Arbeitsumgebung für den Walkthrough vorbereiten

Verwenden Sie eine isolierte Linux-Laborumgebung mit Git, Terraform, kubectl, curl, jq, getent, Python ab Version 3.11 sowie PostgreSQL-Server- und Client-Werkzeugen. Die Rehost-Beispielskripte benötigen außerdem runuser, sha256sum, ein Betriebssystemkonto postgres und Root-Rechte, um eine temporäre lokale Datenbank zu erstellen und zu prüfen. Führen Sie die Beispielbefehle in dieser vorbereiteten Laborumgebung aus, nicht auf einem produktiven Datenbankhost. Die privaten Artefakte müssen für den Migrationsbediener lesbar bleiben; machen Sie sie nicht für alle Benutzer lesbar.

Beziehen Sie geprüfte Commit-IDs beider Repositorys vom Referenz-Maintainer und exportieren Sie diese vorab als REHOST_REVISION und REPLATFORM_REVISION. Der Replatform-Stand muss Gateway API und den freigabegesteuerten Migrationsworkflow enthalten. Setzen Sie nicht voraus, dass der Remote-Standardbranch bereits die lokal getestete Implementierung enthält. Ist der freigegebene Stand nicht verfügbar, beschaffen Sie ihn vor dem Walkthrough.

Ersetzen Sie beide Platzhalter durch die freigegebenen vollständigen Commit-IDs mit jeweils 40 Zeichen und setzen Sie diese im selben Bash-Terminal:

export REHOST_REVISION="REPLACE_WITH_REVIEWED_REHOST_COMMIT_ID"
export REPLATFORM_REVISION="REPLACE_WITH_REVIEWED_REPLATFORM_COMMIT_ID"

Führen Sie den folgenden Block vollständig aus einem leeren Arbeitsverzeichnis aus. Die if-Prüfung lehnt fehlende, leere oder falsch formatierte IDs einschließlich unveränderter Platzhalter ab. Jedes && führt den nächsten Befehl nur nach Erfolg des vorherigen aus. Git prüft die Verfügbarkeit der Commits; die Formatprüfung allein bestätigt weder Freigabe noch Repository-Inhalt.

if [[ ! ${REHOST_REVISION:-} =~ ^[0-9a-fA-F]{40}$ ||
      ! ${REPLATFORM_REVISION:-} =~ ^[0-9a-fA-F]{40}$ ]]; then
  printf '%s\n' "Set both revision variables to reviewed full 40-character commit IDs." >&2
  false
else
  umask 077 &&
    git clone https://github.com/stackitcloud/stackit-cmf-Rehost-springboot.git &&
    git clone https://github.com/stackitcloud/stackit-cmf-replatform-springboot-k8s.git &&
    git -C stackit-cmf-Rehost-springboot checkout --detach "$REHOST_REVISION" &&
    git -C stackit-cmf-replatform-springboot-k8s checkout --detach "$REPLATFORM_REVISION" &&
    test -f stackit-cmf-replatform-springboot-k8s/scripts/migrate_postgres.py &&
    test -f stackit-cmf-replatform-springboot-k8s/scripts/validate_gateway.sh &&
    cd stackit-cmf-replatform-springboot-k8s &&
    printf '%s\n' "Workspace ready. Continue from this Replatform checkout." || {
      printf '%s\n' "Preparation failed. Resolve the error before continuing." >&2
      false
    }
fi

Fahren Sie erst nach der Meldung Workspace ready fort. Bei Fehlern bleibt das Terminal offen; weitere Vorbereitungsbefehle werden übersprungen. Vorhandene oder teilweise geklonte Verzeichnisse werden weder entfernt noch überschrieben: Prüfen Sie diese und bewahren Sie lokale Änderungen, bevor Sie es in einem neuen leeren Arbeitsverzeichnis erneut versuchen. Nach Erfolg befindet sich das Terminal für die nächsten Schritte im Replatform-Checkout.

Nutzen Sie ein freigegebenes STACKIT Projekt, einen Service Account, DNS-Delegation, SKE-Kapazität und ein geschütztes Terraform-Backend. Beziehen Sie Zugangsdaten über den freigegebenen Secret-Kanal, niemals aus diesem Trail. Die folgenden Befehle setzen diese Verzeichnisstruktur und eine geprüfte Konfiguration voraus; sie belegen keinen validierten Greenfield-Produktionsaufbau.

Quellnachweise vorbereiten

Qualifizieren Sie einen konsistenten Quelldump und sein Manifest, bevor Daten in den Migrationsworkflow eingehen.

Die Rehost-Referenz liefert scripts/create_source_dump.sh und scripts/validate_source_dump.sh für ihr reproduzierbares Beispiel. Führen Sie diese im Rehost-Repository aus. Dessen Verzeichnis artifacts liefert source-postgresql.dump und source-postgresql.manifest an den Replatform-Workflow. Das Manifest erfasst Version 1, table=public.album, row_count, album_fingerprint und dump_sha256.

Führen Sie ausschließlich für das reproduzierbare Beispiel die folgenden Befehle vom Replatform-Checkout in der vorbereiteten Laborumgebung aus. Die Skripte erstellen aus dem versionierten Beispiel-SQL eine temporäre PostgreSQL-Instanz, exportieren sie und führen einen unabhängigen Test-Restore aus. Verwenden Sie ein frisches Artefaktverzeichnis; überschreiben Sie keine Nachweise einer bereits laufenden Migration.

umask 077
pushd ../stackit-cmf-Rehost-springboot
bash scripts/create_source_dump.sh
bash scripts/validate_source_dump.sh
popd

Erwartet wird eine erfolgreiche Validierung von acht Zeilen mit passendem Fingerprint. Diese Befehle lesen keine Quell-VM aus. Verwenden Sie für Probe und Cutover genau diese Artefakte weiter.

Ersetzen Sie für eine reale Quelle den Beispielgenerator durch ein freigegebenes Exportverfahren: Frieren Sie alle Schreibzugriffe ein und leiten Sie Dump im Custom-Format und Manifest aus demselben konsistenten Quellsnapshot ab. Das generierte Beispiel mit acht Alben ist kein Export einer beliebigen laufenden VM. Prüfen Sie vor dem Export PostgreSQL-Kompatibilität, Erweiterungen, Eigentümerschaft und Schemaabhängigkeiten.

Stellen Sie nur vertrauenswürdige Dumps wieder her, da sie SQL ausführen. Diese Implementierung migriert das Anwendungsschema public und prüft public.album; von Flex verwaltete Schemas sind bewusst ausgeschlossen. Andere Workloads benötigen eigene Invarianten und einen angepassten Schemaumfang.

Code & Registry github.com Spring-Boot-Rehost-Quelle und Beispielexport Das Rehost-Repository liefert dasselbe Anwendungsartefakt und reproduzierbare Werkzeuge für PostgreSQL-Quellnachweise. Repository öffnen

Ziel bereitstellen

Stellen Sie das Ziel aus einem geprüften Plan mit expliziten Angaben zu Projekt, Kapazität, Zugriff und DNS bereit.

Verwenden Sie Terraform, kubectl, curl, jq, getent und Python ab Version 3.11 unter Linux. Kopieren Sie env.tfvars.example nach env.tfvars und passen Sie die tatsächlichen Variablen dieser Datei an. Behalten Sie die getestete Provider-Lockdatei und unveränderliche Image- und JAR-Referenzen bei. Bestätigen Sie vor dem Plan die Verfügbarkeit der SKE-Version, Node-Pool-Kapazität, Projektberechtigungen und DNS-Delegation.

Aus der STACKIT-DokuLifecycle of Kubernetes Engine › Kubernetes end-of-life datesStand der Quelle 24.08.2026 · übernommen 05.10.2026

Starting with Kubernetes v1.33, we remove minor versions on the patch day that precedes the upstream maintenance end-of-life (EOL) date. The following table below lists the upstream EOL date for each Kubernetes minor version and the corresponding expiration date in SKE:

Seitlich wischen, um die ganze Tabelle zu sehen

Kubernetes minor version	End-of-life date	Expiration in SKE
v1.32	2026-02-28	2026-04-15
v1.33	2026-06-28	2026-06-10
v1.34	2026-10-27	2026-10-14
v1.35	2027-02-28	2027-02-10

Please refer to the official Kubernetes Release History for up-to-date announcements of new versions.

Was ist das?

Dieser Abschnitt wird mehrmals am Tag automatisch aus der STACKIT-Doku übernommen. Hier lässt er sich nicht ändern. Änderungen gehören in die STACKIT-Doku.

Bevorzugen Sie ein freigegebenes Application-Landing-Zone-Projekt. Setzen Sie create_project = false und geben Sie Projekt-ID und Pfad zum Service-Account-Schlüssel an. Die alternative Projekterstellung setzt einen freigegebenen übergeordneten Container und Berechtigungen voraus; sie ersetzt keine Landing-Zone-Governance. Zugangsdaten, State, gespeicherte Pläne und Migrationsnachweise gehören nie in die Versionsverwaltung.

Erstellen Sie für einen neuen Checkout die private Variablendatei, ohne eine vorhandene zu überschreiben:

umask 077
test -e env.tfvars || cp env.tfvars.example env.tfvars
chmod 600 env.tfvars

Bearbeiten Sie diese Datei vor dem Plan: Tragen Sie freigegebenes Projekt und Service-Account-Pfad, Region, unterstützte SKE-Version, verfügbaren Node-Pool-Flavor samt Zone und delegierte DNS-Einstellungen aus dem Repository-Beispiel ein. Prüfen Sie Backend-Zugriff und Sperren, Quotas, Kosten sowie die Grenzen von HTTP und öffentlichen Metriken. Die folgenden Funktionsschalter bilden keine vollständige Umgebungskonfiguration.

Einheitliche Automatisierungs-Flags

Der optionale gemeinsame Wrapper bildet setup_project, setup_observability, setup_database, setup_workload, setup_loadgen und setup_dns auf die Terraform-Schalter des Repositorys ab. Sie wählen ausschließlich den Bereitstellungsumfang: Das Aktivieren der Datenbank erlaubt keinen Datenaustausch und ersetzt niemals die separate Migrationsfreigabe.

Minimale Zielkonfiguration

Diese Werte aktivieren den vollständigen Workload- und Datenbankpfad. Sie ergänzen die Angaben zu Projekt, Region, Node Pool und DNS im Repository-Beispiel, ersetzen sie aber nicht.

deploy_workload                   = true
dns_enabled                       = true
enable_postgres_flex              = true
postgres_flex_target_database     = "springmusic"
postgres_flex_target_app_acl_cidrs = []
observability_enabled             = true
create_observability_instance     = true
create_grafana_dashboard          = true
enable_springboot_hpa              = false
enable_load_generator             = false
deploy_postgres_migration_job      = false

Lassen Sie HPA und Lastgenerierung während der Migration deaktiviert. Wählen Sie Alarmeinstellungen bewusst; die Alarmzustellung wurde im End-to-End-Test nicht validiert. springboot_image wählt die Java-Laufzeit, nicht ein beliebiges vorgefertigtes Anwendungsimage. Der Init-Container lädt das auf einen Commit fixierte Rehost-JAR und prüft vor dem Start seinen SHA-256-Wert. Spiegeln Sie unveränderliche Artefakte für die Produktion in freigegebene Artefakt- und Image-Dienste.

Führen Sie die Befehle im Replatform-Repository aus und prüfen Sie den gespeicherten Plan vor dem Apply:

umask 077
terraform init
terraform validate
terraform plan -var-file=env.tfvars -out=tfplan
terraform apply tfplan
bash scripts/validate_gateway.sh

Zugriffskontrolle und temporäre ACL-Erweiterung für Migration

Bei leeren Anwendungs-ACL-Eingaben verwendet Terraform die tatsächlichen Egress-CIDRs des SKE-Clusters für PostgreSQL Flex. Explizite Anwendungs- oder ältere ACL-Werte überschreiben diesen Standard und müssen geprüft werden. Erlauben Sie nicht 0.0.0.0/0.

Der temporäre PostgreSQL-Client läuft in SKE und erhält den Dump über kubectl. Er verbindet sich nicht direkt mit der Quell-VM; weder Quell- noch Arbeitsplatz-CIDRs benötigen temporären Flex-Zugriff. JDBC und Datenbankwerkzeuge verwenden sslmode=require: Das erzwingt Verschlüsselung, bietet aber nicht die Hostnamenprüfung von verify-full. Schützen Sie Zugangsdaten in Kubernetes Secrets und im Terraform-Backend und validieren Sie bei Bedarf eine stärkere Zertifikatsprüfung.

Migration proben

Stellen Sie den finalen Dump in der isolierten Probedatenbank wieder her und verlangen Sie passende Nachweise, die jünger als 24 Stunden sind.

Führen Sie nach dem Infrastruktur-Apply einen isolierten Restore in springmusic_rehearsal aus. Passen Sie das Quellverzeichnis an die freigegebenen Artefakte an und halten Sie den Nachweispfad privat.

python3 scripts/migrate_postgres.py rehearse \
  --artifacts ../stackit-cmf-Rehost-springboot/artifacts \
  --evidence .tmp/migration-run

Die Probe validiert Manifest, Dump-Prüfsumme, Zielidentität, Zeilenanzahl und Fingerprint, ohne die Anwendungsdatenbank zu ersetzen. Proben Sie nach dem Schreibstopp auf der Quelle erneut mit dem finalen Dump. Der Cutover verlangt passende Nachweise, die jünger als 24 Stunden sind. Eine erfolgreiche Probe mit einem älteren oder anderen Dump gibt die finale Eingabe nicht frei.

Option: VM-PostgreSQL nach PostgreSQL Flex migrieren

Der alte Pfad deploy_postgres_migration_job = true wird durch die Validierung gesperrt. Nutzen Sie stattdessen den freigabegesteuerten Workflow. Stoppen Sie HPA, Lastgenerierung und alle anderen Zielschreiber. Pausieren Sie Terraform- und GitOps-Reconciliation, solange das Skript die Replikazahl steuert. Seine lokale Sperre schützt nur einen Checkout, nicht vor gleichzeitigen Bedienern auf unterschiedlichen Rechnern.

python3 scripts/migrate_postgres.py cutover \
  --artifacts ../stackit-cmf-Rehost-springboot/artifacts \
  --evidence .tmp/migration-run \
  --source-write-frozen --confirm-target springmusic

Das Quellschreibstopp-Flag ist eine Bestätigung des Betreibers, keine automatische Abschaltung der Quelle. Der Cutover skaliert die Anwendung auf null, sichert das Ziel vor dem Cutover und prüft die Sicherung per Prüfsumme. Er weist ihre Wiederherstellbarkeit in der Probedatenbank nach und stellt erst dann die Quelle transaktional wieder her. Vor dem Wiederanlauf mit ursprünglicher Replikazahl werden die Daten geprüft. Bei Fehlern bleibt die Anwendung zur Untersuchung gestoppt. Bewahren Sie Nachweisjournal und Backup auf; überschreiben Sie sie nicht für einen erneuten Versuch.

Validieren und zurückrollen

Vergleichen Sie Datenbanknachweise mit dem Quellmanifest, prüfen Sie das Anwendungsverhalten über das Gateway und bestätigen Sie den Zustand beider Metrik-Jobs. Traffic-Umschaltung und fachliche Abnahme bleiben Betreiberaufgaben; das Skript ändert den Endpunkt der Quellanwendung nicht.

So stellen Sie die geschützte Zieldatenbank aus der Zeit vor dem Cutover wieder her:

python3 scripts/migrate_postgres.py rollback \
  --evidence .tmp/migration-run --confirm-target springmusic

Der Rollback prüft Zielidentität und Backup-Integrität, sichert das aktuelle Ziel separat, stellt die ursprünglichen Daten wieder her und verifiziert vor dem Wiederanlauf deren Fingerprint. Schreibzugriffe nach dem Cutover werden nicht zusammengeführt; bewahren Sie den Dump vor dem Rollback für einen expliziten Abgleich auf. Dies ist ein Zieldatenbank-Rollback, kein automatischer Failback zur Quell-VM.

Datenbank-Metriken in Observability sichtbar machen

Terraform verwaltet den Grafana-Ordner SCF Replatform und das Dashboard mit acht Panels an der vorhandenen Datenquelle Thanos. Öffnen Sie es über grafana_dashboard_url. Cluster-CPU, Cluster-Speicher, laufende Pods, Anwendungsanfragen sowie PostgreSQL-Zustand und -Auslastung unterstützen Abnahme und spätere Optimierung. Ein manueller Dashboard-Import ist nicht nötig.

Anwendungsmetriken stammen aus dem pod-lokalen Boot-2-Actuator über den Metrikadapter auf Port 9090; der PostgreSQL-Exporter nutzt Port 9187. Prüfen Sie beide tatsächlichen Scrape-Ergebnisse, nicht nur die Dashboard-Darstellung. Fehlende Telemetrie ist ein Untersuchungsgrund, niemals der Nachweis fehlender Last.

Validierung mit kubectl

Exportieren Sie eine kurzlebige Kubeconfig mit privaten Berechtigungen und prüfen Sie den Standard-Namespace der Referenz:

umask 077
mkdir -p .tmp
terraform output -raw kubeconfig > .tmp/replatform.kubeconfig
export KUBECONFIG="$PWD/.tmp/replatform.kubeconfig"
kubectl get deploy,svc,pods -n springboot
kubectl get gateway,httproute -n springboot
kubectl rollout status deployment/springboot -n springboot
bash scripts/validate_gateway.sh

Der Gateway-Validator prüft Akzeptanz, aufgelöste Routenreferenzen, DNS und Anwendungsantwort. Entfernen Sie die lokale Kubeconfig nach Gebrauch und beziehen Sie nach Ablauf eine neue. Ein erfolgreicher Rollout allein ist keine Daten- oder fachliche Abnahme.

Grenze zwischen Backup und Recovery

Trennen Sie Migrations-Rollback von Flex-Service-Recovery und bewahren Sie geschützte Nachweise außerhalb kurzlebiger Ausführungsumgebungen auf.

Die Flex-Aufbewahrung wird explizit konfiguriert; der Standard dieser Referenz beträgt 32 Tage. Managed-Datenbankbackups und der Migrationsdump vor dem Cutover dienen unterschiedlichen Zwecken. Die Probe mit Letzterem weist weder Managed-Service-Restore noch Point-in-Time-Recovery oder Disaster Recovery der Anwendung nach. Benennen Sie Recovery-Verantwortliche und testen Sie den benötigten Service-Recovery-Pfad separat.

Bewahren Sie geschützte Nachweise und Backups bis zum Ende des Rollback-Fensters außerhalb eines kurzlebigen Dev Containers auf. Prüfen Sie nach einem abgebrochenen Migrationsprozess verbliebene Pods mit Präfix springmusic-migration-*, bevor Sie fortfahren; starten Sie ein ungeprüftes Ziel nicht durch Terraform neu.

Was dieses Asset zeigt

Dieses Asset zeigt, wie das Anwendungsverhalten beim Wechsel der Betriebsmodelle für Laufzeit und Datenbank erhalten bleibt:

Plattformwechsel: Dasselbe Spring-Boot-JAR auf SKE betreiben, über TLS mit PostgreSQL Flex verbinden und über Gateway API und DNS erreichbar machen.
Kontrollierte Datenmigration: Quelldump und Manifest qualifizieren, einen isolierten Restore proben und vor dem Cutover eine explizite Freigabe sowie ein verifiziertes Zielbackup verlangen. Bei erforderlichem Rollback den Zielzustand vor dem Cutover wiederherstellen.
Unabhängige Validierung: Datenintegrität, Anwendungsantworten, Gateway- und DNS-Bereitschaft sowie tatsächliche Scrape-Ergebnisse prüfen. Den Terraform-Plan auf unerklärte Drift prüfen, statt erfolgreiche Bereitstellung als Migrationsabnahme zu behandeln.
Wiederholbare Observability: Observability-Integration und Grafana-Dashboard mit acht Panels durch Terraform verwalten. Anwendungs- und Datenbanksignale für Abnahme, Stabilisierung und spätere Optimierung nutzen.

Nicht abgedeckt

Diese Nachweise bestätigen weder einen vollständigen Greenfield-Durchlauf noch eine Migration aus einer produktiven Live-Quelle, unterbrechungsfreien Betrieb, Hochverfügbarkeit, öffentliches Gateway-TLS, interaktiven IDP-Login, Alarmzustellung oder Managed-Flex-Recovery. Der getestete Ein-Worker-Aufbau mit HTTP stellt Metriken ohne Authentifizierung bereit; erfüllen Sie die Produktionsanforderungen vor der Verwendung sensibler Daten. Aktualisieren Sie die Beispielanwendung und validieren Sie eine geeignete unterstützte Kubernetes-Version als separate kontrollierte Änderungen.

Code & Registry github.com Referenzkonfiguration, Skripte und Validierungsnachweise Das Repository-README und die versionierte Implementierung liefern genaue Voraussetzungen, Variablen, Befehle und Recovery-Grenzen. Repository öffnen

GOAL

Stabilisieren und optimieren

Kehren Sie zum Optimize-Zyklus des Migration Framework zurück: repräsentative Betriebsnachweise sammeln, begrenzende Ebene identifizieren, eine kontrollierte Änderung umsetzen und Zuverlässigkeit, Performance sowie Kosten vor dem Beibehalten validieren.

In 7 Trails

Überblick: Optimize-Modul

Optimize startet, sobald Workloads auf STACKIT laufen und reale Daten aus dem Betrieb vorliegen. Das Modul überführt Beobachtungen aus dem Betrieb in messbare Verbesserungen für Performance, Stabilität und Wirtschaftlichkeit.

Optimize ist keine einmalige Aufgabe, sondern ein iterativer Zyklus, der sich mit früher Stabilisierung und Unterstützung direkt nach dem Cutover überschneiden kann.

Warum Optimize nach dem Cutover liegt

Viele Entscheidungen zu Rightsizing und Tuning sind erst unter echter Last belastbar. Nach dem Cutover lassen sich Annahmen mit Daten aus dem Betrieb validieren und präzisieren.

Optimize-Zyklus

Laufzeitdaten erfassen: Auslastung, Latenz, Fehlerquoten, Durchsatz und Kostentreiber.
Engpässe und Verschwendungsmuster auf Workload-, Plattform- und Datenebene identifizieren.
Maßnahmen nach Business-Effekt, Risikoreduktion und FinOps-Nutzen priorisieren.
Tuning-Änderungen in kontrollierten Inkrementen umsetzen.
Ergebnisse gegen SLO-, Stabilitäts- und Kostenziele validieren.
Erkenntnisse in Folgewellen und Betriebsstandards zurückführen.

Typische Bereiche

Rightsizing: Compute-, Storage- und Netzwerkressourcen an reale Last anpassen.
Performance-Tuning: Latenz und Durchsatz durch Konfiguration, Skalierung und Architekturmaßnahmen verbessern.
Reliability-Hardening: Incident-Häufigkeit durch Resilienz-, Monitoring- und Fehlerbehandlungsmaßnahmen reduzieren.
FinOps-Steuerung: Kostentransparenz verbessern, Verschwendung abbauen und Run-Rate optimieren.

Von der Theorie zur Umsetzung

Optimierungsentscheidungen sollten auf Laufzeitdaten basieren, nicht auf Annahmen. Für die praktische Umsetzung werden Workload-Telemetrie, Alerting und kontrollierte Infrastrukturänderungen kombiniert.

Managed-Observability-Basis: Mit STACKIT Observability Metriken, Logs und Traces mit Grafana, Prometheus, Thanos, Loki und Tempo erfassen.
Erkennungslogik: Klare Schwellwerte und Beobachtungsfenster für Unterauslastung und Überlast definieren.
Umsetzungspfad: Rightsizing über IaC-Änderungen (zum Beispiel VM-Flavors) mit Rollback-Checkpoints umsetzen.
Validierungsschleife: Nach jedem Tuning-Inkrement SLO, Fehlerquote und Laufkosten erneut messen.

Konkrete Beispiel-Assets

Asset-Titel

Framework

Asset-Typ

Migration migrate optimize rehost observability +2

Rehost Spring Boot mit Observability und VM-Rightsizing optimieren

STACKIT

Migration design-and-mobilize use-cases migrate optimize +6

Praktisches Optimize-Runbook für einen Rehost-Spring-Boot-Workload auf STACKIT mit managed Observability-Signalen und kontrolliertem VM-Rightsizing per IaC.

Rehost Spring Boot mit Observability und VM-Rightsizing optimieren

Migration

Runbook

Replatform Spring Boot auf Kubernetes mit Rightsizing und Pod-Skalierung optimieren

STACKIT

Migration migrate optimize replatform cloud-foundry +3

Dasselbe Spring-Boot-Replatform anhand gemessener Pod- und Node-Kapazität, PostgreSQL-Flex-Tuning, Skalierungsleitplanken und reversibler Änderungen optimieren.

Replatform Spring Boot auf Kubernetes mit Rightsizing und Pod-Skalierung optimieren

Migration

Runbook

Replatform Spring Boot auf Cloud Foundry mit Autoscaling und Rightsizing optimieren

STACKIT

Open Source

Praktisches Optimize-Runbook für einen auf STACKIT Cloud Foundry migrierten Spring-Boot-Workload mit Observability-Signalen, Autoscaling und Validierung.

Replatform Spring Boot auf Cloud Foundry mit Autoscaling und Rightsizing optimieren

Migration

Runbook

Verlagerte VMs mit nachweisbasiertem Rightsizing optimieren

STACKIT

Migration migrate optimize relocate vm +3

Dimensioniert verlagerte STACKIT VMs anhand repräsentativer Telemetrie neu, mit kontrollierten Machine-Type-Änderungen, Storage-Migration, Validierung und Rollback.

Verlagerte VMs mit nachweisbasiertem Rightsizing optimieren

Migration

Runbook

Replatform-Optimierungsdimensionen

Für Replatform-Workloads auf Kubernetes umfasst Optimierung mehrere Ebenen und sollte als gemeinsamer Regelkreis gesteuert werden.

Pod-Skalierung: HPA nutzen, um die Replikazahl anhand von Last mit klaren Min-/Max-Grenzen anzupassen.
Node-Pool-Skalierung: Ausreichend Cluster-Headroom sicherstellen und den Maschinentyp (Flavor) für CPU-/Memory-Dichteanforderungen abstimmen.
Ingress-Skalierung: Den Serviceplan des Load Balancers neu bewerten, wenn Ingress-Durchsatz oder Verbindungsverhalten zum Engpass werden.
Storage-Rightsizing: Storage-Klassen nach Performance-Anforderungen persistenter Workloads auswählen.
Validierungsdisziplin: Nach jeder inkrementellen Tuning-Änderung Latenz, Fehlerquote und Kosten erneut prüfen.

Eingaben und Ergebnisse

Zentrale Eingaben

Cutover-Berichte, Incident-Trends, SLO-Messwerte, Telemetrie-Baselines und Kostenberichte.

Ergebnisse

Priorisiertes Verbesserungs-Backlog, validierte Tuning-Änderungen und aktualisierte Betriebsstandards.

Governance-Effekt

Nachvollziehbare Trade-off-Entscheidungen zwischen Performance, Stabilität und Kosten.

Abgrenzung zu anderen Modulen

Optimize folgt auf die technische Umsetzung in Migrate.
Aktivitäten direkt nach dem Cutover können parallel laufen, die fachliche Verankerung erfolgt jedoch in der Run-Phase.
Umfassende Umbauten bleiben im Modul Refactor.

OPS

Dieselbe Referenzimplementierung fortführen

Migration design-and-mobilize use-cases migrate optimize replatform kubernetes rightsizing hpa spring-boot postgresql

Replatform Spring Boot auf Kubernetes mit Rightsizing und Pod-Skalierung optimieren

STACKIT

Dasselbe Spring-Boot-Replatform anhand gemessener Pod- und Node-Kapazität, PostgreSQL-Flex-Tuning, Skalierungsleitplanken und reversibler Änderungen optimieren.

Code & Registry github.com Spring Boot Kubernetes Replatform Referenz Dieselben versionierten Variablen, Deployment-Ressourcen und Dashboards wie im Migrations- und Stabilisierungsworkflow verwenden. Repository öffnen

STACKIT

Der souveräne europäische Cloud-Anbieter hinter dem Framework, mit IaaS und PaaS aus deutschen und österreichischen Rechenzentren und voller Unabhängigkeit.

Szenario

Wählen Sie nach Migrationsabnahme und Stabilisierung anhand des gemessenen Workload-Verhaltens jeweils eine Optimierung. Dieses Asset behandelt Pod-Ressourcen, Worker-Kapazität, optionales HPA und PostgreSQL Flex. Es behauptet nicht, dass diese Änderungen im Migrationstest erprobt wurden.

Referenzimplementierung fortführen

Führen Sie dieselbe Terraform-, Helm-, Spring-Music-JAR-, PostgreSQL-Flex- und Observability-Implementierung fort, die für Bereitstellung, Probe, Cutover und Rollback genutzt wurde. Führen Sie kein zweites Beispiel ein und keine Kapazitätsexperimente im Migrationsfenster durch.

Observability-Dashboard für Entscheidungen

Öffnen Sie grafana_dashboard_url oder den Ordner SCF Replatform. Terraform verwaltet acht Panels.

Replatform-Grafana-Dashboard mit Cluster-CPU und -Speicher, einem Spring-Boot-Pod, Anwendungsanfragen und PostgreSQL-Flex-Metriken über eine Stunde

Aufnahme der Referenzbereitstellung vom 25. September 2026, 14:41 bis 15:41 UTC. Sie zeigt eine Stunde Testbetrieb mit geringer Last, keine repräsentative Basis für Produktions-Sizing. Bewerten Sie Anwendungsaktivität gemeinsam mit Datenbankverfügbarkeit und -auslastung, bevor Sie einen Optimierungskandidaten auswählen. Die folgende Tabelle erläutert die Grenzen dieser Signale.

Seitlich wischen, um die ganze Tabelle zu sehen

Panelgruppe	Unterstützte Entscheidung	Interpretationsgrenze
Cluster-CPU und -Speicher	Worker-Auslastung und Gesamtkapazität	Die CPU-Abfrage zeigt belegte Kerne, keinen Auslastungsprozentsatz; Cluster-Summen identifizieren keinen einzelnen Pod-Engpass
Laufende Pods	Vorhandensein des Workloads	Ein Scrape-Ersatzwert beweist nicht, dass alle Replikas gesund sind; Kubernetes-Rollout und Soll-Replikazahl prüfen
Anwendungsanfragen	Anfragerate und mittlere Dauer	Der Boot-2-Adapter liefert keine Latenzperzentile und kein vollständiges Fehlerraten-SLO
PostgreSQL-Verfügbarkeit und -Verbindungen	Datenbankerreichbarkeit und Verbindungsdruck	`pg_up` und tatsächlichen Scrape-Zustand unabhängig prüfen
PostgreSQL-Transaktionen	Commit- und Rollback-Trends	Veränderungen mit Anfragelast und Anwendungsverhalten korrelieren
PostgreSQL-Cache-Treffer	Verhalten des Lesecaches	Geringe Anfragelast und fehlende Zeitreihen begründen keinen Kapazitätsbedarf
Temporäre PostgreSQL-Bytes und Sperren	Untersuchung von Abfragen oder Konkurrenz	Mehr Rechenleistung behebt Abfrage- oder Sperrprobleme nicht automatisch

Prüfen Sie vor der Interpretation echte up=1-Messwerte für beide Scrape-Jobs. Einige Cluster-Panels enthalten Ersatzwerte; eine dargestellte Null belegt daher keinen Nullverbrauch. Begrenzen Sie Abfragen auf den gewünschten Cluster und die Datenbank, wenn eine Datenquelle mehrere Workloads enthält. Nutzen Sie zusätzliche Telemetrie und fachliche Tests für Latenzperzentile, Fehler und Recovery-Ziele.

Optimierungssignale und Leitplanken

Erfassen Sie eine repräsentative Baseline einschließlich Spitzenzeiten, geplanter Arbeit, JVM-Aufwärmphase und Datenbankwartung. Vereinbaren Sie Beobachtungsfenster, fachliche SLOs, Kapazitätsreserve und Kostenziel vor der Änderung. Vierzehn Tage können ein Ausgangspunkt für die Beobachtung sein, sind aber keine feste Regel.

Pod-Ressourcenkandidat: Throttling, Neustarts, Heap- oder Working-Set-Druck sind auf Anwendung oder Sidecar begrenzt.
Worker-Kapazitätskandidat: Pods warten auf Scheduling, zuweisbare Ressourcen fehlen oder die Rollout-Reserve im Pool reicht nicht aus.
Datenbankkandidat: Verbindungs-, Transaktions-, Sperr-, Speicher- oder Abfragedruck korreliert mit fachlicher Latenz.
Scale-in-Kandidat: Dauerhafte Reserven nach Berücksichtigung von Spitzen, Rollout und Recovery, ohne ungelöste kritische Incidents.

Bewahren Sie Baseline, vorherige Konfiguration, Rollback-Plan und Entscheidungsschwellen auf. Fehlende Metriken, fehlgeschlagene Alarmzustellung oder ausschließlich synthetischer Traffic reichen als Nachweis für eine produktive Verkleinerung nicht aus.

Metriken aus PostgreSQL Flex für Optimize

Bewerten Sie Datenbank- und Anwendungssignale gemeinsam. Mehr Pods erhöhen den Verbindungsbedarf und können den Engpass zu Flex verlagern. Trennen Sie Connection-Pool-Grenzen, teure Abfragen, Sperrkonflikte und Speicherdruck von tatsächlichen CPU- oder RAM-Engpässen.

Nutzen Sie die Anleitung zum PostgreSQL-Flex-Monitoring , um Service-Metriken zusammen mit dem Anwendungsverhalten zu interpretieren.

PostgreSQL Flex für Rightsizing und Tuning

Die Referenz stellt postgres_flex_cpu, postgres_flex_ram, postgres_flex_replicas, postgres_flex_storage_class und postgres_flex_storage_size bereit. CPU, RAM und die Auswahl Single oder Replica bestimmen einen Flavor aus dem aktuellen Projektkatalog. Wählen Sie eine angebotene Kombination; setzen Sie weder beliebige Werte noch einen Wechsel ohne Neuerstellung voraus.

Prüfen Sie Plan und Service-Einschränkungen vor der Freigabe. Behandeln Sie einen Datenbankaustausch als neue Migration mit verifizierter Recovery, nicht als Routine-Resize. Speicherwachstum und Service-Plan-Wechsel lassen sich möglicherweise nicht durch alte Variablenwerte zurücknehmen. Bestätigen Sie Recovery-Pfad und Wartungsfenster vor der Änderung.

Der getestete Migrations-Rollback stellt Anwendungsdaten wieder her; er macht weder Infrastruktur-Resizing rückgängig noch weist er Managed-Flex-Restore nach. Validieren Sie das erforderliche Recovery-Verfahren separat.

STACKIT Dokumentation docs.stackit.cloud PostgreSQL-Flex-Flavors und Performance-Klassen Dokumentation öffnen

Aus der STACKIT-DokuVerfügbare Flavors und Leistungsklassen › FlavorStand der Quelle 06.07.2026 · übernommen 05.10.2026

Seitlich wischen, um die ganze Tabelle zu sehen

Beschreibung	ID	CPU	Memory	`max_connections`	`shared_buffers`	`work_mem`	`maintenance_work_mem`	`effective_cache_size`
Small, Compute optimized	2.4	2	4 GB	95	950 MB	14 MB	380 MB	2660 MB
Small, Memory optimized	2.16	2	16 GB	385	3950 MB	14 MB	1580 MB	11060 MB
Medium, Compute optimized	4.8	4	8 GB	195	1950 MB	14 MB	780 MB	5460 MB
Medium, Memory optimized	4.32	4	32 GB	785	7950 MB	14 MB	3180 MB	22260 MB
Large, Processor optimized	8.16	8	16 GB	385	3950 MB	14 MB	1580 MB	11060 MB
X-Large, Compute optimized	16.32	16	32 GB	785	7950 MB	14 MB	3180 MB	22260 MB
X-Large, Memory optimized	16.128	16	128 GB	3170	31950 MB	14 MB	12780 MB	89460 MB

Hinweise

CPU und Arbeitsspeicher gelten immer pro Knoten.
Das System nutzt bis zu 15 Verbindungen für interne essenzielle Prozesse wie Backup, Monitoring usw. Diese Verbindungen werden auf das Limit von max_connections angerechnet.

Was ist das?

Dieser Abschnitt wird mehrmals am Tag automatisch aus der STACKIT-Doku übernommen. Hier lässt er sich nicht ändern. Änderungen gehören in die STACKIT-Doku.

Aus der STACKIT-DokuVerfügbare Flavors und Leistungsklassen › LeistungsklassenStand der Quelle 06.07.2026 · übernommen 05.10.2026

Seitlich wischen, um die ganze Tabelle zu sehen

Beschreibung	ID	Max. IOPS	Max. Durchsatz (MB/s)
Leistungsklasse 2	`premium-perf2-stackit`	1000	100
Leistungsklasse 4	`premium-perf4-stackit`	2000	150
Leistungsklasse 6	`premium-perf6-stackit`	5000	200
Leistungsklasse 8	`premium-perf8-stackit`	10000	250
Leistungsklasse 10	`premium-perf10-stackit`	15000	300
Leistungsklasse 12	`premium-perf12-stackit`	20000	350

Aktuell bieten wir drei Typen von Instanzen an. Für jeden Typ ist ein anderer Satz an Flavor verfügbar.

Was ist das?

Dieser Abschnitt wird mehrmals am Tag automatisch aus der STACKIT-Doku übernommen. Hier lässt er sich nicht ändern. Änderungen gehören in die STACKIT-Doku.

Pod-Ressourcen und JVM-Budget

Die Referenz definiert Ressourcen im Spring-Boot-Deployment in main.tf, nicht über eigene CPU- oder Speichervariablen. Java fordert 100m CPU und 512Mi Speicher an; die Limits liegen bei 500m und 1Gi. JAVA_TOOL_OPTIONS setzt den initialen Heap auf 128 MiB und den maximalen Heap auf 512 MiB. Beide Exporter-Sidecars besitzen jeweils ein eigenes Ressourcenbudget.

Vergleichen Sie tatsächlichen Working Set, Heap, Nicht-Heap-Speicher, Throttling, Startverhalten und Sidecar-Verbrauch, bevor Sie das Deployment ändern. Lassen Sie neben dem Java-Heap Raum für Threads und nativen Speicher. Ressourcenänderungen können Pods neu ausrollen und einen Workload mit einer Replika unterbrechen; planen und validieren Sie entsprechend. Erfinden Sie keine nicht unterstützten springboot_cpu- oder Speichervariablen.

Regelkreis für Pod-Autoscaling

Qualifizieren Sie Metriken, Replikaverantwortung, Anwendungssicherheit und Telemetrie pro Pod vor einem begrenzten HPA-Experiment.

HPA vergleicht die beobachtete Pod-CPU-Auslastung mit dem konfigurierten Ziel und passt die Replikazahl innerhalb von Mindest- und Höchstgrenzen an. Die Ressourcenmetrik setzt realistische Requests und eine verfügbare Kubernetes Metrics API voraus; erfolgreiches Grafana-Scraping beweist deren Funktion nicht. Die Ressourcenauslastung umfasst auch die Sidecar-Budgets. HPA allein kann keine Worker-Kapazität erzeugen.

Prüfen Sie vor einem Experiment mit mehreren Replikas Sitzungszustand, gemeinsame Schreibzugriffe, Initialisierung und Datenbankverbindungslimits. Das aktuelle Anwendungs-/Exporter-Scraping nutzt einen lastverteilten Service-Endpunkt; Replikas können wechselnd statt als getrennte Zeitreihen erfasst werden. Etablieren Sie Anwendungsscraping pro Pod und vermeiden Sie doppelte Datenbankaggregation, bevor Sie skalierten Anfrageraten oder Summen vertrauen. Diese Erweiterungen gehören nicht zum validierten Ein-Replika-Pfad.

Konfiguration für Pod-Autoscaling

Testen Sie begrenztes HPA erst nach Abschluss von Migration und Rollback-Arbeiten in einem separat freigegebenen Experiment. Diese beispielhaften Grenzen sind keine Sizing-Empfehlungen für die Produktion:

enable_springboot_hpa                            = true
springboot_hpa_min_replicas                      = 1
springboot_hpa_max_replicas                      = 3
springboot_hpa_target_cpu_utilization_percentage = 70

Das Deployment definiert außerdem springboot_replicas in Terraform. Prüfen Sie spätere Pläne auf konkurrierende Replikaänderungen und legen Sie vor unbeaufsichtigtem HPA-Betrieb eine explizite Zuständigkeit fest. Das Migrationsskript lehnt HPA-verwaltete Ziele ab; deaktivieren Sie HPA vor jeder späteren Migration und jedem Rollback.

Prüfen Sie den Plan und beobachten Sie anschließend HPA mit der konfigurierten Kubeconfig:

terraform plan -var-file=env.tfvars -out=tfplan.optimize
terraform apply tfplan.optimize
kubectl get hpa,pods -n springboot
kubectl describe hpa springboot -n springboot
kubectl top pods -n springboot --containers

Cluster- und Plattform-Rightsizing

Stellen Sie genügend Worker-Reserve bereit und berücksichtigen Sie Pool-Kapazität, Zonengrenzen und Rollout-Unterbrechungen.

STACKIT-SKE-Grafana-Dashboard mit tatsächlicher CPU- und RAM-Nutzung gegenüber Requests und Limits, einem Node, 17 laufenden Pods, keinen wartenden oder fehlgeschlagenen Pods und API-Server-Aktivität

Das SKE-Dashboard zeigt dasselbe Intervall von 14:41 bis 15:41 UTC am 25. September 2026. Die tatsächliche CPU-Nutzung beträgt etwa 2 %, während CPU-Requests etwa 34 % der Cluster-Kapazität reservieren. Das verdeutlicht, warum Scheduling-Reservierungen und gemessener Verbrauch gemeinsam zu bewerten sind. Die 17 laufenden Pods umfassen Plattformkomponenten, nicht 17 Spring-Boot-Replikas; das Workload-Dashboard oben zeigt den einzelnen Anwendungspod. Keine fehlgeschlagenen oder wartenden Pods zu diesem Zeitpunkt sind ein nützliches Zustandssignal, kein Beweis für Spitzenlast- oder Ausfalltoleranz.

Passen Sie node_pool_minimum, node_pool_maximum und node_pool_machine_type anhand aggregierter Requests, beobachteter Nachfrage, System-Overhead und Rollout-Reserve an. Gleiche Mindest- und Höchstwerte fixieren die Pool-Größe; ein höheres HPA-Maximum kann diese Kapazitätsgrenze nicht überwinden.

Die Referenz konfiguriert einen Node Pool. Weitere Pools und Zonenplatzierung erfordern eine explizite Architekturerweiterung. Die Availability Zone eines Node Pools kann nicht ohne Neuerstellung geändert werden; eine andere Zone benötigt einen neuen Pool-Namen und einen geprüften Migrationsplan. Prüfen Sie tatsächliche SKE-Kapazität und geplanten Worker-Austausch vor einer Flavor- oder Topologieänderung.

STACKIT Dokumentation docs.stackit.cloud SKE Node Pools verwalten Dokumentation öffnen

Ingress-Ebene (Durchsatz)

Der implementierte Einstiegspunkt ist Envoy Gateway mit HTTPRoutes, kein älterer Ingress. Vergleichen Sie Gateway- und Service-Verhalten mit Anwendungs- und Datenbanklatenz vor einer Worker-Größenänderung. Der optionale clusterinterne Lastgenerator umgeht öffentliches Gateway, DNS und TLS; ergänzen Sie einen freigegebenen externen End-to-End-Test. Dieses Asset behauptet keine gemessene öffentliche Durchsatzgrenze.

Storage-Ebene (Performance persistenter Volumes)

Spring Music speichert seine maßgeblichen Daten in Flex. In dieser Basis gibt es kein Anwendungs-PersistentVolume für Rightsizing. node_pool_volume_size betrifft Worker-Speicher, nicht Datenbankkapazität. Nutzen Sie die Flex-Speichereinstellungen für Albumdaten und bewerten Sie Wachstum, Abfrage-I/O, Aufbewahrung und Recovery gemeinsam. Ergänzen Sie Kubernetes-Speicher nur für einen separat entworfenen Persistenzbedarf.

Optimize-Workflow für Replatform-Workloads

Repräsentative Metriken, fachliche Abnahmegrenzen, aktuelle Konfiguration und Kosten erfassen.
Eine Hypothese auswählen: Pod-Budget, Worker-Kapazität, Gateway oder Datenbankdruck.
Erwartete Verbesserung und Rollback-Schwelle festlegen; erforderliche Backups und Recovery prüfen.
Einen gespeicherten Terraform-Plan prüfen, fachfremde Änderungen ablehnen und im freigegebenen Fenster anwenden.
Rollout, Gateway, Albumdaten, tatsächliche Scrapes, Latenz, Fehler, Kapazität und Kosten gegen die Baseline validieren.
Die Änderung nur beibehalten, wenn das vereinbarte Beobachtungsfenster die Abnahme erfüllt; andernfalls dem vorab freigegebenen Rücknahme- oder Recovery-Verfahren folgen.

Rollback und Abnahme

Stellen Sie bei reversiblen Konfigurationsänderungen die zuvor geprüften Werte wieder her und prüfen Sie vor dem Apply einen neuen Plan. Setzen Sie nicht voraus, dass eine kleinere Datenbank oder die Rückkehr zur alten Speicherklasse unterstützt wird. War HPA das Experiment, deaktivieren Sie es und stellen Sie die gewünschte Replikazahl über die geprüfte Konfiguration wieder her; bestätigen Sie danach ein stabiles Deployment.

Dokumentieren Sie Vorher-/Nachher-Nachweise, Konfigurationsstand, fachliche Ergebnisse und Kostenwirkung. Ein Datenbank-Migrations-Rollback ersetzt nicht die Rücknahme einer Optimierungsänderung.

Hinweise

Der Live-Referenztest bestätigte den Workload mit einer Replika, Datenmigration und Rollback sowie den Dashboard-/Scrape-Pfad. Er wies weder Autoscaling-Verhalten noch optimales Sizing, Produktionslastkapazität oder Hochverfügbarkeit nach. Erheben Sie für jede dieser Entscheidungen neue Nachweise.

Externe Quelle kubernetes.io Kubernetes Horizontal Pod Autoscaler Regelkreis, Metrikvoraussetzungen und Skalierungsgrenzen der Kubernetes-Referenz vor der Aktivierung von Autoscaling prüfen. Externe Seite öffnen Führt von der Route weg

Szenario

Wählen Sie nach Migrationsabnahme und Stabilisierung anhand des gemessenen Workload-Verhaltens jeweils eine Optimierung. Dieses Asset behandelt Pod-Ressourcen, Worker-Kapazität, optionales HPA und PostgreSQL Flex. Es behauptet nicht, dass diese Änderungen im Migrationstest erprobt wurden.

Referenzimplementierung fortführen

Führen Sie dieselbe Terraform-, Helm-, Spring-Music-JAR-, PostgreSQL-Flex- und Observability-Implementierung fort, die für Bereitstellung, Probe, Cutover und Rollback genutzt wurde. Führen Sie kein zweites Beispiel ein und keine Kapazitätsexperimente im Migrationsfenster durch.

Code & Registry github.com Spring Boot Kubernetes Replatform Referenz Dieselben versionierten Variablen, Deployment-Ressourcen und Dashboards wie im Migrations- und Stabilisierungsworkflow verwenden. Repository öffnen

Observability-Dashboard für Entscheidungen

Öffnen Sie grafana_dashboard_url oder den Ordner SCF Replatform. Terraform verwaltet acht Panels.

Replatform-Grafana-Dashboard mit Cluster-CPU und -Speicher, einem Spring-Boot-Pod, Anwendungsanfragen und PostgreSQL-Flex-Metriken über eine Stunde

Aufnahme der Referenzbereitstellung vom 25. September 2026, 14:41 bis 15:41 UTC. Sie zeigt eine Stunde Testbetrieb mit geringer Last, keine repräsentative Basis für Produktions-Sizing. Bewerten Sie Anwendungsaktivität gemeinsam mit Datenbankverfügbarkeit und -auslastung, bevor Sie einen Optimierungskandidaten auswählen. Die folgende Tabelle erläutert die Grenzen dieser Signale.

Seitlich wischen, um die ganze Tabelle zu sehen

Panelgruppe	Unterstützte Entscheidung	Interpretationsgrenze
Cluster-CPU und -Speicher	Worker-Auslastung und Gesamtkapazität	Die CPU-Abfrage zeigt belegte Kerne, keinen Auslastungsprozentsatz; Cluster-Summen identifizieren keinen einzelnen Pod-Engpass
Laufende Pods	Vorhandensein des Workloads	Ein Scrape-Ersatzwert beweist nicht, dass alle Replikas gesund sind; Kubernetes-Rollout und Soll-Replikazahl prüfen
Anwendungsanfragen	Anfragerate und mittlere Dauer	Der Boot-2-Adapter liefert keine Latenzperzentile und kein vollständiges Fehlerraten-SLO
PostgreSQL-Verfügbarkeit und -Verbindungen	Datenbankerreichbarkeit und Verbindungsdruck	`pg_up` und tatsächlichen Scrape-Zustand unabhängig prüfen
PostgreSQL-Transaktionen	Commit- und Rollback-Trends	Veränderungen mit Anfragelast und Anwendungsverhalten korrelieren
PostgreSQL-Cache-Treffer	Verhalten des Lesecaches	Geringe Anfragelast und fehlende Zeitreihen begründen keinen Kapazitätsbedarf
Temporäre PostgreSQL-Bytes und Sperren	Untersuchung von Abfragen oder Konkurrenz	Mehr Rechenleistung behebt Abfrage- oder Sperrprobleme nicht automatisch

Prüfen Sie vor der Interpretation echte up=1-Messwerte für beide Scrape-Jobs. Einige Cluster-Panels enthalten Ersatzwerte; eine dargestellte Null belegt daher keinen Nullverbrauch. Begrenzen Sie Abfragen auf den gewünschten Cluster und die Datenbank, wenn eine Datenquelle mehrere Workloads enthält. Nutzen Sie zusätzliche Telemetrie und fachliche Tests für Latenzperzentile, Fehler und Recovery-Ziele.

Optimierungssignale und Leitplanken

Erfassen Sie eine repräsentative Baseline einschließlich Spitzenzeiten, geplanter Arbeit, JVM-Aufwärmphase und Datenbankwartung. Vereinbaren Sie Beobachtungsfenster, fachliche SLOs, Kapazitätsreserve und Kostenziel vor der Änderung. Vierzehn Tage können ein Ausgangspunkt für die Beobachtung sein, sind aber keine feste Regel.

Pod-Ressourcenkandidat: Throttling, Neustarts, Heap- oder Working-Set-Druck sind auf Anwendung oder Sidecar begrenzt.
Worker-Kapazitätskandidat: Pods warten auf Scheduling, zuweisbare Ressourcen fehlen oder die Rollout-Reserve im Pool reicht nicht aus.
Datenbankkandidat: Verbindungs-, Transaktions-, Sperr-, Speicher- oder Abfragedruck korreliert mit fachlicher Latenz.
Scale-in-Kandidat: Dauerhafte Reserven nach Berücksichtigung von Spitzen, Rollout und Recovery, ohne ungelöste kritische Incidents.

Bewahren Sie Baseline, vorherige Konfiguration, Rollback-Plan und Entscheidungsschwellen auf. Fehlende Metriken, fehlgeschlagene Alarmzustellung oder ausschließlich synthetischer Traffic reichen als Nachweis für eine produktive Verkleinerung nicht aus.

Metriken aus PostgreSQL Flex für Optimize

Bewerten Sie Datenbank- und Anwendungssignale gemeinsam. Mehr Pods erhöhen den Verbindungsbedarf und können den Engpass zu Flex verlagern. Trennen Sie Connection-Pool-Grenzen, teure Abfragen, Sperrkonflikte und Speicherdruck von tatsächlichen CPU- oder RAM-Engpässen.

Nutzen Sie die Anleitung zum PostgreSQL-Flex-Monitoring , um Service-Metriken zusammen mit dem Anwendungsverhalten zu interpretieren.

PostgreSQL Flex für Rightsizing und Tuning

Die Referenz stellt postgres_flex_cpu, postgres_flex_ram, postgres_flex_replicas, postgres_flex_storage_class und postgres_flex_storage_size bereit. CPU, RAM und die Auswahl Single oder Replica bestimmen einen Flavor aus dem aktuellen Projektkatalog. Wählen Sie eine angebotene Kombination; setzen Sie weder beliebige Werte noch einen Wechsel ohne Neuerstellung voraus.

Prüfen Sie Plan und Service-Einschränkungen vor der Freigabe. Behandeln Sie einen Datenbankaustausch als neue Migration mit verifizierter Recovery, nicht als Routine-Resize. Speicherwachstum und Service-Plan-Wechsel lassen sich möglicherweise nicht durch alte Variablenwerte zurücknehmen. Bestätigen Sie Recovery-Pfad und Wartungsfenster vor der Änderung.

Der getestete Migrations-Rollback stellt Anwendungsdaten wieder her; er macht weder Infrastruktur-Resizing rückgängig noch weist er Managed-Flex-Restore nach. Validieren Sie das erforderliche Recovery-Verfahren separat.

STACKIT Dokumentation docs.stackit.cloud PostgreSQL-Flex-Flavors und Performance-Klassen Dokumentation öffnen

Aus der STACKIT-DokuVerfügbare Flavors und Leistungsklassen › FlavorStand der Quelle 06.07.2026 · übernommen 05.10.2026

Seitlich wischen, um die ganze Tabelle zu sehen

Beschreibung	ID	CPU	Memory	`max_connections`	`shared_buffers`	`work_mem`	`maintenance_work_mem`	`effective_cache_size`
Small, Compute optimized	2.4	2	4 GB	95	950 MB	14 MB	380 MB	2660 MB
Small, Memory optimized	2.16	2	16 GB	385	3950 MB	14 MB	1580 MB	11060 MB
Medium, Compute optimized	4.8	4	8 GB	195	1950 MB	14 MB	780 MB	5460 MB
Medium, Memory optimized	4.32	4	32 GB	785	7950 MB	14 MB	3180 MB	22260 MB
Large, Processor optimized	8.16	8	16 GB	385	3950 MB	14 MB	1580 MB	11060 MB
X-Large, Compute optimized	16.32	16	32 GB	785	7950 MB	14 MB	3180 MB	22260 MB
X-Large, Memory optimized	16.128	16	128 GB	3170	31950 MB	14 MB	12780 MB	89460 MB

Hinweise

CPU und Arbeitsspeicher gelten immer pro Knoten.
Das System nutzt bis zu 15 Verbindungen für interne essenzielle Prozesse wie Backup, Monitoring usw. Diese Verbindungen werden auf das Limit von max_connections angerechnet.

Was ist das?

Dieser Abschnitt wird mehrmals am Tag automatisch aus der STACKIT-Doku übernommen. Hier lässt er sich nicht ändern. Änderungen gehören in die STACKIT-Doku.

Aus der STACKIT-DokuVerfügbare Flavors und Leistungsklassen › LeistungsklassenStand der Quelle 06.07.2026 · übernommen 05.10.2026

Seitlich wischen, um die ganze Tabelle zu sehen

Beschreibung	ID	Max. IOPS	Max. Durchsatz (MB/s)
Leistungsklasse 2	`premium-perf2-stackit`	1000	100
Leistungsklasse 4	`premium-perf4-stackit`	2000	150
Leistungsklasse 6	`premium-perf6-stackit`	5000	200
Leistungsklasse 8	`premium-perf8-stackit`	10000	250
Leistungsklasse 10	`premium-perf10-stackit`	15000	300
Leistungsklasse 12	`premium-perf12-stackit`	20000	350

Aktuell bieten wir drei Typen von Instanzen an. Für jeden Typ ist ein anderer Satz an Flavor verfügbar.

Was ist das?

Dieser Abschnitt wird mehrmals am Tag automatisch aus der STACKIT-Doku übernommen. Hier lässt er sich nicht ändern. Änderungen gehören in die STACKIT-Doku.

Pod-Ressourcen und JVM-Budget

Die Referenz definiert Ressourcen im Spring-Boot-Deployment in main.tf, nicht über eigene CPU- oder Speichervariablen. Java fordert 100m CPU und 512Mi Speicher an; die Limits liegen bei 500m und 1Gi. JAVA_TOOL_OPTIONS setzt den initialen Heap auf 128 MiB und den maximalen Heap auf 512 MiB. Beide Exporter-Sidecars besitzen jeweils ein eigenes Ressourcenbudget.

Vergleichen Sie tatsächlichen Working Set, Heap, Nicht-Heap-Speicher, Throttling, Startverhalten und Sidecar-Verbrauch, bevor Sie das Deployment ändern. Lassen Sie neben dem Java-Heap Raum für Threads und nativen Speicher. Ressourcenänderungen können Pods neu ausrollen und einen Workload mit einer Replika unterbrechen; planen und validieren Sie entsprechend. Erfinden Sie keine nicht unterstützten springboot_cpu- oder Speichervariablen.

Regelkreis für Pod-Autoscaling

Qualifizieren Sie Metriken, Replikaverantwortung, Anwendungssicherheit und Telemetrie pro Pod vor einem begrenzten HPA-Experiment.

HPA vergleicht die beobachtete Pod-CPU-Auslastung mit dem konfigurierten Ziel und passt die Replikazahl innerhalb von Mindest- und Höchstgrenzen an. Die Ressourcenmetrik setzt realistische Requests und eine verfügbare Kubernetes Metrics API voraus; erfolgreiches Grafana-Scraping beweist deren Funktion nicht. Die Ressourcenauslastung umfasst auch die Sidecar-Budgets. HPA allein kann keine Worker-Kapazität erzeugen.

Prüfen Sie vor einem Experiment mit mehreren Replikas Sitzungszustand, gemeinsame Schreibzugriffe, Initialisierung und Datenbankverbindungslimits. Das aktuelle Anwendungs-/Exporter-Scraping nutzt einen lastverteilten Service-Endpunkt; Replikas können wechselnd statt als getrennte Zeitreihen erfasst werden. Etablieren Sie Anwendungsscraping pro Pod und vermeiden Sie doppelte Datenbankaggregation, bevor Sie skalierten Anfrageraten oder Summen vertrauen. Diese Erweiterungen gehören nicht zum validierten Ein-Replika-Pfad.

Konfiguration für Pod-Autoscaling

Testen Sie begrenztes HPA erst nach Abschluss von Migration und Rollback-Arbeiten in einem separat freigegebenen Experiment. Diese beispielhaften Grenzen sind keine Sizing-Empfehlungen für die Produktion:

enable_springboot_hpa                            = true
springboot_hpa_min_replicas                      = 1
springboot_hpa_max_replicas                      = 3
springboot_hpa_target_cpu_utilization_percentage = 70

Das Deployment definiert außerdem springboot_replicas in Terraform. Prüfen Sie spätere Pläne auf konkurrierende Replikaänderungen und legen Sie vor unbeaufsichtigtem HPA-Betrieb eine explizite Zuständigkeit fest. Das Migrationsskript lehnt HPA-verwaltete Ziele ab; deaktivieren Sie HPA vor jeder späteren Migration und jedem Rollback.

Prüfen Sie den Plan und beobachten Sie anschließend HPA mit der konfigurierten Kubeconfig:

terraform plan -var-file=env.tfvars -out=tfplan.optimize
terraform apply tfplan.optimize
kubectl get hpa,pods -n springboot
kubectl describe hpa springboot -n springboot
kubectl top pods -n springboot --containers

Cluster- und Plattform-Rightsizing

Stellen Sie genügend Worker-Reserve bereit und berücksichtigen Sie Pool-Kapazität, Zonengrenzen und Rollout-Unterbrechungen.

STACKIT-SKE-Grafana-Dashboard mit tatsächlicher CPU- und RAM-Nutzung gegenüber Requests und Limits, einem Node, 17 laufenden Pods, keinen wartenden oder fehlgeschlagenen Pods und API-Server-Aktivität

Das SKE-Dashboard zeigt dasselbe Intervall von 14:41 bis 15:41 UTC am 25. September 2026. Die tatsächliche CPU-Nutzung beträgt etwa 2 %, während CPU-Requests etwa 34 % der Cluster-Kapazität reservieren. Das verdeutlicht, warum Scheduling-Reservierungen und gemessener Verbrauch gemeinsam zu bewerten sind. Die 17 laufenden Pods umfassen Plattformkomponenten, nicht 17 Spring-Boot-Replikas; das Workload-Dashboard oben zeigt den einzelnen Anwendungspod. Keine fehlgeschlagenen oder wartenden Pods zu diesem Zeitpunkt sind ein nützliches Zustandssignal, kein Beweis für Spitzenlast- oder Ausfalltoleranz.

Passen Sie node_pool_minimum, node_pool_maximum und node_pool_machine_type anhand aggregierter Requests, beobachteter Nachfrage, System-Overhead und Rollout-Reserve an. Gleiche Mindest- und Höchstwerte fixieren die Pool-Größe; ein höheres HPA-Maximum kann diese Kapazitätsgrenze nicht überwinden.

Die Referenz konfiguriert einen Node Pool. Weitere Pools und Zonenplatzierung erfordern eine explizite Architekturerweiterung. Die Availability Zone eines Node Pools kann nicht ohne Neuerstellung geändert werden; eine andere Zone benötigt einen neuen Pool-Namen und einen geprüften Migrationsplan. Prüfen Sie tatsächliche SKE-Kapazität und geplanten Worker-Austausch vor einer Flavor- oder Topologieänderung.

STACKIT Dokumentation docs.stackit.cloud SKE Node Pools verwalten Dokumentation öffnen

Ingress-Ebene (Durchsatz)

Der implementierte Einstiegspunkt ist Envoy Gateway mit HTTPRoutes, kein älterer Ingress. Vergleichen Sie Gateway- und Service-Verhalten mit Anwendungs- und Datenbanklatenz vor einer Worker-Größenänderung. Der optionale clusterinterne Lastgenerator umgeht öffentliches Gateway, DNS und TLS; ergänzen Sie einen freigegebenen externen End-to-End-Test. Dieses Asset behauptet keine gemessene öffentliche Durchsatzgrenze.

Storage-Ebene (Performance persistenter Volumes)

Spring Music speichert seine maßgeblichen Daten in Flex. In dieser Basis gibt es kein Anwendungs-PersistentVolume für Rightsizing. node_pool_volume_size betrifft Worker-Speicher, nicht Datenbankkapazität. Nutzen Sie die Flex-Speichereinstellungen für Albumdaten und bewerten Sie Wachstum, Abfrage-I/O, Aufbewahrung und Recovery gemeinsam. Ergänzen Sie Kubernetes-Speicher nur für einen separat entworfenen Persistenzbedarf.

Optimize-Workflow für Replatform-Workloads

Repräsentative Metriken, fachliche Abnahmegrenzen, aktuelle Konfiguration und Kosten erfassen.
Eine Hypothese auswählen: Pod-Budget, Worker-Kapazität, Gateway oder Datenbankdruck.
Erwartete Verbesserung und Rollback-Schwelle festlegen; erforderliche Backups und Recovery prüfen.
Einen gespeicherten Terraform-Plan prüfen, fachfremde Änderungen ablehnen und im freigegebenen Fenster anwenden.
Rollout, Gateway, Albumdaten, tatsächliche Scrapes, Latenz, Fehler, Kapazität und Kosten gegen die Baseline validieren.
Die Änderung nur beibehalten, wenn das vereinbarte Beobachtungsfenster die Abnahme erfüllt; andernfalls dem vorab freigegebenen Rücknahme- oder Recovery-Verfahren folgen.

Rollback und Abnahme

Stellen Sie bei reversiblen Konfigurationsänderungen die zuvor geprüften Werte wieder her und prüfen Sie vor dem Apply einen neuen Plan. Setzen Sie nicht voraus, dass eine kleinere Datenbank oder die Rückkehr zur alten Speicherklasse unterstützt wird. War HPA das Experiment, deaktivieren Sie es und stellen Sie die gewünschte Replikazahl über die geprüfte Konfiguration wieder her; bestätigen Sie danach ein stabiles Deployment.

Dokumentieren Sie Vorher-/Nachher-Nachweise, Konfigurationsstand, fachliche Ergebnisse und Kostenwirkung. Ein Datenbank-Migrations-Rollback ersetzt nicht die Rücknahme einer Optimierungsänderung.

Hinweise

Der Live-Referenztest bestätigte den Workload mit einer Replika, Datenmigration und Rollback sowie den Dashboard-/Scrape-Pfad. Er wies weder Autoscaling-Verhalten noch optimales Sizing, Produktionslastkapazität oder Hochverfügbarkeit nach. Erheben Sie für jede dieser Entscheidungen neue Nachweise.

Externe Quelle kubernetes.io Kubernetes Horizontal Pod Autoscaler Regelkreis, Metrikvoraussetzungen und Skalierungsgrenzen der Kubernetes-Referenz vor der Aktivierung von Autoscaling prüfen. Externe Seite öffnen Führt von der Route weg

OPS

PostgreSQL Flex passend dimensionieren

Migration design-and-mobilize use-cases migrate optimize replatform kubernetes rightsizing hpa spring-boot postgresql

Replatform Spring Boot auf Kubernetes mit Rightsizing und Pod-Skalierung optimieren

STACKIT

Dasselbe Spring-Boot-Replatform anhand gemessener Pod- und Node-Kapazität, PostgreSQL-Flex-Tuning, Skalierungsleitplanken und reversibler Änderungen optimieren.

Code & Registry github.com Spring Boot Kubernetes Replatform Referenz Dieselben versionierten Variablen, Deployment-Ressourcen und Dashboards wie im Migrations- und Stabilisierungsworkflow verwenden. Repository öffnen

STACKIT

Der souveräne europäische Cloud-Anbieter hinter dem Framework, mit IaaS und PaaS aus deutschen und österreichischen Rechenzentren und voller Unabhängigkeit.

Szenario

Wählen Sie nach Migrationsabnahme und Stabilisierung anhand des gemessenen Workload-Verhaltens jeweils eine Optimierung. Dieses Asset behandelt Pod-Ressourcen, Worker-Kapazität, optionales HPA und PostgreSQL Flex. Es behauptet nicht, dass diese Änderungen im Migrationstest erprobt wurden.

Referenzimplementierung fortführen

Führen Sie dieselbe Terraform-, Helm-, Spring-Music-JAR-, PostgreSQL-Flex- und Observability-Implementierung fort, die für Bereitstellung, Probe, Cutover und Rollback genutzt wurde. Führen Sie kein zweites Beispiel ein und keine Kapazitätsexperimente im Migrationsfenster durch.

Observability-Dashboard für Entscheidungen

Öffnen Sie grafana_dashboard_url oder den Ordner SCF Replatform. Terraform verwaltet acht Panels.

Replatform-Grafana-Dashboard mit Cluster-CPU und -Speicher, einem Spring-Boot-Pod, Anwendungsanfragen und PostgreSQL-Flex-Metriken über eine Stunde

Aufnahme der Referenzbereitstellung vom 25. September 2026, 14:41 bis 15:41 UTC. Sie zeigt eine Stunde Testbetrieb mit geringer Last, keine repräsentative Basis für Produktions-Sizing. Bewerten Sie Anwendungsaktivität gemeinsam mit Datenbankverfügbarkeit und -auslastung, bevor Sie einen Optimierungskandidaten auswählen. Die folgende Tabelle erläutert die Grenzen dieser Signale.

Seitlich wischen, um die ganze Tabelle zu sehen

Panelgruppe	Unterstützte Entscheidung	Interpretationsgrenze
Cluster-CPU und -Speicher	Worker-Auslastung und Gesamtkapazität	Die CPU-Abfrage zeigt belegte Kerne, keinen Auslastungsprozentsatz; Cluster-Summen identifizieren keinen einzelnen Pod-Engpass
Laufende Pods	Vorhandensein des Workloads	Ein Scrape-Ersatzwert beweist nicht, dass alle Replikas gesund sind; Kubernetes-Rollout und Soll-Replikazahl prüfen
Anwendungsanfragen	Anfragerate und mittlere Dauer	Der Boot-2-Adapter liefert keine Latenzperzentile und kein vollständiges Fehlerraten-SLO
PostgreSQL-Verfügbarkeit und -Verbindungen	Datenbankerreichbarkeit und Verbindungsdruck	`pg_up` und tatsächlichen Scrape-Zustand unabhängig prüfen
PostgreSQL-Transaktionen	Commit- und Rollback-Trends	Veränderungen mit Anfragelast und Anwendungsverhalten korrelieren
PostgreSQL-Cache-Treffer	Verhalten des Lesecaches	Geringe Anfragelast und fehlende Zeitreihen begründen keinen Kapazitätsbedarf
Temporäre PostgreSQL-Bytes und Sperren	Untersuchung von Abfragen oder Konkurrenz	Mehr Rechenleistung behebt Abfrage- oder Sperrprobleme nicht automatisch

Prüfen Sie vor der Interpretation echte up=1-Messwerte für beide Scrape-Jobs. Einige Cluster-Panels enthalten Ersatzwerte; eine dargestellte Null belegt daher keinen Nullverbrauch. Begrenzen Sie Abfragen auf den gewünschten Cluster und die Datenbank, wenn eine Datenquelle mehrere Workloads enthält. Nutzen Sie zusätzliche Telemetrie und fachliche Tests für Latenzperzentile, Fehler und Recovery-Ziele.

Optimierungssignale und Leitplanken

Erfassen Sie eine repräsentative Baseline einschließlich Spitzenzeiten, geplanter Arbeit, JVM-Aufwärmphase und Datenbankwartung. Vereinbaren Sie Beobachtungsfenster, fachliche SLOs, Kapazitätsreserve und Kostenziel vor der Änderung. Vierzehn Tage können ein Ausgangspunkt für die Beobachtung sein, sind aber keine feste Regel.

Pod-Ressourcenkandidat: Throttling, Neustarts, Heap- oder Working-Set-Druck sind auf Anwendung oder Sidecar begrenzt.
Worker-Kapazitätskandidat: Pods warten auf Scheduling, zuweisbare Ressourcen fehlen oder die Rollout-Reserve im Pool reicht nicht aus.
Datenbankkandidat: Verbindungs-, Transaktions-, Sperr-, Speicher- oder Abfragedruck korreliert mit fachlicher Latenz.
Scale-in-Kandidat: Dauerhafte Reserven nach Berücksichtigung von Spitzen, Rollout und Recovery, ohne ungelöste kritische Incidents.

Bewahren Sie Baseline, vorherige Konfiguration, Rollback-Plan und Entscheidungsschwellen auf. Fehlende Metriken, fehlgeschlagene Alarmzustellung oder ausschließlich synthetischer Traffic reichen als Nachweis für eine produktive Verkleinerung nicht aus.

Metriken aus PostgreSQL Flex für Optimize

Bewerten Sie Datenbank- und Anwendungssignale gemeinsam. Mehr Pods erhöhen den Verbindungsbedarf und können den Engpass zu Flex verlagern. Trennen Sie Connection-Pool-Grenzen, teure Abfragen, Sperrkonflikte und Speicherdruck von tatsächlichen CPU- oder RAM-Engpässen.

Nutzen Sie die Anleitung zum PostgreSQL-Flex-Monitoring , um Service-Metriken zusammen mit dem Anwendungsverhalten zu interpretieren.

PostgreSQL Flex für Rightsizing und Tuning

Die Referenz stellt postgres_flex_cpu, postgres_flex_ram, postgres_flex_replicas, postgres_flex_storage_class und postgres_flex_storage_size bereit. CPU, RAM und die Auswahl Single oder Replica bestimmen einen Flavor aus dem aktuellen Projektkatalog. Wählen Sie eine angebotene Kombination; setzen Sie weder beliebige Werte noch einen Wechsel ohne Neuerstellung voraus.

Prüfen Sie Plan und Service-Einschränkungen vor der Freigabe. Behandeln Sie einen Datenbankaustausch als neue Migration mit verifizierter Recovery, nicht als Routine-Resize. Speicherwachstum und Service-Plan-Wechsel lassen sich möglicherweise nicht durch alte Variablenwerte zurücknehmen. Bestätigen Sie Recovery-Pfad und Wartungsfenster vor der Änderung.

Der getestete Migrations-Rollback stellt Anwendungsdaten wieder her; er macht weder Infrastruktur-Resizing rückgängig noch weist er Managed-Flex-Restore nach. Validieren Sie das erforderliche Recovery-Verfahren separat.

STACKIT Dokumentation docs.stackit.cloud PostgreSQL-Flex-Flavors und Performance-Klassen Dokumentation öffnen

Aus der STACKIT-DokuVerfügbare Flavors und Leistungsklassen › FlavorStand der Quelle 06.07.2026 · übernommen 05.10.2026

Seitlich wischen, um die ganze Tabelle zu sehen

Beschreibung	ID	CPU	Memory	`max_connections`	`shared_buffers`	`work_mem`	`maintenance_work_mem`	`effective_cache_size`
Small, Compute optimized	2.4	2	4 GB	95	950 MB	14 MB	380 MB	2660 MB
Small, Memory optimized	2.16	2	16 GB	385	3950 MB	14 MB	1580 MB	11060 MB
Medium, Compute optimized	4.8	4	8 GB	195	1950 MB	14 MB	780 MB	5460 MB
Medium, Memory optimized	4.32	4	32 GB	785	7950 MB	14 MB	3180 MB	22260 MB
Large, Processor optimized	8.16	8	16 GB	385	3950 MB	14 MB	1580 MB	11060 MB
X-Large, Compute optimized	16.32	16	32 GB	785	7950 MB	14 MB	3180 MB	22260 MB
X-Large, Memory optimized	16.128	16	128 GB	3170	31950 MB	14 MB	12780 MB	89460 MB

Hinweise

CPU und Arbeitsspeicher gelten immer pro Knoten.
Das System nutzt bis zu 15 Verbindungen für interne essenzielle Prozesse wie Backup, Monitoring usw. Diese Verbindungen werden auf das Limit von max_connections angerechnet.

Was ist das?

Dieser Abschnitt wird mehrmals am Tag automatisch aus der STACKIT-Doku übernommen. Hier lässt er sich nicht ändern. Änderungen gehören in die STACKIT-Doku.

Aus der STACKIT-DokuVerfügbare Flavors und Leistungsklassen › LeistungsklassenStand der Quelle 06.07.2026 · übernommen 05.10.2026

Seitlich wischen, um die ganze Tabelle zu sehen

Beschreibung	ID	Max. IOPS	Max. Durchsatz (MB/s)
Leistungsklasse 2	`premium-perf2-stackit`	1000	100
Leistungsklasse 4	`premium-perf4-stackit`	2000	150
Leistungsklasse 6	`premium-perf6-stackit`	5000	200
Leistungsklasse 8	`premium-perf8-stackit`	10000	250
Leistungsklasse 10	`premium-perf10-stackit`	15000	300
Leistungsklasse 12	`premium-perf12-stackit`	20000	350

Aktuell bieten wir drei Typen von Instanzen an. Für jeden Typ ist ein anderer Satz an Flavor verfügbar.

Was ist das?

Dieser Abschnitt wird mehrmals am Tag automatisch aus der STACKIT-Doku übernommen. Hier lässt er sich nicht ändern. Änderungen gehören in die STACKIT-Doku.

Pod-Ressourcen und JVM-Budget

Die Referenz definiert Ressourcen im Spring-Boot-Deployment in main.tf, nicht über eigene CPU- oder Speichervariablen. Java fordert 100m CPU und 512Mi Speicher an; die Limits liegen bei 500m und 1Gi. JAVA_TOOL_OPTIONS setzt den initialen Heap auf 128 MiB und den maximalen Heap auf 512 MiB. Beide Exporter-Sidecars besitzen jeweils ein eigenes Ressourcenbudget.

Vergleichen Sie tatsächlichen Working Set, Heap, Nicht-Heap-Speicher, Throttling, Startverhalten und Sidecar-Verbrauch, bevor Sie das Deployment ändern. Lassen Sie neben dem Java-Heap Raum für Threads und nativen Speicher. Ressourcenänderungen können Pods neu ausrollen und einen Workload mit einer Replika unterbrechen; planen und validieren Sie entsprechend. Erfinden Sie keine nicht unterstützten springboot_cpu- oder Speichervariablen.

Regelkreis für Pod-Autoscaling

Qualifizieren Sie Metriken, Replikaverantwortung, Anwendungssicherheit und Telemetrie pro Pod vor einem begrenzten HPA-Experiment.

HPA vergleicht die beobachtete Pod-CPU-Auslastung mit dem konfigurierten Ziel und passt die Replikazahl innerhalb von Mindest- und Höchstgrenzen an. Die Ressourcenmetrik setzt realistische Requests und eine verfügbare Kubernetes Metrics API voraus; erfolgreiches Grafana-Scraping beweist deren Funktion nicht. Die Ressourcenauslastung umfasst auch die Sidecar-Budgets. HPA allein kann keine Worker-Kapazität erzeugen.

Prüfen Sie vor einem Experiment mit mehreren Replikas Sitzungszustand, gemeinsame Schreibzugriffe, Initialisierung und Datenbankverbindungslimits. Das aktuelle Anwendungs-/Exporter-Scraping nutzt einen lastverteilten Service-Endpunkt; Replikas können wechselnd statt als getrennte Zeitreihen erfasst werden. Etablieren Sie Anwendungsscraping pro Pod und vermeiden Sie doppelte Datenbankaggregation, bevor Sie skalierten Anfrageraten oder Summen vertrauen. Diese Erweiterungen gehören nicht zum validierten Ein-Replika-Pfad.

Konfiguration für Pod-Autoscaling

Testen Sie begrenztes HPA erst nach Abschluss von Migration und Rollback-Arbeiten in einem separat freigegebenen Experiment. Diese beispielhaften Grenzen sind keine Sizing-Empfehlungen für die Produktion:

enable_springboot_hpa                            = true
springboot_hpa_min_replicas                      = 1
springboot_hpa_max_replicas                      = 3
springboot_hpa_target_cpu_utilization_percentage = 70

Das Deployment definiert außerdem springboot_replicas in Terraform. Prüfen Sie spätere Pläne auf konkurrierende Replikaänderungen und legen Sie vor unbeaufsichtigtem HPA-Betrieb eine explizite Zuständigkeit fest. Das Migrationsskript lehnt HPA-verwaltete Ziele ab; deaktivieren Sie HPA vor jeder späteren Migration und jedem Rollback.

Prüfen Sie den Plan und beobachten Sie anschließend HPA mit der konfigurierten Kubeconfig:

terraform plan -var-file=env.tfvars -out=tfplan.optimize
terraform apply tfplan.optimize
kubectl get hpa,pods -n springboot
kubectl describe hpa springboot -n springboot
kubectl top pods -n springboot --containers

Cluster- und Plattform-Rightsizing

Stellen Sie genügend Worker-Reserve bereit und berücksichtigen Sie Pool-Kapazität, Zonengrenzen und Rollout-Unterbrechungen.

STACKIT-SKE-Grafana-Dashboard mit tatsächlicher CPU- und RAM-Nutzung gegenüber Requests und Limits, einem Node, 17 laufenden Pods, keinen wartenden oder fehlgeschlagenen Pods und API-Server-Aktivität

Das SKE-Dashboard zeigt dasselbe Intervall von 14:41 bis 15:41 UTC am 25. September 2026. Die tatsächliche CPU-Nutzung beträgt etwa 2 %, während CPU-Requests etwa 34 % der Cluster-Kapazität reservieren. Das verdeutlicht, warum Scheduling-Reservierungen und gemessener Verbrauch gemeinsam zu bewerten sind. Die 17 laufenden Pods umfassen Plattformkomponenten, nicht 17 Spring-Boot-Replikas; das Workload-Dashboard oben zeigt den einzelnen Anwendungspod. Keine fehlgeschlagenen oder wartenden Pods zu diesem Zeitpunkt sind ein nützliches Zustandssignal, kein Beweis für Spitzenlast- oder Ausfalltoleranz.

Passen Sie node_pool_minimum, node_pool_maximum und node_pool_machine_type anhand aggregierter Requests, beobachteter Nachfrage, System-Overhead und Rollout-Reserve an. Gleiche Mindest- und Höchstwerte fixieren die Pool-Größe; ein höheres HPA-Maximum kann diese Kapazitätsgrenze nicht überwinden.

Die Referenz konfiguriert einen Node Pool. Weitere Pools und Zonenplatzierung erfordern eine explizite Architekturerweiterung. Die Availability Zone eines Node Pools kann nicht ohne Neuerstellung geändert werden; eine andere Zone benötigt einen neuen Pool-Namen und einen geprüften Migrationsplan. Prüfen Sie tatsächliche SKE-Kapazität und geplanten Worker-Austausch vor einer Flavor- oder Topologieänderung.

STACKIT Dokumentation docs.stackit.cloud SKE Node Pools verwalten Dokumentation öffnen

Ingress-Ebene (Durchsatz)

Der implementierte Einstiegspunkt ist Envoy Gateway mit HTTPRoutes, kein älterer Ingress. Vergleichen Sie Gateway- und Service-Verhalten mit Anwendungs- und Datenbanklatenz vor einer Worker-Größenänderung. Der optionale clusterinterne Lastgenerator umgeht öffentliches Gateway, DNS und TLS; ergänzen Sie einen freigegebenen externen End-to-End-Test. Dieses Asset behauptet keine gemessene öffentliche Durchsatzgrenze.

Storage-Ebene (Performance persistenter Volumes)

Spring Music speichert seine maßgeblichen Daten in Flex. In dieser Basis gibt es kein Anwendungs-PersistentVolume für Rightsizing. node_pool_volume_size betrifft Worker-Speicher, nicht Datenbankkapazität. Nutzen Sie die Flex-Speichereinstellungen für Albumdaten und bewerten Sie Wachstum, Abfrage-I/O, Aufbewahrung und Recovery gemeinsam. Ergänzen Sie Kubernetes-Speicher nur für einen separat entworfenen Persistenzbedarf.

Optimize-Workflow für Replatform-Workloads

Repräsentative Metriken, fachliche Abnahmegrenzen, aktuelle Konfiguration und Kosten erfassen.
Eine Hypothese auswählen: Pod-Budget, Worker-Kapazität, Gateway oder Datenbankdruck.
Erwartete Verbesserung und Rollback-Schwelle festlegen; erforderliche Backups und Recovery prüfen.
Einen gespeicherten Terraform-Plan prüfen, fachfremde Änderungen ablehnen und im freigegebenen Fenster anwenden.
Rollout, Gateway, Albumdaten, tatsächliche Scrapes, Latenz, Fehler, Kapazität und Kosten gegen die Baseline validieren.
Die Änderung nur beibehalten, wenn das vereinbarte Beobachtungsfenster die Abnahme erfüllt; andernfalls dem vorab freigegebenen Rücknahme- oder Recovery-Verfahren folgen.

Rollback und Abnahme

Stellen Sie bei reversiblen Konfigurationsänderungen die zuvor geprüften Werte wieder her und prüfen Sie vor dem Apply einen neuen Plan. Setzen Sie nicht voraus, dass eine kleinere Datenbank oder die Rückkehr zur alten Speicherklasse unterstützt wird. War HPA das Experiment, deaktivieren Sie es und stellen Sie die gewünschte Replikazahl über die geprüfte Konfiguration wieder her; bestätigen Sie danach ein stabiles Deployment.

Dokumentieren Sie Vorher-/Nachher-Nachweise, Konfigurationsstand, fachliche Ergebnisse und Kostenwirkung. Ein Datenbank-Migrations-Rollback ersetzt nicht die Rücknahme einer Optimierungsänderung.

Hinweise

Der Live-Referenztest bestätigte den Workload mit einer Replika, Datenmigration und Rollback sowie den Dashboard-/Scrape-Pfad. Er wies weder Autoscaling-Verhalten noch optimales Sizing, Produktionslastkapazität oder Hochverfügbarkeit nach. Erheben Sie für jede dieser Entscheidungen neue Nachweise.

Externe Quelle kubernetes.io Kubernetes Horizontal Pod Autoscaler Regelkreis, Metrikvoraussetzungen und Skalierungsgrenzen der Kubernetes-Referenz vor der Aktivierung von Autoscaling prüfen. Externe Seite öffnen Führt von der Route weg

OPS

Pod-Budget passend dimensionieren

Migration design-and-mobilize use-cases migrate optimize replatform kubernetes rightsizing hpa spring-boot postgresql

Replatform Spring Boot auf Kubernetes mit Rightsizing und Pod-Skalierung optimieren

STACKIT

Dasselbe Spring-Boot-Replatform anhand gemessener Pod- und Node-Kapazität, PostgreSQL-Flex-Tuning, Skalierungsleitplanken und reversibler Änderungen optimieren.

Code & Registry github.com Spring Boot Kubernetes Replatform Referenz Dieselben versionierten Variablen, Deployment-Ressourcen und Dashboards wie im Migrations- und Stabilisierungsworkflow verwenden. Repository öffnen

STACKIT

Der souveräne europäische Cloud-Anbieter hinter dem Framework, mit IaaS und PaaS aus deutschen und österreichischen Rechenzentren und voller Unabhängigkeit.

Szenario

Wählen Sie nach Migrationsabnahme und Stabilisierung anhand des gemessenen Workload-Verhaltens jeweils eine Optimierung. Dieses Asset behandelt Pod-Ressourcen, Worker-Kapazität, optionales HPA und PostgreSQL Flex. Es behauptet nicht, dass diese Änderungen im Migrationstest erprobt wurden.

Referenzimplementierung fortführen

Führen Sie dieselbe Terraform-, Helm-, Spring-Music-JAR-, PostgreSQL-Flex- und Observability-Implementierung fort, die für Bereitstellung, Probe, Cutover und Rollback genutzt wurde. Führen Sie kein zweites Beispiel ein und keine Kapazitätsexperimente im Migrationsfenster durch.

Observability-Dashboard für Entscheidungen

Öffnen Sie grafana_dashboard_url oder den Ordner SCF Replatform. Terraform verwaltet acht Panels.

Replatform-Grafana-Dashboard mit Cluster-CPU und -Speicher, einem Spring-Boot-Pod, Anwendungsanfragen und PostgreSQL-Flex-Metriken über eine Stunde

Aufnahme der Referenzbereitstellung vom 25. September 2026, 14:41 bis 15:41 UTC. Sie zeigt eine Stunde Testbetrieb mit geringer Last, keine repräsentative Basis für Produktions-Sizing. Bewerten Sie Anwendungsaktivität gemeinsam mit Datenbankverfügbarkeit und -auslastung, bevor Sie einen Optimierungskandidaten auswählen. Die folgende Tabelle erläutert die Grenzen dieser Signale.

Seitlich wischen, um die ganze Tabelle zu sehen

Panelgruppe	Unterstützte Entscheidung	Interpretationsgrenze
Cluster-CPU und -Speicher	Worker-Auslastung und Gesamtkapazität	Die CPU-Abfrage zeigt belegte Kerne, keinen Auslastungsprozentsatz; Cluster-Summen identifizieren keinen einzelnen Pod-Engpass
Laufende Pods	Vorhandensein des Workloads	Ein Scrape-Ersatzwert beweist nicht, dass alle Replikas gesund sind; Kubernetes-Rollout und Soll-Replikazahl prüfen
Anwendungsanfragen	Anfragerate und mittlere Dauer	Der Boot-2-Adapter liefert keine Latenzperzentile und kein vollständiges Fehlerraten-SLO
PostgreSQL-Verfügbarkeit und -Verbindungen	Datenbankerreichbarkeit und Verbindungsdruck	`pg_up` und tatsächlichen Scrape-Zustand unabhängig prüfen
PostgreSQL-Transaktionen	Commit- und Rollback-Trends	Veränderungen mit Anfragelast und Anwendungsverhalten korrelieren
PostgreSQL-Cache-Treffer	Verhalten des Lesecaches	Geringe Anfragelast und fehlende Zeitreihen begründen keinen Kapazitätsbedarf
Temporäre PostgreSQL-Bytes und Sperren	Untersuchung von Abfragen oder Konkurrenz	Mehr Rechenleistung behebt Abfrage- oder Sperrprobleme nicht automatisch

Prüfen Sie vor der Interpretation echte up=1-Messwerte für beide Scrape-Jobs. Einige Cluster-Panels enthalten Ersatzwerte; eine dargestellte Null belegt daher keinen Nullverbrauch. Begrenzen Sie Abfragen auf den gewünschten Cluster und die Datenbank, wenn eine Datenquelle mehrere Workloads enthält. Nutzen Sie zusätzliche Telemetrie und fachliche Tests für Latenzperzentile, Fehler und Recovery-Ziele.

Optimierungssignale und Leitplanken

Erfassen Sie eine repräsentative Baseline einschließlich Spitzenzeiten, geplanter Arbeit, JVM-Aufwärmphase und Datenbankwartung. Vereinbaren Sie Beobachtungsfenster, fachliche SLOs, Kapazitätsreserve und Kostenziel vor der Änderung. Vierzehn Tage können ein Ausgangspunkt für die Beobachtung sein, sind aber keine feste Regel.

Pod-Ressourcenkandidat: Throttling, Neustarts, Heap- oder Working-Set-Druck sind auf Anwendung oder Sidecar begrenzt.
Worker-Kapazitätskandidat: Pods warten auf Scheduling, zuweisbare Ressourcen fehlen oder die Rollout-Reserve im Pool reicht nicht aus.
Datenbankkandidat: Verbindungs-, Transaktions-, Sperr-, Speicher- oder Abfragedruck korreliert mit fachlicher Latenz.
Scale-in-Kandidat: Dauerhafte Reserven nach Berücksichtigung von Spitzen, Rollout und Recovery, ohne ungelöste kritische Incidents.

Bewahren Sie Baseline, vorherige Konfiguration, Rollback-Plan und Entscheidungsschwellen auf. Fehlende Metriken, fehlgeschlagene Alarmzustellung oder ausschließlich synthetischer Traffic reichen als Nachweis für eine produktive Verkleinerung nicht aus.

Metriken aus PostgreSQL Flex für Optimize

Bewerten Sie Datenbank- und Anwendungssignale gemeinsam. Mehr Pods erhöhen den Verbindungsbedarf und können den Engpass zu Flex verlagern. Trennen Sie Connection-Pool-Grenzen, teure Abfragen, Sperrkonflikte und Speicherdruck von tatsächlichen CPU- oder RAM-Engpässen.

Nutzen Sie die Anleitung zum PostgreSQL-Flex-Monitoring , um Service-Metriken zusammen mit dem Anwendungsverhalten zu interpretieren.

PostgreSQL Flex für Rightsizing und Tuning

Die Referenz stellt postgres_flex_cpu, postgres_flex_ram, postgres_flex_replicas, postgres_flex_storage_class und postgres_flex_storage_size bereit. CPU, RAM und die Auswahl Single oder Replica bestimmen einen Flavor aus dem aktuellen Projektkatalog. Wählen Sie eine angebotene Kombination; setzen Sie weder beliebige Werte noch einen Wechsel ohne Neuerstellung voraus.

Prüfen Sie Plan und Service-Einschränkungen vor der Freigabe. Behandeln Sie einen Datenbankaustausch als neue Migration mit verifizierter Recovery, nicht als Routine-Resize. Speicherwachstum und Service-Plan-Wechsel lassen sich möglicherweise nicht durch alte Variablenwerte zurücknehmen. Bestätigen Sie Recovery-Pfad und Wartungsfenster vor der Änderung.

Der getestete Migrations-Rollback stellt Anwendungsdaten wieder her; er macht weder Infrastruktur-Resizing rückgängig noch weist er Managed-Flex-Restore nach. Validieren Sie das erforderliche Recovery-Verfahren separat.

STACKIT Dokumentation docs.stackit.cloud PostgreSQL-Flex-Flavors und Performance-Klassen Dokumentation öffnen

Aus der STACKIT-DokuVerfügbare Flavors und Leistungsklassen › FlavorStand der Quelle 06.07.2026 · übernommen 05.10.2026

Seitlich wischen, um die ganze Tabelle zu sehen

Beschreibung	ID	CPU	Memory	`max_connections`	`shared_buffers`	`work_mem`	`maintenance_work_mem`	`effective_cache_size`
Small, Compute optimized	2.4	2	4 GB	95	950 MB	14 MB	380 MB	2660 MB
Small, Memory optimized	2.16	2	16 GB	385	3950 MB	14 MB	1580 MB	11060 MB
Medium, Compute optimized	4.8	4	8 GB	195	1950 MB	14 MB	780 MB	5460 MB
Medium, Memory optimized	4.32	4	32 GB	785	7950 MB	14 MB	3180 MB	22260 MB
Large, Processor optimized	8.16	8	16 GB	385	3950 MB	14 MB	1580 MB	11060 MB
X-Large, Compute optimized	16.32	16	32 GB	785	7950 MB	14 MB	3180 MB	22260 MB
X-Large, Memory optimized	16.128	16	128 GB	3170	31950 MB	14 MB	12780 MB	89460 MB

Hinweise

CPU und Arbeitsspeicher gelten immer pro Knoten.
Das System nutzt bis zu 15 Verbindungen für interne essenzielle Prozesse wie Backup, Monitoring usw. Diese Verbindungen werden auf das Limit von max_connections angerechnet.

Was ist das?

Dieser Abschnitt wird mehrmals am Tag automatisch aus der STACKIT-Doku übernommen. Hier lässt er sich nicht ändern. Änderungen gehören in die STACKIT-Doku.

Aus der STACKIT-DokuVerfügbare Flavors und Leistungsklassen › LeistungsklassenStand der Quelle 06.07.2026 · übernommen 05.10.2026

Seitlich wischen, um die ganze Tabelle zu sehen

Beschreibung	ID	Max. IOPS	Max. Durchsatz (MB/s)
Leistungsklasse 2	`premium-perf2-stackit`	1000	100
Leistungsklasse 4	`premium-perf4-stackit`	2000	150
Leistungsklasse 6	`premium-perf6-stackit`	5000	200
Leistungsklasse 8	`premium-perf8-stackit`	10000	250
Leistungsklasse 10	`premium-perf10-stackit`	15000	300
Leistungsklasse 12	`premium-perf12-stackit`	20000	350

Aktuell bieten wir drei Typen von Instanzen an. Für jeden Typ ist ein anderer Satz an Flavor verfügbar.

Was ist das?

Dieser Abschnitt wird mehrmals am Tag automatisch aus der STACKIT-Doku übernommen. Hier lässt er sich nicht ändern. Änderungen gehören in die STACKIT-Doku.

Pod-Ressourcen und JVM-Budget

Die Referenz definiert Ressourcen im Spring-Boot-Deployment in main.tf, nicht über eigene CPU- oder Speichervariablen. Java fordert 100m CPU und 512Mi Speicher an; die Limits liegen bei 500m und 1Gi. JAVA_TOOL_OPTIONS setzt den initialen Heap auf 128 MiB und den maximalen Heap auf 512 MiB. Beide Exporter-Sidecars besitzen jeweils ein eigenes Ressourcenbudget.

Vergleichen Sie tatsächlichen Working Set, Heap, Nicht-Heap-Speicher, Throttling, Startverhalten und Sidecar-Verbrauch, bevor Sie das Deployment ändern. Lassen Sie neben dem Java-Heap Raum für Threads und nativen Speicher. Ressourcenänderungen können Pods neu ausrollen und einen Workload mit einer Replika unterbrechen; planen und validieren Sie entsprechend. Erfinden Sie keine nicht unterstützten springboot_cpu- oder Speichervariablen.

Regelkreis für Pod-Autoscaling

Qualifizieren Sie Metriken, Replikaverantwortung, Anwendungssicherheit und Telemetrie pro Pod vor einem begrenzten HPA-Experiment.

HPA vergleicht die beobachtete Pod-CPU-Auslastung mit dem konfigurierten Ziel und passt die Replikazahl innerhalb von Mindest- und Höchstgrenzen an. Die Ressourcenmetrik setzt realistische Requests und eine verfügbare Kubernetes Metrics API voraus; erfolgreiches Grafana-Scraping beweist deren Funktion nicht. Die Ressourcenauslastung umfasst auch die Sidecar-Budgets. HPA allein kann keine Worker-Kapazität erzeugen.

Prüfen Sie vor einem Experiment mit mehreren Replikas Sitzungszustand, gemeinsame Schreibzugriffe, Initialisierung und Datenbankverbindungslimits. Das aktuelle Anwendungs-/Exporter-Scraping nutzt einen lastverteilten Service-Endpunkt; Replikas können wechselnd statt als getrennte Zeitreihen erfasst werden. Etablieren Sie Anwendungsscraping pro Pod und vermeiden Sie doppelte Datenbankaggregation, bevor Sie skalierten Anfrageraten oder Summen vertrauen. Diese Erweiterungen gehören nicht zum validierten Ein-Replika-Pfad.

Konfiguration für Pod-Autoscaling

Testen Sie begrenztes HPA erst nach Abschluss von Migration und Rollback-Arbeiten in einem separat freigegebenen Experiment. Diese beispielhaften Grenzen sind keine Sizing-Empfehlungen für die Produktion:

enable_springboot_hpa                            = true
springboot_hpa_min_replicas                      = 1
springboot_hpa_max_replicas                      = 3
springboot_hpa_target_cpu_utilization_percentage = 70

Das Deployment definiert außerdem springboot_replicas in Terraform. Prüfen Sie spätere Pläne auf konkurrierende Replikaänderungen und legen Sie vor unbeaufsichtigtem HPA-Betrieb eine explizite Zuständigkeit fest. Das Migrationsskript lehnt HPA-verwaltete Ziele ab; deaktivieren Sie HPA vor jeder späteren Migration und jedem Rollback.

Prüfen Sie den Plan und beobachten Sie anschließend HPA mit der konfigurierten Kubeconfig:

terraform plan -var-file=env.tfvars -out=tfplan.optimize
terraform apply tfplan.optimize
kubectl get hpa,pods -n springboot
kubectl describe hpa springboot -n springboot
kubectl top pods -n springboot --containers

Cluster- und Plattform-Rightsizing

Stellen Sie genügend Worker-Reserve bereit und berücksichtigen Sie Pool-Kapazität, Zonengrenzen und Rollout-Unterbrechungen.

STACKIT-SKE-Grafana-Dashboard mit tatsächlicher CPU- und RAM-Nutzung gegenüber Requests und Limits, einem Node, 17 laufenden Pods, keinen wartenden oder fehlgeschlagenen Pods und API-Server-Aktivität

Das SKE-Dashboard zeigt dasselbe Intervall von 14:41 bis 15:41 UTC am 25. September 2026. Die tatsächliche CPU-Nutzung beträgt etwa 2 %, während CPU-Requests etwa 34 % der Cluster-Kapazität reservieren. Das verdeutlicht, warum Scheduling-Reservierungen und gemessener Verbrauch gemeinsam zu bewerten sind. Die 17 laufenden Pods umfassen Plattformkomponenten, nicht 17 Spring-Boot-Replikas; das Workload-Dashboard oben zeigt den einzelnen Anwendungspod. Keine fehlgeschlagenen oder wartenden Pods zu diesem Zeitpunkt sind ein nützliches Zustandssignal, kein Beweis für Spitzenlast- oder Ausfalltoleranz.

Passen Sie node_pool_minimum, node_pool_maximum und node_pool_machine_type anhand aggregierter Requests, beobachteter Nachfrage, System-Overhead und Rollout-Reserve an. Gleiche Mindest- und Höchstwerte fixieren die Pool-Größe; ein höheres HPA-Maximum kann diese Kapazitätsgrenze nicht überwinden.

Die Referenz konfiguriert einen Node Pool. Weitere Pools und Zonenplatzierung erfordern eine explizite Architekturerweiterung. Die Availability Zone eines Node Pools kann nicht ohne Neuerstellung geändert werden; eine andere Zone benötigt einen neuen Pool-Namen und einen geprüften Migrationsplan. Prüfen Sie tatsächliche SKE-Kapazität und geplanten Worker-Austausch vor einer Flavor- oder Topologieänderung.

STACKIT Dokumentation docs.stackit.cloud SKE Node Pools verwalten Dokumentation öffnen

Ingress-Ebene (Durchsatz)

Der implementierte Einstiegspunkt ist Envoy Gateway mit HTTPRoutes, kein älterer Ingress. Vergleichen Sie Gateway- und Service-Verhalten mit Anwendungs- und Datenbanklatenz vor einer Worker-Größenänderung. Der optionale clusterinterne Lastgenerator umgeht öffentliches Gateway, DNS und TLS; ergänzen Sie einen freigegebenen externen End-to-End-Test. Dieses Asset behauptet keine gemessene öffentliche Durchsatzgrenze.

Storage-Ebene (Performance persistenter Volumes)

Spring Music speichert seine maßgeblichen Daten in Flex. In dieser Basis gibt es kein Anwendungs-PersistentVolume für Rightsizing. node_pool_volume_size betrifft Worker-Speicher, nicht Datenbankkapazität. Nutzen Sie die Flex-Speichereinstellungen für Albumdaten und bewerten Sie Wachstum, Abfrage-I/O, Aufbewahrung und Recovery gemeinsam. Ergänzen Sie Kubernetes-Speicher nur für einen separat entworfenen Persistenzbedarf.

Optimize-Workflow für Replatform-Workloads

Repräsentative Metriken, fachliche Abnahmegrenzen, aktuelle Konfiguration und Kosten erfassen.
Eine Hypothese auswählen: Pod-Budget, Worker-Kapazität, Gateway oder Datenbankdruck.
Erwartete Verbesserung und Rollback-Schwelle festlegen; erforderliche Backups und Recovery prüfen.
Einen gespeicherten Terraform-Plan prüfen, fachfremde Änderungen ablehnen und im freigegebenen Fenster anwenden.
Rollout, Gateway, Albumdaten, tatsächliche Scrapes, Latenz, Fehler, Kapazität und Kosten gegen die Baseline validieren.
Die Änderung nur beibehalten, wenn das vereinbarte Beobachtungsfenster die Abnahme erfüllt; andernfalls dem vorab freigegebenen Rücknahme- oder Recovery-Verfahren folgen.

Rollback und Abnahme

Stellen Sie bei reversiblen Konfigurationsänderungen die zuvor geprüften Werte wieder her und prüfen Sie vor dem Apply einen neuen Plan. Setzen Sie nicht voraus, dass eine kleinere Datenbank oder die Rückkehr zur alten Speicherklasse unterstützt wird. War HPA das Experiment, deaktivieren Sie es und stellen Sie die gewünschte Replikazahl über die geprüfte Konfiguration wieder her; bestätigen Sie danach ein stabiles Deployment.

Dokumentieren Sie Vorher-/Nachher-Nachweise, Konfigurationsstand, fachliche Ergebnisse und Kostenwirkung. Ein Datenbank-Migrations-Rollback ersetzt nicht die Rücknahme einer Optimierungsänderung.

Hinweise

Der Live-Referenztest bestätigte den Workload mit einer Replika, Datenmigration und Rollback sowie den Dashboard-/Scrape-Pfad. Er wies weder Autoscaling-Verhalten noch optimales Sizing, Produktionslastkapazität oder Hochverfügbarkeit nach. Erheben Sie für jede dieser Entscheidungen neue Nachweise.

Externe Quelle kubernetes.io Kubernetes Horizontal Pod Autoscaler Regelkreis, Metrikvoraussetzungen und Skalierungsgrenzen der Kubernetes-Referenz vor der Aktivierung von Autoscaling prüfen. Externe Seite öffnen Führt von der Route weg

STEP

Pod- und Worker-Skalierung qualifizieren

Szenario

Wählen Sie nach Migrationsabnahme und Stabilisierung anhand des gemessenen Workload-Verhaltens jeweils eine Optimierung. Dieses Asset behandelt Pod-Ressourcen, Worker-Kapazität, optionales HPA und PostgreSQL Flex. Es behauptet nicht, dass diese Änderungen im Migrationstest erprobt wurden.

Referenzimplementierung fortführen

Führen Sie dieselbe Terraform-, Helm-, Spring-Music-JAR-, PostgreSQL-Flex- und Observability-Implementierung fort, die für Bereitstellung, Probe, Cutover und Rollback genutzt wurde. Führen Sie kein zweites Beispiel ein und keine Kapazitätsexperimente im Migrationsfenster durch.

Code & Registry github.com Spring Boot Kubernetes Replatform Referenz Dieselben versionierten Variablen, Deployment-Ressourcen und Dashboards wie im Migrations- und Stabilisierungsworkflow verwenden. Repository öffnen

Observability-Dashboard für Entscheidungen

Öffnen Sie grafana_dashboard_url oder den Ordner SCF Replatform. Terraform verwaltet acht Panels.

Replatform-Grafana-Dashboard mit Cluster-CPU und -Speicher, einem Spring-Boot-Pod, Anwendungsanfragen und PostgreSQL-Flex-Metriken über eine Stunde

Aufnahme der Referenzbereitstellung vom 25. September 2026, 14:41 bis 15:41 UTC. Sie zeigt eine Stunde Testbetrieb mit geringer Last, keine repräsentative Basis für Produktions-Sizing. Bewerten Sie Anwendungsaktivität gemeinsam mit Datenbankverfügbarkeit und -auslastung, bevor Sie einen Optimierungskandidaten auswählen. Die folgende Tabelle erläutert die Grenzen dieser Signale.

Seitlich wischen, um die ganze Tabelle zu sehen

Panelgruppe	Unterstützte Entscheidung	Interpretationsgrenze
Cluster-CPU und -Speicher	Worker-Auslastung und Gesamtkapazität	Die CPU-Abfrage zeigt belegte Kerne, keinen Auslastungsprozentsatz; Cluster-Summen identifizieren keinen einzelnen Pod-Engpass
Laufende Pods	Vorhandensein des Workloads	Ein Scrape-Ersatzwert beweist nicht, dass alle Replikas gesund sind; Kubernetes-Rollout und Soll-Replikazahl prüfen
Anwendungsanfragen	Anfragerate und mittlere Dauer	Der Boot-2-Adapter liefert keine Latenzperzentile und kein vollständiges Fehlerraten-SLO
PostgreSQL-Verfügbarkeit und -Verbindungen	Datenbankerreichbarkeit und Verbindungsdruck	`pg_up` und tatsächlichen Scrape-Zustand unabhängig prüfen
PostgreSQL-Transaktionen	Commit- und Rollback-Trends	Veränderungen mit Anfragelast und Anwendungsverhalten korrelieren
PostgreSQL-Cache-Treffer	Verhalten des Lesecaches	Geringe Anfragelast und fehlende Zeitreihen begründen keinen Kapazitätsbedarf
Temporäre PostgreSQL-Bytes und Sperren	Untersuchung von Abfragen oder Konkurrenz	Mehr Rechenleistung behebt Abfrage- oder Sperrprobleme nicht automatisch

Prüfen Sie vor der Interpretation echte up=1-Messwerte für beide Scrape-Jobs. Einige Cluster-Panels enthalten Ersatzwerte; eine dargestellte Null belegt daher keinen Nullverbrauch. Begrenzen Sie Abfragen auf den gewünschten Cluster und die Datenbank, wenn eine Datenquelle mehrere Workloads enthält. Nutzen Sie zusätzliche Telemetrie und fachliche Tests für Latenzperzentile, Fehler und Recovery-Ziele.

Optimierungssignale und Leitplanken

Erfassen Sie eine repräsentative Baseline einschließlich Spitzenzeiten, geplanter Arbeit, JVM-Aufwärmphase und Datenbankwartung. Vereinbaren Sie Beobachtungsfenster, fachliche SLOs, Kapazitätsreserve und Kostenziel vor der Änderung. Vierzehn Tage können ein Ausgangspunkt für die Beobachtung sein, sind aber keine feste Regel.

Pod-Ressourcenkandidat: Throttling, Neustarts, Heap- oder Working-Set-Druck sind auf Anwendung oder Sidecar begrenzt.
Worker-Kapazitätskandidat: Pods warten auf Scheduling, zuweisbare Ressourcen fehlen oder die Rollout-Reserve im Pool reicht nicht aus.
Datenbankkandidat: Verbindungs-, Transaktions-, Sperr-, Speicher- oder Abfragedruck korreliert mit fachlicher Latenz.
Scale-in-Kandidat: Dauerhafte Reserven nach Berücksichtigung von Spitzen, Rollout und Recovery, ohne ungelöste kritische Incidents.

Bewahren Sie Baseline, vorherige Konfiguration, Rollback-Plan und Entscheidungsschwellen auf. Fehlende Metriken, fehlgeschlagene Alarmzustellung oder ausschließlich synthetischer Traffic reichen als Nachweis für eine produktive Verkleinerung nicht aus.

Metriken aus PostgreSQL Flex für Optimize

Bewerten Sie Datenbank- und Anwendungssignale gemeinsam. Mehr Pods erhöhen den Verbindungsbedarf und können den Engpass zu Flex verlagern. Trennen Sie Connection-Pool-Grenzen, teure Abfragen, Sperrkonflikte und Speicherdruck von tatsächlichen CPU- oder RAM-Engpässen.

Nutzen Sie die Anleitung zum PostgreSQL-Flex-Monitoring , um Service-Metriken zusammen mit dem Anwendungsverhalten zu interpretieren.

PostgreSQL Flex für Rightsizing und Tuning

Die Referenz stellt postgres_flex_cpu, postgres_flex_ram, postgres_flex_replicas, postgres_flex_storage_class und postgres_flex_storage_size bereit. CPU, RAM und die Auswahl Single oder Replica bestimmen einen Flavor aus dem aktuellen Projektkatalog. Wählen Sie eine angebotene Kombination; setzen Sie weder beliebige Werte noch einen Wechsel ohne Neuerstellung voraus.

Prüfen Sie Plan und Service-Einschränkungen vor der Freigabe. Behandeln Sie einen Datenbankaustausch als neue Migration mit verifizierter Recovery, nicht als Routine-Resize. Speicherwachstum und Service-Plan-Wechsel lassen sich möglicherweise nicht durch alte Variablenwerte zurücknehmen. Bestätigen Sie Recovery-Pfad und Wartungsfenster vor der Änderung.

Der getestete Migrations-Rollback stellt Anwendungsdaten wieder her; er macht weder Infrastruktur-Resizing rückgängig noch weist er Managed-Flex-Restore nach. Validieren Sie das erforderliche Recovery-Verfahren separat.

STACKIT Dokumentation docs.stackit.cloud PostgreSQL-Flex-Flavors und Performance-Klassen Dokumentation öffnen

Aus der STACKIT-DokuVerfügbare Flavors und Leistungsklassen › FlavorStand der Quelle 06.07.2026 · übernommen 05.10.2026

Seitlich wischen, um die ganze Tabelle zu sehen

Beschreibung	ID	CPU	Memory	`max_connections`	`shared_buffers`	`work_mem`	`maintenance_work_mem`	`effective_cache_size`
Small, Compute optimized	2.4	2	4 GB	95	950 MB	14 MB	380 MB	2660 MB
Small, Memory optimized	2.16	2	16 GB	385	3950 MB	14 MB	1580 MB	11060 MB
Medium, Compute optimized	4.8	4	8 GB	195	1950 MB	14 MB	780 MB	5460 MB
Medium, Memory optimized	4.32	4	32 GB	785	7950 MB	14 MB	3180 MB	22260 MB
Large, Processor optimized	8.16	8	16 GB	385	3950 MB	14 MB	1580 MB	11060 MB
X-Large, Compute optimized	16.32	16	32 GB	785	7950 MB	14 MB	3180 MB	22260 MB
X-Large, Memory optimized	16.128	16	128 GB	3170	31950 MB	14 MB	12780 MB	89460 MB

Hinweise

CPU und Arbeitsspeicher gelten immer pro Knoten.
Das System nutzt bis zu 15 Verbindungen für interne essenzielle Prozesse wie Backup, Monitoring usw. Diese Verbindungen werden auf das Limit von max_connections angerechnet.

Was ist das?

Dieser Abschnitt wird mehrmals am Tag automatisch aus der STACKIT-Doku übernommen. Hier lässt er sich nicht ändern. Änderungen gehören in die STACKIT-Doku.

Aus der STACKIT-DokuVerfügbare Flavors und Leistungsklassen › LeistungsklassenStand der Quelle 06.07.2026 · übernommen 05.10.2026

Seitlich wischen, um die ganze Tabelle zu sehen

Beschreibung	ID	Max. IOPS	Max. Durchsatz (MB/s)
Leistungsklasse 2	`premium-perf2-stackit`	1000	100
Leistungsklasse 4	`premium-perf4-stackit`	2000	150
Leistungsklasse 6	`premium-perf6-stackit`	5000	200
Leistungsklasse 8	`premium-perf8-stackit`	10000	250
Leistungsklasse 10	`premium-perf10-stackit`	15000	300
Leistungsklasse 12	`premium-perf12-stackit`	20000	350

Aktuell bieten wir drei Typen von Instanzen an. Für jeden Typ ist ein anderer Satz an Flavor verfügbar.

Was ist das?

Dieser Abschnitt wird mehrmals am Tag automatisch aus der STACKIT-Doku übernommen. Hier lässt er sich nicht ändern. Änderungen gehören in die STACKIT-Doku.

Pod-Ressourcen und JVM-Budget

Die Referenz definiert Ressourcen im Spring-Boot-Deployment in main.tf, nicht über eigene CPU- oder Speichervariablen. Java fordert 100m CPU und 512Mi Speicher an; die Limits liegen bei 500m und 1Gi. JAVA_TOOL_OPTIONS setzt den initialen Heap auf 128 MiB und den maximalen Heap auf 512 MiB. Beide Exporter-Sidecars besitzen jeweils ein eigenes Ressourcenbudget.

Vergleichen Sie tatsächlichen Working Set, Heap, Nicht-Heap-Speicher, Throttling, Startverhalten und Sidecar-Verbrauch, bevor Sie das Deployment ändern. Lassen Sie neben dem Java-Heap Raum für Threads und nativen Speicher. Ressourcenänderungen können Pods neu ausrollen und einen Workload mit einer Replika unterbrechen; planen und validieren Sie entsprechend. Erfinden Sie keine nicht unterstützten springboot_cpu- oder Speichervariablen.

Regelkreis für Pod-Autoscaling

Qualifizieren Sie Metriken, Replikaverantwortung, Anwendungssicherheit und Telemetrie pro Pod vor einem begrenzten HPA-Experiment.

HPA vergleicht die beobachtete Pod-CPU-Auslastung mit dem konfigurierten Ziel und passt die Replikazahl innerhalb von Mindest- und Höchstgrenzen an. Die Ressourcenmetrik setzt realistische Requests und eine verfügbare Kubernetes Metrics API voraus; erfolgreiches Grafana-Scraping beweist deren Funktion nicht. Die Ressourcenauslastung umfasst auch die Sidecar-Budgets. HPA allein kann keine Worker-Kapazität erzeugen.

Prüfen Sie vor einem Experiment mit mehreren Replikas Sitzungszustand, gemeinsame Schreibzugriffe, Initialisierung und Datenbankverbindungslimits. Das aktuelle Anwendungs-/Exporter-Scraping nutzt einen lastverteilten Service-Endpunkt; Replikas können wechselnd statt als getrennte Zeitreihen erfasst werden. Etablieren Sie Anwendungsscraping pro Pod und vermeiden Sie doppelte Datenbankaggregation, bevor Sie skalierten Anfrageraten oder Summen vertrauen. Diese Erweiterungen gehören nicht zum validierten Ein-Replika-Pfad.

Konfiguration für Pod-Autoscaling

Testen Sie begrenztes HPA erst nach Abschluss von Migration und Rollback-Arbeiten in einem separat freigegebenen Experiment. Diese beispielhaften Grenzen sind keine Sizing-Empfehlungen für die Produktion:

enable_springboot_hpa                            = true
springboot_hpa_min_replicas                      = 1
springboot_hpa_max_replicas                      = 3
springboot_hpa_target_cpu_utilization_percentage = 70

Das Deployment definiert außerdem springboot_replicas in Terraform. Prüfen Sie spätere Pläne auf konkurrierende Replikaänderungen und legen Sie vor unbeaufsichtigtem HPA-Betrieb eine explizite Zuständigkeit fest. Das Migrationsskript lehnt HPA-verwaltete Ziele ab; deaktivieren Sie HPA vor jeder späteren Migration und jedem Rollback.

Prüfen Sie den Plan und beobachten Sie anschließend HPA mit der konfigurierten Kubeconfig:

terraform plan -var-file=env.tfvars -out=tfplan.optimize
terraform apply tfplan.optimize
kubectl get hpa,pods -n springboot
kubectl describe hpa springboot -n springboot
kubectl top pods -n springboot --containers

Cluster- und Plattform-Rightsizing

Stellen Sie genügend Worker-Reserve bereit und berücksichtigen Sie Pool-Kapazität, Zonengrenzen und Rollout-Unterbrechungen.

STACKIT-SKE-Grafana-Dashboard mit tatsächlicher CPU- und RAM-Nutzung gegenüber Requests und Limits, einem Node, 17 laufenden Pods, keinen wartenden oder fehlgeschlagenen Pods und API-Server-Aktivität

Das SKE-Dashboard zeigt dasselbe Intervall von 14:41 bis 15:41 UTC am 25. September 2026. Die tatsächliche CPU-Nutzung beträgt etwa 2 %, während CPU-Requests etwa 34 % der Cluster-Kapazität reservieren. Das verdeutlicht, warum Scheduling-Reservierungen und gemessener Verbrauch gemeinsam zu bewerten sind. Die 17 laufenden Pods umfassen Plattformkomponenten, nicht 17 Spring-Boot-Replikas; das Workload-Dashboard oben zeigt den einzelnen Anwendungspod. Keine fehlgeschlagenen oder wartenden Pods zu diesem Zeitpunkt sind ein nützliches Zustandssignal, kein Beweis für Spitzenlast- oder Ausfalltoleranz.

Passen Sie node_pool_minimum, node_pool_maximum und node_pool_machine_type anhand aggregierter Requests, beobachteter Nachfrage, System-Overhead und Rollout-Reserve an. Gleiche Mindest- und Höchstwerte fixieren die Pool-Größe; ein höheres HPA-Maximum kann diese Kapazitätsgrenze nicht überwinden.

Die Referenz konfiguriert einen Node Pool. Weitere Pools und Zonenplatzierung erfordern eine explizite Architekturerweiterung. Die Availability Zone eines Node Pools kann nicht ohne Neuerstellung geändert werden; eine andere Zone benötigt einen neuen Pool-Namen und einen geprüften Migrationsplan. Prüfen Sie tatsächliche SKE-Kapazität und geplanten Worker-Austausch vor einer Flavor- oder Topologieänderung.

STACKIT Dokumentation docs.stackit.cloud SKE Node Pools verwalten Dokumentation öffnen

Ingress-Ebene (Durchsatz)

Der implementierte Einstiegspunkt ist Envoy Gateway mit HTTPRoutes, kein älterer Ingress. Vergleichen Sie Gateway- und Service-Verhalten mit Anwendungs- und Datenbanklatenz vor einer Worker-Größenänderung. Der optionale clusterinterne Lastgenerator umgeht öffentliches Gateway, DNS und TLS; ergänzen Sie einen freigegebenen externen End-to-End-Test. Dieses Asset behauptet keine gemessene öffentliche Durchsatzgrenze.

Storage-Ebene (Performance persistenter Volumes)

Spring Music speichert seine maßgeblichen Daten in Flex. In dieser Basis gibt es kein Anwendungs-PersistentVolume für Rightsizing. node_pool_volume_size betrifft Worker-Speicher, nicht Datenbankkapazität. Nutzen Sie die Flex-Speichereinstellungen für Albumdaten und bewerten Sie Wachstum, Abfrage-I/O, Aufbewahrung und Recovery gemeinsam. Ergänzen Sie Kubernetes-Speicher nur für einen separat entworfenen Persistenzbedarf.

Optimize-Workflow für Replatform-Workloads

Repräsentative Metriken, fachliche Abnahmegrenzen, aktuelle Konfiguration und Kosten erfassen.
Eine Hypothese auswählen: Pod-Budget, Worker-Kapazität, Gateway oder Datenbankdruck.
Erwartete Verbesserung und Rollback-Schwelle festlegen; erforderliche Backups und Recovery prüfen.
Einen gespeicherten Terraform-Plan prüfen, fachfremde Änderungen ablehnen und im freigegebenen Fenster anwenden.
Rollout, Gateway, Albumdaten, tatsächliche Scrapes, Latenz, Fehler, Kapazität und Kosten gegen die Baseline validieren.
Die Änderung nur beibehalten, wenn das vereinbarte Beobachtungsfenster die Abnahme erfüllt; andernfalls dem vorab freigegebenen Rücknahme- oder Recovery-Verfahren folgen.

Rollback und Abnahme

Stellen Sie bei reversiblen Konfigurationsänderungen die zuvor geprüften Werte wieder her und prüfen Sie vor dem Apply einen neuen Plan. Setzen Sie nicht voraus, dass eine kleinere Datenbank oder die Rückkehr zur alten Speicherklasse unterstützt wird. War HPA das Experiment, deaktivieren Sie es und stellen Sie die gewünschte Replikazahl über die geprüfte Konfiguration wieder her; bestätigen Sie danach ein stabiles Deployment.

Dokumentieren Sie Vorher-/Nachher-Nachweise, Konfigurationsstand, fachliche Ergebnisse und Kostenwirkung. Ein Datenbank-Migrations-Rollback ersetzt nicht die Rücknahme einer Optimierungsänderung.

Hinweise

Der Live-Referenztest bestätigte den Workload mit einer Replika, Datenmigration und Rollback sowie den Dashboard-/Scrape-Pfad. Er wies weder Autoscaling-Verhalten noch optimales Sizing, Produktionslastkapazität oder Hochverfügbarkeit nach. Erheben Sie für jede dieser Entscheidungen neue Nachweise.

Externe Quelle kubernetes.io Kubernetes Horizontal Pod Autoscaler Regelkreis, Metrikvoraussetzungen und Skalierungsgrenzen der Kubernetes-Referenz vor der Aktivierung von Autoscaling prüfen. Externe Seite öffnen Führt von der Route weg

Szenario

Wählen Sie nach Migrationsabnahme und Stabilisierung anhand des gemessenen Workload-Verhaltens jeweils eine Optimierung. Dieses Asset behandelt Pod-Ressourcen, Worker-Kapazität, optionales HPA und PostgreSQL Flex. Es behauptet nicht, dass diese Änderungen im Migrationstest erprobt wurden.

Referenzimplementierung fortführen

Führen Sie dieselbe Terraform-, Helm-, Spring-Music-JAR-, PostgreSQL-Flex- und Observability-Implementierung fort, die für Bereitstellung, Probe, Cutover und Rollback genutzt wurde. Führen Sie kein zweites Beispiel ein und keine Kapazitätsexperimente im Migrationsfenster durch.

Code & Registry github.com Spring Boot Kubernetes Replatform Referenz Dieselben versionierten Variablen, Deployment-Ressourcen und Dashboards wie im Migrations- und Stabilisierungsworkflow verwenden. Repository öffnen

Observability-Dashboard für Entscheidungen

Öffnen Sie grafana_dashboard_url oder den Ordner SCF Replatform. Terraform verwaltet acht Panels.

Replatform-Grafana-Dashboard mit Cluster-CPU und -Speicher, einem Spring-Boot-Pod, Anwendungsanfragen und PostgreSQL-Flex-Metriken über eine Stunde

Aufnahme der Referenzbereitstellung vom 25. September 2026, 14:41 bis 15:41 UTC. Sie zeigt eine Stunde Testbetrieb mit geringer Last, keine repräsentative Basis für Produktions-Sizing. Bewerten Sie Anwendungsaktivität gemeinsam mit Datenbankverfügbarkeit und -auslastung, bevor Sie einen Optimierungskandidaten auswählen. Die folgende Tabelle erläutert die Grenzen dieser Signale.

Seitlich wischen, um die ganze Tabelle zu sehen

Panelgruppe	Unterstützte Entscheidung	Interpretationsgrenze
Cluster-CPU und -Speicher	Worker-Auslastung und Gesamtkapazität	Die CPU-Abfrage zeigt belegte Kerne, keinen Auslastungsprozentsatz; Cluster-Summen identifizieren keinen einzelnen Pod-Engpass
Laufende Pods	Vorhandensein des Workloads	Ein Scrape-Ersatzwert beweist nicht, dass alle Replikas gesund sind; Kubernetes-Rollout und Soll-Replikazahl prüfen
Anwendungsanfragen	Anfragerate und mittlere Dauer	Der Boot-2-Adapter liefert keine Latenzperzentile und kein vollständiges Fehlerraten-SLO
PostgreSQL-Verfügbarkeit und -Verbindungen	Datenbankerreichbarkeit und Verbindungsdruck	`pg_up` und tatsächlichen Scrape-Zustand unabhängig prüfen
PostgreSQL-Transaktionen	Commit- und Rollback-Trends	Veränderungen mit Anfragelast und Anwendungsverhalten korrelieren
PostgreSQL-Cache-Treffer	Verhalten des Lesecaches	Geringe Anfragelast und fehlende Zeitreihen begründen keinen Kapazitätsbedarf
Temporäre PostgreSQL-Bytes und Sperren	Untersuchung von Abfragen oder Konkurrenz	Mehr Rechenleistung behebt Abfrage- oder Sperrprobleme nicht automatisch

Prüfen Sie vor der Interpretation echte up=1-Messwerte für beide Scrape-Jobs. Einige Cluster-Panels enthalten Ersatzwerte; eine dargestellte Null belegt daher keinen Nullverbrauch. Begrenzen Sie Abfragen auf den gewünschten Cluster und die Datenbank, wenn eine Datenquelle mehrere Workloads enthält. Nutzen Sie zusätzliche Telemetrie und fachliche Tests für Latenzperzentile, Fehler und Recovery-Ziele.

Optimierungssignale und Leitplanken

Erfassen Sie eine repräsentative Baseline einschließlich Spitzenzeiten, geplanter Arbeit, JVM-Aufwärmphase und Datenbankwartung. Vereinbaren Sie Beobachtungsfenster, fachliche SLOs, Kapazitätsreserve und Kostenziel vor der Änderung. Vierzehn Tage können ein Ausgangspunkt für die Beobachtung sein, sind aber keine feste Regel.

Pod-Ressourcenkandidat: Throttling, Neustarts, Heap- oder Working-Set-Druck sind auf Anwendung oder Sidecar begrenzt.
Worker-Kapazitätskandidat: Pods warten auf Scheduling, zuweisbare Ressourcen fehlen oder die Rollout-Reserve im Pool reicht nicht aus.
Datenbankkandidat: Verbindungs-, Transaktions-, Sperr-, Speicher- oder Abfragedruck korreliert mit fachlicher Latenz.
Scale-in-Kandidat: Dauerhafte Reserven nach Berücksichtigung von Spitzen, Rollout und Recovery, ohne ungelöste kritische Incidents.

Bewahren Sie Baseline, vorherige Konfiguration, Rollback-Plan und Entscheidungsschwellen auf. Fehlende Metriken, fehlgeschlagene Alarmzustellung oder ausschließlich synthetischer Traffic reichen als Nachweis für eine produktive Verkleinerung nicht aus.

Metriken aus PostgreSQL Flex für Optimize

Bewerten Sie Datenbank- und Anwendungssignale gemeinsam. Mehr Pods erhöhen den Verbindungsbedarf und können den Engpass zu Flex verlagern. Trennen Sie Connection-Pool-Grenzen, teure Abfragen, Sperrkonflikte und Speicherdruck von tatsächlichen CPU- oder RAM-Engpässen.

Nutzen Sie die Anleitung zum PostgreSQL-Flex-Monitoring , um Service-Metriken zusammen mit dem Anwendungsverhalten zu interpretieren.

PostgreSQL Flex für Rightsizing und Tuning

Die Referenz stellt postgres_flex_cpu, postgres_flex_ram, postgres_flex_replicas, postgres_flex_storage_class und postgres_flex_storage_size bereit. CPU, RAM und die Auswahl Single oder Replica bestimmen einen Flavor aus dem aktuellen Projektkatalog. Wählen Sie eine angebotene Kombination; setzen Sie weder beliebige Werte noch einen Wechsel ohne Neuerstellung voraus.

Prüfen Sie Plan und Service-Einschränkungen vor der Freigabe. Behandeln Sie einen Datenbankaustausch als neue Migration mit verifizierter Recovery, nicht als Routine-Resize. Speicherwachstum und Service-Plan-Wechsel lassen sich möglicherweise nicht durch alte Variablenwerte zurücknehmen. Bestätigen Sie Recovery-Pfad und Wartungsfenster vor der Änderung.

Der getestete Migrations-Rollback stellt Anwendungsdaten wieder her; er macht weder Infrastruktur-Resizing rückgängig noch weist er Managed-Flex-Restore nach. Validieren Sie das erforderliche Recovery-Verfahren separat.

STACKIT Dokumentation docs.stackit.cloud PostgreSQL-Flex-Flavors und Performance-Klassen Dokumentation öffnen

Aus der STACKIT-DokuVerfügbare Flavors und Leistungsklassen › FlavorStand der Quelle 06.07.2026 · übernommen 05.10.2026

Seitlich wischen, um die ganze Tabelle zu sehen

Beschreibung	ID	CPU	Memory	`max_connections`	`shared_buffers`	`work_mem`	`maintenance_work_mem`	`effective_cache_size`
Small, Compute optimized	2.4	2	4 GB	95	950 MB	14 MB	380 MB	2660 MB
Small, Memory optimized	2.16	2	16 GB	385	3950 MB	14 MB	1580 MB	11060 MB
Medium, Compute optimized	4.8	4	8 GB	195	1950 MB	14 MB	780 MB	5460 MB
Medium, Memory optimized	4.32	4	32 GB	785	7950 MB	14 MB	3180 MB	22260 MB
Large, Processor optimized	8.16	8	16 GB	385	3950 MB	14 MB	1580 MB	11060 MB
X-Large, Compute optimized	16.32	16	32 GB	785	7950 MB	14 MB	3180 MB	22260 MB
X-Large, Memory optimized	16.128	16	128 GB	3170	31950 MB	14 MB	12780 MB	89460 MB

Hinweise

CPU und Arbeitsspeicher gelten immer pro Knoten.
Das System nutzt bis zu 15 Verbindungen für interne essenzielle Prozesse wie Backup, Monitoring usw. Diese Verbindungen werden auf das Limit von max_connections angerechnet.

Was ist das?

Dieser Abschnitt wird mehrmals am Tag automatisch aus der STACKIT-Doku übernommen. Hier lässt er sich nicht ändern. Änderungen gehören in die STACKIT-Doku.

Aus der STACKIT-DokuVerfügbare Flavors und Leistungsklassen › LeistungsklassenStand der Quelle 06.07.2026 · übernommen 05.10.2026

Seitlich wischen, um die ganze Tabelle zu sehen

Beschreibung	ID	Max. IOPS	Max. Durchsatz (MB/s)
Leistungsklasse 2	`premium-perf2-stackit`	1000	100
Leistungsklasse 4	`premium-perf4-stackit`	2000	150
Leistungsklasse 6	`premium-perf6-stackit`	5000	200
Leistungsklasse 8	`premium-perf8-stackit`	10000	250
Leistungsklasse 10	`premium-perf10-stackit`	15000	300
Leistungsklasse 12	`premium-perf12-stackit`	20000	350

Aktuell bieten wir drei Typen von Instanzen an. Für jeden Typ ist ein anderer Satz an Flavor verfügbar.

Was ist das?

Dieser Abschnitt wird mehrmals am Tag automatisch aus der STACKIT-Doku übernommen. Hier lässt er sich nicht ändern. Änderungen gehören in die STACKIT-Doku.

Pod-Ressourcen und JVM-Budget

Die Referenz definiert Ressourcen im Spring-Boot-Deployment in main.tf, nicht über eigene CPU- oder Speichervariablen. Java fordert 100m CPU und 512Mi Speicher an; die Limits liegen bei 500m und 1Gi. JAVA_TOOL_OPTIONS setzt den initialen Heap auf 128 MiB und den maximalen Heap auf 512 MiB. Beide Exporter-Sidecars besitzen jeweils ein eigenes Ressourcenbudget.

Vergleichen Sie tatsächlichen Working Set, Heap, Nicht-Heap-Speicher, Throttling, Startverhalten und Sidecar-Verbrauch, bevor Sie das Deployment ändern. Lassen Sie neben dem Java-Heap Raum für Threads und nativen Speicher. Ressourcenänderungen können Pods neu ausrollen und einen Workload mit einer Replika unterbrechen; planen und validieren Sie entsprechend. Erfinden Sie keine nicht unterstützten springboot_cpu- oder Speichervariablen.

Regelkreis für Pod-Autoscaling

Qualifizieren Sie Metriken, Replikaverantwortung, Anwendungssicherheit und Telemetrie pro Pod vor einem begrenzten HPA-Experiment.

HPA vergleicht die beobachtete Pod-CPU-Auslastung mit dem konfigurierten Ziel und passt die Replikazahl innerhalb von Mindest- und Höchstgrenzen an. Die Ressourcenmetrik setzt realistische Requests und eine verfügbare Kubernetes Metrics API voraus; erfolgreiches Grafana-Scraping beweist deren Funktion nicht. Die Ressourcenauslastung umfasst auch die Sidecar-Budgets. HPA allein kann keine Worker-Kapazität erzeugen.

Prüfen Sie vor einem Experiment mit mehreren Replikas Sitzungszustand, gemeinsame Schreibzugriffe, Initialisierung und Datenbankverbindungslimits. Das aktuelle Anwendungs-/Exporter-Scraping nutzt einen lastverteilten Service-Endpunkt; Replikas können wechselnd statt als getrennte Zeitreihen erfasst werden. Etablieren Sie Anwendungsscraping pro Pod und vermeiden Sie doppelte Datenbankaggregation, bevor Sie skalierten Anfrageraten oder Summen vertrauen. Diese Erweiterungen gehören nicht zum validierten Ein-Replika-Pfad.

Konfiguration für Pod-Autoscaling

Testen Sie begrenztes HPA erst nach Abschluss von Migration und Rollback-Arbeiten in einem separat freigegebenen Experiment. Diese beispielhaften Grenzen sind keine Sizing-Empfehlungen für die Produktion:

enable_springboot_hpa                            = true
springboot_hpa_min_replicas                      = 1
springboot_hpa_max_replicas                      = 3
springboot_hpa_target_cpu_utilization_percentage = 70

Das Deployment definiert außerdem springboot_replicas in Terraform. Prüfen Sie spätere Pläne auf konkurrierende Replikaänderungen und legen Sie vor unbeaufsichtigtem HPA-Betrieb eine explizite Zuständigkeit fest. Das Migrationsskript lehnt HPA-verwaltete Ziele ab; deaktivieren Sie HPA vor jeder späteren Migration und jedem Rollback.

Prüfen Sie den Plan und beobachten Sie anschließend HPA mit der konfigurierten Kubeconfig:

terraform plan -var-file=env.tfvars -out=tfplan.optimize
terraform apply tfplan.optimize
kubectl get hpa,pods -n springboot
kubectl describe hpa springboot -n springboot
kubectl top pods -n springboot --containers

Cluster- und Plattform-Rightsizing

Stellen Sie genügend Worker-Reserve bereit und berücksichtigen Sie Pool-Kapazität, Zonengrenzen und Rollout-Unterbrechungen.

STACKIT-SKE-Grafana-Dashboard mit tatsächlicher CPU- und RAM-Nutzung gegenüber Requests und Limits, einem Node, 17 laufenden Pods, keinen wartenden oder fehlgeschlagenen Pods und API-Server-Aktivität

Das SKE-Dashboard zeigt dasselbe Intervall von 14:41 bis 15:41 UTC am 25. September 2026. Die tatsächliche CPU-Nutzung beträgt etwa 2 %, während CPU-Requests etwa 34 % der Cluster-Kapazität reservieren. Das verdeutlicht, warum Scheduling-Reservierungen und gemessener Verbrauch gemeinsam zu bewerten sind. Die 17 laufenden Pods umfassen Plattformkomponenten, nicht 17 Spring-Boot-Replikas; das Workload-Dashboard oben zeigt den einzelnen Anwendungspod. Keine fehlgeschlagenen oder wartenden Pods zu diesem Zeitpunkt sind ein nützliches Zustandssignal, kein Beweis für Spitzenlast- oder Ausfalltoleranz.

Passen Sie node_pool_minimum, node_pool_maximum und node_pool_machine_type anhand aggregierter Requests, beobachteter Nachfrage, System-Overhead und Rollout-Reserve an. Gleiche Mindest- und Höchstwerte fixieren die Pool-Größe; ein höheres HPA-Maximum kann diese Kapazitätsgrenze nicht überwinden.

Die Referenz konfiguriert einen Node Pool. Weitere Pools und Zonenplatzierung erfordern eine explizite Architekturerweiterung. Die Availability Zone eines Node Pools kann nicht ohne Neuerstellung geändert werden; eine andere Zone benötigt einen neuen Pool-Namen und einen geprüften Migrationsplan. Prüfen Sie tatsächliche SKE-Kapazität und geplanten Worker-Austausch vor einer Flavor- oder Topologieänderung.

STACKIT Dokumentation docs.stackit.cloud SKE Node Pools verwalten Dokumentation öffnen

Ingress-Ebene (Durchsatz)

Der implementierte Einstiegspunkt ist Envoy Gateway mit HTTPRoutes, kein älterer Ingress. Vergleichen Sie Gateway- und Service-Verhalten mit Anwendungs- und Datenbanklatenz vor einer Worker-Größenänderung. Der optionale clusterinterne Lastgenerator umgeht öffentliches Gateway, DNS und TLS; ergänzen Sie einen freigegebenen externen End-to-End-Test. Dieses Asset behauptet keine gemessene öffentliche Durchsatzgrenze.

Storage-Ebene (Performance persistenter Volumes)

Spring Music speichert seine maßgeblichen Daten in Flex. In dieser Basis gibt es kein Anwendungs-PersistentVolume für Rightsizing. node_pool_volume_size betrifft Worker-Speicher, nicht Datenbankkapazität. Nutzen Sie die Flex-Speichereinstellungen für Albumdaten und bewerten Sie Wachstum, Abfrage-I/O, Aufbewahrung und Recovery gemeinsam. Ergänzen Sie Kubernetes-Speicher nur für einen separat entworfenen Persistenzbedarf.

Optimize-Workflow für Replatform-Workloads

Repräsentative Metriken, fachliche Abnahmegrenzen, aktuelle Konfiguration und Kosten erfassen.
Eine Hypothese auswählen: Pod-Budget, Worker-Kapazität, Gateway oder Datenbankdruck.
Erwartete Verbesserung und Rollback-Schwelle festlegen; erforderliche Backups und Recovery prüfen.
Einen gespeicherten Terraform-Plan prüfen, fachfremde Änderungen ablehnen und im freigegebenen Fenster anwenden.
Rollout, Gateway, Albumdaten, tatsächliche Scrapes, Latenz, Fehler, Kapazität und Kosten gegen die Baseline validieren.
Die Änderung nur beibehalten, wenn das vereinbarte Beobachtungsfenster die Abnahme erfüllt; andernfalls dem vorab freigegebenen Rücknahme- oder Recovery-Verfahren folgen.

Rollback und Abnahme

Stellen Sie bei reversiblen Konfigurationsänderungen die zuvor geprüften Werte wieder her und prüfen Sie vor dem Apply einen neuen Plan. Setzen Sie nicht voraus, dass eine kleinere Datenbank oder die Rückkehr zur alten Speicherklasse unterstützt wird. War HPA das Experiment, deaktivieren Sie es und stellen Sie die gewünschte Replikazahl über die geprüfte Konfiguration wieder her; bestätigen Sie danach ein stabiles Deployment.

Dokumentieren Sie Vorher-/Nachher-Nachweise, Konfigurationsstand, fachliche Ergebnisse und Kostenwirkung. Ein Datenbank-Migrations-Rollback ersetzt nicht die Rücknahme einer Optimierungsänderung.

Hinweise

Der Live-Referenztest bestätigte den Workload mit einer Replika, Datenmigration und Rollback sowie den Dashboard-/Scrape-Pfad. Er wies weder Autoscaling-Verhalten noch optimales Sizing, Produktionslastkapazität oder Hochverfügbarkeit nach. Erheben Sie für jede dieser Entscheidungen neue Nachweise.

Externe Quelle kubernetes.io Kubernetes Horizontal Pod Autoscaler Regelkreis, Metrikvoraussetzungen und Skalierungsgrenzen der Kubernetes-Referenz vor der Aktivierung von Autoscaling prüfen. Externe Seite öffnen Führt von der Route weg

STEP

Optional: HPA konfigurieren und prüfen

Migration design-and-mobilize use-cases migrate optimize replatform kubernetes rightsizing hpa spring-boot postgresql

Replatform Spring Boot auf Kubernetes mit Rightsizing und Pod-Skalierung optimieren

STACKIT

Dasselbe Spring-Boot-Replatform anhand gemessener Pod- und Node-Kapazität, PostgreSQL-Flex-Tuning, Skalierungsleitplanken und reversibler Änderungen optimieren.

Code & Registry github.com Spring Boot Kubernetes Replatform Referenz Dieselben versionierten Variablen, Deployment-Ressourcen und Dashboards wie im Migrations- und Stabilisierungsworkflow verwenden. Repository öffnen

STACKIT

Der souveräne europäische Cloud-Anbieter hinter dem Framework, mit IaaS und PaaS aus deutschen und österreichischen Rechenzentren und voller Unabhängigkeit.

Szenario

Wählen Sie nach Migrationsabnahme und Stabilisierung anhand des gemessenen Workload-Verhaltens jeweils eine Optimierung. Dieses Asset behandelt Pod-Ressourcen, Worker-Kapazität, optionales HPA und PostgreSQL Flex. Es behauptet nicht, dass diese Änderungen im Migrationstest erprobt wurden.

Referenzimplementierung fortführen

Führen Sie dieselbe Terraform-, Helm-, Spring-Music-JAR-, PostgreSQL-Flex- und Observability-Implementierung fort, die für Bereitstellung, Probe, Cutover und Rollback genutzt wurde. Führen Sie kein zweites Beispiel ein und keine Kapazitätsexperimente im Migrationsfenster durch.

Observability-Dashboard für Entscheidungen

Öffnen Sie grafana_dashboard_url oder den Ordner SCF Replatform. Terraform verwaltet acht Panels.

Replatform-Grafana-Dashboard mit Cluster-CPU und -Speicher, einem Spring-Boot-Pod, Anwendungsanfragen und PostgreSQL-Flex-Metriken über eine Stunde

Aufnahme der Referenzbereitstellung vom 25. September 2026, 14:41 bis 15:41 UTC. Sie zeigt eine Stunde Testbetrieb mit geringer Last, keine repräsentative Basis für Produktions-Sizing. Bewerten Sie Anwendungsaktivität gemeinsam mit Datenbankverfügbarkeit und -auslastung, bevor Sie einen Optimierungskandidaten auswählen. Die folgende Tabelle erläutert die Grenzen dieser Signale.

Seitlich wischen, um die ganze Tabelle zu sehen

Panelgruppe	Unterstützte Entscheidung	Interpretationsgrenze
Cluster-CPU und -Speicher	Worker-Auslastung und Gesamtkapazität	Die CPU-Abfrage zeigt belegte Kerne, keinen Auslastungsprozentsatz; Cluster-Summen identifizieren keinen einzelnen Pod-Engpass
Laufende Pods	Vorhandensein des Workloads	Ein Scrape-Ersatzwert beweist nicht, dass alle Replikas gesund sind; Kubernetes-Rollout und Soll-Replikazahl prüfen
Anwendungsanfragen	Anfragerate und mittlere Dauer	Der Boot-2-Adapter liefert keine Latenzperzentile und kein vollständiges Fehlerraten-SLO
PostgreSQL-Verfügbarkeit und -Verbindungen	Datenbankerreichbarkeit und Verbindungsdruck	`pg_up` und tatsächlichen Scrape-Zustand unabhängig prüfen
PostgreSQL-Transaktionen	Commit- und Rollback-Trends	Veränderungen mit Anfragelast und Anwendungsverhalten korrelieren
PostgreSQL-Cache-Treffer	Verhalten des Lesecaches	Geringe Anfragelast und fehlende Zeitreihen begründen keinen Kapazitätsbedarf
Temporäre PostgreSQL-Bytes und Sperren	Untersuchung von Abfragen oder Konkurrenz	Mehr Rechenleistung behebt Abfrage- oder Sperrprobleme nicht automatisch

Prüfen Sie vor der Interpretation echte up=1-Messwerte für beide Scrape-Jobs. Einige Cluster-Panels enthalten Ersatzwerte; eine dargestellte Null belegt daher keinen Nullverbrauch. Begrenzen Sie Abfragen auf den gewünschten Cluster und die Datenbank, wenn eine Datenquelle mehrere Workloads enthält. Nutzen Sie zusätzliche Telemetrie und fachliche Tests für Latenzperzentile, Fehler und Recovery-Ziele.

Optimierungssignale und Leitplanken

Erfassen Sie eine repräsentative Baseline einschließlich Spitzenzeiten, geplanter Arbeit, JVM-Aufwärmphase und Datenbankwartung. Vereinbaren Sie Beobachtungsfenster, fachliche SLOs, Kapazitätsreserve und Kostenziel vor der Änderung. Vierzehn Tage können ein Ausgangspunkt für die Beobachtung sein, sind aber keine feste Regel.

Pod-Ressourcenkandidat: Throttling, Neustarts, Heap- oder Working-Set-Druck sind auf Anwendung oder Sidecar begrenzt.
Worker-Kapazitätskandidat: Pods warten auf Scheduling, zuweisbare Ressourcen fehlen oder die Rollout-Reserve im Pool reicht nicht aus.
Datenbankkandidat: Verbindungs-, Transaktions-, Sperr-, Speicher- oder Abfragedruck korreliert mit fachlicher Latenz.
Scale-in-Kandidat: Dauerhafte Reserven nach Berücksichtigung von Spitzen, Rollout und Recovery, ohne ungelöste kritische Incidents.

Bewahren Sie Baseline, vorherige Konfiguration, Rollback-Plan und Entscheidungsschwellen auf. Fehlende Metriken, fehlgeschlagene Alarmzustellung oder ausschließlich synthetischer Traffic reichen als Nachweis für eine produktive Verkleinerung nicht aus.

Metriken aus PostgreSQL Flex für Optimize

Bewerten Sie Datenbank- und Anwendungssignale gemeinsam. Mehr Pods erhöhen den Verbindungsbedarf und können den Engpass zu Flex verlagern. Trennen Sie Connection-Pool-Grenzen, teure Abfragen, Sperrkonflikte und Speicherdruck von tatsächlichen CPU- oder RAM-Engpässen.

Nutzen Sie die Anleitung zum PostgreSQL-Flex-Monitoring , um Service-Metriken zusammen mit dem Anwendungsverhalten zu interpretieren.

PostgreSQL Flex für Rightsizing und Tuning

Die Referenz stellt postgres_flex_cpu, postgres_flex_ram, postgres_flex_replicas, postgres_flex_storage_class und postgres_flex_storage_size bereit. CPU, RAM und die Auswahl Single oder Replica bestimmen einen Flavor aus dem aktuellen Projektkatalog. Wählen Sie eine angebotene Kombination; setzen Sie weder beliebige Werte noch einen Wechsel ohne Neuerstellung voraus.

Prüfen Sie Plan und Service-Einschränkungen vor der Freigabe. Behandeln Sie einen Datenbankaustausch als neue Migration mit verifizierter Recovery, nicht als Routine-Resize. Speicherwachstum und Service-Plan-Wechsel lassen sich möglicherweise nicht durch alte Variablenwerte zurücknehmen. Bestätigen Sie Recovery-Pfad und Wartungsfenster vor der Änderung.

Der getestete Migrations-Rollback stellt Anwendungsdaten wieder her; er macht weder Infrastruktur-Resizing rückgängig noch weist er Managed-Flex-Restore nach. Validieren Sie das erforderliche Recovery-Verfahren separat.

STACKIT Dokumentation docs.stackit.cloud PostgreSQL-Flex-Flavors und Performance-Klassen Dokumentation öffnen

Aus der STACKIT-DokuVerfügbare Flavors und Leistungsklassen › FlavorStand der Quelle 06.07.2026 · übernommen 05.10.2026

Seitlich wischen, um die ganze Tabelle zu sehen

Beschreibung	ID	CPU	Memory	`max_connections`	`shared_buffers`	`work_mem`	`maintenance_work_mem`	`effective_cache_size`
Small, Compute optimized	2.4	2	4 GB	95	950 MB	14 MB	380 MB	2660 MB
Small, Memory optimized	2.16	2	16 GB	385	3950 MB	14 MB	1580 MB	11060 MB
Medium, Compute optimized	4.8	4	8 GB	195	1950 MB	14 MB	780 MB	5460 MB
Medium, Memory optimized	4.32	4	32 GB	785	7950 MB	14 MB	3180 MB	22260 MB
Large, Processor optimized	8.16	8	16 GB	385	3950 MB	14 MB	1580 MB	11060 MB
X-Large, Compute optimized	16.32	16	32 GB	785	7950 MB	14 MB	3180 MB	22260 MB
X-Large, Memory optimized	16.128	16	128 GB	3170	31950 MB	14 MB	12780 MB	89460 MB

Hinweise

CPU und Arbeitsspeicher gelten immer pro Knoten.
Das System nutzt bis zu 15 Verbindungen für interne essenzielle Prozesse wie Backup, Monitoring usw. Diese Verbindungen werden auf das Limit von max_connections angerechnet.

Was ist das?

Dieser Abschnitt wird mehrmals am Tag automatisch aus der STACKIT-Doku übernommen. Hier lässt er sich nicht ändern. Änderungen gehören in die STACKIT-Doku.

Aus der STACKIT-DokuVerfügbare Flavors und Leistungsklassen › LeistungsklassenStand der Quelle 06.07.2026 · übernommen 05.10.2026

Seitlich wischen, um die ganze Tabelle zu sehen

Beschreibung	ID	Max. IOPS	Max. Durchsatz (MB/s)
Leistungsklasse 2	`premium-perf2-stackit`	1000	100
Leistungsklasse 4	`premium-perf4-stackit`	2000	150
Leistungsklasse 6	`premium-perf6-stackit`	5000	200
Leistungsklasse 8	`premium-perf8-stackit`	10000	250
Leistungsklasse 10	`premium-perf10-stackit`	15000	300
Leistungsklasse 12	`premium-perf12-stackit`	20000	350

Aktuell bieten wir drei Typen von Instanzen an. Für jeden Typ ist ein anderer Satz an Flavor verfügbar.

Was ist das?

Dieser Abschnitt wird mehrmals am Tag automatisch aus der STACKIT-Doku übernommen. Hier lässt er sich nicht ändern. Änderungen gehören in die STACKIT-Doku.

Pod-Ressourcen und JVM-Budget

Die Referenz definiert Ressourcen im Spring-Boot-Deployment in main.tf, nicht über eigene CPU- oder Speichervariablen. Java fordert 100m CPU und 512Mi Speicher an; die Limits liegen bei 500m und 1Gi. JAVA_TOOL_OPTIONS setzt den initialen Heap auf 128 MiB und den maximalen Heap auf 512 MiB. Beide Exporter-Sidecars besitzen jeweils ein eigenes Ressourcenbudget.

Vergleichen Sie tatsächlichen Working Set, Heap, Nicht-Heap-Speicher, Throttling, Startverhalten und Sidecar-Verbrauch, bevor Sie das Deployment ändern. Lassen Sie neben dem Java-Heap Raum für Threads und nativen Speicher. Ressourcenänderungen können Pods neu ausrollen und einen Workload mit einer Replika unterbrechen; planen und validieren Sie entsprechend. Erfinden Sie keine nicht unterstützten springboot_cpu- oder Speichervariablen.

Regelkreis für Pod-Autoscaling

Qualifizieren Sie Metriken, Replikaverantwortung, Anwendungssicherheit und Telemetrie pro Pod vor einem begrenzten HPA-Experiment.

HPA vergleicht die beobachtete Pod-CPU-Auslastung mit dem konfigurierten Ziel und passt die Replikazahl innerhalb von Mindest- und Höchstgrenzen an. Die Ressourcenmetrik setzt realistische Requests und eine verfügbare Kubernetes Metrics API voraus; erfolgreiches Grafana-Scraping beweist deren Funktion nicht. Die Ressourcenauslastung umfasst auch die Sidecar-Budgets. HPA allein kann keine Worker-Kapazität erzeugen.

Prüfen Sie vor einem Experiment mit mehreren Replikas Sitzungszustand, gemeinsame Schreibzugriffe, Initialisierung und Datenbankverbindungslimits. Das aktuelle Anwendungs-/Exporter-Scraping nutzt einen lastverteilten Service-Endpunkt; Replikas können wechselnd statt als getrennte Zeitreihen erfasst werden. Etablieren Sie Anwendungsscraping pro Pod und vermeiden Sie doppelte Datenbankaggregation, bevor Sie skalierten Anfrageraten oder Summen vertrauen. Diese Erweiterungen gehören nicht zum validierten Ein-Replika-Pfad.

Konfiguration für Pod-Autoscaling

Testen Sie begrenztes HPA erst nach Abschluss von Migration und Rollback-Arbeiten in einem separat freigegebenen Experiment. Diese beispielhaften Grenzen sind keine Sizing-Empfehlungen für die Produktion:

enable_springboot_hpa                            = true
springboot_hpa_min_replicas                      = 1
springboot_hpa_max_replicas                      = 3
springboot_hpa_target_cpu_utilization_percentage = 70

Das Deployment definiert außerdem springboot_replicas in Terraform. Prüfen Sie spätere Pläne auf konkurrierende Replikaänderungen und legen Sie vor unbeaufsichtigtem HPA-Betrieb eine explizite Zuständigkeit fest. Das Migrationsskript lehnt HPA-verwaltete Ziele ab; deaktivieren Sie HPA vor jeder späteren Migration und jedem Rollback.

Prüfen Sie den Plan und beobachten Sie anschließend HPA mit der konfigurierten Kubeconfig:

terraform plan -var-file=env.tfvars -out=tfplan.optimize
terraform apply tfplan.optimize
kubectl get hpa,pods -n springboot
kubectl describe hpa springboot -n springboot
kubectl top pods -n springboot --containers

Cluster- und Plattform-Rightsizing

Stellen Sie genügend Worker-Reserve bereit und berücksichtigen Sie Pool-Kapazität, Zonengrenzen und Rollout-Unterbrechungen.

STACKIT-SKE-Grafana-Dashboard mit tatsächlicher CPU- und RAM-Nutzung gegenüber Requests und Limits, einem Node, 17 laufenden Pods, keinen wartenden oder fehlgeschlagenen Pods und API-Server-Aktivität

Das SKE-Dashboard zeigt dasselbe Intervall von 14:41 bis 15:41 UTC am 25. September 2026. Die tatsächliche CPU-Nutzung beträgt etwa 2 %, während CPU-Requests etwa 34 % der Cluster-Kapazität reservieren. Das verdeutlicht, warum Scheduling-Reservierungen und gemessener Verbrauch gemeinsam zu bewerten sind. Die 17 laufenden Pods umfassen Plattformkomponenten, nicht 17 Spring-Boot-Replikas; das Workload-Dashboard oben zeigt den einzelnen Anwendungspod. Keine fehlgeschlagenen oder wartenden Pods zu diesem Zeitpunkt sind ein nützliches Zustandssignal, kein Beweis für Spitzenlast- oder Ausfalltoleranz.

Passen Sie node_pool_minimum, node_pool_maximum und node_pool_machine_type anhand aggregierter Requests, beobachteter Nachfrage, System-Overhead und Rollout-Reserve an. Gleiche Mindest- und Höchstwerte fixieren die Pool-Größe; ein höheres HPA-Maximum kann diese Kapazitätsgrenze nicht überwinden.

Die Referenz konfiguriert einen Node Pool. Weitere Pools und Zonenplatzierung erfordern eine explizite Architekturerweiterung. Die Availability Zone eines Node Pools kann nicht ohne Neuerstellung geändert werden; eine andere Zone benötigt einen neuen Pool-Namen und einen geprüften Migrationsplan. Prüfen Sie tatsächliche SKE-Kapazität und geplanten Worker-Austausch vor einer Flavor- oder Topologieänderung.

STACKIT Dokumentation docs.stackit.cloud SKE Node Pools verwalten Dokumentation öffnen

Ingress-Ebene (Durchsatz)

Der implementierte Einstiegspunkt ist Envoy Gateway mit HTTPRoutes, kein älterer Ingress. Vergleichen Sie Gateway- und Service-Verhalten mit Anwendungs- und Datenbanklatenz vor einer Worker-Größenänderung. Der optionale clusterinterne Lastgenerator umgeht öffentliches Gateway, DNS und TLS; ergänzen Sie einen freigegebenen externen End-to-End-Test. Dieses Asset behauptet keine gemessene öffentliche Durchsatzgrenze.

Storage-Ebene (Performance persistenter Volumes)

Spring Music speichert seine maßgeblichen Daten in Flex. In dieser Basis gibt es kein Anwendungs-PersistentVolume für Rightsizing. node_pool_volume_size betrifft Worker-Speicher, nicht Datenbankkapazität. Nutzen Sie die Flex-Speichereinstellungen für Albumdaten und bewerten Sie Wachstum, Abfrage-I/O, Aufbewahrung und Recovery gemeinsam. Ergänzen Sie Kubernetes-Speicher nur für einen separat entworfenen Persistenzbedarf.

Optimize-Workflow für Replatform-Workloads

Repräsentative Metriken, fachliche Abnahmegrenzen, aktuelle Konfiguration und Kosten erfassen.
Eine Hypothese auswählen: Pod-Budget, Worker-Kapazität, Gateway oder Datenbankdruck.
Erwartete Verbesserung und Rollback-Schwelle festlegen; erforderliche Backups und Recovery prüfen.
Einen gespeicherten Terraform-Plan prüfen, fachfremde Änderungen ablehnen und im freigegebenen Fenster anwenden.
Rollout, Gateway, Albumdaten, tatsächliche Scrapes, Latenz, Fehler, Kapazität und Kosten gegen die Baseline validieren.
Die Änderung nur beibehalten, wenn das vereinbarte Beobachtungsfenster die Abnahme erfüllt; andernfalls dem vorab freigegebenen Rücknahme- oder Recovery-Verfahren folgen.

Rollback und Abnahme

Stellen Sie bei reversiblen Konfigurationsänderungen die zuvor geprüften Werte wieder her und prüfen Sie vor dem Apply einen neuen Plan. Setzen Sie nicht voraus, dass eine kleinere Datenbank oder die Rückkehr zur alten Speicherklasse unterstützt wird. War HPA das Experiment, deaktivieren Sie es und stellen Sie die gewünschte Replikazahl über die geprüfte Konfiguration wieder her; bestätigen Sie danach ein stabiles Deployment.

Dokumentieren Sie Vorher-/Nachher-Nachweise, Konfigurationsstand, fachliche Ergebnisse und Kostenwirkung. Ein Datenbank-Migrations-Rollback ersetzt nicht die Rücknahme einer Optimierungsänderung.

Hinweise

Der Live-Referenztest bestätigte den Workload mit einer Replika, Datenmigration und Rollback sowie den Dashboard-/Scrape-Pfad. Er wies weder Autoscaling-Verhalten noch optimales Sizing, Produktionslastkapazität oder Hochverfügbarkeit nach. Erheben Sie für jede dieser Entscheidungen neue Nachweise.

Externe Quelle kubernetes.io Kubernetes Horizontal Pod Autoscaler Regelkreis, Metrikvoraussetzungen und Skalierungsgrenzen der Kubernetes-Referenz vor der Aktivierung von Autoscaling prüfen. Externe Seite öffnen Führt von der Route weg

SAFE

Optimierung validieren

Migration design-and-mobilize use-cases migrate optimize replatform kubernetes rightsizing hpa spring-boot postgresql

Replatform Spring Boot auf Kubernetes mit Rightsizing und Pod-Skalierung optimieren

STACKIT

Dasselbe Spring-Boot-Replatform anhand gemessener Pod- und Node-Kapazität, PostgreSQL-Flex-Tuning, Skalierungsleitplanken und reversibler Änderungen optimieren.