fix: React to changed ServiceEntry VIPs for ingress-use-waypoint#14391
Merged
davidjumani merged 1 commit intoJul 13, 2026
Merged
Conversation
Signed-off-by: Yossi Mesika <[email protected]>
gateway-bot
added
kind/fix
Contributor
There was a problem hiding this comment.
Pull request overview
This PR fixes a stale-backend bug in kgateway’s Istio ServiceEntry integration for the ingress-use-waypoint path: when Istio auto-allocates a VIP by writing only to ServiceEntry.status.addresses (without bumping generation), kgateway now detects that change and reprograms the static cluster, preventing persistent 503s.
Changes:
- Include resolved
ServiceEntryaddresses (includingstatus.addresses) inBackendObjectIR.ObjIrso backend equality changes when the VIP is allocated. - Add unit tests validating that status-only VIP updates flip backend equality while no-op updates remain stable.
- Add an e2e ingress test case and supporting YAML to exercise the auto-allocated VIP scenario end-to-end.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| test/e2e/features/waypoint/testdata/httproute-ingress-serviceentry.yaml | New e2e test manifest covering ServiceEntry VIP auto-allocation + ingress Hostname backend routing. |
| test/e2e/features/waypoint/cases_ingress.go | Adds an e2e test that waits for ServiceEntry.status.addresses VIP assignment and verifies ingress traffic succeeds via waypoint. |
| pkg/kgateway/extensions2/plugins/serviceentry/backends.go | Makes backend equality sensitive to resolved ServiceEntry addresses so status-only VIP changes trigger backend re-emit/reprogram. |
| pkg/kgateway/extensions2/plugins/serviceentry/backends_test.go | Unit tests ensuring backend equality reacts to status VIP allocation and remains stable otherwise. |
davidjumani
approved these changes
Jul 13, 2026
github-merge-queue
Bot
removed this pull request from the merge queue due to failed status checks
Jul 13, 2026
github-merge-queue
Bot
removed this pull request from the merge queue due to failed status checks
Jul 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.
Description
When an
ingress-use-waypointHTTPRoute targets aServiceEntryvia aHostnamebackendRef, and that ServiceEntry relies on Istio IP auto-allocation (nospec.addresses), the ingress returned 503s for newly created ServiceEntries.Istio writes the auto-allocated VIP to
ServiceEntry.status.addresses, which does not bump the object'sgeneration.BackendObjectIR.Equalscompares the source object by generation (labels/annotations), so the status-only VIP update was treated as no change: the backend built before the VIP was allocated kept an empty static cluster and was never reprogrammed. Any metadata edit to the ServiceEntry (e.g. adding an annotation) worked around it by forcing a re-evaluation.The ServiceEntry backend now carries its resolved addresses (which include
status.addresses) inBackendObjectIR.ObjIr, so a change to those addresses flips backend equality and the static cluster is reprogrammed with the allocated VIP.Fixes #14390
Change Type
/kind fix
Changelog
Additional Notes