Persistent Volumes

Rackspace Spot provides four out-of-the-box storage classes for persistent volumes, in addition to the ephemeral storage available on worker nodes.

Ephemeral Storage

Spot worker nodes have a certain amount of local storage that can be used as ephemeral storage. Please note that this is intended to be available as temporary storage, and data stored here will be lost when nodes are de-provisioned. Ephemeral storage is also not intended to store large amounts of data, since that space must be shared with containers and for other purposes.

Persistent Volume Storage Classes

Spot provides the following storage classes with their performance characteristics and supported access modes:

Access Mode Support

All storage classes support only ReadWriteOnce access mode:

• ✅ ReadWriteOnce (RWO): Volume can be mounted as read-write by a single node
• ❌ ReadWriteMany (RWX): Not currently supported
• ❌ ReadOnlyMany (ROX): Not currently supported

NOTE While only one node can mount the volume, multiple pods can access the same volume if they are scheduled on the same node.

Pricing Overview

Persistent volumes are billed monthly based on the provisioned storage size, regardless of actual usage. Billing continues until the PVC is deleted.

Cost Examples

Cost Calculation

• Formula: Volume Size (GB) × Price per GB-month
• Example: 100GB ssd-large volume = 100GB × $0.06/GB-mo = $6.00/month
• Billing: Charged monthly, prorated to the second

Cost Optimization Tips:

• Use sata storage for cost-effective, less performance-critical data
• Choose appropriate volume sizes to avoid overpaying for unused capacity
• Delete unused PVCs promptly to avoid ongoing charges

For complete pricing details, see Rackspace Spot - Pricing.

Default Storage Class

The 'ssd' storage class is the default in gen-1 datacenters, and will be used if you don't specify an alternate storage class in your persistent volume claim. In gen-2 datacenters, ssdv2-performance is the default storage class.

Creating Persistent Volume Claims

Basic PVC Example (Default Storage Class)

Here is an example of a persistent volume claim that uses the default storage class:

apiVersion: v1

kind: PersistentVolumeClaim

metadata:

  name: app-storage

spec:

  accessModes:

    - ReadWriteOnce  # Only supported access mode

  resources:

    requests:

      storage: 10Gi  # Minimum 5GB for Gen-1, 10GB for Gen-2

Specifying Different Storage Classes

Gen-1 Examples:

SSD Storage (5GB-20GB):

apiVersion: v1

kind: PersistentVolumeClaim

metadata:

  name: small-ssd-storage

spec:

  storageClassName: ssd

  accessModes:

    - ReadWriteOnce

  resources:

    requests:

      storage: 15Gi

Large SSD Storage (>=50GB):

apiVersion: v1

kind: PersistentVolumeClaim

metadata:

  name: large-ssd-storage

spec:

  storageClassName: ssd-large

  accessModes:

    - ReadWriteOnce

  resources:

    requests:

      storage: 100Gi

SATA Storage (Cost-effective):

apiVersion: v1

kind: PersistentVolumeClaim

metadata:

  name: sata-storage

spec:

  storageClassName: sata

  accessModes:

    - ReadWriteOnce

  resources:

    requests:

      storage: 20Gi

Gen-2 Examples:

High-Performance Storage (10 IOPS/GB):

apiVersion: v1

kind: PersistentVolumeClaim

metadata:

  name: high-perf-storage

spec:

  storageClassName: ssdv2-performance  # Default for Gen-2

  accessModes:

    - ReadWriteOnce

  resources:

    requests:

      storage: 50Gi  # Will provide 500 IOPS

Standard NVMe Storage (1 IOPS/GB):

apiVersion: v1

kind: PersistentVolumeClaim

metadata:

  name: standard-nvme-storage

spec:

  storageClassName: ssdv2

  accessModes:

    - ReadWriteOnce

  resources:

    requests:

      storage: 100Gi  # Will provide 100 IOPS

Volume Management Operations

Creating Volumes

