The course is part of these learning paths
Course Introduction and Overview
Production and Course Conclusion
This course provides an introduction to how to use the Kubernetes service to deploy and manage containers.
Be able to recognize and explain the Kubernetes service
Be able to explain and implement a Kubernetes container
Be able to orchestrate and manage Kubernetes containers
This course requires a basic understanding of cloud computing. We recommend completing the Google Cloud Fundamentals course before completing this course.
Hello, and welcome back to the Introduction to Kubernetes course for Cloud Academy. I'm Adam Hawkins, and I'm your instructor for this lesson.
The previous lessons covered probes and init containers. This lesson covers different ways Kubernetes handles non-ephemeral data, separating data from containers, Kubernetes Volumes, and Kubernetes PersistentVolumes. Our goal for this lesson is to deploy the data tier from our sample application with a PersistentVolume for the Redis data. Again, this lesson builds on the code from the previous lessons. I suggest you re-watch the previous lesson before diving in here. Anyways, lets get going by discussing K8s' approach to persistent data.
Kubernetes includes two different data storage types. One type is dependent on a particular pod, and the other is independent from pods. We're focusing on the latter. Volumes are tied to a pod and their lifecycle. Volumes are used to share data between containers in a pod. The volume is then deleted when the pod is deleted. PersistentVolumes are independent from pods. They work a little bit differently. Pods may claim a volume, and use it throughout their lifetime. PersistentVolumes will continue to exist outside of their pods. Given that they may be reused, K8s includes features for how to handle data in a PersistentVolume when the claim is released. Both volumes and PersistentVolumes may be backed by various methods like Google Cloud Platform persistent disks, Azure Disks, or others. We'll use a PersistentVolume for the sample applications data tier. Volumes are less complicated than PersistentVolumes. Truthfully, volumes are actually a subset of PersistentVolumes. So you may explore using volumes on your own after this lesson. Time to head over the terminal and to create some volumes.
Start by creating a new lesson 204 namespace just like we've done in the past lessons. Now, onto the PersistentVolume. Create a new data-tier-volume.yml file with your editor. There are three parts to this example. First, create a PersistentVolume. This is the raw storage for use in pods. It has a defined storage capacity and other attributes. Here, we've allocated 128 megabytes. PersistentVolumes may have multiple access modes. This controls how pods may actually use the volume. ReadWriteOnce means this volume may be mounted for reading and writing by a single pod at a time. There are other access modes for other use cases. Refer to the documentation for the complete list. The persistentVolumeReclaimPolicy sets the behavior when the claim is released. Retain keeps the data. Using recycle clears the data. HostPath defines a local directory on the node for this volume. This driver should only be used on a single node cluster. This is okay for us since we're using Minikube. Remember, you should not use this in production. This is really only for demos.
Second, the volume must be claimed. We need a pod to claim the volume. I suggest you have associated Kubernetes resource types together in the same YAML file. YAML supports specifying multiple route objects in the same file but you have a triple dash separator. The kubectl command is smart enough to know to create multiple things when this happens. The simplest PersistentVolume claim requires setting the access modes and storage requests. We'd request a ReadWriteOnce volume with at least 128 megabytes of capacity. Claims are like resource requests. Pods will fail to schedule if the cluster cannot supply the volume claims.
Third, add a volume to the pod. The volumes key is added to the spec template. Pods may have multiple volumes, but we only need one here. Give the volume a name. Volumes may come from multiple drivers. The data volume comes from the PersistentVolume claim driver in this case. The claim name matches the PersistentVolume claim name.
Finally, add a volumeMounts entry matching the volume name and target path. We've used flash data because the official Redis image uses that for persistent storage. Create the new data-tier-deployment in the correct namespace, and then get the deployments.
Everything is up and running. Let's muck with the data and the pods to see what happens. We'll exec into the running Redis container and set a key, using the Redis CLI. Then, we'll kill the pod. If it all goes according to plan, the deployment will create a new pod. Then, the containers in the new pod will mount the volume with the previous data. Next, we can exec into the new container and retrieve the previous data. Voila. We get the same data back. It's nice when these sort of things just work exactly as you expect.
This concludes our short lesson on persistent storage. We've covered volumes, PersistentVolumes, and PersistentVolumeClaims. We've also created an independent storage device for use with our pods. We've mounted a volume in the Redis pod to persist data. We've used kubectl exec to run commands in existing containers. We've also learned a neat trick for grouping related YAML resources together. There is more to cover on this topic that didn't make it into the lesson. Frankly, the user guides are much better at this than I am. We didn't talk about the different storage DRS or how to use them. I suggest you check back in the user guides for a detailed walkthrough on pod-specific volumes, and also all of the different supported storage drivers or options in the particular use cases.
The next lesson covers two other useful Kubernetes features you should keep in your toolbox. You're almost, almost to the end of the course. Just a few more lessons to go. Keep it up, and I'll catch you in the next one.
About the Author
Adam is backend/service engineer turned deployment and infrastructure engineer. His passion is building rock solid services and equally powerful deployment pipelines. He has been working with Docker for years and leads the SRE team at Saltside. Outside of work he's a traveller, beach bum, and trance addict.