Kubernetes Downward API in action

How to find out if a (docker) container runs in a Kubernetes cluster?

I had to answer this question currently because I work on the transfer of ghe-backup to Kubernetes. Ghe-backup is the Zalando way to backup Github Enterprise data on AWS. So far this application is based on Stups in particular on Taupage.

Ghe-backup backs up several github enterprise instances. Those instances  can’t be moved from AWS to Kubernetes at the same time. Thats the main reason I decided to make ghe-backup run on both, Kubernetes as well as AWS/Taupage.

When brainstorming about how to achieve that one obvious choice came to mind: unix/linux environment variables. However, Kubernetes Downward API is also an option.

“The Downward API allows containers to consume information about themselves or the cluster without using the Kubernetes client or API server.”

Downward API motivation

I use for consuming container information a file: /details/labels.
If the file exists the container assumes to run in Kubernetes. The related if block is part of a bash script:

if [ -f /details/labels ]
 # Kubernetes
elif [ -f /meta/taupage.yaml ]
 # Taupage/AWS

source gh.com/z/ghe-backup/…/convert-kms-private-ssh-key.sh#L32-L77)

The kubernetes downward API creates the file /details/labels with 2 items:

  • volumeMounts
  • volumes

A kubernetes statefulset resource contains a volume mount that creates /details folder as well as a volume including a path labels:

        - name: podinfo
          mountPath: /details
          readOnly: false
      - name: podinfo
            - path: "labels"
Kubernetes Downward API in action
Kubernetes Downward API in action

DownwardAPIVolumeFiles are good examples to show the Downward API in action.

In the screencast below I created a sample POD resource very similar to the Store Pod fields example.

I created a pod “labels” in a minikube cluster. Once the pod is running I follow the POD logs. In two more panes I ssh’ed into the container and watch the labels file:


Two files are watched because the /etc/labels is a symlink – /etc/..10xxxxx/labels is not.

kubectl label po labels newLabel=true

The above command adds a new label to the existing POD.
After some time (actually it depends on how the cluster handles the update) you’ll experience the new label in the log pane. Also the new label shows up in the watched /etc/labels file.
The file /etc/..10xxxxx/labels can’t be open anymore as kubernetes changed that internally.

The Kubernetes Downward API screencast below shows Kubernetes’ capability for a container to have information about itself:

Be the first to comment

Leave a Reply

Your email address will not be published.


This site uses Akismet to reduce spam. Learn how your comment data is processed.