Volume & Storage Objects

Kubernetes tackles the challenge of persistent storage—a crucial requirement for many applications, especially in a distributed environment. Let's demystify how Kubernetes handles storage with volumes, PersistentVolumes (PVs), PersistentVolumeClaims (PVCs), and the Container Storage Interface (CSI).

Kubernetes Volumes

At its core, Kubernetes incorporates the concept of volumes into Pods, allowing shared storage to be used by containers within the same Pod. This approach is foundational for patterns like sidecars and ensures data persistence across container restarts, without data loss on the same node.

Example: Using a hostPath Volume

apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: k8s.gcr.io/test-webserver
    name: test-container
    volumeMounts:
    - mountPath: /test-pd
      name: test-volume
  volumes:
  - name: test-volume
    hostPath:
      path: /data
      type: Directory

This snippet shows a basic volume mounted from the host's filesystem into the Pod, illustrating how data can be persisted and shared.

hostPath Volume Mount

Expanding to Cluster Environments: PersistentVolumes and PersistentVolumeClaims

While hostPath volumes are useful, they don't address the need for persistent storage across multiple nodes. Kubernetes introduces PersistentVolumes (PVs) and PersistentVolumeClaims (PVCs) to provide an abstraction layer that integrates with various storage backends.

PersistentVolumes (PV)

A PV is a piece of storage in the cluster that has been provisioned by an administrator or dynamically via storage classes. It's a resource in the cluster just like a node is a cluster resource.

PersistentVolumeClaims (PVC)

A PVC is a request for storage by a user. It specifies size, access modes, and sometimes storage class, allowing users to consume abstract storage resources.

PV and PVC

Example: Using PV and PVC with an AWS EBS Volume

apiVersion: v1
kind: PersistentVolume
metadata:
  name: test-pv
spec:
  capacity:
    storage: 50Gi
  accessModes:
    - ReadWriteOnce
  csi:
    driver: ebs.csi.aws.com
    volumeHandle: vol-XXXXXX
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: ebs-claim
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 50Gi
---
apiVersion: v1
kind: Pod
metadata:
  name: app
spec:
  containers:
    - name: app
      image: centos
      command: ["/bin/sh"]
      args: ["-c", "while true; do echo $(date -u) >> /data/out.txt; sleep 5; done"]
      volumeMounts:
        - name: persistent-storage
          mountPath: /data
  volumes:
    - name: persistent-storage
      persistentVolumeClaim:
        claimName: ebs-claim

This configuration showcases a Pod using a PVC to claim storage from a PV backed by AWS EBS, facilitated by the CSI.

Container Storage Interface (CSI)

The CSI standardizes storage driver implementations, enabling Kubernetes to work with a variety of storage solutions without needing to know specifics about the underlying infrastructure.

Advanced Storage Management with Rook

For more complex storage needs, projects like Rook orchestrate cloud-native storage systems within Kubernetes, offering sophisticated management for distributed storage solutions such as Ceph.

Rook Architecture

Kubernetes' storage model, from basic volumes to the advanced CSI and Rook orchestration, offers flexible solutions for managing persistent data. By understanding these concepts, users can effectively manage stateful applications in a cloud-native environment, ensuring data persistence and consistency across distributed systems.