kubectl apply vs. set: Die Wahl des richtigen Befehls für Ressourcen-Updates

Kubernetes, die führende Container-Orchestrierungsplattform, bietet leistungsstarke Tools für die Verwaltung des Lebenszyklus von Anwendungen. Ein zentraler Aspekt dieser Verwaltung ist die Aktualisierung bestehender Ressourcen wie Deployments, Services oder ConfigMaps. Während kubectl mehrere Befehle für diesen Zweck bietet, repräsentieren kubectl apply und die kubectl set-/kubectl edit-Familie zwei grundlegend unterschiedliche Philosophien: deklarative vs. imperative Updates.

Zu verstehen, wann und wie jeder Ansatz zu verwenden ist, ist entscheidend für die Aufrechterhaltung stabiler, zuverlässiger und auditierbarer Kubernetes-Bereitstellungen. Der Missbrauch dieser Befehle kann zu Konfigurationsdrift, schwierigem Debugging und betrieblichen Inkonsistenzen führen. Dieser Artikel wird in die Nuancen von kubectl apply, kubectl set und kubectl edit eintauchen und Sie mit dem Wissen ausstatten, um fundierte Entscheidungen für Ihre Ressourcen-Update-Strategien zu treffen.

Die Kernherausforderung: Verwaltung des Ressourcenzustands

In Kubernetes wird jede Komponente – von einem laufenden Pod bis zu einem Netzwerkdienst – als API-Objekt dargestellt. Diese Objekte haben einen gewünschten Zustand, den Sie in YAML- oder JSON-Manifestdateien definieren, und einen beobachteten Zustand, der ihre aktuelle Realität innerhalb des Clusters widerspiegelt. Das primäre Ziel jedes kubectl-Update-Befehls ist es, diese beiden Zustände abzugleichen, aber die Methode des Abgleichs variiert erheblich.

Verständnis von kubectl apply: Der deklarative Ansatz

kubectl apply ist der Grundstein des deklarativen Ressourcenmanagements in Kubernetes. Mit diesem Ansatz definieren Sie den gewünschten Zustand Ihrer Ressourcen in einer lokalen Konfigurationsdatei (oder einem Verzeichnis von Dateien) und weisen Kubernetes dann an, den Zustand des Clusters an diese Definition anzupassen.

Wie kubectl apply funktioniert (Drei-Wege-Merge)

Wenn Sie kubectl apply -f your-manifest.yaml ausführen, führt Kubernetes einen ausgeklügelten Drei-Wege-Merge durch:

1. Zuletzt angewendete Konfiguration: Der Zustand der Ressource, wie er zuletzt mit kubectl apply angewendet wurde. Dieser Zustand wird in einer Annotation (kubectl.kubernetes.io/last-applied-configuration) am Live-Objekt gespeichert.
2. Live-Konfiguration: Der aktuelle Zustand der Ressource im Kubernetes API-Server.
3. Neue Konfiguration: Der Zustand, der in Ihrer Datei your-manifest.yaml definiert ist.

Der Merge-Algorithmus vergleicht diese drei Versionen, um festzustellen, welche Änderungen vorgenommen werden müssen. Er behandelt Konflikte intelligent, indem er Änderungen aus der neuen Konfiguration priorisiert und gleichzeitig Felder respektiert, die seit dem letzten apply imperativ geändert wurden (obwohl dies zu Problemen führen kann, wie unten erläutert).

Dieser Prozess gewährleistet Idempotenz: Das mehrmalige Anwenden desselben Manifests führt zum gleichen Clusterzustand ohne unbeabsichtigte Nebenwirkungen, vorausgesetzt, es sind keine anderen Änderungen aufgetreten.

Praktisches Beispiel: Anwenden eines Deployments

Angenommen, Sie haben eine deployment.yaml-Datei:

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-webapp
  labels:
    app: my-webapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-webapp
  template:
    metadata:
      labels:
        app: my-webapp
    spec:
      containers:
      - name: webapp-container
        image: nginx:1.21.0
        ports:
        - containerPort: 80

Um dieses Deployment zu erstellen oder zu aktualisieren, würden Sie ausführen:

kubectl apply -f deployment.yaml

