Support VirtualService informer filtering to improve isolation

[anencore94]

Summary

When an external VirtualService with an invalid spec exists in the cluster, the net-istio-controller pod crashes with CrashLoopBackOff during informer sync. This happens because the VirtualService informer watches all VirtualServices cluster-wide, and a malformed VS can cause the informer's list/watch operation to fail during validation.

Problem

Root Cause

The VirtualService informer watches all VirtualServices in the cluster without filtering. When an invalid VS exists (e.g., created by another controller like Voyager), the informer fails to sync, causing the controller to crash.

Impact

• net-istio-controller pod enters CrashLoopBackOff
• Knative Service's VirtualService reconcile fails
• InferenceService (KServe) or Knative Services fail to become ready

Example Scenario

1. External application (e.g., Voyager forum) creates a VirtualService with invalid spec
2. net-istio-controller starts and attempts to sync VirtualService informer
3. Informer fails to list/watch due to invalid VS spec
4. Controller crashes before it can reconcile any Knative-owned VS

Proposed Solution (Not Fixed, Please feedback)

Add an opt-in environment variable ENABLE_VS_INFORMER_FILTERING_BY_LABEL that enables label-based filtering for the VirtualService informer.

When enabled, only VirtualServices with the networking.knative.dev/ingress label will be watched.

Key Points

• Opt-in approach: Default is false to maintain backward compatibility
• Follows existing pattern: Similar to ENABLE_SECRET_INFORMER_FILTERING_BY_CERT_UID for Secret filtering
• Label-based filtering: Uses networking.knative.dev/ingress label which is already present on Ingress-owned VirtualServices

Usage

Enable the feature by setting the environment variable:

env:
  - name: ENABLE_VS_INFORMER_FILTERING_BY_LABEL
    value: "true"

Verification

1. Set ENABLE_VS_INFORMER_FILTERING_BY_LABEL=true
2. Create an external VirtualService without the networking.knative.dev/ingress label
3. Verify net-istio-controller starts without crash
4. Deploy a Knative Service and verify VirtualService is created correctly
5. Check controller logs show no errors related to external VirtualService

[dprotaso]

and a malformed VS can cause the informer's list/watch operation to fail during validation.

@anencore94 this sounds like an Istio bug - have you filed one?

What Istio version are running? What version of Knative are you using?

[anencore94]

istio/pilot: 1.15.3-1
knative/serving : 1.10.2

Thanks @dprotaso. However, when I do kubectl get vs -A, it doesn't raise any error for validation, but I think the reason was here, since virtualserviceinformer "knative.dev/net-istio/pkg/client/istio/injection/informers/networking/v1beta1/virtualservice" raise these error.

Also, I don't think these net-istio must always list the whole virtualservices in the cluster! It could be optional.