Gestione degli oggetti Kubernetes dichiarativa e imperativa: CloudSavvy IT

Kubernetes è generalmente descritto come un sistema dichiarativo. La maggior parte delle volte lavori con YAML che definisce come dovrebbe essere lo stato finale del sistema. Kubernetes supporta anche le API imperative, in cui emetti un comando e ottieni un output immediato.

In questo articolo esploreremo le differenze tra queste due forme di gestione degli oggetti. È probabile che tu abbia usato entrambi in precedenza, anche se non riconosci i termini.

Dichiarativo vs imperativo: definizioni

È utile prima esaminare la terminologia.

qualcosa che è dichiarativo fa una dichiarazione del risultato finale, affermando l'intento ma non il processo per arrivarci. In Kubernetes questo significa "Dovrebbe esserci un ReplicaSet con tre Pod".

Una impératif agisce come un comando. Mentre un dichiarativo è passivo, gli imperativi sono attivi e immediati: "Crea un ReplicaSet con tre Pod".

L'ecosistema Kubernetes fornisce meccanismi per interagire con il tuo cluster in una di queste forme. Gli approcci imperativi sono supportati dai comandi CLI e dai singoli file YAML. La configurazione dichiarativa è facilitata dall'utilizzo di directory di file combinate nella rappresentazione finale delle risorse.

Gestisci gli oggetti in modo imperativo

Ecco un esempio di creazione di una distribuzione imperativa:

kubectl crea distribuzione my-deployment --image mia-immagine:latest

Indichi a Kubernetes di aggiungere immediatamente una nuova distribuzione al tuo cluster. Il comando include un singolo verbo (create) e il nome del tipo di risorsa con cui stai lavorando (deployment).

Puoi anche scrivere un file YAML e applicarlo usando l'estensione create ordinare:

apiVersione: app / v1
tipo: Distribuzione
spec:
  repliche: 3
  selettore:
    corrispondenzaEtichette:
      App: esempio
  modello:
    metadati:
      etichette:
        App: esempio
    spec:
        #...

kubectl crea -f deployment.yml

Come prima, dai un comando immediato tramite un verbo attivo. Kubernetes prenderà la configurazione dal tuo file e creerà le risorse corrispondenti nel cluster. Se devi aggiornare una risorsa, devi modificare il tuo YAML e utilizzare il file replace comando per apportare la modifica:

kubectl sostituisci -f deployment.yml

Questa operazione lo farà supprimer la specifica di tutte le risorse esistenti e sostituirla con la versione nel file di configurazione. Questo è trasmesso dal nome del replace ordinare. Ciò significa che perderai tutte le modifiche apportate ai tuoi oggetti attivi che non sono presenti nel tuo YAML.

Quando Kubernetes usa comandi imperativi, deve essere detto esattamente cosa fare. Pertanto, non c'è modo di applicare selettivamente solo le parti modificate del tuo YAML. Per questo, dovrai passare alle operazioni dichiarative.

Prova la gestione dichiarativa

La gestione dichiarativa è disponibile solo quando si utilizzano i file di configurazione YAML. Non esiste un comando dichiarativo. Quando usi operazioni dichiarative, non dici a Kubernetes cosa fare fornendo un verbo (create/replace). Invece, usi il singolo apply comandare e fidarsi di Kubernetes per determinare quali azioni eseguire.

Kubectl Applica -F Deployment.yml

Continuando l'esempio di distribuzione sopra, applicare il precedente YAML al tuo cluster inizialmente agirebbe come un imperativo create ordinare. All'inizio non esisterà alcuna risorsa corrispondente, quindi Kubernetes deve crearne una nuova.

Potresti quindi modificare il replicas campo a 5 e ripetilo apply ordinare. Questa volta, Kubernetes abbinerà la risorsa esistente, rileverà la modifica nel tuo YAML e ridimensionerà la distribuzione senza influire su altri campi.

Utilizzando l'approccio imperativo, è necessario utilizzare il kubectl scale per modificare il numero di repliche di una distribuzione esistente. Se hai modificato lo YAML con cui hai usato kubectl create, dovresti correre kubectl replace – ma ciò sostituirebbe l'intero schieramento spec, invece di ridimensionare semplicemente il numero di repliche.

Dichiarativo vs imperativo: confrontare i compromessi

Le operazioni imperative sono semplici da capire e ragionare. Ogni azione è espressa da un verbo con una conseguenza ben definita. Per questo motivo, la maggior parte delle persone inizierà le prime interazioni con Kubernetes utilizzando comandi imperativi che possono essere liberamente mappati ad altre tecnologie come Docker.

La gestione dichiarativa svela il vero potere di Kubernetes. Dichiari come dovrebbe essere lo stato finale, quindi lascia che Kubernetes faccia il resto. Ogni comando ha la stessa azione imperativa – apply questo insieme di file YAML e portare il cluster allo stato che definiscono.

La gestione dichiarativa è ideale per le distribuzioni automatizzate. Non è necessario dedicare tempo alla creazione di una serie di istruzioni per la migrazione ogni volta che si aggiorna una risorsa. Invece, regola il tuo YAML in modo che produca oggetti configurati correttamente se creati di nuovo al momento attuale. Kubernetes gestirà gli aggiornamenti agli oggetti esistenti in modo che corrispondano anche al nuovo stato.

I file YAML dichiarativi sono facili da revisionare, rivedere e unire sotto il tuo sistema di controllo del codice sorgente. Se utilizzi comandi imperativi, non hai modo di tenere traccia dell'avanzamento del tuo cluster e sarà più difficile tornare a uno stato precedente. A differenza delle operazioni imperative, gli aggiornamenti dichiarativi non sovrascrivono l'intero oggetto, quindi manterrai le modifiche apportate tramite altri meccanismi, indipendentemente dai tuoi file YAML.

Tuttavia, la gestione imperativa conserva alcuni vantaggi. La configurazione dichiarativa aggiunge livelli di complessità e può essere più difficile da eseguire il debug, soprattutto quando Kubernetes sceglie una linea d'azione inaspettata. Ogni modifica comporta un'operazione di unione e correzione per allineare gli oggetti allo stato desiderato. Con il modello imperativo, ciò che chiedi è ciò che ottieni, a meno che non si verifichi un errore.

Come sempre, quando vengono offerti due approcci, entrambe le strategie sono utili e quale scegliere dovrebbe dipendere dal contesto. Per i cluster di produzione che ospitano applicazioni live con modifiche frequenti, probabilmente vorrai file YAML dichiarativi con versione. Se stai avviando rapidamente nuovi contenitori in un cluster di sviluppo, i comandi imperativi ti faranno risparmiare tempo e saranno più facili da usare.

Conclusione

La gestione dichiarativa e imperativa sono due modi per interagire con il cluster Kubernetes e le relative risorse. Kubectl ha il supporto integrato per entrambe queste strategie, ma le tecniche non dovrebbero essere mescolate oggetto per oggetto. Se crei un oggetto in modo dichiarativo, dovrebbe essere gestito in questo modo per tutta la sua vita: l'utilizzo di comandi imperativi con esso può portare a comportamenti imprevisti.

Le operazioni imperative influiscono sugli oggetti attivi all'interno del tuo cluster. Definisci un verbo, una risorsa e una configurazione tramite argomenti e flag di comando. La gestione dichiarativa si basa sulle modifiche ai file di configurazione locali che Kubectl confronta e applica al cluster tramite patch quando si utilizza il kubectl diff et kubectl apply ordini.