Ciao, e benvenuto nella quinta puntata della tredicesima stagione. Nella scorsa puntata abbiamo visto il cluster, l'insieme di macchine governate come una sola, con il suo cervello e le sue macchine lavoratrici. Oggi facciamo un passo più in basso e guardiamo cosa gira, concretamente, su quelle macchine. E qui c'è una sorpresa che spiazza chi arriva da Docker: Kubernetes non fa girare direttamente i container. Fa girare qualcosa che li avvolge, un'unità un po' più grande, con un nome curioso: il pod. Oggi capiamo cos'è e perché esiste.
Partiamo dalla sorpresa. Uno che ha imparato Docker si aspetterebbe che l'unità base di Kubernetes sia il container. E invece no: l'unità più piccola che Kubernetes gestisce e fa girare non è il container, ma il pod. Un pod è una specie di involucro, un contenitore di container, se mi passi il gioco di parole, che avvolge uno o più container e li tratta come un'unità unica e inseparabile. Quando Kubernetes colloca qualcosa su una macchina, non colloca un container: colloca un pod. Quando conta quante copie ci sono, non conta container: conta pod. Il pod è la moneta di base con cui Kubernetes ragiona.
La domanda naturale è: perché? Perché aggiungere questo involucro, invece di gestire direttamente i container? La risposta sta in un'esigenza reale. La maggior parte delle volte, in effetti, un pod contiene un solo container, e allora l'involucro sembra quasi superfluo. Ma a volte capita che due o più container siano così strettamente legati da dover vivere e morire insieme, sempre sulla stessa macchina, condividendo lo stesso ambiente ravvicinato, come due colleghi che devono per forza stare nella stessa stanza. Per questi casi serve un modo di dire a Kubernetes questi container sono un gruppo inseparabile, trattali come una cosa sola. Il pod è proprio questo: il modo di raggruppare container che devono stare insieme.
Vediamo cosa condividono i container dentro uno stesso pod, perché aiuta a capire quanto sono legati. I container di uno stesso pod vivono in un ambiente ravvicinato e condiviso: condividono lo stesso indirizzo di rete, come se fossero sullo stesso piccolo computer, e possono comunicare tra loro in modo diretto e immediato. Sono, in pratica, coinquilini strettissimi, che dividono lo stesso appartamento. Questa vicinanza serve per certi casi particolari, in cui un container principale ha bisogno di un piccolo container di supporto accanto a sé, che lo aiuti facendo un compito accessorio, e i due devono stare appiccicati. Il pod fornisce questa convivenza ravvicinata.
Detto questo, voglio darti subito la regola pratica che tiene semplice tutto, perché è facile complicarsi la vita qui. Nella grande maggioranza dei casi, un pod contiene un solo container, e va benissimo così: pod e container quasi coincidono, e puoi pensarli come quasi la stessa cosa. I casi in cui un pod contiene più container sono relativamente rari e specifici. Quindi, se all'inizio ti confonde, tieni questa semplificazione: normalmente un pod è semplicemente l'involucro di un container. La complessità del pod con più container esiste per i casi speciali, ma non è la norma quotidiana. Non lasciare che questo dettaglio ti spaventi.
C'è una caratteristica dei pod che è cruciale, e che riprende un tema che conosciamo bene dalla scorsa stagione: i pod sono usa e getta, effimeri. Proprio come i container di cui parlavamo con Docker, i pod nascono, vivono e muoiono con disinvoltura. Kubernetes li crea e li distrugge di continuo, per riparare i guasti, per scalare, per aggiornare, per ricollocare quando una macchina muore. Un pod non è qualcosa di permanente e stabile: è qualcosa di transitorio, che può sparire da un momento all'altro ed essere sostituito da uno nuovo. Devi pensare ai pod non come a creature durature, ma come a cose sacrificabili e continuamente rinnovate.
Questa natura effimera dei pod ha una conseguenza importante che prepara le puntate successive, quindi voglio piantarne il seme. Siccome i pod vanno e vengono di continuo, e ogni volta un pod nuovo prende il posto di uno vecchio, non puoi contare sul fatto che un pod specifico sia sempre lì, né che abbia sempre lo stesso indirizzo. Il pod che serve il tuo programma adesso potrebbe essere sostituito tra un minuto da un altro, con un indirizzo diverso. Questo crea un problema: se i pod sono così volatili e mutevoli, come fa qualcosa a raggiungerli in modo affidabile? Come punti a un bersaglio che si sposta di continuo? È un problema serio, che Kubernetes risolve con un'idea elegante di cui parleremo tra due puntate.
Per oggi ci fermiamo qui. L'unità base di Kubernetes non è il container, ma il pod: un involucro che avvolge uno o più container e li tratta come un'unità inseparabile. Serve per raggruppare container strettamente legati, che devono vivere insieme e condividere lo stesso ambiente ravvicinato, ma nella grande maggioranza dei casi un pod contiene un solo container. I pod, come i container, sono usa e getta ed effimeri: Kubernetes li crea e li distrugge di continuo. E questa loro volatilità crea un problema, quello di raggiungere bersagli mobili, che risolveremo più avanti. Nella prossima puntata vediamo come Kubernetes tiene tutto in piedi: l'assegnatore e l'autoriparazione. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.