Shulou(Shulou.com)06/02 Report--

What is 1 Istio?

Istio version 1.0 was released on time in the morning of August 1, and the core features have been supported in the production environment, and articles have been reproduced on official Wechat accounts and blogs. So what exactly is Istio? What will solve the problem?

1. Istio is another open source work of Google after Kubernetes, and the main participating companies include Google,IBM,Lyft. It provides a complete non-intrusive micro-service governance solution to solve application network governance problems such as micro-service management, network connectivity and security management.

2. It can realize load balancing of micro-services, authentication and authorization between services, traffic monitoring and governance without modifying any code. From the perspective of the entire infrastructure, it can be understood as a supplement to a micro-service management platform on the PaaS platform.

2 Istio and Kubernetes

Kubernetes provides deployment, upgrade and limited running traffic management capabilities; use the mechanism of service to register, discover and forward services, and have certain forwarding and load balancing capabilities through kubeproxy. However, it does not have the ability of upper layer, such as circuit breaker, current limit degradation, call chain management and so on.

Istio well makes up for this part of K8s' ability in micro-service governance, and it is also built on K8s, but it is not a completely new set like SpringCloud Netflix. Istio is a key part of Google's microservices governance.

3 introduction of Istio traffic management capabilities

Istio for connection, protection, control, and observation services.

Today, let's talk about the first main function of Istio-connection service.

In that case, three questions arise:

How does Istio implement the connection between services?

What traffic management capabilities do you have after connecting?

How to tell Istio to use these abilities?

3.1How does Istio connect services?

As shown in the Istio architecture diagram above, let's focus on the Pilot on the control plane, which is the core component of Istio for traffic management.

On the data side, one Proxy is injected into each Service. Istio sends configuration information to the Proxy of each Service on the data side through Pilot, thus indirectly controlling the connection between each Service and with the outside through these Proxy. Proxy is usually implemented using another well-known open source project, Envoy.

A combination of Pilot and (N + N) (Service+Proxy) forms a Service Mesh, that is, a service grid. With this set of service grid system, it is easy to manage the traffic between services.

3.2 what traffic management capabilities do you have after connecting?

From the perspective of traffic management between services, Istio can achieve these four functions: request routing, service discovery and load balancing, fault handling and fault injection.

3.2.1 request routing

As shown in the figure above, Istio introduces the concept of service version, which can be further subdivided by (Current Version, Canary Version) two versions. Based on this division, through Pilot, you can send Proxy configured to Service A so that 95% of its traffic is routed to the Current version of Service B and 5% of the traffic is routed to the Canary version of Service B. Of course, you can also choose both rain and dew, each with 50% of the traffic, or the overbearing president, so that the Canary version accounts for 100% of the traffic.

As shown in the figure above, in addition to distributing traffic between different versions by percentage, you can also route the request to different versions according to the content of the request. For example, you can release a version of Canary that is accessible only to users who use Macbook laptops, have the windows operating system installed, and use 360 browsers.

All these changes, you only need to change a configuration file called VirtualService, blink of an eye, Istio has been through Pilot to help you distribute the new configuration.

3.2.2 Service Discovery and load balancing

As shown in the figure above, the service grid has three dynamic cycles of life cycle: service registration, service discovery, and load balancing.

Usually, container management platforms such as kubernetes and mesos have provided service registries to track the load instances of services, so Pilot can easily get all the service registration information in the service grid and inform the Proxy of all services. Proxy performs service discovery based on this information and dynamically updates its load balancing pool accordingly. A service usually has multiple load instances, and when Service A requests Service B, it can configure different load balancing modes: polling, random, and weighted minimum requests. Suppose a load instance of Service B fails, because the Proxy in Service A performs service discovery on a regular basis, so that the failed instance can be discharged from its load balancer pool in a timely manner.

3.2.3 Fault handling

Envoy provides a set of out-of-the-box, optional fault handling functions, which is of great benefit to services in applications. These features include:

1. Timeout

two。 With overtime budget and limited retry, the length of time between retries can be jitter

3. Limit on the number of concurrent connections and upstream service requests

4. Actively (periodically) run health checks for each member of the load balancing pool

5. Fine-grained fuses (passive health check)-for every instance in the load balancing pool

Take Service A's request to call Service B as an example.

For function 1. If Service B clearly knows that the timeout after 10s will inevitably lead to failure, it will shorten the timeout, so that Service A can know the results and respond more quickly, which is a wise move.

For function 2. For overloaded Service B, the jitter between retries greatly reduces the impact of retries, while the timeout budget ensures that Service A gets a response (success / failure) within a predictable time frame.

For function 3. Limiting the number of connections and requests to Service B by Service An or other services can protect Service B from DDOS attacks or crash under heavy traffic load.

