Configurability for network-based health checks in podman kube play

[yoe]

Feature request description

Currently, when a Kubernetes manifest is created that requests HTTP- or TCP-based health checks, as implemented by PR #10956, the container health check is implemented in terms of a command-based health check that runs inside the container and that will try to execute either curl (for HTTP-based health checks) or nc (for TCP-based ones).

This works if the respective commands are actually installed in the container, but that is making assumptions that may not always be met.

Ideally, the behavior for dealing with health checks should keep this in mind.

Suggest potential solution

It would be nice if the user invoking podman kube play could decide what to do in case of such health checks. I would think the following could be valid options:

• Do nothing (ignore the health checks). This does mean that an application posting unhealthy is allowed to run when it should not be, but that is usually preferable over an application posting healthy being considered to have failed because curl is not in the image. Additionally, the user can still install 3rd-party monitoring tools to monitor the application health, and take appropriate action that way.
• Perform the health check from the infra container (i.e., the one running the podman-pause image). This would require that curl and/or nc are installed in the podman-pause image, but that makes less assumptions about third-party containers and is therefore safer to do.
• Perform the health check from the application container (the current behavior). This should probably not be the default.

Have you considered any alternatives?

It should theoretically be possible to filter out health checks by using tools such as jq to edit the Kubernetes manifest before passing it to podman, but this should not be necessary in the first place.

Additional context

No response