This page shows how a Pod can use a DownwardAPIVolumeFile to expose information about itself to Containers running in the Pod. A DownwardAPIVolumeFile can expose Pod fields and Container fields.
You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. It is recommended to run this tutorial on a cluster with at least two nodes that are not acting as control plane hosts. If you do not already have a cluster, you can create one by using minikube or you can use one of these Kubernetes playgrounds:
To check the version, enterkubectl version
. There are two ways to expose Pod and Container fields to a running Container:
Together, these two ways of exposing Pod and Container fields are called the Downward API.
In this exercise, you create a Pod that has one Container. Here is the configuration file for the Pod:
pods/inject/dapi-volume.yaml
apiVersion: v1
kind: Pod
metadata:
name: kubernetes-downwardapi-volume-example
labels:
zone: us-est-coast
cluster: test-cluster1
rack: rack-22
annotations:
build: two
builder: john-doe
spec:
containers:
- name: client-container
image: k8s.gcr.io/busybox
command: ["sh", "-c"]
args:
- while true; do
if [[ -e /etc/podinfo/labels ]]; then
echo -en '\n\n'; cat /etc/podinfo/labels; fi;
if [[ -e /etc/podinfo/annotations ]]; then
echo -en '\n\n'; cat /etc/podinfo/annotations; fi;
sleep 5;
done;
volumeMounts:
- name: podinfo
mountPath: /etc/podinfo
volumes:
- name: podinfo
downwardAPI:
items:
- path: "labels"
fieldRef:
fieldPath: metadata.labels
- path: "annotations"
fieldRef:
fieldPath: metadata.annotations
In the configuration file, you can see that the Pod has a downwardAPI
Volume, and the Container mounts the Volume at /etc/podinfo
.
Look at the items
array under downwardAPI
. Each element of the array is a DownwardAPIVolumeFile. The first element specifies that the value of the Pod's metadata.labels
field should be stored in a file named labels
. The second element specifies that the value of the Pod's annotations
field should be stored in a file named annotations
.
Create the Pod:
kubectl apply -f https://k8s.io/examples/pods/inject/dapi-volume.yaml
Verify that the Container in the Pod is running:
kubectl get pods
View the Container's logs:
kubectl logs kubernetes-downwardapi-volume-example
The output shows the contents of the labels
file and the annotations
file:
cluster="test-cluster1"
rack="rack-22"
zone="us-est-coast"
build="two"
builder="john-doe"
Get a shell into the Container that is running in your Pod:
kubectl exec -it kubernetes-downwardapi-volume-example -- sh
In your shell, view the labels
file:
/# cat /etc/podinfo/labels
The output shows that all of the Pod's labels have been written to the labels
file:
cluster="test-cluster1"
rack="rack-22"
zone="us-est-coast"
Similarly, view the annotations
file:
/# cat /etc/podinfo/annotations
View the files in the /etc/podinfo
directory:
/# ls -laR /etc/podinfo
In the output, you can see that the labels
and annotations
files are in a temporary subdirectory: in this example, ..2982_06_02_21_47_53.299460680
. In the /etc/podinfo
directory, ..data
is a symbolic link to the temporary subdirectory. Also in the /etc/podinfo
directory, labels
and annotations
are symbolic links.
drwxr-xr-x ... Feb 6 21:47 ..2982_06_02_21_47_53.299460680
lrwxrwxrwx ... Feb 6 21:47 ..data -> ..2982_06_02_21_47_53.299460680
lrwxrwxrwx ... Feb 6 21:47 annotations -> ..data/annotations
lrwxrwxrwx ... Feb 6 21:47 labels -> ..data/labels
/etc/..2982_06_02_21_47_53.299460680:
total 8
-rw-r--r-- ... Feb 6 21:47 annotations
-rw-r--r-- ... Feb 6 21:47 labels
Using symbolic links enables dynamic atomic refresh of the metadata; updates are written to a new temporary directory, and the ..data
symlink is updated atomically using rename(2).
Exit the shell:
/# exit
The preceding exercise, you stored Pod fields in a DownwardAPIVolumeFile. In this next exercise, you store Container fields. Here is the configuration file for a Pod that has one Container:
pods/inject/dapi-volume-resources.yaml
apiVersion: v1
kind: Pod
metadata:
name: kubernetes-downwardapi-volume-example-2
spec:
containers:
- name: client-container
image: k8s.gcr.io/busybox:1.24
command: ["sh", "-c"]
args:
- while true; do
echo -en '\n';
if [[ -e /etc/podinfo/cpu_limit ]]; then
echo -en '\n'; cat /etc/podinfo/cpu_limit; fi;
if [[ -e /etc/podinfo/cpu_request ]]; then
echo -en '\n'; cat /etc/podinfo/cpu_request; fi;
if [[ -e /etc/podinfo/mem_limit ]]; then
echo -en '\n'; cat /etc/podinfo/mem_limit; fi;
if [[ -e /etc/podinfo/mem_request ]]; then
echo -en '\n'; cat /etc/podinfo/mem_request; fi;
sleep 5;
done;
resources:
requests:
memory: "32Mi"
cpu: "125m"
limits:
memory: "64Mi"
cpu: "250m"
volumeMounts:
- name: podinfo
mountPath: /etc/podinfo
volumes:
- name: podinfo
downwardAPI:
items:
- path: "cpu_limit"
resourceFieldRef:
containerName: client-container
resource: limits.cpu
divisor: 1m
- path: "cpu_request"
resourceFieldRef:
containerName: client-container
resource: requests.cpu
divisor: 1m
- path: "mem_limit"
resourceFieldRef:
containerName: client-container
resource: limits.memory
divisor: 1Mi
- path: "mem_request"
resourceFieldRef:
containerName: client-container
resource: requests.memory
divisor: 1Mi
In the configuration file, you can see that the Pod has a downwardAPI
Volume, and the Container mounts the Volume at /etc/podinfo
.
Look at the items
array under downwardAPI
. Each element of the array is a DownwardAPIVolumeFile.
The first element specifies that in the Container named client-container
, the value of the limits.cpu
field in the format specified by 1m
should be stored in a file named cpu_limit
. The divisor
field is optional and has the default value of 1
which means cores for cpu and bytes for memory.
Create the Pod:
kubectl apply -f https://k8s.io/examples/pods/inject/dapi-volume-resources.yaml
Get a shell into the Container that is running in your Pod:
kubectl exec -it kubernetes-downwardapi-volume-example-2 -- sh
In your shell, view the cpu_limit
file:
/# cat /etc/podinfo/cpu_limit
You can use similar commands to view the cpu_request
, mem_limit
and mem_request
files.
The following information is available to containers through environment variables and downwardAPI
volumes:
fieldRef
: metadata.name
- the pod's namemetadata.namespace
- the pod's namespacemetadata.uid
- the pod's UIDmetadata.labels['<KEY>']
- the value of the pod's label <KEY>
(for example, metadata.labels['mylabel']
)metadata.annotations['<KEY>']
- the value of the pod's annotation <KEY>
(for example, metadata.annotations['myannotation']
)resourceFieldRef
: DownwardAPIHugePages
feature gate is enabled)DownwardAPIHugePages
feature gate is enabled)In addition, the following information is available through downwardAPI
volume fieldRef
:
metadata.labels
- all of the pod's labels, formatted as label-key="escaped-label-value"
with one label per linemetadata.annotations
- all of the pod's annotations, formatted as annotation-key="escaped-annotation-value"
with one annotation per lineThe following information is available through environment variables:
status.podIP
- the pod's IP addressspec.serviceAccountName
- the pod's service account name, available since v1.4.0-alpha.3spec.nodeName
- the node's name, available since v1.4.0-alpha.3status.hostIP
- the node's IP, available since v1.7.0-alpha.1You can project keys to specific paths and specific permissions on a per-file basis. For more information, see Secrets.
It is sometimes useful for a Container to have information about itself, without being overly coupled to Kubernetes. The Downward API allows containers to consume information about themselves or the cluster without using the Kubernetes client or API server.
An example is an existing application that assumes a particular well-known environment variable holds a unique identifier. One possibility is to wrap the application, but that is tedious and error prone, and it violates the goal of low coupling. A better option would be to use the Pod's name as an identifier, and inject the Pod's name into the well-known environment variable.
© 2022 The Kubernetes Authors
Documentation Distributed under CC BY 4.0.
https://kubernetes.io/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/