whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

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

Browse Source 
Co-authored-by: Tim Bannister <tim@scalefactory.com>
This commit is contained in:
Sergey Kanzhelev
2020-11-11 01:38:09 -08:00
committed by GitHub
parent 220a7b201b
commit d81ee2342a
1 changed files with 4 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md
+4 -1
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. 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`) 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 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, 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. the process inside the container may keep running even after probe returned failure because of the timeout.