mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 21:46:22 +01:00
Merge pull request #102926 from openshift-cherrypick-robot/cherry-pick-102039-to-enterprise-4.21
[enterprise-4.21] OCSDOCS 17279 Remove references to artifacts from Mounting an OCI image into a pod docs
This commit is contained in:
Michael Burke
@@ -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_.
|
||||
|
||||
@@ -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 <file_name>.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.
|
||||
|
||||
@@ -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
|
||||
|
||||
Reference in New Issue
Block a user