Istio and (or versus) Nginx Ingress Controller

Question

I'am on a journey of testing Istio and at the moment I'am about to test the "canary" capabilities of routing traffic.

For my test, I created a small servicemesh composed of 5 microservices (serviceA, serviceB, serviceC, serviceD, serviceE). Each one is able to call the others. I just pass a path like A,E,C,B,B,D and the request follows this path. In order to call my servicemesh from outside the cluster I have an Nginx Ingress Controller with an Ingress rule that point on serviceA pod

This is working fine.

The problem I'am facing concerns the traffic switching using a custom header matching like this :

kind: VirtualService
metadata:
  name: ServiceA
  namespace: demo
  labels:
    app: demo
spec:
  hosts:
  - service-a
  http:
  - route:
    - destination:
        host: service-a
        subset: v1
  - match:
    - headers:
        x-internal-request:
          exact: true
    route:
    - destination:
        host: service-a
        subset: v2

So here, I want to try to route the traffic to the v2 version of ServiceA when I have the custom header x-internal-request set to true.

Questions :

• In order to use this feature, do my services have to be aware of the x-internal-header and do they have to pass it to the next service in the request? Or they do not need to deal with it because Istio do the job for them ?

• In order to use this feature, do I need to use the Istio Ingress Controller (with an Istio Gateway) instead of the Nginx Ingress Controller ?

Today, I am using Nginx Ingress Controller to expose some of my services. We choose Nginx because it has some feature likes "external authorization" that saves us a lot of work and if we need to use Istio Ingress controller instead, I'am not sure it offers the same features than Nginx.

Perhaps there is a middle path I do not see

Thank you for your help

Answer 1

Istio is designed to use Envoy deployed on each Pod as sidecars to intercept and proxy network traffic between microservices in service mesh.

You can manipulate with HTTP headers for requests and responses via Envoy as well. According to the official Documentation, custom headers can be added to the request/response in the following order: weighted cluster level headers, route level headers, virtual host level headers and finally global level headers. Because your Envoy proxies are deployed on each relevant service Pod as sidecar, custom HTTP header should pass to each request or response.

I would recommend using Istio Ingress Controller with its core component Istio Gateway which is commonly used for enabling monitoring and routing rules features in Istio mesh services.

There was an issue opened on GitHub about the implementation of Nginx Ingress controller in mesh services and the problem with routing requests.