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
- From a
- By exporting/creating environment variables on your computer. For example, in Linux or MacOS, you could run
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 envcommand 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
SERVICE_PORT, then the are appropriate values associated with those keys.
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
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.