Key concepts in Istio

To learn Istio, you need to understand the following key terms.

1. Container/Container image

In the service grid architecture of the cloud native era, application publishing and deployment are carried out around the container infrastructure represented by Kubernetes. This requires a clear understanding of the concepts of containers and container images.

In fact, the popularity of containers is due to the popularity of Docker technology, and containers are essentially a set of processes that run on an operating system and are limited by resource isolation, also known as ** “container runtime” **. It can fully restore the user-packaged code and the relationships it depends on. Containerized applications can run faster and more reliably, regardless of the specific computing environment.

Container image is an important medium and carrier of containerization. Formally, it is a lightweight, stand-alone, executable package file that contains everything you need to run your application: code, tools, system libraries, and Settings.

The advent of container technology has completely changed the way applications are built, published and run, and has become the de facto standard for server-side application publishing. Istio’s service grid technology, which I’ll talk about later, is both “grid base components” and “applications” that run on top of the Kubernetes container platform as containers.

2. Micro service

Microservices are an architectural style that splits a large monolithic service into a loosely coupled collection of microservices that provide the same functionality as a monolithic application. But microservices can be developed and deployed independently of other services. In addition, microservices are organized around business capabilities and can be owned by smaller teams, thus enabling smaller, more independent iterations in development/deployment.

At present, the main microservice architecture solutions, represented by Spring Cloud microservice architecture system is the mainstream; However, with the popularity of the concept of cloud native technology, Service Mesh (Service Mesh) microservice architecture represented by Istio is also gradually promoted.

3. Control plane

In the traditional microservices architecture represented by Spring Cloud, the application itself is coupled with the service governance logic. In the Service Mesh solution, the management of Service governance rules, Service governance behavior and application itself are independent of each other, which enables applications to focus on business, while the Service governance logic can be completely removed from the operation and maintenance team for unified management.

The logic or component responsible for managing Service governance rules is called the “control plane” in the Service Mesh architecture. The “control plane” consists of apis and tools for managing service governance behavior (the data plane). Service grid operations personnel can manipulate the control plane to configure the behavior of the data plane in the service grid. For example, apply traffic configuration to the control plane — translate the configuration and push it to the data plane.

4. Data plane

In the Service Mesh, the data plane is the agent that implements the Service governance behavior. In Istio, the data plane consists of Envoy proxies responsible for routing, load balancing, service discovery, health checks, and authorization/authentication. These agents run alongside each service instance (in K8S, on the same Pod as the application container), intercepting all incoming and outgoing user traffic and managing traffic in the process according to service governance rules delivered from the control plane.

5.Envoy

In Istio, the data plane is implemented by Envoy proxies. It is a modern, high-performance edge of the small L7 agent. Envoy is designed for large modern microservice architectures and can be matched with load balancers such as Nginx and HAProxy.

6. The agent

In a network, a proxy is an intermediate server that sits between clients and servers and manages requests and responses. In the case of the Istio service grid, the proxy runs in front of each application instance. When a request is made to an application, the proxy intercepts the request and forwards it to the application instance. Similarly, when an application instance tries to make a request, the proxy intercepts the outbound request and sends it to its destination.

Because the proxy intercepts all requests, it can modify the request to implement traffic routing, fault injection, authorization, and so on.

7. About the agent

The L7 (Layer 7) agent works at the application layer of the OSI model. At this level, the agent can process the content of each request. Http, for example, is a popular L7 protocol. Because the requested data can be accessed, the L7 proxy (Envoy) can make load balancing decisions based on the requested content (URL, Cookies, etc.).

Istio architecture and module composition

The Service Mesh architecture provides a unified way to connect, secure, and view microservices. Proxies within the grid (such as envoys) can capture all communication requests and metrics within the grid — every failed or successful call, retry or timeout request can be captured, visualized and alerted.

This architectural approach of separating communication logic from business and application logic enables developers to focus on business logic and service grid operations to focus on service grid configuration.

With an explanation of a few key terms and an introduction to the benefits of a service grid architecture, I believe you have more or less understood what a service grid is. Next, I’ll focus on Istio, an open source service grid implementation.

At a macro level, Istio supports the following functions:

1. Traffic management

Traffic management is the core function of Istio. You can control the traffic between services by configuring service governance mechanisms such as circuit breakers, timeout, and retry through simple configuration changes in Istio.

2. Observable

Istio can better monitor services by tracking, monitoring, and recording requests between services so that we can understand the health of services and find and fix problems in a timely manner.

3. The security

Istio manages authentication, authorization, and communication encryption at the agent level without intruding on the application itself. These security configuration operations only need to be completed through quick configuration changes.

Next, let’s look at the architectural composition of Istio. As shown below:

As shown in the figure above, Istio implements the service grid, following the common distributed system construction pattern of separating components into ** “control plane” and “data plane” **.

Data planes in Istio are composed of Envoy proxies that control communication between services. Envoy is a high-performance proxy developed in C++. Istio injects the Enovy agent as a Sidecar container next to the application container and then intercepts all inbound and outbound traffic to the service. These Enovy agents next to the injected application container together form the data plane of the Istio service grid.

Istiod is the control plane component of Istio and provides services such as service discovery, configuration, and certificate management. Istiod writes the flow control rules in the YAML file format, converts them into an Envoy’s actiable configuration, and propagates the configuration to all sidecar agents in the grid via the xDS protocol.

Istiod consists of Pilot, Citadel, and Galley. Pilot abstractions a platform-specific service discovery mechanism (such as Kubernetes, Consul, or VM) and transforms it into a standard format that can be used by Sidecar. Citadel is the core security component of Istio. It implements certificate authorization, certificate generation, and mTLS secure communication between sidecar agents on the data plane.

Galley provides configuration management, which includes verifying the format and content of configuration information and providing it to other control plane components such as Pilot.

Istio traffic management implementation

Istio traffic management is as follows:

As shown in the figure above, traffic management in the Istio service grid requires the **VirtualService and DestinationRule resources to manage traffic routing rules.

Istio gateway resources are used to implement traffic of routing rules. The **Ingress Gateway and Egress Gateway ** are part of the Istio service grid component. Each of these gateways runs an instance of an Envoy proxy that acts as a load balancer on the edge of the service grid. The Gateway is connected to an income station. The egress gateway receives connections from the cluster.

It is important to note that the concepts of entrance gateway and exit gateway are not narrowly understood as edge entrances and exits of the Istio service grid. For Istio service grids, external traffic can be routed through VitrualService (virtual service) and Gateway (Gateway resource), and traffic can be routed between grids in this way.

Therefore, when Istio service grid is used to implement microservice traffic management, Gateway+VirtualService resources for external traffic and Gateway+VirtualService resources for traffic between specific microservice grids can be created according to scenarios. And through VitrualService to modify the corresponding routing rules at any time.

For creating Gateway grid resources, the Ingress Gateway or Egress Gateway is associated according to whether the Ingress Gateway or Egress Gateway is controlled.

The final summary

The above is a brief introduction to the core logic of Istio service grid for traffic management, as well as to help you understand some of the operations in previous articles. Although Istio service grid architecture has not completely replaced Spring Cloud microservice system at present, service grid, which separates control plane and data plane, will be the mainstream of microservice architecture in the future.