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 ] then # Kubernetes elif [ -f /meta/taupage.yaml ] then # Taupage/AWS fi
The kubernetes downward API creates the file /details/labels with 2 items:
A kubernetes statefulset resource contains a volume mount that creates /details folder as well as a volume including a path labels:
... volumeMounts: - name: podinfo mountPath: /details readOnly: false ... volumes: - name: podinfo downwardAPI: items: - path: "labels" ...
DownwardAPIVolumeFiles are good examples to show the Downward API in action.
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: