In our Previous posts, we have seen about various scenarios about how to troubleshooting Kubernetes errors, Today, will see about How to troubleshoot Kubernetes PVC with Basics and how to create a PV and PVC.
In Kubernetes, there are separate mechanisms for managing compute resources and storage resources. A storage volume is a construct that allows Kubernetes users and administrators to gain access to storage resources, while abstracting the underlying storage implementation.
Kubernetes provides two API resources that allow pods to access persistent storage:
1. PersistentVolume (PV)
A PV represents storage in the cluster, provisioned manually by an administrator, or automatically using a Storage Class. A PV is an independent resource in the cluster, with a separate lifecycle from any individual pod that uses it. When a pod shuts down, the PV remains in place and can be mounted by other pods. Behind the scenes, the PV object interfaces with physical storage equipment using NFS, iSCSI, or public cloud storage services.
2. PersistentVolumeClaim (PVC)
A PVC represents a request for storage by a Kubernetes user. Users define a PVC configuration and apply it to a pod, and Kubernetes then looks for an appropriate PV that can provide storage for that pod. When it finds one, the PV “binds” to the pod.
PVs and PVCs are analogous to nodes and pods. Just like a node is a computing resource, and a pod seeks a node to run on, a PersistentVolume is a storage resource, and a PersistentVolumeClaim seeks a PV to bind to.
The PVC is a complex mechanism that is the cause of many Kubernetes issues, some of which can be difficult to diagnose and resolve. In this post, let’s see the most common issues and basic strategies for troubleshooting them.
Persistent Volume and Claim Lifecycle
PVs and PVCs follow a lifecycle that includes the following stages:
- Provisioning: a PV can be provisioned either manually, via an administrator, or dynamically, based on pre-configured PVCs.
- Binding: when a user applies a PVC to a pod, Kubernetes searches for a PV with the required amount of storage and other requested storage criteria, and binds it exclusively to the pod.
- Using: at this stage, the bound PV is reserved for a specific pod.
- Storage Object in Use Protection: this is a feature that protects data when PVCs bind to PVs, to avoid data loss when a PVC is removed.
- Reclaiming: when users do not need a PV anymore, they can delete the PVC object. Once the claim has been released, the cluster uses it’s reclaim policy to determine what to do with the PV — retain, recycle, or delete it.
- Retain: this status enables PVs to be manually reclaimed. The PV continues existing without binding to any PVC. However, because it still includes data belonging to the previous user, it needs to be manually configured and cleaned before reuse.
- Delete: this status enables the cluster to remove the PV object, and disassociate from storage resources in the external infrastructure. This is the default for dynamically provisioned PVs.
How to Create a PersistentVolumeClaim (PVC) and Bind to a PV
Let’s quickly check how PVs and PVCs work. It is based on the full PV tutorial in the Kubernetes documentation.
1. Setting Up a Node
To use this tutorial, set up a Kubernetes cluster with only one node. Ensure your kubectl command line can communicate with the control plane. On the node, create a directory as follows:
# sudo mkdir /mnt/data
Within the directory, create an
2. Creating PersistentVolume
Let’s create a YAML file defining a PersistentVolume:
Run the following command to create the PersistentVolume on the node:
# kubectl apply -f https://k8s.io/examples/pods/storage/pv-volume.yaml
3. Creating PersistentVolumeClaim and Bind to PV
Now, let’s create a PersistentVolumeClaim that requests a PV with the following criteria, which match the PV we created earlier:
- Storage volume of at least 3 GB
- Enables read-write access
Continue Reading on How to Troubleshoot Kubernetes PVC — FoxuTech