Volumes are created automatically when you apply a PersistentVolumeClaim. The volume will be provisioned based on your specified storage class and size requirements.

kubectl apply -f my-pvc.yaml

kubectl get pvc  # Check provisioning status

Checking Volume Status

Monitor your persistent volume claims and their bound volumes:

# Check PVC status

kubectl get pvc

​

# Get detailed information

kubectl describe pvc <pvc-name>

​

# Check bound persistent volumes

kubectl get pv

Attaching Volumes to Pods

Reference the PVC in your pod or deployment specification:

apiVersion: v1

kind: Pod

metadata:

  name: app-pod

spec:

  containers:

  - name: app

    image: nginx

    volumeMounts:

    - name: app-storage

      mountPath: /data

  volumes:

  - name: app-storage

    persistentVolumeClaim:

      claimName: app-storage  # References the PVC name

Deleting Volumes

⚠️ Warning: Deleting a PVC will permanently delete the underlying volume and all data.

# Delete the PVC (this will also delete the underlying volume)

kubectl delete pvc <pvc-name>

​

# Verify deletion

kubectl get pvc

kubectl get pv

Troubleshooting

Common Issues

PVC Stuck in Pending State

If your PVC remains in Pending status:

1. Check storage class availability: kubectl get storageclass kubectl describe pvc <pvc-name>

2. Verify volume size requirements:

• Gen-1: Minimum 5GB, avoid 20GB-50GB range
• Gen-2: Minimum 10GB

3. Check capacity limits: Some regions have limited capacity for certain storage classes

PVC Attachment Issues

Known issue where PVCs may get stuck during attachment. If you encounter this:

1. Check pod events: kubectl describe pod <pod-name> kubectl get events --sort-by='.lastTimestamp'

2. Try recycling the affected node:

• In the Spot dashboard, navigate to your Cloudspace
• Find the affected node and select "Recycle Node"
• This will terminate and replace the problematic node

3. Verify volume mount path: Ensure the mount path in your pod spec doesn't conflict with existing directories

Performance Issues

If experiencing slow I/O performance:

1. Consider upgrading storage class:

• Gen-1: Switch from sata to ssd or ssd-large
• Gen-2: Use ssdv2-performance for higher IOPS

2. Check volume size: Larger volumes typically provide better performance, especially for Gen-2 storage classes

Best Practices

Storage Class Selection

• High IOPS workloads: Use ssdv2-performance (Gen-2) for databases and high-performance applications
• Standard workloads: Use default storage classes (ssd for Gen-1, ssdv2-performance for Gen-2)
• Cost optimization: Use sata storage classes for less performance-critical data
• Large datasets: Use ssd-large or sata-large for volumes >= 50GB

Volume Sizing

• Plan for growth: Consider future storage needs when sizing volumes
• IOPS calculation: For Gen-2 storage, calculate required IOPS (volume size × IOPS per GB)
• Avoid size gaps:
• Gen-1: Avoid 20GB-50GB range (not supported)
• Gen-2: Use >= 10GB for optimal performance

Data Protection

• Backup strategy: Implement regular backup procedures for critical data
• Multi-pod access: If multiple pods need access, ensure they're scheduled on the same node or consider alternative storage solutions
• Persistent data: Use persistent volumes for data that must survive pod restarts and node failures

Regional Considerations

• London Gen-1: Prefer ssd-large and sata-large due to limited capacity for smaller volumes
• Gen-2 regions: Take advantage of improved performance with ssdv2-performance storage class

Limitations and Constraints

1. Access Modes: Only ReadWriteOnce is supported across all storage classes
2. Volume Size Restrictions:

• Gen-1: Minimum 5GB, gap between 20GB-50GB not supported
• Gen-2: Minimum 10GB

3. Regional Capacity: Some regions may have limited availability for specific storage classes
4. Node Affinity: Volumes can only be accessed by pods on the node where the volume is attached
5. No Volume Expansion: Volume resizing is not currently supported - plan your storage requirements carefully