Pod

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

In questa pagina viene descritto l'oggetto Kubernetes' pod e il suo utilizzo in Google Kubernetes Engine.

Cos'è un pod?

I pod sono gli oggetti più piccoli e basilari di cui è possibile eseguire il deployment in Kubernetes. Un pod rappresenta una singola istanza di un processo in esecuzione nel cluster.

I pod contengono uno o più container, come container Docker. Quando un pod esegue più container, questi vengono gestiti come un'unica entità e condividono le risorse del pod. In genere, l'esecuzione di più container in un unico pod è un caso d'uso avanzato.

I pod contengono anche risorse di networking e archiviazione condivise per i loro container:

  • Rete: ai pod vengono assegnati automaticamente indirizzi IP univoci. I container pod condividono lo stesso spazio dei nomi di rete, tra cui indirizzo IP e porte di rete. I container all'interno di un pod comunicano tra loro all'interno del pod su localhost.
  • Archiviazione: i pod possono specificare un insieme di volumi di archiviazione condivisibili tra i container.

Puoi considerare un pod un "host logico" isolato e indipendente, che contiene le esigenze sistemiche dell'applicazione che gestisce.

un pod è inteso a eseguire una singola istanza dell'applicazione sul cluster. Tuttavia, non è consigliabile creare direttamente singoli pod. In genere, invece, crei un insieme di pod identici, chiamati repliche, per eseguire la tua applicazione. Questo insieme di pod replicati viene creato e gestito da un controller, ad esempio un deployment. I controller gestiscono il ciclo di vita dei loro pod e possono eseguire la scalabilità orizzontale, modificandone il numero in base alle necessità.

Occasionalmente potresti interagire con i pod direttamente per eseguirne il debug, per la risoluzione dei problemi o per ispezionarli, ma ti consigliamo vivamente di utilizzare un controller per gestire i pod.

I pod vengono eseguiti su nodi nel cluster. Una volta creato, un pod rimane sul nodo finché il processo non è completato, il pod viene eliminato, il pod viene espulso dal nodo a causa della mancanza di risorse o il nodo si arresta. Se un nodo si guasta, i pod sul nodo vengono pianificati automaticamente per l'eliminazione.

Ciclo di vita del pod

i pod sono temporanei. Non sono progettati per essere eseguiti per sempre e quando un pod viene terminato, non può essere ripristinato. In generale, i pod non scompaiono finché non vengono eliminati da un utente o da un controller.

i pod non "riparano" né riparano da soli. Ad esempio, se un pod è pianificato su un nodo che in seguito ha esito negativo, viene eliminato. Allo stesso modo, se un pod viene rimosso da un nodo per qualsiasi motivo, non può sostituirsi.

Ogni pod ha un oggetto API PodStatus, rappresentato dal campo status di un pod. I pod pubblicano la loro fase nel campo status: phase. La fase di un pod è un riepilogo di alto livello del pod nello stato attuale.

Quando esegui kubectl get pod per ispezionare un pod in esecuzione sul cluster, il pod può trovarsi in una delle seguenti fasi possibili:

  • In attesa: il pod è stato creato e accettato dal cluster, ma uno o più dei suoi container non sono ancora in esecuzione. Questa fase include il tempo dedicato alla pianificazione su un nodo e il download delle immagini.
  • In esecuzione: il pod è stato associato a un nodo e tutti i container sono stati creati. Almeno un container è in esecuzione, in fase di avvio o di riavvio.
  • Operazione riuscita: tutti i container nel pod sono stati terminati correttamente. I pod terminati non si riavviano.
  • Operazione non riuscita: tutti i container nel pod sono stati interrotti e almeno un container ha terminato l'esecuzione. Un container "non riesce" se termina con uno stato diverso da zero.
  • Sconosciuto: non è possibile determinare lo stato del pod.

Inoltre, PodStatus contiene un array chiamato PodConditions, che è rappresentato nel manifest del pod come conditions. Il campo ha un campo type e un campo status. conditions indica con maggiore precisione le condizioni all'interno del pod che ne causano lo stato attuale.

Il campo type può contenere PodScheduled, Ready, Initialized e Unschedulable. Il campo status corrisponde al campo type e può contenere True, False o Unknown.

Crea i pod

Poiché i pod sono temporanei, non è necessario creare pod direttamente. Analogamente, poiché i pod non possono ripararsi o sostituirsi, non è consigliato creare pod direttamente.

Puoi invece utilizzare un controller, ad esempio un deployment, che crea e gestisce automaticamente i pod. I controller sono utili anche per implementare gli aggiornamenti, ad esempio per cambiare la versione di un'applicazione in esecuzione in un container, dato che il controller gestisce l'intero processo di aggiornamento per te.

Richieste di pod

Quando viene eseguito, un pod richiede una quantità di CPU e memoria. In questo modo, Kubernetes può pianificare il pod su un nodo appropriato per eseguire il carico di lavoro. Non verrà pianificato un pod su un nodo che non dispone delle risorse necessarie per soddisfare la richiesta del pod. Una richiesta è la quantità minima di CPU o memoria che Kubernetes garantisce a un pod.