Wenn Sie später das image in deployment.yaml auf nginx:1.22.0 ändern und kubectl apply erneut ausführen, wird Kubernetes das Deployment aktualisieren, um das neue Image zu verwenden, während andere Einstellungen erhalten bleiben.

Vorteile von kubectl apply

• Wahrheitsquelle: Ihre Konfigurationsdateien werden zur einzigen Wahrheitsquelle für den gewünschten Zustand Ihres Clusters. Dies passt gut zu den GitOps-Prinzipien.
• Auditierbarkeit & Versionskontrolle: Änderungen werden in Ihrem Versionskontrollsystem (z. B. Git) verfolgt, was einen klaren Audit-Trail und einfache Rollbacks ermöglicht.
• Konsistenz: Gewährleistet Konsistenz über Umgebungen hinweg (Entwicklung, Staging, Produktion).
• Idempotenz: Wiederholte apply-Operationen haben den gleichen Effekt und verhindern unbeabsichtigte Modifikationen.
• Komplexe Updates: Handhabt komplexe Updates, die mehrere Ressourcentypen oder signifikante Änderungen über viele Felder hinweg betreffen.

Wann kubectl apply verwendet werden sollte

• Primäre Methode für alle Ressourcen-Erstellungen und -Updates.
• Beim Bereitstellen von Anwendungen über CI/CD-Pipelines.
• Für die Verwaltung von Infrastructure-as-Code.
• Bei der Teamarbeit, um konsistente Konfigurationen sicherzustellen.

Tipps und Warnungen für kubectl apply

• Halten Sie Ihre Manifestdateien immer aktuell mit dem gewünschten Zustand. Alle mit kubectl set oder kubectl edit vorgenommenen Änderungen, die nicht in Ihren Manifestdateien reflektiert sind, werden beim nächsten apply überschrieben oder führen zu Merge-Konflikten.
• Feld-Manager: Kubernetes 1.16+ führte Server-Side Apply (SSA) ein, das den „Feld-Manager“ (z. B. kubectl, einen Controller) verfolgt, der für jedes Feld in einer Ressource verantwortlich ist. Dies hilft, Konflikte zu vermeiden, wenn mehrere Quellen dieselbe Ressource ändern. Obwohl leistungsstark, sollten Sie sich bewusst sein, wie verschiedene Tools mit der Feldverwaltung interagieren könnten.

Verständnis von kubectl set und kubectl edit: Der imperative Ansatz

kubectl set und kubectl edit gehören zur imperativen Befehlsfamilie. Anstatt den gewünschten Zustand in einer Datei zu definieren, weisen Sie Kubernetes direkt an, bestimmte Aktionen auszuführen oder Live-Objekte innerhalb des Clusters zu ändern. Diese Befehle eignen sich hervorragend für schnelle, ad-hoc-Änderungen, sind aber mit bestimmten Vorbehalten verbunden.

kubectl set: Fokussierte imperative Modifikationen

kubectl set wurde entwickelt, um spezifische, gängige Änderungen an Ressourcen vorzunehmen, ohne eine Manifestdatei anfassen zu müssen. Es bietet mehrere Unterbefehle zur Änderung bestimmter Felder.

Wie kubectl set funktioniert

kubectl set modifiziert das Live-Objekt im Kubernetes API-Server direkt basierend auf den von Ihnen bereitgestellten Kommandozeilenargumenten. Es interagiert nicht mit lokalen Manifestdateien oder aktualisiert die last-applied-configuration-Annotation.

Praktisches Beispiel: Setzen eines Images

Um das Image eines Containers innerhalb eines Deployments namens my-webapp zu aktualisieren:

kubeclt set image deployment/my-webapp webapp-container=nginx:1.22.0

Dieser Befehl ändert direkt das image-Feld für den webapp-container innerhalb des my-webapp-Deployments. Wenn Sie my-webapp zuvor mit kubectl apply verwaltet hätten, würde diese Änderung einen „Drift“ zwischen Ihrer lokalen deployment.yaml und dem Live-Cluster-Zustand erzeugen.

Weitere gängige kubectl set-Befehle:

• kubectl set resources: Zum Festlegen von Ressourcenanfragen/-limits.
• kubectl set env: Zum Hinzufügen oder Aktualisieren von Umgebungsvariablen.
• kubectl set selector: Zum Ändern des Selektors einer Ressource.

