Quello che ho capito dalla documentazione è che:

• kubectl create = Crea una nuova risorsa k8s nel cluster
• kubectl replace = Aggiorna una risorsa nel cluster live
• kubectl apply = Se voglio creare + sostituisci ( riferimento )

Le mie domande sono

1. Perché ci sono tre operazioni per svolgere la stessa attività in un cluster?
2. Quali sono i casi d'uso per queste operazioni?
3. In che modo differiscono l'uno dall'altro sotto il cofano?

Questi sono due approcci diversi:

Gestione imperativa

kubectl createè ciò che chiamiamo gestione imperativa . Con questo approccio dici all'API di Kubernetes come vuoi creare, sostituire o eliminare, non come vuoi che il tuo mondo di cluster K8 appaia.

Gestione dichiarativa

kubectl applyfa parte dell'approccio di gestione dichiarativa , in cui le modifiche che è possibile aver applicato a un oggetto live (ovvero attraverso scale) vengono " mantenute " anche se si applyapportano altre modifiche all'oggetto.

Puoi leggere di più sulla gestione imperativa e dichiarativa nella documentazione di Kubernetes Object Management .

Durante l'esecuzione in uno script CI, si avranno problemi con i comandi imperativi poiché la creazione genera un errore se la risorsa esiste già.

Quello che puoi fare è applicare (modello dichiarativo) l'output del tuo comando imperativo, usando --dry-run=truee le -o yamlopzioni:

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

Il comando sopra non genererà un errore se la risorsa esiste già (e aggiornerà la risorsa se necessario).

Ciò è molto utile in alcuni casi in cui non è possibile utilizzare il modello dichiarativo (ad esempio durante la creazione di un segreto del registro Docker).

Giusto per dare una risposta più diretta, dalla mia comprensione:

apply- apporta modifiche incrementali a un oggetto esistente
create- crea un oggetto completamente nuovo (precedentemente non esistente / cancellato)


Prendendolo da un articolo di DigitalOcean che era collegato dal sito Web di Kubernetes:

Usiamo apply invece di create qui in modo che in futuro possiamo applicare in modo incrementale le modifiche agli oggetti Ingress Controller invece di sovrascriverli completamente.

Questi sono comandi imperativi :

kubectl run = kubectl create deployment

vantaggi:

• Semplice, facile da imparare e facile da ricordare.
• Richiede solo un singolo passaggio per apportare modifiche al cluster.

svantaggi:

• Non integrare con i processi di revisione delle modifiche.
• Non fornire una pista di controllo associata alle modifiche.
• Non fornire una fonte di record ad eccezione di ciò che è live.
• Non fornire un modello per la creazione di nuovi oggetti.

Queste sono le configurazioni imperative degli oggetti :

kubectl create -f your-object-config.yaml

kubectl delete -f your-object-config.yaml

kubectl replace -f your-object-config.yaml

Vantaggi rispetto ai comandi imperativi:

• Può essere archiviato in un sistema di controllo del codice sorgente come Git.
• Può integrarsi con processi come la revisione delle modifiche prima di eseguire push e audit trail.
• Fornisce un modello per la creazione di nuovi oggetti.

Svantaggi rispetto ai comandi imperativi:

• Richiede una conoscenza di base dello schema degli oggetti.
• Richiede il passaggio aggiuntivo di scrittura di un file YAML.

Vantaggi rispetto alla configurazione dichiarativa degli oggetti:

• Più semplice e più facile da capire.
• Più maturo dopo Kubernetes versione 1.5.

Svantaggi rispetto alla configurazione dell'oggetto dichiarativo:

• Funziona meglio su file, non su directory.
• Gli aggiornamenti agli oggetti live devono essere riflessi nei file di configurazione, altrimenti andranno persi durante la successiva sostituzione.

Si tratta di una configurazione di oggetti dichiarativa

kubectl diff -f configs/

kubectl apply -f configs/

Vantaggi rispetto alla configurazione degli oggetti imperativi:

• Le modifiche apportate direttamente agli oggetti live vengono mantenute, anche se non vengono riunite nuovamente nei file di configurazione.
• Migliore supporto per operare su directory e rilevare automaticamente i tipi di operazione (creazione, patch, cancellazione) per oggetto.

Svantaggi rispetto alla configurazione dell'oggetto imperativo:

• Difficile eseguire il debug e comprendere i risultati quando sono inattesi.
• Gli aggiornamenti parziali che utilizzano i diff creano complesse operazioni di unione e patch.

La spiegazione che segue della documentazione ufficiale mi ha aiutato a capire kubectl apply.

Questo comando confronterà la versione della configurazione che stai inviando con la versione precedente e applicherà le modifiche apportate, senza sovrascrivere eventuali modifiche automatizzate alle proprietà che non hai specificato.

kubectl create d'altra parte creerà (dovrebbe essere inesistente) risorse.

kubectl create può funzionare con un file di configurazione oggetto alla volta. Questo è anche noto come gestione imperativa

kubectl create -f nomefile | url

kubectl apply funziona con le directory e le sue sottodirectory contenenti file yaml di configurazione degli oggetti. Questo è anche noto come gestione dichiarativa. È possibile prelevare più file di configurazione degli oggetti dalle directory. kubectl applicare -f directory /

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

Adoriamo Kubernetes perché una volta che diamo loro ciò che vogliamo, continua a capire come raggiungerlo senza il nostro coinvolgimento.

"creare" è come giocare a DIO prendendo le cose nelle nostre mani. È utile per il debug locale quando si desidera solo lavorare con il POD e non preoccuparsi del controller di distribuzione / replica.

"applica" sta giocando secondo le regole. "applica" è come uno strumento principale che ti aiuta a creare e modificare e non richiede nulla da te per gestire i pod.