Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
KEP: [sig-cluster-lifecycle] addons via operators #746
mattfarina left a comment
The writeup here appears to be more like a scope or work rather than a targeted enhancement. For example, the goals state:
Could this be phrased more around the enhancement direction rather than the scope of the group?
@timothysc: GitHub didn't allow me to request PR reviews from the following users: justinsb.
Note that only kubernetes members and repo collaborators can review this PR, and authors cannot review their own PRs.
Some high-level background. (I haven't read the KEP yet.)
Add-on management is a long-standing issue:
It has been exacerbated by 2 developments:
If we want Kubernetes releases to continue to be usable OOB, we at least need a reference implementation to run DNS, for instance.
I think the Operator approach is interesting because we do want Operators to run reliably and to be reconfigurable.
We do need to be careful about how/where the APIs are used. I'd expect managed services to not necessarily expose add-on management, for instance. And some essential functionality, notably DNS, has multiple implementations in use, so we may want to think about implementation-independent APIs for configuring commonly customized user-visible behaviors.
cc @thockin, since he's been interested in the distro vs. kernel question
Also maybe related to CRD installation: https://docs.google.com/document/d/1Mck33AAj7HxrPj7P3sw5IWvHhLML9n--7ZpWPL8P9AA/edit?ts=5c8abadb#heading=h.ho3rd7gieldu
@jwforres for some reason I can't reply to some of your comments inline.
For allowing patching, yes it's clear this is the "break glass" option and carries an element of "use at your own risk". The reason for it is that we don't want CRDs that redefine every field in the manifest, lest we end up defining a meta-language in the CRD. The hope is that supporting something like patching allows the CRD to be smaller and still cover the vast majority of users, with the remaining users able to use patching and not be blocked. But also it's much more realistic to support a relatively small surface area API. A large surface area API over an addon with breaking changes will also have breaking changes.
For flags specifically, you're absolutely right that they are brittle - and there's complementary work to establish componentconfig as the recommended approach instead (the component work being done by @luxas @mtaufen @sttts et al)
For the one repo vs multiple repos question, if there are projects that want to adopt the patterns right away, that's great. I was suspecting that we would have to build a few in a single repo, before persuading the projects to move the code into their repo/repos. But I could be wrong, and I welcome the optimism :-)
luxas left a comment
As discussed and approved in today's SIG Cluster Lifecycle meeting, we're merging this KEP as provisional now, and will follow up in the new cluster-addons subproject of SIG Cluster Lifecycle that was formed to discuss and own the direction of this KEP.
The repo has been set up: https://github.com/kubernetes-sigs/addon-operators
[APPROVALNOTIFIER] This PR is APPROVED
The full list of commands accepted by this bot can be found here.
The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing