Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What does Tekton offer as a runtime #3797

chenbh opened this issue Apr 26, 2019 · 3 comments

What does Tekton offer as a runtime #3797

chenbh opened this issue Apr 26, 2019 · 3 comments


Copy link

@chenbh chenbh commented Apr 26, 2019

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


  • 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


  • 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


Concept mapping (Runtime)

See #3798 for mappings to k8s as a whole


  • 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


@chenbh chenbh added this to Icebox in K8s Runtime Initial Spike via automation Apr 26, 2019
@chenbh chenbh changed the title How can we leverage Tekton as a runtime What does Tekton offer as a runtime Apr 26, 2019
Copy link

@ddadlani ddadlani commented Apr 29, 2019

@nader-ziada @shashwathi @jchesterpivotal thoughts?

@chenbh chenbh moved this from Icebox to Dev Diaries in K8s Runtime Initial Spike Apr 30, 2019
Copy link

@jchesterpivotal jchesterpivotal commented Apr 30, 2019

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.

Copy link
Contributor Author

@chenbh chenbh commented Apr 30, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
No open projects

No branches or pull requests

3 participants