From 654ed70cb15efa81df082ceb944f79f45c232f8e Mon Sep 17 00:00:00 2001 From: Priyanka Saggu Date: Thu, 12 Feb 2026 13:05:09 +0530 Subject: [PATCH] docs: update PodReadyToStartContainers to reflect volume and DRA readiness --- .../concepts/workloads/pods/pod-lifecycle.md | 22 ++++++++++--------- 1 file changed, 12 insertions(+), 10 deletions(-) diff --git a/content/en/docs/concepts/workloads/pods/pod-lifecycle.md b/content/en/docs/concepts/workloads/pods/pod-lifecycle.md index 0c599f9c3acf1..bc69d1c7ae5db 100755 --- a/content/en/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/en/docs/concepts/workloads/pods/pod-lifecycle.md @@ -595,8 +595,9 @@ through which the Pod has or has not passed. The kubelet manages the following PodConditions: * `PodScheduled`: the Pod has been scheduled to a node. -* `PodReadyToStartContainers`: (beta feature; enabled by [default](#pod-has-network)) the - Pod sandbox has been successfully created and networking configured. +* `PodReadyToStartContainers`: (beta feature; enabled by [default](#pod-ready-to-start-containers)) the + Pod sandbox has been successfully created, networking configured, storage volumes mounted, + and any dynamic resources (if requested) allocated. * `ContainersReady`: all containers in the Pod are ready. * `Initialized`: all [init containers](/docs/concepts/workloads/pods/init-containers/) have completed successfully. @@ -674,7 +675,7 @@ when both the following statements apply: When a Pod's containers are Ready but at least one custom condition is missing or `False`, the kubelet sets the Pod's [condition](#pod-conditions) to `ContainersReady`. -### Pod network readiness {#pod-has-network} +### Pod readiness to start containers {#pod-ready-to-start-containers} {{< feature-state for_k8s_version="v1.29" state="beta" >}} @@ -686,8 +687,10 @@ After a Pod gets scheduled on a node, it needs to be admitted by the kubelet and to have any required storage volumes mounted. Once these phases are complete, the kubelet works with a container runtime (using {{< glossary_tooltip term_id="cri" >}}) to set up a -runtime sandbox and configure networking for the Pod. If the -`PodReadyToStartContainersCondition` +runtime sandbox and configure networking for the Pod. If the Pod uses +[Dynamic Resource Allocation](/docs/concepts/scheduling-eviction/dynamic-resource-allocation/), +those resources are also allocated during this phase. +If the `PodReadyToStartContainersCondition` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) is enabled (it is enabled by default for Kubernetes {{< skew currentVersion >}}), the `PodReadyToStartContainers` condition will be added to the `status.conditions` field of a Pod. @@ -704,10 +707,9 @@ the following scenarios: sandbox virtual machine rebooting, which then requires creating a new sandbox and fresh container network configuration. -The `PodReadyToStartContainers` condition is set to `True` by the kubelet after the -successful completion of sandbox creation and network configuration for the Pod -by the runtime plugin. The kubelet can start pulling container images and create -containers after `PodReadyToStartContainers` condition has been set to `True`. +After sandbox creation, network configuration, volume mounting, and (if requested) dynamic resource +allocation are complete, the kubelet sets the `PodReadyToStartContainers` condition to `True`. +Image pulling and container creation occur after this point. For a Pod with init containers, the kubelet sets the `Initialized` condition to `True` after the init containers have successfully completed (which happens @@ -1169,4 +1171,4 @@ When the kubelet restarts, the container statuses are managed differently based * For detailed information about Pod and container status in the API, see the API reference documentation covering - [`status`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodStatus) for Pod. + [`status`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodStatus) for Pod. \ No newline at end of file