Add a caution regarding the exec probe mechanism

Reference Issue: #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 <[email protected]>

Author: sairameshv

content/en/docs/concepts/workloads/pods/pod-lifecycle.md

@@ -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: