ConfigMap generation and rolling update

I tried to automate the rolling update when the configmap changes are made

It is a good practice to create new resources instead of mutating (update in-place). kubectl kustomize is supporting this workflow:

The recommended way to change a deployment's configuration is to

1. create a new configMap with a new name,
2. patch the deployment, modifying the name value of the appropriate configMapKeyRef field.

You can deploy using Kustomize to automatically create a new ConfigMap every time you want to change content by using configMapGenerator. The old ones can be garbage collected when not used anymore.

Whith Kustomize configMapGenerator can you get a generated name.

Example

kind: ConfigMap
metadata:
  name: example-configmap-2-g2hdhfc6tk

and this name get reflected to your Deployment that then trigger a new rolling update, but with a new ConfigMap and leave the old unchanged.

Deploy both Deployment and ConfigMap using

kubectl apply -k <kustomization_directory>

When handling change this way, you are following the practices called Immutable Infrastructure.

Verify deployment

To verify a successful deployment, you are right. You should use:

kubectl rollout status deployment test-app -n test

and when leaving the old ConfigMap unchanged but creating a new ConfigMap for the new ReplicaSet it is clear which ConfigMap belongs to which ReplicaSet.

Also rollback will be easier to understand since both old and new ReplicaSet use its own ConfigMap (on change of content).

Mounted ConfigMaps are updated automatically reference

To Check roll-out history used below steps

ubuntu@dlv-k8s-cluster-master:~$ kubectl rollout history deployment busybox 
REVISION CHANGE-CAUSE 
1        kubectl create --filename=busybox.yaml --record=true

Update image on deployment as below

$ kubectl set image deployment.app/busybox *=busybox --record 
deployment.apps/busybox image updated

Check new rollout history which will list the new change cause for rollout

$ kubectl rollout history deployment busybox 

REVISION CHANGE-CAUSE 
1        kubectl create --filename=busybox.yaml --record=true 
2        kubectl set image deployment.app/busybox *=busybox --record=true

To Rollback Deployment : use undo flag along rollout command

ubuntu@dlv-k8s-cluster-master:~$ kubectl rollout undo deployment busybox deployment.apps/busybox rolled back 

ubuntu@dlv-k8s-cluster-master:~$ kubectl rollout history deployment busybox 

REVISION CHANGE-CAUSE 
2         kubectl set image deployment.app/busybox *=busybox --record=true 
3         kubectl create --filename=busybox.```

Your command is fine to check if an update went through.

Now, a ConfigMap change eventually gets applied to the Pod. There is no need to do a rolling update for that. Depending on what you have passed in the ConfigMap, you probably could have restarted the service and that's it.

What's the best way to know if the rolling update is successful or not?

To check if you rolling update was executed correctly, you command works fine, you could check also if you replicas is running.

I tried to automate the rolling update when the configmap changes are made.

You could use Reloader to perform your rolling updates automatically when a configmap/secret changed.

Reloader can watch changes in ConfigMap and Secret and do rolling upgrades on Pods with their associated DeploymentConfigs, Deployments, Daemonsets and Statefulsets.

Let's explore how Reloader works in a pratical way using a nginx deployment as exxample.

First install Reloader in your cluster:

kubectl apply -f https://raw.githubusercontent.com/stakater/Reloader/master/deployments/kubernetes/reloader.yaml

You will see a new container named reloader-reloader-... this container is responsible to 'watch' your deployments and make the rolling updates when necessary.

Create a configMap with your values, in my case I'll create a my-config and set a variable called myvar.value with value hello:

kubectl create configmap my-config --from-literal=myvar.value=hello

Now, let's create a simple deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: deployment-example
  labels:
    app: nginx
  metadata:
    annotations:
      configmap.reloader.stakater.com/reload: my-config
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80
        env:
      - name: MYVAR
        valueFrom:
          configMapKeyRef:
            name: my-config
            key: myvar.value

In this example, the nginx image will be used getting the value from my configMap and set in a variable called MYVAR.

To Reloader works, you must specify the name of your configMap in annotations, in the example above it will be:

metadata:
  annotations:
    configmap.reloader.stakater.com/reload: my-config

Apply the deployment example with kubectl apply -f mydeplyment-example.yaml and check the variable from the new pod.

$ kubectl exec -it $(kubectl get pods -l=app=nginx --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}') env | grep MYVAR
MYVAR=hello

Now let's change the value of the variable:

Edit configmap with kubectl edit configmap my-config, change the value of myvar.value to hi, save and close.

After save, Reloader will recreate your container and get the new value from configmap. To check if the rolling update was executed successfully:

kubectl rollout status deployment deployment-example

Check the new value:

$ kubectl exec -it $(kubectl get pods -l=app=nginx --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}') env | grep MYVAR
MYVAR=hi

That's all! Check the Reloader github see more options to use.

I hope it helps!

I think it is fine,

kubectl rollout status deployments/test-app -n test can be used to verify the rollout deployment as well.

As an additional step, you can run,

kubectl rollout history deployments/test-app -n test as well.

if you need further clarity,

kubectl get deployments -o wide and check the READY and IMAGE fields.