Storage Basics: OpenStack Cinder and Kubernetes PV/PVC Relationship Explained

#IaaS #Onboarding #Concepts #Cinder

1. Basic Storage Types

Storage can be broadly categorized into three types:

  1. Block Storage
    • Data is stored in “block units.”
    • From the OS perspective, it looks like a local disk.
    • Suitable for workloads requiring fast read/write, such as VM disks and databases.
    • Examples: AWS EBS, OpenStack Cinder.
  2. File Storage
    • Data is stored in a file/folder structure and shared across multiple servers.
    • Examples: NFS, Amazon EFS.
  3. Object Storage
    • Data is stored as “objects (file + metadata + ID).”
    • Highly scalable and suitable for static data such as images and backups.
    • Examples: AWS S3, OpenStack Swift.

2. OpenStack Cinder

  • OpenStack’s block storage service.
  • Provides persistent disk volumes that can be attached to and detached from VM instances.
  • Serves the same role as AWS EBS.
  • Key features:
    • Volume creation/deletion
    • Attach/detach
    • Snapshots and replication
    • Support for various backends (Ceph RBD, LVM, NetApp, etc.)

👉 In short, if you want to attach a “disk (like EBS)” to a VM in an OpenStack environment, you handle it through Cinder via API/CLI.

3. Kubernetes Persistent Storage (PV/PVC)

  • In Kubernetes, when a Pod dies, its storage is lost by default → persistence is required.
  • The structure that solves this is PV/PVC.
  1. PersistentVolume (PV)
    • A storage resource registered in the cluster.
    • A “representative object” connected to actual storage (Cinder, NFS, EBS, etc.).
  2. PersistentVolumeClaim (PVC)
    • Storage requirements requested by a developer (e.g., 10Gi, ReadWriteOnce).
    • When a PVC is created, it is matched with an appropriate PV.
  3. StorageClass + Dynamic Provisioning
    • Instead of having an admin pre-create PVs, storage is automatically created when a PVC is submitted.
    • Defines which provisioner (Cinder, EBS, etc.) to use in StorageClass.
    • PVC created → StorageClass checked → Kubernetes calls Cinder API → new volume created → PV automatically matched.

4. Connecting Cinder and Kubernetes

  • When Kubernetes runs on top of OpenStack, Cinder becomes the actual backend storage for PVs.
  • Flow:
    1. User creates a PVC → needs a 10Gi volume.
    2. The StorageClass linked to the PVC uses the kubernetes.io/cinder provisioner.
    3. Kubernetes calls the OpenStack Cinder API → creates a new block volume.
    4. A PV object is automatically created and bound to the PVC.
    5. Pod mounts the PVC → uses the Cinder volume like a disk.

👉 In summary: Cinder = the actual storage provider, PV = the abstracted storage resource in Kubernetes, PVC = the user’s storage request.

5. OpenStack Cinder vs AWS EBS (Comparing Storage Integration in Kubernetes)

5-1. Basic Definitions

  • Cinder: OpenStack’s block storage service.
  • EBS: AWS’s block storage service.

Both serve the same role in that they provide persistent disks that can be attached to VMs/Pods.

5-2. Kubernetes Integration Structure

CategoryOpenStack EnvironmentAWS Environment
Storage ServiceCinder (Block Storage)EBS (Elastic Block Store)
K8s PV Creation MethodUses cinder provisionerUses ebs.csi.aws.com CSI driver
Dynamic ProvisioningStorageClass → kubernetes.io/cinderStorageClass → ebs.csi.aws.com
Actual VolumeBlock volume created via Cinder API callEBS volume created via EBS API call
Pod ConnectionCinder volume attach → PV/PVC match → Pod mountEBS volume attach → PV/PVC match → Pod mount

5-3. Flow Comparison (Dynamic Provisioning)

[사용자 PVC 생성]
        |
        v
[Kubernetes Controller]
        |
        |--- OpenStack 환경 ---> [Cinder API] → 블록 볼륨 생성
        |
        |--- AWS 환경 ---------> [EBS API] → 블록 볼륨 생성
        |
        v
[PV 자동 생성 및 PVC 바인딩]
        |
        v
[Pod에 attach & mount]

5-4. One-Line Summary

  • Think of Cinder as OpenStack’s EBS and it becomes easy to understand.
  • Both are abstracted through PV/PVC in Kubernetes,
  • And dynamic provisioning is available via StorageClass.

👉 From Kubernetes’ perspective, the flow of PVC → StorageClass → backend volume creation is the same;

the backend is simply Cinder for OpenStack and EBS for AWS.

5-5. Block Storage Comparison: Cinder vs EBS vs Local Disk (NFS, etc.)

CategoryOpenStack CinderAWS EBSLocal/NFS (On-Premises Shared Storage)
PlatformOpenStack (Private Cloud)AWS (Public Cloud)On-premises server/VM environment
Storage TypeBlock storageBlock storageFile storage (NFS), local block disk
Use CasesVM disks, DB storageEC2 disks, DB storageNAS/NFS shared files, single-server local SSD/HDD
Provisioning Method (K8s)StorageClass kubernetes.io/cinderCSI Driver ebs.csi.aws.comNFS: nfs-subdir-external-provisioner, etc.
Dynamic Provisioning SupportYes (via Cinder API call)Yes (via EBS API call)Yes (NFS provisioner, Ceph RBD, GlusterFS, etc.)
BackendLVM, Ceph RBD, NetApp, Dell EMC, etc.AWS-native (SSD, gp2/gp3/io2)Self-built: NFS server, SAN, Ceph, GlusterFS
High AvailabilityMulti-AZ support (virtualization-based)Multi-AZ support (note: EBS is AZ-scoped, cannot be shared across AZs)NFS server HA configuration required (manual)
PerformanceVaries by backend (Ceph = scalable, high-performance)High-performance SSD, IOPS/Throughput options availableLocal SSD is fast; NFS depends on network speed
ScalabilityUnlimited scaling via cloud APIUnlimited scaling via AWS APILimited by server/storage capacity
Management ConvenienceManaged by OpenStack administratorsAWS-managed (fully managed)Self-managed required (manual backup/HA setup)
Primary Use CasePrivate cloud enterprise environmentsAWS-based applicationsOn-premises apps, Kubernetes practice/small-scale environments

One-Line Summary

  • Cinder: OpenStack’s block storage, optimized for private cloud.
  • EBS: AWS’s block storage, used as a managed service in public cloud.
  • NFS/Local Disk: Suitable for on-premises/small-scale environments; requires self-management.