What does Tekton offer as a runtime

[chenbh]

This is a summary of things we've discovered while doing investigating if it would make sense for Concourse to use tekton as another runtime. Much of the material here was part of concourse/rfcs#22

Tekton version: v0.2.0

Concept mapping (Core)

Mostly to do with how Concourse concepts map to Tekton concepts

Task

• best maps to Concourse steps
• all containers inside the pod share the same workspace -> breaks the container isolation contract Concourse provides ( Tekton provides process isolation but not filesystem isolation when using a )
• Tekton injects a binary before your code that executes your command and then writes to a file when it finishes
  • they achieve sequential execution of (Tekton) Task Steps by making every subsequent container wait until they see the file of the previous container (remember that every container in the pod shares the same workspace)
  • seems kinda gimmicky, but it's hard to do sequential containers in pods without putting everything in init containers

Pipeline

• best maps to Concourse jobs
• Concourse supports both sequential and parallel execution of (Concourse) steps, therefore (Tekton) Tasks are a poor fit as they can only do sequential execution (their roadmap does indicate that they're looking to change this in the future). Instead we would most likely have to use a (Tekton) Pipeline or even create multiple (Tekton) Tasks and manage them explicitly

Resource

• the way they transfer bits between the (Tekton) Tasks is that it's copied onto a shared PVC, mounted to an init container on the new Task, contents are then copied to the shared workspace accessible to the Step container
• VERY under-developed right now
  • the Git Resource can only pull, you have to do pushes from within your Step
  • the Image and Cluster Resource is literally a glorified key-value store (seriously, you have to provide your own image that does the actual functionality: https://github.com/tektoncd/pipeline/blob/639b3007b1d48cfa094649108f72ddf0f12eddae/examples/pipelineruns/pipelinerun.yaml#L73-L101)
• no support for custom resources

Concept mapping (Runtime)

See #3798 for mappings to k8s as a whole

Volumes

• Concourse workers manage a large number of volumes to pass between containers, some examples include: resource get and put steps, task input and output steps, task step caches, resource check caches
• we rely on Copy on Write volumes pretty heavily for optimization
• if we want to pass files between (Tekton) Tasks we would have to use something like PVCs or GCS buckets
• Tekton only supports GCS buckets for now, but there is issue to support the other IaaS's
• Tekton creates one PVC per PipelineRun to store the input/output of all the Resources in the run
  • by default the size of this PVC is 5Gi, this might be awkward for us since we have no way of knowing the size of the files ahead of time
• Concourse would have to create, mount, and delete PVCs, Tekton does not provide anything to make this easier

References

• How are PipelineResources handled under the hood
• Tasks
• Pipelines
• PipelineResources

[ddadlani]

@nader-ziada @shashwathi @jchesterpivotal thoughts?

[jchesterpivotal]

Resource incompatibility seems like the biggest problem to me; the rest seems on a skim like it could be obscured behind some sort of abstraction boundary.

[chenbh]

Concourse Resources can almost be run as Tekton Tasks as long as we can figure out an efficient way of moving the bits from one pod to another