storage class , PV and PVC in Open shift - unix1998/technical_notes GitHub Wiki

In OpenShift (and Kubernetes), Persistent Volumes (PVs) and Storage Classes are components of the storage infrastructure, but they serve different roles. Here's how they relate to each other and how Persistent Volume Claims (PVCs) interact with them:

Storage Classes

  • Purpose: Storage Classes define the configuration and policies for dynamic provisioning of Persistent Volumes.
  • Role: They specify the provisioner (e.g., AWS EBS, GCE PD, NFS), parameters (e.g., disk type, IOPS), and other attributes needed to create PVs dynamically.
  • Management: Typically created and managed by cluster administrators.

Persistent Volumes (PVs)

  • Purpose: PVs are actual storage resources in the cluster, representing a piece of storage that can be consumed by applications.
  • Role: PVs can be statically provisioned (created manually by an administrator) or dynamically provisioned (created automatically using a Storage Class).
  • Management: Can be manually created by administrators or automatically created based on Storage Class definitions.

Persistent Volume Claims (PVCs)

  • Purpose: PVCs are requests for storage by users or applications. They specify the desired storage capacity, access modes, and optionally, a Storage Class.
  • Role: PVCs get bound to appropriate PVs that satisfy their requirements. If a PVC references a Storage Class, the cluster dynamically provisions a PV according to the Storage Class parameters.
  • Interaction: PVCs can either request an existing PV (static provisioning) or trigger the creation of a new PV (dynamic provisioning) based on a Storage Class.

Interaction Scenarios

  1. Static Provisioning:

    • Step 1: An administrator manually creates a PV.
    • Step 2: A user creates a PVC specifying the required storage attributes.
    • Step 3: The cluster matches the PVC with an existing PV that meets the criteria (capacity, access modes).
    • No Storage Class involved in this direct binding scenario.

  2. Dynamic Provisioning:

    • Step 1: An administrator defines a Storage Class.
    • Step 2: A user creates a PVC and specifies the Storage Class name.
    • Step 3: The cluster uses the Storage Class to dynamically provision a new PV that meets the PVC's requirements and binds it to the PVC.
    • Storage Class involved to dynamically create the PV.

Example 1: Static Provisioning

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-example
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  nfs:
    path: /path/to/nfs
    server: nfs-server.example.com
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-example
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi

In this case, the PVC (pvc-example) is directly matched with the statically created PV (pv-example).

Example 2: Dynamic Provisioning

  1. Storage Class Definition:
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: nfs-storage
provisioner: nfs-provisioner
parameters:
  path: /path/to/nfs
  server: nfs-server.example.com
  1. Persistent Volume Claim Using the Storage Class:
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-dynamic
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: nfs-storage

In this case, the PVC (pvc-dynamic) triggers the dynamic provisioning of a PV using the nfs-storage Storage Class.

Summary

  • Storage Class: Template for dynamic provisioning of PVs. Not used directly by PVCs unless dynamic provisioning is needed.
  • Persistent Volume (PV): The actual storage resource. Can be manually created (static) or automatically created (dynamic).
  • Persistent Volume Claim (PVC): The request for storage. Can bind to an existing PV or trigger dynamic provisioning via a Storage Class.

By using Storage Classes, administrators can simplify the process of managing storage, while users can request storage without needing to know the details of the underlying storage infrastructure.

####################################################################################################

In the provided example, the my-fast-pvc Persistent Volume Claim (PVC) requests 10Gi of storage from the fast-storage Storage Class. Here’s how it works in detail:

PVC and Storage Class Interaction

  1. PVC Creation:

    • When the my-fast-pvc is created, it specifies that it needs 10Gi of storage with the ReadWriteOnce access mode.
    • It also specifies the storageClassName: fast-storage, indicating that it wants the storage to be provisioned according to the parameters defined in the fast-storage Storage Class.

  2. Storage Class Parameters:

    • The fast-storage Storage Class defines that the provisioner should be kubernetes.io/aws-ebs.
    • It also specifies parameters for the provisioner, such as type: gp2 and fsType: ext4.

