K
Q

GCE Kubernetes: Persistent disk and Persistent Volume claim

1/15/2019

Approach 1 (kubernetes volume is attached to google persistent disk, kubernetes volume claim is attached to kubernetes volume)

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

Approach 2 (Kubernetes volume claim is directly attached to google persistent disk)

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

Approach 3 (pod directly uses google persistent disk docs)

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

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

-- Ankit Deshpande
gce-persistent-disk
google-compute-engine
kubernetes

Similar Questions

Accessing spring boot controller endpoint in kubernetes pod
kubelet logs flooding even after pods deleted
kubectl exec -it - kill the process
Kubernetes: How to increase ephemeral-storage

1 Answer

1/18/2019

In order of best to worst approach:

  • Best: Approach 2 - Dynamic Volume Provisioning
  • Ok: Approach 1 - Pre-provisioned volumes via PersistentVolumeClaim
  • Worst: Approach 3 - Direct reference of disk via pod without PersistentVolumeClaim

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.

With both Approach 1 & 2 your Pod and PersistentVolumeClaim objects remain portable and do not contain cluster specific details in them.

Use Approach 1 (manually creating both PersistentVolumeClaim and PersistentVolume) if you already have an existing disk that you want to use with Kubernetes. First you create a PersistentVolume object to represent the disk in Kubernetes, then you create a PersistentVolumeClaim 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 https://stackoverflow.com/a/34323691/5443528 for details on how to do this. This is the approach you should use for existing GCE PDs.

Approach 2 (manually create a PersistentVolumeClaim and let system automatically create a PersistentVolume). If your storage system supports Kubernetes dynamic volume provisioning, you just create a PersistentVolumeClaim 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 new GCE PDs.

See https://www.youtube.com/watch?v=uSxlgK1bCuA for details on all of this.

-- Saad Ali
Source: StackOverflow