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
The volume is resolved at pod startup depending on which `pullPolicy` value is
558
+
provided:
559
+
560
+
`Always`
561
+
: the kubelet always attempts to pull the reference. If the pull fails, the kubelet sets the Pod to `Failed`.
562
+
563
+
`Never`
564
+
: the kubelet never pulls the reference and only uses a local image or artifact. The Pod becomes `Failed` if any layers of the image aren't already present locally, or if the manifest for that image isn't already cached.
565
+
566
+
`IfNotPresent`
567
+
: the kubelet pulls if the reference isn't already present on disk. The Pod becomes `Failed` if the reference isn't present and the pull fails.
568
+
569
+
The volume gets re-resolved if the pod gets deleted and recreated, which means
570
+
that new remote content will become available on pod recreation. A failure to
571
+
resolve or pull the image during pod startup will block containers from starting
572
+
and may add significant latency. Failures will be retried using normal volume
573
+
backoff and will be reported on the pod reason and message.
574
+
575
+
The types of objects that may be mounted by this volume are defined by the
576
+
container runtime implementation on a host machine and at minimum must include
577
+
all valid types supported by the container image field. The OCI object gets
578
+
mounted in a single directory (`spec.containers[*].volumeMounts.mountPath`) by
579
+
will be mounted read-only. On Linux, the container runtime typically also mounts the
580
+
volume with file execution blocked (`noexec`).
581
+
582
+
Beside that:
583
+
- Sub path mounts for containers are not supported
584
+
(`spec.containers[*].volumeMounts.subpath`).
585
+
- The field `spec.securityContext.fsGroupChangePolicy` has no effect on this
586
+
volume type.
587
+
- The [`AlwaysPullImages` Admission Controller](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages)
588
+
does also work for this volume source like for container images.
589
+
590
+
The following fields are available for the `image` type:
591
+
592
+
`reference`
593
+
: Artifact reference to be used. For example, you could specify
594
+
`registry.k8s.io/conformance:v{{< skew currentPatchVersion >}}`to load the
595
+
files from the Kubernetes conformance test image. Behaves in the same way as
596
+
`pod.spec.containers[*].image`. Pull secrets will be assembled in the same way
597
+
as for the container image by looking up node credentials, service account image
598
+
pull secrets, and pod spec image pull secrets. This field is optional to allow
599
+
higher level config management to default or override container images in
600
+
workload controllers like Deployments and StatefulSets.
601
+
[More info about container images](/docs/concepts/containers/images)
602
+
603
+
`pullPolicy`
604
+
: Policy for pulling OCI objects. Possible values are: `Always`, `Never` or
605
+
`IfNotPresent`. Defaults to `Always` if `:latest` tag is specified, or
606
+
`IfNotPresent`otherwise.
607
+
608
+
See the [_Use an Image Volume With a Pod_](/docs/tasks/configure-pod-container/image-volumes)
609
+
example for more details on how to use the volume source.
610
+
546
611
### iscsi
547
612
548
613
An `iscsi` volume allows an existing iSCSI (SCSI over IP) volume to be mounted
0 commit comments