I have my application running on google kubernetes engine and currently uses pvc for data storage. I am just not able to decide which storage option should we use PVC or Disk?
In case of PVC we can't have snapshot, apart from this is there any strong reason we should go for disk based storage. what is advisable? In which scenarios we should consider using disks rather than pvc
You are mixing two different yet connected concepts here. Persistent Volume Claim and Volume.
Persistent Volume Claim is not a storage device / service. It is a declaration of need for storage of particular characteristic. In a way, you could say it's an equivalent of an async programming promise. It should at some moment "return" a storage in form of a Persistent Volume that will satisfy declared requirements. You don't know when exactly it will (usualy asap) or if it will at all (error).
Persistent Volume is in turn an instance of a Volume, defined and instantiated with a typical Volume definition (ie. AWS EBS id, NFS server details, GlusterFS etc.).
Volume is the way to define some storage that is not a part of the image/container it self.
Now, the fact that sometimes you can confuse PVC for PV/Volume is that PVs can be automatically created by cloud provider or 3rd party provisioner if it has matching storage class (ie. default, but not only).
In most cases when you need persistent storage for your pod, but you want the declaration to be cluster agnostic, you will use PVC and either depend on automated provisioning, or create matching PV in a way feasible for given infra. For example you can support PVC on dev cluster via hostPath volume, but with a central GlusterFS server on prod.
That said, the question PVC or Disk has no relevance as PVC can actualy be Disk. It's more of a question like "local storage (hostPart or emptyDir) vs network storage (cloud block device, fileserver etc.). And the answer to that question is... "it depends".
If loss of stored data on pod rescheduling is not a problem that maybe local storage is good and fast solution (ie. I would consider it for cache storage) if not... well, then you can't use local storage. But that is going outside of the questions initial boundries.
In the way GKE is currently implemented, a persistent disk is automatically provisioned when you create a PVC. PVC a conceptually different thing from a disk, PersistentVolumeClaim represents a claim on a disk, that are bound to a PersistentVolume, that will be automatically provisioned by your cluster.
Here is an example manifest for a PostgreSQL StatefulSet that uses created PVC, PV and, indirectly, persistent disk.
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: postgres-claim
spec:
storageClassName: ssd
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 50Gi
---
kind: Service
apiVersion: v1
metadata:
name: postgres-service
spec:
selector:
app: postgres
ports:
- protocol: TCP
port: 5432
---
apiVersion: apps/v1beta2
kind: StatefulSet
metadata:
name: postgres-set
spec:
serviceName: postgres-service
replicas: 1
selector:
matchLabels:
app: postgres
updateStrategy:
type: RollingUpdate
template:
metadata:
labels:
app: postgres
spec:
containers:
- name: postgres
image: postgres:10.1-alpine
volumeMounts:
- name: pg-data
mountPath: /var/lib/postgresql/data
env:
- name: POSTGRES_USER
value: wollner
- name: PGDATA
value: /var/lib/postgresql/data/pgdata
volumes:
- name: pg-data
persistentVolumeClaim:
claimName: postgres-claim
As soon as you apply this manifest, a new PVC and a PV are created in your cluster. After that the cluster provisions a new persistent disk that backs the PV. You'll be able to see that with kubectl get pv, where the new PV appears. You'll also see the new disk in gcloud compute instances disks list. By default, if you delete this PVC, the disk will be deleted as well.
