# Istio

{% embed url="<https://istio.io/latest/docs/>" %}

## 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](https://app.gitbook.com/o/q7UfRHZ2kCFTwrialwS5/s/cYwIfPqe2ekSEqpmZWXe/ "mention"))

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

L**oad 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](https://istio.io/latest/docs/overview/dataplane-modes/)

### 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.

{% hint style="info" %}
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.
{% endhint %}

<img src="https://3516386803-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHUjPeBwVuSs2hnLSDDvk%2Fuploads%2FsmFGe0l0GIsJfeJEKGSi%2Ffile.excalidraw.svg?alt=media&#x26;token=606b7630-e9df-4d31-b9f1-62eec3ad26c0" alt="" class="gitbook-drawing">

{% hint style="warning" %}
EVERY communication goes through the `proxy` container.

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

#### 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.

{% hint style="info" %}
`istioD` is Istio Daemon, which is a system that runs all the time controlling and adjusting configurations of all the `proxy` containers.
{% endhint %}

### 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

<img src="https://3516386803-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHUjPeBwVuSs2hnLSDDvk%2Fuploads%2FZWjYBUGcTSwUjKkjpFPg%2Ffile.excalidraw.svg?alt=media&#x26;token=36787901-a1ed-4243-80d2-a5677b47f048" alt="" class="gitbook-drawing">

### [Gateway](https://istio.io/latest/docs/concepts/traffic-management/#gateways)

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

{% hint style="danger" %}
Not responsible for:

* Routing connection to cluster nodes.
  {% endhint %}

{% hint style="info" %}
*Similar to Kubernetes Ingress Gateway.*

But it works over Layer 4-6.
{% endhint %}

It is directly connected to a [#virtual-service](#virtual-service "mention").

#### Ingress

Manages traffic entry.

{% hint style="warning" %}
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.
{% endhint %}

#### Egress

Manages traffic exit.

### [Virtual Service](https://istio.io/latest/docs/concepts/traffic-management/#virtual-services)

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.

{% hint style="success" %}
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`.
  {% endhint %}

#### Subsets

Subsets are Destination categories. (Like `v1` and `v2`)

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

### [Destination Rule](https://istio.io/latest/docs/concepts/traffic-management/#destination-rules)

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

{% hint style="success" %}
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`.
  {% endhint %}

#### Consistent Hash (Sticky Sessions)

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

{% hint style="warning" %}
May not work if destinations have weights.
{% endhint %}