Answers: <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>
  
Answers: CC BY-SA 4.0
Answers: 2024-12-24T23:00:00.730Z
Answers: 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!
Answers: Дмитрий Жеребец
Answers: CC BY-SA 4.0
Answers: 2024-12-11T13:27:54.450Z
Answers: 2024-12-11T13:27:54.450Z
Answers: larsks
Body: <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>
  
Tags: <kubernetes><persistent-volumes>
Title: Automatic volume migration following the pod
UserDisplayName: Дмитрий Жеребец
ThreadText: # 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!  
  
  ---
  
  