CODEWITHSUNDEEP
kubernetes
Lucy Panda
Lucy Panda

Reputation: 505

Can I modify container's environment variables without restarting pod using kubernetes

I have a running pod and I want to change one of it's container's environment variable and made it work immediately. Can I achieve that? If I can, how to do that?

Upvotes: 49

Views: 85759

Answers (7)

tback
tback

Reputation: 11561

I'm not aware of any way to do it and I can't think of a real world scenario where this makes too much sense.

Usually you have to restart a process for it to notice the changed environment variables and the easiest way to do that is restarting the pod.

The solution closest to what you seem to want is to create a deployment and then use kubectl edit (kubectl edit deploy/name) to modify it's environment variables. A new pod is started and the old one is terminated after you save.

Upvotes: 11

Ganesh Shinde
Ganesh Shinde

Reputation: 73

You can use configmap with volumes to update environment variables on the go..

Refer: https://itnext.io/how-to-automatically-update-your-kubernetes-app-configuration-d750e0ca79ab

Upvotes: 0

Ahmed Badawy
Ahmed Badawy

Reputation: 481

This worked with me

kubectl set env RESOURCE/NAME KEY_1=VAL_1 ... KEY_N=VAL_N

check the official documentation here

Another approach for runtime pods you can get into the Pod command line and change the variables in the runtime RUN kubectl exec -it <pod_name> -- /bin/bash Then Run export VAR1=VAL1 && export VAR2=VAL2 && your_cmd

Upvotes: 23

Radek &#39;Goblin&#39; Pieczonka
Radek &#39;Goblin&#39; Pieczonka

Reputation: 22892

Simply put and in kube terms, you can not.

Environment for linux process is established on process startup, and there are certainly no kube tools that can achieve such goal. For example, if you make a change to your Deployment (I assume you use it to create pods) it will roll the underlying pods.

Now, that said, there is a really hacky solution reported under Is there a way to change the environment variables of another process in Unix? that involves using GDB

Also, remember that even if you could do that, there is still application logic that would need to watch for such changes instead of, as it usually is now, just evaluate configuration from envs during startup.

Upvotes: 26

Newton Zou
Newton Zou

Reputation: 588

It is hard to change from outside. But it is easy to change from inside. Your App running in the pod can change it. Just oppose an Api to change environment variable.

Upvotes: 0

nikoskip
nikoskip

Reputation: 1920

If you are using Helm 3> according to the documentation:

Automatically Roll Deployments

Often times ConfigMaps or Secrets are injected as configuration files in containers or there are other external dependencies changes that require rolling pods. Depending on the application a restart may be required should those be updated with a subsequent helm upgrade, but if the deployment spec itself didn't change the application keeps running with the old configuration resulting in an inconsistent deployment.

The sha256sum function can be used to ensure a deployment's annotation section is updated if another file changes:

kind: Deployment 
spec: 
  template:
    metadata:
      annotations:
        checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") . | sha256sum }} 
[...]

In the event you always want to roll your deployment, you can use a similar annotation step as above, instead replacing with a random string so it always changes and causes the deployment to roll:

kind: Deployment 
spec:   
  template:
    metadata:
      annotations:
        rollme: {{ randAlphaNum 5 | quote }} 
[...]

Both of these methods allow your Deployment to leverage the built in update strategy logic to avoid taking downtime.

NOTE: In the past we recommended using the --recreate-pods flag as another option. This flag has been marked as deprecated in Helm 3 in favor of the more declarative method above.

Upvotes: 2

Lindsay Landry
Lindsay Landry

Reputation: 4907

Kubernetes is designed in such a way that any changes to the pod should be redeployed through the config. If you go messing with pods that have already been deployed you can end up with weird clusters that are hard to debug.

If you really want to you can run additional commands in your running pod using kubectl exec, but this is only recommended for debug purposes. 

kubectl exec -it <pod_name> export VARIABLENAME=<thing>

Upvotes: 2

Related Questions