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