[What is Istio? ] If you don't know, you're out, a 40-minute text can be quickly understood

Time:2022-8-5

@[toc]

foreword

This article is purely theoretical and contains the following content, read it as needed:

  • Istio concepts, service mesh, traffic management, istio architecture (Envoy, Sidecar, Istiod)
  • Virtual Service (VirtualService), Routing Rules, Destination Rules (DestinationRule)
  • Gateway, network resiliency and testing (timeouts, retries, circuit breakers, fault injection)

    What is Istio?

  • Istio is an open sourceservice mesh, transparent access toDistributed servicemiddle. It is also a platform that integrates anyLogging, Telemetry and Policy SystemsAPI interface.
  • Istio runs successfully and efficientlyDistributed Microservice Architecture, and provideSecure, Connect and MonitorA unified approach to microservices.
  • Istio helps reduceDevOpspressure,development teampressure.

What is a service mesh?

  • compositionMicroservice Network
  • accomplishInteraction between services

Application scenarios

  • Service discovery, load balancing, failover, measurement and monitoring
  • A/B testing, canary releases, rate limiting, access control, and end-to-end authentication

Why use Istio?

Service mesh is throughsidecar(sidecar) proxy service implementation,control planeMainly rightsidecarconfiguration and management, this includes:

  • for HTTP、gRPC、WebSocketandTCP trafficAutomatic load balancing.
  • through the richRouting rules, retries, failover and fault injectionFine-grained control over traffic behavior.
  • Pluggable policy layer and configuration API that supportsAccess Control, Rate Limiting and Quotas
  • All traffic within the cluster (including the ingress and egress of the cluster)Automated metrics, loggingandtrack
  • based on a strongAuthentication and AuthorizationSecure inter-service communication in the cluster.

Istio alsosupport extension, to meet your deployment needs!

Introduction to Traffic Management

  • Istio traffic routing rules can be easilyControl traffic between servicesandAPI call. can be realizedA/B testing, canary releases,based onTraffic percentagerelease.
  • out of the boxRecoveryfeatures that helpEnhance the robustness of your application, so as to better cope with the failure of the service or network that is depended on.
  • Istio's traffic management is provided byEnvoyProxy service provided. In-Grid ServicesAll traffic sent and receivedall byEnvoy proxyProcessing makes it incredibly easy to control traffic within the mesh without requiring changes to the service.

In order to divert flow through the mesh, Istio needs to knowwhere the endpoint is and belongs to which service. in order to locateservice registry, Istio will connect to a service discovery system. For example, if you have Istio installed on a Kubernetes cluster, it will automatically detect services and endpoints in that cluster.

Using this service registry,Envoy proxyTraffic can be directed to related services. Most are based onMicroservice applications, the workload of each service has multiple instances to handle the traffic, calledload balancing pool. By default, the Envoy proxy distributes traffic within the service's load balancing pool based on round-robin scheduling, sending requests to each member of the pool in order, and returning to the first pool member once all service instances have received a request once.

These APIs are also declared using Kubernetes' Custom Resource Definitions (CRDs), which can beConfigure using YAML

istio architecture

The Istio service mesh is logically divided intodata planeandcontrol plane

  • data plane: The Envoy proxy is deployed assidecar,ResponsibleOrchestrate and control microservicesCommunication between, collecting and reporting telemetry data for all mesh traffic.
  • control plane: manage and configureEnvoy proxy
    [What is Istio? ] If you don't know, you're out, a 40-minute text can be quickly understood

    Envoy

  • C++ developmentA high-performance proxy for coordinating all services in the service meshInbound and outbound traffic. Envoy proxy isUniquely interacts with data plane trafficIstio components.

Envoy proxies areSidecar deployed as a service, which logically adds many of Envoy's built-in features to the service, such as:

  • Dynamic Service Discovery
  • load balancing
  • TLS termination
  • HTTP/2 and gRPC proxy
  • fuse
  • health examination
  • Staged rollout based on percentage traffic split
  • fault injection
  • rich indicators

Sidecar

  • Allow Istio to executestrategic decision, extract richtelemetry data, then send this data tomonitoring systemto provide information on the behavior of the entire grid.
  • Sidecar proxy also allowsAdd functionality to Istio, no need to redesign the architecture or rewrite the code.

Istiod

  • Istiod offersService discovery, configuration and certificatesmanage.
  • Istiod willcontrol flowofAdvanced Routing RulesConverted to Envoy specific configuration and propagated to Sidecar at runtime.
  • Istiod is secured through the built-inIdentity and Credentialsmanagement, achieving a strongService to Service and End UserCertification.
  • Istiod acts as a certificateAuthorization (CA), generate a certificate to allow in the data planemTLS communication

    Virtual Service (VirtualService)

  • configurerequest trafficto service, based onConnectivity and Service Discoveryability.
  • Each virtual service containsa set of routing rules. can be realisedload balancing,based onTraffic percentage of different versionsrouting.

