You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: content/en/docs/concepts/configuration/overview.md
-26Lines changed: 0 additions & 26 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -73,32 +73,6 @@ A desired state of an object is described by a Deployment, and if changes to tha
73
73
74
74
- You can manipulate labels for debugging. Because Kubernetes controllers (such as ReplicaSet) and Services match to Pods using selector labels, removing the relevant labels from a Pod will stop it from being considered by a controller or from being served traffic by a Service. If you remove the labels of an existing Pod, its controller will create a new Pod to take its place. This is a useful way to debug a previously "live" Pod in a "quarantine" environment. To interactively remove or add labels, use [`kubectl label`](/docs/reference/generated/kubectl/kubectl-commands#label).
75
75
76
-
## Container Images
77
-
78
-
The [imagePullPolicy](/docs/concepts/containers/images/#updating-images) and the tag of the image affect when the [kubelet](/docs/reference/command-line-tools-reference/kubelet/) attempts to pull the specified image.
79
-
80
-
-`imagePullPolicy: IfNotPresent`: the image is pulled only if it is not already present locally.
81
-
82
-
-`imagePullPolicy: Always`: every time the kubelet launches a container, the kubelet queries the container image registry to resolve the name to an image digest. If the kubelet has a container image with that exact digest cached locally, the kubelet uses its cached image; otherwise, the kubelet downloads (pulls) the image with the resolved digest, and uses that image to launch the container.
83
-
84
-
-`imagePullPolicy` is omitted and either the image tag is `:latest` or it is omitted: `imagePullPolicy` is automatically set to `Always`. Note that this will _not_ be updated to `IfNotPresent` if the tag changes value.
85
-
86
-
-`imagePullPolicy` is omitted and the image tag is present but not `:latest`: `imagePullPolicy` is automatically set to `IfNotPresent`. Note that this will _not_ be updated to `Always` if the tag is later removed or changed to `:latest`.
87
-
88
-
-`imagePullPolicy: Never`: the image is assumed to exist locally. No attempt is made to pull the image.
89
-
90
-
{{< note >}}
91
-
To make sure the container always uses the same version of the image, you can specify its [digest](https://docs.docker.com/engine/reference/commandline/pull/#pull-an-image-by-digest-immutable-identifier); replace `<image-name>:<tag>` with `<image-name>@<digest>` (for example, `image@sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2`). The digest uniquely identifies a specific version of the image, so it is never updated by Kubernetes unless you change the digest value.
92
-
{{< /note >}}
93
-
94
-
{{< note >}}
95
-
You should avoid using the `:latest` tag when deploying containers in production as it is harder to track which version of the image is running and more difficult to roll back properly.
96
-
{{< /note >}}
97
-
98
-
{{< note >}}
99
-
The caching semantics of the underlying image provider make even `imagePullPolicy: Always` efficient, as long as the registry is reliably accessible. With Docker, for example, if the image already exists, the pull attempt is fast because all image layers are cached and no image download is needed.
100
-
{{< /note >}}
101
-
102
76
## Using kubectl
103
77
104
78
- Use `kubectl apply -f <directory>`. This looks for Kubernetes configuration in all `.yaml`, `.yml`, and `.json` files in `<directory>` and passes it to `apply`.
Copy file name to clipboardExpand all lines: content/en/docs/concepts/containers/images.md
+73-15Lines changed: 73 additions & 15 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -39,14 +39,6 @@ There are additional rules about where you can place the separator
39
39
characters (`_`, `-`, and `.`) inside an image tag.
40
40
If you don't specify a tag, Kubernetes assumes you mean the tag `latest`.
41
41
42
-
{{< caution >}}
43
-
You should avoid using the `latest` tag when deploying containers in production,
44
-
as it is harder to track which version of the image is running and more difficult
45
-
to roll back to a working version.
46
-
47
-
Instead, specify a meaningful tag such as `v1.42.0`.
48
-
{{< /caution >}}
49
-
50
42
## Updating images
51
43
52
44
When you first create a {{< glossary_tooltip text="Deployment" term_id="deployment" >}},
@@ -57,13 +49,68 @@ specified. This policy causes the
57
49
{{< glossary_tooltip text="kubelet" term_id="kubelet" >}} to skip pulling an
58
50
image if it already exists.
59
51
60
-
If you would like to always force a pull, you can do one of the following:
52
+
### Image pull policy
53
+
54
+
The `imagePullPolicy` for a container and the tag of the image affect when the
55
+
[kubelet](/docs/reference/command-line-tools-reference/kubelet/) attempts to pull (download) the specified image.
56
+
57
+
Here's a list of the values you can set for `imagePullPolicy` and the effects
58
+
these values have:
59
+
60
+
`IfNotPresent`
61
+
: the image is pulled only if it is not already present locally.
61
62
62
-
- set the `imagePullPolicy` of the container to `Always`.
63
-
- omit the `imagePullPolicy` and use `:latest` as the tag for the image to use;
64
-
Kubernetes will set the policy to `Always`.
65
-
- omit the `imagePullPolicy` and the tag for the image to use.
66
-
- enable the [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) admission controller.
63
+
`Always`
64
+
: every time the kubelet launches a container, the kubelet queries the container
65
+
image registry to resolve the name to an image
66
+
[digest](https://docs.docker.com/engine/reference/commandline/pull/#pull-an-image-by-digest-immutable-identifier). If the kubelet has a
67
+
container image with that exact digest cached locally, the kubelet uses its cached
68
+
image; otherwise, the kubelet pulls the image with the resolved digest,
69
+
and uses that image to launch the container.
70
+
71
+
`Never`
72
+
: the kubelet does not try fetching the image. If the image is somehow already present
73
+
locally, the kubelet attempts to start the container; otherwise, startup fails.
74
+
See [pre-pulled images](#pre-pulled-images) for more details.
75
+
76
+
The caching semantics of the underlying image provider make even
77
+
`imagePullPolicy: Always` efficient, as long as the registry is reliably accessible.
78
+
Your container runtime can notice that the image layers already exist on the node
79
+
so that they don't need to be downloaded again.
80
+
81
+
{{< note >}}
82
+
You should avoid using the `:latest` tag when deploying containers in production as
83
+
it is harder to track which version of the image is running and more difficult to
84
+
roll back properly.
85
+
86
+
Instead, specify a meaningful tag such as `v1.42.0`.
87
+
{{< /note >}}
88
+
89
+
To make sure the Pod always uses the same version of a container image, you can specify
90
+
the image's digest;
91
+
replace `<image-name>:<tag>` with `<image-name>@<digest>`
92
+
(for example, `image@sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2`).
93
+
94
+
When using image tags, if the image registry were to change the code that the tag on that image represents, you might end up with a mix of Pods running the old and new code. An image digest uniquely identifies a specific version of the image, so Kubernetes runs the same code every time it starts a container with that image name and digest specified. Specifying an image fixes the code that you run so that a change at the registry cannot lead to that mix of versions.
95
+
96
+
There are third-party [admission controllers](/docs/reference/access-authn-authz/admission-controllers/)
97
+
that mutate Pods (and pod templates) when they are created, so that the
98
+
running workload is defined based on an image digest rather than a tag.
99
+
That might be useful if you want to make sure that all your workload is
100
+
running the same code no matter what tag changes happen at the registry.
0 commit comments