🚀 Feature: Higher level opinionated view for Kubernetes plugin

[mclarke47]

🔖 Feature description

We should introduce a higher level view for the Kubernetes plugins that is:

• Holistic
• Easy to scan for errors
• More visual, i.e. less reading and paging through data tables
• integrates directly with the error reporting functionality

Something like this:

The user should be able to group the resources on screen various ways, for example:

• by some common label (environment/region/owner etc...)
• by cluster

🎤 Context

The existing Kubernetes plugin works ok to show a basic k8s configuration; however, it can get much more complicated when multi-cluster deployments are shown. The user ends up maximizing and minimizing accordions to see resources across clusters.

✌️ Possible Implementation

We can start with an opt in switch at the top of the Kubernetes plugin showing the existing view by default. Then add functionality to include the higher level view.

We can start with pods, then incorporate:

• cronjobs
• scaling
• service discovery

👀 Have you spent some time to check if this feature request has been raised before?

• I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

• I have read the Code of Conduct

Are you willing to submit PR?

Yes I am willing to submit a PR!

[mclarke47]

Also very interested in feedback from plugin users and what they would like to see here!

[adamdmharvey]

Love the idea; but no specific feedback points of suggestions re: the visual. Could build upon work done in the resource graph part of Backstage which maps entities, but maybe do the same sort of mapping of clusters, deployments, etc.

One thing that might be super helpful for our teams is elevating info about deprecations. As we keep our k8s clusters up to date, we've got various approaches - some which work well, others which could use improvements - of helping our teams keep up on api version changes and deprecations. Elevating summary info per entity on what deprecations are being encountered so teams could be proactive on it might be super useful!

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[rydenius]

One specific aspect that is important to me and my team is that there is super clear distinction between different levels of "errors". The fact that a pod is not yet healthy when it has not yet reached the initialDelaySeconds + periodSeconds * failureThreshold of the startup probe is not an error at all (hourglass icon seems appropriate). A pod that was successfully restarted because of failed probes is for sure an error, but one that the system could fix on its own, so not too bad. A crash looping pod is the worst type. Getting the orange warning triangle during a regular deploy (no single crash, just not done yet) makes the adrenaline rush and my team jump to the conclusion that something is very wrong.