GKE PersistentVolumeClaim in Deployment vs StatefulSet

239 views

Skip to first unread message

Tyler Johnson

unread,

Mar 20, 2018, 1:35:08 PM3/20/18

to Kubernetes user discussion and Q&A

I've seen documentation, blog posts, and stackoverflow responses indicating two different solutions for persisting data across pod restarts.

In one solution, it's a volume mounted as persistent volume claim within a Deployment. [3]

In the other, the persistent volume claim is mounted within a StatefulSet.

The official documentation clearly indicates Deployments for stateless [1] applications and StatefulSets for stateful [2] applications.

The question is, does the Deployment as stateful application set up work even though the documentation appears to indicate otherwise? Is there a significant difference between the two options?

And does it make sense to use the StatefulSet for one pod just to set up persistence? The Kubernetes documentation [4] describes an unrelated goal for StatefulSets, indicating that they "manage the deployment and scaling of a set of Pods, and provides guarantees about the ordering and uniqueness of these Pods."

[1] https://cloud.google.com/kubernetes-engine/docs/how-to/stateless-apps

[2] https://cloud.google.com/kubernetes-engine/docs/how-to/stateful-apps

[3] https://devopscube.com/persistent-volume-google-kubernetes-engine/

[4] https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/

Michelle Au

unread,

Mar 20, 2018, 2:34:34 PM3/20/18

to Kubernetes user discussion and Q&A

Hi Tyler,

