diff --git a/modules/nodes-pods-image-volume-about.adoc b/modules/nodes-pods-image-volume-about.adoc index 56a06be843..f42b8eee76 100644 --- a/modules/nodes-pods-image-volume-about.adoc +++ b/modules/nodes-pods-image-volume-about.adoc @@ -6,7 +6,12 @@ [id="nodes-pods-image-volume-about_{context}"] = Understanding image volumes +// Hiding artifacts in 4.20; artifacts to go TP in 4.21 +//// You can you use an _image volume_ to mount an Open Container Initiative (OCI)-compliant container image or artifact directly into a pod, making the files within the image accessible to the containers without the need to include them in the base image. This means you can host the data in an OCI-compliant registry. +//// + +You can use an _image volume_ to mount an Open Container Initiative (OCI)-compliant container image directly into a pod, making the files within the image accessible to the containers without the need to include them in the base image. This means you can host the data in an OCI-compliant registry. By using an image volume in a pod, you can take advantage of the OCI image and distribution specification standards to accomplish several tasks including the following use cases: @@ -15,8 +20,14 @@ By using an image volume in a pod, you can take advantage of the OCI image and d * In an artificial intelligence environment, you can use image volumes to mount large language model weights or machine learning model weights in a pod alongside a model-server. You can efficiently serve model weights this way without including them in the model-server container image. Therefore, you can separate the model specifications and content from the executables that process them. -* You can package and distribute binary artifacts and mount them directly into your pods, allowing you to streamline your CI/CD pipeline. This allows you to maintain a small set of base images by attaching the CI/CD artifacts to the image volumes instead. - * You can use a public image for a malware scanner and mount it in a volume of private malware signatures, so that you can load those signatures without incorporating the image into a base image, which might not be allowed by the copyright on the public image. +//// +* You can package and distribute binary artifacts and mount them directly into your pods, allowing you to streamline your CI/CD pipeline. This allows you to maintain a small set of base images by attaching the CI/CD artifacts to the image volumes instead. +//// + +//// To mount an image volume, include a path to the image or artifact in your pod spec with an optional pull policy as described in _Adding an image volume to a pod_. +//// + +To mount an image volume, include a path to the image in your pod spec with an optional pull policy as described in _Adding an image volume to a pod_. diff --git a/modules/nodes-pods-image-volume-adding.adoc b/modules/nodes-pods-image-volume-adding.adoc index bf4c4a60e1..097ddca13d 100644 --- a/modules/nodes-pods-image-volume-adding.adoc +++ b/modules/nodes-pods-image-volume-adding.adoc @@ -6,7 +6,12 @@ [id="nodes-pods-image-volume-adding_{context}"] = Adding an image volume to a pod +//Hiding artifacts in 4.20; artifacts to go TP in 4.21 +//// To mount an Open Container Initiative (OCI)-compliant container image or artifact, use the `volume` parameter to include a path to the image or artifact in your pod spec with an optional pull policy. You can create the pod directly or use a controlling object, such as a deployment or replica set. +//// + +To mount an Open Container Initiative (OCI)-compliant container image, use the `volume` parameter to include a path to the image in your pod spec with an optional pull policy. You can create the pod directly or use a controlling object, such as a deployment or replica set. .Procedure @@ -29,18 +34,15 @@ spec: volumes: - name: volume image: <1> - reference: quay.io/crio/artifact:v2 <2> + reference: quay.io/crio/image:v2 <2> pullPolicy: Always <3> ---- -<1> Specifies an OCI container image or artifact that is available on the host machine. -<2> Specifies the path to the image or artifact. +<1> Specifies an OCI container image that is available on the host machine. +<2> Specifies the path to the image. <3> Specifies a pull policy, one of the following options: -+ --- * If `Always`, the kubelet always attempts to pull the image. If the pull fails, the kubelet sets the pod to `Failed`. -* If `Never`, the kubelet never pulls the image and only uses a local image or artifact. The pod becomes `Failed` if any layers of the image are not present locally, or if the manifest for that image is not already cached. -* If `IfNotPresent` the kubelet pulls the image if it not present. The pod becomes `Failed` if the image is not present and the pull fails. This is the default. --- +* If `Never`, the kubelet never pulls the image and only uses a local image. The pod becomes `Failed` if any layers of the image are not present locally, or if the manifest for that image is not already cached. +* If `IfNotPresent` the kubelet pulls the image if it is not present. The pod becomes `Failed` if the image is not present and the pull fails. This is the default. // Pull policy details from upstream: https://kubernetes.io/docs/concepts/storage/volumes/#image . Create the pod by running the following command: @@ -50,6 +52,41 @@ spec: $ oc create -f .yaml ---- +//// +. Create a YAML file similar to the following. ++ +[source,yaml] +---- +apiVersion: v1 +kind: Pod +metadata: + name: image-volume +spec: + containers: + - name: shell + command: ["sleep", "infinity"] + image: debian + volumeMounts: + - name: volume + mountPath: /volume + volumes: + - name: volume + image: <1> + reference: quay.io/crio/image:v2 <2> + pullPolicy: Always <3> +---- +<1> Specifies an OCI container image or artifact that is available on the host machine. +<2> Specifies the path to the image or artifact. +<3> Specifies a pull policy, one of the following options: +-- ++ +* If `Always`, the kubelet always attempts to pull the image. If the pull fails, the kubelet sets the pod to `Failed`. +* If `Never`, the kubelet never pulls the image and only uses a local image or artifact. The pod becomes `Failed` if any layers of the image are not present locally, or if the manifest for that image is not already cached. +* If `IfNotPresent` the kubelet pulls the image if it is not present. The pod becomes `Failed` if the image is not present and the pull fails. This is the default. +-- +// Pull policy details from upstream: https://kubernetes.io/docs/concepts/storage/volumes/#image +//// + .Verification * Examine the pod to view detailed information about the image pull and mount by using a command similar to the following: @@ -67,17 +104,17 @@ Namespace: default # ... Volumes: volume: <1> - Type: Image (a container image or OCI artifact) - Reference: quay.io/crio/artifact:v2 + Type: Image + Reference: quay.io/crio/image:v2 PullPolicy: IfNotPresent # ... Events: Type Reason Age From Message ---- ------ ---- ---- ------- # ... - Normal Pulling 46s kubelet Pulling image "quay.io/crio/artifact:v2" - Normal Pulled 44s kubelet Successfully pulled image "quay.io/crio/artifact:v2" in 2.261s (2.261s including waiting). Image size: 6707 bytes. <2> + Normal Pulling 46s kubelet Pulling image "quay.io/crio/image:v2" + Normal Pulled 44s kubelet Successfully pulled image "quay.io/crio/image:v2" in 2.261s (2.261s including waiting). Image size: 6707 bytes. <2> # ... ---- -<1> Indicates that the image volume was mounted to the pod. +<1> Indicates that the image was mounted to the pod. <2> Indicates that the image was successfully pulled. diff --git a/nodes/pods/nodes-pods-image-volume.adoc b/nodes/pods/nodes-pods-image-volume.adoc index b83f61da0c..64d02a5a86 100644 --- a/nodes/pods/nodes-pods-image-volume.adoc +++ b/nodes/pods/nodes-pods-image-volume.adoc @@ -6,8 +6,12 @@ include::_attributes/common-attributes.adoc[] toc::[] - +// Hiding artifacts in 4.20; artifacts to go TP in 4.21 +//// You can mount an Open Container Initiative (OCI)-compliant container image or artifact directly into a pod, making the files within the image accessible to the containers without the need to include them in the base image, which allows you to host the data in OCI-compliant registries. +//// + +You can mount an Open Container Initiative (OCI)-compliant container image directly into a pod, making the files within the image accessible to the containers without the need to include them in the base image, which allows you to host the data in OCI-compliant registries. // The following include statements pull in the module files that comprise // the assembly. Include any combination of concept, procedure, or reference