このコンテンツは選択した言語では利用できません。
Chapter 31. Downward API
31.1. Overview
The downward API is a mechanism that allows containers to consume information about API objects without coupling to OpenShift Container Platform. Such information includes the pod’s name, namespace, and resource values. Containers can consume information from the downward API using environment variables or a volume plug-in.
31.2. Selecting Fields
Fields within the pod are selected using the FieldRef API type. FieldRef has two fields:
| Field | Description |
|---|---|
|
| The path of the field to select, relative to the pod. |
|
|
The API version to interpret the |
Currently, the valid selectors in the v1 API include:
| Selector | Description |
|---|---|
|
| The pod’s name. This is supported in both environment variables and volumes. |
|
| The pod’s namespace.This is supported in both environment variables and volumes. |
|
| The pod’s labels. This is only supported in volumes and not in environment variables. |
|
| The pod’s annotations. This is only supported in volumes and not in environment variables. |
|
| The pod’s IP. This is only supported in environment variables and not volumes. |
The apiVersion field, if not specified, defaults to the API version of the enclosing pod template.
31.3. Consuming the Container Values Using the Downward API
31.3.1. Using Environment Variables
One mechanism for consuming the downward API is using a container’s environment variables. The EnvVar type’s valueFrom field (of type EnvVarSource) is used to specify that the variable’s value should come from a FieldRef source instead of the literal value specified by the value field. In the future, additional sources may be supported; currently the source’s fieldRef field is used to select a field from the downward API.
Only constant attributes of the pod can be consumed this way, as environment variables cannot be updated once a process is started in a way that allows the process to be notified that the value of a variable has changed. The fields supported using environment variables are:
- Pod name
Pod namespace
Create a
pod.jsonfile:apiVersion: v1 kind: Pod metadata: name: dapi-env-test-pod spec: containers: - name: env-test-container image: gcr.io/google_containers/busybox command: [ "/bin/sh", "-c", "env" ] env: - name: MY_POD_NAME valueFrom: fieldRef: fieldPath: metadata.name - name: MY_POD_NAMESPACE valueFrom: fieldRef: fieldPath: metadata.namespace restartPolicy: NeverCreate the pod from the
pod.jsonfile:$ oc create -f pod.json
Check the container’s logs for the
MY_POD_NAMEandMY_POD_NAMESPACEvalues:$ oc logs -p dapi-env-test-pod
31.3.2. Using the Volume Plug-in
Another mechanism for consuming the downward API is using a volume plug-in. The downward API volume plug-in creates a volume with configured fields projected into files. The metadata field of the VolumeSource API object is used to configure this volume. The plug-in supports the following fields:
- Pod name
- Pod namespace
- Pod annotations
- Pod labels
Example 31.1. Downward API Volume Plug-in Configuration
spec:
volumes:
- name: podinfo
metadata: 1
items: 2
- name: "labels" 3
fieldRef:
fieldPath: metadata.labels 4For example:
Create a
volume-pod.jsonfile:kind: Pod apiVersion: v1 metadata: labels: zone: us-east-coast cluster: downward-api-test-cluster1 rack: rack-123 name: dapi-volume-test-pod annotations: annotation1: "345" annotation2: "456" spec: containers: - name: volume-test-container image: gcr.io/google_containers/busybox command: ["sh", "-c", "cat /etc/labels /etc/annotations"] volumeMounts: - name: podinfo mountPath: /etc readOnly: false volumes: - name: podinfo metadata: items: - name: "labels" fieldRef: fieldPath: metadata.labels - name: "annotations" fieldRef: fieldPath: metadata.annotations restartPolicy: NeverCreate the pod from the
volume-pod.jsonfile:$ oc create -f volume-pod.json
Check the container’s logs and verify the presence of the configured fields:
$ oc logs -p dapi-volume-test-pod cluster=downward-api-test-cluster1 rack=rack-123 zone=us-east-coast annotation1=345 annotation2=456 kubernetes.io/config.source=api
31.4. Consuming Container Resources Using the Downward API
When creating pods, you can use the downward API to inject information about computing resource requests and limits so that image and application authors can correctly create an image for specific environments.
You can do this using both the environment variable and volume plug-in methods.
31.4.1. Using Environment Variables
When creating a pod configuration, specify environment variables that correspond to the contents of the
resourcesfield in thespec.containerfield:... spec: containers: - name: test-container image: gcr.io/google_containers/busybox:1.24 command: [ "/bin/sh", "-c", "env" ] resources: requests: memory: "32Mi" cpu: "125m" limits: memory: "64Mi" cpu: "250m" env: - name: MY_CPU_REQUEST valueFrom: resourceFieldRef: resource: requests.cpu - name: MY_CPU_LIMIT valueFrom: resourceFieldRef: resource: limits.cpu - name: MY_MEM_REQUEST valueFrom: resourceFieldRef: resource: requests.memory - name: MY_MEM_LIMIT valueFrom: resourceFieldRef: resource: limits.memory ...If the resource limits are not included in the container configuration, the downward API defaults to the node’s CPU and memory allocatable values.
Create the pod from the
pod.jsonfile:$ oc create -f pod.json
31.4.2. Using the Volume Plug-in
When creating a pod configuration, use the
spec.volumes.downwardAPI.itemsfield to describe the desired resources that correspond to thespec.resourcesfield:.... spec: containers: - name: client-container image: gcr.io/google_containers/busybox:1.24 command: ["sh", "-c", "while true; do echo; if [[ -e /etc/cpu_limit ]]; then cat /etc/cpu_limit; fi; if [[ -e /etc/cpu_request ]]; then cat /etc/cpu_request; fi; if [[ -e /etc/mem_limit ]]; then cat /etc/mem_limit; fi; if [[ -e /etc/mem_request ]]; then cat /etc/mem_request; fi; sleep 5; done"] resources: requests: memory: "32Mi" cpu: "125m" limits: memory: "64Mi" cpu: "250m" volumeMounts: - name: podinfo mountPath: /etc readOnly: false volumes: - name: podinfo downwardAPI: items: - path: "cpu_limit" resourceFieldRef: containerName: client-container resource: limits.cpu - path: "cpu_request" resourceFieldRef: containerName: client-container resource: requests.cpu - path: "mem_limit" resourceFieldRef: containerName: client-container resource: limits.memory - path: "mem_request" resourceFieldRef: containerName: client-container resource: requests.memory ....If the resource limits are not included in the container configuration, the downward API defaults to the node’s CPU and memory allocatable values.
Create the pod from the
volume-pod.jsonfile:$ oc create -f volume-pod.json
