Istio Service Grid Core Theoretical Concepts of Cloud Native Core Technology

Istio service mesh core theoretical concepts

1. Basic Concepts of Service Mesh

1.1. What is Service Mesh Service Mesh

Before getting familiar with and using Istio, we must first understand what a service mesh is.

Service Mesh is a "service mesh", which is an infrastructure layer used to handle communication between services and services. It is mainly responsible for providing a reliable network for complex cloud-native applications to transmit requests, and implements basic microservice communication. Features such as service discovery, load balancing, monitoring, traffic management, access control, and more.

A service mesh usually deploys and associates an application with an agent, which is transparent to the application, and all requests are handled by the agent.

As shown in the following figure: The whole picture is like a microservice application. Each box can be regarded as a microservice program. The green box represents a specific application, and the blue box represents a sidecar proxy. The communication between them is completed through the agent program. The blue line in the figure represents the communication route between the various microservice programs. The whole picture looks like an intricate grid, which is the origin of the name of the service grid. .

1.2. Characteristics of Service Mesh

• Microservice governance capabilities
• application-agnostic
• Infrastructure layer for service communication
• Decoupled application retry/supermarket, monitoring, tracing and service discovery

The Service Mesh service mesh is mainly born to facilitate the management of microservices. In a microservice environment, there are as few as a few microservice programs as many as hundreds of microservice applications. When using the traditional model, different microservice programs need to be used. Configure agents separately. When there are a large number of microservices, the cost of operation and maintenance will be greatly increased, and it is difficult to manage. When using a service grid, each microservice program will be associated with an agent program, and all traffic requests will be processed by the agent program. And the service mesh has the concept of control center, all the agents are managed through the control center in a unified way, reducing the cost of manual maintenance.

Taking the Sidecar proxy as an example, since all traffic requests are handled by the proxy in the service mesh, there is a lot that can be done.

• Governance capability of microservices: Each microservice program is associated with a Sidecar agent, and all incoming and outgoing traffic is processed by Sidecar.
• Application-agnostic: Although each application needs to be associated with an agent program, there is no need to modify the program code. The program and the agent are associated and bound through tags.
• Infrastructure layer for service communication: After using the grid, applications will not communicate directly, all communication is handled by the agent program, avoiding the failure of communication due to timeout, and ensuring the basic communication facilities
• Decoupling applications: After using the grid, all requests and flow control are handled by the agent program, which realizes the decoupling of the application program from a certain perspective. Since all requests come from the agent program, the operation and maintenance cost is The difficulty is also greatly reduced, and we can get traffic monitoring, tracking and monitoring between links directly from the agent.

Compared with traditional agents, the agents in the service grid have the same underlying implementation, but there is a control center in the service grid, which can uniformly manage the agents of each application.

1.3. The difference between service mesh and traditional proxy

The proxy of Service Mesh service mesh is not the same as the traditional proxy program. Service mesh is a more advanced concept based on traditional proxy process. In addition, traditional proxy is oriented to a single application, while service mesh is oriented to distributed Proxy environment and have the ability of unified management.

• service mesh
  • In the distributed proxy scenario, each application is associated with an agent, and each application communicates through the agent, and all traffic is processed by the agent. There is a control center in the service grid, and the control center manages the service network uniformly. All agents in the grid.
• traditional agent
  • For a single service, all requests are forwarded to the actual back-end program through an agent, that is, one application program and one agent program. Each agent program needs to be manually configured and managed.

2. Basic theoretical concepts of Istio

2.1. Introduction to Istio Service Mesh

There are many ServiceMesh service mesh products, the world's first service mesh product is Linkerd.

Istio is currently a very mainstream service mesh product with rich functions and high maturity. Istio solves the challenges faced by developers and operation and maintenance personnel in transitioning from a monolithic application to a distributed microservice architecture.

At present, applications are deployed in the K8S cluster for management, and microservice programs are also deployed using Pod controllers. There is no problem in deployment and use, but I want to manage microservice programs more delicately, such as traffic control and link status tracking. , rate limit and other functions, K8S cannot meet, so it is necessary to use service mesh to manage microservice programs. The most common solution in enterprises is to combine Istio with K8S. K8S is mainly responsible for application deployment, Elastic scaling and resource isolation, Istio is mainly responsible for microservice governance, traffic monitoring, circuit breaker current limiting, dynamic routing, link tracking and other functions. The two can complement each other perfectly.

