• Explore
  • About Us
  • Log In
  • Get Started
  • Explore
  • About Us
  • Log In
  • Get Started
18:00

Creating Persistent Volumes and Claims

Scenario

Your team is deploying a stateful application (a PostgreSQL database) that requires its data to be preserved even if the pod is restarted or deleted. To achieve this, you need to provide persistent storage to the database pod.

Your task is to manually create a Persistent Volume (PV) that represents a piece of storage on a node, create a Persistent Volume Claim (PVC) to request that storage, and then mount the PVC into the database pod.

Prerequisites

  • A running Kubernetes cluster.
  • The ability to create files on the worker nodes (for the hostPath PV).

SSH Access to Worker Nodes:

Cluster TypeAccess Method
minikubeminikube ssh
kinddocker exec -it <kind-container-name> bash
(find container name with docker ps)
Cloud ProvidersUse provider-specific SSH methods
(e.g., gcloud compute ssh for GKE nodes)
Bare Metal/VMsStandard SSH with cluster setup credentials

Note: hostPath volumes are NOT recommended for production use due to security and portability concerns. This exercise uses them for educational purposes only.

Requirements

  1. Create a Directory on the Node:

    • On one of your worker nodes, create a directory named /mnt/data to serve as the storage for the PV.
  2. Create a Persistent Volume (PV):

    • Create a PV named my-pv with a capacity of 1Gi.
    • The PV should have an access mode of ReadWriteOnce.
    • It should use the hostPath volume type, pointing to the /mnt/data directory on the node.
    • Set the storageClassName to manual.
  3. Create a Persistent Volume Claim (PVC):

    • Create a PVC named my-pvc that requests 500Mi of storage.
    • The PVC should have an access mode of ReadWriteOnce.
    • It should specify the storageClassName as manual to bind to the PV you created.
  4. Create a Pod that Uses the PVC:

    • Create a Pod named db-pod using the postgres:16-alpine image.
    • Mount the my-pvc PVC into the container at the path /var/lib/postgresql/data.
    • Use a Kubernetes Secret to securely store the PostgreSQL password.

Acceptance Criteria

  • The /mnt/data directory exists on the worker node.
  • A Secret containing the PostgreSQL password is created.
  • The my-pv PV is created and has a status of Available.
  • The my-pvc PVC is created and has a status of Bound to my-pv.
  • The db-pod is running and has the PVC mounted correctly.
  • The pod uses the Secret for the PostgreSQL password (no plain text passwords).
  • Data written to /var/lib/postgresql/data inside the pod persists in the /mnt/data directory on the node.

Possible Ways to Implement

  • For Creating the Directory on the Node:

    • Use appropriate access method based on your cluster type (see table above).
  • For Securing PostgreSQL Password:

    • Create a Kubernetes Secret to store the password securely.
    • Reference the Secret in the pod's environment variables using valueFrom.secretKeyRef.
  • For Creating the PV and PVC:

    • Define the PV and PVC in separate YAML files and apply them with kubectl apply -f.
    • Ensure the storageClassName matches in both the PV and PVC to ensure they bind.
  • For Creating the Pod:

    • Define the Pod in a YAML file.
    • Use the volumes section to define a volume that uses the PVC.
    • Use the volumeMounts section in the container definition to mount the volume.
    • Set the PGDATA environment variable to avoid PostgreSQL initialization conflicts.
  • For Verification:

    • Use kubectl get pv and kubectl get pvc to check the status of the PV and PVC.
    • Use kubectl describe pod db-pod to verify that the volume is mounted correctly.
    • Use kubectl exec to create a file in the mounted directory inside the pod, and then access the node to verify that the file exists.

Real-World Significance

Persistent Volumes and Claims are the foundation of running stateful applications in Kubernetes. While hostPath is useful for development and testing on a single node, in a production environment, you would typically use a more robust storage solution like a cloud provider's block storage (e.g., AWS EBS, GCP Persistent Disk) or a network file system (NFS). The PV/PVC abstraction allows you to decouple the application's storage needs from the underlying storage infrastructure, making your applications more portable and easier to manage. For a CKA, mastering PVs and PVCs is essential for managing stateful workloads.

Security Note: This exercise demonstrates the proper use of Kubernetes Secrets for sensitive data like passwords. Never store credentials in plain text within YAML manifests in real-world scenarios.

    CKA Practice Exercises

    Unlock All Exercises

  • Cluster Architecture, Installation & Configuration
    • Setting up a Kubernetes Cluster with Kubeadm
    • Managing Cluster Certificates
    • Upgrading a Kubernetes Cluster
    • Implementing RBAC for Users and ServiceAccounts
    • Configuring Kubeconfig Files
    • Using Helm to Deploy Applications
    • Managing Kubernetes Manifests with Kustomize
    • Understanding CNI, CSI, CRI
    • Managing etcd Backups and Restores
    • API Server Authentication and Authorization Basics
  • Workloads & Scheduling
    • Deploying Applications with Deployments
    • Performing Rolling Updates and Rollbacks
    • Configuring ConfigMaps and Secrets
    • Implementing Horizontal Pod Autoscaling
    • Managing Pod Scheduling with Taints and Tolerations
    • Controlling Pod Placement with Node Selectors and Affinity
    • Configuring Pod Security Context
  • Services & Networking
    • Creating ClusterIP, NodePort, and LoadBalancer Services
    • Configuring Ingress with Gateway API
    • Understanding CoreDNS and DNS Resolution
    • Implementing Network Policies for Pod Isolation
    • Troubleshooting Network Connectivity
  • Storage
    • Creating Persistent Volumes and Claims
    • Implementing Storage Classes and Dynamic Provisioning
    • Configuring Volume Access Modes
    • Using Local Persistent Volumes
  • Troubleshooting
    • Troubleshooting Pod Startup Issues
    • Debugging Application Logs
    • Troubleshooting Node Issues
    • Debugging Service Connectivity
    • Troubleshooting Network Policy Issues
    • Diagnosing Control Plane Component Failures
    • Troubleshooting Storage Issues
    • Monitoring Resource Usage
    • Inspecting etcd with etcdctl
    • Checking Control Plane Component Logs
  • Imperative Kubectl Practice
    • Create a Pod with Image and Label
    • Expose Deployment as Service
    • Scale Deployment Imperatively
    • Update Image Imperatively