How to Set Environment Variables in a Kubernetes Pod

When you’re configuring a Kubernetes pod, you’ll need a specific environment configuration for an application. Whether it’s a port that the app is using or a version of the Docker image for the app, you’ll need to set some type of configuration. Because of the constant changes in environments, this process can get out of control fast. Before you know it, you’ll have dozens of environment variables and nowhere to properly store them.

In this blog post, you’ll learn the Kubernetes way of environment variable configuration and how you can stop an environment from getting out of control with CloudTruth.

Kubernetes Environment Variables

If you’re not familiar with environment variables, think about it like a value that you have to use later on. Sort of like a phone number saved in your cell phone. When you need it, you call. It’s stored, but it can also be erased and changed.

When thinking about environment variables with Kubernetes, they’re no different than environment variables on your local computer. Where-as you would have an application ingest environment variables, the Kubernetes cluster is instead ingesting the variables. You can set up several different environment variables, including:

• Kubernetes pod environment variables
• Kubernetes dynamic environment variables
• Kubernetes deployment environment variables

Essentially, as long as the environment variables can be ingested, they can be set for any deployment, pod, service, ConfigMaps, etc…

Going a step further, you can even set up specific environment variables for the containers running inside of the pods.

Setting Kubernetes Environment Variables

When you’re creating environment variables, there are a few ways to go about it:

• Using the command line. For example, kubectl set env example
• Within the Kubernetes manifest, you can set an env key/value pair
• From a .env file
• By exporting/creating environment variables on your computer. For example, in Linux or MacOS, you could run export NAME=VALUE

As an example, take a look at the Kubernetes manifest below. You’ll see the env keyword along with values.

apiVersion: v1
kind: Pod
metadata:
  name: envar-demo
  labels:
    purpose: demonstrate-envars
spec:
  containers:
  - name: envar-demo-container
    image: gcr.io/google-samples/node-hello:1.0
    env:
    - name: DEMO_GREETING
      value: "Hello from the environment"

Although setting environment variables is straightforward, it may be a headache later on. A few examples that come to mind are:

• What if the value needs to change? Does that mean all of the manifests have to be re-configured/re-written?
• Setting an environment variable locally or from the kubectl set env command doesn’t help other developers and engineers because it’s on one persons computer
• What if the environment variable is a secret?
• What if you want to keep your configurations multi-cloud or hybrid-cloud, so a service like AWS SSM or Secrets Manager is out of the question?

In the last section of this blog post, Utilizing CloudTruth For Variables And Parameters, you’ll learn how CloudTruth can help you with this.

Retrieving Kubernetes Environment Variables

After you set a Kubernetes environment variable, you can retrieve it to ensure that the value is what you expected to see and that it is in the right location.

To retrieve a Kubernetes environment variable via the terminal, you can run the following command. Ensure that you change kuberentes_deployment_name to the deployment name that you want to retrieve the value (environment variables) from.

kubectl exec kubernetes_deployment_name -- printenv

For example, if the Kubernetes deployment is a node app with a port of 8080 and you set those environment variables specifically for the Kubernetes deployment, you’ll see an output similar to below. Notice how it’s a key/value pair, the key being node_version and SERVICE_PORT, then the are appropriate values associated with those keys.

NODE_VERSION=4.4.2
SERVICE_PORT=8080

Utilizing CloudTruth For Variables, Secrets And Parameters

One major problem about setting environment variables using the kubectl command, and most other methods, is:

• The environment variables no longer exist outside of the environment
• Environment variables are stored in a processes memory, so if a computer is restarted, for example, they go away
• There’s no location that teams can retrieve environment variables from

With CloudTruth, you can utilize its centralized configuration to not only store parameters, but to retrieve and use them.

CloudTruth allows you to set parameters/variables with its CLI in an easy way. For example, below are a few lines for setting Nginx parameters for a Kubernetes manifest.

cloudtruth --project cloudtruth_project_name parameter set --value nginx app_name
cloudtruth --project cloudtruth_project_name parameter set --value 3 replicas
cloudtruth --project cloudtruth_project_name parameter set --value 80 port
cloudtruth --project cloudtruth_project_name parameter set --value nginx image_name
cloudtruth --project cloudtruth_project_name parameter set --value latest nginx_version

Once they’re set, you can configure your Kubernetes manifest to ensure it ingests the parameters by using a syntax.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: 
  namespace: default
  labels:
    app: 
spec:
  replicas: 
  selector:
    matchLabels:
      app: 
  template:
    metadata:
      labels:
        app: 
    spec:
      containers:
      - name: 
        image: :
        ports:
        - containerPort: 

To read more about getting started with CloudTruth and Kubernetes, check out this getting started guide over on our blog, which you can find here.