2.0 KiB
assignees | title | ||
---|---|---|---|
|
Using Projected volumes |
The projected volume is a volume that projects several existing volume sources into the same directory. Currently, one can project configmaps, downward API, and secrets. The resulting pod spec is also shorter when projecting to a single volume as opposed to multiple different locations. See all-in-one volume design document for more information.
- TOC {:toc}
Overview of a projected volume
The projected volume encapsulates multiple volumes to be projected, with each volume source respecting nearly the same parameters as supported by each individual type. Consider the following example:
apiVersion: v1
kind: Pod
metadata:
name: volume-test
spec:
containers:
- name: container-test
image: busybox
volumeMounts:
- name: all-in-one
mountPath: "/projected-volume"
readOnly: true
volumes:
- name: all-in-one
projected:
sources:
- secret:
name: mysecret
items:
- key: username
path: my-group/my-username
- secret:
name: mysecret2
items:
- key: password
path: my-group/my-password
mode: 511
Each volume source is listed in the spec under sources
. As stated above the
parameters are nearly the same with two exceptions:
- For secrets, the
secretName
field has been changed toname
to be consistent with config maps naming. - The
defaultMode
can only be specified at the projected level and not for each volume source. However, as illustrated above, you can explicitly set themode
for each individual projection.
Creating projections
A projected volume is created by passing in the pod spec to kubectl as normally done to create a new pod:
kubectl create -f podspec.yaml
Restrictions
Both secrets and config maps are required to be in the same namespace as the pod.