A Volume is a directory accessible to containers in a Pod. It is defined in the Pod spec and mounted into one or more containers.

• Volumes have a lifecycle tied to the Pod (not the container)
• If a container crashes, the volume data survives the restart
• Multiple containers can share the same volume
• Volume type determines where data lives and its durability

"emptyDir is like scratch paper on your desk. It appears when you sit down (Pod starts) and gets thrown away when you leave (Pod deleted). But if you just take a coffee break (container restart), the paper stays."

• Created empty when Pod is assigned to a node
• Persists across container restarts (within the same Pod)
• Deleted permanently when Pod is removed
• Stored on node's disk or in memory (medium: Memory)

apiVersion: v1
kind: Pod
metadata:
  name: shared-data
spec:
  containers:
    - name: writer
      image: busybox
      command: ["sh","-c",
        "echo hello > /data/greeting; sleep 3600"]
      volumeMounts:
        - name: scratch
          mountPath: /data
    - name: reader
      image: busybox
      command: ["sh","-c",
        "cat /data/greeting; sleep 3600"]
      volumeMounts:
        - name: scratch
          mountPath: /data
  volumes:
    - name: scratch
      emptyDir: {}

hostPath mounts a file or directory from the host node's filesystem into a Pod. Useful for system-level workloads but dangerous for regular applications.

• Data persists on that specific node
• Pod must be scheduled on the same node to see the data
• Security risk: exposes host filesystem to containers
• Types: Directory, File, DirectoryOrCreate, FileOrCreate

apiVersion: v1
kind: Pod
metadata:
  name: log-reader
spec:
  containers:
    - name: reader
      image: busybox
      command: ["tail","-f",
        "/var/log/syslog"]
      volumeMounts:
        - name: host-logs
          mountPath: /var/log
          readOnly: true
  volumes:
    - name: host-logs
      hostPath:
        path: /var/log
        type: Directory

A PersistentVolume (PV) is a piece of storage in the cluster that has been provisioned by an administrator or dynamically by a StorageClass.

• Cluster-scoped -- not tied to any namespace
• Has a lifecycle independent of any Pod
• Defines capacity, access modes, and storage backend
• Can be pre-provisioned (static) or dynamically created

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-azure-disk
spec:
  capacity:
    storage: 50Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: managed-premium
  azureDisk:
    diskName: my-data-disk
    diskURI: /subscriptions/.../my-data-disk
    kind: Managed

"You do not ask the gym owner to physically hand you locker number 47. You fill out a claim form: 'I need a medium locker, with a lock.' The gym matches you to an available one. That is a PVC."

• Namespace-scoped request for storage
• Specifies desired size, access mode, and StorageClass
• Kubernetes binds the PVC to a matching PV
• Pods reference the PVC, not the PV directly
• This abstraction separates storage consumers from storage providers

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: data-claim
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 20Gi
  storageClassName: managed-premium

# Check binding status
$ kubectl get pvc data-claim
NAME         STATUS   VOLUME        CAPACITY
data-claim   Bound    pv-azure-01   20Gi

Once a PVC is bound to a PV, any Pod in the same namespace can mount it. The Pod references the PVC name -- it never needs to know about the underlying PV or cloud storage details.

• Pod spec defines volumes referencing the PVC
• Container spec defines volumeMounts with mount path
• Data persists across Pod restarts and rescheduling
• PVC prevents PV from being deleted while in use

apiVersion: v1
kind: Pod
metadata:
  name: database
spec:
  containers:
    - name: postgres
      image: postgres:15
      volumeMounts:
        - name: db-storage
          mountPath: /var/lib/postgresql/data
      env:
        - name: POSTGRES_PASSWORD
          value: "secret"
  volumes:
    - name: db-storage
      persistentVolumeClaim:
        claimName: data-claim

Reclaim Policies

• Retain -- PV kept after PVC deletion. Admin must manually reclaim. Data safe.
• Delete -- PV and underlying storage deleted when PVC is deleted. Default for dynamic provisioning.
• Recycle -- (Deprecated) Basic rm -rf and make available again.

"Not all lockers are created equal. Some are small and free (Standard HDD). Some are large and climate-controlled (Premium SSD). A StorageClass defines the tier -- you pick which tier you want in your PVC."

• Defines the provisioner (who creates the storage)
• Defines parameters (disk type, replication, encryption)
• Defines reclaim policy and binding mode
• Enables dynamic provisioning -- no pre-created PVs needed

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: premium-ssd
provisioner: disk.csi.azure.com
parameters:
  skuName: Premium_LRS
  kind: Managed
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true

"With dynamic provisioning, you do not need an admin to create storage in advance. You submit your claim, and the system automatically provisions a new disk in Azure, creates a PV, and binds it to your PVC. It is like walking into a hotel and a room is ready before you even check in."

• PVC references a StorageClass
• StorageClass provisioner creates storage on-demand
• PV is automatically created and bound
• No admin intervention needed

# Just create a PVC -- that's it!
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-data
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: managed-csi-premium
  resources:
    requests:
      storage: 100Gi

# Azure automatically creates:
# 1. A Premium SSD Managed Disk
# 2. A PV object in Kubernetes
# 3. Binds PVC to PV
$ kubectl get pvc,pv
NAME       STATUS   VOLUME       CAPACITY
my-data    Bound    pvc-a1b2c3   100Gi

By default, PVCs are provisioned immediately. But this can cause problems in multi-zone clusters -- the disk might be created in a different zone than the Pod.

