Durable Volumes
1. Durable Volumes
Along with ephemeral Volume types, Kubernetes offers a durable Volume type: PersistentVolume. The PersistentVolume abstraction has two components: PersistentVolume, or PV, and PersistentVolumeClaim, or PVC. Let’s define both, starting with PersistentVolume. PersistentVolume is a type of storage that can be used to store data that needs to be kept even if the Pod or node that the data is stored on is restarted or fails. This is in contrast to ephemeral storage, which is only available while the Pod or node is running. PersistentVolumes are typically used to store data that is important to the application, such as databases, file systems, and configuration files. That brings us to a PersistentVolumeClaim, or PVC, which represents a request for storage resources. It’s a way for users to request storage that can be used by Pods to store data that needs to persist across Pod restarts or node failures. A PVC specifies the desired characteristics of the storage, such as the size, access mode, and storage class. When a Pod requests a PVC, the Kubernetes controller matches the PVC to an available PersistentVolume that meets the requirements of the PVC. Once a PersistentVolume is matched to a PVC, the Pod can mount the PersistentVolume and access the storage. Application developers can claim and use provisioned storage using PersistentVolumeClaims without creating and maintaining storage volumes directly. This allows for the separation of roles, as it’s the job of administrators to make persistent volumes available, and the job of developers to use those volumes in applications. Now let’s shift focus and explore how to create a PersistentVolume manifest. The first task is to specify the StorageClassName, which is a resource used to implement PersistentVolumes. When you define a PVC in a Pod, the PVC uses the StorageClassName. This means that the PV StorageClassName must match the PVC StorageClassName if you want the claim to be successful. The next step is to decide if you want to use the Compute Engine Standard Persistent Disk type. If so, GKE has a default StorageClass name ‘standard’ that can be used. The persistent disk must be created first, or you will encounter an error. With GKE clusters, a PVC with no defined StorageClass will use this default StorageClass, and it will provide storage by using a standard Persistent Disk. From there, specify volume capacity, which is the storage capacity required for your PersistentVolume. However, if you want to use an SSD persistent disk, create a new StorageClass, and give it an appropriate name, such as “SSD”. In the parameters section, define the type as pd-ssd. Remember, A PVC that uses this new StorageClass named SSD will only use a PV that also has a StorageClass named SSD. And when a new storage class is created, it can be viewed in the Cloud Console. Now it’s important to note that Kubernetes StorageClass and Google Cloud Storage classes are not the same thing. Google Cloud Storage provides object storage for the web, whereas Kubernetes StorageClasses are choices for how PersistentVolumes are backed. Then there are AccessModes. AccessModes in PersistentVolumes define how Pods can mount and access the storage provided by the PV. They determine the level of access and the number of Pods that can simultaneously mount the PV. There are different types of AccessModes. With ReadWriteOnce, the PV can be mounted read-write by a single Node in the cluster. This means that any Pod running on that Node can access the PV for reading and writing. For most applications, persistent disks are mounted as ReadWriteOnce. With ReadOnlyMany, the PV can be mounted read-only by multiple nodes simultaneously. This means that Pods running on these nodes can only read data from the PV, not write to it. And with ReadWriteMany, the PV can be mounted read-write by multiple nodes simultaneously. Pods running on these nodes can both read and write data to the PV. However, Google Cloud persistent disks do not support ReadWriteMany. Persistent Volumes can also be created from a YAML manifest by using a kubectl apply command. For example, let’s say there is a PV named pd-volume that will have 100 GB of storage allocated and will allow ReadWriteOnce access. It will use a standard Persistent Disk based on the storageClassName, and it will be maintained by cluster administrators. Remember, PersistentVolumes can’t be added to Pod specifications directly. Instead, PersistentVolumeClaims must be used. In order for this PersistentVolumeClaim to claim the PersistentVolume, their storageClassNames and accessModes must match. Also, the amount of storage requested in a PersistentVolumeClaim must be within a PersistentVolume’s storage capacity. Otherwise, the claim will fail. Now let’s explore what happens when a PersistentVolumeClaim is added to a Pod. When this Pod is started, GKE will look for a matching PV with the same storageClassName, accessModes, and sufficient capacity. The specific cloud implementation doesn’t really matter, because the specific storage that is used to deliver this storage class is controlled by the cluster administrators, not the application developers. But what if application developers claim more storage than has already been allocated to PersistentVolumes? If there isn’t an existing PersistentVolume to satisfy the PersistentVolumeClaim, Kubernetes will try to provision a new one dynamically. By default, Kubernetes will try to dynamically provision a PersistentVolume if the PersistentVolumeClaim’s storageClassName is defined and an appropriate PV does not already exist. If a matching PersistentVolume already exists, Kubernetes will bind it to the claim. If storageClassName is omitted, the PersistentVolumeClaim will use the default StorageClass, which, in GKE, is named “standard.” Dynamic provisioning will only work in this case if it is enabled on the cluster. GKE manages all of this. The application owner does not have to provision the underlying storage, and does not need to embed the details of the underlying storage into the Pod manifest. Deleting the PersistentVolumeClaim will also delete the provisioned PersistentVolume. So, if you want to retain the PersistentVolume, set its persistentVolumeReclaimPolicy to Retain in the YAML file. PersistentVolumeClaims should be deleted when their underlying PersistentVolume is no longer required.2. Let's practice!
Create Your Free Account
or
By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.