Volumes

  • hostPath mounted volumes are mounted from the host. However, this is not recommended as each node’s directory structure and file contents would be different, since a container can be scheduled on any of the nodes.

  • To get around this issue, Kubernetes supports a number of shared folder solutions such as:

    • NFS Mounted Volume, iscsi, local (disk, partition or directory)

    • GlusterFS

    • Flocker

    • CephFS

    • Cinder

    • Scaleio

    • AWS storage types, e.g. EBS

      volumes:
- name: data-volume
  awsElasticBlockStore:
    volumeID: <volume-id>
    fsType: ext4

    • azureDisk, azureFile (SMB 2.1 & 3.0)

    • vsphereVolume

    • gcePersistentDisk

Persistent Volumes

  • Persistent Volumes (PV) are a cluster wide pool of storage managed by an Kubernetes administrator. Users can then use these persistent volumes with Persistent Volume Claims (PVC).

  • PVs have an independent scope and life cycle from PVCs.

  • PVs can have different access modes:

    • ReadOnlyMany: Only a single node can mount the volume for reading and writing.

    • ReadWriteOnce: Multiple nodes can mount the volume for reading.

    • ReadWriteMany: Multiple nodes can mount the volume for both reading and writing.

  • PVs can also have different reclaim policies:

    • Retain: The persistent volume is not deleted. The administrator can carry out clean up.

    • Delete: The persistent volume is removed from the external asset.

    • Recycle: This policy is deprecated. Instead, dynamic provisioning should be used.

Persistent Volume Claim

  • Every Persistent Volume Claim is bound to a single Persistent Volume.

  • Claiming a Persistent Volume through a Persistent Volume Claim is kept a separate process from creating a pod, because the PVC should stay available even if the pod gets rescheduled. Hence, creating a PVC is a standalone process from claiming this PVC in the pod.

Storage Class

  • Storage classes are used by dynamic volume provisioning services such as AzureDisk or GlusterFS which may have a number of different kinds of attributes such as replication, region, ssd, etc.

  • Based on the different combination of these dynamic provisioning attributes, we can create different types of storage classes, such as platinum, gold and silver. This is the reason why we have storage class.

  • When using a dynamically provisioned volume, we thus only need to specify the storage class for the pod definition.

Stateful Sets

  • Stateful Sets allows deployment pods to be created one after another in an ordered sequence.

  • Each pod in the deployment would have an ordinal number with its headless service name and ordinal number registered with the Kubernetes Core DNS service, so that they are accessible by name.

  • On scaling down or termination, the sequence is killed in the reverse order, i.e. highest ordinal number to lowest ordinal number in a sequenced graceful manner.