Documentation Index
Fetch the complete documentation index at: https://ubicloud.com/docs/llms.txt
Use this file to discover all available pages before exploring further.
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 support@ubicloud.com.
-
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.