Kubernetes Storage

Overview

Overview of kubenetes storage

Volume: Volume is a Docker concept that indicates a directory on disk or in another container
Persistance Volume (PV): A virtual storage instance that is added as a volume to K8s cluster by administrator
Persistance Volume Claim (PVC): request/access (read, write) to PVs
Storage Class: Mechanism to dynamically provision storage service (i.e. Azure file share) and add as volume to K8s cluster
Volume Plugins (add-ons):
- External storage solutions linked to Kubernetes are called Volume plugins
- Volume Plugins enable abstracting storage and grant storage portability

Node (i.e. AKS node VM) local storage (emptyDir and hostPath)
Cloud volumes (i.e. azureFile, azureDisk)
File-sharing volumes (i.e. SMB, NFS)
Distributed-file systems (for example, CephFS, RBD, and GlusterFS)
Special types i.e. PersistentVolumeClaim, secret, and ConfigMap
See:
- Types of K8s volumes: https://kubernetes.io/docs/concepts/storage/volumes/#volume-types

Definition of volume:
- Wikipedia: In computer data storage, a volume (or logical drive) is a single accessible storage area with a single file system (typically, though not necessarily, resident on a single partition of a hard disk)
- Techtarget: A storage volume is an identifiable unit of data storage
- A volume is a unit of data storage
Volume in K8s
- Docker volume:
  - A Docker volume is a directory on disk or in another container
  - Docker volumes are file systems mounted on Docker containers to preserve data generated by the running container
- K8s volume
  - Volumes within Kubernetes are storage that is tied to the Pod’s lifecycle.
  - A volume represents a way to store, retrieve, and persist data across pods and through the application lifecycle
  - A Kubernetes volume is a directory that contains data accessible to containers in a given Pod
  - A K8s volume can shared by all containers in that pod
  - Lifecycle of K8s volumes are tied to Pod lifecycle (if pod is destroyed, volume will be deleted)
Volumes can be persistent or non-persistent, and Kubernetes allows containers to request storage resources dynamically, using a mechanism called volume claims

A PersistentVolume (PV) is a representation of a cluster-wide storage resource that is linked to a backing storage provider (Azure files, NFS, SMB etc.)
A persistent volume (PV) is a storage resource created and managed by the Kubernetes API that can exist beyond the lifetime of an individual pod
A PersistentVolume (PV) is a piece of storage in the cluster that has been provisioned by an administrator or dynamically provisioned using Storage Classes
PVs are K8s resource in the cluster just like a node is a cluster resource
A virtual storage instance that is added as a volume to the cluster
They are independent of any single pod, breaking them free from the ephemeral life cycle of pods
The PersistentVolume subsystem provides an API for users and administrators that abstracts details of how storage is provided from how it is consumed

A PersistentVolumeClaim (PVC) is a request for storage by a user. It is similar to a Pod. Pods consume node resources and PVCs consume PV resources
Persistent Volume Claims (PVC) are requests for K8s storage i.e. PVs
Pods use PVC to get access (read, write) to PVs
A PVC to PV binding is a one-to-one mapping
See: https://kubernetes.io/docs/concepts/storage/persistent-volumes/#claims-as-volumes

Statically:
- Provision real storage i.e. Azure file share
- Create PV resource in K8s cluster
- PVs are ready to be consumed by pods (using PVCs)
Dynamically:
- Create and configure StorageClass K8s resource (might need credentials i.e Azure Storage Account in case of Azure file share)
- Dynamically created storage service i.e. Azure file share will available as K8s volume (can be consumed using PVC)

Dynamic provisioning of storage services in order to use that storage service as a volume
Can provision storage service (i.e. Azure file share) dynamically when needed (no need to provision beforehand as like PVs)
A Kubernetes storage class is used to abstract the underlying storage platform

Once PV is provisioned, a PVC can claim that PV (PVC <-> PV is one-to-one mapping)
If you want a PVC to bind to a specific PV, you need to pre-bind them using claimRef
If PV uses claimRef, only the particular PVC mentioned in claimRef can calim that PV (request by other PVCs will be rejected)

Pods access storage by using PVC as a volume (as if PVC will be mounted as volume inside the pod)
Claims must exist in the same namespace as the Pod using the claim
The cluster finds the claim in the Pod’s namespace and uses it to get the PersistentVolume backing the claim. The volume is then mounted to the Pod