Kubernetes Persistent Volumes and Claims

Kubernetes Persistent Volumes (PV) and Persistent Volume Claims (PVC)

Types of Volumes in Kubernetes

• AWS Elastic Block: For use with EKS (Elastic Kubernetes Service).
• Azure Disk: For use with Azure.
• Azure Files: For use with Azure.
• ConfigMap: Used for injecting configuration data into pods.
• HostPath: Uses a directory or file on the node's filesystem.
• EmptyDir: A temporary directory that lasts the lifetime of the pod.
• Persistent Volume (PV): A piece of storage in the cluster provisioned by an administrator or dynamically provisioned using storage classes.

Persistent Volume (PV)

• A Persistent Volume (PV) is a storage resource in the Kubernetes cluster, similar to how a node is a cluster resource.

• PVs have a lifecycle independent of pods.

• PVs can be provisioned by an administrator or dynamically using storage classes.

• The speaker was a Kubernetes administrator, managing Kubernetes cluster environments for various teams and projects.

• When teams need volumes for their pods, the administrator creates PVs.

• Administrators aren't limited to AWS administrators; Kubernetes administrators manage the Kubernetes cluster itself.

Persistent Volume Claim (PVC)

• A Persistent Volume Claim (PVC) is a request for storage by a user.
• Users create PVCs to claim part or all of a PV.

Creating a Persistent Volume

• A persistent volume can be created by applying a YAML file

Key Parameters of a PV Configuration

• Volume Name: The name of the persistent volume (e.g., "pv-volume").
• Capacity: The storage capacity of the volume (e.g., 100Gi, which stands for 100 gigabytes).
• Volume Mode: Specifies whether the volume is used for a file system or block storage.
• Access Mode: Defines how the volume can be accessed (e.g., ReadWriteOnce).
• Persistent Volume Claim Policy: Defines what happens to the volume when a PVC is deleted (e.g., Recycle).
• Storage Class Name: The name of the storage class to which the PV belongs (e.g., manual).
• Host Path: location of the persistent volume on the node (e.g., /mnt/Data)

Storage Classes

• Storage classes enable dynamic provisioning and resource optimization.
• They facilitate scaling and automation.
• The transcript uses manual provisioning.

Types of Storage Classes

• Manual: Requires the administrator to create the storage.
• AWS EBS: Uses AWS Elastic Block Storage.
• AWS EFS: Uses AWS Elastic File System.

Using AWS EBS for Persistent Volumes

• Create an external EBS volume in the cloud and attach it to the EC2 instance (worker node).
• Specify the EBS volume's storage class in the PV configuration.

Storage Location and Access

• Storage is typically created in the worker nodes, as access to the master node (control plane) is restricted.
• Volumes like EBS or EFS must be attached to the worker nodes.
• The mount point serves as the entry point for the volume.

NFS Server

• NFS (Network File System) can be used for on-premise environments to share storage.
• For cloud deployments using EFS, mount the EFS file system to the EC2 instances and use the mount point as the entry point.

Practical Steps for Creating a Persistent Volume

1. Create an EBS Volume: If using EBS, create the volume.
2. Attach the EBS Volume: Attach the EBS volume to the worker nodes.
3. Create a Mount Point: Create a directory (e.g., /mnt/data) in the worker nodes.

Access Modes for Persistent Volumes

• ReadWriteOnce (RWO): The volume can be mounted as read-write by a single node.
  • Ideal for applications needing exclusive write access, such as databases.
• ReadOnlyMany (ROX): The volume can be mounted read-only by many nodes.
• ReadWriteMany (RWX): The volume can be mounted as read-write by many nodes.
• ReadWriteOncePod (RWOP): Allows only one pod to mount the volume as read-write.

Creating a Persistent Volume Claim (PVC) and Deployment

1. Create a PV: Define the Persistent Volume.
2. Create a PVC: Define the Persistent Volume Claim to request the storage.
3. Create a Deployment: Define the deployment to utilize the PVC.

Volume Claim

• After creating a PV, you need to claim it using a PVC to attach it to pods or deployments.
• The PVC specifies the storage capacity and access mode required.

Key Parameters of a PVC Configuration

• Name: The name of the PVC.
• Resources Request: The amount of storage requested.
• Volume Mode: The volume mode (e.g., FileSystem).
• Storage Class Name: Must match the PV's storage class name (e.g., manual).
• Access Modes: Must be compatible with the PV's access modes (e.g. ReadWriteOnce).

Creating a Volume in Worker Nodes

• Log in to the worker nodes.
• Create the directory specified in the hostPath of the PV (e.g., sudo mkdir /mnt/data).
• Ensure the directory is created on both worker nodes to avoid scheduling issues.

Creating a Deployment

• A deployment ensures that the desired number of pod replicas are running.
• The deployment configuration specifies the PVC to use for storage.

Key Parameters for Deployment

• Volume: Refers to the persistent volume name.
• Persistent Volume Claim: Specifies the PVC to use.
• Mount Point: Specifies where the volume should be mounted inside the container.

Testing the Volume

• Create an index.html file inside the mounted volume directory on both worker nodes.
• The content of the HTML file can be different on each node to verify load balancing.

Accessing the Application

• Create a service of type LoadBalancer to expose the application.
• Access the application through the LoadBalancer's external IP or DNS name.
• The load balancer distributes traffic across the pods.

Load Balancing

• The load balancer distributes traffic across the pods based on the deployment configuration.
• Sticky sessions might cause a user to consistently hit the same pod.

Important Considerations

• If a PVC claims the entire storage capacity of a PV, no other PVC can claim from that PV.
• When using local storage types, the PV name doesn't need to be specified in the PVC, as they are implicitly linked.
• The volume name must match the name of the volume created.