The Workflow: Pipeline
A Pipeline connects multiple Tasks into a directed acyclic graph (DAG). Think of it as the full production schedule for a film: individual scenes (Tasks) can be shot in parallel or must wait for prerequisite scenes to finish, and the schedule defines those dependencies.
Technically, a Pipeline lists tasks entries and uses runAfter to express ordering dependencies. Tasks without runAfter constraints can run in parallel immediately. A representative CI Pipeline shares a single workspace across four tasks: clone (no dependency, runs first), test and lint (both listing clone in their runAfter, so both start the moment clone finishes and run concurrently with each other), and build-image (listing both test and lint in its runAfter, so it waits for both to succeed before starting).
In this example, test and lint run in parallel after clone finishes. build-image only starts when both test and lint succeed. This is the DAG in action.
The Execution: PipelineRun
A PipelineRun instantiates a Pipeline, just as a TaskRun instantiates a Task. The PipelineRun automatically creates child TaskRun objects, which in turn create Pods. You never manually create TaskRuns when running a Pipeline — the controller handles that. A PipelineRun references the Pipeline by name and binds its declared workspace to a concrete resource — typically a PersistentVolumeClaim that the tasks share.
Critical distinction: Unlike Steps within a Task (same Pod, same node), Tasks within a Pipeline run in separate Pods. This means they can be scheduled on different nodes, enabling true horizontal parallelism — but it also means they cannot share the filesystem directly. That's where Workspaces come in.