On July 7th, the 10th session of PaaS Technology Salon of Speh Cloud container was successfully held in Shanghai. Wei Wei, head of Architecture of Speh Cloud Container, explained in detail representative practice schemes in Service Mesh and key technical points in Service Mesh with Istio as an example. Includes the Istio control plane and Istio data plane. The following content is prepared by Wei Wei to help you understand Service Mesh.

Wei wei: Good afternoon, ladies and gentlemen, just a few lecturer spoke K8S storage, PaaS in enterprise’s practice, we need to speak of is the enterprise with the PaaS platform, and on the platform to deploy a variety of services, these services are how to governance, the relationship between the service and the service, as well as the problems such as how to maintain, Service Mesh, which emerged in the last two years, makes it easier to manage these services.

Service Mesh is a dedicated infrastructure layer that addresses the communication and governance issues between services after microservitization of the system architecture. In practice, there are many solutions to the Service Mesh, but they all have common characteristics, such as the macro architectural abstraction mentioned here, which is divided into Control Plane and Data Plane, the overall architectural design.

The second feature, the Service Mesh, is basically a set of lightweight Service proxies that are deployed with the application logic Service. It implements routing, circuit breakers, Service discovery, and so on in a proxy manner that is transparent to the application Service, of course on K8S. If the microservice architecture is not based on Service Mesh, it can also be based on SpringCloud. However, SpringCloud has its own limitations and is mainly used in the java-dominated field.

Istio, Conduit, and Nginmesh are popular practices in Service Mesh. Istio is an open source cooperative project between Google and IBM and Lyft, which is the most mainstream Service Mesh solution at present. Conduit’s design philosophy is very similar to Istio’s in every aspect. It rewrites Sidecar using Rust, and the Control Plane is taken over by Conduit Control Plane written by Go. NginMesh does not implement a full Service Mesh on its own, but replaces the Istio Envoy with Nginx.

Istio

Among Istio, Conduit and Nginmesh, Istio has the greatest influence, so we will focus on Istio today.

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

The control plane is composed of Pilot, Mixer and Citadel, and each component of the control plane is responsible for some specific functions. The data plane consists of a set of intelligent agents deployed as Sidecars that control all network traffic between microservices.

Istio control plane

The Istio control plane consists of the following components:

Pilot: Pilot is responsible for Envoy configuration, full life cycle management. Service discovery can be provided for Envoy Sidecar, enabling flexible routing (e.g., A/B testing, Canary publishing) and elasticity (e.g., Timeouts, retries, fuses, etc.), which can also translate high-level routing rules into Envoy specific configurations and propagate them to the Sidecar at run time.

Mixer: Mixer is a platform-independent component responsible for abstracting, docking, policy configuration, and gathering measurements from Envoy agents and other services for back-end systems.

More abstractly, Mixer provides:

Back-end abstraction: Mixer isolates the Istio components and services in the Mesh from the infrastructure details. Mixer: Mixer enables operations personnel to control all interactions between the Mesh and the back end of the infrastructure.

Mixer acts, in a way, as a bridge. The Envoy provides request-level attribute data that is evaluated and processed by the Mixer. Adapters in the Mixer base on this attribute data to perform logging, monitor indicator collection and presentation, quota management, ACL checking, and more.

Citadel: Provides inter-service authentication and end-user authentication functions, built-in identity and certificate management, and provides service-level policy control in addition to network policies.

Istio data plane

Envoy is Istio’s data plane. Envoy is a high-performance lightweight proxy that controls all inbound and outbound traffic for services in the service grid. Envoy offers many built-in features such as dynamic service discovery, load balancing, TLS session termination, HTTP/2& gRPC traffic proxy, fuse breakers, health checks, and more.

The Envoy deployed as sidecar is deployed in a Kubernetes Pod along with the corresponding microservice. Each microservice instance sends and receives requests through its own SidecAR; Microservices do not communicate with microservices directly, but through proxy forwarding of sidecar. Sidecar forms the call network directly, like a “grid.” There is no need to rebuild or rewrite code using sidecar proxy model code.

Note: pay attention to the speed cloud wechat subscription number, reply: 7.7 Shanghai PPT, you can download the lecturer to share PPT.