Skip to content

Commit e2e7843

Browse files
authored
Merge pull request #30596 from mattcary/blogpost
StatefulSet AutoDelete blog post
2 parents 56d5330 + 1e7731f commit e2e7843

File tree

1 file changed

+103
-0
lines changed

1 file changed

+103
-0
lines changed
Lines changed: 103 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,103 @@
1+
---
2+
layout: blog
3+
title: 'Kubernetes 1.23: StatefulSet PVC Auto-Deletion (alpha)'
4+
date: 2021-12-16
5+
slug: kubernetes-1-23-statefulset-pvc-auto-deletion
6+
---
7+
8+
**Author:** Matthew Cary (Google)
9+
10+
Kubernetes v1.23 introduced a new, alpha-level policy for
11+
[StatefulSets](docs/concepts/workloads/controllers/statefulset/) that controls the lifetime of
12+
[PersistentVolumeClaims](docs/concepts/storage/persistent-volumes/) (PVCs) generated from the
13+
StatefulSet spec template for cases when they should be deleted automatically when the StatefulSet
14+
is deleted or pods in the StatefulSet are scaled down.
15+
16+
## What problem does this solve?
17+
A StatefulSet spec can include Pod and PVC templates. When a replica is first created, the
18+
Kubernetes control plane creates a PVC for that replica if one does not already exist. The behavior
19+
before Kubernetes v1.23 was that the control plane never cleaned up the PVCs created for
20+
StatefulSets - this was left up to the cluster administrator, or to some add-on automation that
21+
you’d have to find, check suitability, and deploy. The common pattern for managing PVCs, either
22+
manually or through tools such as Helm, is that the PVCs are tracked by the tool that manages them,
23+
with explicit lifecycle. Workflows that use StatefulSets must determine on their own what PVCs are
24+
created by a StatefulSet and what their lifecycle should be.
25+
26+
Before this new feature, when a StatefulSet-managed replica disappears, either because the
27+
StatefulSet is reducing its replica count, or because its StatefulSet is deleted, the PVC and its
28+
backing volume remains and must be manually deleted. While this behavior is appropriate when the
29+
data is critical, in many cases the persistent data in these PVCs is either temporary, or can be
30+
reconstructed from another source. In those cases, PVCs and their backing volumes remaining after
31+
their StatefulSet or replicas have been deleted are not necessary, incur cost, and require manual
32+
cleanup.
33+
34+
## The new StatefulSet PVC retention policy
35+
36+
If you enable the alpha feature, a StatefulSet spec includes a PersistentVolumeClaim retention
37+
policy. This is used to control if and when PVCs created from a StatefulSet’s `volumeClaimTemplate`
38+
are deleted. This first iteration of the retention policy contains two situations where PVCs may be
39+
deleted.
40+
41+
The first situation is when the StatefulSet resource is deleted (which implies that all replicas are
42+
also deleted). This is controlled by the `whenDeleted` policy. The second situation, controlled by
43+
`whenScaled` is when the StatefulSet is scaled down, which removes some but not all of the replicas
44+
in a StatefulSet. In both cases the policy can either be `Retain`, where the corresponding PVCs are
45+
not touched, or `Delete`, which means that PVCs are deleted. The deletion is done with a normal
46+
[object deletion](/docs/concepts/architecture/garbage-collection/), so that, for example, all
47+
retention policies for the underlying PV are respected.
48+
49+
This policy forms a matrix with four cases. I’ll walk through and give an example for each one.
50+
51+
* **`whenDeleted` and `whenScaled` are both `Retain`.** This matches the existing behavior for
52+
StatefulSets, where no PVCs are deleted. This is also the default retention policy. It’s
53+
appropriate to use when data on StatefulSet volumes may be irreplaceable and should only be
54+
deleted manually.
55+
56+
* **`whenDeleted` is `Delete` and `whenScaled` is `Retain`.** In this case, PVCs are deleted only when
57+
the entire StatefulSet is deleted. If the StatefulSet is scaled down, PVCs are not touched,
58+
meaning they are available to be reattached if a scale-up occurs with any data from the previous
59+
replica. This might be used for a temporary StatefulSet, such as in a CI instance or ETL
60+
pipeline, where the data on the StatefulSet is needed only during the lifetime of the
61+
StatefulSet lifetime, but while the task is running the data is not easily reconstructible. Any
62+
retained state is needed for any replicas that scale down and then up.
63+
64+
* **`whenDeleted` and `whenScaled` are both `Delete`.** PVCs are deleted immediately when their
65+
replica is no longer needed. Note this does not include when a Pod is deleted and a new version
66+
rescheduled, for example when a node is drained and Pods need to migrate elsewhere. The PVC is
67+
deleted only when the replica is no longer needed as signified by a scale-down or StatefulSet
68+
deletion. This use case is for when data does not need to live beyond the life of its
69+
replica. Perhaps the data is easily reconstructable and the cost savings of deleting unused PVCs
70+
is more important than quick scale-up, or perhaps that when a new replica is created, any data
71+
from a previous replica is not usable and must be reconstructed anyway.
72+
73+
* **`whenDeleted` is `Retain` and `whenScaled` is `Delete`.** This is similar to the previous case,
74+
when there is little benefit to keeping PVCs for fast reuse during scale-up. An example of a
75+
situation where you might use this is an Elasticsearch cluster. Typically you would scale that
76+
workload up and down to match demand, whilst ensuring a minimum number of replicas (for example:
77+
3). When scaling down, data is migrated away from removed replicas and there is no benefit to
78+
retaining those PVCs. However, it can be useful to bring the entire Elasticsearch cluster down
79+
temporarily for maintenance. If you need to take the Elasticsearch system offline, you can do
80+
this by temporarily deleting the StatefulSet, and then bringing the Elasticsearch cluster back
81+
by recreating the StatefulSet. The PVCs holding the Elasticsearch data will still exist and the
82+
new replicas will automatically use them.
83+
84+
Visit the
85+
[documentation](docs/concepts/workloads/controllers/statefulset/#persistentvolumeclaim-policies) to
86+
see all the details.
87+
88+
## What’s next?
89+
90+
Enable the feature and try it out! Enable the `StatefulSetAutoDeletePVC` feature gate on a cluster,
91+
then create a StatefulSet using the new policy. Test it out and tell us what you think!
92+
93+
I'm very curious to see if this owner reference mechanism works well in practice. For example, we
94+
realized there is no mechanism in Kubernetes for knowing who set a reference, so it’s possible that
95+
the StatefulSet controller may fight with custom controllers that set their own
96+
references. Fortunately, maintaining the existing retention behavior does not involve any new owner
97+
references, so default behavior will be compatible.
98+
99+
Please tag any issues you report with the label `sig/apps` and assign them to Matthew Cary
100+
([@mattcary](https://github.com/mattcary) at GitHub).
101+
102+
Enjoy!
103+

0 commit comments

Comments
 (0)