Two ways to reach it

Direct

An HTTP(S) /metrics URL, with an optional bearer token and CA (or an insecure toggle for a self-signed lab). This is the right mode when KSM is behind an ingress or reachable on your tailnet.

Via an existing Kubernetes cluster

KSM is usually a ClusterIP service with no ingress at all — which on a phone would make it unreachable. So the second mode scrapes it through a cluster you have already added, using the API server’s service proxy:

/api/v1/namespaces/{namespace}/services/{name}:{port}/proxy/metrics

That reuses the cluster’s URL, auth and TLS, so there is nothing new to expose and nothing new to store: you pick a cluster, a namespace, a service and a port.

It is also a good illustration of how the app is put together — the KSM module does not depend on the Kubernetes module. The Kubernetes connection publishes a small “cluster service” capability, and KSM asks the app for whichever ones exist. Adding a new provider never means editing another one.

Polling, and history it keeps itself

KSM returns a snapshot, not a series. So:

• an initial scrape when the screen opens;
• a periodic re-scrape while live updates are on (an app-bar toggle);
• pull-to-refresh, always.

Each scrape folds the cluster-level scalars into a session history store, which is what the overview charts draw. The store is cleared when you switch connections, and it is honest about what it is: a session’s worth of history, not a time-series database. Cumulative counters (container restarts, for instance) are differentiated into per-second rates before charting.

The interface behind all this is deliberately “where does a snapshot come from”, so a Prometheus-backed source — real range queries, real history — can be added later without the dashboard changing.