Restart kubernetes deployment after changing configMap

In addition to kubectl rollout restart deployment, there are some alternative approaches to do this:

1. Restart Pods

kubectl delete pods -l app=wiki

This causes the Pods of your Deployment to be restarted, in which case they read the updated ConfigMap.

2. Version the ConfigMap

Instead of naming your ConfigMap just wiki-config, name it wiki-config-v1. Then when you update your configuration, just create a new ConfigMap named wiki-config-v2.

Now, edit your Deployment specification to reference the wiki-config-v2 ConfigMap instead of wiki-config-v1:

apiVersion: apps/v1kind: Deployment# ...      volumes:      - name: config-templates        configMap:          name: wiki-config-v2

Then, reapply the Deployment:

kubectl apply -f wiki.yaml

Since the Pod template in the Deployment manifest has changed, the reapplication of the Deployment will recreate all the Pods. And the new Pods will use the new version of the ConfigMap.

As an additional advantage of this approach, if you keep the old ConfigMap (wiki-config-v1) around rather than deleting it, you can revert to a previous configuration at any time by just editing the Deployment manifest again.

This approach is described in Chapter 1 of Kubernetes Best Practices (O'Reilly, 2019).

For the specific question about restarting containers after the configuration is changed, as of kubectl v1.15 you can do this:

# apply the config changeskubectl apply -f wiki.yaml# restart the containers in the deploymentkubectl rollout restart deployment wiki-deployment

You should do nothing but change your ConfigMap, and wait for the changes to be applies. The answer you have posted the link is wrong. After a ConfigMap change, it doesn't apply the changes right away, but can take time. Like 5 minutes, or something like that.

If that doesn't happen, you can report a bug about that specific version of k8s.