---
title: "Kubernetes Live-Replikation mit Traffic-Split"
description: Konkrete Vorlage für die Kubernetes-zu-Kubernetes-Migration mit Live-Datenreplikation und stufenweisem Traffic-Split für strikte Kontinuitätsanforderungen.
sidebar:
  badge:
    text: "STACKIT"
    variant: success
scfAsset:
  managed: false
  category: "runbook"
  external: false
  tags: ["design-and-mobilize", "use-cases", "replatform", "kubernetes", "replication", "traffic-split", "zero-downtime"]
  maintainers:
    - user: "lukas.weberruss"
      role: true
      website: true
source_url: "https://framework.stackit.cloud/de/migration/assetcontainer/stackit/runbook-k8s-live-replication-traffic-split/"
source_file: "docs/de/migration/assetcontainer/stackit/runbook-k8s-live-replication-traffic-split.mdx"
---

## Use Case

- **Kategorie:** Kubernetes-zu-Kubernetes-Migration
- **State-Profil:** Stateful oder gemischte kritische Workloads
- **Ansatz:** Live-Replikation plus stufenweiser Traffic-Split

## Verbindliche Voraussetzungen

- **Replikationspfad validiert:** Die Datenreplikations-Pipeline erfüllt die Ziel-RPO/RTO.
- **Traffic-Engineering verfügbar:** DNS, Ingress, Service Mesh oder Gateway unterstützen gewichtetes Routing.
- **Dual-Run-Betriebsmodell bereit:** Ownership, Monitoring und Incident-Playbooks für den Parallelbetrieb existieren.
- **Rollback-Trigger-Policy freigegeben:** Quantitative Rollback-Schwellwerte sind vor der Migration vereinbart.

## Nicht geeignet, wenn

- **Replikations-Lag nicht kontrollierbar ist:** Aktualitätsziele können nicht eingehalten werden.
- **Keine progressive Traffic-Steuerung existiert:** Der Cutover kann nur als Voll-Switch erfolgen.

## Umsetzungsvorlage

### Phase 1: Dual-Run-Baseline etablieren

1. Ziel-Stack deployen und Health ohne Produktions-Traffic validieren.
2. Replikations-Pipeline starten und Lag-Metriken verifizieren.
3. Alerting und SLO-Monitoring über Quelle und Ziel hinweg angleichen.

### Phase 2: Progressiver Traffic-Split

1. Kleinen Traffic-Anteil aufs Ziel verlagern und Error-/Latenz-Budgets beobachten.
2. Traffic nach jedem Validierungs-Gate in kontrollierten Inkrementen erhöhen.
3. Quelle aktiv halten, bis der finale Konfidenz-Schwellwert erreicht ist.

### Phase 3: Finaler Switch und Aufräumen

1. Vollständigen Traffic-Umzug aufs Ziel abschließen.
2. Erhöhtes Monitoring über das Stabilisierungsfenster fortführen.
3. Quellpfad nach Sign-off und Nachweis-Archivierung außer Betrieb nehmen.

## Validierungscheckliste

- **Replikations-Health:** Lag- und Replay-Status innerhalb der definierten Grenzen.
- **Traffic-Qualität:** Error-Rate und Latenz auf jeder Split-Stufe stabil.
- **Business Continuity:** Kritische User Journeys bleiben unterbrechungsfrei.
- **Rollback-Readiness:** Der umgekehrte Split kann innerhalb der vereinbarten Zeit laufen.