Istio is a service mesh that allows service mesh to extend on various platforms.

This allows service mesh to extend outside the standard service mesh we use on the Kubernetes. Istio introduces Virtualservice as an abstraction over existing services. It is intentionally mentioned so that it is not confused with the Kubernetes service.

Istio uses an envoy proxy as a sidecar container to implement service mesh.

Istio

Istio has many features. In this article, the focus will be on the service mesh and traffic management. To enable this Istio introduces the next concepts:

• Virtualservice
• Destination rules
• Ingress gateway
• Egress gateway

Virtualservice

Virtual services and destination rules are the key building blocks of Istio’s traffic routing functionality.

They let you define how traffic is routed to the services within the service mesh.

Virtual service lets you manage traffic based on the following parameters:

• Host
• The specific version of the service itself
• Different parameters like Header value

Also, it is possible to:

• Handle incoming traffic to the cluster via Ingress gateway (Instead of ingress controller)
• Handle traffic only inside the Kubernetes cluster

Destination rules

You can think of virtual services as how you route your traffic to a given destination, and then you use destination rules to configure what happens to traffic for that destination.

You use destination rules to specify named service subsets, such as grouping all a given service’s instances by version. You can then use these service subsets in the routing rules of virtual services to control the traffic to different instances of your services.

Ingress gateway

Ingress gateway exposes service mesh to the outside world. On the Kubernetes, it acts as an ingress controller since it uses an Ingress gateway from the Kubernetes.

Egress gateway

The Egress gateway is an outgoing point of the service mesh. It can be used to enforce policy for outgoing connections.

Example setup

Deploying istio

Istio already gives an example of a book review web. It consists of different microservices as a part of their tutorial.

We will assume the Kubernetes cluster is clear and ready to use. In this article, K3s is used. There are many articles about k3s on the qdnqn.

First, we need to install Istio and all add-ons.

helm repo add istio https://istio-release.storage.googleapis.com/charts
helm repo update
kubectl create namespace istio-system
helm install istio-base istio/base -n istio-system
helm install istio istio/istio -n istio-system
helm install istio-ingress istio/gateway -n istio-ingress

After this Istio service mesh is ready to be configured.

Deploying services

You can follow the tutorial directly on the link:

Bookinfo Application

Deploys a sample application composed of four separate microservices used to demonstrate various Istio features.

Istio7 minute read page test

Istio will inject a sidecar container in all namespaces labeled as below.

kubectl label namespace default istio-injection=enabled

To deploy the book info application apply resources from the official Istio repository.

kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.21/samples/bookinfo/platform/kube/bookinfo.yaml

Configuring VirtualService

Using the example given in the book info we can configure VirtualService in the next way:

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: bookinfo-gateway
  namespace: default
spec:
  # The selector matches the ingress gateway pod labels.
  selector:
    istio: ingressgateway # use istio default controller
  servers:
    - port:
        number: 80
        name: http
        protocol: HTTP
      hosts:
        - "istio.k3s.local"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: bookinfo
  namespace: default
spec:
  hosts:
    - "istio.k3s.local"
  gateways:
    - bookinfo-gateway
  http:
    - match:
        - uri:
            exact: /productpage
        - uri:
            prefix: /static
        - uri:
            exact: /login
        - uri:
            exact: /logout
        - uri:
            prefix: /api/v1/products
      route:
        - destination:
            host: productpage
            port:
              number: 9080

We need to point istio.k3s.local to the local IP of the local machine. Afterwards accessing the http://istio.k3s.local/ will resolve the book review front page.

How does Kubernetes service coexist with VirtualService?

As seen in the picture, both the Kubernetes service and VirtualService can coexist.

Traffic still can flow using service FQDN to get to the pod. On the other hand, the virtual channel is open for the mesh traffic. Traffic designated to the VirtualService will leave through the sidecar container and hit the sidecar container where VirtualService points.

That is valid fact if we assume the next scenario:

• Service 1: service1.ns1.svc.cluster.local
• Service 2: service2.ns2.svc.cluster.local

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: KubernetesInternalMeshVirtualService
  namespace: default
spec:
  hosts:
    - "service2.ns2.svc.cluster.local"
    - "service2.ns2"
  http:
    - route:
        - destination:
            host: service2.ns2
            port:
              number: 8080

VirtualService uses Kubernetes FQDN to solve endpoints but traffic is flowing through the mesh now. Now when the container from Pod 1 tries to reach service2.ns2 it will go through the mesh instead of the Kubernetes service.

What happens is that Istio will control the traffic, apply all rules, and policies, if defined on the VirtualService, then route the traffic to the Pod 2 via sidecar containers.

This way mesh will resolve internal Kubernetes services FQDN and route the traffic via mesh.

To confirm this behavior one can implement some delay on the VirtualService and send a request from Pod 1 to Pod 2.

What is the point of the service mesh?

Mesh also can be extended to be:

• Multi cluster aware
• Bare-metal/VM aware

So that requests can go out of the cluster and vice versa. This way we can create a logical group of services under one umbrella. It makes sense to create a service mesh when services are dispersed over various clusters and virtual machines.

Another great benefit is that you have complete control over the network with policies implemented on the VirtualService.

Istio ingress and egress concepts allows full control of in-and-out control of the traffic entering or leaving the mesh.

It is a fully featured product for service mesh with all the tools you need to manage networking on a scale. It is only intended to be used with Kubernetes as the main platform where support for the bare-metal/virtual machines is given as an option.