Why use virtual services?

Virtual services play a vital role in enhancing Istio traffic management byClient request and real response requestoftarget workloadTo achieve decoupling.
Based on different service versionsTraffic percentageroute, implementA/B testing, canary releases

chestnut

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - match:
    - headers:
        end-user:
          exact: jason
    route:
    - destination:
        host: reviews
        subset: v2
  - route:
    - destination:
        host: reviews
        subset: v3

hostsfield

  • host of virtual services,client requestorrouting rulestarget address.
  • The virtual service hostname can beIP address, DNS name, or depending onan abbreviation for platform(short name for Kubernetes service) Wildcards can also be used(“*”)prefix

routing rules

  • httpfield contains the virtual service'srouting rules, to describeMatching Conditions and Routing Behavior, they putHTTP/1.1、HTTP2 和 gRPCwait for traffic to be sent to hosts field specified target
    A routing rule contains the destination address to which the request should flow, with zero or more matching conditions, depending on your use case.

match condition

The first routing rule in the example has a condition, so it starts withmatchfield begins. In this example, you want this route to apply to"jason" userfor all requests, so useheadersend-userandexactfield to select the appropriate request.

- match:
   - headers:
       end-user:
         exact: jason

Destination

  • route sectiondestinationThe field refers to the actual destination address of traffic that matches this condition.
  • with virtual serviceshostsdifferent,destination The host must exist inIstio Service Registrythe actual destination address, otherwise Envoy would not know where to send the request.
route:
- destination:
    host: reviews
    subset: v2

The destination fragment also specifies the subset of Kubernetes services into which requests that meet the conditions of this rule are forwarded, in this case the subset name is v2.

Routing rule priority

routing rules bytop to bottomThe order of selection, defined in the virtual serviceThe first rule has the highest priority, traffic that does not satisfy the first routing ruleflow to a default target

In this example: the second rule has no match condition and directs traffic directly to the v3 subset.

- route:
  - destination:
      host: reviews
      subset: v3

More on Routing Rules

Match conditions can be set on traffic ports, header fields, URIs, etc.

Match condition:

[What is Istio? ] If you don't know, you're out, a 40-minute text can be quickly understood

DestinationRule

A virtual service can be thought of as how traffic is routed to a destination address, and destination rules are then used to configure traffic for that destination. After the virtual service routing rule, the destination rule is applied to the "real" destination address of the traffic.

Simply put: after the virtual service passes the target rule, it reaches the target address (service)

Application scenarios: Customize Envoy's traffic policy, load balancing model, TLS security mode, or circuit breaker settings for the entire destination service or a specific subset of services.

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: my-destination-rule
spec:
  host: my-svc
  trafficPolicy:
    loadBalancer:
      simple: RANDOM # random load balancer
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2
    trafficPolicy:
      loadBalancer:
        simple: ROUND_ROBIN # poll the load balancer
  - name: v3
    labels:
      version: v3

Each subset is based on one or morelabelsDefined, tags are applied to the deployment controller metadata field in the kubernetes cluster to identify different versions.

Load Balancing Options

