Exposing Kubernetes objects in the UI

[mairin]

👋🏻 Hello again :)

A few weeks ago, some of the Podman Desktop contributors participated in a hack week where we worked on fun / experimental ideas. One of the ideas that I worked on with @cdrage was thinking through how we might expose Kubernetes objects in the Podman Desktop UI. We currently support Kubernetes environments through the kind, OpenShift Local, and DeveloperSandbox extensions, but we don't really expose some of the Kubernetes objects in those environments, such as applications and deployments.

This is not really a complete design by any means, but a bit of brain food to start thinking about where such objects might live in the Podman Desktop UI and what bits we might expose and how.

We would love to know what you think about this idea:

• Would you find it useful to be able to view Kubernetes objects for the K8s environments we support in Podman Desktop today?
• Which types of objects do you find the most useful to know more about?
• What kinds of workflows would you use this kind of information for?

It's also totally okay if you think this mockup is not the right approach, of course, but please share what you would like to see instead! 👍🏻

[deboer-tim]

+1, I think this is well laid out and useful. I've said most of this in other contexts, but here are my initial thoughts:

• Having a simplified/task-oriented/user view is definitely the way to go. IMHO this doesn't avoid the fact that we'll need some detailed/object views as well for when you 'just need to see the full list of X', but we don't want another Kube admin UI.

• The one drawback of this view is that I can see Pods at the 'top level', but if I want to see the Applications or Deployments on a Kubernetes environment it's one or two levels deeper. If necessary we could always move one of those to the sidebar or reorganize, we just need to be careful that this doesn't make the Kube environments feel second-class.

• It's only partially related, but having kind and OpenShift Local here draws me back to question how we should do 'environments'. e.g. Pods view has everything merged and uses labels, but here we have separate tiles. Does anyone really need to see all pods in a single list, or should we do the same there and instead of labels keep them separate with a header between each engine? Maybe have a quick filter on the status bar where you can toggle on and off display of environments, and if there's a Kube environment visible show more items in left nav?

[mairin]

I actually really love your ideas in the last point and looking forward to mocking them up & seeing how it would work!

[cdrage]

• I agree with @deboer-tim with regards to having this simplified / application oriented. That's what is missing with a lot of Kubernetes UI's, is the automatic grouping of related information (such as the Stardew example) where all of the information is right there where you wanted in a convenient location. We will however have to implement a more advance / generic view of "view all deployments" or "view all pods". Why? It's because sometimes deployments miss labels / correct names, or it's stuck in a half-terminating state, or you deploy a Helm chart that's not been configured correctly.
• IMO Pods should be shown top-level too above Deployments / near it so we can see what containers are running at the moment. Pods will always be associated with another Kind. Some of them will be using Deployment, others StatefulSet, DaemonSet, etc. It's important to show the Pods as we want to see how many restarts there are, errors, any warnings, etc.
• I do agree with @deboer-tim with regards to grouping into environments. The way that the UI shows it makes it feel like it's a troubleshooting / summary page rather than a more interactive / detailed page. By ungrouping the objects and instead labeling them similar to how we do it now with Pods / Containers / etc, makes it seem more interactive and rather than a settings page. Gives the user the assumption that "Oh, if I click on Deployments here, it'll show me the bigger view!". I think we should "group" them still similar to how we do it with compose / pod groups within Containers. If that makes sense? EDIT: Or just remove the "side" / gray section where it shows Kind / "some details go here" and instead put it at the top of the group?

[mairin]

@cdrage To your last point after the edit... when we were reviewing the mockups for Docker Compatibility support, one idea (I think it was either yours or Tim's) was to use the vertical color bars like this purple podman vertical bar to demarcate the clusters across the rows:

Maybe those side/gray sections with the cluster info could minimize into a slim bar like that and expanded into a wider bar with the info shown in the k8s mockup in OP? (For the mechanics, think of those annoying little show/hide palettes on the right side in Google Slides or something like that.)

[afbjorklund]

Another problem to solve is being able to view containers and images, from the Kubernetes cluster (using e.g. crictl).

• Kubernetes: containers from pods are not showing up #2800

• Kind: Indicates images loaded into Kind in Images page #1450

Maybe not so much for the interface design, as they would sort in with the others - but with a different "label" / badge

[mairin]

This is a good idea. I think it wculd make sense to have a label / badge per cluster in say the full image list, and if you click on the cluster label it filters to only images on that cluster. We could then have a button in the cluster details "view images in this cluster" or whatever and it would go to that label under the main nav > Images.

[afbjorklund]

Not sure what the end game is, but the most obvious implementation would be to show each container engine separately. That is, to show each node in the cluster, rather than aggregated view. Not sure when you ever want to do this, as an application developer?
When you are running a single-node cluster inside of a container, it could be interesting to view the second engine as well. But when showing a whole kubernetes cluster, I think you would rather have such things in the "details" of each node? And not one list, for all of them.

[afbjorklund]

Currently there is no way for PD to talk to containerd, not as a container engine and not as a container runtime (for k8s)

[afbjorklund]

Which types of objects do you find the most useful to know more about?

I think Nodes are missing from the overview, even if it is usually only one.

[cdrage]

You're right. Nodes should be shown too. Most users will be only using one node (kind, minishift, crc, minikube, etc.), but we should have the option to show multiple nodes.

[afbjorklund]

Even if you have one node, it has some details that could be of interest. Like the os image or the container runtime. The node resources are off though, if using kind - since all the nodes are sharing the same VM, and over-allocate resources.

[sftim]

I'm not sure if this is showing things cluster wide or giving a namespaced view. I think the difference matters.

• I'd like to see a tab for policies. That's where things like NetworkPolicy, ValidatingAdmissionPolicy, LimitRange etc can show up. Initially it could be a small list with a UI that hints there might one day be more.

• Another tab for configuration (ConfigMaps and Secrets)

If there is a cluster view and a namespace view, the namespace view should also show things that are cluster scoped but still relevant. For example, a cluster-scoped ValidatingAdmissionPolicy.

[mairin]

Here's some of the changes / additions to the design & areas for further research that I'm gathering from all this awesome feedback (thank you everybody :) ):

