kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

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 <tim@scalefactory.com>

* Clarify endpoint vs pod conditions

* Add more focus on Pod and less on endpoint

---------

Co-authored-by: Tim Bannister <tim@scalefactory.com>
pull/50782/head
Maxim Nazarenko 2025-05-05 15:43:58 +02:00 committed by GitHub
parent d08348cb42
commit 3cbacc45bb
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 5 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -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?