Che cosa sono i pod di Ku­ber­ne­tes?

Un pod di Ku­ber­ne­tes può contenere uno o più container, stret­ta­men­te collegati fra loro, che con­di­vi­do­no le risorse. In questo modo fungono da ambiente coor­di­na­to per le ap­pli­ca­zio­ni.

Pod di Ku­ber­ne­tes

I pod sono le unità di di­stri­bu­zio­ne di base di Ku­ber­ne­tes che com­pren­do­no uno o più container in­ter­con­nes­si. Un pod condivide spazio di rete, memoria e altre risorse e rap­pre­sen­ta quindi un rag­grup­pa­men­to logico di container. I container all’interno di un pod di Ku­ber­ne­tes col­la­bo­ra­no stret­ta­men­te e possono co­mu­ni­ca­re tra loro.

Modello di pod a singolo container

Un pod a singolo container ha al suo interno un solo container. Questa struttura è uti­liz­za­ta spesso quando occorre eseguire un’ap­pli­ca­zio­ne o un mi­cro­ser­vi­zio in un ambiente isolato senza la necessità di con­di­vi­de­re le risorse e la rete con altri container. Un pod di questo tipo è la forma più semplice di­spo­ni­bi­le in Ku­ber­ne­tes e offre comunque vantaggi in termini di or­che­stra­zio­ne, sca­la­bi­li­tà e gestione.

Pod a più container

I pod che eseguono più container ospitano più di un container all’interno dello stesso pod. Questi container col­la­bo­ra­no e con­di­vi­do­no lo stesso spazio di rete e le stesse risorse. È uti­liz­za­to spesso nei casi in cui i container sono stret­ta­men­te collegati fra loro ed eseguono un’attività o una funzione comune. Ad esempio, è possibile eseguire un container prin­ci­pa­le per l’ap­pli­ca­zio­ne e un con­te­ni­to­re se­con­da­rio (sidecar) per la re­gi­stra­zio­ne o il mo­ni­to­rag­gio nello stesso pod di Ku­ber­ne­tes. Questa soluzione consente un coor­di­na­men­to e una co­mu­ni­ca­zio­ne più stretti tra i container, pur trat­tan­do­li come una singola entità all’interno del cluster Ku­ber­ne­tes.

Creazione di pod di Ku­ber­ne­tes

Per creare un pod di Ku­ber­ne­tes è ne­ces­sa­rio un file YAML con­te­nen­te la de­scri­zio­ne delle spe­ci­fi­che 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 Ku­ber­ne­tes

Ti con­si­glia­mo di uti­liz­za­re livelli di astra­zio­ne più elevati come di­stri­bu­zio­ni o Sta­te­ful­Set per gestire i pod in un ambiente di pro­du­zio­ne. Questi con­trol­ler hanno lo scopo di definire lo stato de­si­de­ra­to dell’ap­pli­ca­zio­ne e di garantire che cor­ri­spon­da allo stato effettivo. Inoltre, per­met­to­no di im­ple­men­ta­re la sca­la­bi­li­tà, ag­gior­na­men­ti graduali e il ri­pri­sti­no au­to­ma­ti­co dei pod.

Alla creazione di un pod, di­ret­ta­men­te da parte dell’am­mi­ni­stra­to­re o in­di­ret­ta­men­te per mezzo di un con­trol­ler, il nuovo pod viene pia­ni­fi­ca­to su un nodo specifico nel cluster. Il pod rimane su questo nodo assegnato finché non si verifica una delle seguenti con­di­zio­ni: la sua ese­cu­zio­ne viene in­ter­rot­ta, l’oggetto pod associato viene eliminato ma­nual­men­te, la mancanza di risorse o altri problemi ri­chie­do­no lo spo­sta­men­to del pod su un altro nodo oppure il nodo corrente non funziona. In questo caso, il pod viene riavviato su un altro nodo di­spo­ni­bi­le per garantire che l’ese­cu­zio­ne continui.

Il nome di un pod deve essere impostato come valore del sot­to­do­mi­nio DNS valido. Questa im­po­sta­zio­ne è im­por­tan­te affinché sia possibile iden­ti­fi­ca­re chia­ra­men­te il pod all’interno del cluster Ku­ber­ne­tes. Le etichette DNS devono avere meno di 253 caratteri, devono contenere solo caratteri al­fa­nu­me­ri­ci e trattini, devono iniziare e terminare con un carattere al­fa­nu­me­ri­co.

SO dei pod

