Was ich unter der Dokumentation verstanden habe, ist Folgendes:

• kubectl create = Erstellt eine neue k8s-Ressource im Cluster
• kubectl replace = Aktualisiert eine Ressource im Live-Cluster
• kubectl apply = Wenn ich erstellen + ersetzen möchte ( Referenz )

Meine Fragen sind

1. Warum gibt es drei Vorgänge, um dieselbe Aufgabe in einem Cluster auszuführen?
2. Was sind die Anwendungsfälle für diese Operationen?
3. Wie unterscheiden sie sich unter der Haube?

Das sind zwei verschiedene Ansätze:

Imperatives Management

kubectl createist das, was wir Imperatives Management nennen . Bei diesem Ansatz teilen Sie der Kubernetes-API mit, was Sie erstellen, ersetzen oder löschen möchten, und nicht, wie Ihre K8-Clusterwelt aussehen soll.

Deklarative Verwaltung

kubectl applyist Teil des Ansatzes der deklarativen Verwaltung , bei dem Änderungen, die Sie möglicherweise auf ein lebendes Objekt (dh bis scale) angewendet haben, " beibehalten " werden, selbst wenn Sie applyandere Änderungen am Objekt vornehmen.

Weitere Informationen zur imperativen und deklarativen Verwaltung finden Sie in der Dokumentation zur Kubernetes-Objektverwaltung .

Wenn Sie in einem CI-Skript ausgeführt werden, treten Probleme mit zwingenden Befehlen auf, da beim Erstellen ein Fehler ausgelöst wird, wenn die Ressource bereits vorhanden ist.

Sie können die Ausgabe Ihres imperativen Befehls mithilfe von und Optionen anwenden (deklaratives Muster) :--dry-run=true-o yaml

kubectl create whatever --dry-run=true -o yaml | kubectl apply -f -

Der obige Befehl löst keinen Fehler aus, wenn die Ressource bereits vorhanden ist (und aktualisiert die Ressource bei Bedarf).

Dies ist in einigen Fällen sehr nützlich, in denen Sie das deklarative Muster nicht verwenden können (z. B. beim Erstellen eines Docker-Registrierungsgeheimnisses).

Nur um nach meinem Verständnis eine direktere Antwort zu geben:

apply- nimmt inkrementelle Änderungen an einem vorhandenen Objekt vor
create- erstellt ein ganz neues Objekt (zuvor nicht vorhanden / gelöscht)


Aus einem DigitalOcean-Artikel, der von der Kubernetes-Website verlinkt wurde:

Wir verwenden Apply anstelle von Create hier, damit wir in Zukunft Änderungen schrittweise auf die Ingress Controller-Objekte anwenden können, anstatt sie vollständig zu überschreiben.

Dies sind zwingende Befehle :

kubectl run = kubectl create deployment

Vorteile:

• Einfach, leicht zu erlernen und leicht zu merken.
• Benötigen Sie nur einen einzigen Schritt, um Änderungen am Cluster vorzunehmen.

Nachteile:

• Nicht in Änderungsprüfungsprozesse integrieren.
• Stellen Sie keinen Prüfpfad bereit, der mit Änderungen verbunden ist.
• Geben Sie keine Quelle für Aufzeichnungen an, außer für das, was live ist.
• Geben Sie keine Vorlage zum Erstellen neuer Objekte an.

Dies sind zwingende Objektkonfigurationen :

kubectl create -f your-object-config.yaml

kubectl delete -f your-object-config.yaml

kubectl replace -f your-object-config.yaml

Vorteile gegenüber imperativen Befehlen:

• Kann in einem Versionsverwaltungssystem wie Git gespeichert werden.
• Kann in Prozesse wie das Überprüfen von Änderungen vor Push- und Audit-Trails integriert werden.
• Bietet eine Vorlage zum Erstellen neuer Objekte.

Nachteile gegenüber zwingenden Befehlen:

• Erfordert ein grundlegendes Verständnis des Objektschemas.
• Erfordert den zusätzlichen Schritt des Schreibens einer YAML-Datei.

Vorteile gegenüber der deklarativen Objektkonfiguration:

• Einfacher und leichter zu verstehen.
• Reifer nach Kubernetes Version 1.5.

Nachteile gegenüber der deklarativen Objektkonfiguration:

• Funktioniert am besten mit Dateien, nicht mit Verzeichnissen.
• Aktualisierungen von Live-Objekten müssen in Konfigurationsdateien enthalten sein, da sie sonst beim nächsten Austausch verloren gehen.

Dies sind deklarative Objektkonfigurationen

kubectl diff -f configs/

kubectl apply -f configs/

Vorteile gegenüber der imperativen Objektkonfiguration:

• Änderungen, die direkt an lebenden Objekten vorgenommen werden, bleiben erhalten, auch wenn sie nicht wieder in die Konfigurationsdateien zusammengeführt werden.
• Bessere Unterstützung für den Betrieb in Verzeichnissen und die automatische Erkennung von Operationstypen (Erstellen, Patchen, Löschen) pro Objekt.

Nachteile gegenüber der zwingenden Objektkonfiguration:

• Es ist schwieriger, Ergebnisse zu debuggen und zu verstehen, wenn sie unerwartet sind.
• Teilaktualisierungen mit Diffs führen zu komplexen Zusammenführungs- und Patchvorgängen.

Die folgende Erklärung aus der offiziellen Dokumentation half mir zu verstehen kubectl apply.

Dieser Befehl vergleicht die Version der Konfiguration, die Sie pushen, mit der vorherigen Version und wendet die vorgenommenen Änderungen an, ohne automatisierte Änderungen an Eigenschaften zu überschreiben, die Sie nicht angegeben haben.

kubectl create Auf der anderen Seite werden Ressourcen erstellt (sollten nicht vorhanden sein).

kubectl create kann jeweils mit einer Objektkonfigurationsdatei arbeiten. Dies wird auch als imperatives Management bezeichnet

kubectl create -f Dateiname | URL

kubectl apply arbeitet mit Verzeichnissen und deren Unterverzeichnissen, die Objektkonfigurations-Yaml-Dateien enthalten. Dies wird auch als deklarative Verwaltung bezeichnet. Es können mehrere Objektkonfigurationsdateien aus Verzeichnissen abgerufen werden. kubectl apply -f Verzeichnis /

Details:
https://kubernetes.io/docs/tasks/manage-kubernetes-objects/declarative-config/ https://kubernetes.io/docs/tasks/manage-kubernetes-objects/imperative-config/

Wir lieben Kubernetes, weil wir, sobald wir ihnen das geben, was wir wollen, herausfinden, wie wir es ohne unser Zutun erreichen können.

"erschaffen" ist wie GOTT zu spielen, indem man die Dinge selbst in die Hand nimmt. Es ist gut für das lokale Debuggen, wenn Sie nur mit dem POD arbeiten möchten und sich nicht um Deployment / Replication Controller kümmern möchten.

"anwenden" spielt nach den Regeln. "Übernehmen" ist wie ein Master-Tool, mit dem Sie erstellen und ändern können und für dessen Verwaltung Sie keine Pods benötigen.