denis256 notes and projects

A quiet week for kubernetes/kube-scheduler on the surface: four commits, mostly module file churn. Under the churn there is one real story for operators, the promotion of the scheduling workload API to v1alpha3 with a breaking shape change to DisruptionMode, plus a golang.org/x/net bump that unblocks Go 1.27 tip builds.

The published kube-scheduler repo is a staging mirror of the in tree component, so what shows up here as go.mod shuffling is the publish bot replaying upstream changes after they merge into kubernetes/kubernetes. The repo is small but it is the canonical surface that downstream consumers vendor against, which is why every dep update matters for anyone embedding scheduler code in custom schedulers or operator controllers.

Workload API moves to v1alpha3, DisruptionMode is now a struct

The most consequential change of the window is the v1alpha3 promotion merge. The commit message is short but the description is the part to read: the scheduling workload API drops v1alpha2 and v1alpha3 converts DisruptionMode from an enum field to a struct. Anyone running custom schedulers or controllers built against v1alpha2 needs to regenerate clientsets and update field access patterns. There is no transition shim. The two versions do not coexist.

Inside kube-scheduler itself the visible footprint is one import flip in framework/listers.go. The lister now imports k8s.io/api/scheduling/v1alpha3 instead of v1alpha2. That one line is a flag for the rest of the ecosystem: if you maintain a plugin that registers framework listers or that consumes the scheduling types, audit your imports and rebuild against the new module versions pinned in the parent kubernetes/kubernetes tree.

Practical impact:

• Any code that wrote mode := pod.Spec.DisruptionMode (enum) now needs the struct accessor pattern shipped with v1alpha3. Treat it as a typed switch over fields, not a single value.
• CRD or schema generation pipelines that produce OpenAPI from this group must be regenerated.
• kubectl explain output for the workload scheduling types will change once the apiserver side rolls.

Nothing in the scheduler binary itself changes for end users. The promotion is purely on the API surface that custom integrations bind to.

golang.org/x/net 0.55.0 unblocks Go 1.27 tip

The merge of the x/net bump from 0.54.0 to 0.55.0 has the most useful commit message of the week. It pins down a real failure mode in CI:

vendor/google.golang.org/grpc/internal/transport/handler_server.go:271:18:
    undefined: http2.TrailerPrefix

In x/net 0.54.0, http2.TrailerPrefix lived only inside http2/server.go, gated by a build tag of !(go1.27 && !http2legacy). Under Go 1.27 tip the symbol disappeared and the gRPC vendor copy stopped compiling. Upstream golang/net commit 1efab4271a moved the symbol and a few siblings that were accidentally dropped by the go1.27 server wrapper into common files. v0.55.0 carries that fix.

For operators this is housekeeping, but for anyone running kubernetes/kubernetes ci-kubernetes-e2e-kind-golang-tip or ci-kubernetes-unit-golang-tip jobs in a fork, this is the bump that turns the build green again. The tracking issue is kubernetes/kubernetes#139257.

Two notes worth filing away:

• If you maintain a downstream that vendors golang.org/x/net directly, do the same bump. The http2.TrailerPrefix issue is not specific to scheduler code, it lands wherever gRPC handler_server.go is compiled with Go 1.27 tip.
• The default godebug line in go.mod is go1.26, so Go 1.27 tip is being tested but not yet the targeted runtime.

golang.org/x/crypto goes to 0.52.0

The other Go module change is the x/crypto bump to v0.52.0. The commit message is one line, no rationale, so this is plain housekeeping. The diff drags along the usual companions: golang.org/x/sys from 0.43.0 to 0.45.0, golang.org/x/term from 0.42.0 to 0.43.0, and golang.org/x/text from 0.36.0 to 0.37.0.

Worth noting in the same diff: the published go.mod flips the in tree replace directives. The published mirror normally pins indirect deps to pseudo versions like v0.0.0-20260522... so the package resolves without local module replacements. The publish bot is doing its job here, do not treat the appearance and disappearance of the replace (...) block as a real edit. It is an artefact of how the staging mirror is generated from the monorepo.

Where the churn lives

Both touched files are unsurprising:

• go.mod, touched by all 4 commits
• go.sum, same

That is the entire surface area for this window outside the v1alpha3 promotion. If you grep your local clone for anything more interesting than a module pin, you will not find it. The work this week was upstream of the publish boundary, in kubernetes/kubernetes proper, and the mirror only sees the resolved module state.

What to watch

A few follow ups worth tracking:

• v1alpha2 of the scheduling workload API is gone. If you have CRDs, controllers, or custom schedulers still importing it, they will fail to build on the next dep refresh. Update before pulling the next kube-scheduler tag.
• The Go 1.27 tip CI fix in x/net 0.55.0 is the first signal that the next Go release is starting to surface API drift in vendored gRPC. Expect more bumps as the toolchain stabilises.
• The published mirror’s go.mod will keep oscillating between pseudo version pins and local replace blocks. This is not a regression, it is how the publish bot reconciles in tree refs.

If you want the canonical context, the merged PRs are kubernetes/kubernetes#138572 for the workload API promotion and kubernetes/kubernetes#139258 for the x/net bump. The published mirror at kubernetes/kube-scheduler is the right place to point Go module consumers at.