Node ROLES: configurable role-label sources for non-Kubernetes label schemes

[jonathanwiemers]

First off — thanks for sofka. It has replaced k9s in my daily work, and the
config model (views, thresholds, per-context overrides) is a big part of why.

Problem

ROLES on the nodes table is built from two hardcoded label sources
(columns.rs::node_roles): the node-role.kubernetes.io/<role> key prefix and
the legacy kubernetes.io/role value. Anything else renders <none>.

Clusters whose provisioning labels nodes under their own domain hit this in both
shapes that exist in the wild:

• role in the key: node-role.example.com/<role>: ""
• role in the value: example.com/role: <role>

On those clusters the nodes table loses the column that tells control plane from
workers at a glance, while the labels are right there on the object.

Proposal

An opt-in config section that adds label sources. The Kubernetes-standard pair
stays active with no configuration.

[node_roles]
label_prefixes    = ["node-role.kubernetes.io/", "node-role.example.com/"]
legacy_label_keys = ["kubernetes.io/role", "example.com/role"]

• a prefix entry contributes the non-empty key suffix as the role
• a legacy entry contributes the non-empty label value as the role
• configured entries merge with the built-in pair, then sort + dedup, so listing
  the Kubernetes entries explicitly (as above) is a no-op

Display only — no effect on scheduling, filtering, sorting semantics, or any API
call. With no [node_roles] section the cell renders exactly as it does today.

Why [views] doesn't cover this

The obvious workaround is a custom column, and for the value shape it does work
— as a separate column next to ROLES:

[views.nodes]
columns = [{ header = "ROLE", path = "/metadata/labels/example.com~1role" }]

The key shape has no equivalent. A JSON Pointer selects one known key, but
node-role.example.com/<role> puts the role in the key and uses one label per
role, so there is no fixed path to point at — and no way to fan several of them
into one cell. Even where a custom column does work, it sits beside a ROLES
column still showing <none>, which is worse than either alone.

So this isn't a gap in [views] — it's that role labels are a merge of several
dynamic keys, which is exactly what node_roles already does for the
Kubernetes-standard labels. The ask is to let that same merge see one more
domain. (#523 asked for custom columns in general, which [views] already
covers; this is the narrower case that survives it.)

Happy to work up a PR if you think this fits.

[nklmilojevic]

This fits sofka. Agreed scope for a PR:

• Add optional [node_roles] settings named label_prefixes and label_keys. Keep both built-in sources active and keep the current output with no configuration.
• Add configured sources to the built-in sources, ignore empty role suffixes and values, and sort and remove duplicate roles. Reject empty prefixes with a config warning.
• Support cluster/context overrides and :reload. Use normal array replacement between config levels, then add the built-in sources.
• Use the same role text for display, filtering, and sorting. No changes to Kubernetes objects or API requests.
• Include tests and configuration documentation.

One correction to the workaround: name = "ROLES" replaces the existing column. A separate column is not required. However, it cannot collect variable label keys or combine several sources, so the proposed feature still fills a gap.

Please show only custom sources in the example and use label_keys, since custom labels are not necessarily legacy. I will track this in an issue and start the PR.