Provide more details in Backstage cluster overview

[weatherhog]

Above: Screenshot of the cluster overview as of 2025-01-09.

In our Clusters list in Backstage, as of now we only provide a minimal set of cluster details. To make this more useful to platform teams and admins with a larger amount of clusters, we should add more details (customizable) and more filtering and sorting capabilities to this list.

Colums to add to the table:

• Cluster app version
• Release version
• Kubernetes Version (including EOL marker)
• Kubernetes EOL date
• Number of node pools
• Number of nodes (control plane and node pools)
• Pod CIDRs (.spec.clusterNetwork.pods.cidrBlocks)
• Service CIDRs (.spec.clusterNetwork.services.cidrBlocks)
• Control plane failure domains (availability zones, .status.failureDomains)
• Control plane ready (.status.controlPlaneReady)
• Infrastructure ready (.status.infrastructureReady)
• Configurable set of labels and annotations from the cluster.x-k8s.io resource
• AWS account ID (and equivalent for other providers)
• Type of cluster (Giant Swarm vs. imported EKS etc.)

[marians]

To support platform teams managing lots of clusters, I would like to set a focus on providing a much richer clusters list. In addition to that, some information may only be accessible on a per-cluster basis. But here I want to propose some items and functions for the tabular list.

• Annotations and labels on the cluster.x-k8s.io Cluster resource. Some of them are defined by Giant Swarm for a purpose we know (example: scheduled upgrade), some are defined by the customer. We could offer one table column per annotation key and per label key. As this would make the table overly wide, so these columns would have to be hidden by default and custom column selection would be offered.

• Grouping the cluster overview by a user-defined column. For example, a customer uses labels like acme/environment: production on a cluster. This way the list can be grouped by environment production/development/staging.

• Filtering by columns. It should be easy to select a certain field and only show items with a certain value (or matching a pattern)

• Additional details to show in columns, not necessarily from the main cluster resource. We might need ways to pull this from non Kubernetes sources, e. g. Prometheus, in a non-blocking way.

  • Kubernetes version
  • Number of worker nodes
  • CPU
  • RAM

[marians]

Adding a detail for the list view here: Let's show the GitOps icon for clusters managed through Flux. The logic for detecting this should be encoded in happa.

[marians]

Regarding how customer users access workload clusters, I don't know what's the status currently. Opened this thread to find out more. Team Shield is now responsible for the access part.

[marians]

TODO:

• Update spec
  • Happa icon
  • Add SSH access tab
• Clarify whether we can show the providers supported by an installation

[marians]

TODO: Marian reads through to check of it can get closed and moved to PDV

[marians]

Status:

• Updated the main comment. Scope of this issue should be extending the details shown in the list. To be continued.
• Looked into CAPA details to have an up-to-date picture of what would be available via the MC.

@gusevda I would like to talk to you at some point about how to deal with cascading loading of details, e. g. if some are not available in the Cluster resource itself, but instead in linked resources like AWSCluster, KubeadmControlPlane etc.

[marians]

@gusevda and I talked about this briefly today. We should do a spike towards populating list views based on requests for several types of resources. Example: In one column, show the AWS account ID, which is encoded in the AWSClusterRoleIdentity (infrastructure.cluster.x-k8s.io/v1beta2) resource in .spec.roleARN.

[marians]

@fiunchinho mentioned that it would be great to have the cluster app version in the list view.

That's available in the main Cluster resource as annotation app.kubernetes.io/version or helm.sh/chart.

[marians]

Here is a new wireframe of some faceted table views for clusters and deployments.

https://www.figma.com/design/JUpSVVpsvj81PvHC57EnsB/Backstage-%E2%80%93-cluster-list?node-id=0-1&t=zdLvybITc4o8wnbL-1

[marians]

@gusevda and I have discussed the implications of showing cluster details in the list view that are not available in the main Cluster resource. There are many examples for this, but just to name one:

In order to determine the ID of the AWS account the cluster is running in, we must fetch the AWSCluster resource, then read .spec.identityRef to then fetch the AWSClusterRoleIdentity, which has the account ID in the .spec.roleARN field value. That's two additional resources to fetch (apart from the Cluster resource).

The current situation with asynchronous queries to multiple management clusters already isn't ideal. The resulting table view gets re-rendered as a user reads the content, leading to rather unpredictable results when clicking a row item in the moment the underlying table changes etc. These unwanted side-effects of asynchronous requests would only get amplified if we decided to do more of them.

So instead we are planning to pre-fetch the entire table content before displaying results. While queries are in progress, we would show a status indicator with status info (in progress / done / failed) per management cluster. Our current assumption is that this would mostly affect users on their first visit to the list page. On subsequent visits, the client should have most data cached already.

Anyway, the duration to wait for the table to load will depend on the number of resource kinds to fetch. Hence we should be specific about which resources to fetch and avoiding querying some that are not needed (e. g. because the details they provide are not shown in any visible columns activated by the user). Note: the need to fetch a resource will also be affected by filter facets, which are not in scope of this issue.

Some information to display in the table will be provider-specific (as shown in the example above). There are several ways how this can play out in the UI. One option is to have very specific columns, e. g. one titled AWS Account ID and another e. g. named Azure subscription ID. Depending on the case, we might decide to introduce one column only (e. g. Account ID) to show information from various sources related to various providers.

[marians]

In https://github.com/giantswarm/backstage/pull/627 I'm changing the TYPE column to show an icon, making room for more details horizontally.

[marians]

https://github.com/giantswarm/backstage/pull/629 is for adding the RELEASE column.