Before learning about how Tekton works, it's useful to take some time to understand what a Kubernetes object is. Please see Understanding Kubernetes objects for an overview of working with objects. Kubernetes API conventions docs are another useful resource for understanding object terminology.
Tekton objects, including Tasks, TaskRuns, Pipelines, PipelineRuns, and other resources, are implemented as Kubernetes CustomResourceDefinitions, which are extensions of the Kubernetes API. To better understand what it means to create a CustomResourceDefinition (CRD), check out the tutorial Extend the Kubernetes API with CustomResourceDefinitions. Tekton CRDs are defined in the config folder, and the schemas of these CRDs are defined as Go structs in the apis folder.
Creating an instance of a CRD doesn't "do" much. As shown in the CRD tutorial, creating a CRD allows you to list Objects of that Kind but doesn't result in anything executing. As described in "custom controllers", you must implement a controller to change a Kubernetes cluster's state when an instance of a CRD is created, a process called "reconciling". Reconcilers change the cluster based on the desired behavior defined in an object's "spec", and update the object's "status" to reflect what happened.
The Kubebuilder tutorial is a helpful resource for understanding what it means to build a controller that reconciles CRDs. (Note: Tekton does not use Kubebuilder.)
Not all Tekton CRDs have controllers. For example, there is no reconciler for Tasks, meaning that creating a Task doesn't "do" anything. To run a Task, you must create an instance of a TaskRun referencing it, and the TaskRun is executed by the TaskRun reconciler.
The TaskRun reconciler code is found in pkg/reconciler/taskrun/taskrun.go, and the PipelineRun reconciler code is found in pkg/reconciler/pipelinerun/pipelinerun.go.
All Tekton CRDs use validating admission webhooks to validate instances of CRDs. Some CRDs also use mutating admission webhooks to set default values for some fields. Validation and defaulting code is found in the apis folder. For a useful overview and tutorial on admission webhooks, see In-depth introduction to Kubernetes admission webhooks.
Tekton uses knative/pkg to generate client code for its CRDs, as well as code for its controllers and webhooks. Code generation scripts are found in the hack folder. These scripts write generated code to pkg/client. The Knative docs on dependency injection describe the contracts of the functions that must be implemented for generated reconcilers and webhooks, as well as the concept of "informers", which notify the reconcilers about other objects in the cluster.
Please read "Generated reconciler responsibilities" from the Knative documentation before reading this section.
The TaskRun controller handles any events related to TaskRuns, and any events related to a pod owned by a TaskRun.
When one of these events occurs, the TaskRun name is added to the reconciler working queue. When an event (a TaskRun) is popped off the queue, the reconciler runs a reconcile loop with that TaskRun. It does not know what event occurred; it simply brings the cluster state in line with the TaskRun spec, and updates the TaskRun status to reflect what happened.
When a TaskRun is created, the reconciler sees that the TaskRun has not run yet, and has no pod associated with it. It creates a pod to run the TaskRun and exits the reconcile loop.
Later, the pod completes, resulting in another event that triggers reconciliation of the TaskRun that owns it. The reconciler sees that the TaskRun has a pod associated with it, and that the pod has completed. It updates the TaskRun status to mark it as completed and exits the reconcile loop.