|
| 1 | +# HA support for Tekton Pipeline controllers |
| 2 | + |
| 3 | +- [Overview](#overview) |
| 4 | +- [Configuring HA](#configuring-ha) |
| 5 | + - [Configuring the controller replicas](#configuring-the-controller-replicas) |
| 6 | + - [Configuring the leader election](#configuring-the-leader-election) |
| 7 | +- [Disabling leader election](#disabling-leader-election) |
| 8 | + - [Use the disable-ha flag](#use-the-disable-ha-flag) |
| 9 | + - [Scale down your replicas](#scale-down-your-replicas) |
| 10 | + |
| 11 | +## Overview |
| 12 | + |
| 13 | +--- |
| 14 | +This document is aimed at helping maintainers/developers when configuring High Availability(HA) support for the Tekton Pipeline [controller deployment](../../config/controller.yaml). |
| 15 | + |
| 16 | +HA support allows components to remain operational when a disruption occurs. This is achieved by following an active/active model, where all replicas of the Tekton controller can receive workload. In this HA approach the reconcile space is distributed across buckets, where each replica owns a subset of those buckets and can process the load if the given replica is the leader of that bucket. |
| 17 | + |
| 18 | +By default HA is enabled in the Tekton pipelines controller. |
| 19 | + |
| 20 | +## Configuring HA |
| 21 | + |
| 22 | +--- |
| 23 | +In order to achieve HA, the number of replicas for the Tekton Pipeline controller should be greater than one. This allows other instance(_s_) to take over in case of any disruption on the current active controller. |
| 24 | + |
| 25 | +### Configuring the controller replicas |
| 26 | + |
| 27 | +You can modify the replicas number in the [controller deployment](../../config/controller.yaml) under `spec.replicas` or apply an update to a running deployment: |
| 28 | + |
| 29 | +```sh |
| 30 | +kubectl -n tekton-pipelines scale deployment tekton-pipelines-controller --replicas=3 |
| 31 | +``` |
| 32 | + |
| 33 | +### Configuring the Leader Election |
| 34 | + |
| 35 | +The leader election can be configured via the [config-leader-election.yaml](../../config/config-leader-election.yaml). The configmap defines the following parameters: |
| 36 | + |
| 37 | +| Parameter | Default | |
| 38 | +| -------------------- | -------- | |
| 39 | +| `data.resourceLock` | "leases" | |
| 40 | +| `data.leaseDuration` | 15s | |
| 41 | +| `data.renewDeadline` | 10s | |
| 42 | +| `data.retryPeriod` | 2s | |
| 43 | + |
| 44 | +## Disabling leader election |
| 45 | + |
| 46 | +--- |
| 47 | + |
| 48 | +If HA is not required and running a single instance of the Tekton Pipeline controller is enough, there are two alternatives: |
| 49 | + |
| 50 | +### Use the disable-ha flag |
| 51 | + |
| 52 | +You can modify the [controller deployment](../../config/controller.yaml), by specifying in the `tekton-pipelines-controller` container the `disable-ha` flag. For example: |
| 53 | + |
| 54 | +```yaml |
| 55 | +spec: |
| 56 | + serviceAccountName: tekton-pipelines-controller |
| 57 | + containers: |
| 58 | + - name: tekton-pipelines-controller |
| 59 | + ... |
| 60 | + args: [ |
| 61 | + # Other flags defined here... |
| 62 | + "-disable-ha=true" |
| 63 | + ] |
| 64 | +``` |
| 65 | + |
| 66 | +by setting `disable-ha` to `true`, HA will be disable in the controllers. |
| 67 | + |
| 68 | +**Note**: Please consider that when disabling HA and keeping multiple replicas of the [controller deployment](../../config/controller.yaml), each replica will act as an independent controller, leading to an unwanted behaviour when creating resources(e.g. `TaskRuns`, etc). |
| 69 | + |
| 70 | +### Scale down your replicas |
| 71 | + |
| 72 | +Although HA is enable by default, if your [controller deployment](../../config/controller.yaml) replicas are set to one, there would be no High Availability in the scenario where the running instance is deleted or fails. Therefore having a single replica even with HA enable, does not ensure high availability for the controller. |
0 commit comments