Che cosa sono i pod di Kubernetes?

Un pod di Kubernetes può contenere uno o più container, strettamente collegati fra loro, che condividono le risorse. In questo modo fungono da ambiente coordinato per le applicazioni.

Pod di Kubernetes

I pod sono le unità di distribuzione di base di Kubernetes che comprendono uno o più container interconnessi. Un pod condivide spazio di rete, memoria e altre risorse e rappresenta quindi un raggruppamento logico di container. I container all’interno di un pod di Kubernetes collaborano strettamente e possono comunicare tra loro.

Modello di pod a singolo container

Un pod a singolo container ha al suo interno un solo container. Questa struttura è utilizzata spesso quando occorre eseguire un’applicazione o un microservizio in un ambiente isolato senza la necessità di condividere le risorse e la rete con altri container. Un pod di questo tipo è la forma più semplice disponibile in Kubernetes e offre comunque vantaggi in termini di orchestrazione, scalabilità e gestione.

Pod a più container

I pod che eseguono più container ospitano più di un container all’interno dello stesso pod. Questi container collaborano e condividono lo stesso spazio di rete e le stesse risorse. È utilizzato spesso nei casi in cui i container sono strettamente collegati fra loro ed eseguono un’attività o una funzione comune. Ad esempio, è possibile eseguire un container principale per l’applicazione e un contenitore secondario (sidecar) per la registrazione o il monitoraggio nello stesso pod di Kubernetes. Questa soluzione consente un coordinamento e una comunicazione più stretti tra i container, pur trattandoli come una singola entità all’interno del cluster Kubernetes.

Creazione di pod di Kubernetes

Per creare un pod di Kubernetes è necessario un file YAML contenente la descrizione delle specifiche del pod. Quello che segue è un semplice esempio per un pod Nginx:

apiVersion: v1
kind: Pod
metadata:
    name: nginx-pod
spec:
    containers:
    - name: nginx-container
        image: nginx:latest

Questo documento YAML definisce un pod di nome nginx-pod che contiene un singolo container di nome nginx-container. Il container utilizza l’immagine Nginx più recente presa da Docker Hub.

Digita il comando seguente per creare il pod:

kubectl apply -f nginx-pod.yaml

Utilizzo di pod di Kubernetes

Ti consigliamo di utilizzare livelli di astrazione più elevati come distribuzioni o StatefulSet per gestire i pod in un ambiente di produzione. Questi controller hanno lo scopo di definire lo stato desiderato dell’applicazione e di garantire che corrisponda allo stato effettivo. Inoltre, permettono di implementare la scalabilità, aggiornamenti graduali e il ripristino automatico dei pod.

Alla creazione di un pod, direttamente da parte dell’amministratore o indirettamente per mezzo di un controller, il nuovo pod viene pianificato su un nodo specifico nel cluster. Il pod rimane su questo nodo assegnato finché non si verifica una delle seguenti condizioni: la sua esecuzione viene interrotta, l’oggetto pod associato viene eliminato manualmente, la mancanza di risorse o altri problemi richiedono lo spostamento del pod su un altro nodo oppure il nodo corrente non funziona. In questo caso, il pod viene riavviato su un altro nodo disponibile per garantire che l’esecuzione continui.

Il nome di un pod deve essere impostato come valore del sottodominio DNS valido. Questa impostazione è importante affinché sia possibile identificare chiaramente il pod all’interno del cluster Kubernetes. Le etichette DNS devono avere meno di 253 caratteri, devono contenere solo caratteri alfanumerici e trattini, devono iniziare e terminare con un carattere alfanumerico.

SO dei pod

Di solito i pod di Kubernetes sono configurati per girare su un sistema operativo Linux. Tuttavia, ci sono casi in cui è preferibile eseguire un pod su un sistema operativo Windows, ad esempio se la tua applicazione o parte di essa richiedono funzionalità specifiche di Windows. Puoi cambiare il sistema operativo nel campo .spec.os.name delle specifiche del pod (file YAML).

Gestione dei pod

Sebbene sia possibile creare pod manualmente, spesso non risulta pratico per via della crescente complessità delle applicazioni e dei carichi di lavoro. I controller di Kubernetes offrono un livello astratto basato sulla configurazione dichiarativa. Esistono diversi tipi di controller:

• Distribuzione di Kubernetes
• StatefulSet in Kubernetes
• DaemonSet in Kubernetes

I controller di distribuzione monitorano continuamente l’integrità del cluster. Ciò consente di effettuare azioni automatizzate come il ridimensionamento, l’aggiornamento e la manutenzione delle applicazioni. I ReplicaSet garantiscono che sia in esecuzione un numero costante di pod identici. I controller StatefulSet sono essenziali per le applicazioni che fanno un uso intenso di dati, in quanto garantiscono identità di rete stabili per i pod.

Modelli di pod

Un modello di pod è una parte della configurazione di un controller che descrive le proprietà desiderate per un pod di Kubernetes. I modelli includono container, immagini Docker, variabili di ambiente, requisiti di risorse e altro ancora. Il controller utilizza il modello di pod per configurare o aggiornare i pod. Ad esempio, durante una distribuzione vengono creati nuovi pod quando è richiesto il loro ridimensionamento oppure vengono aggiornati i pod esistenti nel corso di un rolling update.

apiVersion: batch/v1
kind: Job
metadata:
    name: new-job
