Istio

DocumentationIstio

About

It is an open source project that implements a Service Mesh to reduce distributed services management complexity, regardless of languages or tools that the services were developed on.

Istio is commonly runned over Kubernetes, but can also be implemented in Apache Mesos, Consul or Nomad.

Why use it?

Traffic Management

How should requests enter the ecosystem. (API Gateway)

Or how should services communicate with each other, considering they use many types of communications. (Like http, gRPC, Async messaging, etc)

Load balancing requests. (More advanced ways to balance than Kubernetes)

Request timeouts.

Retry policies.

Circuit Breaker.

Fault injection. (To simulate how services will react to errors from other service)

Observability

It can help with observability in the ecosystem, like metrics, distributed traces, logs.

Security

Facilitate security, encrypting communication between services.

Also with AAA, (Authentication, Authorization and Audit)

Architectures

Sidecar Mode

How can Istio, for instance, retry requests from one service to another without the services having code in them to handle this?

A proxy container is added to each Pod, and they intercept and handle all of the Traffic management of the Mesh. Meaning that they know would to do if the container that they are attached is down.

Usually in Kubernetes each Pod has only one container, which is the service running on it.

With Istio, now it should have 2 container, with the addition of the proxy container.

EVERY communication goes through the proxy container.

This also means that Proxies have access to ALL the data shared between service containers.

Control Plane

But must I configure each proxy container individually?

No, Istio has a Pod named istioD that is responsible for configurations, authentication and control of these proxy Pods. The configurations done to istioD are replicated to the Proxies.

istioD is Istio Daemon, which is a system that runs all the time controlling and adjusting configurations of all the proxy containers.

Ambient Mode

It uses a per-node Layer 4 proxy, and optionally a per-namespace Envoy proxy for Layer 7 features.

There is no longer an Envoy Proxy container along with each Pod.

Traffic Management

Gateway

Responsible for receiving/releasing connections from/to out of the cluster, managing ports, host and TLS.

Not responsible for:

• Routing connection to cluster nodes.

Similar to Kubernetes Ingress Gateway.

But it works over Layer 4-6.

It is directly connected to a Virtual Service.

Ingress

Manages traffic entry.

If accessing a cluster from the outside, always access through the Ingress Gateway, otherwise it will not use your Gateway rules.

Communications from inside the cluster will always use the routing rules, since the Proxies will make sure to use them.

Egress

Manages traffic exit.

Virtual Service

Responsible for routing the connections to destinations (Destination Rules).

It allows you to configure how requests will be routed to a service, with a bunch of rules that when applied will route the request to a specific destination.

A virtual service rules:

• Match urls: For routing requests.

• Retries: To set retry policies.

• Fault Injection: To simulate errors.

• Timeout: To set timeouts on requests.

• Subsets: To define Subsets.

Subsets

Subsets are Destination categories. (Like v1 and v2)

Where each category can be configured to reach a different Destination Rule.

Destination Rule

It allows you to configure what happens with traffic when it reaches a destination.

Destination Rules can:

• Create selectors to define the amount of the traffic it should be receiving. (Ex.: 30%)

• Setup different kinds of Load Balancers, even between Pods.

• Setup balancers based on locality.

• Setup Circuit Breakers.

Consistent Hash (Sticky Sessions)

So that load balancer may be able to route some clients always to the same Destination Rule.

May not work if destinations have weights.