From 1f306541c7fde10ccf8a725221cf6a3e6d79c057 Mon Sep 17 00:00:00 2001 From: Sergey Kanzhelev Date: Wed, 11 Nov 2020 01:39:07 -0800 Subject: [PATCH] Update content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md Co-authored-by: Tim Bannister --- .../configure-liveness-readiness-startup-probes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md index 4138fd7a3a..cdbcddb5d0 100644 --- a/content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md +++ b/content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md @@ -344,7 +344,7 @@ until a result was returned. This defect was corrected in Kubernetes v1.20. You may have been relying on the previous behavior, even without realizing it, as the default timeout is 1 second. As a cluster administrator, you can disable the [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `ExecProbeTimeout` (set it to `false`) -on kubelet to restore the behavior from older versions, then remove that override +on each 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. 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