Given a Kubernetes cluster with two namespaces; what is the recommended way to monitor and sync differences in configmaps, deployments, ingresses etc. between the namespaces?
Add a comment
|
3 Answers
We are currently investigating https://github.com/roboll/helmfile to easily sync Helm charts across namespaces.
Edit: The deploy script that is described in this answer is very much looks like Helmfile and we are now in the process of upgrading to Helmfile so that we can retire our scripts that run multiple Helm releases as that’s that Helmfile does well.
This is a bit of an alternative and indirect answer. Use infrastructure-as-code best practices to avoid environments getting out of sync. I believe people will find it a helpful alternative suggestion so a valid answer.
Prevention is better than cure. Don't let the namespaces get out of sync by treating your configuration as code and manage it via git. Helm is a package manager for Kubernetes configuration. It can handle arbitrary configuration objects such as Openshift extensions. This let's you setup a deployment pipeline and a git workflow that ensures your environments stay in sync. (Update: use Helmfile to manage multiple Helm releases).
By way of an example in our setup we have a Helm chart that just installs configmaps and another that just installs secrets. The actual values to install are passed in as a parameter like my-app-secret-values.yaml. So we have different yaml values all under git and a deploy script that iterates over them applying the helm chart that loads the values and updates the corresponding configmap or secret. Helm reads, compares, and only writes when something has changed. So the deploy script will result in only changing a secret or config map that has changed in git. All the configuration is under git and managed like code. Syncing configuration between environments can then be managed just like promotion of code. As a bonus helm creates a backup every version of every object it changes stored inside of Kubernetes. If let's you list the prior versions and rollback to a previous configuration. Also as everything is deployed from git all the history of all settings in all namespaces can be seen in git.
We also install and run out main applications as traditional Helm charts that are promoted through environments. Those helm charts reference the configmaps and secrets that are separately deployed when we want to adjust the settings in a given environment.
Heptio has open sourced a tool called Theseus to help with this. There's nothing built in to Kubernetes to do this, but check out the Theseus utility, you should be able to write a script to do this.
