<p>After learning that we should have used a <code>StatefulSet</code> instead of a <code>Deployment</code> in order to be able to attach the same persistent volume to multiple pods and especially pods on different nodes, I tried changing our config accordingly.</p>

<p>However, even when using the same name for the volume claim as before, it seems to be creating an entirely new volume instead of using our existing one, hence the application loses access to the existing data when run as a <code>StatefulSet</code>.</p>

<p>Here's the volume claim part of our current <code>Deployment</code> config:</p>

<pre><code>apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: gitea-server-data
  labels:
    app: gitea
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 20Gi
</code></pre>

<p>This results in a claim with the same name.</p>

<p>And here's the template for the <code>StatefulSet</code>:</p>

<pre><code>  volumeClaimTemplates:
    - metadata:
        name: gitea-server-data
        labels:
          app: gitea
      spec:
        accessModes:
        - ReadWriteOnce
        resources:
          requests:
            storage: 20Gi
</code></pre>

<p>This results in new claims for every pod, with the pod name and an ID per claim, like e.g. <code>gitea-server-data-gitea-server-0</code>.</p>

<p>The new claims are now using a new volume instead of the existing one. So I tried specifying the existing volume explicitly, like so:</p>

<pre><code>  volumeClaimTemplates:
    - metadata:
        name: gitea-server-data
        labels:
          app: gitea
      spec:
        accessModes:
          - ReadWriteOnce
        volumeName: pvc-c87ff507-fd77-11e8-9a7b-420101234567
        resources:
          requests:
            storage: 20Gi
</code></pre>

<p>However, this results in pods failing to be scheduled and the new claim being "pending" indefinitely:</p>

<blockquote>
  <p>pod has unbound immediate PersistentVolumeClaims (repeated times)</p>
</blockquote>

<p>So the question is: how can we migrate the volume claim(s) in a way that allows us to use the existing persistent volume and access the current application data from a new <code>StatefulSet</code> instead of the current <code>Deployment</code>?</p>

<p>(In case it is relevant, we are using Kubernetes on GKE.)</p>

<p>OK, so I spent quite some time trying out all kinds of different configs until finally learning that GCE persistent disks simply don't support <code>ReadWriteMany</code> to begin with.</p>

<p>The <a href="https://cloud.google.com/kubernetes-engine/docs/concepts/persistent-volumes" rel="nofollow noreferrer">GKE docs</a> go out of their way to never explicitly mention that you cannot actually mount <em>any</em> normal GKE persistent volume on multiple pods/nodes.</p>

<p>Apparently, the only way to get shared file storage between pods is to deploy either your own NFS/Gluster/etc. or to cough up a bunch of money and <a href="https://cloud.google.com/filestore/docs/accessing-fileshares" rel="nofollow noreferrer">use Google Cloud Filestore</a>, for which there is a GKE storage class, and which can indeed be mounted on multiple pods.</p>

<p>Unfortunately, that's not an option for this app, as Filestore pricing begins with 1TB minimum capacity at a whopping $0.20/GB/month, which means that <strong>the cheapest option available costs around $205 per month</strong>. We currently pay around $60/month, so that would more than triple our bill, simply to get rolling deployments without errors.</p>
