kubectl cycle pods

[cbluth]

Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see http://kubernetes.io/docs/troubleshooting/.):

What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): cycle, refresh

---

Is this a BUG REPORT or FEATURE REQUEST? (choose one): FEATURE

This is a VERY common occurrence:

1. update configmap values (using envFrom)
2. desire this new environment variable to be "pushed out" to all the currently running pods.
3. at this point i manually delete pods in order for it to take effect, or i have also discovered that adding an extra/non-needed environment variable to the deployment will have a similar effect.
   I would prefer a feature that allows me to cycle or refresh all the pods of a given selector, so that they grab the new config.
4. Am I doing this wrong, is there a "better" way to do it?

Kubernetes version (use kubectl version):
Client Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.1", GitCommit:"b0b7a323cc5a4a2019b2e9520c21c7830b7f708e", GitTreeState:"clean", BuildDate:"2017-04-03T20:44:38Z", GoVersion:"go1.7.5", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.2", GitCommit:"477efc3cbe6a7effca06bd1452fa356e2201e1ee", GitTreeState:"clean", BuildDate:"2017-04-19T20:22:08Z", GoVersion:"go1.7.5", Compiler:"gc", Platform:"linux/amd64"}

Environment:

• Cloud provider or hardware configuration: AWS
• OS (e.g. from /etc/os-release):

core@ip-10-20-25-116 ~ $ cat /etc/os-release NAME="Container Linux by CoreOS" ID=coreos VERSION=1465.6.0 VERSION_ID=1465.6.0 BUILD_ID=2017-08-16-0012 PRETTY_NAME="Container Linux by CoreOS 1465.6.0 (Ladybug)" ANSI_COLOR="38;5;75" HOME_URL="https://coreos.com/" BUG_REPORT_URL="https://issues.coreos.com" COREOS_BOARD="amd64-usr" core@ip-10-20-25-116 ~ $

• Kernel (e.g. uname -a):
  core@ip-10-20-25-116 ~ $ uname -a Linux ip-10-20-25-116.ec2.internal 4.12.7-coreos #1 SMP Tue Aug 15 23:54:56 UTC 2017 x86_64 Intel(R) Xeon(R) CPU E5-2670 v2 @ 2.50GHz GenuineIntel GNU/Linux core@ip-10-20-25-116 ~ $
• Install tools: kops
• Others:

What happened:

What you expected to happen:

How to reproduce it (as minimally and precisely as possible):

Anything else we need to know:

[apelisse]

Deleting pods manually is not ideal if you want a rolling update to the new values (and avoid downtime). It's a little bit tedious.

The "correct" way to do it is to create a new configmap everytime you want to change a value, and then update-then-apply (or edit) the deployment to point to that new configmap. This will automatically perform a rolling-update. It is tedious to create a new configmap everytime (you need to find a name, and then delete the obsolete configmap). I know that https://github.com/kubernetes/kubernetes/pull/49961 will at least fix the naming problem.

[kargakis]

Updates to a config map should project inside your container seconds after you update the configmap. Or isn't this the case with envFrom? Pretty sure it works for volumes. If your app knows how to reread config on an interval, it should be able to pick up the new config.

[tonglil]

Most, if not a lot of, apps (especially off the shelf) don't know to reread config on intervals. For example, even nginx requires the user to manually reload it.

My use case is trying to automate the changing of config for the https://github.com/cloudendpoints/esp that only accepts parameters via flags. Even if I set those flags from environment vars, I still need to cycle the pods to get it run the startup command with the new env vars.

[apelisse]

My use case is trying to automate the changing of config for the https://github.com/cloudendpoints/esp that only accepts parameters via flags. Even if I set those flags from environment vars, I still need to cycle the pods to get it run the startup command with the new env vars.

And that's probably the sane thing to do. You want declaratively defined configuration, and your app to behave in a predictable way. The recommended way is to: update the config-map with new options, change its name, change the configmap reference in the deployment to that new name, commit these two files, review that this is a good change, merge and deploy.

PS: This will perform a rolling update, which means that if the configuration happens to be bad, the deployment will stop, and nothing will break, you can safely rollback and fix the config. Updating a file live, even through a configmap, is more risky.

[cbluth]

RE: https://github.com/kubernetes/kubectl/issues/56#issuecomment-333301655
If this is the case, then consider my original issue invalid. I didn't know the changes were instant. I will have to try it out.

[apelisse]

I don't think there is much we can do about it. Also, know that @monopole and @mengqiy are working on a new declarative management tool that would address your problems with updates to configmaps.