kubectl edit: Interaktive imperative Modifikationen

kubectl edit ermöglicht es Ihnen, jedes Feld eines Live-Ressourcenobjekts in Ihrem Cluster direkt mit Ihrem konfigurierten Standardtexteditor (z. B. vi, nano) zu ändern.

Wie kubectl edit funktioniert

Wenn Sie kubectl edit <resource-type>/<resource-name> ausführen:

1. kubectl ruft die aktuelle YAML-Definition der Live-Ressource vom API-Server ab.
2. Es öffnet diese Definition in Ihrem lokalen Texteditor.
3. Sie nehmen Ihre gewünschten Änderungen vor und speichern die Datei.
4. kubectl sendet dann die geänderte Definition zurück an den API-Server, der versucht, die Änderungen anzuwenden. Bei Syntaxfehlern oder ungültigen Feldern werden die Änderungen abgelehnt.

Wie kubectl set arbeitet auch kubectl edit direkt am Live-Objekt und aktualisiert keine lokalen Manifestdateien oder die last-applied-configuration-Annotation.

Praktisches Beispiel: Bearbeiten eines Deployments

Um das my-webapp-Deployment in Ihrem Editor zu öffnen:

kubeclt edit deployment/my-webapp

Ihr Editor wird mit einer YAML-Repräsentation des Live-Deployments geöffnet. Sie können dann Felder wie replicas, image ändern oder neue Annotationen/Labels hinzufügen. Sobald Sie den Editor speichern und schließen, versucht kubectl, diese Änderungen anzuwenden.

Vorteile von kubectl set und kubectl edit

• Geschwindigkeit: Hervorragend für schnelle, einmalige Korrekturen oder Debugging in einer Entwicklungsumgebung.
• Flexibilität: Beliebiges Feld einer Ressource direkt ändern (mit edit).
• Ad-hoc-Änderungen: Nützlich, wenn Sie keine Manifestdatei zur Hand haben oder keine für eine triviale Änderung erstellen möchten.

Wann kubectl set/kubectl edit verwendet werden sollte

• Debugging in einem Entwicklungscluster: Temporäres Erhöhen der Replikationsanzahl oder Ändern eines Images, um einen Fix zu testen.
• Kleine, unkritische, temporäre Änderungen in Nicht-Produktionsumgebungen.
• Erkundung von Ressourcendefinitionen: kubectl edit ist eine bequeme Möglichkeit, die vollständige, Live-YAML einer Ressource zu sehen.

Warnungen für kubectl set und kubectl edit

• Konfigurationsdrift: Mit set oder edit vorgenommene Änderungen werden nicht in Ihren lokalen Manifestdateien widergespiegelt.
• Das nächste kubectl apply aus Ihrem Manifest wird diese imperativen Änderungen überschreiben oder Konflikte verursachen.
• Mangelnde Auditierbarkeit: Diese Änderungen werden nicht in der Versionskontrolle verfolgt, wodurch es schwer ist zu wissen, wer was wann geändert hat, was Debugging und Compliance behindert.
• Nicht-Idempotent: Wiederholtes Vornehmen derselben imperativen Änderung kann zu unerwartetem Verhalten führen, wenn der Ausgangszustand unbekannt ist.
• Fehlerrisiko: Manuelle Bearbeitung (insbesondere mit edit) erhöht die Wahrscheinlichkeit von Syntaxfehlern oder ungültigen Konfigurationen.

Hauptunterschiede: kubectl apply vs. kubectl set/kubectl edit

Zur Zusammenfassung der Kernunterschiede:

