Introduction to service mesh — istio

In modern era where containers and micro-services are becoming the reality, they also have an overhead of managing the common functionalities like inter service communications spanning between java, node, python / go-lang with diff communication protocols (REST/ gRPCs), mTLS, service discovery, Load-Balancers, etc. The maintenance can be heavily felt for franchise-critical applications where the there are 20+ µservices running with 10’s of pods in each service and every transaction is important for the business.

Service mesh simply abstracts all the common functions out of the µservices’ and helps developers to just focus on the core business logic. Service mesh can take care of the optics part for Production grade applications like — discovery, load balancing, failure recovery, metrics, and monitoring. It can also perform more funky things like A/B or canary deployments , rate limiting end-to-end authentication (mTLS). Some Popular service mesh are linkerd, istio, Consul.

The popularity of istio is mainly from the fact that it’s developed by Google, IBM & Lyft. Also, it’s predominantly preferred on Kubernetes as a sidecar pattern. Most common design for service mesh is the side-car one; as well spring-cloud provides alternate flavours.

Lemme try to explain in simple terms without too much of jargons

Istio is divided into 2 main components:

Control plane: responsible for all the routing, proxies to routes; They also collect data for mesh traffic analysis.

Service plane: responsible for injecting sidecar proxy to the pods and managing the service-to-service communications.

In developer terms, a light weight sidecar proxy (Envoy proxy) container is appended to the app container, which handles all the traffic for and between the pods. And ingress gateway manages all the traffic to the application services.

What does istio offer ??

Traffic management:

Virtual services, Gateways, mainly help to map the API end points to services.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews   # kube service to route to (can be IP/FQDN as well)
  http:
  - match:
    - headers:
        end-user:
          exact: jason

Gateway helps to configure the external route

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: ext-host-gwy
spec:
  selector:
    app: my-gateway-controller
  servers:
  - port:
      number: 443
      name: https
      protocol: HTTPS
    hosts:
    - ext-host.example.com
    tls:
      mode: SIMPLE    # public and private key for HTTPS connection 
      serverCertificate: /tmp/tls.crt
      privateKey: /tmp/tls.key

Security

It’s packed with the most versatile security for different platforms — AWS IAM, GCP service account, Kubernetes service account.

For Authentication

peer-to-peer Auth: mTLS (2 way SSL). STRICT/PERMISSIVE/DISABLE

Request Auth: JSON Web tokens and common Open ID providers (Auth0, FireBase, GoogleAuth etc.).

Observability

Telemetry collected by istio can be used to analysis the application behaviour, debug & optimize the service calls.

Metrics: proxy-level, service-level & control panel metrics are collected.

Access Logs: Istio generates full record of each request which can be used for analysis

Distributed Tracing: Monitoring individual requests, latency with each service throughout the mesh. Istio is compatible to be plugged for distributed tracing with popular backend tools like Zipkin, Kiali, Jaeger.

Reference: https://istio.io/latest/docs

To be continued…