Shulou(Shulou.com)06/03 Report--

This article mainly explains "what is the principle of Istio architecture". The content of the explanation is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "what is the principle of Istio architecture".

Why choose Istio?

With the increase of business complexity, in order to cope with high concurrency and high traffic, the system architecture splits the service / application. Split services / applications can be distributed deployed to cope with the system pressure caused by high concurrency and to deal with complex business logic.

This practice will result in a large number of independent services or applications in the system, which are distributed in different processes and hosts, and there is a problem of service governance when they are called each other. Micro-service is a typical example, and the development and operation of micro-service is a challenge for programmers.

The idea of divide and conquer makes the scale and complexity of the business increase rather than decrease.

In distributed systems, network reliability, communication security, network delay and network topology changes have all become the focus of attention. at the same time, service registration, service discovery, load balancing, inter-service communication and distributed call chain tracking are all problems to be solved.

To solve this problem, the service governance part is abstracted into a common library, which is used by all micro-services. As shown in figure 1, two services, Service 1 and Service 2, are used on Node 1 and Node 2, respectively, and each of them has a corresponding SDK of service governance for their own business logic, through which service discovery and service registration are completed.

Figure 1. Abstract the logic of service governance into a common library

If you include the SDK in figure 1 in the development framework (for example, Spring Cloud), you will have the ability to govern services when you use this development framework. Although the pattern of SDK decouples business logic and service governance, because in a development framework, business logic needs to be compiled with the SDK of service governance, and the code of business logic and service governance runs in the same process after release. This can cause the business code and SDK to be based on the same language and not compatible with services developed in other languages. At the same time, when the service governance is upgraded, the entire service needs to be upgraded, even if the business logic has not changed. If the pattern in figure 1, SDK and the business code are in the same process, it needs to be decoupled to separate service governance from the business code. As shown in figure 2, the red part replaces the original SDK, which uses the Sidecar pattern. In this form, business logic and service governance run under independent processes.

Figure 2.Sidecar decouples business logic and service governance

The mode of Sidecar makes the code and operation of both uncoupled. As shown in figure 3, the business logic is like a green square, and the blue square on the right is the Sidecar provided by Istio, which is linked to the Sidecar of other services in the network through this Sidecar to achieve communication between services.

In this way, business logic can be developed in different languages, and upgrades are independent of each other, while other service governance tasks, such as service registration, service discovery, load balancing, communication, etc., are done by Sidecar.

Figure Sidecar mode of 3.Istio

From the perspective of business logic and service governance, microservices before and after using Istio are distinguished and compared from the following three dimensions.

Business logic and service governance before using Istio, running processes after using Istio, both in the same process, both in different process technology stacks, both using the same technology stack, both using different technology stacks, both upgrading at the same time, both upgrading at the same time

Therefore, after using the Istio architecture, we will completely decouple business logic from service governance in terms of running processes, technology stacks and service upgrades, and create best practices for distributed systems through the Sidecar pattern. Next, let's take a look at what Istio includes.

What is Istio?

It is well known that Istio is an open platform for service governance in the form of Service Mesh. The service "governance" here is not limited to "micro-services", but can be extended to any service. Istio can be used as long as there are services or applications, access between them, and management of services and applications.

As shown in figure 4, in the official introduction of Istio, its functions include: Connect, Secure, Control and Observe

Figure introduction to the official functions of 4.Istio

The above four functions are summarized as follows:

Connection: through traffic rules to control the traffic and invocation between services, to achieve load balancing, circuit breaker, fault injection, retry, redirection and other functions.

Security: provide authentication mechanism, channel encryption, service access authorization and other security capabilities to enhance the security of access.

Control: access control, rate limit, quota management, service billing and other capabilities are realized through dynamically pluggable and scalable policies.

Observation: obtain service operation data and output, provide call chain monitoring and log collection capabilities.

In the micro-service era, Kubernetes provides operation and management capabilities such as service deployment, upgrade and expansion, but it is insufficient in service governance, such as service circuit breaker, current limit, dynamic routing and call chain tracking.

