Add gateway_selector field to VirtualService for label-based gateway selection

[prashanthjos]

Add Label Selector Support for VirtualService Gateway Selection

Overview

This PR introduces a new gateway_selector field to the VirtualService API that enables selecting gateways using Kubernetes-style label selectors instead of explicit gateway names.

Problem

Currently, VirtualServices require explicitly listing gateway names, which creates operational challenges when updating or replacing gateways across hundreds of VirtualServices.

Related Issue

Fixes: #58426

Solution

Add a new gateway_selector field with Kubernetes-style label selectors.

API Changes

New Message

message GatewayReference {
  string name = 1;
  map<string, string> selector = 2;
}

Updated VirtualService

message VirtualService {
  repeated string hosts = 1;
  repeated string gateways = 2;
  repeated GatewayReference gateway_selector = 7;  // NEW
  repeated HTTPRoute http = 3;
  // ...
}

Examples

Select by labels

gateway_selector:
- selector:
    env: prod
    version: v1

Mix names and selectors

gateway_selector:
- name: "mesh"
- selector:
    env: prod

Benefits

• Update gateways without modifying VirtualServices
• Enable blue-green deployments via relabeling
• Support multi-environment routing
• Reduce configuration drift

Backward Compatibility

• Existing gateways field unchanged
• No breaking changes
• gateway_selector takes precedence if both specified

Files Changed

• networking/v1alpha3/virtual_service.proto
• Generated Go code and CRDs

Related Work

Requires implementation PR in istio/istio repository.

[istio-testing]

Hi @prashanthjos. Thanks for your PR.

I'm waiting for a github.com member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[istio-policy-bot]

🤔 🐛 You appear to be fixing a bug in Go code, yet your PR doesn't include updates to any test files. Did you forget to add a test?

Courtesy of your friendly test nag.

[prashanthjos]

@keithmattix, could you please let me know if there’s a specific reason the PR is labeled as do-not-merge/hold?

[howardjohn]

Thanks for the PR. I understand the motivations but I don't think this is a good fit for Istio's APIs. We are primarily focusing around Gateway API, which does not support such a selector. Additionally, adding a selector introduces pretty substantial runtime and cognitive complexities to the project.

[keithmattix]

+1 to @howardjohn I don't think it's a good fit from an API perspective, and I'm concerned about a malicious VirtualService creator can bind to a gateway with just labels and not explicitly (bypassing OPA or other admission control that may be watching the gateways: field)

[renatovassaomb]

@howardjohn @keithmattix Thank you for your replies. How would you recommend solving the mentioned problem (i.e. changing Gateways without changing VirtualServices) using the current APIs?

[howardjohn]

I would recommend changing the problem parameters to not require that you don't change the VirtualService

[renatovassaomb]

How would that be possible in the case where we're updating load balancers? Could we somehow change the backing LB for a Gateway?

We're thinking of implementing canary gateway upgrades.

[tvenegas10]

@keithmattix @howardjohn shouldn't there be a way of decoupling Gateways and VirtualServices? Because it does feel like Gateways are more at the platform management level and VirutalServices at the app management level. We could add admission control rules to watch for the selectors too.

[keithmattix]

@tvenegas10 you're 100% correct about the difference in roles here, but that's why we're pushing users who need that separation to Gateway API: https://gateway-api-inference-extension.sigs.k8s.io/.

[renatovassaomb]

@keithmattix I would gladly migrate to Gateway API if that would solve this problem for us, but my understanding is that this specific use case is not supported since kubernetes-sigs/gateway-api#594. Please correct me if I am wrong!

[keithmattix]

Ah I see that the explicit binding from HTTPRoute to Gateways is an issue as well (which makes sense; I read through the response too quickly). I would recommend commenting on that Gateway API issue and asking for it to be reopened as that would be the clearest way to get this sort of functionality into Istio