denis256 notes and projects

kube-scheduler, the Kubernetes scheduler module mirror, had a quiet but useful week: dependency pins moved forward, etcd reached 3.7.0, and mutable scheduler snapshots got a cleaner interface. This is not a flashy feature week. It is the kind of maintenance that matters when you build scheduler plugins or track Kubernetes master from Go modules.

Generated module pins are the main story

The largest part of the seven day window is dependency churn in go.mod and go.sum. That is expected for this repo. The file is generated, and the module mirrors pieces of the larger Kubernetes tree as concrete Go module inputs.

The important detail is not the raw count of 312 insertions and 248 deletions. The useful detail is that the publisher converted local Kubernetes module references back into pseudo versions in the merge for the etcd update. In plain terms, downstream users get resolvable module versions instead of a local replace block that only makes sense inside the Kubernetes source tree.

That matters if you run scheduler plugin tests against this module. A local checkout can pass with sibling module paths. A consumer module cannot. The publisher step keeps the public module usable without asking every user to clone half of Kubernetes next to it. Very boring. Also very necessary.

Concrete items from this batch:

• k8s.io/api, k8s.io/apimachinery, k8s.io/client-go, and related modules moved to fresh pseudo versions
• k8s.io/apiserver moved with them as an indirect dependency
• local replace entries for sibling Kubernetes modules were removed from the published state
• go.sum was trimmed back after the temporary local build view

If your CI compares go.sum too aggressively, expect noise from this sort of mirror update. The right reaction is usually to run normal module tidy checks, not to infer a scheduler behavior change from every checksum line.

etcd 3.7.0 reaches the scheduler module

The clearest dependency update is the bump to etcd 3.7.0. In this repo, it shows up through module metadata rather than scheduler code edits. The diff adds etcd 3.7.0 related module records, then the publisher commit folds the generated module view back into public pseudo versions.

For scheduler users, this does not mean the scheduler suddenly speaks a new public API. The scheduler depends on the broader Kubernetes control plane graph, and etcd is part of that graph. The practical point is that anyone testing master based scheduler builds now inherits the same storage client dependency direction as the rest of Kubernetes.

There are two small traps here. First, do not read this as an isolated scheduler storage feature. The scheduler is not becoming an etcd client in normal operator workflows. Second, do not ignore it if you vendor or pin every dependency for plugin builds. A dependency graph update can still affect build reproducibility, license scans, or static analysis baselines.

The same maintenance window also included a bump of sigs.k8s.io/structured-merge-diff/v6 to 6.4.2. That package sits in the wider Kubernetes API machinery path. In this repo it is indirect, but indirect does not mean irrelevant when you keep a strict module policy.

Runtime plumbing keeps moving

The low level runtime side also moved with the github.com/containerd/ttrpc bump to 1.2.9. The visible diff again lands in module files, with golang.org/x/sys moving to 0.46.0 at the same time.

This is the sort of change that plugin authors can miss because no scheduler package name changes. Then the build image changes, a cache is stale, or a security scanner starts reporting a different set of packages. If your project wraps the scheduler framework in its own module, use this window as a reminder to keep module graph checks explicit.

A useful review routine for this kind of activity:

• compare go list -m all before and after the scheduler module update
• keep generated module changes separate from plugin behavior changes in review
• rebuild against the target Go version, here go 1.26.0
• watch indirect dependency updates that alter platform packages such as golang.org/x/sys

None of this is glamorous. It is still where many broken Friday builds are born.

Mutable snapshots get a cleaner framework contract

The source level scheduler change is small and worth reading. The maintainers embedded SharedLister into MutableSnapshotSharedLister, touching framework/interface.go and framework/listers.go.

Before this, the mutable snapshot lister represented mutation controls, but it did not explicitly include the normal shared lister methods. After the change, code with a MutableSnapshotSharedLister can also use the read side from SharedLister, including node info, storage info, and pod group state access. The interface says what the implementation already wants to be.

That matters around preemption and pod group scheduling. The handle comment still says mutable snapshot access is only for the PodGroupPostFilter extension point. The tighter interface makes the intended access pattern clearer: one object can expose the normal snapshot view and the mutation session operations needed to test scenarios, then restore state.

Plugin authors should not treat this as a broad invitation to mutate snapshots anywhere. The narrow wording is still there. The benefit is mostly type clarity. If custom code had helper wrappers around mutable snapshots, this change may remove a little adapter code. If custom code assumed the mutable lister was only mutation methods, the compiler will tell you where the assumption leaks.

What to watch

First, keep an eye on the mutable snapshot boundary. The comments still restrict it to PodGroupPostFilter, and that is a good thing. Scheduler snapshot mutation is sharp tooling, not a general plugin convenience layer.

Second, expect more generated module pin movement while Kubernetes master keeps advancing. The recent decouple WAP logic merge is a good example: the visible mirror change is module alignment, even when the upstream subject sounds more behavioral.

Third, treat this repo as a signal for consumers of Kubernetes scheduler internals. If you build against master, pin intentionally, review go.mod changes plainly, and let compile errors guide any framework interface cleanup. Drama is optional. The compiler is cheaper.