Puoi configurare le richieste di CPU e memoria per un pod in base alle risorse necessarie per le tue applicazioni. Puoi anche specificare richieste per singoli container in esecuzione nel pod. Tieni presente che:

  • Non esiste una richiesta predefinita per la CPU. Un pod senza richiesta CPU predefinita può essere pianificato su un nodo senza CPU sufficienti per eseguire i carichi di lavoro del pod.
  • Non è presente una richiesta predefinita di memoria. Un pod senza richiesta di memoria predefinita potrebbe essere pianificato su un nodo senza memoria sufficiente per eseguire i carichi di lavoro del pod.
  • L'impostazione di un valore troppo piccolo per le richieste di CPU o memoria potrebbe causare la pianificazione di troppi pod o di una combinazione non ottimale di pod su un determinato nodo e ridurre le prestazioni.
  • Se imposti un valore troppo grande per le richieste di CPU o memoria, il pod potrebbe non essere pianificabile e aumentare i costi delle risorse del cluster.
  • Oltre o invece di impostare le risorse di un pod, puoi specificare risorse per singoli container in esecuzione nel pod. Se specifichi solo le risorse per i container, le richieste dei pod corrispondono alla somma delle richieste specificate per i container. Se specifichi entrambi, la somma delle richieste di tutti i container non deve superare le richieste dei pod.

Ti consigliamo vivamente di configurare le richieste per i pod, in base ai requisiti dei carichi di lavoro effettivi. Per ulteriori informazioni, consulta Best practice per Kubernetes: richieste e limiti delle risorse sul blog di Google Cloud.

Limiti dei pod

Per impostazione predefinita, un pod non ha un limite superiore sulla quantità massima di CPU o memoria che può utilizzare su un nodo. Puoi impostare limiti per controllare la quantità di CPU o memoria che il pod può utilizzare su un nodo. Un limite è la quantità massima di CPU o memoria che Kubernetes garantisce a un pod.

Oltre all'impostazione dei limiti di un pod, anziché impostarli, puoi specificare limiti per i singoli container in esecuzione nel pod. Se specifichi solo i limiti per i container, i limiti dei pod sono la somma dei limiti specificati per i container. Tuttavia, ogni container può accedere alle risorse solo fino al limite stabilito; pertanto, se scegli di specificare i limiti solo per i container, devi specificare dei limiti per ciascun container. Se specifichi entrambi, la somma dei limiti per tutti i container non deve superare il limite dei pod.

I limiti non vengono presi in considerazione durante la pianificazione dei pod, ma possono impedire la conflitto di risorse tra i pod sullo stesso nodo e impedire a un pod di causare l'instabilità del sistema sul nodo, causando la limitazione del sistema operativo sottostante.

Consigliamo vivamente di configurare i limiti dei pod, in base ai requisiti dei carichi di lavoro effettivi. Per ulteriori informazioni, consulta Best practice per Kubernetes: richieste e limiti delle risorse sul blog di Google Cloud.

Modelli di pod

Gli oggetti controller, come Deployment e StatefulSet, contengono un campo Modello pod. I modelli di pod contengono una specifica dei pod che determina la modalità di esecuzione di ogni pod, inclusi i container che devono essere eseguiti all'interno dei pod e i volumi che devono essere montati.

Gli oggetti controller utilizzano i modelli di pod per creare pod e gestire il loro "stato" desiderato all'interno del cluster. Quando un modello di pod viene modificato, tutti i pod futuri riflettono il nuovo modello, ma non tutti i pod esistenti.

Per ulteriori informazioni su come funzionano i modelli di pod, consulta la sezione relativa alla creazione di un deployment nella documentazione di Kubernetes.

Controllare su quali nodi viene eseguito un pod

Per impostazione predefinita, i pod vengono eseguiti su nodi nel pool di nodi predefinito per il cluster. Puoi configurare il pool di nodi che un pod seleziona in modo esplicito o implicito:

  • Puoi forzare esplicitamente il deployment di un pod in un pool di nodi specifico impostando un nodeSelector nel manifest del pod. Questo forza l'esecuzione di un pod solo sui nodi nel pool in questione.

  • Puoi specificare le richieste di risorse per i container che esegui. Il pod viene eseguito solo sui nodi che soddisfano le richieste di risorse. Ad esempio, se la definizione del pod include un container che richiede quattro CPU, il servizio non selezionerà i pod in esecuzione su nodi con due CPU.

Pattern di utilizzo dei pod

I pod possono essere utilizzati in due modi principali:

  • Pod che eseguono un singolo container. Il pattern pod più semplice e comune è un singolo container per pod, dove il singolo container rappresenta un'intera applicazione. In questo caso, puoi pensare a un pod come a un wrapper.
  • Pod che eseguono più container che devono funzionare insieme. I pod con più container vengono utilizzati principalmente per supportare programmi co-gestiti e gestiti che hanno bisogno di condividere risorse. Questi container collocati possono formare un'unica unità coerente di servizio, ovvero un container che pubblica file da un volume condiviso, mentre un altro container aggiorna o aggiorna i file. Il pod riunisce questi container e risorse di archiviazione come un'unica entità gestibile.

Ogni pod ha lo scopo di eseguire una singola istanza di una determinata applicazione. Se vuoi eseguire più istanze, devi utilizzare un pod per ogni istanza dell'applicazione. In genere, questa operazione viene chiamata replica. I pod replicati vengono creati e gestiti come gruppo da un controller, come un deployment.

Terminazione di pod

I pod terminano con esito positivo quando i loro processi sono completati. Kubernetes impone un periodo di tolleranza Gratuito predefinito di 30 secondi. Quando elimini un pod, puoi ignorare questo periodo di tolleranza impostando il flag --grace-period sul numero di secondi di attesa per terminare il pod prima di terminarlo forzatamente.

Se utilizzi il gestore della scalabilità automatica dei cluster, il periodo di tolleranza massimo per la risoluzione considerato durante gli eventi di scale down è di 10 minuti. Il periodo di tolleranza massimo per la terminazione durante gli upgrade dei nodi è di un'ora.

Passaggi successivi