<p>I tried to automate the rolling update when the configmap changes are made. But, I am confused about how can I verify if the rolling update is successful or not. I found out the command </p>

<pre><code>kubectl rollout status deployment test-app -n test
</code></pre>

<p>But I guess this is used when we are performing the rollback rather than for rolling update. What's the best way to know if the rolling update is successful or not?</p>

programmingtech
<h2>ConfigMap generation and rolling update</h2>

<blockquote>
  <p>I tried to automate the rolling update when the configmap changes are made</p>
</blockquote>

<p>It is a good practice to <strong>create new</strong> resources instead of <strong>mutating</strong> (update in-place). <a href="https://kubernetes.io/docs/tasks/manage-kubernetes-objects/kustomization/" rel="nofollow noreferrer">kubectl kustomize</a> is supporting this <a href="https://github.com/kubernetes-sigs/kustomize/blob/master/examples/configGeneration.md" rel="nofollow noreferrer">workflow</a>:</p>

<blockquote>
  <p>The recommended way to change a deployment's configuration is to</p>
  
  <ol>
  <li>create a new configMap with a new name,</li>
  <li>patch the deployment, modifying the name value of the appropriate configMapKeyRef field.</li>
  </ol>
</blockquote>

<p>You can deploy using <a href="https://kubernetes.io/docs/tasks/manage-kubernetes-objects/kustomization/#configmapgenerator" rel="nofollow noreferrer">Kustomize</a> to automatically create a new ConfigMap every time you want to change content by using <a href="https://kubernetes.io/docs/tasks/manage-kubernetes-objects/kustomization/#configmapgenerator" rel="nofollow noreferrer">configMapGenerator</a>. The old ones can be <em>garbage collected</em> when not used anymore.</p>

<p>Whith Kustomize configMapGenerator can you get a generated <em>name</em>.</p>

<p>Example</p>

<pre><code>kind: ConfigMap
metadata:
  name: example-configmap-2-g2hdhfc6tk
</code></pre>

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

<p>Deploy both <code>Deployment</code> and <code>ConfigMap</code> using</p>

<pre><code>kubectl apply -k &lt;kustomization_directory&gt;
</code></pre>

<p>When handling change this way, you are following the practices called <a href="https://www.digitalocean.com/community/tutorials/what-is-immutable-infrastructure" rel="nofollow noreferrer">Immutable Infrastructure</a>.</p>

<h2>Verify deployment</h2>

<p>To verify a successful deployment, you are right. You should use:</p>

<pre><code>kubectl rollout status deployment test-app -n test
</code></pre>

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

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