Should minio service be a Deployment or a Statefulset? about examples HOT 5 CLOSED

It is generally not recommended to use a Deployment with a ReadWriteOnce PVC because, as you mentioned, the default Deployment strategy involves creating a new Pod before tearing down the old one, which can lead to a deadlock if the new Pod is unable to start due to the ReadWriteOnce volume being in use.

A StatefulSet, on the other hand, is designed to handle persistent storage more gracefully and is a better choice when using ReadWriteOnce volumes. It ensures that each Pod is created and terminated in a specific order, which helps to avoid the potential deadlock scenario that can occur with Deployments.

That being said, it is possible to use a Deployment with a ReadWriteOnce PVC if you are willing to accept the risks and are prepared to handle potential failures. However, it is generally recommended to use a StatefulSet instead in order to avoid these issues.

In the example you mentioned, it is possible that the use of a Deployment with a ReadWriteOnce PVC was intentional in order to illustrate a specific scenario or to demonstrate how to handle persistent storage in a Deployment. However, if the goal of the example is to provide a recommended practice for using persistent storage with Kubernetes, it may be worth considering updating the example to use a StatefulSet instead.

from examples.

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

from examples.

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

from examples.

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

from examples.

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

from examples.