Should Minecraft be a StatefulSet?

[ChipWolf]

StatefulSet seems more suitable than a Deployment for this type of workload, what are your thoughts?

[itzg]

I prefer using statefulsets, but changing these charts from deployments seems very disruptive for little to no functional gain.

[ChipWolf]

The main reason I ask is: we occasionally have an issue where a pod is stuck terminating for a little longer than expected & another one comes up to replace it, subsequently failing as it can't mount to the volume and needs manual intervention to resolve.
I imagine StatefulSet wouldn't allow another pod to come up until the previous one was totally gone.

I would've thought the Recreate strategy would prevent this, but I'm guessing the 'Terminating' state is good enough for the Deployment to spawn a new pod.

[itzg]

STS's rolling update strategy seems to be advertised as similar behavior to deployment's recreate strategy. Go ahead and experiment with a statefulset in your scenario and see what happens.

[itzg]

@billimek it feels like a similar conversation happened on the original helm repo, so I'm not able to find it there. What's your latest thoughts on the deployment/statefulset approaches and challenges.

[billimek]

@billimek it feels like a similar conversation happened on the original helm repo, so I'm not able to find it there. What's your latest thoughts on the deployment/statefulset approaches and challenges.

Personally speaking, I've gone full-circle on the idea that things should be statefulsets vs deployments meaning I believe that workloads like minecraft are appropriate for deployments and not statefulsets. For the minecraft-server chart, it's most likely going to require persistence and using a Recreate strategy vs Rollout should alleviate issues that @ChipWolf describe with a race condition of the new pod trying to consume the storage before the old pod terminates. I personally have not seen this issue and I run several minecraft chart instances and wonder if there is a better way to go about remediating the problem that doesn't involve using StatefulSet.

Anecdotally, it seems some folks have some issues with StatefulSet workloads being too 'sticky' to a given host and making updates challenging.

[ChipWolf]

@billimek it feels like a similar conversation happened on the original helm repo, so I'm not able to find it there. What's your latest thoughts on the deployment/statefulset approaches and challenges.

Personally speaking, I've gone full-circle on the idea that things should be statefulsets vs deployments meaning I believe that workloads like minecraft are appropriate for deployments and not statefulsets. For the minecraft-server chart, it's most likely going to require persistence and using a Recreate strategy vs Rollout should alleviate issues that @ChipWolf describe with a race condition of the new pod trying to consume the storage before the old pod terminates. I personally have not seen this issue and I run several minecraft chart instances and wonder if there is a better way to go about remediating the problem that doesn't involve using StatefulSet.

Anecdotally, it seems some folks have some issues with StatefulSet workloads being too 'sticky' to a given host and making updates challenging.

I'm inclined to agree after some experimentation. I have a suspicion the main issue I'm seeing pods sticking in the terminating state is down to Longhorn being Longhorn.