I/Replicating stateful pods:
– ReplicaSets create multiple pod replicas from a single pod template. These replicas don’t differ from each other, apart from their name and IP address. If the pod template includes a volume, which refers to a specific PersistentVolumeClaim, all replicas of the ReplicaSet will use the exact same PersistentVolumeClaim and therefore the same PersistentVolume bound by the claim => can’t make each replica use its own separate PersistentVolumeClaim.
*Ways for running multiple replicas with separate storage for each:
+ Create pod mannually use its own PersistentVolumeClaim without take care by Replica Set.
+ Using one Reaplica Set for one Pod instance with using dedicated PVC and support automatic rescheduling in case of node failures or accidental pod deletions.
*Using multiple directories in same volume:
– This solution does require coordination between the instances, and isn’t easy to do correctly. It also makes the shared storage volume the bottleneck.
– Instead of using a ReplicaSet to run pod need statefull (dedicated PVC) K8s support to create a StatefulSet resource (new instance needs to have the same state and identity as the old one).
– When a stateful pod instance dies (or the node it’s running on fails), the pod instance needs to be resurrected on another node, but the new instance needs to get the same name, network identity, and state as the one it’s replacing (have a unique, stable network identifier across restarts and reschedules).
– A StatefulSet, like a ReplicaSet, has a desired replica count field that determines how many instance you want running at that time. Similar to ReplicaSets, pods are created from a pod template specified as part of the StatefulSet.
– Each pod created by a StatefulSet is assigned an ordinal index (zero-based), which is then used to derive the pod’s name and hostname, and to attach stable storage to the pod (pod’s name is derived from the StatefulSet’s name and the ordinal index of the instance).
– When a pod instance managed by a StatefulSet disappears, the StatefulSet makes sure it’s replaced with a new instance same name and hostname as the pod that has disappeared.
*SCALING A STATEFULSET:
– Scaling the StatefulSet creates a new pod instance with the next unused ordinal index. Scaling down a StatefulSet always removes the instances with the highest ordinal index.
*Providing stable dedicated storage to each stateful instance:
– Storage for stateful pods needs to be persistent, each pod of a StatefulSet needs to reference a different PersistentVolumeClaim to have its own separate PersistentVolume.
– Using Volume Claim Template to create the PersistentVolumeClaims along with each pod instance. The PersistentVolumes for the claims can either be provisioned up-front by an administrator or just in time through dynamic provisioning of PersistentVolumes.
Example: Create and Scale Mysql Pod Using StatefulSet resource on Azure Kubernetes Service
1/ Open Cloud Shell and using az aks get-credentials command to connect AKS clsuter
2/Create Persistent Volume Claim using for volumeClaimTemplates
3/Create secret resource for storing Mysql password of pod:
4/Create StatefulSet resoruce for deploy Mysql pod with own PV:
– name: mysql
– name: MYSQL_ROOT_PASSWORD
– containerPort: 3306
– name: data
– Checking new volume already created and attach to pod
– Checking each pod using with different PV