WorkloadSelector in DestinationRule resulting in route error

[qts0312]

Is this the right place to submit this?

• This is not a security vulnerability or a crashing bug
• This is not a question about how to use Istio

Bug Description

My configuration below.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: vs-0
spec:
  hosts:
  - '*.example.com'
  http:
  - route:
    - destination:
        host: productpage.default.svc.cluster.local
        subset: v1
        port:
          number: 9080
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: dr-0
spec:
  host: productpage.default.svc.cluster.local
  subsets:
  - name: v1
    labels:
      version: v1
  workloadSelector:
    matchLabels:
      app: productpage
---
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: se-0
spec:
  hosts:
  - www.example.com
  ports:
  - number: 8080
    protocol: HTTP
    name: port-1
    targetPort: 9080
  resolution: DNS
---
apiVersion: v1
kind: Service
metadata:
  name: productpage
spec:
  selector:
    app: productpage
  ports:
  - port: 9080
    targetPort: 9080
    name: http-0

I tried curl -H"Host:www.example.com" http://1.1.1.1:8080/ and received 503. After I removed the workloadSelector in the DestinationRule, I tried again and received 200.

In my configuration, the workloadSelector in DestinationRule shouldn't affect the route correctness of curl -H"Host:www.example.com" http://1.1.1.1:8080/. So the behavior above is really confusing for me.

Version

$ istioctl version
client version: 1.20.0
control plane version: 1.20.0
data plane version: 1.20.0 (5 proxies)
$ kubectl version
Client Version: v1.28.2
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
Server Version: v1.27.3

Additional Information

No response

[ilrudie]

The workload selector in DestinationRule governs where the DestinationRule is applied (in your case it would be limited to only the sidecars for the productpage app) so its likely the traffic is going through a proxy that has no DestinationRule applied and your VirtualService consequently relies on a subset that isn't defined. When you remove the selector in your DestinationRule the subset can then be defined on all proxies and traffic flows as expected.

[qts0312]

https://istio.io/latest/docs/reference/config/networking/destination-rule/#DestinationRule
According to the documentation, the DestinationRule applies on the pods with label app: productpage, which means that the subset is defined on these pods instead of that only these pods can see the subset.
Besides, the workloadSelector in ServiceEntry doesn't cause other pods can't see the service. Why the workloadSelectors in DestinationRule and ServiceEntry make different effects?

[ilrudie]

"Criteria used to select the specific set of pods/VMs on which this DestinationRule configuration should be applied." (emphasis my own) ref

This is the specific verbiage on the field in DestinationRule. It's stating that the field is used to set where the DestinationRules configuration (in your case, the subset) should be applied. It goes on to mention one intended use case which I think helps to explain things:

"For example, if specific sidecars need to have egress TLS settings for services outside of the mesh, instead of every sidecar in the mesh needing to have the configuration (which is the default behaviour), a workload selector can be specified." ref

I can't speak to exactly why the same field name in different resources has a different effect/behavior but I see how this can be confusing and frustrating. I'd be happy to work with you to improve the clarity of the documentation if you'd like to get some commits in the Istio project or if you just want to leave some suggestions here I can see about updating the documentation myself..

[NaturezzZ]

Thank you @ilrudie. According to your description, WorkloadSelector in DestinationRule is to specify which pods (request sender) to apply the DR rule. But in ServiceEntry, it is used to specify the endpoints of service. That is to say, WorkloadSelector defines source in DR but destination in SE. It seems very interesting. Is there some special design inside?

[ilrudie]

Hi @NaturezzZ, I'm not sure I understand your question. You can look at the envoy config generated by Istio on any of the proxies to confirm whether or not the subset is being configured if that's what you're getting at but I suspect it's not.

[NaturezzZ]

Hi @ilrudie, I add some supplementary explanations in istio/api#3088. Would you mind take a look? Thank you.

[ilrudie]

Thanks for adding this @NaturezzZ, I left a few comments/suggestions on the wording of the note but it looks like it'll be a helpful clarification.

[NaturezzZ]

Thanks for polishing @ilrudie 🎉

[istio-policy-bot]

🚧 This issue or pull request has been closed due to not having had activity from an Istio team member since 2024-02-16. If you feel this issue or pull request deserves attention, please reopen the issue. Please see this wiki page for more information. Thank you for your contributions.

Created by the issue and PR lifecycle manager.