CODEWITHSUNDEEP
kubernetesgoogle-kubernetes-enginepersistent-volumeskubernetes-pvc
rakeshz
rakeshz

Reputation: 377

GKE PVC vs Disk

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

Upvotes: 2

Views: 3502

Answers (2)

Radek 'Goblin' Pieczonka
Radek 'Goblin' Pieczonka

Reputation: 22884

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.

Upvotes: 6

Max Desiatov
Max Desiatov

Reputation: 5565

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.

Upvotes: 3

Related Questions