Browsing resources

Under Custom Resources, kweblens adds one collapsible sub-group per API group, generated from the cluster’s own CRDs and sorted alphabetically; the kinds inside each group are sorted by label. Nothing has to be registered, and a CRD installed after startup appears when the catalog is next fetched.

Custom resource lists are rendered with the CRD’s own printer columns — the same additionalPrinterColumns that kubectl get uses — so a custom kind gets meaningful columns rather than just name and age.

Gateway API is delivered as CRDs, but it is networking, not a curiosity. When the gateway.networking.k8s.io group is discovered, its kinds are lifted out of Custom Resources into their own Gateway category, placed immediately after Network — where someone looking for ingress-shaped things will actually look. The kinds are removed from Custom Resources at the same time, so they never appear twice.

Inside the category the order follows traffic flow rather than the alphabet — GatewayClass, Gateway, ListenerSet, HTTPRoute, GRPCRoute, TLSRoute, ReferenceGrant, BackendTLSPolicy — because reading top to bottom then follows a request. Kinds outside that list (a newer API version, an extension of the same group) sort after the known ones rather than being dropped.

The promotion is conditional. A static entry for a CRD-delivered kind would give every cluster without Gateway API a dead category that errors when clicked, so the category only exists where the group does.

The two answers to "what scales this workload" used to be filed in two places: the built-in HorizontalPodAutoscaler sat in Config, next to ConfigMaps and Secrets, while the CRD-delivered VerticalPodAutoscaler sat under its API group in Custom Resources. They are one category now — Autoscaling, immediately after Workloads, the thing they act on.

Inside it the order is by what each kind changes: an HPA changes how many pods there are, a VPA changes how big each one is, and "how many" is the question asked first when a workload’s capacity moves.

The category is on every cluster, and only the VPA half is conditional. HorizontalPodAutoscaler is a built-in kind — autoscaling/v2, served by every supported cluster — so there is always something to navigate to, and an empty list is a correct answer: it is how you see that a cluster has no HPAs yet. Every one of the other 38 built-in kinds is in the menu on those terms, and nothing is probed to decide it. The VPA kinds appear where their CRD is installed, which is the Gateway rule and the only thing that rule covers: a kind the cluster’s API does not serve does not go in the menu.

VerticalPodAutoscalerCheckpoint is deliberately not in the category. It is the recommender’s saved histogram for one target — the cluster writes them, and there are more of them than there are VPAs — while the recommendation an operator wants is on the VPA’s own status. It stays under Custom Resources with its API group, so it is demoted rather than hidden.

status: matches the state the server computed for the object, which is the same value the category overview cards count. A card reading 80 Running · 3 Pending · 2 Failed and the rows status:Pending selects are therefore the same objects, not two similar answers.

That is the reason the state is computed on the server and shipped on the row rather than derived in the browser. For several kinds the browser could not derive it at all: a Service is broken when nothing is behind it, which lives in the Endpoints object; a claim is "Nearly full" only according to the metrics backend; a ConfigMap is "Not referenced" only after scanning the namespace’s pods, service accounts and ingresses. Those three are shipped too — the list request opens the same second collection the card used, once, before it walks the rows (see Health and diagnostics for what each costs). And a rule transcribed into two languages drifts without either side going quiet — both keep answering, just differently.

Two consequences worth stating:

A query that does not parse is not applied, and the header says why — an invalid regex, an unterminated quote, a missing label key. Every row stays on screen and the count goes back to the plain total, because "nothing matched" and "your pattern is broken" are different claims and only one of them is true. The parser is kweblens-ui/src/objectFilter.ts; its grammar and every malformed input are pinned by objectFilter.test.ts.

The filter is client-side, and that is a decision rather than an accident. A filter evaluated over a truncated page reports "no matches" for an object that exists, which is the failure the Performance and scale page’s paging question was closed to avoid. The list endpoint returns the whole collection — chunked internally, which the client never sees and which never truncates — so a filter that runs in the browser sees every object and cannot give that answer.

The same projection adds a field: kweblensState, {"label": …, "tone": …} — the object’s state in the vocabulary described under status:, computed by the same call the overview cards tally their numbers from. It is what lets a filter in the browser select exactly the objects a card counted. Kinds with no verdict get no field at all, and it is added in the projection rather than in either controller for the same reason the strips are: the list and the watch are separate code paths feeding one table, and a field added to only one of them would be erased by the first watch event to arrive.

Opening a row’s detail drawer refetches the full object from GET …/object whenever the row it was given contains a null inside one of those fields. The predicate reads the row rather than consulting a hard-coded list of kinds, deliberately: a kind list in the browser would be a second copy of the server’s rule, and the copy that goes stale silently.

So the projection bounds what a listing pushes into the browser. It does not hide anything from you. Per the identity model, an operator may read any Secret the underlying credentials can reach, and the drawer shows the real values — see Security and identity.

Sections appear only where they apply, so you will never see all twelve at once:

Three of them — Endpoints, Selected Pods and Mounted By — get kind-specific columns; the rest render as name/kind/namespace tables.

Each section is bounded at 100 items, and says so when it truncates rather than quietly showing a prefix: Showing the first N only — there are more. An empty section renders the literal word None., and a section kweblens is not permitted to read says that too — a permission error is reported, not folded into an empty list.

Relation carries objects, so a join whose interesting answer is that the referenced object is missing cannot be expressed: an absent reference could only be dropped (claiming a completeness that is false) or fabricated (claiming an existence that is false). Ingress TLS secret expiry is the usual request and is not implemented for that reason.

Requests-and-limits versus actual usage is not a relation either — that is the metrics path, see Metrics.