Istio Architecture: Istio service mesh commonly comprises of two planes: a control plane and data plane The data plane is implemented in such a way that it intercepts all inbound and outbound traffic for all services (network traffic). Control plane enable Secure access and communications between services in a policy-driven way.

Refer the previous post for  Istio Service mesh Introduction

Istio is an implementation of a service mesh. It is an open service platform to manage inbound/outbound service interaction across containers, make it easier to connect, manage and secure traffic between, and obtain telemetry about microservices running in containers and VM based workloads efficiently.

In this article, we are going to look into the Istio architecture and request the flow of a packet. The infographic which is attached in the header is logically split into data plane and the bottom is called the control plane.

Data plane

The data plane is implemented in such a way that it intercepts all inbound and outbound traffic for all services (network traffic) and lets you create a network of deployed services with load-balancing, service-to-service authentication, authorization, health checking, and more without requiring to change the business logic, service code or your microservice.

Control Plane

Control planes enable Secure access and communications between services in a policy-driven way. Meaning that it provides policies and configuration for services in the mesh and it does not touch any packets/request in the data path and it has complete visibility into everything happening with your service with minimal instrumentation.

Let’s take a quick look @ Istio architecture components.

Pilot

Pilot is the captain of the ship. Handles configuration and programming of the envoy proxy sidecars, and service discovery.

Basically it configures and manages all the envoy proxies and it is going to do load balancing, service discovery, traffic routing (for example, A / B tests, canary deployments) and fault tolerance (timeouts, retries, circuit breakers);

Below are some of the pilot responsibilities

Observe the service topology.
Convert istio api resources in to envoy config.
Pushes envoy config to the sidecar proxies.
Envoy sidecars hot-reload with no downtime.
Request routing
Fault injection
Traffic shifting
Request timeouts
Circuit breaking
Mirroring

Mixer

Mixer component is a little special; it is halfway piece between the control plane and data plane. When the envoy got the request it is going to intercept and ask the mixer whether this call is allowed or not.

After envoy finished processing it will take raw metadata of the request and push it to Mixer to generate the telemetry data from Envoy proxy server and other services;

Also, it provides access control and usage policies for the network of services and collects telemetry data from the Envoy proxy server and other services;

Citadel

Provides keys & certificates to enable a secure connection between services. Example: Say for example if you have Front End talking with Business logic, we can apply a style of policy where we can restrict Front End with Database.

It also provides strong service-to-service and end-user authentication using mutual Transport Layer Security (mTLS). Citadel encryption configuration will be pushed to Envoy by the pilot.

Galley

Its core responsibility is to distribute the configuration’s input to other Istio components. Meaning that you write an Istio configuration, it will go to galley and Galley stores the user configuration and then sends/push it to pilot for further action.

Envoy

Network proxy to intercept communication and apply policies.

Traffic management in Istio

Traffic is classified as data plane traffic and control plane traffic in Isito. Data plane traffic refers to inbound and outbound cluster network traffic. Control plane traffic refers to configuration and control messages sent between Istio components to program the behavior of the mesh. So traffic management in Istio refers exclusively to data plane traffic.

Data Plane: HTTP/TCP routing features

Gateway

The Istio Gateway service is a load balancer that will enable HTTP(S) traffic to your cluster. It will sit at the entry of the service mesh and listen to the external connection which will allow the external traffic into the mesh.

It will have details like i) Hostnames that will route to services. ii) Serve certificates for those hostnames. iii) Port details.

The call from Gateway load balancer will be intercepted by the Istio object “Gateway” pod which is an envoy proxy (yes you are reading it correctly; Envoy acts as a sidecar and as well as Gateway pod). The call from Gateway will be redirected to the destination service based on the “VirtualService” routing configuration.

A snippet of Gateway YAML:

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: hellowworld-gateway-1
  namespace: hello-world-ui
spec:
  selector:
    istio: ingressgateway # use istio default ingress gateway
  servers:
    - port:
        number: 443
        name: HTTP
        protocol: HTTPS
      tls:
        mode: SIMPLE # enables HTTPS on this port
        serverCertificate: /etc/certs/servercert.pem
        privateKey: /etc/certs/privatekey.pem
      hosts:
        - "helloworld.example.com"

Virtual Service

VirtualServices configure how traffic flows to a service by defining a set of traffic rules for routing Envoy traffic inside service mesh. The traffic rules define what criteria to match before applying the rules on the call.

