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