本文已超过一年。较旧的文章可能包含过时的内容。请检查页面中的信息自发布以来是否已不正确。

Kubernetes 中的 PersistentVolume 最后阶段转换时间

作者：Roman Bednář (Red Hat) |

在最近的 Kubernetes v1.28 版本中，我们（SIG Storage）引入了一项新的 alpha 功能，旨在改进 PersistentVolume (PV) 存储管理，并帮助集群管理员更好地了解 PV 的生命周期。通过在 PV 的状态中添加 lastPhaseTransitionTime 字段，集群管理员现在可以跟踪 PV 上次转换为不同阶段的时间，从而实现更高效和知情的资源管理。

为什么我们需要新的 PV 字段？

Kubernetes 中的 PersistentVolume 在为集群中运行的工作负载提供存储资源方面起着至关重要的作用。然而，有效地管理这些 PV 可能具有挑战性，尤其是在确定 PV 上次在不同阶段（例如 Pending、Bound 或 Released）之间转换的时间时。管理员通常需要知道 PV 上次使用的时间或转换为特定阶段的时间；例如，为了实施保留策略、执行清理或监控存储健康状况。

过去，Kubernetes 用户在使用 Delete 保留策略时曾面临数据丢失问题，并且不得不求助于更安全的 Retain 策略。当我们计划引入新的 lastPhaseTransitionTime 字段的工作时，我们希望提供一个更通用的解决方案，该解决方案可用于各种用例，包括基于卷上次使用时间的手动清理或基于阶段转换时间生成警报。

lastPhaseTransitionTime 如何提供帮助

如果您启用了功能门（请参阅如何使用），则 PersistentVolume (PV) 的新 .status.lastPhaseTransitionTime 字段会在 PV 从一个阶段转换为另一个阶段时更新。无论是从 Pending 转换为 Bound，Bound 转换为 Released，还是任何其他阶段转换，都会记录 lastPhaseTransitionTime。对于新创建的 PV，阶段将设置为 Pending，并且也会记录 lastPhaseTransitionTime。

此功能允许集群管理员执行以下操作：

  1. 实施保留策略

    借助 lastPhaseTransitionTime，管理员现在可以跟踪 PV 上次使用的时间或转换为 Released 阶段的时间。此信息对于实施保留策略以清理已在 Released 阶段中特定持续时间的资源至关重要。例如，现在可以轻松编写一个脚本或策略，删除所有已在 Released 阶段中一周的 PV。

  2. 监控存储健康状况

    通过分析 PV 的阶段转换时间，管理员可以更有效地监控存储健康状况。例如，他们可以识别处于 Pending 阶段的时间异常长的 PV，这可能表明存储配置器存在潜在问题。

如何使用

从 Kubernetes v1.28 开始，lastPhaseTransitionTime 字段为 alpha 状态，因此需要启用 PersistentVolumeLastPhaseTransitionTime 功能门。

如果您想在 alpha 阶段测试该功能，则需要在 kube-controller-manager 和 kube-apiserver 上启用此功能门。

使用 --feature-gates 命令行参数

--feature-gates="...,PersistentVolumeLastPhaseTransitionTime=true"

请记住，启用该功能不会立即生效；只有当 PV 更新并在阶段之间转换时，才会填充新字段。然后，管理员可以通过 PV 状态访问新字段，可以使用标准 Kubernetes API 调用或通过 Kubernetes 客户端库检索该状态。

以下是如何使用 kubectl 命令行工具检索特定 PV 的 lastPhaseTransitionTime 的示例

kubectl get pv <pv-name> -o jsonpath='{.status.lastPhaseTransitionTime}'

展望未来

此功能最初是作为 alpha 功能引入的，位于默认情况下禁用的功能门之后。在 alpha 阶段，我们（Kubernetes SIG Storage）将收集最终用户社区的反馈，并解决发现的任何问题或改进。

一旦收到足够的反馈，或者没有收到投诉，该功能就可以转移到 beta 阶段。beta 阶段将允许我们进一步验证实现并确保其稳定性。

在该字段升级到 beta 的版本和该字段升级到正式发布 (GA) 的版本之间，至少会发生两次 Kubernetes 发布。这意味着该字段最早可以正式发布的时间是 Kubernetes 1.32，很可能安排在 2025 年初。

参与其中

我们始终欢迎新的贡献者，因此如果您想参与其中，可以加入我们的 Kubernetes 存储特殊兴趣小组 (SIG)。

如果您想分享反馈，可以在我们的公共 Slack 频道上进行。如果您还不是该 Slack 工作区的一部分，可以访问 https://slack.k8s.io/ 获取邀请。

特别感谢所有提供了精彩评论、分享了宝贵见解并帮助实施此功能的贡献者（按字母顺序排列）