Istio, as the framework of service governance, makes up for the deficiency of Kubernetes and becomes a good partner of Kubernetes.

Now that Istio is all over the world, let's take a look at what Istio has done in the process of service access. As shown in figure 5, there are two Pod containers that hold two different services, Service An and Service B. Service An is developed by Java and Service B is developed by Python.

Service An obtains the list of Service B service instances through service discovery. If Service B has multiple horizontal scaling (Service B clusters), it also needs to select a specific Service B instance according to the load balancing strategy.

To ensure security, requests and responses between services need to be enabled for two-way authentication and channel encryption.

For a period of time, Service A kept making errors when accessing Service B, which required circuit breaker processing and stopped the request action to Service B.

According to the processing capacity of Service B, the maximum number of requests and access timeout are set for service protection.

The request made by Service A to Service B can be redirected to other services if necessary.

If there are new and old versions of Service B, during the grayscale release, some of the traffic requested by Service A (20%) is imported into the new version of Service B, and the other traffic (80%) is imported into the old version of Service B. As the new version of Service B gradually stabilizes, import the remaining 80% of the traffic into the new version.

Trace the call chain of Service A calling Service B to provide data basis for improving the efficiency of invocation between services.

Figure 5.Istio functions for service governance

Principle of Istio Architecture

In the previous section, I introduced what Istio is, which is a description of its function, which seems abstract. Here we further describe the working mechanism and architecture of Istio. As shown in figure 4, the whole architecture of Istio can be divided into two parts: the control plane and the data plane, which mainly includes Pilot, Mixer, Galley, Citadel and other components; the data plane consists of the proxy Envoy that accompanies the service deployment, and the Envoy completes the logic of service governance for the service. Here we follow the operating mechanism of Istio to mark each step with a serial number and introduce it one by one. The sequence number does not represent the order of execution, but only for easy labeling and for explaining the function. The interaction in the data plane is represented by a solid line with arrows, and the interaction between the data surface and the control surface is marked by dotted lines. Its resources are deployed through Kubernetes, and Service An and Service B are deployed in Node 1 and Node 2 through the Pod container, where Service B has two versions V1 and V2, deployed in two Pod of Node 2. Describe the workflow of each component of Istio by describing the different versions of Service A calling Service B and the process of external request to access Service A.

Control plane and data plane of figure 6.Istio

1. Automatic injection

Because Istio uses the pattern of Sidecar agents, business logic and service governance are decoupled. So when you create a Pod in a Kubernetes scene, you also create a Sidecar container. Two containers, istio-proxy and istio-init, are actually injected and created. Istio-proxy contains two processes: Pilot-agent and Envoy. Envoy, as a process that handles request traffic between services, plays an important role in service invocation, so it is specifically noted in figure 4.

two。 Service discovery

After injecting Envoy, assume that service An invokes service B, so you need to initiate a request to service B through Envoy. How does service A know the access address of service B, it needs to be done through service discovery. At this point, Envoy needs to call the service discovery API of the management side component Pilot to obtain the instance list of service B. Pilot directly extracts data from the running platform and transforms it into Istio's service discovery model, which also supports Kubernetes, Consul and other platforms.

3. Traffic interception

When Service A learns the address of Service B, it sends request traffic to Envoy through Service A. The outgoing traffic becomes Outbound, and the traffic is received on the B side of the service as Inbound. In figure 4, the outflow from service A (Outbound) is intercepted by the Envoy on the service A side, and when the traffic arrives at service B as the incoming traffic (Inbound), it is intercepted by the Envoy on the service B side. The purpose of the interception here is to control the traffic, especially in the case of high concurrency, some services will be limited.

4. Load balancing

Service An is the initiator of the request. Envoy selects the service instance according to the configured load balancing policy and connects the corresponding instance address. These load balancer policies are sent to Envoy in the form of configuration files through Pilot, such as RANDOM and ROUND_ROBIN. In figure 4, when you access the version of service BMI V2, it is found that there are multiple service B in this version, so you need to use the load balancing policy to access one of them.

