I pod vengono creati dalle risorse dei carichi di lavoro, denominate controller, che gestiscono l'implementazione, la replica e lo stato dei pod nel cluster. Ad esempio, se un nodo nel cluster incorre in un guasto, un controller rileva che i pod su quel nodo non rispondono e crea pod sostitutivi sugli altri nodi.

I tre tipi più comuni di controller sono:

• Jobs per i processi di tipo batch effimeri che eseguono un'attività fino al completamento
• Deployments per applicazioni stateless e persistenti, come i server web (server HTTP)
• StatefulSets per le applicazioni stateful e persistenti, come i database

Se un pod ha più container, questi sono tutti pianificati insieme sullo stesso server del cluster, che si tratti di una VM o di un server fisico. Tutti i container nel pod condividono le risorse e le dipendenze e possono coordinare l'esecuzione e l'interruzione. Ad esempio, i pod possono contenere container "init" che vengono eseguiti prima dei container delle applicazioni, configurando l'ambiente per le applicazioni successive.

I pod sono quasi sempre creati da controller che possono gestirne automaticamente il ciclo di vita, incluse la sostituzione dei pod guasti, la replica dei pod in caso di necessità e l'eliminazione del pod dai nodi del cluster quando sono completi o non più necessari.

I controller utilizzano le informazioni in un modello specifico per creare i pod e si assicurano che i pod in esecuzione corrispondano al deployment definito nel template di pod, ad esempio creando repliche che corrispondano al numero definito nel deployment.

Al momento della creazione, al pod viene assegnato un indirizzo IP univoco. Se sono presenti più container all'interno del pod, possono comunicare tra loro utilizzando semplicemente localhost. Le comunicazioni all'esterno del pod vengono stabilite tramite l'esposizione di una porta. Le comunicazioni tra i pod in un cluster sfruttano il fatto che Kubernetes assegna un indirizzo IP privato del cluster a ogni pod in un cluster, eliminando la necessità di creare collegamenti espliciti tra i pod o di mappare le porte dei container alle porte dell'host. In questo modo, i pod in un cluster possono "vedersi" reciprocamente senza bisogno di NAT.

Kubectl fornisce una serie di comandi che consentono a un utente di creare pod, eseguirli utilizzando i deployment, controllare lo stato dei pod in esecuzione e arrestare i pod che non sono più necessari. I comandi JSON (JavaScript Object Notation) o YAML (YAML Ain't Markup Language) sono validi per la codifica dei comandi.

Di seguito sono elencati i comandi kubectl più utilizzati:

Get

Il comando kubectl get visualizza informazioni tabulari su una o più risorse. Le informazioni possono essere filtrate tramite selettori di etichette e possono essere visualizzate solo per lo spazio dei nomi esistente o per tutti gli spazi dei nomi nel cluster.
Il comando "kubectl api-resources" genera un elenco di tutte le risorse supportate sulle quali è possibile ottenere informazioni. Il formato generale del comando kubectl get è:

$ kubectl get [(-o|--output=)json|yaml|wide|custom-columns=...|custom-columns-file=...|go-template=...|go-template-file=...|jsonpath=...|jsonpath-file=...] (TYPE[.VERSION][.GROUP] [NAME | -l etichetta] | TYPE[.VERSION][.GROUP]/NAME ...) [flag]

Create

I pod vengono creati utilizzando il comando create nel formato:

$ kubectl create -f NOMEFILE.

Ad esempio, il comando:

kubectl create -f ./mypod.yaml crea un nuovo pod dal file YAML "mypod"

Delete

Il comando "kubectl delete -f ./mypod.yaml" cancella il pod "mypod" dal cluster. L'eliminazione dei pod è un processo graduale. I pod continuano a essere eseguiti per un periodo di tolleranza (il valore predefinito è 30 secondi) prima di essere terminati in modo forzato. Se necessario, il valore del periodo di tolleranza può essere sovrascritto con il flag -grace-period.