Choose a SKAO debugging tool

Headlamp, Coder, BinderHub, and InfraHQ expose different execution contexts. Choose the tool according to the evidence and interaction your investigation needs.

Match the tool to the problem

Tool	Best fit	Execution context	Main limitation
Headlamp	Inspect current Kubernetes state, events, logs, resource relationships, and deployment metadata	Web interface backed by the Kubernetes API	Offers less flexibility than a shell or IDE
Coder	Run cluster-aware commands, test network paths, inspect workloads, and use remote development tools	Persistent remote workspace inside the Kubernetes cluster	Available only in selected environments and constrained by workspace RBAC
BinderHub	Reproduce notebook code and dependency environments, then share the same execution context	Per-repository image built by repo2docker and launched by JupyterHub	Requires committed repository content, and starts without Kubernetes credentials, so it can reach Services in its cluster but cannot query the cluster itself
InfraHQ	Reach a cluster from your own machine and run local tools against it, including kubectl, Headlamp, and JupyterHub	Short-lived credentials written into a local kubeconfig	Not deployed everywhere, granted per person, and bounded by the RBAC configured for your identity

Follow the evidence path

        flowchart TD
    S["What evidence do you need?"] --> K{"How do you need to reach live cluster state?"}
    K -->|"Hosted web view"| H["Headlamp"]
    K -->|"Shell, network test, or IDE"| C["Coder"]
    K -->|"Local kubectl or local tools"| I["InfraHQ"]
    K -->|"Not live state"| R{"What kind of evidence?"}
    R -->|"Reproducible notebook environment"| B["BinderHub"]
    R -->|"Historical logs or metrics"| O["Observability tools"]
    

Use Monitoring and logging for retained logs, metrics, dashboards, and alerts. Headlamp and Coder show live cluster state, which can remain available after central log retention has expired.

Understand Headlamp

Headlamp turns Kubernetes API objects into navigable views and applies the permissions of the signed-in identity. It can display Pods, controllers, Services, events, logs, metadata, and custom resources. SKAO plugins add organisation views, Prometheus metrics, CI/CD ownership metadata, Helm release information, and Tango Operator resources.

Headlamp does not create a separate debugging environment. It presents the current cluster state and links that state to related monitoring, logging, and delivery information. This makes it the lowest-overhead starting point for a runtime investigation.

How you reach Headlamp depends on the environment. The central CI/CD datacentres publish it on a URL. The ITF and Array Assembly environments do not, so you run Headlamp locally over an InfraHQ connection instead.

Understand Coder

Coder provisions a remote development workspace from an administrator-defined template. The SKAO Kubernetes workspace runs inside the cluster and includes cluster-aware command-line tools. Coder routes browser terminals, web IDEs, desktop IDE connections, and SSH sessions to the workspace.

The workspace has persistent home storage, but it is separate from the target application Pod. Kubernetes RBAC controls what it can inspect or change. This separation lets a developer retain tools and source code while investigating multiple permitted namespaces without modifying the application image.

Understand BinderHub

BinderHub converts a repository and Git reference into a runnable environment. It asks repo2docker to read dependency files, build an image, and store that image in a registry. JupyterHub then starts a notebook server from the image. BinderHub reuses the cached image when the same resolved reference has already been built.

The Git repository is the reproducibility boundary. A package installed by hand inside one running server can test a hypothesis, but collaborators receive it only after the dependency is recorded in the repository and BinderHub builds a new image. A commit SHA or tag provides a more stable shared environment than a branch name.

The cluster is the second boundary, and a narrower one than it first appears. A notebook server reaches the internal network and the internet as normal. What is specific to its cluster is in-cluster DNS: a name such as <service>.<namespace>.svc.cluster.local resolves only from inside the cluster that hosts it. The server also starts without Kubernetes credentials, so it can use a running Service but cannot query the API server about one. Reaching a deployment and inspecting a deployment are different capabilities, and BinderHub provides only the first.

Understand InfraHQ

InfraHQ issues short-lived Kubernetes credentials and writes them into a local kubeconfig. It provides no debugging interface of its own. What it provides is reachability: once you select a destination, the cluster answers kubectl from your own machine, and any tool that reads a kubeconfig works against it. That includes k9s, a locally run Headlamp, and a local JupyterHub targeting the cluster.

This matters in two situations. The first is a cluster that publishes no web endpoint, such as the ITF and Array Assembly environments, where InfraHQ is the only route to Headlamp. The second is a preference for your own tooling and notebooks over a hosted environment, while still working against real cluster state.

The credentials carry the RBAC configured for your identity, so what you can read and change comes from your grants rather than from the tool. Availability is not universal: InfraHQ is not deployed in every environment, and access is granted per person and per cluster rather than by default. Request it before an investigation depends on it, following Access a cluster with InfraHQ.