<p>I have a deployment which includes a configMap, persistentVolumeClaim, and a service. I have changed the configMap and re-applied the deployment to my cluster. I understand that this change does not automatically restart the pod in the deployment:</p>

<p><a href="https://stackoverflow.com/questions/56954670/configmap-change-doesnt-reflect-automatically-on-respective-pods?noredirect=1&amp;lq=1">configmap change doesn&#39;t reflect automatically on respective pods</a></p>

<p><a href="https://stackoverflow.com/questions/56979319/updated-configmap-yaml-but-its-not-being-applied-to-kubernetes-pods?noredirect=1&amp;lq=1">Updated configMap.yaml but it&#39;s not being applied to Kubernetes pods</a></p>

<p>I know that I can <code>kubectl delete -f wiki.yaml &amp;&amp; kubectl apply -f wiki.yaml</code>. But that destroys the persistent volume which has data I want to survive the restart. How can I restart the pod in a way that keeps the existing volume?</p>

<p>Here's what wiki.yaml looks like:</p>

<pre><code>apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: dot-wiki
spec:
  accessModes:
    - ReadWriteOnce
  volumeMode: Filesystem
  resources:
    requests:
      storage: 4Gi
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: wiki-config
data:
  config.json: |
    {
      "farm": true,
      "security_type": "friends",
      "secure_cookie": false,
      "allowed": "*"
    }
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: wiki-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: wiki
  template:
    metadata:
      labels:
        app: wiki
    spec:
      securityContext:
        runAsUser: 1000
        runAsGroup: 1000
        fsGroup: 1000
      initContainers:
      - name: wiki-config
        image: dobbs/farm:restrict-new-wiki
        securityContext:
          runAsUser: 0
          runAsGroup: 0
          allowPrivilegeEscalation: false
        volumeMounts:
          - name: dot-wiki
            mountPath: /home/node/.wiki
        command: ["chown", "-R", "1000:1000", "/home/node/.wiki"]
      containers:
      - name: farm
        image: dobbs/farm:restrict-new-wiki
        command: [
          "wiki", "--config", "/etc/config/config.json",
          "--admin", "bad password but memorable",
          "--cookieSecret", "any-random-string-will-do-the-trick"]
        ports:
        - containerPort: 3000
        volumeMounts:
          - name: dot-wiki
            mountPath: /home/node/.wiki
          - name: config-templates
            mountPath: /etc/config
      volumes:
      - name: dot-wiki
        persistentVolumeClaim:
          claimName: dot-wiki
      - name: config-templates
        configMap:
          name: wiki-config
---
apiVersion: v1
kind: Service
metadata:
  name: wiki-service
spec:
  ports:
  - name: http
    targetPort: 3000
    port: 80
  selector:
    app: wiki
</code></pre>

<p>In addition to <code>kubectl rollout restart deployment</code>, there are some alternative approaches to do this:</p>

<p><strong>1. Restart Pods</strong></p>

<pre class="lang-sh prettyprint-override"><code>kubectl delete pods -l app=wiki
</code></pre>

<p>This causes the Pods of your Deployment to be restarted, in which case they read the updated ConfigMap.</p>

<p><strong>2. Version the ConfigMap</strong></p>

<p>Instead of naming your ConfigMap just <code>wiki-config</code>, name it <code>wiki-config-v1</code>. Then when you update your configuration, just create a new ConfigMap named <code>wiki-config-v2</code>.</p>

<p>Now, edit your Deployment specification to reference the <code>wiki-config-v2</code> ConfigMap instead of <code>wiki-config-v1</code>:</p>

<pre><code>apiVersion: apps/v1
kind: Deployment
# ...
      volumes:
      - name: config-templates
        configMap:
          name: wiki-config-v2
</code></pre>

<p>Then, reapply the Deployment:</p>

<pre class="lang-sh prettyprint-override"><code>kubectl apply -f wiki.yaml
</code></pre>

<p>Since the Pod template in the Deployment manifest has changed, the reapplication of the Deployment will recreate all the Pods. And the new Pods will use the new version of the ConfigMap.</p>

<p>As an additional advantage of this approach, if you keep the old ConfigMap (<code>wiki-config-v1</code>) around rather than deleting it, you can revert to a previous configuration at any time by just editing the Deployment manifest again.</p>

<p>This approach is described in Chapter 1 of <a href="http://shop.oreilly.com/product/0636920273219.do" rel="noreferrer">Kubernetes Best Practices</a> (O'Reilly, 2019).</p>