Di solito i pod di Ku­ber­ne­tes sono con­fi­gu­ra­ti per girare su un sistema operativo Linux. Tuttavia, ci sono casi in cui è pre­fe­ri­bi­le eseguire un pod su un sistema operativo Windows, ad esempio se la tua ap­pli­ca­zio­ne o parte di essa ri­chie­do­no fun­zio­na­li­tà spe­ci­fi­che di Windows. Puoi cambiare il sistema operativo nel campo .spec.os.name delle spe­ci­fi­che del pod (file YAML).

Gestione dei pod

Sebbene sia possibile creare pod ma­nual­men­te, spesso non risulta pratico per via della crescente com­ples­si­tà delle ap­pli­ca­zio­ni e dei carichi di lavoro. I con­trol­ler di Ku­ber­ne­tes offrono un livello astratto basato sulla con­fi­gu­ra­zio­ne di­chia­ra­ti­va. Esistono diversi tipi di con­trol­ler:

• Di­stri­bu­zio­ne di Ku­ber­ne­tes
• Sta­te­ful­Set in Ku­ber­ne­tes
• DaemonSet in Ku­ber­ne­tes

I con­trol­ler di di­stri­bu­zio­ne mo­ni­to­ra­no con­ti­nua­men­te l’integrità del cluster. Ciò consente di ef­fet­tua­re azioni au­to­ma­tiz­za­te come il ri­di­men­sio­na­men­to, l’ag­gior­na­men­to e la ma­nu­ten­zio­ne delle ap­pli­ca­zio­ni. I Re­pli­ca­Set ga­ran­ti­sco­no che sia in ese­cu­zio­ne un numero costante di pod identici. I con­trol­ler Sta­te­ful­Set sono es­sen­zia­li per le ap­pli­ca­zio­ni che fanno un uso intenso di dati, in quanto ga­ran­ti­sco­no identità di rete stabili per i pod.

Modelli di pod

Un modello di pod è una parte della con­fi­gu­ra­zio­ne di un con­trol­ler che descrive le proprietà de­si­de­ra­te per un pod di Ku­ber­ne­tes. I modelli includono container, immagini Docker, variabili di ambiente, requisiti di risorse e altro ancora. Il con­trol­ler utilizza il modello di pod per con­fi­gu­ra­re o ag­gior­na­re i pod. Ad esempio, durante una di­stri­bu­zio­ne vengono creati nuovi pod quando è richiesto il loro ri­di­men­sio­na­men­to oppure vengono ag­gior­na­ti 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 con­fi­gu­ria­mo un job de­no­mi­na­to 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ò ef­fet­tua­re al massimo tre tentativi di ri­pe­ti­zio­ne se si verifica un errore.

Ag­gior­na­men­to dei pod di Ku­ber­ne­tes

In Ku­ber­ne­tes è possibile ag­gior­na­re le risorse in vari modi, tra cui i due metodi uti­liz­za­ti di solito, patch e replace.

Il metodo patch è usato per eseguire ag­gior­na­men­ti mirati e parziali su una risorsa senza so­sti­tui­re l’intera de­fi­ni­zio­ne della risorsa. A tal fine viene di­stri­bui­ta una patch che contiene solo i campi da mo­di­fi­ca­re. In questo modo è possibile ag­gior­na­re parti spe­ci­fi­che di una risorsa, mentre altre rimangono invariate. Questo metodo offre una soluzione ef­fi­cien­te per apportare modifiche minime a una risorsa, so­prat­tut­to quando è ne­ces­sa­rio ag­gior­na­re solo alcuni campi specifici.

Il metodo replace, invece, so­sti­tui­sce tutti i campi della risorsa con i campi cor­ri­spon­den­ti nella nuova de­fi­ni­zio­ne. Il metodo replace è uti­liz­za­to quando è ne­ces­sa­rio applicare un ag­gior­na­men­to im­por­tan­te o vengono apportate modifiche strut­tu­ra­li e fon­da­men­ta­li alla risorsa.

Alcuni metadati e campi nelle de­fi­ni­zio­ni YAML delle risorse Ku­ber­ne­tes sono im­mu­ta­bi­li. Questi sono:

• apiVersion e kind: questi metadati de­fi­ni­sco­no il tipo e la versione della risorsa e di solito non devono essere mo­di­fi­ca­ti.
• metadata.name e metadata.namespace: il nome e lo spazio dei nomi di una risorsa sono so­li­ta­men­te im­mu­ta­bi­li per garantire l’iden­ti­fi­ca­zio­ne univoca della risorsa.
• metadata.creationTimestamp: la data di creazione di una risorsa è im­mu­ta­bi­le e indica il momento in cui è stata creata la risorsa.

