feat: give every instance its own network interface - #224
Merged
Conversation
Ask the network layer for an interface the way a pod asks for storage: an instance declares what it needs and gets back an object carrying the addresses required to bring up a NIC. A workload's network interface gains the fields a consumer needs to say what kind of address it wants — families in priority order, a reclaim policy, and a class per additional address — and none that name a subnet, prefix length, or location. Instance status grows from a single address to the full picture, so the address column that has always printed blank finally has an answer in it. Provisioning changes shape. One network binding and one shared subnet claim per deployment become one NetworkInterfaceClaim per instance per interface, named from the slot rather than the instance filling it, so a replacement finds a claim that already holds its address. The scheduling gate that held instances back becomes per-instance: one instance waiting on an exhausted pool no longer holds back its siblings. The gate releases on Bound and Allocated rather than Ready. Programmed has no data plane reporting it yet, so it stays Unknown and Ready with it; gating on either would hold every instance forever. Relates to #112.
The data plane can attach one interface to an instance. Accepting more would take a declaration the platform cannot honour. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The Kubernetes 0.36 and controller-runtime 0.24 bump deprecated two helpers the repo leans on. Register API types through an apimachinery scheme builder owned by each API package, keeping the API packages free of a controller-runtime import, and hash instances through the surviving dump package rather than the forwarder apimachinery now asks callers to skip. Also reach for the existing WorkloadDeployment kind constant where a literal had crept back in. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
scotwells
force-pushed
the
feat/112-network-interface-claims
branch
from
August 13, 2026 19:56
25e9e45 to
bb566b0
Compare
scotwells
marked this pull request as ready for review
August 13, 2026 20:20
ecv
approved these changes
Aug 13, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
An instance asks for a network interface the way a pod asks for storage. It says what it needs, and gets back the addresses required to bring one up.
What a consumer writes
A workload names a kind of address, and every replica gets one of its own:
Nothing here names a subnet, a prefix length, a location, or an address. A consumer names a kind of address and the platform decides the rest.
What they get back
Today an instance prints an address column that is always blank. This fills it in, and with more than one address:
An address a workload keeps
An address is claimed for a slot rather than for the instance filling it, so replacing, rescheduling, and redeploying keep the address. Surviving a scale-down takes
Retain.What stops being a problem
Every instance now gets its own addresses. Today one allocation is shared across a whole deployment, so instances cannot be told apart by address.
One instance waiting on an address no longer holds back its siblings — an exhausted pool stalls the instance that hit it, not the deployment.
And when an address cannot be had, the instance says why: an exhausted pool, a family the network does not carry, a project that cannot be resolved. An instance stuck behind an address it never got is a new way to be stuck, and it needs to be legible.
Not on yet
This ships behind the
NetworkingIntegrationfeature gate, which stays off. Nothing changes for anyone until it is turned on.Readiness waits on the address existing, not on the data plane carrying it — the part that reports traffic is a separate change, and waiting for it today would hold every instance forever.
Related