Skip to main content

SCS KaaS default storage class

Introduction

Cluster consumers can request persistent storage via PersistentVolumeClaims which is provisioned automatically by cloud-provided automation. Storage requirements may vary across use cases, so there is the concept of StorageClasses. StorageClasses define some set of storage properties. So, consumers can choose one of these depending on the use case.

Kubernetes documentation

Motivation

While often times, consumers will choose a StorageClass explicitly, usually, there is also a default StorageClass to fall back on in case it is not chosen explicitly (that is, when storageClassName is not set on the PersistentVolumeClaim).

This document attempts to define the properties this default StorageClass should have.

Decision

The default StorageClass is made default using the storageclass.kubernetes.io/is-default-class annotation, following Kubernetes upstream. Hence, standardizing its name is not required for the intents of this standard.

  • ReadWriteOnce must be a supported access mode
  • volume must be protected against data loss due to hardware failures of a single disk or host
  • volume must not be bound to the lifecycle of a Kubernetes Node

Hence,

  • ...volume must not be backed by local storage on the Kubernetes Node VM itself
  • ...volume may be backed by some kind of redundant storage within an AZ, across hosts
  • ...volume may be backed by some kind of redundant storage across AZ's
  • NO fixed guarantees regarding latency/bandwidth/IOPS/...

Generally, customers should be able to expect low-tier performance without pricing surprises.

This document does not describe performance related properties. This will be done in another document which is yet to be created.

Conformance Tests

The script k8s-default-storage-class-check.py requires a kubeconfig file with connection details for the Kubernetes cluster that should be checked for conformance. It will check for a default storage class and use the associated storage provider to try to create and mount a PersistentVolumeClaim with the aforementioned properties to a container in a Pod. After it is done, it cleans up the resources. Rule violations will be reported on various logging channels: ERROR for mandatory rules and INFO for recommended rules. An exit code of zero indicates that the standard has been met.