Home > Software engineering >  Why is the Deployment a de-facto object for stateless app? Why not to use Statefulset for these?
Why is the Deployment a de-facto object for stateless app? Why not to use Statefulset for these?

Time:01-19

I know why use StatefulSet for stateful applications. (e.g. DB or something) In most cases, I can see like "You want to deploy stateful app to k8s? Use StatefulSet!" However, I couldn't see like "You want to deploy stateless app to k8s? Then, DO NOT USE StatefulSet" ever.

Even nobody says "I don't recommend to use StatefulSet for stateless app", many stateless apps is deployed through Deployment, like it is the standard.

The StatefulSet has clear pros for stateful app, but I think Deployment doesn't for stateless app. Is there any pros in Deployment for stateless apps? Or is there any clear cons in StatefulSet for stateless apps?

I supposed that StatefulSet cannot use LoadBalancer Service or StatefulSet has penalty to use HPA, but all these are wrong.

I'm really curious about this question.

P.S. Precondition is the stateless app also uses the PV, but not persists stateful data, for example logs.

I googled "When not to use StatefulSet", "when Deployment is better than StatefulSet", "Why Deployment is used for stateless apps", or something more questions.

I also see the k8s docs about StatefulSet either.

CodePudding user response:

In contrast to a Kubernetes Deployment, where pods are easily replaceable, each pod in a StatefulSet is given a name and treated individually. Pods with distinct identities are necessary for stateful applications.

This implies that if any pod perishes, it will be apparent right away. StatefulSets act as controllers but do not generate ReplicaSets; rather, they generate pods with distinctive names that follow a predefined pattern. The ordinal index appears in the DNS name of a pod. A distinct persistent volume claim (PVC) is created for each pod, and each replica in a StatefulSet has its own state.

For instance, a StatefulSet with four replicas generates four pods, each of which has its own volume, or four PVCs. StatefulSets require a headless service to return the IPs of the associated pods and enable direct interaction with them. The headless service has a service IP but no IP address and has to be created separately.The major components of a StatefulSet are the set itself, the persistent volume and the headless service.

That all being said, people deploy Stateful Applications with Deployments, usually they mount a RWX PV into the pods so all "frontends" share the same backend. Quite common in CNCF projects.

CodePudding user response:

A stateful set manages each POD with a unique hostname based on an index number. So with an index, it would be easy to identify the individual PODs and also easy for the application to check which on real or unique network identities. Also, you might have read stateful sets get deleted in a specified order to maintain consistency.

When you use stateful for the stateless application it will be like burden to manage and add complexity to unique network identities and ordering guarantees.

For example, when you scale down to zero stateful sets it goes in the controlled way while with deployment or RS it won't be the same case. However, there is no guarantee when deleting the resource stateful set.

Also, Before a scaling operation is applied to a Pod, all of its predecessors must be Running and Ready. So if you are deploying the application, three Pods will be deployed suppose in order app-0, app-1, app-2. app-1 wont be deployed before app-0 is Running & Ready, and app-2 wont be deployed until app-1 is Ready.

While with deployment you can manage the % for and handle the RollingUpdate scenario but with a stateful set it will delete and recreate new POD.

  • Related