Kubernetes Was Built for Cluster Admins
Since its 2014 release, Kubernetes has fundamentally changed how services are deployed. Autoscaling, container scheduling, and cost optimization — once difficult to get right — are now standard capabilities that any team can leverage. But the tooling around Kubernetes has remained stubbornly admin-centric, even as the people using it day-to-day have changed.
Today, most organizations separate infrastructure teams from service owners. The infrastructure team builds and maintains clusters; developers deploy and own the services running inside them. This split has enabled more advanced setups, such as clusters spread across multiple geographic regions to reduce latency. But it has also created a visibility problem: a developer checking on their service now has to know which clusters it’s deployed to, then hop between kubectl contexts or multiple UIs to get a complete picture.
That overhead feels small at first, but it compounds with every additional service and region. A quick health check becomes a scavenger hunt across infrastructure you don’t own or manage.
Why Existing Tools Fall Short
The available monitoring tools were designed with a different user in mind. When we evaluated them for service owners, we found three recurring gaps:
- They don’t handle deployments spread across multiple Kubernetes clusters well.
- They typically require clusterwide permissions that service owners shouldn’t have.
- They show everything running on a cluster, with no way to focus on the service you actually care about.
That last point is critical. A cluster-centric view displays every workload, whether it belongs to you or not. What service owners need is the inverse: a view that starts with their service and aggregates its state across every cluster and region where it runs.
A Service-Centric View
We built Kubernetes support into Backstage, our open platform for developer portals, to provide exactly that. Backstage Kubernetes connects directly to your existing Kubernetes API and shows service owners what matters about their deployments without requiring them to become cluster experts.
From a single view, developers can see:
- The current status of their systems, aggregated from multiple clusters and regions.
- Any errors reported by Kubernetes.
- How close each deployment is to its autoscaling limits.
- Container restart counts.
No more spending twenty minutes in a CLI tracking down which clusters your service was deployed to. The information is available at a glance, with deeper details about autoscaler limits, pod status, and errors just a click away.
One Tool for the Full Lifecycle
Fixing pod-level visibility alone would be useful, but it’s more valuable as part of a broader workflow. Backstage already centralizes service information through its service catalog, giving developers a consistent UI for APIs, documentation, and ownership. Kubernetes monitoring slots into that same catalog, so developers have one place to go for both the operational state and the surrounding context of their services.
Because Backstage communicates with the Kubernetes API directly, it is cloud agnostic. It works with any managed Kubernetes offering, including those from AWS, Azure, and Red Hat OpenShift, regardless of the provider used internally.
What’s Next
Kubernetes support in Backstage currently focuses on Deployments and Custom Resource Definitions. As development continues with the open-source community, the plan is to expand support to additional Kubernetes resource types.
For developers deploying services to Kubernetes, the goal is simple: managing your service shouldn’t require mastering cluster management.
