downwardAPI volume is used to expose Pod information into a container. The definition of downwardAPI is a list of items. An item contains a path and fieldRef. Kubernetes will dump the specified metadata listed in fieldRef to a file named path under mountPath and mount the <volume name> into the destination you specified. Currently supported metadata for downwardAPI volume includes:
|
Field path |
Scope |
Definition |
|
spec.nodeName |
Pod |
The node that the Pod is running on |
|
spec.serviceAccountName |
Pod |
The service account associating with the current Pod |
|
metadata.name |
Pod |
The name of the Pod |
|
metadata.namespace |
Pod |
The Namespace that the Pod belongs to |
|
metadata.annotations |
Pod |
The annotations of the Pod |
|
metadata.labels |
Pod |
The labels of the Pod |
|
status.podIP |
Pod |
The ip of the Pod |
|
limits.cpu |
Container |
The CPU limits of the container |
|
requests.cpu |
Container |
The CPU requests of the container |
|
limits.memory |
Container |
The memory limits of the container |
|
requests.memory |
Container |
The memory requests of the container |
|
limits.ephemeral-storage |
Container |
The ephemeral storage limits of the container |
|
requests.ephemeral-storage |
Container |
The ephemeral storage requests of the container |
We use fieldRef.fieldPath if the scope is with a Pod; resourceFieldRef is used when the scope is with a container. For example, the following configuration file could expose metadata.labels in /data-mount volume in an Ubuntu container:
// pod scope example
# cat 2-6-5_downward_api.yaml
apiVersion: v1
kind: Pod
metadata:
name: downwardapi
labels:
env: demo
spec:
containers:
-
name: downwardapi
image: ubuntu
command:
- sleep
- "3600"
volumeMounts:
- name: podinfo
mountPath: "/data-mount"
volumes:
- name: podinfo
downwardAPI:
items:
- path: metadata
fieldRef:
fieldPath: metadata.labels
By describing the pod, we could check that the volume is mounted successfully to /data-mount, and metadata.labels is pointed to the metadata file:
// describe the pod
# kubectl describe pod downwardapi
...
Mounts:
/data-mount from podinfo (rw)
...
Volumes:
podinfo:
Type: DownwardAPI (a volume populated by information about the pod)
Items:
metadata.labels -> metadata
We could check the file inside the container with kubectl exec downwardapi cat /data-mount/metadata, and you should be able to see env="example" presents.
If it's in the container scope, we'll have to specify the container name:
# cat 2-6-5_downward_api_container.yaml
apiVersion: v1
kind: Pod
metadata:
name: downwardapi-container
spec:
containers:
-
name: downwardapi
image: ubuntu
command:
- sleep
- "3600"
volumeMounts:
- name: podinfo
mountPath: "/data-mount"
volumes:
- name: podinfo
downwardAPI:
items:
- path: "cpu_limit"
resourceFieldRef:
containerName: downwardapi
resource: limits.cpu
We could use the docker inspect <container_name> command inside a node to check the implementation:
{
"Source": "/var/lib/kubelet/pods/<id>/volumes/kubernetes.io~downward-api/<volume name>",
"Destination": "/data-mount",
"Mode": "",
"RW": true
}
Kubernetes exposes pod information in source volume, and mounts it to /data-mount.
For the IP of the Pod, using environment variable to propagate in Pod spec would be must easier:
spec:
containers:
- name: envsample-pod-info
env:
- name: MY_POD_IP
valueFrom:
fieldRef:
fieldPath: status.podIP
The sample folder in the Kubernetes GitHub (https://kubernetes.io/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information) contains more examples for both environment variables and downwardAPI volume.