Kubernetes Container Image Pull Concepts: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
 
(17 intermediate revisions by the same user not shown)
Line 11: Line 11:
=Pull Policy=
=Pull Policy=


The pull policy is configured on a per-container basis using the [[Kubernetes_Pod_Manifest#imagePullPolicy|imagePullPolicy]] tag in the pod manifest.
The pull policy is configured on a per-container basis using the [[Kubernetes_Pod_Manifest#imagePullPolicy|imagePullPolicy]] tag in the pod manifest. "imagePullPolicy" is configuration that tells the container runtime how to pull the container image prior to starting the container.  


There are three possible values: <code>Always</code>, <code>IfNotPresent</code> and <code>Never</code>. This attribute is optional, and if it is not specified, it is inferred based on the image tag. The default is <code>Always</code> if ":latest" tag is specified, or <code>IfNotPresent</code> otherwise.
There are three possible values: <code>Always</code>, <code>IfNotPresent</code> and <code>Never</code>. This attribute is optional, and if it is not specified, it is inferred based on the image tag. The default is <code>Always</code> if ":latest" tag is specified, or <code>IfNotPresent</code> otherwise. Note that if the attribute is explicitly set to "IfNotPresent" or "Never", it will be honored even if the image tag is ":latest".


The pull policy can be also enforced with the [[Kubernetes_Admission_Controller_Concepts#AlwaysPullImages|AlwaysPullImages admission controller]].
The pull policy can be also enforced with the [[Kubernetes_Admission_Controller_Concepts#AlwaysPullImages|AlwaysPullImages admission controller]].
Line 20: Line 20:
{{External|https://kubernetes.io/docs/concepts/containers/images/#using-a-private-registry}}
{{External|https://kubernetes.io/docs/concepts/containers/images/#using-a-private-registry}}
{{External|https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/}}
{{External|https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/}}
Conceptually, there could be several ways to configure access to private registries for pods:
There are several ways to configure access to private registries for pods:
* An entire node can be configured to authenticate to one or more private registry. If this option is used, all pods scheduled on that node can read any configured private registries. This method requires the involvement of the cluster administrator, who needs to configured the nodes, but isolates individual pods from registry configuration concerns. More details in [[#Node-Level_Configuration|Node-Level Configuration]].
* [[#Configure_Individual_Pods_with_Secrets|Configure individual pods with secrets]]
* Pods can be individually configured to authenticate to private registries, by specifying [[Kubernetes_Cluster_Configuration_Concepts#imagePullSecrets|imagePullSecrets]] on specific pods. Only the pods that provide suitable keys can access the private repository. More details in [[#Configure_imagePullSecrets|Configure imagePullSecrets]].
* [[#Node-Level_Configuration|Configure the entire node]]
 
* [[#Cluster-Level_Configuration|Configure the entire cluster]]
The images can also be pre-pulled on nodes, and all pods scheduled on the node can use the cached images. However, this requires root access to all nodes to setup.
* [[#Pre-pulled Images|Pull images in advance]]
 
==Configure Individual Pods with Secrets==
Pods can be individually configured to authenticate to private registries, by specifying <code>[[Kubernetes_Cluster_Configuration_Concepts#imagePullSecrets|imagePullSecrets]]</code> on specific pods. Only the pods that provide suitable keys can access the private repository. This approach involves creating and deploying dedicated secrets in the same namespace as the pod's and also modification of the pod manifests. More details in: {{Internal|Kubernetes_Cluster_Configuration_Concepts#imagePullSecrets|Kubernetes Configuration Concepts &#124; Secrets Required to Pull Images for Pods}}
==Node-Level Configuration==
==Node-Level Configuration==
{{External|https://kubernetes.io/docs/concepts/containers/images/#configuring-nodes-to-authenticate-to-a-private-registry}}
{{External|https://kubernetes.io/docs/concepts/containers/images/#configuring-nodes-to-authenticate-to-a-private-registry}}
 
An entire node can be configured to authenticate to one or more private registries. If this option is used, all pods scheduled on that node can read any configured private registries. This method requires the involvement of the cluster administrator, who needs to configured the nodes, but isolates individual pods from registry configuration concerns.
==Configure imagePullSecrets==
==Cluster-Level Configuration==
{{External|https://kubernetes.io/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod}}
The entire Kubernetes cluster can be integrated with the registry: {{Internal|Azure_Container_Registry_Concepts#Integrate_the_ACR_instance_with_the_AKS_Cluster|Azure Kubernetes Service (AKS) integration with Azure Container Registry (ACR)}}
 
==Pre-pulled Images==
==Pre-pulled Images==
{{External|https://kubernetes.io/docs/concepts/containers/images/#pre-pulled-images}}
{{External|https://kubernetes.io/docs/concepts/containers/images/#pre-pulled-images}}
The images can also be pre-pulled on nodes, and all pods scheduled on the node can use the cached images. However, this requires root access to all nodes to setup.

Latest revision as of 19:52, 28 June 2021

External

Internal

Overview

A pod's containers pull their images from their respective repositories while the pod is in Pending phase. Technically, it is the kubelet that performs the image pulling on behalf of the pod.

Pull Policy

The pull policy is configured on a per-container basis using the imagePullPolicy tag in the pod manifest. "imagePullPolicy" is configuration that tells the container runtime how to pull the container image prior to starting the container.

There are three possible values: Always, IfNotPresent and Never. This attribute is optional, and if it is not specified, it is inferred based on the image tag. The default is Always if ":latest" tag is specified, or IfNotPresent otherwise. Note that if the attribute is explicitly set to "IfNotPresent" or "Never", it will be honored even if the image tag is ":latest".

The pull policy can be also enforced with the AlwaysPullImages admission controller.

Private Registries

https://kubernetes.io/docs/concepts/containers/images/#using-a-private-registry
https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/

There are several ways to configure access to private registries for pods:

Configure Individual Pods with Secrets

Pods can be individually configured to authenticate to private registries, by specifying imagePullSecrets on specific pods. Only the pods that provide suitable keys can access the private repository. This approach involves creating and deploying dedicated secrets in the same namespace as the pod's and also modification of the pod manifests. More details in:

Kubernetes Configuration Concepts | Secrets Required to Pull Images for Pods

Node-Level Configuration

https://kubernetes.io/docs/concepts/containers/images/#configuring-nodes-to-authenticate-to-a-private-registry

An entire node can be configured to authenticate to one or more private registries. If this option is used, all pods scheduled on that node can read any configured private registries. This method requires the involvement of the cluster administrator, who needs to configured the nodes, but isolates individual pods from registry configuration concerns.

Cluster-Level Configuration

The entire Kubernetes cluster can be integrated with the registry:

Azure Kubernetes Service (AKS) integration with Azure Container Registry (ACR)

Pre-pulled Images

https://kubernetes.io/docs/concepts/containers/images/#pre-pulled-images

The images can also be pre-pulled on nodes, and all pods scheduled on the node can use the cached images. However, this requires root access to all nodes to setup.