[Cloud native | Learning istio from scratch] 2. Istio core features and architecture

Istio core features

1. Traffic management
circuit breakers, timeout, retry, multi-routing rules, AB test, grayscale release, traffic distribution according to percentage, etc.

2. Security
encryption, identity authentication, service-to-service permission control, container-to-container permission control in K8S, etc.

3. Observability
tracking, monitoring, data collection, and comprehensive understanding of uplink and downlink traffic, service link status, service operation, system performance, and domestic microservice architecture system through the control background are relatively lacking.

4. Platform support (platform support)
K8s, physical machines, and their own virtual machines are no problem.

5, integration and customization (integration and customization)
can be customized to expand the function.

breaker

Explain circuit breaker with an example from life

When a circuit fails or is abnormal, the current is continuously increased, and the increased current may damage some important components in the circuit, or may burn the circuit or even cause a fire. If the fuse is correctly placed in the circuit, the fuse will cut off the current by itself when the current abnormally rises to a certain height and heat, thus protecting the safe operation of the circuit.

Many technologies are derived from life. With social progress and technological development, circuit breakers are also called service fuses. When multiple service calls are made, service A depends on service B, and service B depends on service C. If the response time of service C exceeds If it is too long or unavailable, service B will occupy too much system resources, while service A also depends on service B, and also occupies a lot of system resources, causing system avalanches. The Istio circuit breaker intercepts and judges the traffic through the sidecars in the grid, avoiding the intrusion of control logic in the code, and it is very convenient to realize the ability of service fuse.

In the microservice architecture, in the case of high concurrency, if the number of requests reaches a certain limit (you can set the threshold yourself) and exceeds the set threshold, the circuit breaker will automatically turn on the service protection function, and then return a friendly service by degrading the service. Prompt to the client (non-computer professionals may not understand the error code 504). Suppose that when 10% of the 10 requests fail, the circuit breaker will be turned on, and calling this service again at this time will directly return the failure and no longer call the remote service. After 10s, the trigger condition is re-detected to determine whether to close the fuse or continue to open it.

Service degradation (improving user experience)

For example, e-commerce platforms will have some seckill scenarios for 618 and Double 11. During the seckill, there will be a large number of requests, and an error message may be returned: "There are currently too many requests, please try again later." When the service cannot be provided, the consumer will call the downgrade operation, return information such as service unavailability, or return the information written on the static page prepared in advance.

time out

When do you need to use a timeout?

In the production environment, it is often encountered that the caller waits too long for the downstream response, and the accumulation of a large number of requests blocks its own service, causing an avalanche. Timeout processing is used to avoid failures caused by indefinite waiting, thereby enhancing service availability. . understand by example

The nginx service sets the timeout time to 3 seconds. If it exceeds this time, it will not wait and return a timeout error. The
httpd service sets a response time delay of 5 seconds. Any request needs to wait for 5 seconds before returning to the
client. Go to the reverse proxy by accessing the nginx service For the httpd service, since the httpd service takes 5 seconds to return, but the nginx service only waits for 3 seconds, the client will prompt a timeout error.

Retry

The istio retry mechanism is the maximum number of times the Envoy proxy will try to connect to the service if the invocation of the service fails. By default, the Envoy proxy does not attempt to reconnect to the service after a failure.
for example:

The client calls nginx, and nginx forwards the request to tomcat. Tomcat stops external services through fault injection, and nginx is set to retry 3 times if access to tomcat fails.

Multiple routing rules

1. HTTP Redirect

2. HTTP Rewrite

3. HTTP Retry (HTTPRetry)

4. HTTP Fault Injection

5. HTTP Cross-Origin Resource Sharing (CorsPolicy)

Istio Architecture

The istio service mesh is logically divided into data plane and control plane.

1. The data plane consists of a set of intelligent agents (Envoy+Polit-agent) deployed in the sidecar mode. These proxies host and control all network communication between microservices, managing ingress and egress traffic, similar to frontline workers. Sidecar is generally bound to the business container (injected into the business pod by automatic injection in Kubernetes) to hijack the traffic of the business application container, accept the control of the control plane component, and output logs, For tracking and monitoring data, Envoy and pilot-agent are in the same mirror, the sidecar Proxy.

