Manually configuring mounts for containers to various network storage platforms and services is tedious and time consuming. OpenShift and Kubernetes provides a rich library of volume plugins that allow authors of containerized applications (Pods) to declaratively specify what the storage requirements for the containers are so that OpenShift can dynamically provision and allocate the storage assets for the specified containers. As the author of the Kubernetes Persistent Volume specification, I will provide an overview of how Persistent Volume plugins work in OpenShift, demo block storage and file storage volume plugins and close with the Red Hat storage roadmap.
Presented at LinuxCon/ContainerCon by Mark Turansky, Principal Software Engineer, Red Hat
Mark Turansky is a Principal Software Engineer at Red Hat and a full-time contributor to the Kubernetes Project. Mark is the author of the Kubernetes Persistent Volume specification and a member of the Red Hat OpenShift Engineering team.
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
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
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
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