Envoy proxies – Implementing Traffic Management, Security, and Observability with Istio

Envoy proxies play a pivotal role in enabling various aspects of your service mesh. These Layer 7 proxies are uniquely capable of making crucial decisions based on the content of the messages they

handle, and they are the sole components that directly interact with your business traffic. Here’s how these envoy proxies contribute to the functionality of Istio:

• Traffic control: They provide fine-grained control over how traffic flows within yourservice mesh, allowing you to define routing rules for various types of traffic, includingHTTP, TCP, WebSockets, and gRPC.

• Security and authentication: Envoy proxies enforce identity and access management, ensuring that only authorized pods can interact with one another. They implement mutual TLS and traffic encryption to prevent man-in-the-middle attacks and offer features such as rate limiting to safeguard against runaway costs and denial-of-service attacks.

• Network resiliency: They enhance network resiliency by supporting features such as retries, failover, circuit breaking, and fault injection to maintain the reliability and robustness of your services.

Next, let’s look at Ingress and egress gateways.

Ingress and egress gateways

In Istio, ingress is a collection of one or more envoy proxies, which Pilot dynamically configures upon their deployment. These envoy proxies are crucial in controlling and routing incoming external traffic into your service mesh, ensuring that it is appropriately directed to the relevant services based on defined routing rules and policies. This dynamic configuration allows Istio to effectively manage and secure external traffic flows without requiring extensive manual intervention, ensuring that your applications can operate efficiently and securely within the service mesh.

Egress gateways are similar to ingress gateways but they work on outgoing traffic instead. To understand this better, let’s use Figure 15.3 as a reference and understand the traffic flow through Service A and Service B.

In this architecture, traffic within the service mesh follows a structured path through Ingress, microservices (Service A and Service B), and Egress, ensuring efficient routing and security measures. Let’s break down the flow of a traffic packet through your service mesh.

Ingress

Traffic enters theservice mesh through an ingress resource, which is essentially a cluster of envoy proxies. Pilot configures these envoy proxies upon deployment. Ingress proxies are aware of their backends due to configurations based on Kubernetes service endpoints. Ingress proxies conduct health checks, perform load balancing, and make intelligent routing decisions based on metrics such as load, packets, quotas, and traffic balancing.

Service A

Once Ingress routes the traffic to a pod, it encounters the sidecar proxy container of the Service A pod, not the actual microservice container. The envoy proxy and the microservice container share the same network namespace within the pod and have identical IP addresses and IP Table rules. The envoy proxy takes control of the pod, handling all traffic passing through it. The proxy interacts with Citadel to enforce policies, checks whether traffic needs encryption, and establishes TLS connections with the backend pod.

Service B

Service A’s encrypted packet is sent to Service B, where similar steps are followed. Service B’s proxy verifies the sender’s identity through a TLS handshake with the source proxy. Upon establishing trust, the packet is forwarded to the Service B container, continuing the flow toward the egress layer.

Egress

The egress resource manages outbound traffic from the mesh. Egress defines which traffic can exit the mesh and employs Pilot for configuration, similar to the ingress layer. Egress resources enable the implementation of policies restricting outbound traffic to only necessary services.

Telemetry data collection

Throughout these steps, proxies collect telemetry data from the traffic. This telemetry data is sent to Prometheus for storage and analysis. This data can be visualized inGrafana, offering insights into the service mesh’s behavior. The telemetry data can also be sent to external tools such as ELK for more in-depth analysis and machine learning applications on metrics collected.

This structured flow ensures traffic moves securely and efficiently through the service mesh while providing valuable insights for monitoring, analysis, and decision-making processes.

Now that we’ve understood the Istio architecture and its features, let’s go ahead and see how we can install it.