★ ServiceMesh Series
1 Introduction to Service Mesh
In the previous section we covered the basics of ServiceMesh in detail.
ServiceMesh is the latest generation of microservices architecture as an infrastructure layer that can decouple with business and solve the communication between microservices and microservices under complex network topology. Its realization form is generally a lightweight network agent and deployed with application SideCar, while being transparent to business applications.
2 Introduction to Istio
ServiceMesh is a powerful microservices architecture, but not an architectural product. Some of the more popular ServiceMesh products are Istio, Linkerd, and Consul Connect.。
One of the most popular, powerful, and trusted service grids is Istio. Founded in 2016 by Google, IBM, and Lyft, Istio is a graduate program of the Cloud Native Computing Foundation, alongside projects like Kubernetes and Prometheus.
Istio ensures the resiliency of cloud-native and distributed systems, helping modern organizations maintain their workloads across different platforms while remaining connected and protected. It enables security and governance controls, including mTLS encryption, policy management and access control, support for network functions such as canary deployment, A/B testing, load balancing, failover, and increased visibility into traffic across assets.
Istio is not limited to the boundaries of a single cluster, network, or runtime-services running on Kubernetes or VMs, multi-cloud, hybrid, or local can all be included in a single grid.
Carefully designed to be extensible and supported by a broad ecosystem of contributors and partners, Istio provides packaged integration and distribution for a variety of use cases. You can install Istio stand-alone or choose hosted support from commercial vendors offering Istio-based solutions.
Official website:/latest/
3 Istio Deployment Logic
The Istio Service Grid is logically categorized for deployment intodata planecap (a poem)control plane。
- The data plane is a set of agents that mediate and control all network communications between microservices. They also collect and report observable data on all grid traffic.
- The control plane manages and configures agents in the data plane.
Istio supports two main data plane modes:
1. Sidecar model. It will deploy an Envoy agent with each Pod you start in the cluster, or with a service running on a virtual machine.
2. Ambient mode. Use a four-tier agent per node and optionally an Envoy agent per namespace for seven-tier functionality.
4 Istio Architecture Diagram
The Istio architecture diagram is shown below:
It provides the following features:
- Provides load balancing for HTTP, gRPC, WebSocket and TCP protocols;
- Fine-grained flow control, such as A/B testing, canary deployment, etc;
- The modular plug-in design allows access via API, frequency restrictions, etc;
- Fully automated request telemetry including request tracking, monitoring and logging;
- Strong security features such as authentication, authorization, encryption, etc;
Anyway: Discovery、Configuration、Certificates
4.1 Control surfaces
The control surface is responsible for service governance, such as routing rules, traffic rules (exception retry, timeout retry, timeout protection, flow limiting, fusion), security policies, etc. It is the control core of the Service Grid, and through the control surface, you can configure the behavior of each component in the Service Grid.
In order to structure the functions of the control surfaces, Istio categorizes them intoPilot，Mixer，Citadel and other components with functions corresponding to their individual parts:
- Pilot: responsible for service discovery, load balancing, routing rules , etc., but Pilot does not provide service registration, but only to provide standardized interfaces that can be easily connected to various service registry centers , such as Eureka, Etcd , etc., and then through the service discovery to control Envoy's dynamic forwarding capabilities;
- Mixer: responsible for access control, policy enforcement, etc. In the original Istio architecture design, Mixer is the centralized component, because Mixer provides a variety of access control policies, so the load pressure of Mixer is relatively large, before initiating a request to do a logical check, the request is also required to report the end of the processing, Mixer receives a request at least up to 2 times the original request. The request received by Mixer has increased at least 2 times of the original request. In order to solve this problem , Mixer added the function of caching , logic processing and reporting are completed by the Mixer cache , so that the load pressure on Mixer can be relieved ;
- Citadel: Responsible for security functions, such as authentication authorization, etc. For example, those services with a high security level that require separate encryption processing or role control for requests, Istio makes security capabilities transparent by introducing the Citadel component;
4.2 Datasheets
As you can see on the architecture diagram, each service has a sidecar, or Envoy, which is the data plane responsible for inter-service communication and load balancing.
All requests to the service pass through the Envoy and are then forwarded to the appropriate service based on routing rules, so the Envoy is known as the entry point to the service grid.
The Envoy architecture diagram is shown below:
Envoy consists of several parts:
- listeners: listeners, responsible for listening to ports and receiving requests, such as listening to port 10000 in the above configuration file;
- filter Chains: Filter Chains, can be configured in the configuration file for the processing of the request chain, you can be in any socket, according to our needs to splice multiple filters, to achieve the traffic, different functions of the processing, such as the above configuration file of the filter chain, in the listener to add the HttpConnectionManager filter, this filter is responsible for parsing the HTTP protocol; this filter is responsible for parsing the HTTP protocol. This filter is responsible for parsing the HTTP protocol;
- cluster defintios: sets forwarding to a downstream upsteam server, such as the cluster defintios in the configuration file above, setting forwarding to the
xxxdomain name
Envoy provides the xDS API standard (x-discovery service), which is the service discovery service Envoy obtains configuration information through the xDS API, and then forwards the information according to the configuration information, including several types, namely: EDS (endpoint discovery service), LDS (listener discovery service) and CDS (cluster discovery service), which correspond to node service discovery and cluster service discovery. service), corresponding to the realization of node service discovery, listener service discovery and cluster service discovery.
4.3 Control-plane and data-plane interaction processes
The entire delivery process is divided into 3 steps: administrators use the control plane to configure the policy, the policy is distributed to the data plane, and the data plane policy takes effect.
4.3.1 Configure istioctl, kubectl , call k8s api process
4.3.2 Pilot Policy Dissemination via xDS Interface
4.3.3 Flow strategy implementation process
5 Summary
- Service Mesh is the next generation of microservices architecture
- Istio is an implementation architecture of ServiceMesh, which mainly contains data plane and control plane, and their interaction steps are as follows:
- Control surface support strategy configuration
- Strategies are sent down to the data plane
- Data plane policies take effect and enable traffic governance