Answers: <p><strong>Edit</strong>: The deploy script that is described in this answer is very much  looks like <a href="https://github.com/roboll/helmfile" rel="nofollow noreferrer">Helmfile</a>  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. </p>
  
  <p>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.</p>
  
  <p>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. <a href="https://helm.sh" rel="nofollow noreferrer">Helm</a> 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). </p>
  
  <p>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 <code>my-app-secret-values.yaml</code>. 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. </p>
  
  <p>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.</p>
  
Answers: CC BY-SA 4.0
Answers: 2018-10-31T18:32:25.327Z
Answers: 2018-12-30T09:09:07.210Z
Answers: 2018-12-30T09:09:07.210Z
Answers: simbo1905
Answers: <p>We are currently investigating <a href="https://github.com/roboll/helmfile" rel="nofollow noreferrer">https://github.com/roboll/helmfile</a> to easily sync Helm charts across namespaces.</p>
  
Answers: CC BY-SA 4.0
Answers: 2018-11-02T16:46:27.033Z
Answers: 2018-12-11T14:19:22.663Z
Answers: 2018-12-11T14:19:22.663Z
Answers: user3233089
Answers: <p>Heptio has open sourced a tool called <a href="https://github.com/heptiolabs/theseus" rel="nofollow noreferrer">Theseus</a> 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.</p>
  
Answers: CC BY-SA 4.0
Answers: 2018-10-31T02:55:20.860Z
Answers: 2018-10-31T02:55:20.860Z
Answers: marcc
Body: <p>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?</p>
  
Tags: <kubernetes><orchestration>
Title: What is the recommended way to monitor differences between multiple Kubernetes namespaces/clusters?
UserDisplayName: user3233089
ThreadText: # What is the recommended way to monitor differences between multiple Kubernetes namespaces/clusters?
  
  (Asked by: username_0 on 2018-08-01)
  
  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?
  
  **Tags:** kubernetes, orchestration
  
  
  ---
  
  ## 3 answers
  
  ### Answer by username_1 on 2018-10-31. Score: 2
  
  **Edit**: The deploy script that is described in this answer is very much looks like [Helmfile](https://github.com/roboll/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](https://helm.sh) 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.
  
  
  ---
  
  ### Answer by username_0 on 2018-11-02. Score: 2
  
  We are currently investigating <https://github.com/roboll/helmfile> to easily sync Helm charts across namespaces.
  
  
  ---
  
  ### Answer by username_2 on 2018-10-31. Score: 1
  
  Heptio has open sourced a tool called [Theseus](https://github.com/heptiolabs/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.
  
  
  ---
  
  