<p>By default, a Deployment uses a <code>RollingUpdate</code> strategy, which means new pods spin up before old pods are terminated. This causes problems with RWO volumes, resulting in the error you have reported in your question.</p>
<p>You can modify this behavior by setting <code>spec.strategy.type</code> to <code>Recreate</code>. In this case, old pods are terminated <em>first</em>, before spawning the new pods. This will free up the PVC so that it can bind on a new node.</p>
<p>See <a href="https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#strategy" rel="nofollow noreferrer">here</a> for the official documentation.</p>

CC BY-SA 4.0
2024-12-24T23:00:00.730Z
Sadly, it does not work. The reason might be that the strategy type is only used during pod upgrades. In case of a lost node, something typical is triggered. I cannot explain it more clearly, sorry.
Anyway, thanks for your answer!
Дмитрий Жеребец
CC BY-SA 4.0
2024-12-11T13:27:54.450Z
2024-12-11T13:27:54.450Z
larsks
<p>I have k8s test cluster with 1 master and 2 worker nodes. I created a PersistentVolumeClaim resource using the Hetzner Cloud csi driver. This driver only allows you to create ReadWriteOnce volumes.</p>
<pre><code>apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: metadata
  namespace: development
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: hcloud-volumes
</code></pre>
<p>I also created a Deployment resource with one Pod that uses that volume.</p>
<pre><code>apiVersion: apps/v1
kind: Deployment
...
spec:
  replicas: 1
  selector:
    matchLabels:
      app: app1
  template:
    metadata:
      labels:
        app: app1
    spec:
      containers:
        - name: app1
          image: some-image
          volumeMounts:
            - name: metadata
              mountPath: /mnt/metadata

      volumes:
        - name: metadata
          persistentVolumeClaim:
            claimName: metadata
</code></pre>
<p>Overall everything works great. The pod was tied to a specific node to which the volume was assigned (for example worker-2). The problems start when I turn off worker-2. Deployment resources tries to recreate the pod on another node (worker-1), but gets stuck in deadlock, since the PersistentVolumeClaim is busy with the old pod. Specific error: <em><strong>Multi-Attach error for volume &quot;pvc-f587e0c2-25f1-4792-815e&quot; Volume is already used by pod(s) app1-5f9c445458</strong></em></p>
<p>Is there any way I can make a volume automatically unmount from a pod using this volume type? I would like to have a deployment resource that can easily migrate a pod from one node to another, along with its associated volumes.</p>

<kubernetes><persistent-volumes>
Automatic volume migration following the pod
Дмитрий Жеребец
# Automatic volume migration following the pod

(Asked by: username_0 on 2024-12-08)

I have k8s test cluster with 1 master and 2 worker nodes. I created a PersistentVolumeClaim resource using the Hetzner Cloud csi driver. This driver only allows you to create ReadWriteOnce volumes.
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: metadata
  namespace: development
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: hcloud-volumes

I also created a Deployment resource with one Pod that uses that volume.
apiVersion: apps/v1
kind: Deployment
...
spec:
  replicas: 1
  selector:
    matchLabels:
      app: app1
  template:
    metadata:
      labels:
        app: app1
    spec:
      containers:
        - name: app1
          image: some-image
          volumeMounts:
            - name: metadata
              mountPath: /mnt/metadata

      volumes:
        - name: metadata
          persistentVolumeClaim:
            claimName: metadata

Overall everything works great. The pod was tied to a specific node to which the volume was assigned (for example worker-2). The problems start when I turn off worker-2. Deployment resources tries to recreate the pod on another node (worker-1), but gets stuck in deadlock, since the PersistentVolumeClaim is busy with the old pod. Specific error: Multi-Attach error for volume "pvc-f587e0c2-25f1-4792-815e" Volume is already used by pod(s) app1-5f9c445458
Is there any way I can make a volume automatically unmount from a pod using this volume type? I would like to have a deployment resource that can easily migrate a pod from one node to another, along with its associated volumes.

**Tags:** kubernetes, persistent-volumes


---

## 1 answers

### Answer by username_1 on 2024-12-11. Score: 0

By default, a Deployment uses a `RollingUpdate` strategy, which means new pods spin up before old pods are terminated. This causes problems with RWO volumes, resulting in the error you have reported in your question.

You can modify this behavior by setting `spec.strategy.type` to `Recreate`. In this case, old pods are terminated *first*, before spawning the new pods. This will free up the PVC so that it can bind on a new node.

See [here](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#strategy) for the official documentation.

> **Comments:**
> **username_0**: Sadly, it does not work. The reason might be that the strategy type is only used during pod upgrades. In case of a lost node, something typical is triggered. I cannot explain it more clearly, sorry. Anyway, thanks for your answer!  

---

