Managing storage is a distinct problem from managing compute resources. FaktorZ leverages the Kubernetes persistent volume (PV) framework to allow administrators to provision persistent storage for a cluster. Using persistent volume claims (PVCs), developers can request PV resources without having specific knowledge of the underlying storage infrastructure.
PVCs are specific to a project and are created and used by developers as a means to use a PV. PV resources on their own are not scoped to any single project; they can be shared across the entire FaktorZ cluster and claimed from any project. After a PV has been bound to a PVC, however, that PV cannot then be bound to additional PVCs. This has the effect of scoping a bound PV to a single namespace (that of the binding project).
PVs are defined by a
PersistentVolume API object, which represents a piece
of existing networked storage in the cluster that has been provisioned by an
administrator. It is a resource in the cluster just like a node is a cluster
resource. PVs are volume plug-ins like
Volumes, but have a lifecycle
independent of any individual
pod that uses the PV. PV
objects capture the details of the implementation of the storage, be that NFS,
iSCSI, or a cloud-provider-specific storage system.
High-availability of storage in the infrastructure is left to the underlying storage provider.
PVCs are defined by a
PersistentVolumeClaim API object, which represents a
request for storage by a developer. It is similar to a pod in that pods consume
node resources and PVCs consume PV resources. For example, pods can request
specific levels of resources (e.g., CPU and memory), while PVCs can request
specific storage capacity and access
modes (e.g, they can be mounted once read/write or many times read-only).
PVs are resources in the cluster. PVCs are requests for those resources and also act as claim checks to the resource. The interaction between PVs and PVCs have the following lifecycle.
In response to requests from a developer defined in a PVC, a cluster administrator configures one or more dynamic provisioners that provision storage and a matching PV.
Alternatively, a cluster administrator can create a number of PVs in advance, which carry the details of the real storage that is available for use by cluster users. PVs exist in the API and are available for consumption.
A user creates a
PersistentVolumeClaim with a specific amount of storage
requested and with certain access modes and optionally a
control loop in the master watches for new PVCs. It either finds a matching PV
or waits for a provisioner for the
StorageClass to create one, then binds them
The user will always get at least what they asked for, but the volume might be in excess of what was requested. This is especially true with manually provisioned PVs. To minimize the excess, FaktorZ binds to the smallest PV that matches all other criteria.
Claims remain unbound indefinitely if a matching volume does not exist or cannot
be created with any available provisioner servicing a
are bound as matching volumes become available. For example, a cluster
with many manually provisioned 50Gi volumes would not match a PVC requesting
100Gi. The PVC can be bound when a 100Gi PV is added to the cluster.
Pods use claims as volumes. The cluster inspects the claim to find the bound volume and mounts that volume for a pod. For those 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. Users schedule pods and access their claimed
PVs by including a
persistentVolumeClaim in their pod’s volumes block. See
below for syntax details.
When a user is done with a volume, they can delete the PVC object from the API which allows reclamation of the resource. The volume is considered "released" when the claim is deleted, but it is not yet available for another claim. The previous claimant’s data remains on the volume which must be handled according to policy.
The reclaim policy of a
PersistentVolume tells the cluster what to do with
the volume after it is released. Volumes reclaim policy can either be
Retained reclaim policy allows manual reclamation of the resource for those volume plug-ins that support it.
Deleted reclaim policy deletes both the
PersistentVolume object from FaktorZ and the associated storage asset in external infrastructure, such as AWS EBS, GCE PD, or Cinder volume.
Volumes that were dynamically provisioned are always deleted.