---
# System prepended metadata

title: Kubernetes Concepts

---

# Kubernetes Concepts

## Networking

## Storage

### Persistent Volumes

**PersistentVolume (PV)** is a piece of storage in the cluster that has been provisioned statically by administrator or dynamically provisioned using **Storage Classes**. PVs are like Volumes, but have a lifecycle independent of an individual Pod that using it.

### Persistent Volume Claim

A **PersistentVolumeClaim (PVC)** is a request from user to consume abstract storage. PVC can request specific *storage size* and *access modes*. Cluster administrators need to be able to offer a variety of PersistentVolumes that differ in more ways than just size and access modes, without exposing users to the details of how those volumes are implemented.

### Provisioning

There are two ways PVs may be provisioned: either statically or dynamically.

#### Static Provisioning

A cluster administrator creates a number of PVs. They carry the details of the real storage, which is available for use by cluster users. They exist in the Kubernetes API and are available for consumption.

#### Dynamic Provisioning
When none of the static PVs the administrator created match a user's PersistentVolumeClaim, the cluster may try to dynamically provision a volume specially for the PVC. This provisioning is based on **StorageClasses**.

The PVC must request a storage class and the administrator must have created and configured that class for dynamic provisioning. Claims that request the class `""` effectively disable dynamic provisioning.

To enable dynamic storage provisioning based on storage class, the cluster administrator needs to enable the `DefaultStorageClass` admission controller on the API server.

:::info 
**Default Storage Class**:
An administrator can mark a specific StorageClass as default by adding the `storageclass.kubernetes.io/is-default-class` annotation. When a default StorageClass exists in a cluster and a user creates a PVC with *storageClassName* unspecified, the DefaultStorageClass admission controller automatically adds the storageClassName to the default storage class.



:::
### Binding

A user has either created or been dynamically provisioned a PersistentVolumeClaim with a specific amount of storage requested and with certain access modes. A control loop in the master now watches for new PVCs, finds a matching PV (if possible), and binds them together.

Claims will remain unbound indefinitely if a matching volume does not exist. Claims will be bound as matching volumes become available. For example, a cluster provisioned with many 50Gi PVs would not match a PVC requesting 100Gi. The PVC can be bounded when a 100Gi PV is added to the cluster.

### Usage

Pods use PVC as volumes. The cluster inspects the claim to find the bound volume and mounts that volume to a Pod. For volumes that support multiple access modes, the user specifies which mode is desired when using their claim as a volume in a Pod. Once a user has a claim and that claim is bound, the bound PV belongs to the user for as long as they need it.


