Improve Knative Headlamp plugin: Serverless Workload Management UI - Linux Foundation paid mentorship project

[illume]

This issue is for a Linux Foundation mentorship project. A paid 12 week program. See https://mentorship.lfx.linuxfoundation.org/project/b6178852-f18d-41e2-b352-c839b8570eae There you can learn more and apply if interested. Please do not start this issue, as it is reserved for that project.

---

💥 Please do not ask if you can start this in this issue, see the link to apply. 💥

Please add example open source PRs to your cover letter (not necessarily headlamp plugin ones, but any that show your quality work and communication skills)

---

Knative is a Kubernetes-based platform for deploying and managing serverless workloads, providing automatic scaling (to zero), traffic splitting, and simplified app deployment. This project will continue development of a Headlamp plugin that brings first-class UI support for Knative (focusing on Knative Serving resources) directly into Headlamp’s dashboard. The plugin will allow Kubernetes operators and developers to visualize, inspect, and tweak Knative Services and their components (Services, Revisions, Configurations, Routes/traffic rules) without leaving the Headlamp UI. It builds on an initial Knative plugin. Our goal is to complete the remaining work and polish the experience. By doing so, we empower users to manage serverless applications (like deploying new revisions or adjusting traffic splits) more easily, complementing the kn CLI with an intuitive dashboard interface.

Expected Outcome

• Complete and fully functional Knative plugin integrated into the official Headlamp plugin repository, appearing as a new sidebar item “Knative”. The plugin should list Knative Services (KService) across namespaces, showing key info (name, URL, traffic percentage, latest revision status, etc.) in a table. The list columns will be adjusted to closely match what kubectl get kservice displays for familiarity.
• Detail pages for Knative Services that present both status and configuration: e.g., the service’s URL, current traffic split between revisions, concurrency and scaling settings, and condition statuses (Ready/Not Ready). Users should be able to perform common actions from the UI, such as adjusting traffic percents between revisions, updating configuration values (like environment variables or concurrency limits), and triggering a new revision (rolling out new image or configuration) via an “Update” or “Redeploy” action. These actions would be backed by form inputs or modals, and changes can be saved to the cluster with proper feedback.
• Where applicable, the plugin will surface or link related Knative resources: for example, showing a list of Revisions associated with each Service (and their status tags like “latest ready” or “latest created”), and linking to underlying Kubernetes objects (like an external HTTPRoute if Knative is configured with Kubernetes Gateway API, or Knative Route if using legacy ingress). This gives users a full picture of how each Knative Service is routed and its revision history. If feasible, a read-only view or separate list of Revisions and Configurations might be included for completeness (so advanced users can examine any revision’s details or YAML).
• Consistent Headlamp UX: The plugin’s UI will follow Headlamp conventions. For example, sections in the detail view that allow editing (traffic, config) will use a clear edit mode or modal dialog (rather than always-on form fields) to avoid confusion, and buttons or form sections will only be enabled if the user has proper RBAC permissions (leveraging Headlamp’s AuthVisible checks, similar to how the Karpenter plugin handles privileged actions). The overall look-and-feel (spacing, typography, icons) will match the native Headlamp style. We’ll also ensure multi-cluster support: if the user switches contexts, the Knative plugin should gracefully update to show Knative data for the current cluster (or indicate if Knative is not installed on that cluster).
• It should work with the Headlamp Map view, and integrate Knative metrics where appropriate.
• Robustness and polish: A number of known issues will be addressed. This includes fixing any navigation or routing bugs, eliminating console errors, and writing basic tests for critical components (e.g., rendering the Knative Service list, editing a traffic split form). The plugin will be packaged with appropriate metadata (icon, description, version) and released on ArtifactHub as an official Headlamp plugin.
• Documentation and outreach: The project will produce a README or user guide explaining how to install the plugin, prerequisites (Knative Serving must be installed on the cluster), and how to use its features (with screenshots for clarity).
• A blog post will be written (for the Headlamp blog or Kubernetes blog) announcing the Knative plugin and highlighting use cases – for example, “Managing Serverless Deployments via Headlamp: Introducing the Knative Plugin”. Including a short demo of adjusting traffic between two revisions through the UI.

---

Tasks and Proposed Enhancements

Note this is a rough list of remaining tasks.
TODO: note: the priorities are fairly random at this point.