For functions 4 and 5. The combination of active and passive health checks minimizes the chances of accessing unhealthy instances in the load balancing pool. When combined with platform-level health checks, such as those supported by Kubernetes or Mesos, applications can ensure that unhealthy load instances are quickly removed from the service grid, minimizing the impact of request failures and delays.

In summary, these functions enable the service grid to tolerate failed nodes and prevent the stability of other nodes from deteriorating due to local failures.

3.2.4 Fault injection

Although Proxy provides a large number of fault handling mechanisms for services running on Istio, it is still necessary to test the end-to-end fault resilience of the applications composed of the entire service grid. A misconfigured recovery policy (for example, incompatible / restrictive timeouts across service invocations) can cause critical services in the application to remain unavailable, thus undermining the user experience.

Istio can inject protocol-specific faults into the network without killing the load instance, creating packet delay or damage at the TCP layer. Our reason is that no matter what the failure at the network level, the failure observed at the application layer is the same, and more meaningful faults (for example, HTTP's classic 4xx and 5xx error codes) can be injected into the application layer to verify and improve the resilience of the application.

Operators can configure failures for requests that meet specific conditions, and can further limit the percentage of failed requests. Two types of faults can be injected: delay and interruption. Latency is a timing failure that simulates rising network delays or upstream service overload. An interruption is a crash failure that simulates an upstream service. Interruptions are usually in the form of HTTP error codes or TCP connection failures.

Still take the Service A request to call Service B as an example.

If Service B is given a delay of 10s or an interrupt of 503s, Service A will not get the response of the request for at least 10s or the response of the request will be 503error. Through a variety of scenario coverage tests, we can get the comprehensive performance of Service An in the face of these scenarios, so as to make targeted improvements and increase its toughness.

3.3.How can I tell Istio to use these capabilities?

Istio has four profiles to help us customize all of the above traffic management needs: VirtualService, DestinationRule, ServiceEntry and Gateway:

1. The function of request routing can be realized by configuring VirtualService.

two。 By configuring DestinationRule, the functions of service discovery and load balancing, fault handling and fault injection can be realized.

3. By configuring ServiceEntry, you can see the outside world from the services in the service grid.

4. By configuring Gateway, the services of the service grid can be seen by the whole world.

With the above four magic weapons, all our needs for traffic management of the service grid can be met.

Limited to space, let's give three simple chestnuts:

Suppose there is a service explorer with only one version v 1 in our service grid, and there is another service helloworld with two versions v 1 and v2.

If ① wants to make all requests initiated by explorer go to v1 version of helloworld and v2 version with 25% probability, you only need to configure the following two files, VirtualService and DestinationRule:

ApiVersion: networking.Istio.io/v1alpha3

Kind: VirtualService

Metadata:

Name: helloworld

Spec:

Hosts:

-helloworld

Http:

-route:

-destination:

Host: helloworld

Subset: v1

Weight: 75

-destination:

Host: helloworld

Subset: v2

Weight: 25

-

ApiVersion: networking.Istio.io/v1alpha3

Kind: DestinationRule

Metadata:

Name: helloworld

Spec:

Host: helloworld

Subsets:

-name: v1

Labels:

Version: v1

-name: v2

Labels:

Version: v2

② if you need to access www.google.com inside helloworld to get some information to tell explorer what the world is like, you need to configure the following two files, ServiceEntry and DestinationRule:

ApiVersion: networking.Istio.io/v1alpha3

Kind: ServiceEntry

Metadata:

Name: googleapis

Spec:

Hosts:

-"* .google.com"

Ports:

-number: 443

Name: https

Protocol: http

-

ApiVersion: networking.Istio.io/v1alpha3

Kind: DestinationRule

Metadata:

Name: googleapis

Spec:

Host: "* .google.com"

③ if the helloworld needs to be accessed outside the service network, not just by the explorer service, you need to configure the following two files, Gateway and VirtualService:

ApiVersion: networking.Istio.io/v1alpha3

Kind: Gateway

Metadata:

Name: helloworld-gateway

Spec:

Selector:

Istio: ingressgateway

Servers:

-port:

Number: 80

Name: http

Protocol: HTTP

Hosts:

-'helloworld.com'

-

ApiVersion: networking.Istio.io/v1alpha3

Kind: VirtualService

Metadata:

Name: bookinfo

Spec:

Hosts:

-'helloworld.com'

Gateways:

-helloworld-gateway

Http:

-route:

-destination:

Host: helloworld

Port:

Number: 9080

So far, we make a simple summary: Pilot and Proxy provided by Istio compose hundreds of services into a service grid. Based on this, we can achieve traffic management capabilities such as request routing, service discovery and load balancing, fault handling and fault injection, all of which can be achieved through simple configuration of VirtualService, DestinationRule, ServiceEntry and Gateway resources.

What kind of thunder and ground fire will be triggered by the collision of K8S and Istio in the world of Cloud Native?

rub one's eyes and wait.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.