CloudRaya Documentation

Storage

KubeRaya provides a flexible approach to storage that follows Kubernetes-native patterns, allowing you to run both stateless and stateful workloads while maintaining clear separation between platform-managed infrastructure and application-level data handling.

This page explains the storage models currently available in KubeRaya, how they work in real deployments, and how to design reliable persistence strategies for production environments.

Overview

In Kubernetes, storage is not a single service but a set of abstractions that allow applications to request and consume persistent data.

KubeRaya follows this model by supporting:

  • Node-local storage (default)
  • Object storage integration via S3-compatible APIs
  • External CSI-based storage backends (advanced use cases)

Each model serves different workload profiles, from lightweight services to production-grade, stateful applications.

Storage Models Available in KubeRaya

1. Node-Local Storage (Default)

By default, workloads in KubeRaya use disk storage that is local to the worker node.

How it works:

  • Pods write data to storage attached to the node they are scheduled on
  • No external storage service is required
  • Simple and fast for development and lightweight workloads

Best for:

  • Development and testing
  • Caching and temporary data
  • Stateless applications
  • Non-critical stateful services

Limitations:

  • Data is tied to a specific node
  • If a node is replaced or rescheduled, data may be lost
  • Not suitable for high-availability or portable workloads

2. Object Storage Integration (StorageRaya)

KubeRaya supports persistent data storage using Object Storage (StorageRaya) through S3-compatible APIs.

This model treats storage as an external service, accessed directly by your application rather than mounted as a filesystem.

How it works:

  • Applications connect to Object Storage using access keys and service endpoints
  • Data is stored independently of the Kubernetes cluster lifecycle
  • Works across pods, nodes, and clusters

Best for:

  • Media and asset storage
  • Backups and archives
  • Logs and analytics data
  • Application artifacts and exports

Benefits:

  • Highly durable and scalable
  • Cluster-independent persistence
  • Works naturally with cloud-native and microservice architectures

πŸ“„ See: StorageRaya

3. External CSI-Based Storage (Advanced)

For advanced and enterprise deployments, KubeRaya allows the use of external Kubernetes CSI (Container Storage Interface) drivers.

This enables integration with third-party or self-managed storage platforms that provide:

  • Block storage
  • Network file systems
  • Distributed storage backends

How it works:

  • A CSI driver is installed at the cluster level
  • StorageClasses, PersistentVolumes (PV), and PersistentVolumeClaims (PVC) are defined inside Kubernetes
  • Pods dynamically request storage through Kubernetes-native APIs
Note

External CSI drivers are installed and operated by you inside the Kubernetes cluster. CloudRaya provides the managed KubeRaya environment, but does not manage the CSI driver lifecycle or the external storage backend.

Best for:

  • Production stateful workloads
  • Databases and message queues
  • Enterprise applications requiring volume portability and high availability

Requirements:

  • Kubernetes administration knowledge
  • Cluster-level access
  • External storage infrastructure or provider

CloudRaya Block Storage Integration (Current Status)

At this time, CloudRaya Block Storage is not exposed as a native Kubernetes CSI backend through the KubeRaya control plane.

This means:

  • Block storage is used as node-level disk, not as dynamically provisioned Persistent Volumes
  • Kubernetes resources such as StorageClasses, PersistentVolumes, and PersistentVolumeClaims are not managed directly through CloudRaya’s platform interface

For Kubernetes-native persistent volumes, external CSI drivers must be used.

πŸ’‘

This design keeps KubeRaya aligned with standard Kubernetes storage architecture while allowing advanced users to integrate enterprise-grade storage solutions as needed.

Choosing the Right Storage Model

Workload TypeRecommended Model
Stateless applicationsNode-local storage
Media, backups, logsObject Storage (StorageRaya)
DatabasesExternal CSI-based storage
HA enterprise systemsExternal CSI-based storage

Architecture Perspective

KubeRaya separates responsibilities clearly:

  • CloudRaya Platform manages:
    • Cluster lifecycle
    • Node infrastructure
    • Networking and scaling
  • Kubernetes Control Plane manages:
    • PersistentVolumes and PersistentVolumeClaims
    • StorageClasses
    • Pod-to-storage binding

This model ensures compatibility with upstream Kubernetes standards and avoids vendor lock-in at the storage layer.

Security Considerations

When working with persistent storage:

  • Store Object Storage credentials in Kubernetes Secrets
  • Restrict access using RBAC for CSI driver configuration
  • Use encrypted storage backends for sensitive data
  • Limit pod permissions to only required volumes or endpoints

Future Capability Direction

CloudRaya is evaluating native Kubernetes CSI integration for its block storage platform.

This would allow KubeRaya to provide cloud-managed StorageClasses that can be used directly by Kubernetes.

With this model, users would be able to:

  • Create PersistentVolumeClaims without installing external CSI drivers
  • Automatically provision block volumes from CloudRaya storage
  • Attach and mount volumes to pods through standard Kubernetes workflows
  • Manage the full volume lifecycle using Kubernetes-native APIs

This approach is intended to simplify stateful workload deployment while preserving compatibility with upstream Kubernetes storage standards.

πŸ“„ KubeRaya Cluster Architecture & Concepts

πŸ“„ StorageRaya (Object Storage)

πŸ“„ Managing Clusters in KubeRaya

πŸ“„ Kubernetes Best Practices

Β© 2026 CloudRaya Product Team. All rights reserved.

On this page