istio gateway api traffic shifting example - how we can shift traffic based on weight


 

Let's setup the book info application by running 

kubectl apply -f samples/bookinfo/platform/kube/bookinfo.yaml

And then setup the gateway and default http route below:-


apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: bookinfo-gateway
spec:
  gatewayClassName: istio
  listeners:
  - name: http
    port: 80
    protocol: HTTP
    allowedRoutes:
      namespaces:
        from: Same
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: bookinfo
spec:
  parentRefs:
  - name: bookinfo-gateway
  rules:
  - matches:
    - path:
        type: Exact
        value: /productpage
    - path:
        type: PathPrefix
        value: /static
    - path:
        type: Exact
        value: /login
    - path:
        type: Exact
        value: /logout
    - path:
        type: PathPrefix
        value: /api/v1/products
    backendRefs:
    - name: productpage
      port: 9080

You should have your product page up and running by hitting localhost/productpage

Notice we have the following pod


To route traffic by weight or percentage, we need to version our services using yaml below. 

apiVersion: v1
kind: Service
metadata:
  name: reviews-v1
spec:
  ports:
  - port: 9080
    name: http
  selector:
    app: reviews
    version: v1
---
apiVersion: v1
kind: Service
metadata:
  name: reviews-v2
spec:
  ports:
  - port: 9080
    name: http
  selector:
    app: reviews
    version: v2
---
apiVersion: v1
kind: Service
metadata:
  name: reviews-v3
spec:
  ports:
  - port: 9080
    name: http
  selector:
    app: reviews
    version: v3
---
apiVersion: v1
kind: Service
metadata:
  name: productpage-v1
spec:
  ports:
  - port: 9080
    name: http
  selector:
    app: productpage
    version: v1
---
apiVersion: v1
kind: Service
metadata:
  name: ratings-v1
spec:
  ports:
  - port: 9080
    name: http
  selector:
    app: ratings
    version: v1
---
apiVersion: v1
kind: Service
metadata:
  name: details-v1
spec:
  ports:
  - port: 9080
    name: http
  selector:
    app: details
    version: v1
---apiVersion: v1
kind: Service
metadata:
  name: reviews-v1
spec:
  ports:
  - port: 9080
    name: http
  selector:
    app: reviews
    version: v1
---
apiVersion: v1
kind: Service
metadata:
  name: reviews-v2
spec:
  ports:
  - port: 9080
    name: http
  selector:
    app: reviews
    version: v2
---
apiVersion: v1
kind: Service
metadata:
  name: reviews-v3
spec:
  ports:
  - port: 9080
    name: http
  selector:
    app: reviews
    version: v3
---
apiVersion: v1
kind: Service
metadata:
  name: productpage-v1
spec:
  ports:
  - port: 9080
    name: http
  selector:
    app: productpage
    version: v1
---
apiVersion: v1
kind: Service
metadata:
  name: ratings-v1
spec:
  ports:
  - port: 9080
    name: http
  selector:
    app: ratings
    version: v1
---
apiVersion: v1
kind: Service
metadata:
  name: details-v1
spec:
  ports:
  - port: 9080
    name: http
  selector:
    app: details
    version: v1
---

And then we can simply distribute traffic route 90 percent to reviews-v3 and 10 percent to reviews-v1.


apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: reviews
spec:
  parentRefs:
  - group: ""
    kind: Service
    name: reviews # <--- setup up route for service called reviews on port 9080
    port: 9080
  rules:
  - backendRefs: # <---- splits traffic 90 / 10
    - name: reviews-v1
      port: 9080
      weight: 10
    - name: reviews-v3
      port: 9080
      weight: 90

Given the yaml above, you will notice that we don't have gateway attached to it. This means it is a service-to-service connection. 

So the keypoint her is to define service level versions for reviews and then define the proper httproute. 

Some side notes: 

You will notice that we didn't inject our namespace with istio. So that means there's no side car - as you can see here:- 


And if you run this command here 

istioctl experimental describe pod serverb-6b965b6cc5-kjvm6.tenant-b



Also means you get some error when trying to run istioctl proxy status on a pod - which make sense because we don't have side car injection and envoy proxy going in there.


 


Comments

Popular posts from this blog

mongosh install properly

gemini cli getting file not defined error

vllm : Failed to infer device type