Expose Pod Information to Containers Through Files

    In Kubernetes, 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.

    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:

    In this part of exercise, you create a Pod that has one container, and you project Pod-level fields into the running container as files. Here is the manifest for the Pod:

    pods/inject/dapi-volume.yaml

    In the manifest, 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 defines a downwardAPI volume. 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.

    Note: The fields in this example are Pod fields. They are not fields of the container in the Pod.

    Create the Pod:

    1. kubectl apply -f https://k8s.io/examples/pods/inject/dapi-volume.yaml

    Verify that the container in the Pod is running:

    1. kubectl get pods
    1. kubectl logs kubernetes-downwardapi-volume-example

    The output shows the contents of the labels file and the annotations file:

    1. cluster="test-cluster1"
    2. rack="rack-22"
    3. zone="us-est-coast"
    5. build="two"
    6. builder="john-doe"

    Get a shell into the container that is running in your Pod:

    In your shell, view the labels file:

    1. /# cat /etc/podinfo/labels

    The output shows that all of the Pod’s labels have been written to the labels file:

    1. cluster="test-cluster1"
    2. rack="rack-22"
    3. zone="us-est-coast"

    Similarly, view the annotations file:

    1. /# cat /etc/podinfo/annotations

    View the files in the /etc/podinfo directory:

    1. /# 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 are symbolic links.

    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 .

    Note: A container using Downward API as a subPath volume mount will not receive Downward API updates.

    Exit the shell:

    1. /# exit

    pods/inject/dapi-volume-resources.yaml Expose Pod Information to Containers Through Files - 图2

    1. apiVersion: v1
    2. kind: Pod
    3. metadata:
    4.   name: kubernetes-downwardapi-volume-example-2
    5.   containers:
    6.     - name: client-container
    7.       image: registry.k8s.io/busybox:1.24
    8.       command: ["sh", "-c"]
    9.       args:
    10.       - while true; do
    11.           echo -en '\n';
    12.           if [[ -e /etc/podinfo/cpu_limit ]]; then
    13.             echo -en '\n'; cat /etc/podinfo/cpu_limit; fi;
    14.           if [[ -e /etc/podinfo/cpu_request ]]; then
    15.             echo -en '\n'; cat /etc/podinfo/cpu_request; fi;
    16.           if [[ -e /etc/podinfo/mem_limit ]]; then
    17.             echo -en '\n'; cat /etc/podinfo/mem_limit; fi;
    18.           if [[ -e /etc/podinfo/mem_request ]]; then
    19.             echo -en '\n'; cat /etc/podinfo/mem_request; fi;
    20.           sleep 5;
    21.         done;
    22.       resources:
    23.         requests:
    24.           memory: "32Mi"
    25.           cpu: "125m"
    26.         limits:
    27.           memory: "64Mi"
    28.           cpu: "250m"
    29.       volumeMounts:
    30.         - name: podinfo
    31.           mountPath: /etc/podinfo
    32.   volumes:
    33.     - name: podinfo
    35.           - path: "cpu_limit"
    36.             resourceFieldRef:
    37.               containerName: client-container
    38.               resource: limits.cpu
    39.               divisor: 1m
    40.           - path: "cpu_request"
    41.             resourceFieldRef:
    42.               containerName: client-container
    43.               resource: requests.cpu
    44.               divisor: 1m
    45.           - path: "mem_limit"
    46.             resourceFieldRef:
    47.               containerName: client-container
    48.               resource: limits.memory
    49.               divisor: 1Mi
    50.           - path: "mem_request"
    51.             resourceFieldRef:
    52.               containerName: client-container
    53.               resource: requests.memory
    54.               divisor: 1Mi

    In the manifest, you can see that the Pod has a , and that the single container in that Pod mounts the volume at /etc/podinfo.

    Look at the items array under downwardAPI. Each element of the array defines a file in the downward API volume.

    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 published as a file named cpu_limit. The divisor field is optional and has the default value of 1. A divisor of 1 means cores for cpu resources, or bytes for memory resources.

    Create the Pod:

    1. 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:

    1. kubectl exec -it kubernetes-downwardapi-volume-example-2 -- sh

    In your shell, view the cpu_limit file:

    You can use similar commands to view the cpu_request, mem_limit and mem_request files.

    You can project keys to specific paths and specific permissions on a per-file basis. For more information, see .

    • Read the API definition for Pod. This includes the definition of Container (part of Pod).
    • Read the list of available fields that you can expose using the downward API.

    Read about volumes in the legacy API reference:

    • Check the API definition which defines a generic volume in a Pod for containers to access.
    • Check the DownwardAPIVolumeSource API definition which defines a volume that contains Downward API information.
    • Check the API definition which contains references to object or resource fields for populating a file in the Downward API volume.
    • Check the ResourceFieldSelector API definition which specifies the container resources and their output format.