eG Monitoring
 

Measures reported by KuberVolumeTest

A PersistentVolume (PV) is a piece of storage in the cluster that has been provisioned by an administrator or dynamically provisioned using Storage Classes. It is a resource in the cluster just like a node is a cluster resource. PVs are volume plugins like Volumes, but have a lifecycle independent of any individual pod that uses the PV. A PersistentVolumeClaim (PVC) is a request for storage by a user. It is similar to a pod. Pods consume node resources and PVCs consume PV resources. Pods can request specific levels of resources (CPU and Memory). Claims can request specific size and access modes (e.g., can be mounted once read/write or many times read-only). Typically, a user creates a PersistentVolumeClaim with a specific amount of storage requested and with certain access modes. A control loop in the master watches for new PVCs, checks if any static PV (a PV manually created by the administrator) matches the new PVC, and binds them together. When none of the static PVs the administrator created matches a user's PVC, the cluster may try to dynamically provision a volume specially for the PVC. If a PV was dynamically provisioned for a new PVC, the loop will always bind that PV to the PVC. Claims will remain unbound indefinitely if a matching volume does not exist. Claims will be bound as matching volumes become available. For example, a cluster provisioned with many 50Gi PVs would not match a PVC requesting 100Gi. The PVC can be bound when a 100Gi PV is added to the cluster.

When a user is done with their volume, they can delete the PVC objects from the API which allows reclamation of the resource.

If there are many unfulfilled PVCs, an administrator may quickly want to check the status of the existing PVs to determine why they could not be bound to any of the PVCs - is it because the PVs are already bound? is it because the PVs have been released, but cannot be reclaimed? or has reclamation failed for many PVs? The Kube Persistent Volumes test provides answers to these questions!

This test auto-discovers PVs and reports the bind status of each PV, thereby pointing administrators to those PVs that are unbound, bound, or released, and those that could not be reclaimed. This way, administrators can figure out if the bind/reclamation status of a PV is why it could not be bound to a PVC. Also, if there are one/more available/unbound PVs, then administrators can use this test to verify the configuration - i.e., the access mode and storage capacity - of such PVs. This will reveal if those PVs are unbound because their configuration does not match any open PVC.

Outputs of the test:One set of results for each Persistent Volume in the Kubernetes cluster being monitored.

The measures made by this test are as follows:

Measurement Description Measurement Unit Interpretation
Status Indicates the current status of this PV.   This measure can report any of the following values:

  • Available: A free resource that is yet bound to a claim

  • Bound: The volume is bound to a claim

  • Released: The claim has been deleted, but the resource is not reclaimed by the cluster. This depends upon the reclaim policy of the PV. For instance, if the reclaim policy is Retain, then the cluster will not automatically reclaim the resource once it is released; it can only be manually reclaimed.

  • Failed: The volume has failed its automatic reclamation.

The numeric values that correspond to these measure values are as follows:

Numeric Value Measure Value
1 Available
2 Bound
3 Released
4 Failed

Note:

By default, this measure reports the Measure Values discussed above to indicate the state of a PV. In the graph of this measure however, the same is indicated using the numeric equivalents only.

Using the detailed diagnosis of this measure, you can determine the namespace to which a PV belongs, the PVC that binds the PV (in case the PV is Bound), the reclaim policy configured for the PV, and the storage class (in case the PV is dynamically provisioned).
Volume_age Indicates how old this PV is.   The value of this measure is expressed in number of days, hours, and minutes.
Access_mode Indicates the access modes configured for this PV. Number A PersistentVolume can be mounted on a host in any way supported by the resource provider. As shown in the table below, providers will have different capabilities and each PV's access modes are set to the specific modes supported by that particular volume. For example, NFS can support multiple read/write clients, but a specific NFS PV might be exported on the server as read-only. Each PV gets its own set of access modes describing that specific PV's capabilities.

The access modes are:

  • ReadWriteOnce – the volume can be mounted as read-write by a single node

  • ReadOnlyMany – the volume can be mounted read-only by many nodes

  • ReadWriteMany – the volume can be mounted as read-write by many nodes

The aforesaid access modes also represent the values that this measure can report. The numeric values that correspond to these measure values are as follows:

Numeric Value Measure Value
1 ReadOnlyMany
2 ReadWriteMany
3 ReadWriteOnce

Note:

By default, this measure reports the Measure Values discussed above to indicate the access mode of a PV. In the graph of this measure however, the same is indicated using the numeric equivalents only.
Storage Indicates the storage capacity configured for this PV. GB