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

One: introduction to Istio

1.Istio definition

A development platform for connecting, managing, and protecting services. Istio provides a simple way to establish a deployed service network, with load balancing, inter-service authentication and monitoring and other functions.

Without changing any service code. To add support for Istio to services, you only need to deploy a sidecar in the environment and use the Istio control panel feature to configure and manage agents to intercept all network traffic between microservices.

two。 Why do you need Istio

With the emergence of micro-services, the connection, management and monitoring of micro-services have become difficult. Kubernetes can handle workloads from multiple containers, but when more complex requirements are involved, a service grid such as Istio is required.

Main functions of 3.Istio

a. Traffic management (Pilot): controls the flow of traffic between services and the flow of API calls, making calls more flexible and reliable, and making the network more robust under adverse conditions.

b. Observability: by integrating services such as zipkin, you can quickly understand the dependencies between services, as well as the nature and flow of traffic between them, thus providing the ability to quickly identify problems.

c. Policy enforcement (mixer): apply organizational policies to the interaction between services to ensure that access policies are enforced and resources are well allocated among consumers. Policy changes are made by configuring the grid rather than modifying the application code.

d. Service identity and Security (Istio-auth): provides verifiable identity for services in the grid and the ability to protect service traffic so that it can flow over networks with different credibility.

4.Envoy architecture

There are two versions of a.svcA service as the server-side svcB,svcB for customer endpoints, but svcA is not aware of it

B.Envoy is deployed as a sidecar to each svc to pod, proxying all incoming and outgoing traffic

c. When svcA accesses its service through svcB to the domain name, Envoy distributes 1% of the traffic to the alpha version of svcB according to the routing rules configured by Pilot

5.Pilot architecture

Through configuration, Pilot can enable Envoy to achieve many capabilities, such as routing configuration, fault injection, traffic migration, request timeout, circuit breaker, and so on.

6.Mixer architecture

Mixer provides three core functions:

Prerequisite check: occurs before the service responds to the request, and the response can be terminated if the check fails

Quota management:

Telemetry report: can monitor service and report log information

Second: detailed explanation of Mixer

1. Infrastructure backend:

Mixer provides a common mediation layer between the application code and the infrastructure backend

The infrastructure backend is designed to provide support capabilities for building services. They include access control system, telemetry acquisition system, quota execution system, billing system and so on. Services have traditionally integrated directly with these back-end systems, creating hard couplings, as well as specific semantics and usage options.

Istio provides a unified abstraction that allows Istio to interact with a set of open infrastructure backends. This is done to provide rich and in-depth control to operations and maintenance without burdening service developers. Istio aims to change the boundaries between layers to reduce system complexity, eliminate policy logic in service code, and give control to operators.

two。 Attribute

Properties are fragments of metadata with names and types that describe egress traffic.

At run time, Mixer accepts a set of properties, and mixer processes the incoming properties to the appropriate underlying settings backend based on the configuration.

Features:

a. Pre-condition check. It occurs before the request is processed, and the mixer is accessed when the request is intercepted to envoy.

Allows the service to validate some prerequisites before responding to incoming requests from the service consumer. Prerequisites can include whether the service consumer is correctly authenticated, whether it is on the whitelist of the service, whether it passes the ACL check, and so on.

b. Quota management. Occurs during request processing when the back-end infrastructure needs to be invoked in the service.

To enable services to allocate and release quotas in multiple dimensions, quotas, a simple resource management tool, can provide a relatively fair (competitive means) when service consumers compete for limited resources. Frequency control is an example of a quota.

c. Telemetry report. After the request is processed, the reference data is reported to the mixer. As a result, envoy has the ability to check the health of pod.

The service can report logs and monitor. In the future, it will also enable tracking and billing streams for service operators and service consumers.

Telemetry reports are asynchronous. That is, to cache multiple reports once.

3. Adaptor

Mixer is a highly modular and extensible component. One of his key functions is to abstract the details of different backend policies and telemetry collection systems so that the rest of the Istio is unaware of these backends.

Mixer's flexibility in dealing with different infrastructure backends is achieved through the use of a common plug-in model. Each plug-in is called Adapter,Mixer and connects to different infrastructure backends that provide core functions such as logging, monitoring, quotas, ACL inspection, and so on. The exact adapter suite to be used at run time can be determined by configuration and can be easily extended to new or custom infrastructure backends.

4. Profile exampl

a. Processor (Handler):

The adapter encapsulates the necessary interfaces for Mixer to interact with the back end of a specific external infrastructure, such as Prometheus or Stackdriver. Various adapters require parameter configuration to work. For example, a log adapter might need an IP address and port to output the log.

The example here configures an adapter of type listchecker. The listchecker adapter uses a list to check the input. If the whitelist mode is configured and the input value exists in the list, a successful result will be returned.

ApiVersion: config.istio.io/v1alpha2kind: listcheckermetadata:name: staticversion namespace: istio-systemspec:providerUrl: http://white_list_registry/ blacklist: false

{metadata.name}. {kind}. {metadata.namespace} is the fully qualified name of HANDLER. The FQDN of the object defined above is staticversion.listchecker.istio-system, which must be unique. The data structure in spec depends on the requirements of the corresponding adapter.

Some adapters do more than just connect the Mixer to the back end. For example, prometheus adapters consume metrics and aggregate them into distributions or counters in a configurable manner.

ApiVersion: config.istio.io/v1alpha2kind: prometheusmetadata:name: handler namespace: istio-systemspec: metrics:- name: request_count instance_name: requestcount.metric.istio-system kind: COUNTER label_names:-destination_service-destination_version-response_code- name: request_duration instance_name: requestduration.metric.istio-system kind: DISTRIBUTION label_names:-destination_service-destination_version-response_code buckets: explicit _ buckets: bounds: [0.005 0.01, 0.025, 0.05, 0.1, 0.25, 0.5, 1, 2.5, 5, 10]

Each adapter defines configuration data in its own format. A detailed list of adapters and their configurations can be found here

b. Instance (Instance):

The configuration instance maps the properties in the request to the input of the adapter. The following example is the configuration of a metric instance to generate requestduration metric.

ApiVersion: config.istio.io/v1alpha2kind: metricmetadata:name: requestduration namespace: istio-systemspec: value: response.duration | "0ms" dimensions: destination_service: destination.service | "unknown" destination_version: destination.labels ["version"] | "unknown" response_code: response.code | 200 monitored_resource_type:'"UNSPECIFIED"'

c. Rules (Rule):

Rules are used to specify when to invoke a HANDLER using a specific instance configuration. For example, we want to send the requestduration metrics of requests with X-USER in the request header in the service1 service to Prometheus HANDLER.

ApiVersion: config.istio.io/v1alpha2kind: rulemetadata: name: promhttp namespace: istio-system spec: match: destination.service = = "service1.ns.svc.cluster.local" & & request.headers ["x-user"] = "user1" actions:- handler: handler.prometheus instances:-requestduration.metric.istio-system

The rule contains a MATCH element for pre-checking, and if the check passes, a list of actions is performed. The action contains a list of instances that will be distributed to HANDLER. The rule must use the fully qualified name of HANDLER and instance. If the rule, HANDLER, and instance are all in the same namespace, the namespace suffix can be omitted in FQDN, such as handler.prometheus.

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.