Skip to main content

​
Overview

This document describes how PersistentVolumeClaims (PVCs) work in Ubicloud Managed Kubernetes, including usage, limitations and behavior during failures. All Ubicloud Kubernetes nodes include bundled local NVMe storage. Persistent volumes are supported in preview via the UbiCSI implementation using the local NVMe storage. Generic ephemeral volumes are also available for temporary storage tied to pod lifecycles.

​
Quickstart

For a quickstart example, we will install prometheus-stack using its helm chart. 
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update
kubectl create namespace monitoring
helm install prometheus prometheus-community/prometheus --namespace monitoring
Once the installation is complete, run the following command to list the PVCs: 
$ kubectl -n monitoring get pvc
NAME                                STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS        VOLUMEATTRIBUTESCLASS   AGE
prometheus-server                   Bound    pvc-6c92f4d4-7db2-4229-be1a-8826739322df   8Gi        RWO            ubicloud-standard   <unset>                 70s
storage-prometheus-alertmanager-0   Bound    pvc-4d6d879d-0961-4b29-a0d7-d4954a8c9476   2Gi        RWO            ubicloud-standard   <unset>                 69s

​
Limitations and Considerations

  • UbiCSI is in preview, so features and behavior may evolve over time.
  • PVCs are limited to 10 GB by default to ensure reliable data migration and avoid network strain. Larger volumes can be requested via [email protected].
  • Data is stored locally and not replicated. If a node is permanently lost due to critical hardware failure, any data on that node is also lost.
  • Volume Expansion is not supported yet.
Every Ubicloud Kubernetes Cluster comes with the UbiCSI add-on pre-installed and a StorageClass is defined for creating PVCs: 
$ kubectl get storageclass
NAME                          PROVISIONER        RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
ubicloud-standard (default)   csi.ubicloud.com   Delete          WaitForFirstConsumer   false                  2h
All UbiCSI components are deployed in the ubicsi namespace to separate them from other workloads. The source code for UbiCSI is available in Ubicloud repository.

​
How it works

UbiCSI driver provisions PersistentVolumeClaims on local volumes for speed and automatically migrating data when a node becomes unschedulable. This combines the performance of local storage with the reliability of managed persistence. By using node affinities on the PersistentVolume, the PVC stays bound to that node, ensuring the pod always runs on the same node during normal restarts and as long as the node remains schedulable.

​
Data Durability and Migration

For data durability, UbiCSI continuously monitors node health. When a pod’s node becomes unschedulable, UbiCSI automatically reschedules the pod onto a healthy node and transfers its data. This process ensures workloads stay available and data persists even when nodes fail or are taken out of service. When migration begins, data is copied in the background to the new node. During this time, the pod may temporarily return errors such as “Old PV data is not copied yet” - these indicate that migration is still in progress. Users should not force delete or restart the pod, as this can interrupt the copy. Once migration completes, the pod resumes normal operation with its data fully restored on the new node.