K
Q

How can istio mesh-virtual-service manage traffic from ingress-virtual-service?

4/18/2021

I am defining canary routes in mesh-virtual-service and wondering whether I can make it applicable for ingress traffic (with ingress-virtual-service) as well. With something like below, but it does not work (all traffic from ingress is going to non-canary version)

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: test-deployment-app
  namespace: test-ns
spec:
  gateways:
  - mesh 
  hosts:
  - test-deployment-app.test-ns.svc.cluster.local
  http:
  - name: canary
    match:
    - headers:
        x-canary:
          exact: "true"
    - port: 8080
    headers:
      response:
        set:
          x-canary: "true"
    route:
    - destination:
        host: test-deployment-app-canary.test-ns.svc.cluster.local
        port:
          number: 8080
      weight: 100
  - name: stable
    route:
    - destination:
        host: test-deployment-app.test-ns.svc.cluster.local
        port:
          number: 8080
      weight: 100
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: test-deployment-app-internal
  namespace: test-ns
spec:
  gateways:
  - istio-system/default-gateway
  hosts:
  - myapp.dev.bla
  http:
  - name: default
    route:
    - destination:
        host: test-deployment-app.test-ns.svc.cluster.local
        port:
          number: 8080
      weight: 100

So I am expecting x-canary:true response header when I call myapp.dev.bla but I don't see that.

-- Kumar Gaurav
istio
istio-gateway
kubernetes

Similar Questions

Cilium pods pending using kuberspay
Scale up and Scale down in containers
KubeletNotReady - Failed to initialize CSINodeInfo
RBAC for kubectl and helm
How to bind a PVC with worker pod in airflow when using kubernetes executor?

1 Answer

4/18/2021

Well the answer is only partially inside the link you included. I think the essential thing to realize when working with Istio 'what even is Istio Service Mesh'. Service mesh is every pod with Istio envoy-proxy sidecar + all the gateways (gateway is standalone envoy-proxy). They all know about each other because of IstioD so they can cooperate.

Any pod without Istio sidecar (including ingress pods or i.e. kube-system pods) in your k8s cluster doesn't know anything about Istio or Service Mesh. If such pod wants to send traffic to Service Mesh (to apply some Traffic Management rules like you have) must send it through Istio Gateway. Gateway is object that creates standard deployment + service. Pods in the deployment consist standalone envoy-proxy container.

Gateway object is a very similar concept to k8s ingress. But it doesn't have to listen on nodePort necessarily. You can use it also as an 'internal' gateway. Gateway serves as entry point into your service mesh. Either for external or even internal traffic.

  1. If you're using i.e. Nginx as the Ingress solution you must reconfigure the Ingress rule to send traffic to one of the gateways instead of the target service. Most likely to your mesh gateway. It's nothing else than k8s Service inside istio-gateway or istio-system namespace
  2. Alternatively you can configure Istio Gateway as 'new' Ingress. As I'm not sure if some default Istio Gateway listens on nodePort you need to check it (again in istio-gateway or istio-system namespace. Alternatively you can create new Gateway just for your application and apply VirtualService to the new gateway as well.
-- Ondrej Bardon
Source: StackOverflow