5. Flow management

Envoy acquires configured traffic rules from Pilot and executes governance logic when intercepting Inbound traffic and Outbound traffic. Unlike traffic blocking, it is designed to access different versions of the same service. Service An acquires rules through Envoy and distributes traffic to the V1 or V2 version of Service B by rule judgment.

6. Access security

Establish two-way authentication and channel encryption between service An and service B, and manage authorization based on the identity of the service. The security configuration is also issued by Pilot, and the certificate and key are loaded on the Envoy corresponding to service An and service B to achieve two-way authentication, and the certificate and key are maintained by the Citadel component of the management side.

7. Service telemetry

When communicating between services, the Envoy of both sides of the communication will connect the Mixer component of the management side to report the access data. For example, monitoring metrics, logs, and call chains can all be collected in this way.

8. External access

There is an "external request access" in the lower left corner, which accesses service A within the grid as a request outside the grid. So there is an Envoy at the entrance that acts as an ingress gateway. The external service accesses service A through Gateway. If you need load balancing and traffic governance policies, you can set them in the Envoy of this Gateway.

9. Manage configuration

Finally, there is the galley component of the management side. It does not provide services to the data side, but provides support to other components on the control plane. It is mainly responsible for verifying the correctness of the format and content of the configuration information in the control plane, and providing the configuration information to the Pilot and Mixer components.

Introduction to Istoio Service Governance function

Through the introduction of the principle of the Istio architecture above, we go through the components of the control plane and the data plane. As the issue of space can not be introduced here one by one, as the main function of Istio is service governance, it can be regarded as a glimpse of several functions that are often used in service governance.

Service routing

Service routing is common in real-world scenarios. As shown in figure 5, Service An accesses ServiceB, C, and D according to different routes: Test.com/ServiceB, Test.com/ServiceC, and Test.com/ServiceD.

Figure 7. Service routing

As mentioned in the chapter "Istio Architecture principles", Istio configuration rules are passed from the Pilot initiation to the Envoy for execution. Its configuration file format is basically similar to that of Kubernetes. The configuration file specific to figure 5 uses a configuration of type VirtualService.

VirtualService defines traffic rules for specific target services. It represents a virtual service that forwards traffic that meets the criteria to the corresponding service (one or more).

As shown in code snippet 1, in the configuration file of Istio, it is described in red numbers as follows:

Hongmeng official Strategic Cooperation to build HarmonyOS Technology Community

Define the type of VirtualService in kind

Define the name of the portal service to be accessed, where ServiceA is the portal service through which the next three services are accessed.

The url address of the host is defined in hosts as part of the route, because the address access here is accessed in a "Test.com/ServiceB" way, so it is defined as "Test.com".

Http requests are routed here, so prefix is defined in uri in match (matching) under http. Obviously, if you want to access "Test.com/ServiceB", the prefix needs to be defined as "/ ServiceB". It is actually the address of a specific service route.

Finally, make the corresponding route for the uri address, and define the name of the service in the host of the destination (target): "ServiceB". The definitions of ServiceC and D are basically the same as those of B.

Code snippet 1

Traffic segmentation

The rule settings for simple routing are described above. If there is a need for more access content for traffic segmentation, or if you need to split traffic proportionally, the content of the profile needs to be modified. As shown in figure 6, Service An accesses three different versions of Service B, V1, V2, and V3. When URI is "Test.com/status" and "Test.com/data", the V2 and V3 versions of Service B are requested, and the imported traffic is 20% and 80%, respectively (the part marked with red lines). Other URI is routed to the V1 version of Service B (the part marked with the green line).

Figure 8. Traffic segmentation

Take a look at the contents of each configuration item in the configuration file, described in red numbers as follows:

Hongmeng official Strategic Cooperation to build HarmonyOS Technology Community

In the http-match section to match the URI, there are two prefix: "data" and "status". Enter the following route selection when the request URI meets one of these two conditions.

The destination of the routing route corresponds to the ServiceB service, subset:V2, which is the V2 version. The Weight setting is 20, which means 20% of the traffic flows into the V2 version of ServiceB.

