kubectl apply und kubectl create beides sind zwei unterschiedliche Ansätze zum Erstellen von Ressourcen in der Kubernetes-Clusterumgebung.
Beide erstellen Ressourcen entweder aus einer Datei oder aus STDIN.
kubectl anwenden und erstellen:Zwei Ansätze zum Erstellen von Ressourcen
Lassen Sie uns nun etwas ins Detail gehen und verstehen, wie sich kubectl apply und create bei der Implementierung voneinander unterscheiden.
kubectl create:Imperative Verwaltung
kubectl create ist das, was wir imperatives Management nennen. Bei diesem Ansatz teilen Sie der Kubernetes-API mit, was Sie erstellen, ersetzen oder löschen möchten.
Einfacher ausgedrückt:create erstellt ein völlig neues Objekt (zuvor nicht vorhanden oder gelöscht).
kubectl apply:deklarative Verwaltung
kubectl apply ist Teil des deklarativen Verwaltungsansatzes, bei dem Änderungen, die Sie möglicherweise auf ein Live-Objekt angewendet haben (d. h. durch scale ) wird "gepflegt". " auch wenn Sie sich apply andere Änderungen am Objekt.
Einfacher ausgedrückt:apply - nimmt inkrementelle Änderungen an einem bestehenden Objekt vor, indem definiert wird, was wir brauchen.
HINWEIS: Sowohl der kubectl create- als auch der apply-Ansatz akzeptieren JSON- und YAML-Dateiformate.
Den Unterschied zwischen kubectl create und apply mit Beispiel verstehen
Ich werde die folgende YAML-Datei verwenden, um einen Kubernetes-Pod zu erstellen.
[email protected]:~/pod-create# cat mypod.yml
apiVersion: v1
kind: Pod
metadata:
name: create-vs-apply-demo
labels:
app: front-end
rel: dev
spec:
containers:
- name: httpd
image: docker.io/httpd
imagePullPolicy: IfNotPresent
ports:
- containerPort: 80
Lassen Sie uns den Pod auf imperative Weise erstellen, d. h. mit kubectl create Befehl:
[email protected]:~/pod-create# kubectl create -f mypod.yml
pod/create-vs-apply-demo created
Listen Sie den Pod-Status zusammen mit Labels auf:
[email protected]:~/pod-create# kubectl get pods --show-labels
NAME READY STATUS RESTARTS AGE LABELS
create-vs-apply-demo 1/1 Running 0 8s app=front-end,rel=dev
Jetzt werde ich die YAML-Datei bearbeiten und ihr ein zusätzliches Label (demo:applyVscreate) hinzufügen.
[email protected]:~/pod-create# cat mypod.yml
apiVersion: v1
kind: Pod
metadata:
name: create-vs-apply-demo
labels:
app: front-end
rel: dev
demo: applyVscreate
spec:
containers:
- name: httpd
image: docker.io/httpd
imagePullPolicy: IfNotPresent
ports:
- containerPort: 80
Lassen Sie uns nun wieder den imperativen Ansatz verwenden, um die Änderungen anzuwenden.
[email protected]:~/pod-create# kubectl create -f mypod.yml
Error from server (AlreadyExists): error when creating "mypod.yml": pods "create-vs-apply-demo" already exists
Es wirft einen Fehler und sagt, dass die Ressource bereits existiert.
Lassen Sie uns nun dieselbe Operation mit einem deklarativen Ansatz ausführen, d. h. kubectl apply Befehl.
[email protected]:~/pod-create# kubectl apply -f mypod.yml
pod/create-vs-apply-demo configured
Die Ressource wurde also dieses Mal konfiguriert. Überprüfen Sie die vorgenommenen Änderungen.
[email protected]:~/pod-create# kubectl get pods --show-labels
NAME READY STATUS RESTARTS AGE LABELS
create-vs-apply-demo 1/1 Running 0 3m19s app=front-end,demo=applyVscreate,rel=dev
Sie können sehen, dass das neue Label auf den Pod angewendet wurde.
Ich glaube, Sie sollten jetzt ein klares Verständnis der beiden Ansätze haben.
Kubectl erstellen oder anwenden? Welches soll ich verwenden?
Es hängt vom Anwendungsfall ab, wie Sie diese Konzepte oder Methoden verwenden möchten. Es geht nicht darum, was gut oder schlecht ist.
Wenn Sie Versionskontrolle wünschen das k8s-Objekt, dann ist es besser, declarative zu verwenden Weise (kubectl apply), die dabei hilft, die Genauigkeit von Daten in k8s-Objekten zu bestimmen.
Und wenn Sie nur eine Ressource zur Fehlerbehebung, zum Lernen oder zum interaktiven Experimentieren erstellen möchten gehe mit Imperativ Ansatz (kubectl create).
Immer noch verwirrt? Hinterlassen Sie einen Kommentar und ich werde versuchen, Ihre Zweifel zu beantworten.
Rakesh Jain
DevOps-Profi | RCA | Jenkins | Git | Docker | Kubernetes | Ansible | Prometheus | Grafana | AWS-Cloud