4

I can't use Kubernetes service as I need retry VirtualService feature. How can I access VirtualService from the pods?

If I use VirtualService through Gateway: Pod -> Kubernetes service -> Istio Gateway -> Virtual service then for some reason locality balancing feature not working.

Jonas
  • 4,683
  • 4
  • 45
  • 81
  • What platform/infastructure are you using? Please provide your config files - virtualservice definition, gateway etc. – Malgorzata Jan 08 '21 at 16:58

1 Answers1

2

I am guessing you have something like this:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: review-external
spec:
  hosts:
  - "*.example.com"
  gateways:
  - mygateway
  http:
    route:
    - destination:
        host: reviews.prod.svc.cluster.local
        subset: v2
      weight: 25

In that case you can use the gateways list in the VirtualService object for that.

For Docs:

When this field is omitted, the default gateway (mesh) will be used, which would apply the rule to all sidecars in the mesh. If a list of gateway names is provided, the rules will apply only to the gateways. To apply the rules to both gateways and sidecars, specify mesh as one of the gateway names.

Source: https://istio.io/latest/zh/docs/reference/config/networking/virtual-service/#VirtualService

So you have two options here. You can either mention mesh as one of the gateways:

[...]
  gateways:
  - mygateway
  - mesh
  http:
[...]

Or you could create a second VirtualService without the gateways list so it defaults to mesh (or mention only the mesh as gateway if you want to be declarative). The spec.hosts field must contain the host, that is mentioned in the destination.host.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: review-mesh-internal
spec:
  hosts:
  - "reviews.prod.svc.cluster.local" # must be the kubernetes service host as below
  gateways:
  - mesh #optional since it's the default
  http:
    route:
    - destination:
        host: reviews.prod.svc.cluster.local
        subset: v1
      weight: 100

This brings the advantage, that you can route the traffic from outside the cluster differently than from inside the cluster. Think about maintenance for example, where user traffic should not reach a specific pod but traffic from inside the cluster should still be able to.

Chris
  • 5,109
  • 3
  • 19
  • 40
  • I have tried this and locality balancing is not preserved. Did you try using pod to pod communication with the locality? If you have tried and it is working "by design" I will create a simplified example of my configuration, maybe I am missing something. Thank you for the detailed answer. – Jonas Jan 10 '21 at 07:03
  • I am using this for pod to pod communication with two vs to handle traffic inside the cluster differently, but my use case does not need loadbalancing. You can add a header to the request by the vs to confirm that it is used. – Chris Jan 10 '21 at 17:41