I have a devops pipeline divided in three steps:

• kubectl apply -f configmap.yml
• kubectl apply -f deployment.yml
• kubectl rollout restart deployment/test-service

I think that when the configmap.yml changes the rollout restart step is useful. But when only the deployment.yml changes, I'm worried that the "extra" rollout restart step is not useful and should be avoided.

Should I execute rollout restart only when the configmap.yml changes or should I don't care about?

CodePudding user response：

This isn't a direct answer, but it ended up being too long for a comment and I think it's relevant. If you were to apply your manifests using kustomize (aka kubectl apply -k), then you get the following behavior:

• ConfigMaps are generated with a content-based hash appended to their name
• Kustomize substitutes the generated name into your Deployment
• This means the Deployment is only modified when the content of the ConfigMap changes, causing an implicit re-deploy of the pods managed by the Deployment.

This largely gets you the behavior you want, but it would require some changes to your deployment pipeline.

CodePudding user response：

Best practice is to annotate the deployment's pod with the hash of the configmap. If the content of the configmap changes, the annotation changes and all pods will be rolling updated. If the configmap doesn't change, nothing will happen.

E.g. with helm:

annotations:
  checksum/config: {{ include (print .Template.BasePath "/configmap.yaml") . | sha256sum }}

from grafana example.

If you're not using helm you can have a script create the hash in your pipeline.

By that the rollout restart step is not required anymore. Pods will restart always if the configmap and/or the deployment changes. Otherwise nothing happens.

CodePudding user response：

Not sure you are injecting the configmap to deployment. If you have mounted to the volume you don't need the rollout restart at all. It will get updated automatically. If using subpath it won't update the configmap automatically.

Read my article : Update configmap without restarting POD

Now if you can put a condition if there is any change in configmap it should rollout in pipeline thn well and good.

There is no need if any change in deployment.yaml it will auto rollout new containers without that's the default behavior of deloyment.