Istio uses a round-robin load balancing strategy by default. Istio also supports the following load balancing models, which can be found inDestinationRuleis specified in:

  • Random: Requests go to instances in the pool in a random fashion.
  • Weight: Requests go to instances based on a specified percentage.
  • Least Requested: Requests are directed to the least accessed instance.

    Gateway

  • To manage inbound and outbound traffic, the gateway configures a standalone Envoy proxy at the mesh boundary instead of a sidecar proxy serving the workload.
  • The Istio gateway can be configured with layer 4-6 load balancing properties, such as externally exposed ports, TLS settings, etc.
  • Gateways are primarily used to manage incoming traffic
  • Istio provides preconfigured gateway proxies (istio-ingressgatewayandistio-egressgateway

chestnut

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: ext-host-gwy
spec:
  selector:
    istio: ingressgateway  # use istio default controller
  servers:
  - port:
      number: 443
      name: https
      protocol: HTTPS
    hosts:
    - ext-host.example.com
    tls:
      mode: SIMPLE
      serverCertificate: /tmp/tls.crt
      privateKey: /tmp/tls.key

This gateway configuration allows HTTPS traffic fromext-host.example.comFlow into the mesh over port 443, but no routing rules are specified for the request. To specify the route for the gateway you want to work, you must bind the gateway to the virtual service.

Using the virtual service'sgatewaysfield to set:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: virtual-svc
spec:
  hosts:
  - ext-host.example.com
  gateways:
    - ext-host-gwy

A virtual service with routing rules can then be configured for egress traffic.

Sidecar

By default, Istio makes each Envoy proxy accessible to all ports of its associated workload, and forwards it to the corresponding workload.

You can use the sidecar configuration to do:

  • fine-tuningAccepted by the Envoy proxyPorts and Protocol Sets
  • limitEnvoy proxies canAccessed service collection

in larger applicationsLimit sidecar reachability, configure each proxy to access any service in the grid, possibly becausehigh memory usageand affect the performance of the grid.

The sidecar configuration can be specified to apply to all workloads in a specific namespace, or useworkloadSelectorChoose a specific workload

For example, the following sidecar configuration willbookinfoAll services in a namespace are configured to only access services running in the same namespace and Istio control plane:

apiVersion: networking.istio.io/v1alpha3
kind: Sidecar
metadata:
  name: default
  namespace: bookinfo
spec:
  egress:
  - hosts:
    - "./*"
    - "istio-system/*"

Cyber ​​resilience and testing

In addition to mesh diversion, Istio providesFault recovery and fault injectionfunctions, which you can dynamically configure at runtime. Using these features allows your application torun smoothly, to ensure that the service mesh canfail-tolerant node, and prevent local failures from cascading to other nodes.

time out

timeout isEnvoy proxywaiting for fromreply to servicetime to ensure that the service does not wait for a replySuspend indefinitely. HTTP requestDefault timeoutYes15 seconds, which means that the call will fail if the service does not respond within 15 seconds.

to findoptimal timeout setting, Istio allows the use of virtual services to easily adjust timeouts dynamically on a per-service basis without having to modify your business code.

chestnut:

a dummy service, a call to the v1 subset of the ratings service, specifying10 second timeouttime

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
  - ratings
  http:
  - route:
    - destination:
        host: ratings
        subset: v1
    timeout: 10s

Retry

service is initialcall failedEnvoy proxyAttempt to connect to the serviceMaximum times. Make sure the call doesn't becausetemporary overloadpermanent failure due to service or network issues.

between retriesInterval (25ms+)is mutable, the default retry behavior for HTTP requests is before returning an errorretry twice

Use Case: As with timeouts, Istio's default retry behavior may not suit your application needs in terms of latency (too many retries on failed services slow down) or availability.

chestnut

configured at the initialcall failedafter, up toretry 3 timesTo connect to a subset of services, each retry has a 2 second timeout.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
  - ratings
  http:
  - route:
    - destination:
        host: ratings
        subset: v1
    retries:
      attempts: 3
      perTryTimeout: 2s

fuse

circuit breaker, set a pair of serviceLimits for a single host call, such as the number of concurrent connections or the hostThe number of times the call failed. Once the limit is triggered, the fuse will"tripping"and stop connecting to that host.

Function: useFusing modeCan fail fast without having clients try to connect tooverloaded or faultyhost.

Fusing applies to theload balancing poolThe "real" grid destination address in the , circuit breaker thresholds can be configured in the destination rule, allowing the configuration to apply to every host in the service.

chestnut:

subset v1reviewsThe number of concurrent connections for service workloads is limited to 100:

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews
  subsets:
  - name: v1
    labels:
      version: v1
    trafficPolicy:
      connectionPool:
        tcp:
          maxConnections: 100

fault injection

What: Can use Istiofault injectionmechanism to serve the entire applicationTest Failure Resilience

Why use it: Fault injection is a method of introducing errors into a system to ensure that the system can survive and recover fromerror conditionrecovery test method.

Purpose: It is especially useful to use fault injection to ensurefailover strategyNot to be incompatible or too restrictive, which would render critical services unavailable.

There are two types of faults that can be injected, both configured using a virtual service:

  • Delay: Delay is a time failure. They simulate increased network latency or an overloaded upstream service.
  • termination: Terminate is a crash failure. They mimic the failure of upstream services. Termination usually occurs in the form of HTTP error codes or TCP connection failures.

chestnut:

1 in 1000 visitsratingsService requests, configured with a 5 second delay:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
  - ratings
  http:
  - fault:
      delay:
        percentage:
          value: 0.1
        fixedDelay: 5s
    route:
    - destination:
        host: ratings
        subset: v1

run with your application

Istio failoverThe function is for the applicationcompletely transparentof. The application does not know if the Envoy sidecar proxy is working until the response is returnedHandling failures of called services. This means that if you have a failback strategy set up in your application code, you need to remember that both strategies work independently, otherwise there will be conflicts.

For example, let's say you set two timeouts, one configured in the virtual service and one in the application.application as a serviceAPI calls have a timeout of 2 seconds. while you areVirtual serviceA 3 second timeout and retries are configured in . In this case, the application's timeout will take effect first, so Envoy's timeout and retry attempts will fail.

Although Istio's failover features improve thereliability and availability, but the application must handle failures or errors and take appropriate fallback action. For example, when all instances in the load balancer fail, Envoy returns aHTTP 503code. Applications must implement fallback logic to handleHTTP 503error code.

Summarize

This article took a lot of energy, and I hope the bloggers will support the newcomers! ! !

A practical operation will be released later, and I look forward to your continued attention! ! !

Learning without detours, pay attention to v "yeTechLog"