Link to this blog: https://security.blog.csdn.net/article/details/128449214
1. The concept of microservices
Microservices is to split all the modules in a complete application into multiple different services, each of which can be independently deployed, maintained and expanded, and usually communicate with each other through RESTful APIs. These services revolve around business capabilities build, and each service can use different programming languages and different data storage technologies.
The essence of microservice design is to use services with clearer functions and more refined business to solve larger and more practical problems.
2. The concept of service mesh
A service mesh is typically implemented through a set of lightweight network proxies that are deployed alongside the application without being aware of the application itself.
The service grid runs next to the service as a sidecar, which is transparent to the application. All traffic passing through the application will pass through the sidecar. Therefore, the sidecar implements traffic control functions, including service discovery, load balancing, intelligent routing, fault injection, and fuse device, TLS termination, etc. The emergence of the service grid separates microservice governance from the application itself, greatly reduces the code coupling degree through the form of sidecar, and makes microservice management no longer complicated.
At present, the more popular service grids include Istio, Linkerd, Envoy, NginMesh, Conduit, etc. Among them, Istio has become the industry standard for service grids due to the popularity of the community and the joint development investment of major manufacturers.
3. Introduction to lstio (istio)
3.1. Istio architecture
Istio is a microservice management framework and is also considered to be a representative implementation of service grid. It is an open source project jointly developed by Google, IBM and Lyft. The architecture diagram is as follows:
The design of the Istio architecture is similar to the software-defined network (SDN). It is mainly divided into two parts: the control plane and the data plane. The data plane consists of a set of agents and is deployed next to the service in the form of Sidecar. These agents are responsible for managing all services between services. Network communication; the control plane is used to manage and configure the agents of the data plane. There are many benefits of this design. First, there is no need to change the business container code, so that the application can be transparent to the greatest extent and make the application unaware of proxy injection; on the other hand, Istio's open interface and flexible deployment mechanism have greatly improved It improves scalability and portability; finally, Istio's unified policy management also decouples many service-based policies from Sidecar, and manages them uniformly through APIs, thus simplifying operating costs.
3.2. Data plane
Istio's data plane consists of a set of network proxies. The default proxy used by Istio is Envoy. Of course, it can also be replaced by other proxies, such as linkerd, nginmesh, moison or the proxies written by developers themselves. Envoy is a high-performance proxy developed on the basis of C++ to mediate all inbound and outbound traffic of services in the service mesh. The Envoy proxy is the only component that interacts with Istio data plane traffic.
The core of Envoy is L3/L4 and L7 layer network proxy. Through Envoy's internal Filter mechanism and open Filter programming interface, developers can use Envoy's existing Filter or custom Filter to manage business traffic in a fine-grained manner.
Envoy's built-in functions include "service discovery", "load balancing", "TLS termination", "HTTP/2", "GRPC proxy", "circuit breaker", "health check", "grayscale based on percentage traffic splitting" Release", "Fault Injection", etc.
Envoy is usually deployed as a sidecar in Istio, and the sidecar is deployed in the same pod as the business container. This deployment mode allows Istio to extract a large amount of traffic-related information as metadata. Istio can use these metadata to implement corresponding policies, and at the same time send metadata to external monitoring systems, such as Prometheus, Zipkin, Jaeger, etc., to visualize the behaviors occurring in the service grid.
3.3. Control plane
Istiod is the control plane component of Istio, and istiod includes three subcomponents: Pilot, Citadel, and Galley.
Pilot
Pilot is responsible for providing service discovery for Envoy Sidecar, providing traffic management for intelligent routing and resilience (A/B testing, canary deployment, timeouts, retries, circuit breaking, etc.), and converting advanced routing rules that control traffic into specific Envoy configuration, and propagated to the Envoy/Sidecar container at runtime.
From the above figure, we can see that the interaction process is mainly divided into the following three steps:
1. The platform starts a new instance of the service, and the instance notifies Pilot's platform adapter;
2. The platform adapter uses Pilot's abstract model to register the instance;
3. Pilot sends traffic rules and configurations to the Envoy agent on the data plane;
It can be seen that this loosely coupled design allows Istio to run in multiple environments such as Kubernetes, Consul or Nomad, while maintaining the same Operator interface for traffic management.
Citadel
Citadel is the security module of Istio. Through built-in identity and certificate management, it can support strong service-to-service and end-user authentication. At the same time, we can use Citadel to upgrade unencrypted traffic in the service grid.
Galley
Galley is the core component for verification, extraction, processing, and distribution in the Istio configuration process. It does not directly provide business capabilities to the data plane, but provides support to other components on the control plane, so that other components only need to deal with Galley. Thus decoupling from the underlying platform (such as Kubernetes).
4. Features of Istio
4.1, Istio traffic management
Istio has a wealth of traffic management functions, including request routing, fault injection, and traffic migration.
request routing
Istio supports user-delivered request routing policies, which are mainly used to redirect access service traffic to a specific version, so as to realize canary deployment (canary release refers to gradually updating the back-end application in the production environment in stages version (requires flow control capabilities), and after a small-scale verification meets expectations, it will be promoted to the entire production environment). This method brings many benefits when testing new projects online.
fault injection
Istio's fault injection mechanism is mainly used to test the fault recovery capability of the entire application. Ultimately, it can ensure that the fault strategy will not be incompatible and restrictive. Unlike the fault mechanism introduced at other network layers, Istio injects faults at the application layer. , so that more results can be obtained, such as using the http status code to indicate the failure result.
traffic migration
Traffic migration refers to the gradual migration of traffic from one version of the application to another version. In Istio, this goal can be achieved by configuring a series of rules. For example, 50% of the traffic in the request can be sent to the v1 version of a service A , and the remaining 50% of the traffic is sent to the v2 version of service A. Then, the migration is done by adjusting the threshold to eventually send 100% of the traffic to the v2 version of Service A.
4.2. Istio security
Istio can provide signed certificates for services in the service grid through the Citadel component to ensure the communication security between microservices. In addition, Istio's authentication and authorization mechanism provides a relatively secure access environment for service grid services.
4.3. Istio Observability
Since the entire architecture of Istio includes monitoring and visualization tools such as kiali, Prometheus, and Grafna, it is possible to visualize the service call chain and the number of requests in the service grid, so that the service grid has better observability.