The document discusses managing persistent storage in Kubernetes and OpenShift, focusing on key components like PersistentVolume (PV) and PersistentVolumeClaim (PVC). It outlines the goals, lifecycle, and the different types of persistent volumes available, along with the distinction between pets and cattle in storage management. The document also emphasizes the importance of robust security, scalability, and dynamic provisioning in future storage solutions.

1. Persistent Storage
w/ Kubernetes & OpenShift
© 2015
Mark Turansky - mturansk@redhat.com

2. Red Hat and Kube
Stuff we’ve built
● Storage
● Secrets
● Quotas
● Limit Ranges
● Deployments
● … and more
Stuff we contribute to
● lots of API server
● Networking
● Auth & Authz
● Security contexts
● Scalability
● … and more

3. OpenShift and Kube
Stuff we add around Kube
● Automatic Builds & Deployments
● Application Templates
● STI (Source-to-image) builder
● Tons of RH approved/tested images
● Red Hat’s standard of excellence and support for
open source technology

4. Managing compute != managing storage

5. Pets vs. Cattle
Pets
● Have names and identity
● You care about them
● You nurse them back to
health when sick
Cattle
● Have numbers
● Are just like other cattle
● You don’t care about them
● You get a new ones

6. Persistent Storage
Goals
● Allow admins to describe storage
● Allow users to request storage
● No tight coupling to any disk, server, network,
or storage device

7. Two API objects
PersistentVolume (PV)
PersistentVolumeClaim (PVC)

8. PersistentVolume
● A PV is a real piece of networked storage in the cluster
provisioned by an administrator.
● PVs are resources like nodes are resources
● Long lifecycle independent of any pod

9. Persistent Volume
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv0003
spec:
capacity:
storage: 5Gi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Recycle
nfs:
path: /tmp
server: 172.17.0.2

10. Persistent Volume Claim
● A request for storage by a user
● Allows specific resource requests (e.g, size, access modes)
● Used like a claim check

11. Persistent Volume Claim
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: myclaim
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 3Gi

12. Storage Lifecycle
● Provisioning
● Binding
● Using
● Releasing
● Reclaiming

13. Provisioning
● Dynamic
● Scripted
● Manual

14. Binding
● Claims matched to volumes
● Always more, never less
● Claim can be unbound indefinitely

15. Using a claim check
kind: Pod
apiVersion: v1
metadata:
name: mypod
labels:
name: frontendhttp
spec:
containers:
- name: myfrontend
image: nginx
ports:
- containerPort: 80
name: "http-server"
volumeMounts:
- mountPath: "/var/www/html"
name: mypd
volumes:
- name: mypd
persistentVolumeClaim:
claimName: myclaim
* Claims and Pods must be
in the same namespace!

16. Re-use your claim
$ oc delete pod mypod
● Deleting a pod does not delete your claim
● Re-use your claim in another pod

17. Releasing
$ oc delete pvc myclaim
● Delete your claim to release your storage
● Volume is “released” but not available for another claim
● Recycling policy can scrub the volume to clean previous
claimant’s data

18. Reclaiming
● Reclaim policy per volume
● Scrubbing is configurable (PR #9870)
● Delete/Recreate via dynamic provisioning
● PVs are “Retain” by default and can be manually reclaimed

19. Types of persistent volumes
● GCEPersistentDisk
● AWSElasticBlockStore
● NFS
● Glusterfs
● iSCSI
● RBD (Ceph block device)
● HostPath (for testing)
● Fiber Channel
● Cephfs
● Cinder & Manila

20. Demo!
Wordpress + MySQL
Both require persistent storage
https://github.com/openshift/origin/tree/master/examples/wordpress

21. Roadmap
● Robust security between pods, volumes, and containers
● Scalable storage and nominal services
● Dynamic provisioning

22. https://github.com/openshift/origin
Red Hat & Project Atomic
swag and raffles and smart people
Booth #310
github: markturansky
irc: markturansky
#openshift-dev
#google-containers