Research

• Would be good to develop a list of the most 10 (or however many) common workflows and test out the visual hierarchy to make sure the most common workflows are served well by default without too much drilling down.

Design

• Explore a label-oriented way of navigating from a list of pods (or whatever) back to the application oriented view.
• Explore how to better integrate kube environments so they don't feel "second class;" could be a matter of rethinking navigation.
• I love this suggestion wholesale and want to wireframe it out: "Does anyone really need to see all pods in a single list, or should we do the same there and instead of labels keep them separate with a header between each engine? Maybe have a quick filter on the status bar where you can toggle on and off display of environments, and if there's a Kube environment visible show more items in left nav?"
• Wireframe generic / ungrouped views to support when "deployments miss labels / correct names, or it's stuck in a half-terminating state, or you deploy a Helm chart that's not been configured correctly."
• Add "Pods" as a top level in the tabset per cluster; data should include "how many restarts there are, errors, any warnings, etc."
• Add "Nodes" as an item in the list (per cluster?); understanding in most cases there will only be one. (Exposing Kubernetes objects in the UI #3297 (comment)) One node will have details such as os image and container runtime.
• Add "Configuration" as a top level in the tabset per cluster (ConfigMaps and Secrets)
• Add "Policies" as a top level in the tabset per cluster. (NetworkPolicy, ValidatingAdmissionPolicy, LimitRange etc)
• Work through how to provide a namespace vs a cluster view (Wireframes needed)
• Account for how the user can see what images are loaded into a given cluster. And conversely, account for how the user can tell which cluster (or other environment / context / etc.) an image is in in the full images list. (Kind: Indicates images loaded into Kind in Images page #1450)
• Display containers and their images per pod (Kubernetes: containers from pods are not showing up #2800)

[mairin]

BTW the issue I'm going to use to track progress on this design is here:
#3297

[mairin]

Here's some design sketch ideas for this feature:

1. Filter idea for Pods list screen

This is an idea for allowing integration of K8s pods in the standard Podman Desktop pods list screen.

Some discussion points around this idea that came up in the weekly UX call we do:

• Right now we support one kubecontext at a time being active. Can this list support turning on more than one kubecontext listed in kubeconfig at the same time? Yes - (but maybe only the active has updated info? The inactive ones might be cached?) We should highlight which pods are from the active kubecontext vs which are from the inactive kubecontext.
• List namespace (and/or project) for pods in a namespace?
• We might end up with dupes of kind environments. But there is enough metadata in the kubeconfig that we can figure this out and de-duplicate the listings. (Florent's idea was to key off of the admin URL listed in the config.)
• [IDEA] Tim suggested designing a dialog to allow users to view and clean up their kubeconfig
• Mo brought up that we could have one filter dropdown for container engines and a separate one for kubernetes / container orchestrators. Consensus was that having one drop down for all sources was better and would provide the best experience.
• What is the scope of this filter dropdown? Mo's intention is that it is global - it could appear on multiple screens (pods, containers, applications, images(?)) and would have a shared single state across all. So if you turn kind on in the pods screens, that will be sticky for when you visit the containers screen. However, placing in the header of the screen isntead of on the global status bar. If we note users have confusion with the header placement, we can always move down to the status bar later.... Mo feels it's important to be in the header and to try that since it is closer to the action / placed besides other controls in that same shared context of filtering the ist.
• Jef suggested showing namespaces per cluster in the pods list. This will help scale.

2. Pod list row design idea

This is a sketch of the pods list, showing a single pod - penpot - with 4 containers in it.

Some discussion points around this idea that came up in the weekly UX call:

• A general idea of popup cards for details, e.g. this bit in the mockup:
  
  • Can we make little pop up card designs for different elements to keep the screen lean & clean but allow for less efort to dive into the details on demand? (e.g. for the environment, for the application, for the image, etc. the little lozenge-shaped buts in the table)
• The pod has a little /!\ emblem icon / overlay in the mockup but it isn´ t needed as we have a "degraded" status icon that would be used instead (to indicate 1 or more containers in the pod is in a bad state)
• would be nice to have a slim iconified view of the containers and their status without having to open up expander
• can we display routes / services here?

3. Application list

This is a sketch of a new propose screen - an application list - showing two apps, one is penpot and it has 3 pods in 2 different environemnts, the other is an app called python-demo and it is present as a pod in one environment.

Some discussions points around this idea that came up in the weekly UX call:

• What is the sort order of the application list? Mo's thought is that we display applications that are running on the top, sorted A-Z. After the block of running apps we display the apps that have no running pods, sorted A-Z.
• Versioning for apps - each pod connected to an app might be running a different version. is there a label for the application that has a version #
• It would be nice to have controls to create apps and label them properly since that metadata might not be super reliable.

Ok, that's the full set of notes and sketches from last week. Going to try to do this on a weekly cadence :)