Using variables in Kubernetes

No single environment is equal to the other. While the content of the deployment itself is equal (at least, it should be), the differences between the applications resides in the variables.

This article is a follow up of my previous article about running a Kubernetes cluster in Azure.

Using variables

Keep in mind that your application which is running in Kubernetes is always the same image, no matter what environment is it running on. Differences are always there and must be defined in variables.

Knowing this, implement these variables in your application from the beginning. These variables can be anything, for example en-/disable debugging, setting Analytics keys, test/staging/production api endpoints etc. Just make sure to have a stable implementation of using these variables.

For this article I’ve added a single value for the subtitle which renderes the hosting environment. This show ‘Running on Local Webserver‘ when it’s executed on my development machine and Running on Kubernetes’ when it’s executed in an Kubernetes cluster:

I’ve put this variable inside my .Net Core application as an environment variable. You can override this value by using a setting file but this is easier to show. I’ve created a variable called appTitle with a value Local Webserver.

My ViewModel is getting this value by using:

PageTitle = _configuration.GetValue<string>("AppTitle");

Our application is ready to use the environment variable, assuming there is an environment variable called “AppTitle”. We need to make sure our application in Kubernetes has an environment variable called App Title.

Extend our deployment

In order to add an environment variable to our application, we need to modify our manifest file first:

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: deployment-megamath
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: app-megamath
    spec:
      containers:
        - image: "megamathcontainerregistry.azurecr.io/megamath-web:4.0.0"
          imagePullPolicy: Always
          name: container-megamath
          ports:
          - containerPort: 80
          env:
          - name: AppTitle
            valueFrom:
              configMapKeyRef:
                name:  configmap-megamath
                key: key_app_title

Take a look at the last lines. Here, I’ve added a, environment variable called AppTitle. So, our application has an new variable which can be used. The value however must be variable. It’s possible to define the value in several ways. I’ve picked up a configmap because it’s easy to understand and to implement.

Looking at the example, there is a reference to a key/value pair in a configmap (configmapRef). In other words, this line is just adding a environment variable calle AppTitle with a value which is retrieved from a configmap. This configmap is just a Kubernetes resource.

Kubernetes configmaps

Now our application is using a variable defined in the configmap, let’s add the configmap itself:

apiVersion: v1
kind: ConfigMap
metadata:
    name: configmap-megamath
data:    
    key_app_title: "Kubernetes"

Note the name of the configmap and the key. This is referenced by the deployment manifest.

When applying the deployment and the configmap, the application returns the new value from the configmap: “Kubernetes”.

Combining

Remember, for the best overview, combine manifests files into a single file. This way you can just use:

kubectl apply -f manifest.yaml

Folkert

I'm a webdeveloper, looking for the best experience, working between development and design. Just a creative programmer. When I'm getting tired of programming C#, i'd love to create 3D images in 3D Studio Max, play the guitar, create an app for Android or crush some plastics on a climbing wall or try to stay alive when i´m descending some nice white powdered snowy mountains on my snowboard.

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.