From 360170b1eaad503466d48c2487901642b6ce70fc Mon Sep 17 00:00:00 2001 From: Kevin Hannon Date: Fri, 23 Jun 2023 09:35:42 -0400 Subject: [PATCH 1/5] rename PodHasNetwork to PodReadyToStartContainers as part of alpha rename --- .../2022-09-14-pod-has-network-condition.md | 36 +++++++++---------- 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/content/en/blog/_posts/2022-09-14-pod-has-network-condition.md b/content/en/blog/_posts/2022-09-14-pod-has-network-condition.md index 00bd8ad977b49..fc34e1d6a4e17 100644 --- a/content/en/blog/_posts/2022-09-14-pod-has-network-condition.md +++ b/content/en/blog/_posts/2022-09-14-pod-has-network-condition.md @@ -1,6 +1,6 @@ --- layout: blog -title: 'Kubernetes 1.25: PodHasNetwork Condition for Pods' +title: 'Kubernetes 1.25: PodReadyToStart Condition for Pods' date: 2022-09-14 slug: pod-has-network-condition --- @@ -9,18 +9,18 @@ slug: pod-has-network-condition Deep Debroy (Apple) Kubernetes 1.25 introduces Alpha support for a new kubelet-managed pod condition -in the status field of a pod: `PodHasNetwork`. The kubelet, for a worker node, -will use the `PodHasNetwork` condition to accurately surface the initialization +in the status field of a pod: `PodReadyToStartContainers`. The kubelet, for a worker node, +will use the `PodReadyToStartContainers` condition to accurately surface the initialization state of a pod from the perspective of pod sandbox creation and network configuration by a container runtime (typically in coordination with CNI plugins). The kubelet starts to pull container images and start individual -containers (including init containers) after the status of the `PodHasNetwork` +containers (including init containers) after the status of the `PodReadyToStartContainers` condition is set to `"True"`. Metrics collection services that report latency of pod initialization from a cluster infrastructural perspective (i.e. agnostic of per container characteristics like image size or payload) can utilize the -`PodHasNetwork` condition to accurately generate Service Level Indicators +`PodReadyToStartContainers` condition to accurately generate Service Level Indicators (SLIs). Certain operators or controllers that manage underlying pods may utilize -the `PodHasNetwork` condition to optimize the set of actions performed when pods +the `PodReadyToStartContainers` condition to optimize the set of actions performed when pods repeatedly fail to come up. ### How is this different from the existing Initialized condition reported for pods? @@ -44,14 +44,14 @@ containers will report the status of the `Initialized` condition as `"True"` even if the container runtime is not able to successfully initialize the pod sandbox environment. -Relative to either situation above, the `PodHasNetwork` condition surfaces more +Relative to either situation above, the `PodReadyToStartContainers` condition surfaces more accurate data around when the pod runtime sandbox was initialized with networking configured so that the kubelet can proceed to launch user-configured containers (including init containers) in the pod. ### Special Cases -If a pod specifies `hostNetwork` as `"True"`, the `PodHasNetwork` condition is +If a pod specifies `hostNetwork` as `"True"`, the `PodReadyToStartContainers` condition is set to `"True"` based on successful creation of the pod sandbox while the network configuration state of the pod sandbox is ignored. This is because the CRI implementation typically skips any pod sandbox network configuration when @@ -61,17 +61,17 @@ A node agent may dynamically re-configure network interface(s) for a pod by watching changes in pod annotations that specify additional networking configuration (e.g. `k8s.v1.cni.cncf.io/networks`). Dynamic updates of pod networking configuration after the pod sandbox is initialized by Kubelet (in -coordination with a container runtime) are not reflected by the `PodHasNetwork` +coordination with a container runtime) are not reflected by the `PodReadyToStartContainers` condition. -### Try out the PodHasNetwork condition for pods +### Try out the PodReadyToStartContainers condition for pods -In order to have the kubelet report the `PodHasNetwork` condition in the status -field of a pod, please enable the `PodHasNetworkCondition` feature gate on the +In order to have the kubelet report the `PodReadyToStartContainers` condition in the status +field of a pod, please enable the `PodReadyToStartContainersCondition` feature gate on the kubelet. For a pod whose runtime sandbox has been successfully created and has networking -configured, the kubelet will report the `PodHasNetwork` condition with status set to `"True"`: +configured, the kubelet will report the `PodReadyToStartContainers` condition with status set to `"True"`: ``` $ kubectl describe pod nginx1 @@ -80,7 +80,7 @@ Namespace: default ... Conditions: Type Status - PodHasNetwork True + PodReadyToStartContainers True Initialized True Ready True ContainersReady True @@ -88,7 +88,7 @@ Conditions: ``` For a pod whose runtime sandbox has not been created yet (and networking not -configured either), the kubelet will report the `PodHasNetwork` condition with +configured either), the kubelet will report the `PodReadyToStartContainers` condition with status set to `"False"`: ``` @@ -98,7 +98,7 @@ Namespace: default ... Conditions: Type Status - PodHasNetwork False + PodReadyToStartContainers False Initialized True Ready False ContainersReady False @@ -108,13 +108,13 @@ Conditions: ### What’s next? Depending on feedback and adoption, the Kubernetes team plans to push the -reporting of the `PodHasNetwork` condition to Beta in 1.26 or 1.27. +reporting of the `PodReadyToStartContainers` condition to Beta in 1.26 or 1.27. ### How can I learn more? Please check out the [documentation](/docs/concepts/workloads/pods/pod-lifecycle/) for the -`PodHasNetwork` condition to learn more about it and how it fits in relation to +`PodReadyToStartContainers` condition to learn more about it and how it fits in relation to other pod conditions. ### How to get involved? From e0a9d6aed595cd4d314ec79127173b8407e5f76b Mon Sep 17 00:00:00 2001 From: Kevin Hannon Date: Fri, 23 Jun 2023 09:43:58 -0400 Subject: [PATCH 2/5] update blog post with latest name --- content/en/blog/_posts/2022-09-14-pod-has-network-condition.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/blog/_posts/2022-09-14-pod-has-network-condition.md b/content/en/blog/_posts/2022-09-14-pod-has-network-condition.md index fc34e1d6a4e17..f19b91e4f9814 100644 --- a/content/en/blog/_posts/2022-09-14-pod-has-network-condition.md +++ b/content/en/blog/_posts/2022-09-14-pod-has-network-condition.md @@ -1,6 +1,6 @@ --- layout: blog -title: 'Kubernetes 1.25: PodReadyToStart Condition for Pods' +title: 'Kubernetes 1.25: PodReadyToStartContainers Condition for Pods' date: 2022-09-14 slug: pod-has-network-condition --- From b3af1a9553862ece5adc68c02cfcf456dc1503e2 Mon Sep 17 00:00:00 2001 From: Kevin Hannon Date: Wed, 12 Jul 2023 12:47:25 -0400 Subject: [PATCH 3/5] add a note mentioning the rename in 1.28 --- .../2022-09-14-pod-has-network-condition.md | 42 +++++++++++-------- 1 file changed, 24 insertions(+), 18 deletions(-) diff --git a/content/en/blog/_posts/2022-09-14-pod-has-network-condition.md b/content/en/blog/_posts/2022-09-14-pod-has-network-condition.md index f19b91e4f9814..b78d8dcf53003 100644 --- a/content/en/blog/_posts/2022-09-14-pod-has-network-condition.md +++ b/content/en/blog/_posts/2022-09-14-pod-has-network-condition.md @@ -1,6 +1,6 @@ --- layout: blog -title: 'Kubernetes 1.25: PodReadyToStartContainers Condition for Pods' +title: 'Kubernetes 1.25: PodHasNetwork Condition for Pods' date: 2022-09-14 slug: pod-has-network-condition --- @@ -9,20 +9,26 @@ slug: pod-has-network-condition Deep Debroy (Apple) Kubernetes 1.25 introduces Alpha support for a new kubelet-managed pod condition -in the status field of a pod: `PodReadyToStartContainers`. The kubelet, for a worker node, -will use the `PodReadyToStartContainers` condition to accurately surface the initialization +in the status field of a pod: `PodHasNetwork`. The kubelet, for a worker node, +will use the `PodHasNetwork` condition to accurately surface the initialization state of a pod from the perspective of pod sandbox creation and network configuration by a container runtime (typically in coordination with CNI plugins). The kubelet starts to pull container images and start individual -containers (including init containers) after the status of the `PodReadyToStartContainers` +containers (including init containers) after the status of the `PodHasNetwork` condition is set to `"True"`. Metrics collection services that report latency of pod initialization from a cluster infrastructural perspective (i.e. agnostic of per container characteristics like image size or payload) can utilize the -`PodReadyToStartContainers` condition to accurately generate Service Level Indicators +`PodHasNetwork` condition to accurately generate Service Level Indicators (SLIs). Certain operators or controllers that manage underlying pods may utilize -the `PodReadyToStartContainers` condition to optimize the set of actions performed when pods +the `PodHasNetwork` condition to optimize the set of actions performed when pods repeatedly fail to come up. +### Updates for Kubernetes 1.28 + +The PodHasNetwork condition has been renamed to PodReadyToStartContainers. +To enable this alpha feature you have to set the feature toggle PodReadyToStartContainersCondition +to true. + ### How is this different from the existing Initialized condition reported for pods? The kubelet sets the status of the existing `Initialized` condition reported in @@ -44,14 +50,14 @@ containers will report the status of the `Initialized` condition as `"True"` even if the container runtime is not able to successfully initialize the pod sandbox environment. -Relative to either situation above, the `PodReadyToStartContainers` condition surfaces more +Relative to either situation above, the `PodHasNetwork` condition surfaces more accurate data around when the pod runtime sandbox was initialized with networking configured so that the kubelet can proceed to launch user-configured containers (including init containers) in the pod. ### Special Cases -If a pod specifies `hostNetwork` as `"True"`, the `PodReadyToStartContainers` condition is +If a pod specifies `hostNetwork` as `"True"`, the `PodHasNetwork` condition is set to `"True"` based on successful creation of the pod sandbox while the network configuration state of the pod sandbox is ignored. This is because the CRI implementation typically skips any pod sandbox network configuration when @@ -61,17 +67,17 @@ A node agent may dynamically re-configure network interface(s) for a pod by watching changes in pod annotations that specify additional networking configuration (e.g. `k8s.v1.cni.cncf.io/networks`). Dynamic updates of pod networking configuration after the pod sandbox is initialized by Kubelet (in -coordination with a container runtime) are not reflected by the `PodReadyToStartContainers` +coordination with a container runtime) are not reflected by the `PodHasNetwork` condition. -### Try out the PodReadyToStartContainers condition for pods +### Try out the PodHasNetwork condition for pods -In order to have the kubelet report the `PodReadyToStartContainers` condition in the status -field of a pod, please enable the `PodReadyToStartContainersCondition` feature gate on the +In order to have the kubelet report the `PodHasNetwork` condition in the status +field of a pod, please enable the `PodHasNetworkCondition` feature gate on the kubelet. For a pod whose runtime sandbox has been successfully created and has networking -configured, the kubelet will report the `PodReadyToStartContainers` condition with status set to `"True"`: +configured, the kubelet will report the `PodHasNetwork` condition with status set to `"True"`: ``` $ kubectl describe pod nginx1 @@ -80,7 +86,7 @@ Namespace: default ... Conditions: Type Status - PodReadyToStartContainers True + PodHasNetwork True Initialized True Ready True ContainersReady True @@ -88,7 +94,7 @@ Conditions: ``` For a pod whose runtime sandbox has not been created yet (and networking not -configured either), the kubelet will report the `PodReadyToStartContainers` condition with +configured either), the kubelet will report the `PodHasNetwork` condition with status set to `"False"`: ``` @@ -98,7 +104,7 @@ Namespace: default ... Conditions: Type Status - PodReadyToStartContainers False + PodHasNetwork False Initialized True Ready False ContainersReady False @@ -108,13 +114,13 @@ Conditions: ### What’s next? Depending on feedback and adoption, the Kubernetes team plans to push the -reporting of the `PodReadyToStartContainers` condition to Beta in 1.26 or 1.27. +reporting of the `PodHasNetwork` condition to Beta in 1.26 or 1.27. ### How can I learn more? Please check out the [documentation](/docs/concepts/workloads/pods/pod-lifecycle/) for the -`PodReadyToStartContainers` condition to learn more about it and how it fits in relation to +`PodHasNetwork` condition to learn more about it and how it fits in relation to other pod conditions. ### How to get involved? From 6e1a413071c0a3bc302d4058269347fc2f56f043 Mon Sep 17 00:00:00 2001 From: Kevin Hannon Date: Mon, 24 Jul 2023 13:23:42 -0400 Subject: [PATCH 4/5] Update content/en/blog/_posts/2022-09-14-pod-has-network-condition.md Co-authored-by: Tim Bannister --- content/en/blog/_posts/2022-09-14-pod-has-network-condition.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/blog/_posts/2022-09-14-pod-has-network-condition.md b/content/en/blog/_posts/2022-09-14-pod-has-network-condition.md index b78d8dcf53003..9eb0b940c02bb 100644 --- a/content/en/blog/_posts/2022-09-14-pod-has-network-condition.md +++ b/content/en/blog/_posts/2022-09-14-pod-has-network-condition.md @@ -25,7 +25,7 @@ repeatedly fail to come up. ### Updates for Kubernetes 1.28 -The PodHasNetwork condition has been renamed to PodReadyToStartContainers. +The `PodHasNetwork` condition has been renamed to `PodReadyToStartContainers`. To enable this alpha feature you have to set the feature toggle PodReadyToStartContainersCondition to true. From 20b50495e9c27760d99b2d7436eb89cbcb2d92e3 Mon Sep 17 00:00:00 2001 From: Kevin Hannon Date: Mon, 24 Jul 2023 13:23:58 -0400 Subject: [PATCH 5/5] Update content/en/blog/_posts/2022-09-14-pod-has-network-condition.md Co-authored-by: Tim Bannister --- .../en/blog/_posts/2022-09-14-pod-has-network-condition.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/content/en/blog/_posts/2022-09-14-pod-has-network-condition.md b/content/en/blog/_posts/2022-09-14-pod-has-network-condition.md index 9eb0b940c02bb..beb4b07c47904 100644 --- a/content/en/blog/_posts/2022-09-14-pod-has-network-condition.md +++ b/content/en/blog/_posts/2022-09-14-pod-has-network-condition.md @@ -26,8 +26,9 @@ repeatedly fail to come up. ### Updates for Kubernetes 1.28 The `PodHasNetwork` condition has been renamed to `PodReadyToStartContainers`. -To enable this alpha feature you have to set the feature toggle PodReadyToStartContainersCondition -to true. +Alongside that change, the feature gate `PodHasNetworkCondition` has been replaced by +`PodReadyToStartContainersCondition`. You need to set `PodReadyToStartContainersCondition` +to true in order to use the new feature in v1.28.0 and later. ### How is this different from the existing Initialized condition reported for pods?