---
title: "Kubernetes Stateless-Migration mit GitOps-Re-Deployment"
description: Konkrete Vorlage für die stateless Kubernetes-zu-Kubernetes-Migration per GitOps-Re-Deployment mit kontrolliertem, schrittweise validiertem Rollout-Pfad.
sidebar:
  badge:
    text: "STACKIT"
    variant: success
scfAsset:
  managed: false
  category: "runbook"
  external: false
  tags: ["design-and-mobilize", "use-cases", "replatform", "kubernetes", "stateless", "gitops", "redeploy"]
  maintainers:
    - user: "lukas.weberruss"
      role: true
      website: true
source_url: "https://framework.stackit.cloud/de/migration/assetcontainer/stackit/runbook-k8s-stateless-gitops-redeploy/"
source_file: "docs/de/migration/assetcontainer/stackit/runbook-k8s-stateless-gitops-redeploy.mdx"
---

## Use Case

- **Kategorie:** Kubernetes-zu-Kubernetes-Migration
- **State-Profil:** Stateless Workloads
- **Ansatz:** GitOps-getriebenes Re-Deployment in den Ziel-Cluster

## Verbindliche Voraussetzungen

- **GitOps-Baseline aktiv:** Source-of-Truth-Repository und Promotion-Flow sind betriebsbereit.
- **Cluster-Parität validiert:** Namespaces, Policies, Secrets-Modell und Ingress-Regeln sind gemappt.
- **Traffic-Steuerung verfügbar:** Ein progressiver Cutover-Pfad ist über DNS, Ingress oder Gateway möglich.
- **Observability-Baseline bereit:** Golden Signals und Rollback-Kriterien sind definiert und überwacht.

## Nicht geeignet, wenn

- **Stateful-Abhängigkeiten dominieren:** Persistente Datenmigration ist im selben Pfad erforderlich.
- **GitOps-Controls fehlen:** Keine verlässliche deklarative Deployment-Pipeline existiert.

## Umsetzungsvorlage

### Phase 1: Ziel-Cluster-Baseline vorbereiten

1. Namespace-, Policy- und Secret-Grundgerüst anwenden.
2. Unterstützende Services und Ingress-Baseline deployen.
3. Readiness-Probes und Skalierungsverhalten validieren.

### Phase 2: Deployment per GitOps

1. Manifeste/Helm-Values in den Ziel-Environment-Branch promoten.
2. Reconciliation-Status und Runtime-Health verifizieren.
3. Funktionale und Integrations-Checks vor dem Cutover durchführen.

### Phase 3: Progressiver Cutover

1. Traffic schrittweise auf die Ziel-Workloads verlagern.
2. Golden Signals bei jedem Inkrement beobachten.
3. Vollständigen Switch und Stabilisierungsphase abschließen.

## Validierungscheckliste

- **Deployment-Parität:** Gewünschte Replicas und Service-Endpunkte entsprechen dem Plan.
- **Funktionale Parität:** Kritische API- und UI-Pfade laufen erfolgreich.
- **Performance-Parität:** Latenz- und Error-Budgets bleiben innerhalb der Schwellwerte.
- **Rollback-Readiness:** Der vorherige Traffic-Anteil kann bei einem Trigger wiederhergestellt werden.