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.

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

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


The kubernetes downward API creates the file /details/labels file 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 creat 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:

  1. /etc/labels
  2. /etc/..10xxxxx/labels

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

With kubectl label po labels newLabel=true I add 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:

Lothar Schulz

Leave a Reply

Your email address will not be published. Required fields are marked *

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