This issue is currently awaiting triage.

If a SIG or subproject determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

/sig node

If the relevant SIG believes this feature request is worthwhile, I can begin working on it.

/kind feature

IIUC, a simple workaround is using exec probe.

• There are alternative solutions, but I am not opposed to this requirement.

IIUC, a simple workaround is using exec probe.

Yes, that's correct, but it would mean the image needs to have curl (or a similar tool) included, which isn’t always the case. Plus, using exec would make the probe configuration a bit more verbose.

Exec probes are also a bit more resource intensive compared to the other ones. I kinda like the idea of supporting the predefined environment variables, but it needs to apply to all other types of probes as well.

I’m considering an approach like the one below to resolve environment variables in the path:

exec := exec.New()
cmd := exec.Command("echo", pathToProcess)
buff := bytes.Buffer{}
cmd.SetStdout(&buff)
cmd.Run()
processedPath := buff.String()

However, I’m concerned this might not be safe, as it could open the door to remote shell execution attacks (though exec probes have a similar risk). Additionally, running a shell before using httpGet could end up being just as resource-intensive as exec probes. An alternative might be to fetch environment variables directly from the container object, but there’s a chance that some variables in the path might not be present in the container spec. Additionally, values for certain variables, like the pod name, cannot be derived from the container spec.

An alternative might be to fetch environment variables directly from the container object

That's how we should do it from my point of view.

That's how we should do it from my point of view.

I think I’m leaning toward the first approach since, as mentioned, fetching environment variables directly from the container object wouldn’t work for all cases.

We should use Kubernetes-style environment variable interpolation, I think

See https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/#using-environment-variables-inside-of-your-config for an example.

@bachmanity1 the issue is that the kubelet calls the http probes directly, while exec'ing into the container comes with a reasonable overhead. Keeping those constraints allows us only to work with the data we have at the manifest level.

Thanks for the feedback! I’m planning to open a PR in a couple of days using Kubernetes-style environment variable interpolation.

/assign @bachmanity1

Hi @pacoxu, @saschagrunert, and @sftim, thank you for your feedback! I've opened a PR and linked it above. Could you take a look when you have a moment? Thanks!

Exec probes are also a bit more resource intensive compared to the other ones. I kinda like the idea of supporting the predefined environment variables, but it needs to apply to all other types of probes as well.

@saschagrunert they are not for the kubelet, http and tcp probes steal resources from the kubelet that is more problematic, actually for constrained kubelet that fails network probes the workaround is to move to use exec probes #89898 (comment)

reinterpreting existing fields in new ways isn't really ok... existing httpGet probes with environment-looking substrings would behave differently

see kubernetes/enhancements#559 / #71351 for a similar addition to support envvars in subpath mounts, which required a new field that explicitly supported envvar expansion

if this was added, I would expect the same env values and format used to expand other aspects of the pod (container args, etc)