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

Thanks to the good modular design, the design of each component of Istio is clear, the division of labor is clear, and several large components can even work independently, so we will analyze the various components of Istio one by one. First of all, this paper makes a detailed analysis of the modules corresponding to our most commonly used flow management function-Pilot and Envoy.

Istio basic architecture

The basic architecture diagram of Istio is shown in the following figure. The flow control of the grid in east-west and south direction is maintained and managed by Pilot, and sent to Envoy Proxy through standard interface, and the traffic is finally forwarded by Envoy.

Istio service grid is logically divided into data plane and control plane:

Data plane: consists of a set of intelligent agents (Envoy) deployed as Sidecar, which can regulate and control all network communication between microservices. Control plane: service management and configuration agents to "flow".

The main issues related to flow management include Pilot at the control level and Envoy Proxy at the data level.

Control plane component-- Pilot

The basic architecture of Pilot is shown in the following figure.

Pilot function

According to the figure above, Pilot mainly implements the following functions:

1. Unified service model

The main function of the unified service model is to obtain service-related information from the underlying platform and the flow rules between services defined by RuleAPI. Taking kubernetes as the platform, the unified service model obtains the information registered in Pod, Service, Node and flow rules from the platform, and then converts the information into a understandable data format on the data plane and stores it in Abstract Model.

two。 Standard data plane API

After obtaining various service information and flow rules, it will be sent to the Sidecar on the data side through the API.

3. Domain Speci DSL language (Business Language)

The SL language provides a high-level business-oriented abstraction that can be understood and used by operators. Operation and maintenance personnel use this DSL to define flow rules and send them to Pilot. These rules are translated into data-side configurations by Pilot, and then distributed to Envoy implementations through standard API, so that the traffic of micro-services can be controlled and adjusted during operation.

Pilot's rule DSL is implemented using Custom Resource (CRD) in K8S API Server, so similar to the creation and use of other resource types such as Service Pod Deployment, it can be created with Kubectl imports.

By using the same traffic rules, we can control the fine flow of micro-services in the grid, such as shunt by version, circuit breaker, fault injection, grayscale release and so on.

Pilot implementation

There are two main services related to Pilot:

(1) Discovery Service

The corresponding docker is gcr.io/istio-release/pilot, and the process is pilot-discovery. The features of this component include:

To obtain service information from Service Provider, Istio supports Consul as a Service Provider in addition to Kubernetes, which is mainly introduced in "this".

Get the flow rules (Kubernetes CRD Resource) from Kubernetes API Server.

The service information and traffic rules are transformed into a format that can be solved on the data surface, and then sent to each Sidecar in the grid through the standard data plane API.

(2) Kubernetes API Server

Provide Pilot related CRD Resource add, delete, change, check. There are several types of CRD related to Pilot:

Virtualservice: used to define custom rules, such as making rules based on source or Header, or splitting a stream from a service version.

DestinationRule: defines the configuration policy of the destination service and a subset of configurable subsets. Strategies include outage, load balancing, TLS and so on.

ServiceEntry: with ServiceEntry, additional service entries can be added to the Istio so that requests can be made to services outside the Istio service grid within the grid.

Gateway: configure a gateway for the grid to allow a service to be accessed outside the grid.

EnvoyFilter: filter filters can be configured for Envoy. Since Envoy already supports Lua filtering filters, you can enable Lua filtering filters through EnvoyFilter to dynamically change the filter chain of Envoy to. I've been thinking about how to dynamically extend the capabilities of Envoy, and EnvoyFilter provides flexible extensibility.

Data plane component-- EnvoyEnvoy implementation

Istio implements the automatic injection of Envoy sidecar through the Admission Webhook mechanism of K8s, and each micro-service in the Istio cluster will be added to the Envoy-related capacity. The following is the Pod content of the official product page micro-service. It can be seen that in addition to productpage, Istio has also injected two capacity gcr.io/istio-release/proxy_init and gcr.io/istio-release/proxyv2 into the Pod.

1. Initialize the container proxy_init

An InitContainer proxy_init,InitContrainer in Productpage's Pod is a mechanism provided by K8S, which is used to perform some initialization tasks in Pod, and other container in Pod will not be started until the Initialcontainer is executed and exited.

Implement the iptables.sh script in proxy_init, which is used to hijack the stream blocks in Pod by configuring iptable.

two。 Run-time Sidecar container contains proxyv2

Most of the configurations of Envoy are dynamic resource, including service cluster, listener, route rules related to services in the grid. These dynamic resource are obtained dynamically from the Istio control plane through the xDS interface. But how does Envoy know the address of xDS server? This is configured as static resource in the Envoy initialization configuration file.

When the Proxyv2 container runs, there are two processes, pilot-agent and envoy.

1) pilot-agent process

This process generates the configuration file of Envoy based on the configuration information in K8S API Server and is responsible for starting the Envoy process. Note that most of the configuration information for Envoy is dynamically obtained from Pilot through the xDS interface, so Agent generates only a small amount of static configuration for initializing Envoy.

2) envoy process

Envoy is started by the Pilot-agent process. After startup, Envoy reads the configuration file generated by Pilot-agent for it, then obtains the address of the Pilot according to the configuration of the file, and pulls the dynamic configuration information from the pilot through the xDS interface of the standard API on the data side, including routing (route), listener cluster (listener), service cluster (cluster) and service endpoint (endpoint). After the initialization of Envoy is completed, the communication between microservices is addressed and routed according to these configuration information.

Related concepts of Envoy

There are many concepts involved in the data plane component, which are listed below.

