kubectl apply e kubectl create entrambi sono due approcci diversi per creare risorse nell'ambiente del cluster Kubernetes.
Entrambi creano risorse da un file o da STDIN.
kubectl applica e crea:due approcci per la creazione di risorse
Ora entriamo nei dettagli e comprendiamo in che modo kubectl applica e crea differiscono l'uno dall'altro durante l'implementazione.
kubectl create:gestione imperativa
kubectl create è ciò che chiamiamo gestione imperativa. Con questo approccio dici all'API Kubernetes cosa vuoi creare, sostituire o eliminare.
In parole più semplici, create crea un oggetto completamente nuovo (precedentemente non esistente o eliminato).
kubectl apply:gestione dichiarativa
kubectl apply fa parte dell'approccio di gestione dichiarativa, in cui le modifiche che potresti aver applicato a un oggetto live (ad esempio tramite scale ) sarà "mantenuto " anche se apply altre modifiche all'oggetto.
In parole più semplici, apply - apporta modifiche incrementali a un oggetto esistente definendo ciò di cui abbiamo bisogno.
NOTA: Sia kubectl create che applica approcci accettano formati di file JSON e YAML.
Capire la differenza tra kubectl create e apply con esempio
Userò il file YAML sottostante per creare un pod Kubernetes.
[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
Creiamo il Pod in modo imperativo, ovvero usando kubectl create comando:
[email protected]:~/pod-create# kubectl create -f mypod.yml
pod/create-vs-apply-demo created
Elenca lo stato del pod insieme alle etichette:
[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
Ora modificherò il file YAML e aggiungerò un'etichetta aggiuntiva (demo:applyVscreate).
[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
Ora utilizziamo di nuovo l'approccio imperativo per applicare le modifiche.
[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
Genera un errore e dice che la risorsa esiste già.
Ora eseguiamo la stessa operazione usando un approccio dichiarativo, ovvero kubectl apply comando.
[email protected]:~/pod-create# kubectl apply -f mypod.yml
pod/create-vs-apply-demo configured
Quindi, questa volta la risorsa è stata configurata. Verifica le modifiche apportate.
[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
Puoi vedere che la nuova etichetta è stata applicata al pod.
Credo che ora dovresti avere una chiara comprensione dei due approcci.
Kubectl creare o applicare? Quale usare?
Dipende dal caso d'uso come si desidera utilizzare questi concetti o metodologia. Non si tratta di cosa è buono o cosa è cattivo.
Se desideri controllo della versione l'oggetto k8s allora è meglio usare dichiarativo way (kubectl si applica) che aiuta a determinare l'accuratezza dei dati negli oggetti k8s.
E se vuoi semplicemente creare qualche risorsa per risoluzione dei problemi, apprendimento o scopo di sperimentazione interattiva vai con imperativo approccio (kubectl create).
Ancora confuso? Lascia un commento e cercherò di rispondere ai tuoi dubbi.
Rakesh Jain
DevOps professionale | RHCA | Jenkins | Git | Docker | Kubernetes | Abile | Prometeo | Grafana | AWS Cloud