kubectl apply vs create: Wann welchen Befehl nutzen?

Wer mit Kubernetes startet, stolpert frueh ueber die Frage: kubectl apply oder kubectl create? Beide Befehle erstellen Ressourcen -- aber sie funktionieren grundlegend anders. Dazu kommt kubectl replace, das nochmal eigene Regeln hat. Dieser Artikel klaert den Unterschied, zeigt typische Fallstricke und gibt klare Empfehlungen fuer den Praxisalltag.

TL;DR

• kubectl apply arbeitet deklarativ: Sie beschreiben den gewuenschten Zustand, Kubernetes berechnet die Aenderungen. Funktioniert zum Erstellen und Aktualisieren.
• kubectl create ist imperativ: Erstellt eine Ressource einmalig. Schlaegt fehl, wenn die Ressource schon existiert.
• kubectl replace ersetzt eine Ressource komplett. Felder, die nicht in der neuen YAML stehen, gehen verloren.
• Fuer produktive Workflows ist kubectl apply fast immer die richtige Wahl.

Der fundamentale Unterschied: Deklarativ vs. Imperativ

Bevor wir in die Befehle einsteigen, muessen Sie den Kern verstehen. Testen Sie es direkt:

# Imperativ: "Erstelle dieses Deployment"
kubectl create deployment nginx --image=nginx:1.27

# Deklarativ: "Stelle sicher, dass dieses Deployment so existiert"
kubectl apply -f deployment.yaml

Imperativ heisst: Sie geben Kubernetes einen konkreten Befehl. "Erstelle X." Wenn X schon existiert, gibt es einen Fehler. Sie sagen was passieren soll.

Deklarativ heisst: Sie beschreiben den Zielzustand. Kubernetes vergleicht den aktuellen Zustand mit dem gewuenschten und fuehrt nur die noetige Aenderungen durch. Sie sagen wie es aussehen soll.

kubectl create im Detail

create ist der einfachste Befehl. Er erstellt eine Ressource und meldet einen Fehler, wenn sie schon existiert:

# Ressource aus YAML erstellen
kubectl create -f service.yaml

# Imperativ ein Deployment erzeugen
kubectl create deployment redis --image=redis:7 --replicas=3

# Namespace erstellen
kubectl create namespace staging

Was passiert, wenn die Ressource schon da ist?

Error from server (AlreadyExists): deployments.apps "redis" already exists

Genau hier liegt das Problem fuer automatisierte Workflows. Wenn Ihre CI/CD Pipeline kubectl create nutzt, schlaegt der zweite Lauf fehl. Deshalb sieht man in Skripten manchmal dieses Anti-Pattern:

# Nicht empfohlen -- fragil und fehleranfaellig
kubectl delete -f deployment.yaml --ignore-not-found
kubectl create -f deployment.yaml

Das funktioniert, verursacht aber Downtime, weil die Ressource kurz geloescht wird.

Wann create sinnvoll ist

• Einmalige Aktionen: Namespace erstellen, Secret anlegen, Job starten
• Schnelle Tests in der lokalen Entwicklung
• Generierung von YAML-Vorlagen mit --dry-run=client -o yaml

Gerade der letzte Punkt ist im Alltag Gold wert:

# YAML-Template generieren, ohne etwas zu erstellen
kubectl create deployment web --image=nginx:1.27 --replicas=3 \
  --dry-run=client -o yaml > deployment.yaml

kubectl apply im Detail

apply ist der Arbeitspferd-Befehl fuer produktive Kubernetes-Umgebungen. Er erstellt Ressourcen, wenn sie nicht existieren, und aktualisiert sie, wenn sie schon da sind.

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web-app
  template:
    metadata:
      labels:
        app: web-app
    spec:
      containers:
      - name: web
        image: nginx:1.27
        resources:
          requests:
            cpu: 100m
            memory: 128Mi

# Erstes apply: erstellt die Ressource
kubectl apply -f deployment.yaml

# Image aendern, erneut apply: aktualisiert nur das Image
# (alle anderen Felder bleiben erhalten)
kubectl apply -f deployment.yaml

Wie apply intern funktioniert

kubectl apply speichert den letzten angewandten Zustand als Annotation (kubectl.kubernetes.io/last-applied-configuration) auf der Ressource. Beim naechsten apply vergleicht Kubernetes drei Versionen:

1. Letzte angewandte Konfiguration (Annotation)
2. Aktuelle Live-Konfiguration (was im Cluster steht)
3. Neue gewuenschte Konfiguration (Ihre YAML-Datei)