Istio has four synonyms:

• Connect
  • Intelligent realization of traffic management, load balancing, and grayscale release of programs.
• Security Hardening (Secure)
  • All traffic is managed by the agent, so some authentication and authentication aspects can be automatically processed on the received traffic.
• Control
  • You can do some access control operations based on traffic.
• Observe
  • Various data during server operation can be monitored, such as logs, link monitoring, and traffic monitoring.

2.2. Changes in Istio version architecture

The architecture of Istio has undergone major changes in version 1.5, mainly for the changes in the control plane architecture. Deploying Istio before version 1.5 requires the installation of many components, and individual components are also prone to failure in the use environment, and the complexity is extremely high. In and later versions, Istio integrated many of the original components into a single structure, that is, the Istiod service. Colleagues abandoned the mixer component before version 1.5 and integrated some functions of the mixer into Istiod.

The Istiod service also includes the functions of the main components such as pliot, citadel, and Galley, and the complexity is greatly reduced after the architecture becomes a single structure.

2.3. Introduction to Istio Service Mesh Components

Control Platform Components

• Pilot
  • The traffic management component is the most important control component in Istio. The Pilot component provides the service discovery function for Envoy Sidecar, intelligent routing (canary deployment, A/B testing) and traffic processing (timeout, retry, fuse and current limiting) ), etc. to provide traffic management capabilities.
  • The Pilot component can also issue governance rules, agent configuration, etc. to the data layer.
• Citadel
  • Security component, which provides certificate generation and issuance, encrypted communication and access control.
• Galley
  • The configuration management component verifies the correctness of the format and content of the configuration information, and distributes the configuration information to other components.
• Ingressgateway
  • The gateway component of the Istio service grid, accessing services in the grid from outside the grid is implemented through the Gateway. The Gateway program of Istio is a service resource of the LoadBlancer type. The service resource opens a set of ports. These ports are the network External access port for grid services.

Data Platform Components

• Proxy
  • Responsible for microservice network communication, each application is associated with a Sidecar Proxy, called envoy in Istio, and the proxy program forwards traffic.
  • Envoy is a very influential lightweight high-performance open source service proxy developed in C++. As the data plane of the service mesh, Envoy provides dynamic service discovery, load balancing, TLS, HTTP/2 and gRPC proxy, circuit breaker, health check, traffic splitting, grayscale publishing, fault injection and other functions, and most of the governance capabilities In the end, it was implemented on the implementation of Envoy.

2.4.Istio Service Mesh Features

• automatic injection
  • When an application is created, the sidecar proxy envoy program is automatically injected. When a Pod is created in the K8S cluster, the kube-apiserver component will call the sidecar-injecor service of the Istio control plane to automatically modify the description information of the application and inject the sidecar proxy program, namely Create a sidecar container at the same time as the business container.
• Traffic interception
  • For applications that are unaware, Istio will modify the iptables rules when the pod is initialized, and intercept inbound and outbound traffic to the Sidecar proxy program based on the configured iptables rules, thereby realizing traffic interception.
• service discovery
  • The sidecar agent of the service initiator will call the service discovery interface of the pilot component of the Istio control plane to obtain the instance list of the target service.
• load balancing
  • The sidecar agent of the service initiator will connect other instances of the same application to form load balancing according to the configured load balancing policy.
• Traffic governance
  • The agent will obtain the configured traffic rules from the pilot component and execute governance logic during traffic processing.
• access security
  • The access between each microservice will be communicated through the agent program, and the agent programs of both parties will perform two-way authentication and channel encryption, and can also perform authorization management based on the identity of the service.
• Service monitoring
  • All traffic requests are handled by the Sidecar proxy program, which can do service monitoring well.

2.5.Istio configuration resources

Istio has 4 configuration resources, which are controller types.

• VirtualService: A virtual service that implements the routing rule function for service requests, mainly forwarding the gateway request to the corresponding back-end service.
• DestinationRule: The destination rule, which implements the functions of load balancing, service discovery, fault handling and fault injection of the target service.
• Gateway: Let the applications in the service mesh be published externally.
• ServiceEntry: Service entry, which allows to manage service traffic outside the mesh.