Shulou(Shulou.com)05/31 Report--

Editor to share with you what are the benefits of Istio traffic management in kubernetes, I believe most people do not know much about it, so share this article for your reference, I hope you can learn a lot after reading this article, let's go to know it!

One: brief introduction

The core component of Istio traffic management is Pilot, which manages and configures all Envoy proxy instances deployed in a particular Istio service grid. It allows you to specify what routing traffic rules are used between Envoy agents and to configure recovery features such as timeouts, retries, and fuses. It also maintains a specification model for all services in the grid and uses this model to let Envoy know about other instances in the grid through discovery services. Each Envoy instance maintains load balancer information, which is based on the information obtained from Pilo and regular health checks of other instances in its load balancer pool. This allows it to intelligently distribute traffic between target instances while following its specified routing rules.

Second: the benefits of traffic management

The traffic management model using Istio is essentially decoupling traffic from infrastructure expansion, allowing operators to specify what rules traffic should follow through Pilot, rather than executing which pod/VM should receive traffic-Pilot and intelligent Envoy agents help us. So, for example, you can specify through Pilot that 5% of traffic from a particular service can be directed to the canary version, regardless of the size of the canary deployment, or send traffic to a specific version based on the content of the request.

Decoupling traffic from the infrastructure extension allows Istio to provide a variety of traffic management capabilities outside of the application code. In addition to the dynamic request routing, roll-out, and canary release tested by Apex B, it uses timeouts, retries, and fuses to handle fault recovery and, finally, fault injection to test the compatibility of recovery strategies between services. These functions are implemented through Envoy sidecar/ agents deployed in the service grid.

Pilot is responsible for the lifecycle management of Envoy instances deployed in the Istio service grid.

As shown in the figure above, Pilot maintains a canonical representation of services in the grid, independent of the underlying platform. The platform-specific adapters in Pilot are responsible for populating this specification model appropriately. For example, the Kubernetes adapter in Pilot implements the necessary controllers to monitor changes to pod registration information in Kubernetes API server, Ingress resources, and third-party resources used to store traffic management rules. The data is translated into a canonical representation. Envoy specific configurations are generated based on canonical representations.

Pilot exposes API for dynamic updates of service discovery, load balancing pools, and routing tables. These API frees Envoy from platform-specific nuances, simplifies design and improves cross-platform portability.

Operation and maintenance personnel can specify advanced traffic management rules through Pilot's Rules API. These rules are translated into low-level configurations and distributed to the Envoy instance through discovery API.

Three: request routing

As mentioned by Pilot, the specification of services in a particular grid is maintained by Pilot. The Istio model of the service is independent of the expression in the underlying platform (Kubernetes,Mesos, Cloud Foundry, etc.). Platform-specific adapters are responsible for obtaining various fields of metadata from their respective platforms and then populating the service model. Istio introduces the concept of service version, which can be further subdivided into services by version (v1, staging,prod) or environment (v2). These versions are not necessarily different API versions: they may be different iterations of the same service deployed in different environments (prod,staging, dev, etc.). Common scenarios that use this approach include Ascarb B testing or canary deployment. Istio's traffic routing rules can provide additional control over traffic between services according to the version of the service.

IV: communication between services

As shown in the figure above, the client of the service is not aware of the differences between different versions of the service. They can continue to access the service using the hostname or IP address of the service. The Envoy sidecar/ agent intercepts and forwards all requests and responses between the client and the server.

Operators use Pilot to specify routing rules, and Envoy dynamically determines the actual choice of its service version based on these rules. This model enables application code to decouple it from the evolution of its dependent services while providing other benefits (see Mixer). Routing rules enable Envoy to make version selection based on criteria such as header, labels associated with the source / destination, and / or weights assigned to each version.

Istio also provides traffic load balancing for multiple instances of the same service version. You can find more information in service discovery and load balancing.

Istio does not provide DNS. Applications can try to parse FQDN using DNS services that exist in the underlying platform (kube-dns,mesos-dns, etc.).

Five: service discovery and load balancing

Service registration: Istio assumes that a service registry exists to track the pod/vm of services in the application. It also assumes that new instances of the service are automatically registered in the service registry and that unhealthy instances will be automatically deleted. Platforms such as kubernetes,mesos already provide this capability for container-based applications.

Service discovery: Pilot uses information from service registrations and provides a platform-independent service discovery interface. The Envoy instance in the grid performs service discovery and dynamically updates its load balancing pool accordingly.

As shown in the figure above, services in the grid access each other using their DNS names. All HTTP traffic for the service is automatically rerouted through Envoy. Envoy distributes traffic between instances in the load balancing pool. Although Envoy supports a variety of complex load balancing algorithms, Istio currently allows only three load balancing modes: round robin, random, and weighted minimum requests.

In addition to load balancing, Envoy periodically checks the health of each instance in the pool. Envoy follows the fuse style pattern, classifying instances as unhealthy or healthy based on the failure rate of health check API calls. In other words, when the number of health check failures for a given instance exceeds a predetermined threshold, it will pop up from the load balancing pool. Similarly, when the number of health checks passed exceeds a predetermined threshold, the instance will be added back to the load balancing pool. You can learn more about the fault handling capabilities of Envoy in troubleshooting.

Services can proactively lighten their burden by using HTTP 503to respond to health checks. In this case, the service instance is immediately removed from the caller's load balancing pool.

Six: fault handling

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

Timeout

Limited retry function with overtime budget and variable jitter (interval) between retries

Limit on the number of concurrent connections and upstream service requests

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

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

These features can be dynamically configured at run time using Istio's traffic management rules

Seven: fine-tuning

Istio's traffic management rules allow operators to set global default values for failure recovery for each service / version. However, consumers of the service can also override the default values for timeouts and retries with request-level values provided by special HTTP headers. In the implementation of the Envoy agent, the corresponding Header are x-envoy-upstream-rq-timeout-ms and x-envoy-max-retries, respectively.

Eight: fault injection

Although Envoy sidecar/proxy provides a large number of fault recovery mechanisms for services running on Istio, it is still necessary to test the end-to-end fault resilience of the entire application. 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 Pod, creating packet delay or damage at the TCP layer. Our reason is that regardless of the failure at the network level, the faults observed at the application layer are the same, and more meaningful faults (such as HTTP 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.

These are all the contents of this article entitled "what are the benefits of implementing Istio traffic management in kubernetes?" Thank you for reading! I believe we all have a certain understanding, hope to share the content to help you, if you want to learn more knowledge, welcome to follow the industry information channel!

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.