Host: an entity that can access network communications (applications on mobile phones or services, etc.). In Envoy, a host is a logical network application. As long as each host can be addressed independently, multiple hosts can be carried on a piece of hardware. Downstream: the downstream (downstream) host connects to the Envoy, sends a request, or gets a response. Upstream: upstream (upstream) hosts get link requests and responses from Envoy. Cluster: a cluster is a set of logically similar upstream hosts to which Envoy is connected. Envoy discovers the members of the cluster through service discovery. Envoy can determine the health status of cluster members through proactive health checks. How Envoy transfers requests to cluster members is determined by the load balancer policy. Mesh: a group of hosts that coordinate with each other to provide consistent network attack. Envoy mesh refers to a set of Envoy generations that form the messaging foundation of a distributed system made up of multiple identical services and application platforms. Run-time configuration: an out-of-band real-time configuration system deployed with Envoy. You can change the settings to affect the operation without restarting Envoy or modifying the Envoy master configuration. Listener: listener are named network locations (for example, ports, unix domain sockets, and so on) that can be connected by downstream clients. Envoy exposes listeners for one or more downstream host connections. Generally, each host runs one Envoy and uses a single process to run it. However, any number of Listener (listeners) can be started in each process. Currently, only TCP is listened, and each listener is independently configured with a certain number of L3/L4 network filters. Listenter can also be obtained dynamically through Listener Discovery Service (LDS). Listener lter:Listener uses the listener monitor lter to manipulate linked metadata. Its function is to add more integration functions in the case of changing the core functions of Envoy. The API of Listener subscription lter is relatively simple because these filters end up running on newly accepted sockets. They can be connected to each other in the chain to support "complex scenarios," such as call rate limits. Envoy already contains multiple snooping filter filters. The routing rules of Http Route Table:HTTP, such as the requested domain name, the rules that Path conforms to, and the Cluster to which it is forwarded. Health checking: health checks are used in conjunction with SDS service discovery. However, even with other service discovery methods, there is a corresponding need for active health check-ups. XDS:xDS is a key concept, which is a general term for a class of discovery services that dynamically refresh new Envoy configurations through requests to xDS, including the following categories:

CDS:Cluster Discovery Service

EDS:Endpoint Discovery Service

SDS:Service Discovery Service

RDS:Route Discovery Service

LDS:Listener Discovery ServiceEnvoy configuration

The configuration of Envoy consists of two parts, initializing the configuration and dynamically updating the new configuration.

Initial configuration of 1.Envoy

The Pilot-agent process generates the initial configuration file of Envoy based on the startup parameters and the configuration information in K8S API Server, and is responsible for starting the Envoy process. From the output of the ps command, you can see that Pilot-agent passes in the pilot address and zipkin address when starting the Envoy process, and generates an initialization configuration file envoy-rev0.json for Envoy.

2.Envoy dynamically updates configuration

Obtain the complete configuration through the management interface. From the Envoy initialization configuration file, we can roughly see that Istio implements the basic primitive of service discovery and flow management through Envoy. That is, the control plane configures the xDS server information to the initialization configuration file of the Envoy through static resource, and after Envoy starts, the dynamic resource is obtained through xDS server, including the service information and routing rules in the grid.

The detailed process is as follows:

Pilot-agent generates the initial configuration file envoy-rev0.json of Envoy based on the startup parameters and the configuration information in K8S API Server, which tells Envoy to obtain dynamic configuration information from xDS server and configures the address information of xDS server, that is, the Pilot of the control plane. Pilot-agent uses envoy-rev0.json to start the Envoy process. Envoy obtains the Pilot address according to the initial configuration, and uses the xDS interface to obtain the d dynamic configuration information such as Listener,Cluster,Route from Pilot. Envoy launches Listener according to the obtained dynamic configuration, and combines Route and Cluster to enter the blocked traffic according to the configuration of Listener. Interaction process between services

The following figure shows the process of service-to-service interaction through sidecar.

The basic process is analyzed as follows:

Productpage initiates a call to Details: http://details:9080/details/0. The request is intercepted by Pod's iptable rules and forwarded to port 15001. The Virtual Listener of Envoy listens on port 15001 and receives the request. The request is forwarded by Virtual Listener to the listener of 0.0.0.0room900 based on the original destination IP (wildcard) and port (9080).

Based on the http_connection_manager requests lter configuration of 0.0.0.09080 listener, the request is distributed in a "9080" route feed.

In the configuration of "9080" route, the cluster for requests with host name of details:9080 is outbound | 9080 | | details.default.svc.cluster.local.

Outbound | 9080 | | details.default.svc.cluster.local cluster is a dynamic resource. The endpoint obtained by eds query is 192.168.206.21 endpoint 9080.

The request is forwarded to 192.168.206.21, the Pod where the Details service is located, intercepted by iptable rules, and forwarded to port 15001. The Virtual Listener of Envoy listens on port 15001 and receives the request. The request is forwarded by Virtual Listener to the listener of 192.168.206.21x9080 according to the original destination address IP (192.168.206.21) and port (9080). According to the http_connection_manager requests lter configuration of 92.168.206.21o9080 listener, the corresponding cluster for this request is inbound | 9080 | | details.default.svc.cluster.local.

Inbound | 9080 | | host configured by details.default.svc.cluster.local cluster is 127.0.0.1 host 9080. The request is forwarded to 127.0.0.1 Details 9080, where the service is entered.

Reference link

Https://zhaohuabing.com/post/2018-09-25-istio-traffic-management-impl-intro/

Https://istio.io/zh/docs/concepts/what-is-istio/

Https://www.cnblogs.com/xishuai/p/microservices-and-service-mesh.html

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.