Enabling automatic sidecar injection – Implementing Traffic Management, Security, and Observability with Istio-2

When we define an Istio gateway, we also need to define a VirtualService resource that uses the gateway and describes the routing rules for the traffic. Without aVirtualService resource, the Istio gateway will not know where and how to route the traffic it receives. AVirtualService resource is not only used for routing traffic from gateways but also for routing traffic within different services of the mesh. It allows you to define sophisticated routing rules, including traffic splitting, retries, timeouts, and more. Virtual services are often associated with specific services or workloads and determine how traffic should be routed to them. You can use virtual services to control how traffic is distributed among different versions of a service, enabling practices such as A/B testing, canary deployments, and Blue/Green deployments. Virtual services can also route traffic based on HTTP headers, paths, or other request attributes. In the current context, we will use the VirtualService resource to filter traffic based on paths and route them all to thefrontend microservice.

Let’s look at the definition of the Gateway resource first:
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: blog-app-gateway
namespace: blog-app
spec:
selector:
istio: ingress
servers:
port: number: 80 name: http
protocol: HTTP
hosts:
“*”

As we can see, we define a Gateway resource that uses the Istio ingress gateway (defined by the istio: ingress selector) and listens on HTTP port 80. It allows connection to all hosts as we’ve set that to ““. For gateways to work correctly, we need to define a VirtualService resource. Let’s look at that next: apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: blog-app namespace: blog-app spec: hosts: ““
gateways:
blog-app-gateway http:
match:
uri: exact: /
uri:
prefix: /static
uri:
prefix: /posts
uri:
exact: /login
uri:
exact: /logout
uri:
exact: /register
uri:
exact: /updateprofile
route:
destination: host: frontend port:
number: 80

The VirtualService resource listens on all hosts and applies to blog-app-gateway as specified. It allows /static, and /posts as a prefix match. This means all requests with a URI that begins with them would be routed. The /login, /logout, /register, /updateprofile, and / paths have an exact match, which means that the exact URI is matched and allowed. These are routed to the frontend service on port 80.

We must also modify the frontend service within the blog-app.yaml file to change the service type to ClusterIP. This will remove the attached load balancer from the service, and all requests will be routed via the ingress gateway.

Now, let’s go ahead and apply these changes using the following commands:
$ cd ~/mdo-environments
$ cp ~/modern-devops/ch15/istio-ingressgateway/gateway.yaml \ manifests/blog-app/gateway.yaml
$ cp ~/modern-devops/ch15/istio-ingressgateway/blog-app.yaml \ manifests/blog-app/blog-app.yaml $ git add –all
$ git commit -m “Added gateway”
$ git push

We will wait 5 minutes for the sync to work, after which we can go to http:// to access our Blog App. You should see the following page. This shows that the application is working correctly:

Figure 15.5 – Blog App – home page

You can play around with the application by registering, logging in, creating a post, and writing a review. Try updating the post and reviews to see whether all aspects of the application are working. Now, let’s look at the security aspects of our microservices.