Task/Enhancement	Priority
Align list columns with kubectl: Update Knative Service list view to include the same columns as kubectl get kservice (for example, Name, URL, Ready status, latest created/ready revision, age) for familiarity.	High 🔺
Refine edit UX in detail views: Change inline editable sections into a clearer UX flow (e.g., an “Edit” button that toggles fields, or opens a modal) so that the details page isn’t always in edit-mode. Use Headlamp’s AuthVisible or similar to hide or disable edit controls if the user lacks update permissions.	High 🔺
Implement Revision info display: Ensure users can see Revision details – e.g., a table or list of a Service’s revisions (with labels like “current” or “traffic %”) on the Service detail page, or a separate Revisions list view. This helps operators understand deployment history and quickly view past revisions.	High 🔺
Ensure multi-cluster & namespace support: Verify the plugin works across cluster contexts and respects namespace scopes. For example, in multi-cluster Headlamp, the Knative sidebar should appear for any cluster that has Knative CRDs, and within a cluster you can filter by namespace (using Headlamp’s namespace selector) to view services in that namespace.	High 🔺
Bug fixes & stability: Address any known bugs from the initial PR – e.g., fixing navigation issues, ensuring the plugin doesn’t crash if Knative CRDs are not present (perhaps show a friendly message like “Knative not detected on this cluster”), and removing any dev console warnings or errors. Add basic unit tests for critical components to catch regressions.	High 🔺
Icons and branding: Add an appropriate icon for the Knative sidebar entry (for example, use Knative’s “serving” icon or a generic serverless icon in monochrome style) instead of any placeholder. Use status icons or badges in the list (e.g., a green check for Ready) for quick scanning of health.	Medium 🔸
Additional Knative resources (stretch): Explore showing other Knative Serving resources like Configurations and Routes if they provide value. For instance, a Configuration is mostly an internal detail (each Service has one Configuration generating Revisions), but exposing it might help advanced debugging. Similarly, if using Knative Eventing, consider listing Eventing resources (Brokers, Triggers) in the future to broaden the plugin’s scope. These are optional and can be future enhancements once the core Serving UI is solid.	Medium 🔸
Traffic split enhancements: If not already in place, make the traffic editing UI more powerful – e.g., allowing users to split traffic between more than two revisions, or to assign a “tag” to a revision (Knative supports named routes). Also, validate inputs (ensuring traffic percentages total 100%).	Medium 🔸
Documentation & testing improvements: Write a comprehensive README for the plugin with screenshots. Also add integration tests (if possible) or end-to-end scenarios (perhaps via Cypress or Headlamp’s testing framework) to verify that a user can perform a full workflow (view service, edit something, see result) without issues.	Medium 🔸
Knative Eventing UI (future idea): Adding Knative Eventing support to the plugin. This could include listing event brokers, triggers, and sources, so that Headlamp covers the full Knative ecosystem.	Medium 🔸

Contact

• Headlamp Slack: #headlamp channel on Kubernetes slack
• Headlamp GitHub: https://github.com/kubernetes-sig/headlamp

Other open Headlamp LFX mentor projects

You only get max 3 applications, but maybe consider only applying to the 1-2 you are most interested in (and state your preference of the one you are most interested in your application). There are other projects to apply to as well.

• Improve Knative Headlamp plugin
• Add Kubeflow to Headlamp
• Improve Cluster API Headlamp plugin
• Add Strimzi to Headlamp
• Add Volcano to Headlamp

[kahirokunn]

Thank you so much @illume for creating this incredibly detailed and thoughtful issue! This is truly an excellent initiative that will significantly improve the Knative experience in Headlamp, and I'm very grateful for your leadership on this.

I wanted to share some clarifications about the current state of the implementation, as I believe some functionality that was included in the initial merged PR may have been overlooked due to the substantial volume of work that was delivered.

Regarding the traffic split enhancements you mentioned:

Traffic split enhancements: If not already in place, make the traffic editing UI more powerful – e.g., allowing users to split traffic between more than two revisions, or to assign a "tag" to a revision (Knative supports named routes). Also, validate inputs (ensuring traffic percentages total 100%).

I'm happy to share that this functionality is actually already implemented in the current version!

Regarding CRD detection:

CRDs are not present (perhaps show a friendly message like "Knative not detected on this cluster")

This feature has also been implemented! I believe it works well as long as it communicates clearly to users.

Regarding column alignment with kubectl:

Align list columns with kubectl: Update Knative Service list view to include the same columns as kubectl get kservice (for example, Name, URL, Ready status, latest created/ready revision, age) for familiarity.

I believe this has been completed in this commit:

b5284dc

Regarding edit UX refinements:

Refine edit UX in detail views: Change inline editable sections into a clearer UX flow (e.g., an "Edit" button that toggles fields, or opens a modal) so that the details page isn't always in edit-mode. Use Headlamp's AuthVisible or similar to hide or disable edit controls if the user lacks update permissions.

The functionality to hide or disable edit controls based on permissions has been implemented:
9c1e435

Given my professional background working extensively with React, I determined that a custom hook would provide better reusability than the AuthVisible component in this context, which led me to implement useKServicePermissions. However, I genuinely believe that such hooks would be more appropriately housed in the Headlamp core. Would it make sense to add a new task for moving this functionality there? I think proposing and integrating improvements that emerge from plugin development into the core would be a valuable learning experience for mentees as well.

That said, I completely agree that implementing explicit edit modes and further UX improvements would be incredibly valuable! 🙌

Regarding Revision information display:

Implement Revision info display: Ensure users can see Revision details – e.g., a table or list of a Service's revisions (with labels like "current" or "traffic %") on the Service detail page, or a separate Revisions list view. This helps operators understand deployment history and quickly view past revisions.

I wanted to provide some additional context here. The list of revisions is actually already displayed within the Traffic Splitting UI, so users can currently view the revision list:

However, at this point in time, the functionality is limited to viewing the list. There's currently no way to inspect the detailed configuration within each Revision, so there's absolutely significant work remaining, such as creating a dedicated Revision UI and integrating it properly.

I'm very excited to see this project progress and look forward to supporting the mentees as they work on these enhancements!