Allow customisation of sleeperImage in --replace mode for compliance with cluster restrictions

[kbatalin]

Please describe your use case / problem.
When using Telepresence in --replace mode to intercept a deployment, the service container is replaced with a "sleeperImage" (currently hardcoded to alpine:latest). However, in my environment, I face restrictions on the Docker registries and versions of images allowed in the cluster. This hardcoding prevents me from using Telepresence effectively in --replace mode due to compliance and compatibility constraints.

I need the --replace mode specifically for services that run background tasks, as the ordinary interception via sidecar only redirects traffic to the local process but does not handle the original container's background jobs, which continue working. While sidecar-based interception is fast and sufficient for most use cases, it is inadequate for scenarios involving tasks such as batch processing or scheduled jobs.

Describe the solution you'd like
I would like the ability to override the sleeperImage (including the image registry and tag) used in --replace mode. This could be implemented in a way that allows flexibility, such as:

• Adding configurable values in the Telepresence Helm chart.
• Providing CLI parameters to specify the image, registry, and tag during the interception setup.

Either option would work, though the former might be better for environments with stricter cluster-wide policies.

Describe alternatives you've considered
Manually stopping the original container before each interception.
While this could stop the background processes temporarily, it introduces challenges with liveness probes configured on the deployment, which may trigger pod restarts or other issues.

Versions (please complete the following information)

• Output of telepresence version:

OSS Client         : v2.21.1
OSS Root Daemon    : v2.21.1
OSS User Daemon    : v2.21.1
OSS Traffic Manager: v2.21.1
Traffic Agent      : telepresenceio/tel2:2.21.1

• Kubernetes Environment and Version
  all versions

Additional context
This feature would significantly enhance Telepresence's usability for services with background tasks and in restricted environments. Example of the command: telepresence intercept <name> --port <ports> --env-file <env-file> --replace

[thallgren]

@kbatalin I'm considering a solution where there would be no replacement container at all. Instead, the traffic-agent would serve as the replacement. The traffic-agent would then listen and forward all ports that the replaced container was listening to to the local process.

Would such a solution work for your use-case?

[kbatalin]

@thallgren
Thank you for the prompt response and for considering a solution!

If I understand correctly, in this proposed solution, the original container would be completely replaced by the traffic-agent, and no background processes from the original container would remain active. Is that correct?

If so, this approach might work for my use case, as the key requirement is to stop any background tasks or processes from the original container while testing or developing locally.