KEP-5008: Introduce Kubernetes Desktop #5009
Conversation
joaquimrocha
commented
Dec 19, 2024
joaquimrocha
commented
- One-line PR description: Adding new KEP 5008 for introducing a Kubernetes Desktop project
- Issue link: Introduce Kubernetes Desktop #5008
- Other comments:
Signed-off-by: Joaquim Rocha <[email protected]>
k8s-ci-robot
added
the
kind/kep
k8s-ci-robot
added
the
cncf-cla: yes
|
Welcome @joaquimrocha! |
k8s-ci-robot
added
the
needs-ok-to-test
|
Hi @joaquimrocha. Thanks for your PR. I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
k8s-ci-robot
added
the
size/XL
joaquimrocha
force-pushed
the
kep-5008
branch
from
d1740ee to
afba2eb
Compare
| Effectively this entails moving the Headlamp project under the Kubernetes | ||
| GitHub organization and under the auspices of Kubernetes SIG UI. To be | ||
| specific, we would propose that the Headlamp project be moved to a repo under | ||
| the Kubernetes project; something to the effect of kubernetes/ui. |
There was a problem hiding this comment.
Alternative: we could still call it Headlamp.
There was a problem hiding this comment.
As we are proposing to bring the project under the Kubernetes umbrella, our thinking is that having a separate branding (Headlamp) could be confusing for users and developers.
There was a problem hiding this comment.
- We could list "Kubernetes Headlamp" as an alternative to "Kubernetes Desktop".
- We need a name for the bits of Headlamp that are not Kubernetes Desktop
- We have a precedent for components of Kubernetes that have their own name; for example: etcd.
There was a problem hiding this comment.
The build/app we are proposing should be called Kubernetes Desktop. You are right that there are non-desktop bits, but that should be encompassed in having kubernetes/ui as a technical/repo name as proposed.
There was a problem hiding this comment.
I'm wary of calling it "UI".
Imagine using it in conversation; "Well, I've worked on a few cloud native things; I wrote tests for kube-apiserver, I improve the CRI support in containerd, and I wrote the style guide for UI". Even if you said "Kubernetes UI", people might not realise you mean Headlamp.
By rough analogy: we call it kubectl and not cli-client.
| ## Release Signoff Checklist | ||
|
|
||
| <!-- | ||
| **ACTION REQUIRED:** In order to merge code into a release, there must be an | ||
| issue in [kubernetes/enhancements] referencing this KEP and targeting a release | ||
| milestone **before the [Enhancement Freeze](https://git.k8s.io/sig-release/releases) | ||
| of the targeted release**. | ||
| For enhancements that make changes to code or processes/procedures in core | ||
| Kubernetes—i.e., [kubernetes/kubernetes], we require the following Release | ||
| Signoff checklist to be completed. | ||
| Check these off as they are completed for the Release Team to track. These | ||
| checklist items _must_ be updated for the enhancement to be released. | ||
| --> | ||
|
|
||
| Items marked with (R) are required *prior to targeting to a milestone / release*. | ||
|
|
||
| - [ ] (R) Enhancement issue in release milestone, which links to KEP dir in [kubernetes/enhancements] (not the initial KEP PR) | ||
| - [ ] (R) KEP approvers have approved the KEP status as `implementable` | ||
| - [ ] (R) Design details are appropriately documented | ||
| - [ ] (R) Test plan is in place, giving consideration to SIG Architecture and SIG Testing input (including test refactors) | ||
| - [ ] e2e Tests for all Beta API Operations (endpoints) | ||
| - [ ] (R) Ensure GA e2e tests meet requirements for [Conformance Tests](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/conformance-tests.md) | ||
| - [ ] (R) Minimum Two Week Window for GA e2e tests to prove flake free | ||
| - [ ] (R) Graduation criteria is in place | ||
| - [ ] (R) [all GA Endpoints](https://github.com/kubernetes/community/pull/1806) must be hit by [Conformance Tests](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/conformance-tests.md) | ||
| - [ ] (R) Production readiness review completed | ||
| - [ ] (R) Production readiness review approved | ||
| - [ ] "Implementation History" section is up-to-date for milestone | ||
| - [ ] User-facing documentation has been created in [kubernetes/website], for publication to [kubernetes.io] | ||
| - [ ] Supporting documentation—e.g., additional design documents, links to mailing list discussions/SIG meetings, relevant PRs/issues, release notes | ||
|
|
||
| <!-- | ||
| **Note:** This checklist is iterative and should be reviewed and updated every time this enhancement is being considered for a milestone. | ||
| --> | ||
|
|
||
| [kubernetes.io]: https://kubernetes.io/ | ||
| [kubernetes/enhancements]: https://git.k8s.io/enhancements | ||
| [kubernetes/kubernetes]: https://git.k8s.io/kubernetes | ||
| [kubernetes/website]: https://git.k8s.io/website |
There was a problem hiding this comment.
There's a way to handle KEPs not tied to a Kubernetes release; I think this one wouldn't be. Have I got that right?
There was a problem hiding this comment.
I agree. I wasn't sure if for the sake of the KEP formatting I had to keep this around. Should I remove it then?
| As a vendor I want to create a new Kubernetes user interface for my system. I | ||
| take Headlamp Base and build a set of plugins and take some of the existing | ||
| plugins to create my custom UI. I customize the UI with my company/product | ||
| branding and provide that to my users with or without them knowing it’s | ||
| Headlamp. If I desire, I can even allow my users to extend my customer UI using | ||
| the same way I did. |
There was a problem hiding this comment.
Can this be done right now with the existing Headlamp? If so, maybe we should mention that.
There was a problem hiding this comment.
Yes, this is possible right now (all user stories are possible ATM, except when indicated by notes, like the minikube plugin being a POC still). How can we indicate that we do support these more explicitly?
| <!-- | ||
| Detail the things that people will be able to do if this KEP is implemented. | ||
| Include as much detail as possible so that people can understand the "how" of | ||
| the system. The goal here is to make this feel real for users without getting | ||
| bogged down. | ||
| --> |
There was a problem hiding this comment.
A few ideas for more stories we could maybe want to support one day:
-
as an add-on vendor / author, I define a custom resource using a Headlamp plugin CRD. Now, when people deploy my add-on, they can automatically benefit from the plug-in for my addon.
-
I have made a specialised control plane based on projects similar to Kubernetes [I'm thinking KCP and Crossplane]. I use Headlamp against the specialised control plane to deploy a Kubernetes cluster, or to update it based on my desired state.
-
as an appliance vendor, I build an edge appliance that bundles Kubernetes as a way to manage components. I make a custom version of Headlamp and have it serve as the administrative console for the appliance. Customers using the appliance can install addons that integrate with the main admin console.
There was a problem hiding this comment.
Thanks. I think the 2nd and 3rd suggestions here are already covered by Story 4, in that a Headlamp plugin can be used for a variety of goals (like using a different control plane, or as an admin console for an appliance), besides the actual user interfaces associated with it. Should we write these suggestions as examples in this story, or do you think they are not covered by our stories we should have it more explicitly?
About the 1st suggestions, can you elaborate a bit? Are you saying a CRD has info on what specific Headlamp plugin that is associated with it? This could be a good idea actually: e.g. Headlamp checks CRDs for a specific spec that indicates what plugin is associated with it (if any) and suggest to the user that they may install it (if not yet installed).
There was a problem hiding this comment.
I'm imagining an addon manager that deploys lots of elements for an addon: the CRD, the operator / controller, the Headlamp plugin, and more.
There was a problem hiding this comment.
Maybe there is an API kind named HeadlampPlugin, a bit like the Prometheus operators has an API kind named ServiceMonitor.
There was a problem hiding this comment.
Being able to deploy a Headlamp plugin via an operator would be a nice (eventual) touch, I think.
| ### Existing Dashboard project | ||
|
|
||
| The Kubernetes project already has a Dashboard project. However, we think that | ||
| the Headlamp project has a number of advantages that make it a great solution | ||
| to build on going forward. Some of these are: | ||
| * Has a robust plugin system for customization and integrations | ||
| * Supports both desktop and in-cluster mode | ||
| * Is under very active development and has dedicated resources assigned to it | ||
| in addition to the active external contributors | ||
| * Is built on a very common technology stack (Typescript, React, Material UI, | ||
| Vite, Go) | ||
| * Has more advanced features (multi-cluster, graph view, powerful plugin | ||
| system, 3rd party plugins) | ||
| * Addresses many more use cases (see below) |
There was a problem hiding this comment.
If you would want to keep this, then I think that this should be a comparison. In its current form, it only describes the advantages over Kubernetes Dashboard and does not mention any differences and/or potential disadvantages/missing features.
It should also mention the difference in features. Some of them would be:
- Reverse auth proxy support
- Impersonation options through headers
- Lazy search with a time window where it can search through stale data
- Whole logic execution and load is shifted towards the user machine from the hosted backend instance
There is also a side effect of fully exposing a raw Kubernetes API server whenever Headlamp is hosted as a generally available web app via <headlamp_url>/clusters/<cluster_name>/<kubernetes API endpoint>. This is because the backend only acts as a proxy and WS multiplexer to the K8S API. It might be worth mentioning as some users might not be aware of that.
In addition to that I would also love to see a high-level architecture comparison. IMHO it is important for the potential users to know about frontend-as-backend architecture where backend is mostly for handling websocket connections and multiplexing. The advantages and disadvantages of such an architecture too.
Most of the mentioned points are fine. Technology stack is almost identical but it's still nice to have it written down.
There was a problem hiding this comment.
I agree. Showing only the advantages of Headlamp without mentioning any drawbacks sounds wrong to me. To make the comparison fair it should also explain trade-offs that come with Headlamp architecture as well.
| The proposal is to ship the Headlamp desktop experience as a new Kubernetes | ||
| Desktop and the Headlamp in-cluster UI to eventually become the next generation | ||
| of the Kubernetes Dashboard. |
There was a problem hiding this comment.
This somewhat contradicts the non-goal. I'd suggest changing it to: "The proposal is to ship the Headlamp desktop experience as a new Kubernetes Desktop and the Headlamp in-cluster UI" and focus on the onboarding of the new project only.
| The current repo kubernetes/dashboard would remain but include a note about the | ||
| existence of the other repo. This would allow for users to compare the projects | ||
| and make an informed decision about which works best for their use case. Over | ||
| time, we can measure adoption trends and make decisions based on that data. |
There was a problem hiding this comment.
As we already discussed, this will be a separate project under the same SIG. Neither one needs to mention the other projects directly in the project repo. It should be listed in: https://github.com/kubernetes/community/tree/master/sig-ui and also the official kubernetes docs.
| _**Note:** We have the minikube installer plugin in POC but the tutorial plugin | ||
| is not something we currently have._ |
There was a problem hiding this comment.
I'd only mention shipped features here and introduce a Roadmap section that will cover future work and planned features.
There was a problem hiding this comment.
I think the goal here is to highlight the possibility of having local clusters provisioned due to the plugin system supporting (desktop only) running local tools, which is something that we already support when enabled. The minikube part is an example of this, and we happen to be working on that, but it's not yet complete, so that's mentioned here too.
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: joaquimrocha The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Signed-off-by: Joaquim Rocha <[email protected]>