In the below snippet, Virtual Service routes all HTTP(s) traffic by default to pods of the productpage service with label “version: v1”. In addition, HTTPs request with a path starting with/productpage or /api/v1/productswill be rewritten to /newcatalog and sent to pods with label “version: v1”.

A snippet of Virtual Service YAML

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: hellow-world-virtualservice
  namespace: hello-world-ui
spec:
  hosts:
    - "helloworld.example.com"
  gateways:
    - helloworld-gateway-1
  http:
  - name: "ProductPage-v1-routes"
    - match:
        - uri:
            exact: /productpage
        - uri:
            prefix: /api/v1/products
        rewrite:
          uri: "/newcatalog"
        route:
        - destination:
            host: productpage
            subset: v1
  - name: "ProductPage-v2-routes"
      route:
      - destination:
          host: productpage
          subset: v2

DestinationRule

DestinationRule(Optional) will come in to play when routing is done to your application service subsets v1 and v2. Say if you are introducing a new version of service or patch fixes to production, it is often desirable to move a controlled percentage of user traffic to a newer version of service in the process of phasing out the older version (Canary deployment). Basically it covers the basic configuration for load balancing, connection pool, circuit breaker, etc.

A snippet of DestinationRule YAML:

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: hellowworld-DestinationRule
spec:
  host: "helloworld.example.com"
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

Service Entry

If you want to call external services outside your service mesh, We have to create a service entry configuration for externally running business components/ down streams.

A snippet of Service Entry YAML:

apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: external-svc-https
spec:
  hosts:
  - api.dropboxapi.com
  - www.googleapis.com
  - api.facebook.com
  location: MESH_EXTERNAL
  ports:
  - number: 443
    name: https
    protocol: TLS
  resolution: DNS

Control Plane Traffic

Control planes provide a single point of administration for service proxies and it will not directly touch any network packets in the mesh and operate out of the band. Following is the quick walkthrough on request flow in Istio.

Service A comes up
Service A comes up and Client-Side Envoy is deployed and in turn fetches configuration policy, routing, service information from Pilot. If the case Citadel is being used, TLS certs are securely distributed as well.
Service A places a call to service B
Client-side Envoy will inspect the request call and make a client-side load balancing based on following protocol HTTP (it uses Host Header), TCP (it uses Ip address), TLS ( it uses SNI). There are a bunch of different mechanisms to intercept the traffic and by default, Ip tables are used to capture the traffic in Isito.
Client Side envoy forwards request to Service B
Client-side envoy forwards requests to the appropriate instance of service B. There, the Server-side Envoy proxy which is deployed with service B will intercept the Client-side envoy call.
Server Side Envoy policy checks
Before the Service side envoy forwards the request to B, It will check with the Mixer component with appropriate adaptors (policy engine, quota adaptor) to validate whether the call will proceed or stop. The mixer will send results in the form of boolean value (true/false) to Server-side Envoy. Let’s assume that mixer returns as true, In that case Envoy will forward the request to the service B.
Server Side Envoy forwards req to Service B
Once the request received by Service B Server-side Envoy, It will forward the request to service B which will in turn process and return the response.
Server side Envoy forwards response to client side envoy
Server-side Envoy (Service B) forwards the response to the original caller, where the response is intercepted by client-side Envoy (service A) on the caller side. Client-side Envoy relays telemetry to Mixer, which in turn notifies appropriate plugins.
Client Side Envoy forwards response to Service A
Client-side Envoy forwards the response to the original caller (Service A) and relays telemetry to Mixer, which in turn notifies appropriate plugins.

Summing-up

Enabling Istio with an additional bunch of containers used to extend the Kubernetes functionality by having good visibility on what you have deployed and much more. From my perspective, Istio is not about weight-based routing or canary based deployments….etc. It is more about mutual TLS encryption from pod to pod because to achieve encryption & certificate management in microservices without Istio will add more operational overhead.

For successful Mesh Implementation:

Adopt the technology that solves specific pain points that solves today.
For most of the companies observability, security is the major problem. Mesh will be the perfect solution to start addressing one by one.
Always Focus on one specific pain point and use mesh to solve the problem.
Don’t adopt service mesh or any other new technology because it is a cool thing; If you don’t have the exact scenario; don’t use it for the sake of using it. You are very likely to fail and create complexity.

That’s all about mesh architecture. Refer mesh for more details Good day 🙂

Leave a Comment Cancel Reply

Sign up for my newsletter