Kubernetes persistent volume, persistent volume clam, and storage class

1 = The storage must be available on all nodes because it's not clear the pod that related to the storage restarts in which node. 2 = PVs are outside of the namespaces and it accessible throughout the whole cluster. 3 =

Kubernetes Persistent Volume (PV): A Persistent Volume (PV) is a Kubernetes resource that represents a piece of networked storage in the cluster, such as a physical disk, a network file share, or a cloud-based storage solution. PVs abstract the underlying storage details from the applications using them. They provide a way to manage and control the storage resources of the cluster separately from the application's lifecycle.

Attributes of a Persistent Volume: Persistent Volumes have several attributes that define the characteristics of the underlying storage:

Storage Capacity: This attribute specifies the total amount of storage available in the Persistent Volume. It is typically specified in terms of bytes (e.g., 1Gi for 1 gibibyte).

Access Modes: PVs define how the storage can be accessed. These modes include the same access modes mentioned before for Persistent Volume Claims (PVCs):

• ReadWriteOnce (RWO): The volume can be mounted as read-write by a single node.
• ReadOnlyMany (ROX): The volume can be mounted as read-only by multiple nodes.
• ReadWriteMany (RWX): The volume can be mounted as read-write by multiple nodes.

Reclaim Policy: The reclaim policy specifies what should happen to the underlying storage when the PV is released or the associated PVC is deleted. The reclaim policies are:

• Retain: The PV's storage is not deleted automatically. The administrator is responsible for deleting the data.
• Delete: The PV's storage is deleted when the PV is released or the associated PVC is deleted.
• Recycle: The PV's data is deleted and the PV is made available for a new claim.
• Storage Class: Similar to PVCs, PVs can also have an associated storage class. The storage class defines the provisioner and parameters used to dynamically create the PV. If a PV does not have a storage class, it is considered "static" and must be manually created.

Volume Mode: The volume mode specifies how the volume should be formatted. It can be either "Filesystem" or "Block".

Here's an example of YAML's definition of a Persistent Volume:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-pv
spec:
  capacity:
    storage: 5Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: slow
  volumeMode: Filesystem
  nfs:
    server: nfs-server.example.com
    path: /exports/data        

In this example, a PV named "my-pv" is created with 5 gibibytes of storage, using the ReadWriteOnce access mode, and a reclaim policy of "Retain". It is associated with the "slow" storage class and uses the NFS protocol to connect to the server at nfs-server.example.com and mount the path /exports/data.

PVs provide a way to manage storage in a Kubernetes cluster in a more abstract and scalable manner, allowing for better resource utilization and isolation between applications.

Kubernetes Persistent Volume Claim (PVC):

A Persistent Volume Claim is a Kubernetes resource used to request storage resources from a Persistent Volume (PV). It acts as a user's request for storage with specific attributes such as size, access modes, and storage class. PVCs abstract the underlying storage details and allow developers to request storage without needing to know the specific implementation or location of the storage.

Attributes of a Persistent Volume Claim:

Persistent Volume Claims have several attributes that define the characteristics of the requested storage:

Storage Request: This specifies the amount of storage requested by the user, such as "1Gi" for 1 gigabyte.

Access Modes: PVCs define how the storage can be accessed. These modes include:

• ReadWriteOnce (RWO): The volume can be mounted as read-write by a single node.
• ReadOnlyMany (ROX): The volume can be mounted as read-only by multiple nodes.
• ReadWriteMany (RWX): The volume can be mounted as read-write by multiple nodes.

Storage Class: A Storage Class is used to define different classes of storage with specific properties. It allows administrators to define storage backends with various performance characteristics, replication levels, and other features. When a PVC is created, you can specify the desired storage class.

Selector: This is an optional field that allows you to specify a label selector to match a specific PV. This can be used to request a particular type of storage.

Resources: PVCs can have resource limits and requests defined, similar to how you define resource requests and limits for pods. These resource settings help Kubernetes allocate the appropriate amount of storage.

Here's an example YAML definition of a Persistent Volume Claim:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: my-pvc
spec:
accessModes:
 - ReadWriteOnce
resources:
requests:
storage: 1Gi
storageClassName: standard        

In this example, a PVC named "my-pvc" requests 1 gigabyte of storage with ReadWriteOnce access mode and uses the "standard" storage class.

Remember that a PVC must match a PV's access modes and other requirements to bind to it successfully. Once a PVC is bound to a PV, the PV's storage is provisioned and made available to the pod that uses the PVC.