-
Notifications
You must be signed in to change notification settings - Fork 222
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[TEP-0128] Multiple Tekton instances per Cluster
TEP proposal about running multiple instances of Tekton Pipeline in a single Tekton cluster. Signed-off-by: Andrea Frittoli <[email protected]>
- Loading branch information
Showing
2 changed files
with
310 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,309 @@ | ||
| --- | ||
| status: proposed | ||
| title: Multiple Tekton instances per cluster | ||
| creation-date: '2023-01-11' | ||
| last-updated: '2023-01-11' | ||
| authors: | ||
| - '@afrittoli' | ||
| collaborators: [] | ||
| --- | ||
|
|
||
| # TEP-0128: Multiple Tekton instances per cluster | ||
|
|
||
| <!-- toc --> | ||
| - [Summary](#summary) | ||
| - [Motivation](#motivation) | ||
| - [Goals](#goals) | ||
| - [Non-Goals](#non-goals) | ||
| - [Use Cases](#use-cases) | ||
| - [Requirements](#requirements) | ||
| - [Proposal](#proposal) | ||
| - [Notes and Caveats](#notes-and-caveats) | ||
| - [Design Details](#design-details) | ||
| - [Design Evaluation](#design-evaluation) | ||
| - [Reusability](#reusability) | ||
| - [Simplicity](#simplicity) | ||
| - [Flexibility](#flexibility) | ||
| - [User Experience](#user-experience) | ||
| - [Performance](#performance) | ||
| - [Risks and Mitigations](#risks-and-mitigations) | ||
| - [Drawbacks](#drawbacks) | ||
| - [Alternatives](#alternatives) | ||
| - [Implementation Plan](#implementation-plan) | ||
| - [Test Plan](#test-plan) | ||
| - [Infrastructure Needed](#infrastructure-needed) | ||
| - [Upgrade and Migration Strategy](#upgrade-and-migration-strategy) | ||
| - [Implementation Pull Requests](#implementation-pull-requests) | ||
| - [References](#references) | ||
| <!-- /toc --> | ||
|
|
||
| ## Summary | ||
|
|
||
| With the growth of [Tekton adoption][tekton-adoption], Tekton is now used as | ||
| a foundation technology for several open source tools as well as commercial | ||
| offerings. | ||
|
|
||
| Users may want to adopt different tools that rely on Tekton and run them in | ||
| the same kubernetes clusters. Since tools may not be aligned in the version | ||
| and configuration of Tekton they depend on, the main roadblock today is the | ||
| ability to run multiple different instances of Tekton in a single kubernetes | ||
| cluster. | ||
|
|
||
| ## Motivation | ||
|
|
||
| The Tekton controller provides some functionality towards the ability of | ||
| running multiple instances in a single cluster, namely the ability to | ||
| configure the Tekton controller to watch a single namespace for resources | ||
| to be reconciled. This functionality is not properly documented and it does | ||
| not include other Tekton controllers, such as the various controllers | ||
| bundled in the Tekton webhook as well the remote resolution controller. | ||
|
|
||
| ### Goals | ||
|
|
||
| - Allow multiple instances of Tekton Pipeline to run in single kubernetes | ||
| cluster, each responsible for a Tekton resources in a dedicated namespaces. Each | ||
| instance performs validation, resolution and execution and is configured | ||
| independently from the others. | ||
| - Allow multiple version of Tekton Pipeline to run in a single kubernetes cluster, | ||
| as long as there are no backward incompatible changes between the older and newer | ||
| versions. | ||
| - Identify and configure cluster level resources in Tekton Pipelines, such as CRDs, | ||
| cluster roles and bindings and the conversion webhook, so that they can safely | ||
| shared across multiple Tekton instances. | ||
|
|
||
| ### Non-Goals | ||
|
|
||
| - Support multiple instances of Tekton Triggers | ||
| - Changes to the Tekton cli, dashboard, operator, results, chains, triggers to | ||
| support multiple instances / versions of Tekton pipeline. While some of these | ||
| may be desirable, they are not in scope for this TEP. | ||
|
|
||
| ### Use Cases | ||
|
|
||
| - Run multiple tools that depend on Tekton in the same clusters. Different | ||
| tools may require different configurations and versions of Tekton | ||
| - Run multiple instance of Tekton for development and testing purposes | ||
|
|
||
| ### Requirements | ||
|
|
||
| - Each instance of Tekton is responsible (validation, resolution, execution) | ||
| for resources in a dedicated namespace | ||
| - Each instance of Tekton is configured independently, which includes observability | ||
| targets | ||
| - Each instance of Tekton does not have access to resources in namespaces it's | ||
| not responsible for | ||
|
|
||
| ## Proposal | ||
|
|
||
| <!-- | ||
| This is where we get down to the specifics of what the proposal actually is. | ||
| This should have enough detail that reviewers can understand exactly what | ||
| you're proposing, but should not include things like API designs or | ||
| implementation. The "Design Details" section below is for the real | ||
| nitty-gritty. | ||
| --> | ||
|
|
||
| ### Notes and Caveats | ||
|
|
||
| <!-- | ||
| (optional) | ||
| Go in to as much detail as necessary here. | ||
| - What are the caveats to the proposal? | ||
| - What are some important details that didn't come across above? | ||
| - What are the core concepts and how do they relate? | ||
| --> | ||
|
|
||
|
|
||
| ## Design Details | ||
|
|
||
| <!-- | ||
| This section should contain enough information that the specifics of your | ||
| change are understandable. This may include API specs (though not always | ||
| required) or even code snippets. If there's any ambiguity about HOW your | ||
| proposal will be implemented, this is the place to discuss them. | ||
| If it's helpful to include workflow diagrams or any other related images, | ||
| add them under "/teps/images/". It's upto the TEP author to choose the name | ||
| of the file, but general guidance is to include at least TEP number in the | ||
| file name, for example, "/teps/images/NNNN-workflow.jpg". | ||
| --> | ||
|
|
||
|
|
||
| ## Design Evaluation | ||
| <!-- | ||
| How does this proposal affect the api conventions, reusability, simplicity, flexibility | ||
| and conformance of Tekton, as described in [design principles](https://github.com/tektoncd/community/blob/master/design-principles.md) | ||
| --> | ||
|
|
||
| ### Reusability | ||
|
|
||
| <!-- | ||
| https://github.com/tektoncd/community/blob/main/design-principles.md#reusability | ||
| - Are there existing features related to the proposed features? Were the existing features reused? | ||
| - Is the problem being solved an authoring-time or runtime-concern? Is the proposed feature at the appropriate level | ||
| authoring or runtime? | ||
| --> | ||
|
|
||
| ### Simplicity | ||
|
|
||
| <!-- | ||
| https://github.com/tektoncd/community/blob/main/design-principles.md#simplicity | ||
| - How does this proposal affect the user experience? | ||
| - What’s the current user experience without the feature and how challenging is it? | ||
| - What will be the user experience with the feature? How would it have changed? | ||
| - Does this proposal contain the bare minimum change needed to solve for the use cases? | ||
| - Are there any implicit behaviors in the proposal? Would users expect these implicit behaviors or would they be | ||
| surprising? Are there security implications for these implicit behaviors? | ||
| --> | ||
|
|
||
| ### Flexibility | ||
|
|
||
| <!-- | ||
| https://github.com/tektoncd/community/blob/main/design-principles.md#flexibility | ||
| - Are there dependencies that need to be pulled in for this proposal to work? What support or maintenance would be | ||
| required for these dependencies? | ||
| - Are we coupling two or more Tekton projects in this proposal (e.g. coupling Pipelines to Chains)? | ||
| - Are we coupling Tekton and other projects (e.g. Knative, Sigstore) in this proposal? | ||
| - What is the impact of the coupling to operators e.g. maintenance & end-to-end testing? | ||
| - Are there opinionated choices being made in this proposal? If so, are they necessary and can users extend it with | ||
| their own choices? | ||
| --> | ||
|
|
||
| ### Conformance | ||
|
|
||
| <!-- | ||
| https://github.com/tektoncd/community/blob/main/design-principles.md#conformance | ||
| - Does this proposal require the user to understand how the Tekton API is implemented? | ||
| - Does this proposal introduce additional Kubernetes concepts into the API? If so, is this necessary? | ||
| - If the API is changing as a result of this proposal, what updates are needed to the | ||
| [API spec](https://github.com/tektoncd/pipeline/blob/main/docs/api-spec.md)? | ||
| --> | ||
|
|
||
| ### User Experience | ||
|
|
||
| <!-- | ||
| (optional) | ||
| Consideration about the user experience. Depending on the area of change, | ||
| users may be Task and Pipeline editors, they may trigger TaskRuns and | ||
| PipelineRuns or they may be responsible for monitoring the execution of runs, | ||
| via CLI, dashboard or a monitoring system. | ||
| Consider including folks that also work on CLI and dashboard. | ||
| --> | ||
|
|
||
| ### Performance | ||
|
|
||
| <!-- | ||
| (optional) | ||
| Consider which use cases are impacted by this change and what are their | ||
| performance requirements. | ||
| - What impact does this change have on the start-up time and execution time | ||
| of TaskRuns and PipelineRuns? | ||
| - What impact does it have on the resource footprint of Tekton controllers | ||
| as well as TaskRuns and PipelineRuns? | ||
| --> | ||
|
|
||
| ### Risks and Mitigations | ||
|
|
||
| <!-- | ||
| What are the risks of this proposal and how do we mitigate? Think broadly. | ||
| For example, consider both security and how this will impact the larger | ||
| Tekton ecosystem. Consider including folks that also work outside the WGs | ||
| or subproject. | ||
| - How will security be reviewed and by whom? | ||
| - How will UX be reviewed and by whom? | ||
| --> | ||
|
|
||
| Custom Resource Definitions are cluster scoped resources, which means that | ||
| some parts of Tekton must be shared across multiple instances of Tekton. | ||
| Constraints on the version of Tekton can be used to reduce the risk introduced | ||
| by this. Adoption of "v1" will help here, since no backward compatible changes | ||
| are allowed in the CRD definitions at all. | ||
|
|
||
| ### Drawbacks | ||
|
|
||
| <!-- | ||
| Why should this TEP _not_ be implemented? | ||
| --> | ||
|
|
||
| ## Alternatives | ||
|
|
||
| <!-- | ||
| What other approaches did you consider and why did you rule them out? These do | ||
| not need to be as detailed as the proposal, but should include enough | ||
| information to express the idea and why it was not acceptable. | ||
| --> | ||
|
|
||
|
|
||
| ## Implementation Plan | ||
|
|
||
| <!-- | ||
| What are the implementation phases or milestones? Taking an incremental approach | ||
| makes it easier to review and merge the implementation pull request. | ||
| --> | ||
|
|
||
|
|
||
| ### Test Plan | ||
|
|
||
| <!-- | ||
| Consider the following in developing a test plan for this enhancement: | ||
| - Will there be e2e and integration tests, in addition to unit tests? | ||
| - How will it be tested in isolation vs with other components? | ||
| No need to outline all the test cases, just the general strategy. Anything | ||
| that would count as tricky in the implementation and anything particularly | ||
| challenging to test should be called out. | ||
| All code is expected to have adequate tests (eventually with coverage | ||
| expectations). | ||
| --> | ||
|
|
||
| ### Infrastructure Needed | ||
|
|
||
| <!-- | ||
| (optional) | ||
| Use this section if you need things from the project or working group. | ||
| Examples include a new subproject, repos requested, GitHub details. | ||
| Listing these here allows a working group to get the process for these | ||
| resources started right away. | ||
| --> | ||
|
|
||
| ### Upgrade and Migration Strategy | ||
|
|
||
| <!-- | ||
| (optional) | ||
| Use this section to detail whether this feature needs an upgrade or | ||
| migration strategy. This is especially useful when we modify a | ||
| behavior or add a feature that may replace and deprecate a current one. | ||
| --> | ||
|
|
||
| ### Implementation Pull Requests | ||
|
|
||
| <!-- | ||
| Once the TEP is ready to be marked as implemented, list down all the GitHub | ||
| merged pull requests. | ||
| Note: This section is exclusively for merged pull requests for this TEP. | ||
| It will be a quick reference for those looking for implementation of this TEP. | ||
| --> | ||
|
|
||
| ## References | ||
|
|
||
| <!-- | ||
| (optional) | ||
| Use this section to add links to GitHub issues, other TEPs, design docs in Tekton | ||
| shared drive, examples, etc. This is useful to refer back to any other related links | ||
| to get more details. | ||
| --> | ||
|
|
||
| [tekton-adoption]: https://github.com/tektoncd/community/blob/main/adopters.md |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters