A projected volume combines data from multiple sources into one volume mounted in a container. It can collect entries from ConfigMaps, Secrets, the Downward API, and a Pod’s ServiceAccount token, keeping related configuration and metadata in one directory. section 9.5.6 section 9.1.2
Use it when separate configMap and secret volumes would otherwise require different mount directories. The subPath technique can combine individual files, but it prevents those files from being updated when their source values change. section 9.5.6
Combining Envoy configuration and TLS files
A Pod can replace separate configMap and secret volumes with one projected volume mounted at /etc/envoy. The ConfigMap contributes envoy.yaml, while the Secret contributes example-com.crt and example-com.key under /etc/envoy/certs; the private key uses mode 0600. Listing the directory shows all three files together. section 9.5.6
Listing 9.15 Using a projected volume instead of a configMap and secret volume
apiVersion: v1
kind: Pod
metadata:
name: kiada-ssl
spec:
...
volumes:
- name: etc-envoy #1
projected: #1
sources: #1
- configMap: #2
name: kiada-ssl-config #2
items: #2
- key: envoy.yaml #2
path: envoy.yaml #2
- secret: #3
name: kiada-tls #3
items: #3
- key: tls.crt #3
path: example-com.crt #3
- key: tls.key #3
path: example-com.key #3
mode: 0600 #4
containers:
- name: kiada
image: luksa/kiada:1.2
env:
...
- name: envoy
image: envoyproxy/envoy:v1.14.1
volumeMounts: #5
- name: etc-envoy #5
mountPath: /etc/envoy #5
readOnly: true #5
ports:
...
Inspect the complete Pod manifest showing projected sources, selected keys, destination paths, and file permissions. section 9.5.6
A projected volume can also support platform-provided Pod data:
- ServiceAccount token: mounts a token that a container can use to authenticate with the Kubernetes API. section 9.5.6
- Built-in API access volume: commonly combines a ServiceAccount token, the cluster CA certificate, and the Pod namespace. section 9.5.6
