Multi-cluster

Several Kubernetes clusters open at once, for real

PodSteer holds several clusters open at once, one per tab, each with its own namespace, search and refresh. The All-clusters view merges pods, workloads or events from every open tab into one table, and each cluster reports for itself when it is slow, unreachable or refusing.

Tabs that are real

No part of PodSteer has a notion of "the current cluster". Every call names the cluster it is for, so each tab keeps its own namespace, filters, open object and connection, and the tabs are genuinely independent rather than one selector with extra steps.

Several namespaces at once

The sidebar's namespace selector takes a set: All, a filter box and checkboxes, applied as you tick. The set holds across Pods, Deployments and the other workloads, Events, Applications, Helm, Security, custom resources, the Multi-kind table and the Topology, and is remembered per cluster. On the All-clusters view it offers the union of the open clusters' namespaces.

The sidebar's namespace selector open over the Pods list, with payments, platform and storefront ticked and the other namespaces unticked, the button naming payments and two more, and the list showing the 38 pods of those three namespaces together. The sidebar's namespace selector open over the Pods list, with payments, platform and storefront ticked and the other namespaces unticked, the button naming payments and two more, and the list showing the 38 pods of those three namespaces together.
Several namespaces at once. One selection, applied as you tick, and kept by every list and the topology.

One table across clusters

The All-clusters view reads each open cluster in parallel and shows what answered. A cluster that is forbidden, unreachable or slow is marked on its own rather than failing the whole view, and nothing is polled when the view is not on screen.

The Multi-kind table shows several kinds in one list — the Deployments, Services and Ingresses of one application, say — and a set of kinds can be saved.

The All clusters view with two demo clusters open, filtered to failing pods: five from kind-podsteer-demo in the payments and storefront namespaces and one from kind-podsteer-demo-2 in warehouse, each row naming its cluster. The All clusters view with two demo clusters open, filtered to failing pods: five from kind-podsteer-demo in the payments and storefront namespaces and one from kind-podsteer-demo-2 in warehouse, each row naming its cluster.
Failing pods, in every open cluster. One table across every open tab, so a problem in the second cluster is not hidden behind the first.

Finding and organising clusters

  • Discover EKS, AKS, GKE and DigitalOcean clusters through the aws, az, gcloud or doctl CLI you already use, and add one in a click.
  • Read kubeconfigs from a folder of files as well as ~/.kube/config, with changes picked up without a restart.
  • Group clusters, pin them, and mark a group as production or read-only.
  • Connect through a proxy.

What it does not do.

  • Cloud discovery runs your own CLI, which contacts your cloud provider; PodSteer passes it no region, account or project of its own and never installs one.
  • PodSteer is a desktop application: it does not run in a cluster or serve a shared web dashboard.
  • RBAC review reads one namespace at a time, and a dialog that needs a single namespace asks for one when several are selected.
  • Selecting more than three namespaces reads the whole cluster and filters it, so an account allowed only a few namespaces is limited to the lists it may make.

Cluster assessment

Ranked findings instead of a pod list: crash loops, OOM kills, pods that will never schedule, sizing problems — each with what to do about it.

Day-2 operations

Apply any kind including CRDs, roll back, drain, bulk-act with a review step — and see the kubectl command for each.

Shells and terminals

Exec, debug containers, node shells, an in-cluster shell and your own local terminal — with the pods PodSteer creates cleaned up after.