Istio Architecture

To explain how Istio works, we’ll use Service A and Service B to communicate with each other. Each app will have Envoy deployed alongside it, known as a sidecar deployment - a crucial part of Istio and mesh.

Our sidecar intercepts all incoming and outgoing network traffic for the application. It enables us to apply policies and utilize the mentioned resiliency features. By capturing the network traffic, we can access the interface point with the outside world and perform advanced functions.

The data plane of Istio consists of a group of Envoys. However, the Istio Control Plane is necessary to configure and manage their behavior. The Istio Control Plane is in the istiod binary.

Galley is Istio’s management plane. It retrieves configuration from the configuration store by serving as an API server. Galley obtains, validates, and distributes the configuration to other Istio components in Kubernetes by communicating with the Kubernetes API server.

Pilot is the piece responsible for taking configuration from Galley (these are the things we write in YAML - things like Gateways, VirtualServices, and networking config, among others). Pilot combines that with a view of the world from the set of service registries. In Kubernetes, we talk to the Kubernetes API server to get the services that exist in the system, which are their endpoints.

To create a network, Pilot establishes a model of the mesh and configures it for the Envoys. It then sends this configuration to the Envoys, which control the runtime behavior of the network. Pilot also distributes policies in addition to the network configuration.

The final piece is called Citadel. It’s responsible for identity issuance and certificate rotation. Istio mints x.509 certificates - these are the certs you would typically use for things like terminating a website for HTTPS. The certs Istio mints are ephemeral, meaning they only live for a couple of hours - they encode the service’s identity. We authenticate the service, issue the identity, and then that identity is used at runtime.

We call that a SPIFFE identity for each workload in the mesh.

SPIFFE stands for secure production identity framework for everyone, and it provides a secure identity in the form of a specially crafted x.509 certificate. For more information about SPIFFE, please read here.

We can implement authorization policies (authz) now that we have established their identities.

Since Envoy is running alongside your application, it transparently intercepts the call. It modifies the iptables rules and intercepts incoming and outgoing traffic. In Kubernetes, changes made to the iptables rules by the init container in a pod will apply to all the containers in the pod due to their shared network space.

“Transparently” means that Service A is unaware of the intercepted request. If Service A sends a request to Service B, Envoy must determine the destination and forward the request accordingly. We don’t necessarily know that there’s an Envoy on the other side; the client is unaware. But we forward the request, and Service B happens to have another sidecar, which intercepts the request and checks the destination’s identity. The server Envoy, also referred to as the upstream Envoy, verifies the sender’s identity. Then Envoy checks the policy to see if it should forward the request, which is where we can apply our service-to-service communication policy and decide if the call should go through or not. Let’s assume the request goes through. Envoy will forward that to Service B, and B does the necessary work to assemble the answer and call other services. Eventually, B prepares the response and sends it back over the network. Again, Envoy intercepts that response and forwards it to the client that requested it. The client envoy delivers it back to the destination application, Service A.

Let’s take a step back and review. At a high level, we have data planes and control planes. The data plane is a collection of Envoy proxies that run next to your applications. Envoy intercepts communication and applies the policy.

The control plane is a single binary called istiod with the following components: - Galley for configuration validation and distribution, - Pilot to configure and push service configuration, and - Citadel for identity and credential management.

Next

With Istio installed and a proper environment, we can deploy an application to the mesh.