Istio layered architecture? 80% of people have misunderstandings

ServiceMesh(3)

Before the article:

What exactly does ServiceMesh Solve?

What is Istio, ServiceMesh?

Istio is a productization of ServiceMesh:

• It helps build connections between microservices, helps r&d teams better manage and monitor microservices, and makes system architectures more secure
• It helps decouple microservices hierarchies so that the proxy layer is more focused on providing infrastructure capabilities such as:

(1) Service Discovery

(2) Load balancing

(3) Failure Recovery

(4) Service Metrics

(5) Service Monitoring

(6) A/B testing

(7) Grayscale release (Canary Rollouts)

(8) Rate limiting

(9) Access Control

(10) End-to-end authentication

, and other functions.

• It enables both the business engineering team and the infrastructure team to work more efficiently, each focusing on its own work and better empowering each other

Today I will talk about the core architecture design of Istio.

The website for Istio’s architecture uses the following sentence:

Logically, Istio is divided into:

• Data plane
• Control plane

These two words, which are at the heart of Istio’s architecture, are the most misleading.

Data plane and control plane, not first proposed by ServiceMesh and Istio, are mature concepts in computer networks, packet routing and forwarding:

• Data plane: Used for fast forwarding
• Control plane: Provides necessary information for fast forwarding

Voice-over: The last two pictures show the router architecture.

Its design principles are:

• In a routing device, forwarding is the most important work, it has the highest priority, the core of the design of data plane is efficient forwarding, how to process the most packets in the shortest time, often use efficient memory management, queue management, timeout management and other technologies to achieve in the hardware
• Control plane is not, it is to achieve routing protocol, device management, IGMP, ARP protocol, it is more inclined to control and application, often by software implementation

Voice-over:

Internet GroupManagement Protocol (IGMP) is a multicast Protocol.

Address ResolutionProtocol (ARP), which is familiar, obtains MAC addresses based on IP addresses.

The architectural core of Istio is very similar to a router:

• The service (the little red box at the top) interacts with the proxy through local communication
• The data plane is composed of a series of proxies (two small red boxes in the middle layer), and its core responsibilities are:

(1) Efficient forwarding;

(2) Receiving and implementing strategies from Mixer;

• The control plane (bottom red box), the core is control and application, core responsibilities are:

(1) Manage and configure sidecar agents;

(2) Implement strategies and collect data from sidecar agents through Mixer;

Voice-over:

(1) Sidecar proxy

(2) Mixer, not sure how to translate, some articles are called “mixer”, the latter text is directly called “Mixer”;

(3) Pilot, Galley, Citadel, dare not translate into The pilot, kitchen, fortress, after the text directly into English;

As shown in the architecture diagram, there are five core components in this two-tier architecture.

The data plane has one core component:

Envoy (proxy)

Envoy’s core responsibility is to efficiently retransmit, and more specifically, it has the ability to:

(1) Service discovery

(2) Load balancing

(3) Secure transmission

(4) Multi-protocol support, such as HTTP/2 and gRPC

(5) Circuit Breakers

(6) Health check

(7) Percentage routing

(8) Fault injection

(9) System measurement

Most of these capabilities are available or well understood by RPC frameworks, with emphasis on circuit breakers and fault injection.

Circuit breaker design

It is a design concept of service self-preservation, or degradation, in software architecture.

For example, if the system detects a large number of timeout times on an interface, the circuit breaker policy can terminate the call to the interface (the circuit breaker is on), and then retry the call after a period of time. If the interface no longer times out, the call slowly resumes (the circuit breaker is off).

Fault injection design

It is a method of deliberately introducing faults in software architecture design to expand test coverage and ensure system robustness. It is mainly used for testing.

In most Domestic Internet companies, fault injection is seldom considered in the architecture design. It is often used in the development and debugging of operating system kernel and router. It can be used to simulate some very difficult anomalies such as memory allocation failure and disk IO error to ensure the test coverage.

The control plane has four core components:

Mixer

Some of Mixer’s core capabilities are:

(1) Cross-platform, as an Adapter of other components, to achieve Istio cross-platform capability;

(2) Communicate with Envoy, real-time various strategies

(3) Communicate with Envoy and collect various data

At the heart of the Mixer’s design was the “plug-in” model, which enabled Istio to adapt to a variety of complex host environments as well as back-end infrastructures.

Pilot

As a very important control plane component, Pilot’s core capabilities are:

(1) Service discovery capabilities for envoys;

(2) Provide intelligent routing management capabilities such as A/B testing, gray scale publishing for Envoy;

(3) Provide various flexible management capabilities such as time-outs, retries, and circuit breakers for envoys;

At the heart of Pilot’s design is “standardization”, which translates various flow control commands into configurations that envoys recognize and, at run time, diffuses these commands to all envoys. The advantage of Pilot abstracting these capabilities into a common configuration is that any Envoy that meets this standard can plug into Pilot.

The subtext is that any third party can implement its own proxy and integrate with Pilot as long as it complies with the relevant API standards.

Citadel

Citadel component, which provides end-user authentication and service-to-service access control. Anyway, this is a security-related component.

Galley

The Gally component, which is a configuration capture, validation, processing, distribution component, is designed to be decoupled from Istio by obtaining user configuration from the underlying platform (for example, K8S).

Lace: why are 80% of Chinese users wrong about Istio’s two-tier architecture?

Many friends ask me how to learn the latest technical knowledge, and my answer is always the English official website.

Voice-over: All information in this article is from Istio1.1.

I searched Istio in Baidu, 80% of the information, and translated the two-layer architecture as:

• Panel data
• The control panel

Voice-over: You can search “ISTIO Control Panel” on Baidu.

I was extremely confused at first because “data plane” and “control plane” are very mature translations. Routers use this layer 2 architecture, and ServiceMesh uses the same architectural design for decoupling, so there should be no creative translation required.

Later, I understood:

• Control plane
• Control Panel

Half-english programmer, second hand technical documentation, really harm, alas.

conclusion

Istio adopts a two-layer architecture with five modules to decouple microservices ServiceMesh:

• The data plane is mainly responsible for efficient forwarding

(1) Envoy module: proxy;

• Control plane, mainly responsible for control and application

(2) Mixer module: Adapter supporting cross-platform and standardized API;

(3) Pilot module: Control and configure most strategies for envoy;

(4) Citadel module: security related;

(5) Galley module: decoupled from the configuration of the underlying platform (such as K8S);

Separation of implementation and control, classical architectural design approach, GOT?

Thinking is more important than conclusion.