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

This article mainly shows you "how to achieve Istio traffic management in kubernetes". The content is simple and clear. I hope it can help you solve your doubts. Let me lead you to study and learn this article "how to achieve Istio traffic management in kubernetes".

One: brief introduction

Istio provides a simple configuration model to control API calls and layer 4 communication between multiple services within an application deployment. Operators can use this model to configure service level properties, which can be circuit breakers, timeouts, retries, and some common continuous release tasks, such as canary release, Amax B testing, usage percentage control of traffic, and so on.

For example, the requirement to send 100% of the incoming traffic to the v1 version of the reviews service can be achieved with the following rules:

ApiVersion: networking.istio.io/v1alpha3 kind: VirtualServicemetadata: name: reviewsspec: hosts:-reviews http:-route:-destination: host: reviews subset: v1

The intention of this configuration is that traffic sent to the reviews service (identified in the host field) should be routed to the v1 subset of the reviews service instance. The subset in the route formulates a predefined subset name, which is defined from the target rule configuration

ApiVersion: networking.istio.io/v1alpha3 kind: DestinationRulemetadata: name: reviewsspec: host: reviews subsets:-name: v1 labels: version: V1-name: v2 labels: version: v2

One or more tags are specified in the subset to distinguish between different versions of the instance. Suppose there is a service in the Istio service grid on Kubernetes, and version:v1 means that only Pod with "version:v1" in the label will receive traffic.

The rules can be configured using the istioctl client tool, and in the case of Kubernetes deployment, you can use the kubectl command to accomplish the same task, but only istioctl checks the model during this process, so we recommend using istioctl. Configuration examples are included in the configure request routing task.

Istio contains four kinds of traffic management configuration resources, namely VirtualService, DestinationRule, ServiceEntry, and Gateway. Here are some of the key points of these resources. More information about this can be found in the web reference.

Two: Virtual Services

Virtual Services defines how requests for services are routed in the Istio service grid. For example, a Virtual Service can route requests to different versions, or even to a service that is completely different from the request. Routing can be determined by many conditions, such as the source and destination of the request, the HTTP path and Header, and the weight of each service version.

Routing rule definition

Routing rules correspond to one or more request destination hosts specified with VirtualService configuration. These hosts may or may not be the actual target load, or even may not be routable services within a grid. For example, to define routing rules for requests to the reviews service, you can use the internal name reviews or the domain name bookinfo.com,VirtualService. You can use the host field as follows:

Hosts:

-reviews

-bookinfo.com

The host field defines one or more fully qualified names (FQDN) either explicitly or implicitly. The reviews above implicitly extends to a specific FQDN, for example, in a Kubernetes environment, the full name is inherited from the cluster and namespace where VirtualService resides (for example, reviews.default.svc.cluster.local)

two。 Make rules based on source or Header

a. Qualify according to a specific user. For example, you can make a rule that only applies to Pod from a reviews service

ApiVersion: networking.istio.io/v1alpha3 kind: VirtualServicemetadata: name: ratingsspec: hosts:-ratings http:-match: sourceLabels: app: reviews.

The value of sourceLabels depends on the implementation of the service. For example, in Kubernetes, it is consistent with the Pod selection tag of the service.

b. Qualify according to the specific version of the caller. For example, the following rule modifies the previous example before the request issued by the v2 version of the reviews service will take effect:

ApiVersion: networking.istio.io/v1alpha3 kind: VirtualServicemetadata: name: ratingsspec: hosts:-ratings http:-match:-sourceLabels: app: reviews version: v2.

c. Select rules based on HTTP Header. The following rule only applies to requests that contain end-user headers and have a value of jason:

ApiVersion: networking.istio.io/v1alpha3 kind: VirtualServicemetadata: name: reviewsspec: hosts:-reviews http:-match:-headers: end-user: exact: jason.

3. Split traffic between servic

Each routing rule needs to identify one or more weighted backends and invoke the appropriate backend. Each backend corresponds to a specific version of the target service, and the version of the service is distinguished by tags. If a service version contains multiple registered instances, it will be routed according to the load balancing policy defined for the service, and the default policy is round-robin.

For example, the following rule assigns 25% of reviews service traffic to the v2 label, and the remaining 75% to v1:

ApiVersion: networking.istio.io/v1alpha3 kind: VirtualServicemetadata: name: reviewsspec: hosts:-reviews http:-route:-destination: host: reviews subset: v1 weight: 75-destination: host: reviews subset: v2 weight: 25

4. Timeout and retry

By default, the timeout for HTTP requests is set to 15 seconds, which can be overridden with routing rules:

ApiVersion: networking.istio.io/v1alpha3 kind: VirtualServicemetadata: name: ratingsspec: hosts:-ratings http:-route:-destination: host: ratings subset: v1 timeout: 10s

5. Error injection in the request

When forwarding a http request to a selected destination according to the routing rule, one or more errors can be injected into it. The error can be a delay or an exit.

The following example injects a 5-second delay into 10% of the traffic targeting ratings:v1 services.