• Immediate -- PV provisioned when PVC is created
• WaitForFirstConsumer -- PV provisioned when a Pod first uses the PVC
• WaitForFirstConsumer ensures the disk is in the same zone as the Pod

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: zone-aware-ssd
provisioner: disk.csi.azure.com
parameters:
  skuName: Premium_LRS
volumeBindingMode: WaitForFirstConsumer

Running out of space? You can expand a PVC without downtime (if the StorageClass allows it).

• StorageClass must have allowVolumeExpansion: true
• Edit the PVC to increase spec.resources.requests.storage
• Azure Disk: requires Pod restart for filesystem resize
• Azure Files: online expansion (no restart needed)
• You can only increase size, never decrease

# Expand PVC from 20Gi to 50Gi
$ kubectl patch pvc data-claim -p \
  '{"spec":{"resources":{"requests":{"storage":"50Gi"}}}}'

# Check status
$ kubectl get pvc data-claim
NAME         STATUS   CAPACITY
data-claim   Bound    50Gi

# For Azure Disk, restart the Pod:
$ kubectl delete pod database
# Pod recreated by Deployment/StatefulSet
# Filesystem resized on mount

"A ConfigMap is like the bulletin board in your office. You pin up configuration that anyone can read: the Wi-Fi password for guests, the lunch menu, office hours. It is not secret -- just information your app needs."

• Stores non-sensitive configuration data
• Key-value pairs or entire files
• Consumed as environment variables or mounted files
• Changes to mounted ConfigMaps auto-update in Pods (with delay)
• Max size: 1 MiB

# Create from literal values
$ kubectl create configmap app-config \
    --from-literal=DB_HOST=postgres \
    --from-literal=LOG_LEVEL=info

# Create from a file
$ kubectl create configmap nginx-conf \
    --from-file=nginx.conf

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  DB_HOST: postgres.default.svc.cluster.local
  LOG_LEVEL: info
  MAX_CONNECTIONS: "100"

"If ConfigMaps are the bulletin board, Secrets are the locked safe in the manager's office. Passwords, API keys, TLS certificates -- anything you would not want posted on the wall goes here."

• Stored as Base64-encoded data (not encrypted by default!)
• Types: Opaque, kubernetes.io/tls, kubernetes.io/dockerconfigjson
• Consumed the same way as ConfigMaps (env vars or volumes)
• Mounted Secrets are stored in tmpfs (never written to disk on the node)
• Max size: 1 MiB

# Create from literal
$ kubectl create secret generic db-creds \
    --from-literal=username=admin \
    --from-literal=password=S3cur3P@ss

# Create TLS secret
$ kubectl create secret tls my-tls \
    --cert=tls.crt --key=tls.key

apiVersion: v1
kind: Secret
metadata:
  name: db-creds
type: Opaque
data:
  username: YWRtaW4=       # base64
  password: UzNjdXIzUEBzcw== # base64

• Industry standard for storage in container orchestrators
• Storage vendors ship their own drivers (out-of-tree)
• No need to modify Kubernetes core code
• Supports: provisioning, attaching, mounting, snapshots, cloning, expansion

Azure CSI Drivers

• disk.csi.azure.com -- Azure Managed Disks
• file.csi.azure.com -- Azure Files (SMB/NFS)
• blob.csi.azure.com -- Azure Blob Storage (NFS/FUSE)
• secrets-store.csi.k8s.io -- Azure Key Vault

Volume Snapshots are point-in-time copies of a PV. Like taking a photo of your data at a specific moment -- you can restore from it later.

• Requires a VolumeSnapshotClass (like StorageClass for snapshots)
• Create a VolumeSnapshot from an existing PVC
• Restore by creating a new PVC from the snapshot
• Azure Disk supports incremental snapshots

# Create a snapshot
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: db-snapshot
spec:
  volumeSnapshotClassName: azure-disk-snapshot
  source:
    persistentVolumeClaimName: data-claim

# Restore from snapshot
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: restored-data
spec:
  storageClassName: managed-csi-premium
  dataSource:
    name: db-snapshot
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 50Gi

StatefulSets use volumeClaimTemplates to automatically create a unique PVC for each replica. This is how databases like PostgreSQL and MongoDB get per-replica storage.

• Each replica gets its own PVC: data-postgres-0, data-postgres-1, etc.
• PVCs survive Pod deletion and rescheduling
• When scaling down, PVCs are not deleted (data preserved)
• Combined with Headless Services for stable network identity

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: postgres
spec:
  serviceName: postgres
  replicas: 3
  selector:
    matchLabels:
      app: postgres
  template:
    spec:
      containers:
        - name: postgres
          image: postgres:15
          volumeMounts:
            - name: data
              mountPath: /var/lib/postgresql/data
  volumeClaimTemplates:
    - metadata:
        name: data
      spec:
        accessModes: ["ReadWriteOnce"]
        storageClassName: managed-csi-premium
        resources:
          requests:
            storage: 50Gi

A Projected Volume combines multiple volume sources into a single mount point. Think of it as a folder that pulls files from different places.

• Combines: secret, configMap, downwardAPI, serviceAccountToken
• All sources appear as files in one directory
• Useful for apps that read config from a single directory

volumes:
  - name: app-config
    projected:
      sources:
        - configMap:
            name: app-settings
        - secret:
            name: app-secrets
        - downwardAPI:
            items:
              - path: "labels"
                fieldRef:
                  fieldPath: metadata.labels