Kubeconfigs and contexts

Adding a file

Kubeconfigs are added by path and referenced in place. Spinoza never copies one, and never merges several into a file it manages. The list of paths it knows about lives in kubeconfigs.json.

Contexts are grouped under the file they came from, so two contexts with the same name in different files stay distinguishable.

Reading them

Every file is re-read on every listing and on every context switch, so an edit you make outside Spinoza takes effect without a restart.

spinoza --kubeconfig /path/to/config

--kubeconfig replaces the default lookup for that run only. It does not add the file to the list.

Opening one

Open clusters sit as tabs in one strip, with a control beside them that lists the contexts it knows about. The header names the cluster you are working in.

Opening a context says how long it is prepared to wait, and gives you a control to stop waiting. If a cluster is already open, it asks whether to replace that tab or keep both, and can remember the answer.

Each tab's menu renames it, gives it a colour, puts it in a group, and decides whether it reopens on the next run.

Accounts limited to some namespaces

A kubeconfig whose account reads only named namespaces works as it is. The namespace picker offers the namespaces that account can read, and a view across all namespaces asks you to pick one when the account cannot read the kind everywhere.

An account that cannot list namespaces at all has nothing to discover them from. Spinoza tries the namespace set in the kubeconfig, and Settings, Cluster takes a list of the others for that context. It shows only the ones the account can actually read.

Version skew

Spinoza is built on client-go v0.36, which puts Kubernetes 1.35 to 1.37 inside the supported skew.