Skip to main content

Storage and object storage

Provide block, shared, and S3-compatible storage through standard Kubernetes APIs.

Kube-DC uses Ceph on your hardware for its storage layer. The platform team defines storage classes, topology, and replication. Tenants request storage through Kubernetes APIs within their assigned quotas.

Block storage​

  • PersistentVolumes for containers and disks for VMs from a replicated Ceph RBD pool.
  • Online volume expansion.
  • Storage classes are operator-defined: you decide which tiers exist (replicated, node-local, performance) and what backs them — the platform runs on the disks and failure domains you give it.

Shared (read-write-many) storage​

Operator-defined RWX storage classes serve the cases single-writer volumes can't — each with the access mode and backend appropriate to its semantics:

  • Multi-pod shared filesystems — several pods writing the same volume (content stores, shared uploads, legacy apps that expect a shared disk).
  • Migration-eligible VM disks — a VM whose disk is on the shared block class is eligible for live migration between hosts (see the Virtual Machines datasheet).

S3-compatible object storage​

  • Per-project buckets provisioned through a standard ObjectBucketClaim — credentials arrive as a Secret and ConfigMap the workload mounts; no manual account management.
  • The platform's own services use the same storage: database backups and managed-cluster snapshots land in per-project buckets.
  • Typical tenant uses: application assets, exports, log archives, backup targets.
Storage services from operator-provided disksOperator-provided SSD, NVMe, or HDD capacity forms the Ceph storage layer. Ceph publishes block volumes for Pods and virtual machines, shared read-write storage for shared applications and migration-eligible VM disks, and S3-compatible per-Project buckets used by applications, backups, and snapshots.PHYSICAL CAPACITY · STANDARD CONSUMPTIONYour disksSSD · NVMe · HDDCeph storage layertopology + replicationBlock volumesPVCs · VM disksRWX storageshared filesystemsmigratable VM disksS3 object storageProject bucketsapps · backups
The operator's disk topology feeds Ceph, which publishes block, shared and S3 services to Project workloads through standard Kubernetes storage interfaces.

Snapshots, clones and images​

  • Volume snapshots through the standard Kubernetes snapshot API — point-in-time copies of workload and VM volumes.
  • Instant clones: new volumes from snapshots without duplicating data — the mechanism behind the prepared-OS-image catalog and VM provisioning without image downloads.
  • Prepared images are published per project as snapshots.

Capacity and quota​

Storage consumption counts against organization plans and project quotas like CPU and memory. Object-storage capacity is governed per organization and requires its own capacity planning. How many disks, which tiers, what replication — these are platform-team decisions made against your hardware; capacity and durability are properties of the topology your team designs, validated in the architecture review.

Data protection posture​

Storage replication protects against component failure within the platform; it is not a backup. The protection stack is layered:

LayerMechanismOwner
Component failureCeph replication per your topologyPlatform team
Point-in-time copiesScheduled jobs run by platform controllers; on-demand snapshots and restores initiated by tenantsShared
Site/storage lossCopied by your configured enterprise backup integration via S3 endpointsYour backup team

Responsibilities​

ConcernYour platform teamTenant
Disks, tiers, replication, failure domains✅—
Storage classes and quotas✅ definesconsumes within quota
Volume/bucket provisioningAutomatic via API✅ requests
Snapshots and clonesAPIs provided✅ initiates
Backup of application dataS3 + snapshot APIs provided✅ owns