Daraus berechnet Kubernetes einen Three-Way-Merge. Das bedeutet: Wenn jemand manuell ein Label hinzugefuegt hat und Ihre YAML-Datei dieses Label nicht enthaelt, bleibt es erhalten -- solange es nicht in der letzten Annotation stand.

kubectl replace: Die Holzhammer-Methode

replace ersetzt eine Ressource komplett. Alles, was nicht in der neuen YAML steht, geht verloren:

kubectl replace -f deployment.yaml

Das klingt gefaehrlich -- und ist es auch. Ein typisches Problem:

# Jemand hat manuell ein Label hinzugefuegt
kubectl label deployment web-app team=backend

# replace ueberschreibt alles -- das Label ist weg
kubectl replace -f deployment.yaml

Wann replace sinnvoll ist

• Sie wollen sicherstellen, dass die Ressource exakt Ihrer YAML entspricht, ohne Altlasten
• Bei Ressourcen, die sich nicht per apply aktualisieren lassen (selten, aber es kommt vor)
• In Kombination mit --force fuer einen Delete-and-Recreate-Workflow:

# Loescht und erstellt die Ressource neu -- verursacht kurze Downtime
kubectl replace --force -f deployment.yaml

Typische Fallstricke

Fallstrick 1: create in CI/CD Pipelines

Wie oben beschrieben: create schlaegt beim zweiten Lauf fehl. Nutzen Sie in Pipelines immer apply.

Fallstrick 2: apply nach create

Wenn Sie eine Ressource mit create erstellt haben und danach apply nutzen, erscheint diese Warnung:

Warning: resource deployments/web-app is missing the
kubectl.kubernetes.io/last-applied-configuration annotation

Die Annotation fehlt, weil create sie nicht setzt. Das erste apply fuegt sie hinzu, danach funktioniert alles normal. Kein Grund zur Panik -- aber ein Grund, von Anfang an apply zu nutzen.

Fallstrick 3: Felder loeschen mit apply

Wenn Sie ein Feld aus Ihrer YAML entfernen und apply ausfuehren, wird es aus der Ressource entfernt -- aber nur, wenn es in der last-applied-configuration Annotation stand. Felder, die manuell oder durch Controller hinzugefuegt wurden, bleiben.

Fallstrick 4: Server-Side Apply

Seit Kubernetes 1.22 gibt es Server-Side Apply als Alternative:

kubectl apply --server-side -f deployment.yaml

Server-Side Apply loest Konflikte besser, weil der Server den Merge durchfuehrt und Feld-Ownership trackt. Fuer Teams, die gleichzeitig an Ressourcen arbeiten (z.B. HPA aendert Replicas, waehrend Sie das Image updaten), ist das die bessere Wahl.

Entscheidungshilfe

Nutzen Sie diese einfache Regel:

• Produktion, CI/CD, GitOps: kubectl apply -f
• Schneller Test, einmalige Aktion: kubectl create
• YAML generieren: kubectl create --dry-run=client -o yaml
• Komplette Ersetzung erzwingen: kubectl replace -f

Im Zweifel: apply. Es ist der sicherste und flexibelste Befehl.

FAQ

Kann ich apply und create mischen?

Technisch ja, aber Sie bekommen beim ersten apply nach einem create eine Warnung wegen der fehlenden Annotation. Bleiben Sie bei einem Ansatz -- idealerweise apply.

Ist kubectl apply idempotent?

Ja. Sie koennen apply beliebig oft mit derselben YAML ausfuehren. Wenn sich nichts geaendert hat, passiert nichts (die Ressource wird als "unchanged" gemeldet).

Was ist der Unterschied zwischen apply und patch?

apply sendet die komplette Ressource und berechnet einen Merge. kubectl patch aendert gezielt einzelne Felder, ohne die gesamte YAML zu benoetigen. Fuer schnelle Einzelaenderungen ist patch praktisch, fuer reproduzierbare Deployments apply.

Wann sollte ich Server-Side Apply nutzen?

Wenn mehrere Akteure dieselbe Ressource aendern (z.B. HPA, VPA, CI/CD Pipeline). Server-Side Apply trackt, wer welches Feld "besitzt", und verhindert versehentliches Ueberschreiben.

Tipp: Gewoehnen Sie sich an kubectl apply und speichern Sie alle Ressourcen als YAML in Git. So haben Sie jederzeit einen reproduzierbaren, nachvollziehbaren Zustand Ihres Clusters.

Weiterführende Artikel:

• Kubernetes Tutorial: Erster Pod, Deployment und Service
• Kubernetes Deployment: Rolling, Blue-Green, Canary