Add NetworkService and resolve its membership from interfaces - #441
Merged
Conversation
An application that runs in several locations has no resource that names its members as a group, so a consumer who wants traffic spread across them has to write addresses, per-location weights and a failover order by hand and keep them current as capacity moves. Add NetworkService, which selects network interfaces by label and reports per-location member and health counts in its status. A controller resolves the selector into membership, counts a member healthy only when its holder says so, and refuses a selector whose members span two networks. Protect the new kind with Milo IAM. Key changes: - Add the NetworkService API type, CRD and reference docs - Add a controller resolving membership from bound interfaces - Report Ready and MembersResolved with per-location summaries - Register the kind as an IAM protected resource and grant roles
4 tasks
ecv
previously approved these changes
Sep 9, 2026
ecv
left a comment
Contributor
There was a problem hiding this comment.
The NetworkService API and membership resolution read cleanly. Namespace scoping, the empty-selector CEL guard, the multi-network refusal, and the healthy-vs-member split are all covered by unit tests, and status is recomputed whole each pass with a stability test behind it.
Minor note for later, not a blocker: the serving field comment reads as though there is a health threshold, while the implementation is strictly healthy > 0.
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 application running in several locations has no resource that names its members as a group, so a consumer who wants traffic spread across them writes addresses, per-location weights, and a failover order by hand and keeps them current as capacity moves. This adds a network service that selects network interfaces by label and reports per-location member and health counts in its status, with membership tracking whatever is bound at the time. A controller resolves the selector into membership, counts a member healthy only when its holder says it is available, and refuses a selector whose members span two networks since a service is one network. This is the third of six stacked pull requests splitting the network services prototype, and it builds on the holder condition from the first.
Test plan