The default StorageClass — implicit bindings and the production risk

The default StorageClass is the implicit binding target for PVCs that do not specify storageClassName. It is useful for development; it is dangerous for production. This lesson walks the default, its risks, and the production discipline.

How the default is selected

The default StorageClass is set by an annotation:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: standard
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"

Only one StorageClass can be the default at a time. The binding controller treats the default as the implicit storageClassName for any PVC that does not specify one:

# PVC without storageClassName — binds to the default
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: data
spec:
  accessModes: ["ReadWriteOnce"]
  resources:
    requests:
      storage: 10Gi

The binding controller sees no storageClassName and uses the cluster default.

The production risk

The risk of relying on the default:

• Implicit dependency: a workload’s storage behavior depends on a cluster-wide annotation. Changing the default changes every unbound PVC’s behavior.
• Inconsistency across environments: the default in staging may be standard; the default in production may be premium. A workload deployed via the same Helm chart binds to different backends.
• Hidden cost: a PVC without explicit StorageClass may bind to a premium tier, incurring unexpected costs.

# Find PVCs relying on the default
kubectl get pvc -A -o json | \
  jq '.items[] | select(.spec.storageClassName == null) |
    {name: .metadata.name, namespace: .metadata.namespace}'

The output is the list of PVCs that should specify their StorageClass explicitly.

The discipline

The production discipline:

• Every production PVC specifies storageClassName. No implicit defaults.
• The default StorageClass is for development. New namespaces can use it; production namespaces must not.
• Audits catch implicit bindings. A regular audit (e.g., weekly) finds PVCs without storageClassName and remediates them.

Changing the default

To set a new default:

# Set the new default
kubectl annotate storageclass new-default \
  storageclass.kubernetes.io/is-default-class="true" --overwrite

# Remove the old default
kubectl annotate storageclass old-default \
  storageclass.kubernetes.io/is-default-class="false" --overwrite

Existing PVCs that were bound to the old default are not affected; only new PVCs without storageClassName will bind to the new default.

Disabling the default

To disable the default entirely (force all PVCs to be explicit):

# Name of the StorageClass currently marked default:
SC=standard

# Remove the is-default-class annotation
kubectl annotate storageclass "$SC" \
  storageclass.kubernetes.io/is-default-class="false" --overwrite

# Or, delete the default StorageClass
kubectl delete storageclass "$SC"

After this change, any PVC without storageClassName is Pending. The operator sees the error and remediates by specifying a StorageClass.

Quiz

Production discipline

• Every production PVC specifies storageClassName. No implicit defaults.
• The default StorageClass is for development. It is not used by production workloads.
• Audit PVCs for implicit bindings. Weekly or monthly audits catch PVCs without explicit StorageClass.
• Changing the default is a cluster-wide change. Communicate; document; audit the impact.
• Consider disabling the default. Force every PVC to be explicit; prevent accidental implicit bindings.