Idou Teacher teaches you to learn Istio05: How to implement Intelligent routing configuration with Isito

Overview

To introduce Istio request routing, we can't help but start with pilot and envoy. In the service grid, the pilot manages and configures all envoy instances. In the pilot, you can configure almost all of the traffic-oriented rules and other recovery rules. Envoy will not only get the basic load balancing information from the pilot, but also the periodic health checks that will tell all envoy other instances of the current state of operation. Load balancing information, and health check information, can enable envoy to distribute traffic more intelligently.

In the pilot structure above, it is not difficult to understand, platform adapter as a platform adapter, you can make istio smoothly under any platform to work. The Envoy API provides dynamic update information, service discovery, and the ability to configure routing rules.

Request routing

In Istio, the existence of Envoy provides a controllable and visible basic condition for flow inflow and outflow. Envoy according to the information maintained on the one hand to the request traffic to balance the workload of each pod, to ensure that there is no extreme situation but "rain equitably". On the other hand, Envoy's distribution of request traffic is not perceptible from the user's point of view.

The user accesses service A through an address, and service A's envoy discovers the presence of service B in the grid in real time and distributes traffic according to the established forwarding rules (1% to POD4 Access B ' version of the remaining 99% based on load balancer information into POD1-POD3 Access B version). It is also the design that envoy hangs on the outside of the service to facilitate the development and operation of personnel for fault testing, fusing and real-time monitoring.

Virtualservice & Destinationrule

Virtualservice

The virtualservice is primarily defined by the routing rules of the request, and when a request satisfies a previously scheduled path, the request is routed to the default service. Let's look at a simple Virtualservice example:

In this virtualservice, the green range of the host has two content, the first is the short name of the service, in fact, the name is omitted after the FQDN, here should be reviews.default.svc.cluster.local

The middle mark is the namespace of the rule, not the namespace where the reviews is located. The second is the address that is configured for load-balanced access to the reviews component. The XXX section is the routing address, where the subset corresponds to the version in the service.

Destinationrule

Destinationrule is a traffic access policy after routing, the Access policy contains load balancing algorithm, fuse and other restrictions. is an example of a destinationrule:

The XXX section is clearly two versions of the service. The meaning of the green part is Trafficpolicy, which is configured with the load balancing algorithm set to the minimum number of connections, when two hosts provide services, will automatically select the minimum number of connections to the host. We can also configure connection pooling, TLS connection, port level policy, and automatic removal of unhealthy host settings.

Connection Pool Management

The connection pool is configured to the upstream host, which means that all of the link requests that the host obtains from envoy follow the configured connection pooling principles, which can be either assigned to the TCP layer or to the HTTP layer.

HTTP Connection Pool Configuration

Http1maxpendingrequests: The maximum number of wait requests to the target host, if not set by default is 1024, which is set for http1.1, is not affected for HTTP2 because the request is not queued.

Http2maxrequests: The maximum number of requests to the backend is not set to default to 1024,

Maxrequestsperconnection: The maximum number of requests per connection, if this property value is set to 1, then each connection sends a maximum of one request, that is, the connection cannot be maintained.

Maxretries: Maximum number of retries.

TCP Connection Pool Configuration

MaxConnections: The maximum number of connections, but only works on http1.1 and is not used for HTTP2, because the latter only establishes one connection.

CONNECTIONTIMEOUT:TCP Connection Timeout

Load Balancer Configuration

Load Balancing Overview

There are two types of load balancing: The load balancing algorithm and the consistent hash based. The configuration based on the load-balancing algorithm is very simple, as long as the Simplelb with the response field.

Algorithm field Description
Round_robin simple rotation algorithm, which is also the default way
Least_conn randomly selects two healthy hosts, and selects one of the few connections in both
Randomly selected in the random health host
Paasthrough direct distribution to the destination address host
A consistent hash-based load-balancing approach can provide soft session affinity based on HTTP Header,cookie, but this load-balancing method only supports HTTP connections.

Algorithm field Description
Httpheadername hash based on HTTP header
HttpCookie hash based on HTTP cookie
USESOURCEIP hash based on IP address
Minimumringsize minimum number of virtual nodes in the hash ring, default is 1024

Load Balancing Sample

The load balancing policy configuration is flexible and can be configured for a service, and all pods that are subordinate to the service will be allocated according to the configured load Balancing method, in addition to the Istio allows the user to make a deeper configuration and load-balance the version of the service. Pods that are configured to conform to this version will be allocated according to the load balancing pattern in the deep configuration, while the rest are also distributed according to the load Balancing mode at the service level.

Summarize

This article only introduces a small part of the content of Istio request routing, its flexible configuration, non-intrusive design, cross-platform support greatly improves development efficiency and reduces the difficulty of testing. In-depth understanding of virtualservice,destinationrule is the basic premise of using istio functionality, and skilled use of connection pooling and load balancing configurations maximizes application performance with limited resources.

Welcome attention to the public number "container cube", if you want to join the container communication technology Group, add Administrator Monicka, apply for the group, the container circle of people look over ~

Idou Teacher teaches you to learn Istio05: How to implement Intelligent routing configuration with Isito