This is the fourth day of my participation in the November Gwen Challenge. Check out the details: The last Gwen Challenge 2021

Istio is logically divided into a Data Plane and a Control Plane.

  • The data plane: by the entire grid withinSidecarThe agents are composed ofSidecarIs deployed with the application service. These agents are responsible for coordinating and controlling all network communications between application services. eachSidecarIt will take over the incoming and outgoing traffic and cooperate with the control plane to complete functions such as flow control.
  • Control plane: controls and manages the data planeSidecarProxy enables you to configure distribution, service discovery, traffic routing, and authorization to centrally manage data planes. inIstio 1.5In this version, the control plane is integrated from several previously dispersed and independently deployed components into an independent oneistiodBecomes a single-process, multi-module organization. At the same time,Istio 1.5Deprecated for performance and ease of deploymentMixer, and instead put these functions inSidecarIn the.

The following figure shows the different components that make up each plane:

Figure 4.1.1: Istio architecture diagram

1. Core components

Here is a brief overview of the main functions of several core components of the Istio architecture.

1.1 the Proxy

The Proxy resides on the data plane, that is, the Sidecar Proxy. The Proxy and the application service are deployed in the same Pod in Sidecar mode. Proxy consists of isTIo-Proxy and Pilot-Agent, which are deployed in the same container ISTIo-Proxy as two different processes.

istio-proxy

The data plane of Istio defaults to using an extended version of The Envoy as the Sidecar proxy (i.e., ISTIo-Proxy). Istio-proxy is based on the Envoy’s new extensions, and its code repository is located in Istio/Proxy.

Note: In theory, Istio supports a variety of Sidecar proxies, with the Envoy serving as the default data plane.

Envoy is a high-performance agent developed in C++ to coordinate inbound and outbound traffic for all services in a service grid, and is the only component that interacts with data plane traffic. It mainly includes three parts:

  • Dynamic service discovery, load balancing, routing, and traffic transfer.
  • Elastic capability: such as timeout retry and fusing.
  • Debugging functions: such as fault injection and traffic mirroring.

polit-agent

Pilot-agent: Manages the entire life cycle of ISTIo-Proxy, including preparing startup parameters and configuration files for ISTIo-Proxy, managing the startup process, running status monitoring, and restart of ISTIo-Proxy. The code warehouse located in istio/istio/pilot/CMD/pilot – agent.

In deployment, isito-Proxy and Polit-Agent are packaged together to build an image isTIO/Proxyv2, instead of building an image separately. Poilt-agent will start ISTIo-Proxy as a child process. And monitor the running status of ISTIO-Proxy.

1.2 Istiod

Since Istio 1.5, the control plane integrates the three components (Pilot, Citadel, and Galley) into an independent ISTIOD, and becomes a single-process, multi-module organization, greatly reducing the complexity of the original deployment.

Pilot

Responsible for xDS configuration and management of Istio data plane, including:

  • Discover services and configuration rules: Provides Sidecar with service discovery, traffic management capabilities for intelligent routing (for example, A/B testing, Canary publishing, and so on), and resiliency capabilities (timeout, retry, fuses, and so on). By providing a common traffic management model and service discovery adapter (Service Discovery Adapter), to connect with the adaptation layer of different platforms.
  • XDS configuration delivered: Provides unifiedxDS APIIs called by Sidecar. The Sidecar converts configuration information, such as routing rules, to the information identified by the Sidecar and sends the information to the data plane.

Note: this is actually refers to the pilot – discovery, code warehouse located in istio/istio/pilot/CMD/pilot – discovery

Citadel

Manage and issue security certificates and implement authorization and authentication.

Citadel is not the only certificate management mode. Istio supports multiple certificate management modes, such as Citadel, Vault, and Google. Citadel is the default certificate management mode.

Galley

Galley is a configuration management component newly introduced in Istio 1.1. Galley is responsible for verifying, extracting, and processing configurations. The goal is to decouple Istio from the underlying platform, such as Kubernetes.

Before Galley is introduced, each component of Istio control plane needs to manage Kubernetes resources, including verifying resource configuration, monitoring resource configuration changes, and handling configuration changes accordingly.

2. Design objectives

The architecture of Istio is shaped by several key design goals that are critical to enabling systems to handle services at scale and with high performance.

  • Transparency to Applications: Essentially, transparency to applications is a feature of Service Mesh. Any qualified Service Mesh product should have this feature, otherwise it will lose the core competitiveness of the Mesh product. To do this, Istio automatically injects itself into all network paths between services, making it transparent to applications. Istio uses Sidecar agents to capture traffic and automatically configure the network layer to route traffic through these agents without changing the deployed application code.
  • Scalability: Istio believes there will be more demand from operational and peacekeeping developers as they get deeper into Istio’s capabilities, mainly in the policy area. Therefore, providing sufficient extensibility for the policy system is a major design goal of Istio.
  • Portability: Considering the diversity of the existing cloud ecosystem, Istio is designed to support different underlying platforms as well as different deployment environments such as on-premise, virtual machine, and cloud platforms. However, from the current situation, Istio and Kubernetes still have a relatively close dependence, platform independence, portability will be the ultimate goal of Istio.
  • Policy consistency: Istio uses its own API to isolate the policy system rather than integrate it into Sidecar, allowing services to integrate directly with it as needed. At the same time, Istio also pays attention to unification and consistency of user experience in configuration. A typical example is that routing rules are uniformly configured by virtual services that can be reused for flow control within, outside, and at the boundaries of the grid.

3. Istio architecture evolution

Since its release in May 2017, Istio has gone through four major releases and three development phases. In less than three years of product iterations, there have been two major architectural changes.

  • Version 0.1: May 2017. As the pioneer of the second generation of Service Mesh, IT heralded the birth of Istio and ignited the battle of the grid market.
  • Version 1.0: Released in July 2018, advertised as available in production environments. From version 0.1 to 1.0, the development took more than a year, but there were multiple 0.x releases that continued to be rapid iterations.
  • Version 1.1: Released in March 2019, touted as enterprise-level available. A small version number change took half a year, mainly because of the first architectural refactoring, which is the adjustment period.
  • Version 1.5: Released in March 2020, the architecture was rebuilt again to integrate multiple components into isTIOD in a single form. A year from version 1.1 to 1.5, Istio began to follow seasonal releases and entered a period of steady growth for the product.

Figure 4.1.2: Istio architecture evolution

Next, we will elaborate on the Istio data plane and the control plane.