3 ms·

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 supporti

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

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...