Volume stores the data generated by a pod even after the pod is deleted. The volume needs storage which can be configured in multiple ways. We mount the volume once it is created to access it from a container.
Access Mode defines how a Volume should be mounted on the hosts.
The supported values are ReadOnlyMany, ReadWriteOnce or ReadWriteMany mode.
Persistent Volumes can be configured to be recycled or retained after the associated
claim has been deleted.
If recycled, the data is scrubbed before assigning the volume to other claims.
Once the Persistent Volume Claims are created, Kubernetes binds the Persistent Volumes to Claims based on the request and properties set on the volume. Every Persistent Volume Claim is bound to a single Persistent Volume. There is a 1:1 mapping between Persistent Volume and Persistent Volume Claim.
Every time an application requires storage we have to manually provision the disk and then manually create a persistent volume definition file using the same name as that of the disk created. This is called Static Provisioning of Volumes.
We can define a provisioner that can automatically provision storage and attach that to pods when a claim is made. That's called Dynamic Provisioning of Volumes. Storage Classes allow us to dynamically provision volumes.
The Storage Class automatically creates a Persistent Storage so we don't have to.
Stateful sets are similar to deployment sets. As is, they create pods based on templates. They can scale up and scale down. They can perform rolling updates and rollbacks.
There are differences though:
- With stateful sets, pods are created in a sequential order. After the first pod is deployed, it must be in a running and ready state before the next pod is deployed.
- Stateful sets assign a unique ordinal index to each pod starting from zero and incrementing by 1. Each pod gets a unique name derived from this index combined with the stateful set name. We can be sure that the first pod in any stateful set is always going to be name of the stateful set followed by zero. Stateful sets maintain a sticky identity for each of their pods.
Stateful sets should be used if our instances need to come up in a particular order or if the instances need a stable name.
The template definition for stateful set is similar to a deployment. Stateful sets require a headless service name to be specified.
While defining a stateful set, we don't need to specify a subdomain or hostname.
It'll automatically assign the right subdomain based on the headless service name.
When creating a stateful set we must specify the service name explicitly using
the service name option in the stateful set definition file. This is how it knows
what subdomain should be assigned to the pods.
Headless service does not load balance requests but gives us a
DNS entry to reach each pod. Headless service is created like a normal service
but it does not have an IP of its own like a cluster IP for a normal service.
Setting clusterIP to None is service definition creates a headless service.
The pod definition needs to have subdomain and hostname defined in its template
in order for the headless service to create a DNS record for the pod.
kubectl get persistentvolume will show all persistent volumes.
kubectl exec <pod-name> -- cat <file-path> will read the file located at
file-path within the pod pod-name.