Kubernetes | Deployments V/s StatefulSets

Kubernetes is an open source container orchestration engine for management, deployment and scaling of containerized applications. Kubernetes provides a framework to run distributed systems resiliently and allowing canary deployments and releases. It provides in-built capabilities for service discovery, automated rollouts and rollbacks, self-healing, load balancing and much more. This blog is focused on the deployments and Statefulsets for Kubernetes Services.

The smallest unit of deployment in Kubernetes is Pod, which is an abstraction of containers. A pod can have one or more containers, ideally one, with shared storage and network resources. In Kubernetes, you don’t work with Pods directly, instead, you work with the deployments or Statefulsets, which is the blueprint of the Pod. You can think of it as one more layer of abstraction on containers and Pod. Working with deployments or Statefulsets makes the deployments, scaling and management of containers really easy.

Deployment

Deployment is the blueprint of a set of Pods that allow you to deploy, manage and scale identical pods using common specifications. Once created, deployment controller verifies the current state of the deployment to match the defined desired set. The controller then creates the ReplicaSet, which then creates the pods. The ReplicaSet is managed by the Kubernetes internally and you don’t need to work with those either. Deployment ensures that the specified number of pods are always running and available. The entire update process is recorded along with the versions to provide option to roll back to previous versions.

Deployments are typically used to deploy stateless applications. However, a stateful application can also be deployed using deployment by attaching a persistent volume. But, in this case, all pods will share the same volume and same copy data. For a true stateful application, StatefulSet is used, discussed next. A deployment created with name sample, will create a ReplicaSet named sample-<Replica-Set-Id>, each Pod with name sample-<Replica-Set-Id>–<Unique-Pod-Id> e.g. sample-rs4685-dg344e.

StatefulSet

StatefulSet allows you to deploy, manage and scale stateful applications based on the identical specs eg: Database Pods. Stateful applications require pods with unique identities. StatefulSet guarantees the ordering of the Pods and assign a persistent identity to each of the Pod that is maintained across rescheduling. In a StatefulSet, each pod is treated individually.This means that if any pod dies, it is immediately noticeable. Each replica in a StatefulSet has its own state and persistent volume claim.

StatefulSet doesn’t create ReplicaSet, unlike Deployments instead creates the Pod with a unique naming convention by its own. e.g. A StatefulSet named sample, will create pods with name sample-0, sample-1, sample-2, etc., in the incremental sequence. Each pods created by the StatefulSet will have its own Persistent Volume Claim.

Sample Use Case

Let’s understand the difference between deployment and StatefulSet through a sample use case. Assume you have a Node.js application that uses MySQL database to store data. The Node.js application can be deployed using the deployments. When the load increases you would want to scale your application out an create more of the application Pods to support the load, which is pretty easy in Kubernetes. You just need to change the replica count in the deployment specs and controller will take care of it. Since, the Pods are identical and interchangeable, there is no issue there. Each application Pod will have its unique name as the deployment name and a random hash generated by Kubernetes. The service can load balance the request to any of the Pods.

Now, you would probably need to scale our database as well to meet the load. However, database Pods can’t be created or deleted in any order and can’t be addressed randomly because the replica Pods in case of database are not identical. The master and replica nodes are different. Each Pod has it’s own persistent volume and keeps it’s own copy of the data. Each Pod always sync data from the previous Pod. In this case you would need to create a StatefulSet. The StatefulSet will create the Pods to meet desired state in orderly fashion where each new Pod will take the copy of the data from last Pod. In case a Pod dies, the controller will create a new Pod with the same name and will attach to the same Persistent Volume Claim. This makes the StatefulSet Set different from the deployments.

Deployments v/s StatefulSet 

Parameters	Deployment	StatefulSet
Application State	Deployments are used for stateless applications.	StatefulSets are used for stateful applications.
Interchangeability	Pods deployed by Deployment are identical and interchangeable.	Pods deployed by StatefulSet are not identical and interchangeable.
Name and Identity	Each Pod is given a random hash in the name for its unique identity along with deployment and replicaset name. Example: sample-rs4685-dg344e	Each Pod is given a persistent identity with a sequence number along with statefulset name, which is kept between restarts. Example: sample-1
Order Creation	Pods are created and deleted in a random order.	Pods can’t be created or deleted at the same time or in random order.
Service	Deployments require a service to enable interaction with pods	while a headless service handles the pods’ network ID in StatefulSets.
Persistent Volumes	In deployment, the replicas all share same volume and PVC.	In StatefulSet each pod has its own volume and PVC.

Conclusion

Deployments and StatefulSet in Kubernetes makes the scaling and management of Pods really easy. Deployments are used to deploy Stateless application where the order or identity doesn’t matter. Statefulsets are used to deploy the stateful applications where each Pod is treated individually and have its own persistent volume.

Deployment V/s StatefulSet Deployments V/s StatefulSets StatefulSets V/s Deployments StatefulSet V/s Deployment9