1) Theyre not that hard to lose:
- Provision a PV dynamically after you create a PVC.
- Bind it with a pod. Write important data to it.
- Delete that pvc.
- Poof you might lose your data.
2) Depending on how your app and dynami provisioner behaves, sub directories under your volume might end up on local disk. Yeah.
Example of how to do real world storage
There's no one size fits all solution to the above issues... But I thought I'd paste a real, working PVC config that uses dynamic storage, just as a reference. I'll add more details to this post over time (maybe). For those new to this stuff, ill start with an example just to get vernacular out of the way... First, lets create a PVC in a dynamic environment.
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: crazy
spec:
accessModes:
- ReadWriteOnce
- ReadOnlyMany
resources:
requests:
storage: 1Mi
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
pvc-2e4c58a8-3967-11e8-b64d-42010a8000a2 1Gi RWO,ROX Delete Bound crazy/crazy standard 27m
apiVersion: v1
kind: Pod
metadata:
name: crazy-writer
spec:
volumes:
- name: crazy-vol
persistentVolumeClaim:
claimName: crazy
initContainers:
- name: c0
image: alpine
command: ["mkdir","-p","-m","777","/crazy-vol-mount/i-was-here1"]
volumeMounts:
- name: crazy-vol
mountPath: /crazy-vol-mount
readOnly: false
containers:
- name: c1
image: alpine
volumeMounts:
- name: crazy-vol
mountPath: /crazy-vol-mount
readOnly: false
command: ["touch","/crazy-vol-mount/i-was-here2"]
restartPolicy: Never
Afterwards, you might do something like this, to read those contents in multiple places, in parallel.
So, in the real world, you mount a writer, then maybe you mount multiple readers. You dont ever delete the PVC. The points we've touched on that arent normally addressed in PVC examples:
- readOnly mounts can be done in parallel, all over the place.
- consider provisioning your PVC to support both types : Its usually easy to do that - for example even the most basic GCE Persistent disk supports both types of mounts, as long as you dont do them at the same time.
- remember to clean up your PVCs / delete them when your done chances are when getting started you wont have a sophistcated storageClass setup which prevents overusage for you.
Also, in the real world, you might want subPaths
Given that volumes are complex, the less you have, sometimes, the better. You can use the subPath directive to mount various parts of the same volume to different pods. That way, you can use a simple starting solutoin, like NFS as a multitenant PVC system.
.... Back to the original goal here: which is to simplify the storage workflows that are probably going to be used by normal humans, who dont have industrial strength storage support, i.e. in a new-ish/medium size kubernetes cluster ...
EmptyDir
The data in your emptyDir is, as you probably know, truly ephemeral. There is no setting in the universe that you can set which will change this. But to be honest... your still probably better off using these and backing data up to s3 . I know i sound old school. But its really hard to mess up immutable styles of storage workflows .
PVC with a Delete reclaim policy
You can lose your data permanently if you mess up and delete the PVC.
PVC with a RETAIN reclaim policy
You wont lose your data permanently unless you kill the volume.
PVC with a RETAIN reclaim policy and RWO semantics, on the same node, or with ReadOnly mounts in other nodes at times.
This will give you , for cheap, what most people want for cloud native storage: The ability to read something in one container, write it somewhere else, and so on. However its tricky to implement properly.
PVC with a RETAIN reclaim policy and RWX semantics
This basically gives you, but its expensive, what most people ultimately want with cloud native storage.
No comments:
Post a Comment