Dynamic Provisioning Process

When the PVC is created, the following steps occur:

  1. Check for Existing PVs:

    • The Kubernetes control plane first checks if there are any existing PVs that match the PVC's requirements (10Gi, ReadWriteOnce access mode, and fast-storage Storage Class). Since the scenario describes dynamic provisioning, it assumes no matching PVs exist.

  2. Dynamic Provisioning:

    • Because the PVC specifies the fast-storage Storage Class and there are no matching existing PVs, the cluster initiates dynamic provisioning.
    • The fast-storage Storage Class instructs the cluster to use the kubernetes.io/aws-ebs provisioner to create a new PV.

  3. Provisioning a New PV:

    • The kubernetes.io/aws-ebs provisioner communicates with the AWS EBS service to provision a new 10Gi EBS volume with the specified parameters (gp2 type and ext4 filesystem).
    • Once the new EBS volume is created, a corresponding PV is created in the Kubernetes cluster, representing this new 10Gi EBS volume.

  4. Binding PV to PVC:

    • The newly created PV is then automatically bound to the my-fast-pvc PVC.
    • The application that requested the PVC can now use the 10Gi of storage provided by the dynamically created EBS volume.

Summary

  • Storage Class fast-storage: Defines how to dynamically provision storage using AWS EBS with specific parameters.
  • PVC my-fast-pvc: Requests 10Gi of storage and specifies to use the fast-storage Storage Class.
  • Dynamic Provisioning: The cluster dynamically provisions a new 10Gi EBS volume based on the Storage Class parameters and binds it to the PVC.

The Storage Class fast-storage does not directly "find" 10Gi of storage from a pre-existing PV. Instead, it triggers the creation of a new PV with the specified size and properties using the AWS EBS provisioner. This new PV is then used to fulfill the PVC's storage request.

#########################################################################

When you specify storageclass.kubernetes.io/is-default-class: "true" in a StorageClass manifest file, it marks that particular StorageClass as the default StorageClass for the cluster. Here’s how it affects PVC creation:

Default StorageClass Behavior

  1. Default StorageClass Defined:

    • If you set storageclass.kubernetes.io/is-default-class: "true" for a StorageClass, it means that any PVC created without explicitly specifying a storageClassName will automatically use this default StorageClass.

  2. PVC Creation Without storageClassName:

    • When you create a PVC without specifying a storageClassName, Kubernetes/OpenShift will automatically assign it to the default StorageClass that is marked as is-default-class: "true".

Example Scenario

Assume you have the following setup:

StorageClass Manifest (fast-storage.yaml):

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-storage
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"
provisioner: kubernetes.io/aws-ebs
parameters:
  type: gp2
  fsType: ext4

PVC Manifest (my-pvc.yaml):

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

In this example:

  • The fast-storage StorageClass is marked as the default StorageClass (is-default-class: "true").
  • The my-pvc PVC does not specify a storageClassName.

Behavior:

  • When you create the my-pvc PVC using kubectl apply -f my-pvc.yaml, Kubernetes/OpenShift will automatically associate this PVC with the fast-storage StorageClass because it is marked as the default.
  • The PVC my-pvc will request and provision 10Gi of storage using the parameters defined in the fast-storage StorageClass (kubernetes.io/aws-ebs provisioner, gp2 type, ext4 filesystem).

Summary:

  • Setting storageclass.kubernetes.io/is-default-class: "true" in a StorageClass makes it the default choice for PVCs that do not specify a storageClassName.
  • PVCs without a specified storageClassName will automatically use the default StorageClass.
  • This simplifies PVC manifests by eliminating the need to specify storageClassName explicitly when you intend to use the default StorageClass.

By leveraging default StorageClasses, administrators can streamline PVC management, ensuring that applications can obtain storage resources conveniently without additional configuration overhead.