Merkmal	kubectl apply (Deklarativ)	kubectl set/kubectl edit (Imperativ)
Ansatz	Gewünschten Zustand in Datei definieren, Kubernetes gleicht ab.	Live-Objekte oder spezifische Felder direkt manipulieren.
Wahrheitsquelle	Lokale Konfigurationsdateien (z. B. Git-Repository).	Das Live-Cluster-Objekt selbst (ephemer).
Idempotenz	Ja, das Anwenden derselben Datei führt zum gleichen Ergebnis.	Nein, nicht inhärent. Jeder Befehl ist eine explizite Aktion.
Auditierbarkeit	Hoch (Änderungen werden in Git, last-applied-configuration verfolgt).	Niedrig (keine Versionskontrolle, Änderungen sind sofort im Cluster).
Konfliktmgmt.	3-Wege-Merge, verwendet last-applied-configuration-Annotation.	Überschreibt direkt (für set) oder führt interaktiv zusammen (für edit).
Anwendungsfall	Produktionsbereitstellungen, CI/CD, GitOps, Teamzusammenarbeit.	Schnelle Korrekturen, Debugging, Ad-hoc-Änderungen in Nicht-Produktionsumgebungen.
Risiko des Drifts	Niedrig, solange die Dateien aktuell gehalten werden.	Hoch, sehr wahrscheinlich Konfigurationsdrift von den Quelldateien verursachend.

Die Wahl des richtigen Befehls: Best Practices

Für Produktionsumgebungen und kollaborative Teams ist die Wahl klar:

• Ziehen Sie kubectl apply (oder darauf basierende GitOps-Tools wie Argo CD oder Flux CD) immer der Verwaltung Ihrer Kubernetes-Ressourcen vor. Dies stellt sicher, dass der Zustand Ihres Clusters versionskontrolliert, auditierbar und konsistent ist.
• Behandeln Sie Ihre Kubernetes-Manifestdateien als Ihre einzige Wahrheitsquelle. Alle Änderungen an Ressourcenkonfigurationen sollten idealerweise aus diesen Dateien stammen und in die Versionskontrolle übernommen werden.

Imperative Befehle wie kubectl set und kubectl edit sollten reserviert sein für:

• Temporäres Debugging oder Testen in Entwicklungs-/Staging-Clustern. Wenn Sie sie verwenden, stellen Sie sicher, dass Sie entweder die Änderung rückgängig machen oder Ihre Quell-Manifestdateien sofort aktualisieren, um den neuen Zustand widerzuspiegeln.
• Einmalige, kurzlebige Operationen, die keinen gewünschten langfristigen Zustand darstellen (z. B. das kurzzeitige Anhalten eines Deployments).

Hybrider Ansatz (Vorsicht geboten)

In einigen Szenarien müssen Sie möglicherweise schnell etwas in der Produktion hotfixen. Obwohl generell davon abgeraten wird, wenn Sie kubectl edit verwenden müssen:

1. Verstehen Sie die Auswirkungen der Konfigurationsdrift.
2. Erfassen Sie die Änderungen sofort, indem Sie kubectl get <resource> -o yaml > new-manifest.yaml ausführen.
3. Integrieren Sie diese Änderungen so schnell wie möglich wieder in Ihre versionskontrollierten Manifestdateien.

Warnung: Die regelmäßige Verwendung von kubectl edit oder kubectl set in der Produktion, ohne Ihre Quell-Manifeste zu aktualisieren, führt zu einem unüberschaubaren, nicht wiederherstellbaren Clusterzustand, in dem die tatsächliche Konfiguration stark von dem abweicht, was Ihr Team glaubt, sie sein sollte.

Fazit

kubectl apply, kubectl set und kubectl edit sind allesamt leistungsstarke Tools für die Interaktion mit Ihrem Kubernetes-Cluster. Sie dienen jedoch unterschiedlichen Zwecken und verkörpern unterschiedliche Philosophien der Ressourcenverwaltung. Indem Sie die deklarative Natur von kubectl apply und die imperative Natur von kubectl set und kubectl edit verstehen, können Sie Best Practices anwenden, die zu stabileren, zuverlässigeren und wartbareren Kubernetes-Bereitstellungen führen.

Für fast alle persistente Ressourcenverwaltung, insbesondere in der Produktion, setzen Sie auf kubectl apply und versionskontrollieren Sie Ihre Konfigurationsdateien. Reservieren Sie imperative Befehle für temporäre, ad-hoc-Fehlerbehebung und stellen Sie sicher, dass alle kritischen Änderungen schnell wieder in Ihren deklarativen Manifesten widergespiegelt werden. Diese Disziplin wird für reibungslose Operationen und eine nahtlose Zusammenarbeit in Ihrer Kubernetes-Umgebung von unschätzbarem Wert sein.