One of the key functionalities of microservices is their ability to decouple configurations. For instance, whenever a change happens, Kubernetes' primitive ConfigMap configurations are decoupled from the application and pushed down to the application by Kubernetes. Istio provides a much more powerful capability to decouple traffic routing that's independent of the application code.

Traffic management in Istio is decoupled from the application. This is possible due to the language-agnostic Envoy sidecar that sits with the microservice. The rules are defined in Pilot, and these are independent of the pod. This helps us to decouple traffic, independent of the replica sets' deployment. For instance, regardless of the number of replicas in a canary deployment, it is only possible to shift 10% of the live traffic to it.

Pilot plays an important role in managing and configuring all of the proxy sidecars within a service mesh. Pilot lets you define the rules that are then pushed down to the proxy sidecars to route traffic between proxies and configure various features such as timeouts, retries, and circuit breakers. Load balancing is done in an intelligent fashion based on the health of other proxies in the load balancing pool. Pilot enables service discovery, dynamic updates to load balancing pools, and routing tables.

Istio provides a gateway for managing incoming and outgoing traffic through Ingress and Egress gateways. These gateways sit on the periphery of the service mesh, which is the data plane running the microservices application:

The preceding diagram shows the Istio components and the service mesh encompassing services running in the data plane. The incoming traffic arrives at the Ingress gateway, which has its own sidecar proxy that receives its configuration from Pilot. Through the definition of the gateway that's defined, the incoming traffic from a host can be mapped to a service running inside the Kubernetes cluster. If a microservice needs to establish a connection to the outside world, the Egress gateway, which sits on the edge of the proxy mesh, can be configured to originate TLS or rules and can be configured to control access.

Within Istio, there are many traffic rules that can be managed and maintained within the configuration model for controlling API calls and traffic flows across various microservices.

The configuration model allows operators to configure service-level properties such as circuit breakers, timeouts, and retries, load balancing, and many more testing and monitoring capabilities.

Istio provides three routing primitives, as follows:

• Gateway
• Virtual service
• Destination rules

Now, let's understand these routing primitives one by one.