New applications view

[joaquimrocha]

Hey folks! When I meet users who don't know about Headlamp, a good portion of them always ask if Headlamp is cluster focused or app focused, or admin focused vs dev focused.
Seems like a number of users could therefore benefit from a view where we focus more on applications, deployments, projects, ... than the pure cluster views.

Some questions I'd like to start a discussion on:

• What constitutes an application unit in Kubernetes though? Is it a deployment? Maybe it's a namespace?
• What would a view of these applications be like? Maybe an item in the cluster sidebar showing only those "application units"? With options to see how their are doing in terms of health, an easy way to scale them, etc. Maybe this view could actually be in the top sidebar/home, so applications could be set as multi-cluster as well?

WDYT?

[jda258]

I think a namespace makes sense as an application boundary as there can be multiple deployments/daemonsets for a single application. Some popular examples:

• gatekeeper - two deployments
• falco - falco daemonset, falcosidekick deployment, falcosidekick-ui deployment
• external-secrets - three deployments
• flux - six deployments
• kube-prometheus-stack - three deployments, one daemonset

In the end, I could see where someone would consider those separate applications though. In addition, a user could choose to deploy multiple applications to a single namespace. This is not easy...

[jda258]

@joaquimrocha I had another idea. We can use the recommended labels from Kubernetes: https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/

I think the most promising one is app.kubernetes.io/instance. A cursory look at our clusters shows that both popular projects and our users are using this label. This is most likely due to the use of Helm where it is assigned the Helm release name.

[joaquimrocha]

Hey! We are finishing implementing this idea and initially we thought the configuration for this applications view (we're calling it Projects) should be local, but maybe it's useful to have it in a way that multiple users of the cluster can see the same projects.
Now, we thought that we either make it Namespace specific, so a project is one or more namespaces, and we identify this by having a special label in the namespace, like dev.headlamp.projects.name="my project", or we use a special Headlamp Custom Resource (or maybe a ConfigMap is more appropriate for this) for holding the configuration, like

headlamp.projects:
  name: My Project

However, using a Headlamp specific ConfigMap or CR would be a first for Headlamp, as till now we have managed to avoid integrating anything that is Headlamp specific in users' clusters.

Any opinions on what would be a most desirable approach?

[joaquimrocha]

I want to share some screenshots illustrating the current Projects area:

Projects home page

Project details

Project resource view

[LinPr]

I think applicaion concept in ArgoCD project is great, probably🤔