ApiVersion: networking.istio.io/v1alpha3 kind: VirtualServicemetadata: name: ratingsspec: hosts:-ratings http:-fault: delay: percent: 10 fixedDelay: 5s route:-destination: host: ratings subset: v1

Three: DestinationRule

1. Target rule

After the request is routed by VirtualService, a series of policies configured by DestinationRule take effect. These strategies include the configuration of circuit breaker, load balancing and TLS. DestinationRule also defines a routable subset corresponding to the target host (for example, a named version). VirtualService uses these subsets when sending requests to a specific version of the service.

ApiVersion: networking.istio.io/v1alpha3 kind: DestinationRulemetadata: name: reviewsspec: host: reviews trafficPolicy: loadBalancer: simple: RANDOM subsets:-name: v1 labels: version: V1-name: v2 labels: version: v2 trafficPolicy: loadBalancer: simple: ROUND_ROBIN-name: v3 labels: version: v3

two。 Circuit breaker

A simple circuit breaker can be defined using a series of criteria, such as connections and request limits.

For example, the following DestinationRule sets a limit of 100 connections for the v1 version of the reviews service:

ApiVersion: networking.istio.io/v1alpha3 kind: DestinationRulemetadata: name: reviewsspec: host: reviews subsets:-name: v1 labels: version: V1 trafficPolicy: connectionPool: tcp: maxConnections: 100

3. Evaluation of target rules

Similar to routing rules, these policies are associated with a specific host, and if subset is specified, the decision on the specific effective subset is determined by the routing rule.

The first step in rule evaluation is to confirm the routing rules (if any) corresponding to the requested host in the VirtualService, which determines which subset (that is, a specific version) of the target service to send the request to. Next, if the selected subset defines a policy, it will begin to evaluate whether it is effective or not.

This algorithm needs to be aware that policies defined for a particular subset will only take effect if that subset is explicitly routed. For example, in the following configuration, only rules are defined for review services (there are no corresponding VirtualService routing rules).

ApiVersion: networking.istio.io/v1alpha3kind: DestinationRulemetadata: name: reviewsspec: host: reviews subsets:-name: v1 labels: version: V1 trafficPolicy: connectionPool: tcp: maxConnections: 100

Since no routing rules are defined for the reviews service, the default round-robin policy is used, and occasional requests are made to the v1 instance, and if there is only one v1 instance, all requests are sent to it. However, the above policy will never take effect, because the default route is a task done at a lower level, and the policy engine cannot know the final goal or select a matching subset policy for the request.

There are two ways to solve this problem. You can raise the routing policy to one level, requiring it to take effect on all versions:

ApiVersion: networking.istio.io/v1alpha3kind: DestinationRulemetadata: name: reviewsspec: host: reviews trafficPolicy: connectionPool: tcp: maxConnections: 100subsets:-name: v1 labels: version: v1

A better approach is to define routing rules for services, such as adding a simple routing rule to reviews:v1:

ApiVersion: networking.istio.io/v1alpha3kind: VirtualServicemetadata: name: reviewsspec: hosts:-reviews http:-route:-destination: host: reviews subset: v1

Although Istio can send traffic from all sources to all versions of the target service without defining any rules. However, once you need to make a difference to the version, you need to make the rules. Setting default rules for each service from the beginning is a recommended best practice in the Istio world.

Four: Service Entries

Istio maintains a service registry internally, to which additional entries can be added using ServiceEntry. Typically, this object is used to enable requests to services outside the Istio service grid. For example, the following ServiceEntry can be used to allow external calls to the service host on the * .foo.com domain name.

ApiVersion: networking.istio.io/v1alpha3 kind: ServiceEntrymetadata: name: foo-ext-svcspec: hosts:-* .foo.com ports:-number: 80 name: http protocol: HTTP-number: 443 name: https protocol: HTTPS

Five: Gateway

Gateway configures a load balance for HTTP/TCP traffic, which in most cases operates at the edge of the grid to enable Ingress traffic for a service.

Unlike Kubernetes Ingress, Istio Gateway only configures layer 4 to layer 6 functions (such as open port or TLS configuration). By binding a VirtualService to Gateway, users can use standard Istio rules to control incoming HTTP and TCP traffic.

For example, the following provides a simple Gateway code, together with a load balancer, to allow external https traffic for host bookinfo.com:

ApiVersion: networking.istio.io/v1alpha3kind: Gatewaymetadata: name: bookinfo-gatewayspec: servers:-port: number: 443 name: https protocol: HTTPS hosts:-bookinfo.com tls: mode: SIMPLE serverCertificate: / tmp/tls.crt privateKey: / tmp/tls.key

To configure the corresponding route for Gateway, you must define a VirtualService defined by the same host, where the gateways field is used to bind to the defined Gateway:

ApiVersion: networking.istio.io/v1alpha3kind: VirtualServicemetadata: name: bookinfospec: hosts:-bookinfo.com gateways:-bookinfo-gateway #

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.