3 ms·

From the latest documentation[1]: StatefulSets are valuable for applications that require one or more of the following. Stable, unique network identifiers. S

From the latest documentation[1]: 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. [1] https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/ https://kubernetes.io/docs/concepts/workloads/controllers/st...

Filligree 4y ago
Which confuses me, frankly. When do you not need automated rolling updates? Or stable network identifiers? I'm sure there are cases, but it seems like supporting them should be the default -- are statefulsets somehow expensive?
- lokar 4y ago
  Consider a job of N identical API servers. Your request can go to any of them. To update we could just add new tasks and take away old tasks. It's a gradual update, but not "rolling" is the sens that each task name has a single love instance at a time.
- mjg235 4y ago
  A basic stateless web app behind a load balancer can tolerate unstable network identifiers as long as you automate registering/deregistering the new names, which kubernetes services do very well. Stateful apps can be a bit more exceptional because they often have client libraries that require you to hardcode network addresses via connection strings and other tooling that makes that glue automation more tricky and worth the added guarantee around consistent naming.
- lokar 4y ago
  I'f it was named today I'm sure it would be called a "non fungible set" :)
- bogomipz 4y ago
  >"When do you not need automated rolling updates? Or stable network identifiers?" Most of the time with stateless apps. In regards to automated rolling updates, the key word there is "ordered." It will always select the same ordinal index first(reverse order starting with highest ordinal.)[1] This is different than the regular deployment strategy of "rolling update" which is also one by one but will select any pod to whack first. Regular pods don't have stable network identifiers as they are inherently unstable. In regular pods stable network identifiers are provided by either the cluterIP or a load balancer service. [1] https://kubernetes.io/docs/tutorials/stateful-application/basic-stateful-set/ https://kubernetes.io/docs/tutorials/stateful-application/ba...
lokar 4y ago
Persistent storage is its own API, you don't need to use it with a satefull set. All of the other properties are implied by stable task names. And I would guess the doc is a bit of after the fact justification for a design choice already made.
- mdaniel 4y ago
  > Persistent storage is its own API, you don't need to use it with a satefull set. All of the other properties are implied by stable task names. I believe that's only partially true, since even if one has a PVC in something like a Deployment (the antipattern I see *a lot* in folks new to k8s trying to run mysql or whatever), then "k scale --replicas=10 deploy/my-deploy" will not allocate new PVCs for the new pods That's why I think StatefulSets are valuable as their own resource type: they represent _future_ storage needs
- mcronce 4y ago
  Persistent storage tied to a specific member of the deployment is a StatefulSet feature. That's likely what they mean by "stable", although I really wish they were more clear about it
- bogomipz 4y ago
  Your comment makes no sense. Persistent storage is one component of a stateful set. You are not even using correct Kubernetes terminology, I have never once seen the term "stable task name."

Filligree 4y ago

Which confuses me, frankly. When do you not need automated rolling updates? Or stable network identifiers? I'm sure there are cases, but it seems like supporting them should be the default -- are statefulsets somehow expensive?

lokar 4y ago
Consider a job of N identical API servers. Your request can go to any of them. To update we could just add new tasks and take away old tasks. It's a gradual update, but not "rolling" is the sens that each task name has a single love instance at a time.
mjg235 4y ago
A basic stateless web app behind a load balancer can tolerate unstable network identifiers as long as you automate registering/deregistering the new names, which kubernetes services do very well. Stateful apps can be a bit more exceptional because they often have client libraries that require you to hardcode network addresses via connection strings and other tooling that makes that glue automation more tricky and worth the added guarantee around consistent naming.
lokar 4y ago
I'f it was named today I'm sure it would be called a "non fungible set" :)
bogomipz 4y ago
>"When do you not need automated rolling updates? Or stable network identifiers?" Most of the time with stateless apps. In regards to automated rolling updates, the key word there is "ordered." It will always select the same ordinal index first(reverse order starting with highest ordinal.)[1] This is different than the regular deployment strategy of "rolling update" which is also one by one but will select any pod to whack first. Regular pods don't have stable network identifiers as they are inherently unstable. In regular pods stable network identifiers are provided by either the cluterIP or a load balancer service. [1] https://kubernetes.io/docs/tutorials/stateful-application/basic-stateful-set/ https://kubernetes.io/docs/tutorials/stateful-application/ba...

lokar 4y ago

Persistent storage is its own API, you don't need to use it with a satefull set. All of the other properties are implied by stable task names. And I would guess the doc is a bit of after the fact justification for a design choice already made.

mdaniel 4y ago
> Persistent storage is its own API, you don't need to use it with a satefull set. All of the other properties are implied by stable task names. I believe that's only partially true, since even if one has a PVC in something like a Deployment (the antipattern I see *a lot* in folks new to k8s trying to run mysql or whatever), then "k scale --replicas=10 deploy/my-deploy" will not allocate new PVCs for the new pods That's why I think StatefulSets are valuable as their own resource type: they represent _future_ storage needs
mcronce 4y ago
Persistent storage tied to a specific member of the deployment is a StatefulSet feature. That's likely what they mean by "stable", although I really wish they were more clear about it
bogomipz 4y ago
Your comment makes no sense. Persistent storage is one component of a stateful set. You are not even using correct Kubernetes terminology, I have never once seen the term "stable task name."