The destination of the routing route corresponds to the ServiceB service, subset:V3, which is the V3 version. The Weight setting is 80, which means 80% of the traffic flows into the V3 version of ServiceB.

Finally, if the above two prefix are not hit, the traffic will flow into the V1 version of the ServiceB.

Code snippet 2

Load balancing

Load balancing is a function often encountered in service governance. Let's see how it is implemented in Istio. As shown in figure 7, Service An accesses the Service B V2 version of the cluster and the Service B V1 version of the cluster. Two different load balancing strategies, ROUND_ROBIN and RANDOM, are required for two different versions of the same service.

Figure 9. Load balancing

After looking at the requirements of load balancing, let's take a look at how to implement it through the configuration file. Before introducing the configuration file, let's introduce the rule description of DestinationRule.

If VirtualService is a virtual Service, which describes "which service handles the request from the service", then DestinationRule describes "how to handle the incoming request after it reaches the service", which literally means the target rule. If it falls into the example of load balancing, that is, how the traffic will be accessed after it reaches the two versions of Service B (V1 and V2).

As shown in snippet 3, the order of the red numbers is as follows:

Hongmeng official Strategic Cooperation to build HarmonyOS Technology Community

The rule configuration is defined as DestinationRule, which means that requests for inflows of services are processed.

The requested inflow of service here is Service B, which exists in two versions, each of which is clustered.

In the case of Service B version V2, the ROUND_ROBIN strategy is used in loadBalancer (load balancing) of trafficPolicy (Traffic rules).

Similarly, in the case of Service B version V1, the RANDOM policy is used in loadBalancer (load balancing) of trafficPolicy (Traffic rules).

The introduction of the function of Istio service governance above in code paragraph 3 mainly focuses on the relationship between services. The relationship between services is defined through the adjustment of node data in the configuration file. Obtaining this way is a bit abstract for developers to understand its working principle. In order to facilitate the understanding of the relationship between services and manage them effectively, Istio provides a visual service grid tool-Kiali. Provide a visual interface for service topology map, full-link tracking, index telemetry, configuration verification, health check and other functions.

This paper focuses on the functions of the service topology diagram. Due to the lack of space, the installation of Kiali is not introduced here. Students who are interested can check it on the official website of Istio. As shown in figure 8, after logging in to Kiali, you can see its Overview interface, which includes services for all namespaces in the grid.

Figure 10.Kiali overview interface

If you want to view the corresponding service, such as Bookinfo, you can click on the Bookinfo namespace card to display the content shown in figure 9. The invocation of the service under this namespace is shown here. Notice the red box above: Graph Type, where you can choose the type of service display, that is, to show the relationship between services in different forms. There are currently four options: App, Versioned App, Workload, and Service.

Figure the service diagram under the 11.Bookinfo namespace

Selecting the App type aggregates all versions of the same application into a single point, as shown in figure 10. Requests outside the grid invoke productpage services through istio-ingressgateway, and productpage invokes details services and reviews services respectively. Where reviews invokes the ratings service and mongedb in turn. The service relationship presentation of the App type describes the dependency (invocation) relationship between services in a concise way, without involving the specific version of the service.

Figure 12.App type call

The Versioned App type displays the version of each service based on the App type. As shown in figure 11, you can see that there is only one version of the productpage service v1, but there are three versions of the reviews service v1, v2, v3, and there are two versions of ratings. The reality of this approach makes the version of the service invocation clearer.

Figure 13.Versioned App type

The Workload type is transformed on the display for the workload of each service on the basis of the Versioned App type. As shown in figure 12, the version of each service is displayed as a workload in a circle, and the workload of each circle is actually an entity in the actual invocation.

Figure 14.Workload type

Finally, there is the Service type, shown in figure 13, which generates a node for each service in the grid, but excludes all applications and workloads.

Figure 15.Service type

Thank you for your reading, the above is the content of "what is the principle of Istio architecture", after the study of this article, I believe you have a deeper understanding of what the principle of Istio architecture is, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.