In modern software development, it is common to separate configuration variables from the application code itself. In this way, it is easier to make updates to service URLs, credentials, common paths, and so on. Having these values in external configuration files means we can easily update configuration without rebuilding the entire application.

This separation solves the initial problem, but true portability comes when you can remove the dependency from the application completely. Kubernetes offers a configuration store for exactly this purpose. ConfigMaps are simple constructs that store key-value pairs. 

Let's take a look at an example that will allow us to store some configuration and then consume it in various pods. The following listings will work for both federated and single clusters, but we will continue using a federated setup for this example.

The ConfigMap kind can be created using literal values, flat files and directories, and finally YAML definition files. The following listing is a YAML definition of the configmap-fed.yaml file:

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-application-config
  namespace: default
data:
  backend-service.url: my-backend-service

Let's first switch back to our federation plane:

$ kubectl config use-context master-control

Now, create this listing with the following command:

$ kubectl create -f configmap-fed.yaml

Let's display the configmap object that we just created. The -o yaml flag helps us to display the full information: 

$ kubectl get configmap my-application-config -o yaml

Now that we have a ConfigMap object, let's start up a federated ReplicaSet that can use the ConfigMap object. This will create replicas of pods across our cluster that can access the ConfigMap object. ConfigMaps can be accessed via environment variables or mount volumes. This example will use a mount volume that provides a folder hierarchy and the files for each key with the contents representing the values. Save the following file as configmap-rs-fed.yaml:

apiVersion: extensions/v1beta1
kind: ReplicaSet
metadata:
  name: node-js-rs
spec:
  replicas: 3
  selector:
    matchLabels:
      name: node-js-configmap-rs
  template:
    metadata:
      labels:
        name: node-js-configmap-rs
    spec:
      containers:
      - name: configmap-pod
        image: jonbaier/node-express-info:latest
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: configmap-volume
          mountPath: /etc/config

volumes:
      - name: configmap-volume
        configMap:
          name: my-application-config

Create this pod with kubectl create -f configmap-rs-fed.yaml. After creation, we will need to switch contexts to one of the clusters where the pods are running. You can choose either, but we will use the GCE context here:

$ kubectl config use-context gcek8s

Now that we are on the GCE cluster specifically, let's check configmaps here:

$ kubectl get configmaps

As you can see, the ConfigMap is propagated locally to each cluster. Next, let's find a pod from our federated ReplicaSet:

$ kubectl get pods

Let's take one of the node-js-rs pod names from the listing and run a bash shell with kubectl exec:

$ kubectl exec -it node-js-rs-6g7nj bash

Then, let's change directories to the /etc/config folder that we set up in the pod definition. Listing this directory reveals a single file with the name of the ConfigMap we defined earlier:

$ cd /etc/config
$ ls

If we then display the contents of the files with the following command, we should see the value we entered earlier, my-backend-service:

$ echo $(cat backend-service.url)

If we were to look in any of the pods across our federated cluster, we would see the same values. This is a great way to decouple configuration from an application and distribute it across our fleet of clusters.