2. Control plane The control plane is responsible for managing and configuring proxies to route traffic.
A new deployment mode is used in istio1.5+, the control plane is rebuilt, and the original multiple components are integrated into a single structure istiod. This component is the core of the control plane and manages all the functions of Istio, mainly including Pilot , Mixer, Citadel and other service components.

istiod is the biggest change in the new version. It replaces the original architecture with a single component, which reduces the complexity and maintenance difficulty. However, the original multi-component is not completely removed, but a module after refactoring. The forms are integrated together to form the istiod.

Combined with the following figure, we can understand the function of each component of Istio and the way they cooperate with each other.

1. Automatic injection: Automatically inject the Sidecar proxy Envoy program when the application is created. When a Pod is created in Kubernetes, Kube-apiserver calls the Sidecar-Injector service of the control plane component, automatically modifies the application description information and injects the Sidecar. When actually creating a Pod, create a Sidecar container in the Pod where the business container is created.

2. Traffic interception: Set iptables rules when the Pod is initialized, and intercept the inbound and outbound traffic of the business container to the sidecar based on the configured iptables rules. The applications are not aware of the existence of Sidecar, and still access each other in the original way. In the above figure, the traffic flowing out of the frontend service will be intercepted by Envoy on the frontend service side, and when the traffic reaches the forecast container, the inbound traffic will be intercepted by Envoy on the forecast service side.

3. Service discovery: Envoy of the service initiator calls the service discovery interface of the control plane component Pilot to obtain the instance list of the target service. In the above figure, Envoy on the frontend service side obtains the address of each instance of the forecast service through the service discovery interface of Pilot.

4. Load balancing: Envoy of the service initiator selects the service instance according to the configured load balancing policy, and connects to the corresponding instance address. In the above figure, each Envoy on the data plane obtains the load balancing configuration of the forecast service from the Pilot and performs load balancing actions.

5. Traffic governance: Envoy obtains the configured traffic rules from Pilot and executes governance logic when intercepting inbound and outbound traffic. In the above figure, Envoy on the frontend service side obtains traffic governance rules from Pilot, and distributes traffic with different characteristics to the v1 or v2 version of the forecast service according to the traffic governance rules.

6. Access security: When accessing between services, two-way authentication and channel encryption are performed through Envoy on both sides, and authorization management is performed based on the identity of the service. In the above figure, Pilot issues security-related configuration, and automatically loads certificates and keys on Envoy of frontend service and forecast service to achieve mutual authentication. The certificates and keys are maintained by another management plane component, Citadel.

7. Service monitoring: When communicating between services, the Envoys on both sides of the communication will connect to the management plane component Mixer to report access data, and forward the data to the corresponding monitoring backend through the Mixer. In the above figure, the access monitoring indicators, logs and call chains of the frontend service to the forecast service can be collected to the corresponding monitoring backend in this way.

8. Policy execution: When accessing services, use Mixer to connect back-end services to control access between services, and determine whether to allow or deny access. In the above figure, the Mixer backend can connect to a current-limiting service to perform rate control and other operations on the access from the frontend service to the forecast service.

9. External access: There is an Envoy at the ingress of the mesh that acts as the ingress gateway. In the above figure, the external service accesses the ingress service frontend through the Gateway, and the load balancing and some traffic governance policies for the frontend service are executed on this Gateway.

Sidecar and proxy go hand in hand, just like a car and wheels. In the future, sidecar and proxy refer to the proxy process that provides basic capabilities after the microservice process is decoupled into two processes.

write at the end

It is not easy to create, if you think the content is helpful to you, please give me a three-link follow to support me! If there are any mistakes, please point them out in the comments and I will change them in time!

Series currently being updated: Learning istio from scratch

Thank you for watching, the article is mixed with personal understanding, if there is any error, please contact me to point out~