-
Notifications
You must be signed in to change notification settings - Fork 14.6k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Add blog for PersistentVolume last phase transition time
1 parent
2c969da
commit 8bf7307
Showing
1 changed file
with
91 additions
and
0 deletions.
There are no files selected for viewing
91 changes: 91 additions & 0 deletions
91
content/en/blog/_posts/2023-08-15-pv-last-phase-transtition-time.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,91 @@ | ||
--- | ||
layout: blog | ||
title: "Kubernetes 1.28: Persistent Volume Last Phase Transition Time" | ||
date: 2023-08-15T10:00:00-08:00 | ||
slug: kubernetes-1-28-persistent-volume-last-phase-transition-time | ||
--- | ||
|
||
**Author:** Roman Bednář (Red Hat) | ||
|
||
In Kubernetes v1.28, we are introducing a new alpha feature that aims to improve PersistentVolume (PV) management and help cluster administrators gain better insights into the lifecycle of PVs. | ||
With the addition of the LastPhaseTransitionTime field in the PV status, administrators will be able to track the last time a PV transitioned to a different phase, allowing for more efficient and informed resource management. | ||
|
||
## Why do we need new PV field | ||
|
||
PersistentVolumes in Kubernetes play a crucial role in providing storage resources to workloads running in the cluster. | ||
However, managing these PVs effectively can be challenging, especially when it comes to determining the last time a PV transitioned between different phases, such as "Pending," "Bound," or "Released." | ||
Administrators often need to know when a PV was last used or transitioned to certain phases, for instance, to implement retention policies, perform cleanup, or monitor storage health. | ||
|
||
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. | ||
By introducing the LastPhaseTransitionTime field, we aim to provide a more generic solution that can be used for various use cases, | ||
including manual cleanup based on the time a volume was last used or producing alerts based on phase transition times. | ||
|
||
## How LastPhaseTransitionTime helps | ||
|
||
The new LastPhaseTransitionTime field added to the PV status is updated every time a PV transitions from one phase to another. | ||
Whether it's transitioning from "Pending" to "Bound," "Bound" to "Released," or any other phase transition, the LastPhaseTransitionTime will be recorded. | ||
For newly created PVs the phase will be set to "Pending" and the LastPhaseTransitionTime will be recorded as well. | ||
|
||
This feature allows cluster administrators to: | ||
|
||
1. Implement Retention Policies | ||
|
||
With the LastPhaseTransitionTime, administrators can now track when a PV was last used or transitioned to the "Released" phase. | ||
This information can be crucial for implementing retention policies to clean up resources that have been in the "Released" phase for a specific duration. | ||
|
||
2. Monitor Storage Health | ||
|
||
By analyzing the phase transition times of PVs, administrators can monitor storage health more effectively. | ||
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. | ||
|
||
3. Produce Alerts and Metrics | ||
|
||
The LastPhaseTransitionTime can be utilized to produce alerts and metrics. | ||
Cluster administrators can set up alerts based on specific phase transition durations, ensuring proactive management of PVs and avoiding potential storage-related problems. | ||
|
||
## How to use it | ||
|
||
The LastPhaseTransitionTime field is currently alpha so it requires `PersistentVolumeLastPhaseTransitionTime` feature gate to be enabled. | ||
|
||
If you want to test the feature whilst it's alpha, you need to enable this feature gate in the kube-controller-manager and the kube-apiserver. | ||
|
||
Use the `--feature-gates` command line argument: | ||
|
||
``` | ||
--feature-gates="...,PersistentVolumeLastPhaseTransitionTime=true" | ||
``` | ||
|
||
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 phases. | ||
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. | ||
|
||
Here is an example of how to retrieve the LastPhaseTransitionTime for a specific PV using the kubectl command-line tool: | ||
|
||
``` | ||
kubectl get pv <pv-name> -o jsonpath='{.status.lastPhaseTransitionTime}' | ||
``` | ||
|
||
## Going forward | ||
|
||
The LastPhaseTransitionTime feature is initially introduced as an alpha feature and will be behind a feature gate. | ||
During the alpha phase, we will collect feedback from the community and address any issues or improvements identified. | ||
|
||
Once sufficient feedback has been received, or no complaints are received the feature can move to beta. | ||
The beta phase will allow us to further validate the implementation and ensure its stability. | ||
At least two Kubernetes releases will be available between the beta phase and the general availability (GA) release. | ||
|
||
## Getting involved | ||
|
||
We always welcome new contributors so if you would like to get involved you can | ||
join our [Kubernetes Storage Special-Interest-Group](https://github.com/kubernetes/community/tree/master/sig-storage) (SIG). | ||
|
||
If you would like to share feedback, you can do so on our [public Slack channel](https://app.slack.com/client/T09NY5SBT/C09QZFCE5). | ||
|
||
Special thanks to all the contributors that provided great reviews, shared valuable insight and helped implement this feature (alphabetical order): | ||
|
||
- Han Kang ([logicalhan](https://github.com/logicalhan)) | ||
- Jan Šafránek ([jsafrane](https://github.com/jsafrane/)) | ||
- Jordan Liggitt ([liggitt](https://github.com/liggitt)) | ||
- Kiki ([carlory](https://github.com/carlory)) | ||
- Michelle Au ([msau42](https://github.com/msau42)) | ||
- Wojciech Tyczynski ([wojtek-t](https://github.com/wojtek-t)) | ||
- Xing Yang ([xing-yang](https://github.com/xing-yang)) |