<p>Approach 1 (kubernetes volume is attached to google persistent disk, kubernetes volume claim is attached to kubernetes volume)</p>

<pre><code>apiVersion: v1
kind: PersistentVolume
metadata:
  name: volume-1
spec:
  storageClassName: ""
  capacity:
    storage: 50Gi
  accessModes:
    - ReadWriteOnce
  gcePersistentDisk:
    pdName: pd-test-1
---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: pv-claim-1
spec:
  storageClassName: ""
  volumeName: volume-1
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
</code></pre>

<p>Approach 2 (Kubernetes volume claim is directly attached to google persistent disk)</p>

<pre><code>kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: pv-claim-1
spec:
  volumeName: pd-test-1
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
</code></pre>

<p>Approach 3 (pod directly uses google persistent disk <a href="https://kubernetes.io/docs/concepts/storage/volumes/#gcepersistentdisk" rel="nofollow noreferrer">docs</a>)</p>

<pre><code>apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: k8s.gcr.io/test-webserver
    name: test-container
    volumeMounts:
    - mountPath: /test-pd
      name: test-volume
  volumes:
  - name: test-volume
    # This GCE PD must already exist.
    gcePersistentDisk:
      pdName: my-data-disk
      fsType: ext4
</code></pre>

<p>I'm not sure which method should be used in which scenarios. <br>What is the difference between three approaches and which one should I use if I want to store data on google persistent disks ? </p>

Ankit Deshpande
<p>In order of best to worst approach:</p>

<ul>
<li>Best: Approach 2 - Dynamic Volume Provisioning</li>
<li>Ok: Approach 1 - Pre-provisioned volumes via <code>PersistentVolumeClaim</code></li>
<li>Worst: Approach 3 - Direct reference of disk via pod <em>without</em> <code>PersistentVolumeClaim</code></li>
</ul>

<p>Approach 3 is the worst because you lose portability. If you move your pod to a Kubernetes cluster where GCE PD isn't available you will have to modify your pod with whatever type of storage is available on the new cluster. You should not use this approach.</p>

<p>With both Approach 1 &amp; 2 your <code>Pod</code> and <code>PersistentVolumeClaim</code> objects remain portable and do not contain cluster specific details in them.</p>

<p>Use Approach 1 (manually creating both <code>PersistentVolumeClaim</code> and <code>PersistentVolume</code>) if you already have an existing disk that you want to use with Kubernetes. First you create a <code>PersistentVolume</code> object to represent the disk in Kubernetes, then you create a <code>PersistentVolumeClaim</code> to bind to it and act as a pointer that you can use in your Pod. You have to be careful to make sure the objects point to each other, see <a href="https://stackoverflow.com/a/34323691/5443528">https://stackoverflow.com/a/34323691/5443528</a> for details on how to do this. This is the approach you should use for <em>existing</em> GCE PDs.</p>

<p>Approach 2 (manually create a <code>PersistentVolumeClaim</code> and let system automatically create a <code>PersistentVolume</code>). If your storage system supports Kubernetes dynamic volume provisioning, you just create a <code>PersistentVolumeClaim</code> object and your storage system will automatically create a new volume. Kubernetes on GCE and GKE has a default StorageClass installed for GCE PD, so this should work out of the box, and this is the approach you should use to create and use <em>new</em> GCE PDs.</p>

<p>See <a href="https://www.youtube.com/watch?v=uSxlgK1bCuA" rel="noreferrer">https://www.youtube.com/watch?v=uSxlgK1bCuA</a> for details on all of this.</p>
