UX: Design new Kubernetes welcome page

[Firewall]

More information in the Epic: https://github.com/containers/podman-desktop/issues/8825

This is the UX task to design the new welcome page for Kubernetes.

[ekidneyrh]

I have a first draft of the Kubernetes welcome page - I followed the pattern Masha created for the InstructLab page (https://github.com/containers/podman-desktop-extension-ai-lab/issues/1802#issuecomment-2404931125).

For the 'Get up and running' section, I included cards that prompt the user to start using different parts of the sub menu. Once the action is complete the corresponding card disappears. The 'Set up' button leads to the page > apply YAML button, or it could just bring the user to the relevant page.

For the docs link, I think it would be worth adding a section on each menu item to the documentation so the user can get a guide to how it works and how to set up - I couldn't find anything on the documentation myself.

[ekidneyrh]

here it is with gray icons

[axel7083]

One of my concern is the Set up leads to page -> apply YAML. We currently do not have any dedicated page to apply resources, here is what is happening when you click on apply YAML in the Kubernetes section.

https://github.com/user-attachments/assets/14331fa3-7aa4-4dfa-a08e-6edc4eef3723

We have an issue related to the yaml copy paste https://github.com/containers/podman-desktop/issues/725, where we could have presets, let's say you click on Set up deployment a good user experience would be to open a dedicated page with prefilled yaml definition of a basic deployment (template) that the user can read, edit, before applying to the cluster.

OpensLens

As an example, in open lens they provide a template system when you want to apply resources, that you can select.

https://github.com/user-attachments/assets/9795e093-31ce-4904-a5a4-ded50fbabe29

Small remark

You cannot really apply a node resource, this is not like a pod or deployment, this is not user friendly operation.

[ekidneyrh]

Following last week's UX call I made changes to the mockup.

• Got rid of the get started cards and moved the information on them to the item page
• Make the ‘About Kubernetes’ header collapsible so users can opt to hide it in favor of focusing on the data cards.
• Data cards that visualize the information in the Kubernetes clusters. I’m not entirely sure what this will look like. I had a look at tools like grafana-dashboards-kubernetes and Headlamp and they are doing interesting stuff.
• ^ Pic from Grafana dashbord
• For the moment I included some cards that display information like the amount of nodes, deployments, services. I also have a graph for PVC usage (https://github.com/kais271/pvc-exporter) and a placeholder for another metric. What Grafana is doing is really cool and I wonder if anyone can tell me what we can do in terms of displaying information like this? It’s hard to know what I am designing for without knowing what can be done.

[cdrage]

Following last week's UX call I made changes to the mockup.

• Got rid of the get started cards and moved the information on them to the item page
• Make the ‘About Kubernetes’ header collapsible so users can opt to hide it in favor of focusing on the data cards.
• Data cards that visualize the information in the Kubernetes clusters. I’m not entirely sure what this will look like. I had a look at tools like grafana-dashboards-kubernetes and Headlamp and they are doing interesting stuff.
• ^ Pic from Grafana dashbord
• For the moment I included some cards that display information like the amount of nodes, deployments, services. I also have a graph for PVC usage (https://github.com/kais271/pvc-exporter) and a placeholder for another metric. What Grafana is doing is really cool and I wonder if anyone can tell me what we can do in terms of displaying information like this? It’s hard to know what I am designing for without knowing what can be done.

To answer your question about graphs, it would be a bit more difficult to implement as we will have to temporarily store the history information.

You can use the kubectl get --raw "/api/v1/nodes/k8s1/proxy/stats/summary" endpoint to get a summary of the node.

Available to use is CPU, memory, network and filesystem (and swap and rlimit).

However... Kubernetes does not store the history, so in our implementation we will have to store what the cpu / memory / filesystem / etc usage was if we want a graph based approach rather than "donut". We would also have to query every node which may cause issues with large-node-clusters (limit how many nodes are pinged?).

cc @feloy @deboer-tim

Below is the available information from one of my own nodes that we can extrapolate from:

  "startTime": "2024-10-16T17:38:12Z",
  "cpu": {
   "time": "2024-10-24T12:09:40Z",
   "usageNanoCores": 166214664,
   "usageCoreNanoSeconds": 104913802316000
  },
  "memory": {
   "time": "2024-10-24T12:09:40Z",
   "availableBytes": 13907468288,
   "usageBytes": 3436490752,
   "workingSetBytes": 2478735360,
   "rssBytes": 1492086784,
   "pageFaults": 350259878,
   "majorPageFaults": 10931
  },
  "network": {
   "time": "2024-10-24T12:09:40Z",
   "name": "",
   "interfaces": [
    {
     "name": "eno1",
     "rxBytes": 9039158666,
     "rxErrors": 0,
     "txBytes": 13045471486,
     "txErrors": 0
    },
    {
     "name": "tailscale0",
     "rxBytes": 653000,
     "rxErrors": 0,
     "txBytes": 3812,
     "txErrors": 0
    },
    {
     "name": "flannel.1",
     "rxBytes": 4965395537,
     "rxErrors": 0,
     "txBytes": 1897139951,
     "txErrors": 0
    },
    {
     "name": "cni0",
     "rxBytes": 5931837621,
     "rxErrors": 0,
     "txBytes": 9670259469,
     "txErrors": 0
    }
   ]
  },
  "fs": {
   "time": "2024-10-24T12:09:40Z",
   "availableBytes": 334328733696,
   "capacityBytes": 500807262208,
   "usedBytes": 140963688448,
   "inodesFree": 30204253,
   "inodes": 31129600,
   "inodesUsed": 925347
  },
  "runtime": {
   "imageFs": {
    "time": "2024-10-24T12:09:40Z",
    "availableBytes": 334328733696,
    "capacityBytes": 500807262208,
    "usedBytes": 87704821760,
    "inodesFree": 30204253,
    "inodes": 31129600,
    "inodesUsed": 835229
   },
   "containerFs": {
    "time": "2024-10-24T12:09:40Z",
    "availableBytes": 334328733696,
    "capacityBytes": 500807262208,
    "usedBytes": 87704821760,
    "inodesFree": 30204253,
    "inodes": 31129600,
    "inodesUsed": 835229
   }
  },
  "rlimit": {
   "time": "2024-10-24T12:09:50Z",
   "maxpid": 124659,
   "curproc": 736
  },
  "swap": {
   "time": "2024-10-24T12:09:40Z",
   "swapAvailableBytes": 9663668224,
   "swapUsageBytes": 0
  }
 },

[Firewall]

If it's a bit more difficult to implement I suggest we split the graphs into a seperate task. That way we have a great first iteration of the welcome page ready to go for 1.14.

[ekidneyrh]

Thanks @cdrage for the info! I agree with @Firewall - we can think about graphs etc as a separate task as it's seems more complicated. We will have to discuss if we want to store the history and what it will look like if we do - which will probably take some time.

Is there anything else needed for this ticket or can it be closed?

[Firewall]

I think we are good to close 👍