Deployments
Deployments are the way we manage pods in k8s. We specify all possible information about the pods like which version image it is going to pick and how many replicas of the pod will be there.
- Properties
- The
spec.selector
specify which pod it needs to manage. - When we update a deployment, it first creates a new pod, deletes an old pod, and makes sure that 125% of the desired number of pods is available at any time.
- The
- Rollout to a Previous Version When rolling out to a previous version we just use –
kubectl rollout undo deployment/nginx-deployment
When rolling out to another previous version we use –kubectl rollout undo deployment/nginx-deployment --to-revision=2
StatefulSet
Just like we manage the stateless applications with deployments we work with stateful applications with StatefulSet.
- Properties
- The StatefulSet cannot be created/deleted at the same time
- can’t be accessed randomly
- The replica set here is not identical.
- Each pod gets a unique identifier in increasing order and these are required while rescheduling.
- Each pod has its own physical store.
- There is a master pod that is only allowed to change data.
- All the slave pods sync with the master pod in order to achieve data consistency.
- When a new pod joins the replica set it first clones all the data from one of the slave pods and after that starts to sync.
- StatefulSets are valuable for applications that require one or more of the following.
- Stable, unique network identifiers.
- Stable, persistent storage.
- Ordered, graceful deployment and scaling.
- Ordered, automated rolling updates.
- Data Persistence If a pod dies then all its data will be lost. So in order to counter this, we use persistent volume attached to every pod.
- The storage has all the synchronized data with the pod’s state data.
- When a pod gets replaced the persistent volume gets reattached to the pod and the state of the pod gets resumed.