add blog post to reflect state of podreadytostartcontainerscondition

content/en/blog/_posts/2023-11-14-PodReadyToStartContainersCondition-in-beta.md

@@ -0,0 +1,38 @@
+---
+layout: blog
+title: "Kubernetes 1.29: PodReadyToStartContainersCondition in beta"
+date: 2023-11-13
+slug: pod-ready-to-start-containers-condition-now-in-beta
+---
+
+**Author**: Kevin Hannon(Red Hat)  zefeng chen
+
+
+With Kubernetes 1.29 the PodReadyToStartContainersCondition functionality entered beta and is available by default.
+A new kubelet-managed pod condition in the status field of a pod. The kubelet 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
+
+## Some history
+
+It's previous known as ``PodHasNetwork``. You probably wander why we need a new condition for kubelet. In some cases, metric collection and monitoring services can use the fields associated with the PodReadyToStartContainers condition to report sandbox creation state
+and latency either at a per-pod cardinality or aggregate the data based on various properties of the pod: number of volumes, storage class of PVCs, runtime class, custom annotations for CNI and IPAM plugins,
+arbitrary labels and annotations on pods, etc.
+
+
+### What’s next?
+
+Depending on feedback and adoption, the Kubernetes team plans to promote
+the `PodReadyToStartContainersCondition` condition to Beta in 1.29.
+
+### How can I learn more?
+
+Please check out the
+[documentation](/docs/concepts/workloads/pods/pod-lifecycle/) for the
+`PodReadyToStartContainersCondition` to learn more about it and how it fits in relation to
+other pod conditions.
+
+### How to get involved?
+
+This feature is driven by the SIG Node community. Please join us to connect with
+the community and share your ideas and feedback around the above feature and
+beyond. We look forward to hearing from you!