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

Merge pull request #28406 from sftim/20210614_tweak_readiness_probe_explanation 

Revise explanation for when to use readiness probes
This commit is contained in:
Kubernetes Prow Robot 2021-07-15 05:20:48 -07:00 committed by GitHub
parent 2c5fabeeaf 7045fc791d
commit 2ba49ba415
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 12 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -304,13 +304,23 @@ specify a readiness probe. In this case, the readiness probe might be the same
as the liveness probe, but the existence of the readiness probe in the spec means as the liveness probe, but the existence of the readiness probe in the spec means
that the Pod will start without receiving any traffic and only start receiving that the Pod will start without receiving any traffic and only start receiving
traffic after the probe starts succeeding. traffic after the probe starts succeeding.
If your container needs to work on loading large data, configuration files, or
migrations during startup, specify a readiness probe.
If you want your container to be able to take itself down for maintenance, you If you want your container to be able to take itself down for maintenance, you
can specify a readiness probe that checks an endpoint specific to readiness that can specify a readiness probe that checks an endpoint specific to readiness that
is different from the liveness probe. is different from the liveness probe.
If your app has a strict dependency on back-end services, you can implement both
a liveness and a readiness probe. The liveness probe passes when the app itself
is healthy, but the readiness problem additionally checks that each required
back-end service is available. This helps you avoid directing traffic to Pods
that can only respond with error messages.
If your container needs to work on loading large data, configuration files, or
migrations during startup, you can use a
[startup probe](#when-should-you-use-a-startup-probe). However, if you want to
detect the difference between an app that has failed and an app that is still
processing its startup data, you might prefer a readiness probe.
{{< note >}} {{< note >}}
If you want to be able to drain requests when the Pod is deleted, you do not 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 necessarily need a readiness probe; on deletion, the Pod automatically puts itself