From 1a13c6ba45e1110edd03dcd4fc1ca578d6918f10 Mon Sep 17 00:00:00 2001 From: Sergey Kanzhelev Date: Wed, 11 Nov 2020 01:38:45 -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 e4add99e2a..4138fd7a3a 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 @@ -343,7 +343,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 `ExecProbeTimeout` (set it to `false`) +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 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,