Add a caution regarding the `exec` probe mechanism

Reference Issue: https://github.com/kubernetes/website/issues/41084
1. Exec probe's implementation involves the Kubelet making a gRPC call to the
underlying CRI which inturn involves in the creation of multiple processes that
require a good amount of cpu usage whenever the probe is executed.
2. Whereas the other probes namely `http/gRPC/tcp` involves the Kubelet alone making
a call to the container.
3. There might be a significant amount of cpu overhead in the cases of
higher pod densities, lower periodic intervals when the exec probe is configured.
4. Hence, it would be a good idea to alert the user to opt for the other available probes
in case of the above mentioned scenarios.

Signed-off-by: Sai Ramesh Vanka <svanka@redhat.com>
pull/41286/head
Sai Ramesh Vanka 2023-05-23 21:54:18 +05:30
parent 38ee257860
commit 0ef0dedf3a
1 changed files with 4 additions and 0 deletions

View File

@ -316,6 +316,10 @@ Each probe must define exactly one of these four mechanisms:
the port is open. If the remote system (the container) closes the port is open. If the remote system (the container) closes
the connection immediately after it opens, this counts as healthy. the connection immediately after it opens, this counts as healthy.
{{< caution >}} Unlike the other mechanisms, `exec` probe's implementation involves the creation/forking of multiple processes each time when executed.
As a result, in case of the clusters having higher pod densities, lower intervals of `initialDelaySeconds`, `periodSeconds`, configuring any probe with exec mechanism might introduce an overhead on the cpu usage of the node.
In such scenarios, consider using the alternative probe mechanisms to avoid the overhead.{{< /caution >}}
### Probe outcome ### Probe outcome
Each probe has one of three results: Each probe has one of three results: