Pipeline: Specify sidecar containers to run inside a TaskRun's Pod

[sbwsg]

Expected Behavior

Users can define sidecar containers to run inside a TaskRun's Pod.

Actual Behavior

There is no way currently to specify sidecar containers as part of any Tekton CRD.

Open Questions

1. What are some good use cases for this feature?
2. Where should sidecars be specified? Task / TaskRun / Pipeline / PipelineRun?
   
   
   
   • What would defining a sidecar in a PipelineRun do? Add a sidecar container to every TaskRun pod started for that pipeline?
   
   

Additional Info

It may be worth writing a short design doc describing the intended usecases and behaviour before committing to an implementation of this.

[sbwsg]

Possible Usecase: https://github.com/tektoncd/pipeline/issues/1032
Summary: User wants to launch a database and webserver in sidecar containers, await their readiness, then have a step container execute integration tests against them.

[sbwsg]

A bunch of other usecases for user-defined sidecars running alongside tasks:

• Start a dummy API server with fixture data in a sidecar for tests to execute against.
• Introduce network proxy so primary Task container can access internal/external networks.
• Introduce network proxy to capture network traffic for debugging and/or test doubles.
• Add a logging sidecar to stream log output from the primary Task container. E.g. stdout/stderr
• Add a results sidecar to upload test result files from the primary Task container. E.g. junit xml
• Run selenium or other headless browser for UI functional testing.

[pierretasci]

I'm not sure if this is the right issue to add this thought to but I wanted to bring up the use case of sidecars that span multiple Tekton tasks. I am thinking here of expensive objects to setup like a database with a full schema that several tasks would call.

This could be an argument for allowing sidecars to be defined on a Pipeline and on a Task.

[sbwsg]

Interesting idea! Am I right in thinking that this is more like a "sidecar Pod" rather than a "sidecar Container"? Sounds like it would need more startup configuration - i.e. a Service to direct traffic to the pod running the initialized database.

My initial thought for sidecars in Pipeline resources was as a way to define containers that will be run as part of each Task's Pod, rather than as a concurrently running Pod with its own containers.

I'm thinking that the "sidecar Pod" approach might be a separate feature request entirely. I can see the usecase for it but I expect the implementation would diverge considerably from the sidecar container support described in this issue.

[sbwsg]

I've written up a short design doc for specifying sidecars in Tekton. Available here.

It doesn't address the issue of enforcing a sidecar lifecycle[1] at the moment. I've been skimming through the k8s codebase looking for the spot where the container termination flow is implemented and it looks as though the precise implementation of the grace period is delegated to the container runtime.

[1] https://kubernetes.io/docs/concepts/workloads/pods/pod/#termination-of-pods

[aristosvo]

@sbwsg Nice piece of work, thanks a lot!

With regard to the implementation of sidecar lifecycle, what are you looking for exactly?

• Validation the sidecar is ready
• Graceful failing
• Graceful termination

Is there more to it?

[sbwsg]

@aristosvo Referring specifically to https://github.com/tektoncd/pipeline/issues/1131 : the ability to signal to sidecars that they're going to be terminated soon so they can clean up / flush buffers etc.