StatefulSets will also give you a stable network identity, if you need that. Since GCE PDs can only be mounted in write mode by one node, you should only have one pod referencing it. It is easy to misconfigure Deployments to end up in scenarios with multiple pods referencing the same GCE PD (see discussion https://github.com/kubernetes/kubernetes/issues/48968#issuecomment-315490408), which will fail. For that reason, StatefulSets is also recommended to avoid the multi-pod scenario.

Thanks,

Michelle

--
You received this message because you are subscribed to the Google Groups "Kubernetes user discussion and Q&A" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-use...@googlegroups.com.
To post to this group, send email to kubernet...@googlegroups.com.
Visit this group at https://groups.google.com/group/kubernetes-users.
For more options, visit https://groups.google.com/d/optout.

Tyler Johnson

unread,

Mar 20, 2018, 2:58:17 PM3/20/18

to kubernet...@googlegroups.com

Thanks Michelle, that helps to clarify the reason to prefer Deployments over StatefulSets when using PDs.

To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-users+unsubscribe@googlegroups.com.
To post to this group, send email to kubernetes-users@googlegroups.com.

Visit this group at https://groups.google.com/group/kubernetes-users.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "Kubernetes user discussion and Q&A" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/kubernetes-users/2jG8nr-WA3A/unsubscribe.
To unsubscribe from this group and all its topics, send an email to kubernetes-users+unsubscribe@googlegroups.com.
To post to this group, send email to kubernetes-users@googlegroups.com.

Michelle Au

unread,

Mar 20, 2018, 3:47:10 PM3/20/18

to Kubernetes user discussion and Q&A

To be clear, I am recommending using StatefulSets over Deployments when using any Read-Write-Once volume type like PDs.

On Tue, Mar 20, 2018 at 11:58 AM Tyler Johnson <tyler....@risevision.com> wrote:

Thanks Michelle, that helps to clarify the reason to prefer Deployments over StatefulSets when using PDs.

On Tue, Mar 20, 2018 at 2:34 PM, 'Michelle Au' via Kubernetes user discussion and Q&A <kubernet...@googlegroups.com> wrote:

Hi Tyler,

StatefulSets will also give you a stable network identity, if you need that. Since GCE PDs can only be mounted in write mode by one node, you should only have one pod referencing it. It is easy to misconfigure Deployments to end up in scenarios with multiple pods referencing the same GCE PD (see discussion https://github.com/kubernetes/kubernetes/issues/48968#issuecomment-315490408), which will fail. For that reason, StatefulSets is also recommended to avoid the multi-pod scenario.

Thanks,
Michelle

On Tue, Mar 20, 2018 at 10:35 AM Tyler Johnson <tyler....@risevision.com> wrote:

I've seen documentation, blog posts, and stackoverflow responses indicating two different solutions for persisting data across pod restarts.

In one solution, it's a volume mounted as persistent volume claim within a Deployment. [3]

In the other, the persistent volume claim is mounted within a StatefulSet.

The official documentation clearly indicates Deployments for stateless [1] applications and StatefulSets for stateful [2] applications.

The question is, does the Deployment as stateful application set up work even though the documentation appears to indicate otherwise? Is there a significant difference between the two options?
And does it make sense to use the StatefulSet for one pod just to set up persistence? The Kubernetes documentation [4] describes an unrelated goal for StatefulSets, indicating that they "manage the deployment and scaling of a set of Pods, and provides guarantees about the ordering and uniqueness of these Pods."

[1] https://cloud.google.com/kubernetes-engine/docs/how-to/stateless-apps
[2] https://cloud.google.com/kubernetes-engine/docs/how-to/stateful-apps
[3] https://devopscube.com/persistent-volume-google-kubernetes-engine/
[4] https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/

--
You received this message because you are subscribed to the Google Groups "Kubernetes user discussion and Q&A" group.

To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-use...@googlegroups.com.
To post to this group, send email to kubernet...@googlegroups.com.

Visit this group at https://groups.google.com/group/kubernetes-users.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "Kubernetes user discussion and Q&A" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/kubernetes-users/2jG8nr-WA3A/unsubscribe.

To unsubscribe from this group and all its topics, send an email to kubernetes-use...@googlegroups.com.
To post to this group, send email to kubernet...@googlegroups.com.

Visit this group at https://groups.google.com/group/kubernetes-users.
For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "Kubernetes user discussion and Q&A" group.

To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-use...@googlegroups.com.
To post to this group, send email to kubernet...@googlegroups.com.

Tyler Johnson

unread,

Mar 20, 2018, 4:04:08 PM3/20/18

to kubernet...@googlegroups.com

Sorry, I had understood the preference for SS but written it out backwards :)

On Tue, Mar 20, 2018 at 3:46 PM, 'Michelle Au' via Kubernetes user discussion and Q&A <kubernet...@googlegroups.com> wrote:

To be clear, I am recommending using StatefulSets over Deployments when using any Read-Write-Once volume type like PDs.

On Tue, Mar 20, 2018 at 11:58 AM Tyler Johnson <tyler....@risevision.com> wrote:

Thanks Michelle, that helps to clarify the reason to prefer Deployments over StatefulSets when using PDs.

On Tue, Mar 20, 2018 at 2:34 PM, 'Michelle Au' via Kubernetes user discussion and Q&A <kubernetes-users@googlegroups.com> wrote:

Hi Tyler,

StatefulSets will also give you a stable network identity, if you need that. Since GCE PDs can only be mounted in write mode by one node, you should only have one pod referencing it. It is easy to misconfigure Deployments to end up in scenarios with multiple pods referencing the same GCE PD (see discussion https://github.com/kubernetes/kubernetes/issues/48968#issuecomment-315490408), which will fail. For that reason, StatefulSets is also recommended to avoid the multi-pod scenario.

Thanks,
Michelle

On Tue, Mar 20, 2018 at 10:35 AM Tyler Johnson <tyler....@risevision.com> wrote:

I've seen documentation, blog posts, and stackoverflow responses indicating two different solutions for persisting data across pod restarts.

In one solution, it's a volume mounted as persistent volume claim within a Deployment. [3]

In the other, the persistent volume claim is mounted within a StatefulSet.

The official documentation clearly indicates Deployments for stateless [1] applications and StatefulSets for stateful [2] applications.

The question is, does the Deployment as stateful application set up work even though the documentation appears to indicate otherwise? Is there a significant difference between the two options?
And does it make sense to use the StatefulSet for one pod just to set up persistence? The Kubernetes documentation [4] describes an unrelated goal for StatefulSets, indicating that they "manage the deployment and scaling of a set of Pods, and provides guarantees about the ordering and uniqueness of these Pods."

[1] https://cloud.google.com/kubernetes-engine/docs/how-to/stateless-apps
[2] https://cloud.google.com/kubernetes-engine/docs/how-to/stateful-apps
[3] https://devopscube.com/persistent-volume-google-kubernetes-engine/
[4] https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/

--
You received this message because you are subscribed to the Google Groups "Kubernetes user discussion and Q&A" group.

To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-users+unsubscribe@googlegroups.com.
To post to this group, send email to kubernetes-users@googlegroups.com.

Visit this group at https://groups.google.com/group/kubernetes-users.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "Kubernetes user discussion and Q&A" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/kubernetes-users/2jG8nr-WA3A/unsubscribe.

To unsubscribe from this group and all its topics, send an email to kubernetes-users+unsubscribe@googlegroups.com.
To post to this group, send email to kubernetes-users@googlegroups.com.

Visit this group at https://groups.google.com/group/kubernetes-users.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Kubernetes user discussion and Q&A" group.

To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-users+unsubscribe@googlegroups.com.
To post to this group, send email to kubernetes-users@googlegroups.com.

Visit this group at https://groups.google.com/group/kubernetes-users.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "Kubernetes user discussion and Q&A" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/kubernetes-users/2jG8nr-WA3A/unsubscribe.

To unsubscribe from this group and all its topics, send an email to kubernetes-users+unsubscribe@googlegroups.com.
To post to this group, send email to kubernetes-users@googlegroups.com.

Reply all

Reply to author

Forward

0 new messages