A downwardAPI volume projects selected Pod metadata and container resource information into files inside a container. It avoids duplicating values already present in the Pod manifest and exposes values known only after creation or scheduling, such as the Pod name or node. section 8.4 section 9.5.5
Configure each projected file with a field reference:
- Use fieldRef for supported Pod fields, including metadata.name, metadata.namespace, labels, annotations, and selected status or specification fields. section 8.4.1
- Use resourceFieldRef for container requests and limits such as CPU, memory, ephemeral storage, and hugepages. section 8.4.1
- Mount the volume in the container and choose each file’s path; defaultMode and per-file mode control permissions. section 9.5.5
- Specify containerName when a volume projects resource fields, because the volume belongs to the Pod rather than one obvious container. section 9.5.5
Write the Pod name to a file
Define a downwardAPI volume with an item whose path is name.txt and whose fieldRef is metadata.name. Mount it at /etc/pod; the container then reads the Pod name from /etc/pod/name.txt. section 9.5.5
Listing 9.14 Injecting Pod metadata into the container’s filesystem
...
volumes: #1
- name: metadata #1
downwardAPI: #1
items: #2
- path: name.txt #2
fieldRef: #2
fieldPath: metadata.name #2
containers: #2
- name: foo
...
volumeMounts: #3
- name: metadata #3
mountPath: /etc/pod #3
Use the manifest listing to see the volume, projected metadata item, and container mount together. section 9.5.5
