Update readiness probe docs to match observed behaviour (#49476)

* Update readiness probe docs to match observed behaviour

* Address comment

* Reword

* Describe endpoint and LB instead of Pod

* Address comments

* Fix link

Co-authored-by: Tim Bannister <[email protected]>

* Clarify endpoint vs pod conditions

* Add more focus on Pod and less on endpoint

---------

Co-authored-by: Tim Bannister <[email protected]>

Author: NovemberZulu

content/en/docs/concepts/workloads/pods/pod-lifecycle.md

@@ -562,10 +562,11 @@ processing its startup data, you might prefer a readiness probe.
 
 {{< note >}}
 If you want to be able to drain requests when the Pod is deleted, you do not
-necessarily need a readiness probe; on deletion, the Pod automatically puts itself
-into an unready state regardless of whether the readiness probe exists.
-The Pod remains in the unready state while it waits for the containers in the Pod
-to stop.
+necessarily need a readiness probe; when the Pod is deleted, the corresponding endpoint
+in the `EndppointSlice` will update its [conditions](/docs/concepts/services-networking/endpoint-slices/#conditions):
+the endpoint `ready` condition will be set to `false`, so load balancers
+will not use the Pod for regular traffic. See [Pod termination](#pod-termination)
+for more information about how the kubelet handles Pod deletion.
 {{< /note >}}
 
 #### When should you use a startup probe?