Con­di­vi­sio­ne di risorse

I pod possono uti­liz­za­re i volumi per con­di­vi­de­re 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 mec­ca­ni­smi efficaci per l’ar­chi­via­zio­ne di dati che si estendono oltre il ciclo di vita di un singolo container.

Ogni pod di Ku­ber­ne­tes ha il proprio indirizzo IP univoco all’interno della rete del cluster. Questo indirizzo IP consente la co­mu­ni­ca­zio­ne diretta tra i pod. Se più container sono in ese­cu­zio­ne all’interno di un pod, possono co­mu­ni­ca­re tra loro uti­liz­zan­do localhost e porte diverse. In questo modo si sem­pli­fi­ca l’in­te­ra­zio­ne tra le diverse parti di un’ap­pli­ca­zio­ne 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 nor­mal­men­te non sono di­spo­ni­bi­li in un normale container isolato. In Ku­ber­ne­tes, la modalità con privilegi si abilita im­po­stan­do l’opzione securityContext.privileged nelle spe­ci­fi­che del container.

È im­por­tan­te notare che l’utilizzo della modalità con privilegi comporta rischi si­gni­fi­ca­ti­vi per la sicurezza. Per via delle au­to­riz­za­zio­ni estese, un container com­pro­mes­so o un’ap­pli­ca­zio­ne dannosa po­treb­be­ro causare seri problemi di sicurezza sul sistema host. Pertanto, la modalità con privilegi deve essere uti­liz­za­ta solo quando è ne­ces­sa­ria e dopo aver con­si­de­ra­to at­ten­ta­men­te i po­ten­zia­li rischi per la sicurezza.

Pod statici

I pod statici in Ku­ber­ne­tes sono pod che non vengono mo­ni­to­ra­ti o gestiti dal livello di controllo centrale del cluster. A dif­fe­ren­za dei pod normali che dipendono dai con­trol­ler Ku­ber­ne­tes, i pod statici sono ini­zia­liz­za­ti di­ret­ta­men­te da un nodo. Questi pod sono legati a un nodo specifico e le loro de­fi­ni­zio­ni si trovano sul nodo stesso, di solito in una directory come /etc/kubernetes/manifests/. Kubelet sul nodo provvede al mo­ni­to­rag­gio e all’avvio del pod statico, riav­vian­do­si au­to­ma­ti­ca­men­te se il pod si blocca.

A dif­fe­ren­za dei pod normali, i pod statici non sono con­trol­la­ti dall’API Ku­ber­ne­tes e sono in­vi­si­bi­li al livello di controllo centrale del cluster. I pod statici sono una soluzione semplice per di­stri­bui­re ap­pli­ca­zio­ni o servizi su un nodo senza un cluster Ku­ber­ne­tes centrale. Non offrono però tutte le fun­zio­na­li­tà dei normali pod gestiti dal con­trol­ler manager di Ku­ber­ne­tes.

Sonde per container

Le sonde per container (“probe”) sono mec­ca­ni­smi di Ku­ber­ne­tes che mo­ni­to­ra­no lo stato e l’integrità di un container.

Kubelet può eseguire diverse azioni a scopo di diagnosi:

• Exe­cAc­tion (eseguita per mezzo del runtime del container): questa azione consente a kubelet di eseguire un comando all’interno del container. È par­ti­co­lar­men­te utile per eseguire controlli o test per­so­na­liz­za­ti all’interno del container. Se il comando è stato ri­chia­ma­to, il controllo della sonda è riuscito.
• TCP­Soc­ke­tAc­tion (con­trol­la­to di­ret­ta­men­te dal kubelet): questa azione permette al kubelet di ve­ri­fi­ca­re la rag­giun­gi­bi­li­tà di una data porta TCP all’interno del container. Se la porta spe­ci­fi­ca­ta è aperta, il controllo della sonda è riuscito.
• HTT­P­Ge­tAc­tion (con­trol­la­to di­ret­ta­men­te 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 è uti­liz­za­ta spesso per gli endpoint HTTP al fine di garantire che un’ap­pli­ca­zio­ne risponda cor­ret­ta­men­te alle richieste. Se la richiesta attiva un codice di stato 2xx, il controllo della sonda è riuscito.