Skip to content

Commit d9a9011

Browse files
committed
Add blog for PersistentVolume last phase transition time
1 parent d66ac9b commit d9a9011

File tree

1 file changed

+105
-0
lines changed

1 file changed

+105
-0
lines changed
Lines changed: 105 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,105 @@
1+
---
2+
layout: blog
3+
title: PersistentVolume Last Phase Transition Time in Kubernetes
4+
date: 2023-10-23
5+
slug: persistent-volume-last-phase-transition-time
6+
---
7+
8+
**Author:** Roman Bednář (Red Hat)
9+
10+
In the recent Kubernetes v1.28 release, we (SIG Storage) introduced a new alpha feature that aims to improve PersistentVolume (PV)
11+
storage management and help cluster administrators gain better insights into the lifecycle of PVs.
12+
With the addition of the `lastPhaseTransitionTime` field into the status of a PV,
13+
cluster administrators are now able to track the last time a PV transitioned to a different
14+
[phase](/docs/concepts/storage/persistent-volumes/#phase), allowing for more efficient
15+
and informed resource management.
16+
17+
## Why do we need new PV field? {#why-new-field}
18+
19+
PersistentVolumes in Kubernetes play a crucial role in providing storage resources to workloads running in the cluster.
20+
However, managing these PVs effectively can be challenging, especially when it comes
21+
to determining the last time a PV transitioned between different phases, such as
22+
`Pending`, `Bound` or `Released`.
23+
Administrators often need to know when a PV was last used or transitioned to certain
24+
phases; for instance, to implement retention policies, perform cleanup, or monitor storage health.
25+
26+
In the past, Kubernetes users have faced data loss issues when using the `Delete` retain policy and had to resort to the safer `Retain` policy.
27+
When we planned the work to introduce the new `lastPhaseTransitionTime` field, we
28+
wanted to provide a more generic solution that can be used for various use cases,
29+
including manual cleanup based on the time a volume was last used or producing alerts based on phase transition times.
30+
31+
## How lastPhaseTransitionTime helps
32+
33+
Provided you've enabled the feature gate (see [How to use it](#how-to-use-it), the new `.status.lastPhaseTransitionTime` field of a PersistentVolume (PV)
34+
is updated every time that PV transitions from one phase to another.
35+
``
36+
Whether it's transitioning from `Pending` to `Bound`, `Bound` to `Released`, or any other phase transition, the `lastPhaseTransitionTime` will be recorded.
37+
For newly created PVs the phase will be set to `Pending` and the `lastPhaseTransitionTime` will be recorded as well.
38+
39+
This feature allows cluster administrators to:
40+
41+
1. Implement Retention Policies
42+
43+
With the `lastPhaseTransitionTime`, administrators can now track when a PV was last used or transitioned to the `Released` phase.
44+
This information can be crucial for implementing retention policies to clean up resources that have been in the `Released` phase for a specific duration.
45+
For example, it is now trivial to write a script or a policy that deletes all PVs that have been in the `Released` phase for a week.
46+
47+
2. Monitor Storage Health
48+
49+
By analyzing the phase transition times of PVs, administrators can monitor storage health more effectively.
50+
For example, they can identify PVs that have been in the `Pending` phase for an unusually long time, which may indicate underlying issues with the storage provisioner.
51+
52+
## How to use it
53+
54+
The `lastPhaseTransitionTime` field is alpha starting from Kubernetes v1.28, so it requires
55+
the `PersistentVolumeLastPhaseTransitionTime` feature gate to be enabled.
56+
57+
If you want to test the feature whilst it's alpha, you need to enable this feature gate on the `kube-controller-manager` and the `kube-apiserver`.
58+
59+
Use the `--feature-gates` command line argument:
60+
61+
```shell
62+
--feature-gates="...,PersistentVolumeLastPhaseTransitionTime=true"
63+
```
64+
65+
Keep in mind that the feature enablement does not have immediate effect; the new field will be populated whenever a PV is updated and transitions between phases.
66+
Administrators can then access the new field through the PV status, which can be retrieved using standard Kubernetes API calls or through Kubernetes client libraries.
67+
68+
Here is an example of how to retrieve the `lastPhaseTransitionTime` for a specific PV using the `kubectl` command-line tool:
69+
70+
```shell
71+
kubectl get pv <pv-name> -o jsonpath='{.status.lastPhaseTransitionTime}'
72+
```
73+
74+
## Going forward
75+
76+
This feature was initially introduced as an alpha feature, behind a feature gate that is disabled by default.
77+
During the alpha phase, we (Kubernetes SIG Storage) will collect feedback from the end user community and address any issues or improvements identified.
78+
79+
Once sufficient feedback has been received, or no complaints are received the feature can move to beta.
80+
The beta phase will allow us to further validate the implementation and ensure its stability.
81+
82+
At least two Kubernetes releases will happen between the release where this field graduates
83+
to beta and the release that graduates the field to general availability (GA). That means that
84+
the earliest release where this field could be generally available is Kubernetes 1.32,
85+
likely to be scheduled for early 2025.
86+
87+
## Getting involved
88+
89+
We always welcome new contributors so if you would like to get involved you can
90+
join our [Kubernetes Storage Special-Interest-Group](https://github.com/kubernetes/community/tree/master/sig-storage) (SIG).
91+
92+
If you would like to share feedback, you can do so on our
93+
[public Slack channel](https://app.slack.com/client/T09NY5SBT/C09QZFCE5).
94+
If you're not already part of that Slack workspace, you can visit https://slack.k8s.io/ for an invitation.
95+
96+
Special thanks to all the contributors that provided great reviews, shared valuable insight and helped implement this feature (alphabetical order):
97+
98+
- Han Kang ([logicalhan](https://github.com/logicalhan))
99+
- Jan Šafránek ([jsafrane](https://github.com/jsafrane))
100+
- Jordan Liggitt ([liggitt](https://github.com/liggitt))
101+
- Kiki ([carlory](https://github.com/carlory))
102+
- Michelle Au ([msau42](https://github.com/msau42))
103+
- Tim Bannister ([sftim](https://github.com/sftim))
104+
- Wojciech Tyczynski ([wojtek-t](https://github.com/wojtek-t))
105+
- Xing Yang ([xing-yang](https://github.com/xing-yang))

0 commit comments

Comments
 (0)