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

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
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
content/en/docs/concepts/workloads/pods/pod-lifecycle.md
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 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
Each probe has one of three results: