denis256 notes and projects

Kubernetes is the container orchestration project most teams meet through clusters, but this week the interesting work is in the machinery behind new scheduling APIs. The master branch activity is worth reading if you build controllers, scheduler plugins, or clients against alpha APIs. The headline is PodGroup policy work, with preemptionPolicy, workloadRef, and broader declarative validation all moving at once.

PodGroup policy gets a clearer contract

The biggest user facing change is the new PreemptionPolicy field for PodGroup. It adds spec.preemptionPolicy behind the PodGroupPreemptionPolicy gate, with Never and PreemptLowerPriority as the two values. The gate is alpha for v1.37 and depends on GenericWorkload, which is the right warning label for anyone trying this in a real controller.

Defaulting also matters. When the gate is on and the field is unset, Kubernetes defaults the policy to PreemptLowerPriority. The registry strategy drops the field when the gate is off unless it already exists on the old object, so clients should not expect silent persistence while testing mixed settings.

The related rename from PodGroupTemplateRef to WorkloadRef makes the model less nested. Instead of a union wrapping a workload reference, the API now carries spec.workloadRef.workloadName and templateName directly. The follow up generated code refresh pushes that shape into OpenAPI, protobuf, conversion code, and tests.

• spec.preemptionPolicy is immutable.
• Never prevents lower priority preemption for the group.
• PreemptLowerPriority keeps the existing default style.
• spec.workloadRef is the new reference path for Workload owned PodGroups.

Declarative validation stops relying on memory

Validation work shows up across several commits, and it is not decorative. Scale validation became more focused by checking only managed fields and spec.replicas, because the scale handler discards the other metadata fields anyway. That is a small but useful correction: validation should match the object shape that actually survives the request path.

The test harness got stricter too. Scheme gained HasValidationFunc so tests can tell the difference between “no validation registered” and “validation ran and found no errors”. Then the fuzz sweep moved to auto discovery, replacing a hand maintained list of group versions with scheme discovery for served GVKs that have declarative validation.

For contributors, this changes the failure mode. Missing generated validation for a served version should now fail the sweep instead of being skipped quietly. The pod group declarative validation test being touched so often is a signal that alpha API shape and generated validation are being kept in step, not left for release week.

• managedFields validation stays explicit on Scale.
• Scheme.HasValidationFunc removes a false pass case.
• VerifyVersionedValidationEquivalence now treats most missing versions as a bug.

Scheduler events avoid duplicate informer work

The scheduler change that matters most for operators is skipping informer registration for logical Pod event resources. Pod, AssignedPod, UnscheduledPod, and TargetPod do not need separate informer setup. They come from the Pod handlers that are already registered.

This is the kind of change that looks dull until a plugin event map grows and a test starts reporting incorrect registration. The new test asserts that only Pod, Node, and Namespace informers are active for those logical pod resources, with no dynamic informers. Less accidental machinery is better in the scheduler path.

Other scheduling commits reinforce the same area. The maintainers added observation of scheduling attempts during ordered pod creation, flattened pending PodGroup pods, and fixed scheduler perf version emulation when NodeDeclaredFeatures is disabled. Taken together, this is maintenance around queue behavior and feature gate realism. Not glamorous, but this is where scheduler bugs usually hide.

Low level API fixes remove ugly failure modes

The most user visible fix outside scheduling is in API response writing. The apiserver now discards a buffered partial response before writing a fallback status when streaming collection encoding fails under gzip before the response is committed. Before that fix, the fallback status could be appended after a truncated object, producing a body that clients could not parse.

That is exactly the sort of failure that turns a server error into a client mystery. A clean status object is much easier to log, retry, and alert on than half of a JSON list plus an error payload. If client code still accepts partial JSON here, that is client debt, not a Kubernetes feature.

Runtime conversion also got a sharp fix. Kubernetes now avoids generating uint64 values in structToUnstructured, converting unsigned values through a helper that rejects overflow above math.MaxInt64. This keeps unstructured data inside the JSON value set expected by DeepCopyJSONValue and related runtime paths.

How to prepare

If you build controllers around Workload and PodGroup, track the workloadRef rename and the preemptionPolicy field together. Use generated clients from the same branch when testing, because alpha scheduling APIs are moving across types, protobuf, OpenAPI, and validation at the same time.

If you maintain validation code, expect more failures from shared test helpers. The stricter declarative validation sweep is useful, but it means a local change may fail because a served version lacks generated validation, not because your handwritten rule is wrong.

If you operate clusters, there is no immediate config flip here unless you are testing alpha features. Still, read these commits before trying the next Kubernetes development build in busy scheduler environments. The changes are practical, but they touch the exact path where batch workloads, feature gates, and API validation meet.