<p>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? </p>

<p>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</p>

<p>You are mixing two different yet connected concepts here. Persistent Volume Claim and Volume.</p>

<p>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 <strong>promise</strong>. 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).</p>

<p>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.).</p>

<p>Volume is the way to define some storage that is not a part of the image/container it self.</p>

<p>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).</p>

<p>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 <code>hostPath</code> volume, but with a central <code>GlusterFS</code> server on prod.</p>

<p>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".</p>

<p>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.</p>
