Introduction to istio
foreword
After the study of docker and k8s, I finally got to the chapter of service grid. After deep thinking, I decided to change the article of docker and k8s into a paid column after reaching 20,000 fans, so those who want to read it, hurry up!
Introducing Istio
Official explanation: An open platform to connect, secure, control and observe services.
Translated, it is "an open platform for connection, security hardening, control and observation services". An open platform means that it is open source, and services correspond to microservices, which can also be roughly understood as a single application.
1. Connect: intelligently control the call traffic between services, enabling functions such as grayscale upgrade, AB testing, and blue-green deployment
2. Security: Automatically provide authentication, authorization, and encryption for calls between services.
3. Control: Apply user-defined policies to ensure fair distribution of resources among consumers.
4. Observe: View various data during the operation of the service, such as logs, monitoring and tracing, to understand the operation of the service.
Istio is the productized implementation of ServiceMesh. By adding a sidecar proxy to the existing server, the application does not need to change the code, or only needs to change a little code, and the following basic functions can be realized:
1. Help establish connections between microservices, help the R&D team to better manage and monitor microservices, and make the system architecture more secure;
2. Help the decoupling of microservice layers, and the decoupled proxy layer can focus more on providing infrastructure capabilities
E.g:
(1) service discovery (discovery);
(2) load balancing (load balancing);
(3) failure recovery (failure recovery);
(4) service metrics (metrics);
(5) service monitoring (monitoring);
(6) A/B testing;
(7) canary rollouts;
(8) rate limiting;
(9) access control;
(10) identity authentication ( end-to-end authentication).
Service registration and discovery
RPC: RPC (Remote Procedure Call) remote procedure call, a simple understanding is that a node requests services provided by another node
load balancing
Distribute front-end requests to multiple servers in the background
Recovery
Self-recovery ability in case of failure
Service Metrics
For HTTP, HTTP/2 and GRPC traffic, Istio generates the following metrics:
1. Request count (istio_requests_total): This is a COUNTER metric that accumulates each request handled by the Istio proxy.
2. Request duration (istio_request_duration_seconds): This is a DISTRIBUTION metric used to measure the duration of a request.
3. Request size (istio_request_bytes): This is a DISTRIBUTION indicator used to measure the size of the HTTP request body.
4. Response size (istio_response_bytes): This is a DISTRIBUTION indicator used to measure the size of the HTTP response body.
For TCP traffic, Istio generates the following metrics:
1. TCP Sent Bytes (istio_tcp_sent_bytes_total): This is a COUNTER metric that measures the total number of bytes sent during a response under a TCP connection.
2. Tcp Received Bytes (istio_tcp_received_bytes_total): This is a COUNTER metric used to measure the total number of bytes received during a request under a TCP connection.
3. Tcp open connections (istio_tcp_connections_opened_total): This is a COUNTER indicator used to accumulate each open connection.
4. The number of Tcp closed connections (istio_tcp_connections_closed_total): This is a COUNTER indicator used to accumulate each closed connection.
grayscale release
Grayscale release is also called canary release. The origin is that mine workers found out that canaries are very sensitive to gas gas. Before going down the mine, the miners would put a canary into the well. If the canary stopped calling, It means that the gas concentration is high.
After the grayscale release starts, a new version of the application is launched first, but the traffic is not directly cut, but the testers test the new version online, and the new version of the application launched is our canary. If there is no problem, you can import a small amount of user traffic to the new version, and then observe the running status of the new version and collect various runtime data. /B test.
After confirming that the new version is running well, gradually import more traffic to the new version. During this period, you can continuously adjust the number of running server copies of the old and new versions, so that the new version can withstand more and more high flow pressure. Until 100% of the traffic is switched to the new version, and finally the remaining old version services are closed to complete the grayscale release.
If a problem with the new version is found during the grayscale release (grayscale period), the traffic should be switched back to the old version immediately, so that the negative impact will be kept to a minimum.
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~