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

Kubernetes 1.29: PodReadyToStartContainers 条件升级至 Beta

随着 Kubernetes 1.29 的发布,`PodReadyToStartContainers` 条件 默认可用。kubelet 在 Pod 的整个生命周期中,在 Pod 的 status 字段中管理该条件的值。kubelet 将使用 `PodReadyToStartContainers` 条件,从 Pod sandbox 创建和容器运行时进行网络配置的角度,准确地反映 Pod 的初始化状态。

这项功能的动机是什么?

集群管理员没有一种清晰且易于访问的方式来查看 Pod sandbox 创建和初始化的完成情况。从 1.28 版本开始,Pod 中的 `Initialized` 条件跟踪 init container 的执行。然而,它在准确反映集群中所有 Pod 的 sandbox 创建完成情况和容器启动准备情况方面存在局限性。这种区分在多租户集群中尤为重要,租户拥有 Pod 规范(包括 init container 的集合),而集群管理员管理存储插件、网络插件和容器运行时处理程序。因此,需要一种改进的机制,为集群管理员提供 Pod sandbox 创建完成情况和容器准备情况的清晰全面的视图。

有什么好处?

  1. 提高了可见性:集群管理员对 Pod sandbox 创建完成情况和容器准备情况有了更清晰、更全面的了解。这种增强的可见性使他们能够做出更明智的决策并更有效地解决问题。
  2. Metrics 收集和监控:监控服务可以利用与 `PodReadyToStartContainers` 条件相关的字段来报告 sandbox 创建状态和延迟。可以按每个 Pod 的基数或根据 Pod 的各种属性(例如 `volumes`、`runtimeClassName`、用于 CNI 和 IPAM 插件的自定义注解或任意标签和注解,以及 PersistentVolumeClaims 的 `storageClassName`)聚合收集 Metrics。这使得能够对整个集群中的 Pod 准备情况进行全面监控和分析。
  3. 增强的故障排除能力:通过更准确地表示 Pod sandbox 创建和容器准备情况,集群管理员可以快速识别和解决初始化过程中可能出现的任何问题。这提升了故障排除能力并减少了停机时间。

下一步是什么?

由于收到的反馈和采用情况,Kubernetes 团队在 1.29 版本中将 `PodReadyToStartContainersCondition` 提升到 Beta 阶段。您的意见将有助于决定此条件是否继续前进并提升到 GA 阶段,因此请就此功能提交更多反馈!

如何了解更多?

请查阅 `PodReadyToStartContainersCondition` 的文档,了解更多关于它以及它如何与其他 Pod 条件相关的内容。

如何参与?

此功能由 SIG Node 社区推动。请加入我们,与社区联系,分享您围绕上述功能及其他方面的想法和反馈。我们期待您的来信!