Le policy di pull dell'immagine Kubernetes controllano quando Kubelet deve recuperare una versione dell'immagine aggiornata. I criteri pull vengono utilizzati all'avvio di un nuovo pod. Kubelet intraprenderà l'azione appropriata indicata dalla politica del Pod.
Il comportamento predefinito
Non devi specificare una politica di pull dell'immagine. Quando un pod non ha una politica, Kubernetes dedurrà le tue intenzioni dal tag dell'immagine. Se hai fornito un tag specifico (come my-image:my-release), l'immagine verrà estratta solo se il tag non esiste già sul nodo Kubelet. Questa politica si chiama IfNotPresent.
Quando non viene specificato alcun tag o stai utilizzando il tag più recente, l'immagine verrà sempre estratta. Kubernetes recupererà il manifest dell'immagine ogni volta che viene avviato un nuovo Pod. Se il manifest indica una modifica, l'immagine aggiornata verrà estratta prima della creazione dei contenitori.
Kubernetes non modificherà mai imagePullPolicy come conseguenza di un'altra azione. La modifica dell'immagine di un pod non attiverà Kubernetes per rivalutare la policy di pull predefinita. Ciò significa che se inizi con my-image:latest ma in seguito aggiorni il Pod a my-image:my-release, la politica di pull dell'immagine sarà ancora IfNotPresent. Se lo desideri, devi specificare manualmente una nuova politica.
Rendere Kubelet sempre pull
Devi applicare un criterio di pull dell'immagine per costringere Kubelet a tentare sempre un pull. Imposta imagePullPolicy: Always on a Pod per abilitare questo comportamento.
specifica: container: – name: my-container image: my-image:my-release imagePullPolicy: Always
Le nuove versioni dell'immagine verranno estratte ogni volta che si avvia un Pod e il digest del manifest dell'immagine viene modificato. Una versione dell'immagine memorizzata nella cache locale verrà comunque riutilizzata se il digest non è cambiato. Ciò evita download non necessari sulla rete. I digest Docker sono riferimenti immutabili che identificano in modo univoco le immagini senza nome o tag.
I pull forzati sono utili quando si desidera distribuire nuove versioni della propria immagine utilizzando lo stesso tag. Questo potrebbe essere il caso quando tagghi le immagini utilizzando il nome del ramo da cui sono state create. Senza la policy Always, Kubernetes non ricaverebbe mai le tue nuove release di immagini se il tag fosse già disponibile localmente.
Blocco dei pull automatici
Tutte le policy che consentono i pull di immagini recupereranno nuove versioni dei tag memorizzati nella cache locale. Usa un digest di immagini come campo immagine del tuo Pod se vuoi che un contenitore contenga una versione esatta dell'immagine ogni volta che viene avviato.
Ci sono scenari in cui potresti non volere che Kubernetes estragga affatto le immagini. L'impostazione del criterio Mai impedirà i pull automatici di Kubelet. Questa norma non verifica affatto la presenza di aggiornamenti – la versione del manifest del registro non verrà recuperata.
Se usi Never, avrai bisogno di un modo alternativo per ottenere immagini sui tuoi nodi. Ogni immagine dovrà esistere localmente prima di provare ad avviare i tuoi pod. In caso contrario, Kubernetes non sarà in grado di eseguire i contenitori del Pod.
Questo funge da meccanismo di protezione quando si utilizza un meccanismo di estrazione dell'immagine autonomo. Non vorrai che Kubernetes tenti inavvertitamente un recupero automatico nel caso in cui un pull abbia esito negativo. Potrebbe portare alla perdita di immagini che sono già memorizzate nella cache locale.
Politiche di pull e memorizzazione nella cache
La policy di pull selezionata non dovrebbe’ ;t ha un impatto significativo sulle prestazioni. Finché il tuo fornitore di immagini supporta la memorizzazione nella cache dei livelli, Kubelet dovrà solo estrarre i nuovi livelli in ogni immagine.
Il criterio Sempre aggiunge una chiamata di rete ogni volta che avvii un nuovo Pod. Ha solo bisogno di controllare il digest dell'immagine, quindi questo dovrebbe essere praticamente istantaneo. Se il digest non corrisponde alla versione memorizzata nella cache locale, i nuovi livelli dell'immagine verranno estratti dal registro. L'overhead più significativo delle prestazioni è l'effettivo trasferimento di rete di quei livelli, seguito dalla loro successiva decompressione.
Riepilogo
Kubernetes supporta diversi modelli di comportamento per i pull di immagini. Le immagini sono gestite da Kubelet e verranno recuperate ogni volta che si avvia un Pod. Il criterio predefinito estrarrà l'immagine se il tag non esiste già localmente. Se l'immagine non è contrassegnata o ha l'ultimo come tag, verrà invece utilizzata la politica Sempre.
L'impostazione di imagePullPolicy nelle specifiche del pod rende esplicita la politica selezionata. Questo aiuta tutti i contributori a comprendere il comportamento scelto, anche se non hanno familiarità con le impostazioni predefinite di Kubernetes. È particolarmente importante se utilizzi immagini più recenti o senza tag, in cui Kubernetes applica una gestione speciale che potrebbe creare confusione.
Ricorda che le policy di pull delle immagini sono sempre impostate per Pod per impostazione predefinita. Se desideri utilizzare un criterio per l'intero cluster, dovrai utilizzare uno strumento di convalida della configurazione per eseguire la scansione dei manifesti del pod. kube-score è uno strumento di analisi statica per i manifest di oggetti Kubernetes che include un controllo imagePullPolicy nel set di regole predefinito. Esegui kube-score score my-manifest.yaml come parte di una pipeline CI per impedire l'uso di manifest privi di criteri definiti.