spec:
    template:
        metadata:
            name: pod
        spec:
            containers:
            - name: container
                image: ubuntu:latest
                command: ["echo", "Hello from Kubernetes"]
    backoffLimit: 3

In questo esempio configuriamo un job denominato new-job. Il modello di pod crea un singolo pod con un container che utilizza l’immagine Ubuntu ed esegue il comando echo "Hello from Kubernetes". A causa del backoffLimit impostato, il job può effettuare al massimo tre tentativi di ripetizione se si verifica un errore.

Aggiornamento dei pod di Kubernetes

In Kubernetes è possibile aggiornare le risorse in vari modi, tra cui i due metodi utilizzati di solito, patch e replace.

Il metodo patch è usato per eseguire aggiornamenti mirati e parziali su una risorsa senza sostituire l’intera definizione della risorsa. A tal fine viene distribuita una patch che contiene solo i campi da modificare. In questo modo è possibile aggiornare parti specifiche di una risorsa, mentre altre rimangono invariate. Questo metodo offre una soluzione efficiente per apportare modifiche minime a una risorsa, soprattutto quando è necessario aggiornare solo alcuni campi specifici.

Il metodo replace, invece, sostituisce tutti i campi della risorsa con i campi corrispondenti nella nuova definizione. Il metodo replace è utilizzato quando è necessario applicare un aggiornamento importante o vengono apportate modifiche strutturali e fondamentali alla risorsa.

Alcuni metadati e campi nelle definizioni YAML delle risorse Kubernetes sono immutabili. Questi sono:

• apiVersion e kind: questi metadati definiscono il tipo e la versione della risorsa e di solito non devono essere modificati.
• metadata.name e metadata.namespace: il nome e lo spazio dei nomi di una risorsa sono solitamente immutabili per garantire l’identificazione univoca della risorsa.
• metadata.creationTimestamp: la data di creazione di una risorsa è immutabile e indica il momento in cui è stata creata la risorsa.

Condivisione di risorse

I pod possono utilizzare i volumi per condividere dati tra container all’interno dello stesso pod. Un volume è un file system o una directory condivisi da uno o più container nel pod. I volumi sono meccanismi efficaci per l’archiviazione di dati che si estendono oltre il ciclo di vita di un singolo container.

Ogni pod di Kubernetes ha il proprio indirizzo IP univoco all’interno della rete del cluster. Questo indirizzo IP consente la comunicazione diretta tra i pod. Se più container sono in esecuzione all’interno di un pod, possono comunicare tra loro utilizzando localhost e porte diverse. In questo modo si semplifica l’interazione tra le diverse parti di un’applicazione nello stesso pod.

Modalità con privilegi

Se un container viene eseguito in modalità con privilegi, dispone di maggiori permessi e può accedere a risorse di sistema che normalmente non sono disponibili in un normale container isolato. In Kubernetes, la modalità con privilegi si abilita impostando l’opzione securityContext.privileged nelle specifiche del container.

È importante notare che l’utilizzo della modalità con privilegi comporta rischi significativi per la sicurezza. Per via delle autorizzazioni estese, un container compromesso o un’applicazione dannosa potrebbero causare seri problemi di sicurezza sul sistema host. Pertanto, la modalità con privilegi deve essere utilizzata solo quando è necessaria e dopo aver considerato attentamente i potenziali rischi per la sicurezza.

Pod statici

I pod statici in Kubernetes sono pod che non vengono monitorati o gestiti dal livello di controllo centrale del cluster. A differenza dei pod normali che dipendono dai controller Kubernetes, i pod statici sono inizializzati direttamente da un nodo. Questi pod sono legati a un nodo specifico e le loro definizioni si trovano sul nodo stesso, di solito in una directory come /etc/kubernetes/manifests/. Kubelet sul nodo provvede al monitoraggio e all’avvio del pod statico, riavviandosi automaticamente se il pod si blocca.

A differenza dei pod normali, i pod statici non sono controllati dall’API Kubernetes e sono invisibili al livello di controllo centrale del cluster. I pod statici sono una soluzione semplice per distribuire applicazioni o servizi su un nodo senza un cluster Kubernetes centrale. Non offrono però tutte le funzionalità dei normali pod gestiti dal controller manager di Kubernetes.

Sonde per container

Le sonde per container (“probe”) sono meccanismi di Kubernetes che monitorano lo stato e l’integrità di un container.

Kubelet può eseguire diverse azioni a scopo di diagnosi:

• ExecAction (eseguita per mezzo del runtime del container): questa azione consente a kubelet di eseguire un comando all’interno del container. È particolarmente utile per eseguire controlli o test personalizzati all’interno del container. Se il comando è stato richiamato, il controllo della sonda è riuscito.
• TCPSocketAction (controllato direttamente dal kubelet): questa azione permette al kubelet di verificare la raggiungibilità di una data porta TCP all’interno del container. Se la porta specificata è aperta, il controllo della sonda è riuscito.
• HTTPGetAction (controllato direttamente dal kubelet): con questa azione, il kubelet esegue una richiesta HTTP GET su un percorso e una porta specifici all’interno del container. Questa azione è utilizzata spesso per gli endpoint HTTP al fine di garantire che un’applicazione risponda correttamente alle richieste. Se la richiesta attiva un codice di stato 2xx, il controllo della sonda è riuscito.