Is Istio doing the routing or is it another component? (k8s, ambassador)

Networking
1

So I have this setup:

apiVersion: v1
kind: Service
metadata:
  name: svc-telemetry
  annotations:
    getambassador.io/config: |
      ---
      apiVersion: ambassador/v1
      kind:  Mapping
      name:  svc-telemetry-mapping-1
      prefix: /svc-telemetry/
      service: svc-telemetry.data-dev
spec:
  selector:
    app: svc-telemetry
  ports:
  - port: 80
    name: http
    targetPort: http
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: svc-telemetry-1
spec:
  replicas: 1
  strategy:
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: svc-telemetry
        version: v1
    spec:
      containers:
      - name: svc-telemetry-1
        image:<my_image-1>
        ports:
        - name: http
          containerPort: 8083
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: svc-telemetry-2
spec:
  replicas: 1
  strategy:
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: svc-telemetry
        version: v2
    spec:
      containers:
      - name: svc-telemetry-2
        image: <my-image-2>
        ports:
        - name: http
          containerPort: 8083

Then I added DestinationRules, a VirtualService and then a Gateway. I then started seeing traffic flowing to v1 and v2 which got me really happy. As I started playing with different routing rules in the VirtualService I wasn’t seeing the expected results (i.e a 90/10 split) so that got me thinking that maybe Istio was not the one calling the shots for that routing. Next, I deleted all Istio components and got to see the same result.

How can I find out who is doing the routing or how can I find out if Istio is part of it in any way?

Any help would be greatly appreciated as I hit this wall last Tuesday.

Thanks beforehand!!

2

When addressing the request to a (ClusterIP) service, the ‘service itself’ loadbalances the requests. See https://kubernetes.io/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies

3

That’s not entirely accurate - Istio intercepts the VIP and does it’s own routing and load balancing.

k8s load balancing and routing are only used if traffic is exluded from interception.

4

Well, in this case I don’t think Istio is doing the routing. I created a virtualservice where I’m injecting an HTTP fault just to test if it was active but unfortunately none of the 500 calls in my test suite showed that error.

Are there any logs where I can inspect this?

5

You can enable debug logging in the sidecar - it’s a good way to find many possible issues.
The access logs in envoy or envoy stats are quick way to get basic info.

6

Just to be sure, you are talking about doing something like:
kubectl logs -c istio-proxy

7

In my infra, ambassador is the ingressgateway so should I have somthing like this in my virtualservice?

 apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: svc-telemetry-vs
spec:
  hosts:
  - "*"
  gateways:
  - ambassador
  name: svc-telemetry
  http:
  - route:
    - destination:
        host: svc-telemetry
        subset: v1
      weight: 90
    - destination:
        host: svc-telemetry
        subset: v2
      weight: 10
8

Yes, maybe you are running into this problem? https://istio.io/help/ops/traffic-management/troubleshooting/#route-rules-have-no-effect-on-ingress-gateway-requests