# Downward API

Downward APIThere are two ways to expose Pod and container fields to a running container: environment variables, and as files that are populated by a special volume type. Together, these two ways of exposing Pod and container fields are called the downward API.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.In Kubernetes, there are two ways to expose Pod and container fields to a running container:as environment variablesas files in a downwardAPI volumeTogether, these two ways of exposing Pod and container fields are called the downward API.Available fieldsOnly some Kubernetes API fields are available through the downward API. This section lists which fields you can make available.You can pass information from available Pod-level fields using fieldRef. At the API level, the spec for a Pod always defines at least one Container. You can pass information from available Container-level fields using resourceFieldRef.Information available via fieldRefFor some Pod-level fields, you can provide them to a container either as an environment variable or using a downwardAPI volume. The fields available via either mechanism are:metadata.namethe pod's namemetadata.namespacethe pod's namespacemetadata.uidthe pod's unique IDmetadata.annotations['<KEY>']the value of the pod's annotation named <KEY> (for example, metadata.annotations['myannotation'])metadata.labels['<KEY>']the text value of the pod's label named <KEY> (for example, metadata.labels['mylabel'])The following information is available through environment variables but not as a downwardAPI volume fieldRef:spec.serviceAccountNamethe name of the pod's service accountspec.nodeNamethe name of the node where the Pod is executingstatus.hostIPthe primary IP address of the node to which the Pod is assignedstatus.hostIPsthe IP addresses is a dual-stack version of status.hostIP, the first is always the same as status.hostIP.status.podIPthe pod's primary IP address (usually, its IPv4 address)status.podIPsthe IP addresses is a dual-stack version of status.podIP, the first is always the same as status.podIPThe following information is available through a downwardAPI volume fieldRef, but not as environment variables:metadata.labelsall of the pod's labels, formatted as label-key="escaped-label-value" with one label per linemetadata.annotationsall of the pod's annotations, formatted as annotation-key="escaped-annotation-value" with one annotation per lineInformation available via resourceFieldRefThese container-level fields allow you to provide information about requests and limits for resources such as CPU and memory.Note:FEATURE STATE: Kubernetes v1.33 [beta] (enabled by default: true)Container CPU and memory resources can be resized while the container is running. If this happens, a downward API volume will be updated, but environment variables will not be updated unless the container restarts. See Resize CPU and Memory Resources assigned to Containers for more details.resource: limits.cpuA container's CPU limitresource: requests.cpuA container's CPU requestresource: limits.memoryA container's memory limitresource: requests.memoryA container's memory requestresource: limits.hugepages-*A container's hugepages limitresource: requests.hugepages-*A container's hugepages requestresource: limits.ephemeral-storageA container's ephemeral-storage limitresource: requests.ephemeral-storageA container's ephemeral-storage requestFallback information for resource limitsIf CPU and memory limits are not specified for a container, and you use the downward API to try to expose that information, then the kubelet defaults to exposing the maximum allocatable value for CPU and memory based on the node allocatable calculation.What's nextYou can read about downwardAPI volumes.You can try using the downward API to expose container- or Pod-level information:as environment variablesas files in downwardAPI volume