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

Update content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md 

Co-authored-by: Tim Bannister <tim@scalefactory.com>
pull/24692/head
Sergey Kanzhelev 2020-11-11 01:38:09 -08:00 committed by GitHub
parent 220a7b201b
commit d81ee2342a
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 4 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md
View File

@ -345,7 +345,10 @@ This defect was corrected in Kubernetes v1.20. You may have been relying on the
even without realizing it, as the default timeout is 1 second.
As a cluster administrator, you can disable the feature gate `ExecProbeTimeout` (set it to `false`)
on kubelet to restore the behavior from older versions, then remove that override
once all the exec probes in the cluster have a `timeoutSeconds` value set.
once all the exec probes in the cluster have a `timeoutSeconds` value set.
If you have pods that are impacted from the default 1 second timeout,
you should update their probe timeout so that you're ready for the
eventual removal of that feature gate.
With the fix of the defect, for exec probes, on Kubernetes `1.20+` with the `dockershim` container runtime,
the process inside the container may keep running even after probe returned failure because of the timeout.