Skip to content

CSI Integration

Kubernetes provides several volume types to manage persistent storage, each with distinct use cases and integration mechanisms. Understanding these options is critical for deploying stateful applications. This section explores built-in volume types like hostPath, NFS, and cloud provider-specific solutions, alongside the modern Container Storage Interface (CSI), which standardizes storage integration across diverse backends.

Built-in Volume Types

hostPath Volumes

hostPath volumes mount a file or directory from the host node's filesystem into a Pod. They are useful for development or testing but not recommended for production due to lack of portability and isolation.

Example:

apiVersion: v1
kind: Pod
metadata:
  name: hostpath-pod
spec:
  containers:
  - name: app
    image: nginx
    volumeMounts:
    - name: mydata
      mountPath: /data
  volumes:
  - name: mydata
    hostPath:
      path: /var/mydata

Use Cases:
- Debugging or local development.
- Sharing data between containers on the same node.

NFS Volumes

NFS (Network File System) volumes provide shared storage accessible across multiple nodes. They are ideal for stateful applications requiring networked storage.

Example:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-pv
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteMany
  nfs:
    server: nfs-server.example.com
    path: /exported/path
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nfs-pvc
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 5Gi

Use Cases:
- Shared file systems for distributed applications.
- Centralized logging or cache storage.

Cloud Provider Volumes

Cloud providers like AWS, GCP, and Azure offer native storage solutions (e.g., EBS, PD, Disk). These volumes are typically managed via cloud-specific controllers and require integration with Kubernetes.

Example (AWS EBS):

apiVersion: v1
kind: PersistentVolume
metadata:
  name: ebs-pv
spec:
  capacity:
    storage: 20Gi
  accessModes:
    - ReadWriteOnce
  awsElasticBlockStore:
    volumeID: vol-12345678
    fsType: ext4

Use Cases:
- High-performance, durable storage for databases.
- Integration with cloud-native tools and services.

CSI (Container Storage Interface) Integration

What is CSI?

CSI is a standard API for attaching storage systems to Kubernetes, enabling dynamic provisioning, plugin extensibility, and cross-cloud compatibility. It replaces older "in-tree" drivers, which are now deprecated.

Key Components

  1. Driver: Manages storage operations (e.g., creating, deleting volumes).
  2. Controller Plugin: Handles volume provisioning and snapshot management.
  3. Node Plugin: Mounts volumes on worker nodes.

Dynamic Provisioning with StorageClasses

CSI enables dynamic provisioning via StorageClass objects, which define storage policies.

Example:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: aws-sc
provisioner: ebs.csi.aws.com
parameters:
  type: gp2
  iops: "1000"
reclaimPolicy: Retain

Use Cases:
- Automating storage provisioning based on workload needs.
- Supporting heterogeneous storage backends (e.g., AWS, Azure, OpenStack).

CSI vs. In-Tree Drivers

  • CSI: Modern, standardized, and cloud-agnostic. Supports dynamic provisioning and advanced features like snapshots.
  • In-Tree Drivers: Legacy, provider-specific, and deprecated. Limited to static provisioning and basic operations.

Key takeaways

  • Use hostPath for local development, but avoid it in production.
  • NFS and cloud provider volumes are ideal for shared or high-performance storage.
  • CSI standardizes storage integration, enabling dynamic provisioning and cross-cloud compatibility.
  • Migrate from in-tree drivers to CSI for future-proof, scalable storage solutions.