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

The container components Deployment names Container and PortContainer and Portistio-pilotpilot: 8080 Deployment 15010 proxyv2: 15003 Istio 15007 istiolightgalleygalley: 443memo 909istiolsgatewayproxyv2: 80433 maxim 15090istioMathingsgatewayproxyv2: 80pr 443meme 1503parsgatewayproxyv2: 80pr 443parsgatewayproxyv2: 80primetheus: 9090istio-citadelcitadel: 94111J 15031J 1503fanagrafana: 3000istio-policymixer: 9093prima 42422proxyv2: 9091rep 1500422proxyv2: 90911400415090promeuspromethetheus: 8086istio-sidecar-injectorsidecar-injectoristio-tracingjaegertracing/all-in-one: 9411686: 80443

The direction of traffic is shown in the following figure:

Description: the red line represents the control flow, the black line represents the data flow, and the blue part represents the related components of Envoy and pilot

Core components and functions of Istio

Istio mainly consists of two parts: control plane and data plane.

The data side is called Sidecar: it injects a container into the business Pod, hijacks the traffic of the business application container, accepts the control of the control component, and outputs logs, tracking and monitoring data to the control component. The control plane is the core of Istio and manages all the functions of Istio.

Pilot: the core flow control component of Istio, which is mainly responsible for traffic management. Pilot manages all Envoy proxy instances (Sidecar) and has the following functions:

Go back to the service information from the K8S or other platform registry, complete the service discovery, read the control configuration of Istio, and send it to the data component for implementation. The data component Sidecar completes the configuration of routing, service, monitoring, clustering and so on according to Pilot instructions.

Mixer: mainly pre-checking and reporting, policy control, monitoring, and log collection, etc. The main workflow is as follows:

The user sends the Mixer configuration to the Kubernetes cluster and Mixer acquires the configuration changes by listening to the cluster resources. Before each call, the service in the grid issues a pre-check request to Mixer to see if it is allowed to execute. After the service invocation is completed, a report message is sent to the Mixer reporting the monitoring trace data generated during the call. Mixer contains a number of Adapter components, these components to deal with the pre-check report data received in the Mixer, to complete the functions of Mixer.

Citadel: mainly used for certificate management and identity authentication.

Sidecar (Envoy): a data plane in Istio that controls the actual execution of control over the service grid.

The default Sidecar in Istio is derived from Envoy. In theory, as long as it supports Envoy's xDS protocol (the general term for x descovery service service discovery), other similar reverse proxy software can replace Envoy to play this role. Istio uses the iptables instruction in the istio-init initialization container to hijack the traffic of the Pod, so as to take over the communication in the Pod application. After Sidecar is injected into Pod, the communication mode of the original source container-> target container is changed to source container-> Sidecar-> Sidecar-> target container. Data plane component

Istio realizes the automatic injection of sidecar through the Admission webhook [9] mechanism of K8s, and each micro-service pod in Mesh will be added to the Envoy-related container.

In addition to the microservice's own containers, istio also injects two containers, proxy_init and proxyv2, into Pod. The two processes running in the proxyv2 container are the core of the data plane.

Proxy_init

Proxy_init is an initContainer, which is mainly used to do some initialization work before starting the Pod. Other container in the Pod will be started only after the InitContainer executes successfully.

You can obtain the metadata of this container image through the docker inspect command:

... "Env": ["PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"], "Cmd": ["/ bin/sh", "- c", "# (nop) COPY file:1e5fc95e10f8888f4cae33f7e0ea42b5aff9d18d36280ae288a0fee948dc18e1 in/"] "ArgsEscaped": true, "Image": "sha256:e261e1418e2ed94d1de1742d80997cc58f96aa3c4bfc56cd50e7f2848bf5bcf6", "Volumes": null, "WorkingDir": "," Entrypoint ": [" / usr/local/bin/istio-iptables.sh "],...

As you can see from the command line output above, the command executed in Proxy_init is an istio-iptables.sh script, and the specific contents of the script can be copied directly from the existing container to view:

Docker cp cbbaf5413d04:/usr/local/bin/istio-iptables.sh. /

This script mainly sets the iptables port forwarding rules for Istio sidecar.

Proxyv2

The injection container that runs with the business container for a long time is istio-proxy, which is responsible for intercepting all inflow and outflow traffic in POD.

You can see the processes running in this container with the following command:

[root@k8s-node-1] # kubectl exec reviews-v3-748456d47b-6jvsp-c istio-proxy-- ps-efUID PID PPID C STIME TTY TIME CMDistio-p+ 1 00 02:26? 00:00:00 / usr/local/bin/pilot-agent proxy sidecar-configPath / etc/istio/proxy-binaryPath / usr/local/bin/envoy-- serviceCluster reviews--drainDuration 45s-- parentShutdownDuration 1m0s-- discoveryAddress istio-pilot.istio-system 15007-- discoveryRefreshDelay 1s-- zipkinAddress zipkin.istio-system:9411-- connectTimeout 10s-- proxyAdminPort 15000-- controlPlaneAuthPolicy NONEistio-p+ 16 10 02:26? 00:03:37 / usr/local/bin/envoy-c / etc/istio/proxy/envoy-rev0.json-- restart-epoch 0-- drain-time-s 45-- parent-shutdown-time-s 60-- service-cluster reviews--service-node sidecar~10.2.53.61~reviews-v3-748456d47b-6jvsp. Default~default.svc.cluster.local-- max-obj-name-len 189-- allow-unknown-fields-l warn-- v2After ps onlyistio warn p + 39 00 13:07? 00:00:00 ps-ef

There are two main processes running in this container:

Pilot-agent: responsible for generating the configuration file required for Envoy startup, specifying the service and port to connect to the istio control plane, and starting the Envoy process. Envoy: the specified / etc/istio/proxy/envoy-rev0.json file is the core configuration of the current pod network traffic. The address of the pilot is obtained through this file, which records the current POD information and the forwarding rules of the traffic. The pilot establishes a persistent connection with it and pushes the latest updated network policy to it.

Through the analysis of the envoy-rev0.json file, we can find that it mainly contains the following parts:

Node: contains current Pod information, including ID,IP,servicename,namespace, etc. Stats_config: defines some naming rules and corresponding regular parameters admin: gives a set of local IP 127.0.0.1 and 15000 management ports, you can log in to this container and execute curl http://127.0.0.1:15000/help to get the interface and status information of the current POD dynamic_resources: defines the service discovery configuration of xDS: defines the information of the connection control plane, including the service address of connecting pilot components And configuration information such as timeout setting and connection limit. Tracing: mainly defines the interface and other information of zipkin, which is used to track the direction of business traffic.

Log in to istio-proxy to view the listening port, where port 80 is the port that provides services for the business container:

$netstat-lntpActive Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program nametcp 00 0.0.0.0 only servers 15001 0.0.0.0 LISTEN 13/envoy tcp 00 0.0.0.0 LISTEN 13/envoy tcp 80 0.0.0.0 LISTEN-tcp 00 0.0.0.0 LISTEN 13/envoy tcp 15090 0.0.0.0 LISTEN 13/envoy tcp 00 127.0.0.1 LISTEN 13/envoy tcp 15000 0.0.0.0 LISTEN 13/envoy tcp6 00: 15020 : * LISTEN 1/pilot-agent 15001: Envoy's ingress listener Iptable imports pod traffic into this port for processing by Envoy 15000: Envoy management port, which is bound to the local loopback address and can only be accessed within Pod. Data side component startup process

Process diagram:

InitContainer executes the initialization script to add iptables rules for Pod Pilot-agent generates the initial configuration file envoy-rev0.json of Envoy based on the startup parameters and 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 processes the intercepted traffic according to the configuration of Listener, combined with Route and Cluster. Envoy profile structure

The configuration that is actually in effect in Envoy consists of static configuration in the initialization configuration file and dynamic configuration obtained from Pilot. Therefore, only the analysis of envoy-rev0. JSON can not see the full picture of traffic management in Mesh. So is there a way to see the full configuration that actually takes effect in Envoy? The answer is yes. We can obtain the complete configuration of Envoy through the management interface of Envoy:

Kubectl-n yak exec yak-files-7d48cd48f-tf75f-c istio-proxy curl http://127.0.0.1:15000/config_dump > config_dump

View the structure of this file:

{"configs": [{"@ type": "type.googleapis.com/envoy.admin.v2alpha.BootstrapConfigDump", "bootstrap": Object {...}, "last_updated": "2019-05-08T08:07:28.221Z"}, {"@ type": "type.googleapis.com/envoy.admin.v2alpha.ClustersConfigDump" "version_info": "2019-05-09T08:36:01Z/4", "static_clusters": Array [3], "dynamic_active_clusters": Array [96]}, {"@ type": "type.googleapis.com/envoy.admin.v2alpha.ListenersConfigDump", "version_info": "2019-05-09T08:36:01Z/4" "static_listeners": Array [1], "dynamic_active_listeners": Array [57]}, {"@ type": "type.googleapis.com/envoy.admin.v2alpha.RoutesConfigDump", "static_route_configs": Array [3], "dynamic_route_configs": Array [17]}}

The configuration mainly includes the following parts:

Bootstrap: the content in the file is the same as the envoy-rev0.json described earlier: clusters: it is a service cluster containing one or more endpoint, each endpoint can provide services, and Envoy sends requests to these endpoint according to the load balancing algorithm. Static_clusters: is the xDS server and zipkin server information from envoy-rev0.json. Dynamic_active_clusters: the dynamic service information obtained from the Istio control plane through the xDS interface. Listeners: Envoy uses listener to receive and process requests from downstream. The processing logic of listener is plug-in, and different processing logic can be inserted by configuring different filter. Static_listenersdynamic_active_listenersroutes: configure routing rules for Envoy. The default routing rule issued by Istio sets a routing rule for each port to route and distribute requests according to host. Static_route_configsdynamic_route_configs

Official bookinfo service invocation diagram:

Reference link: https://zhaohuabing.com/post/2018-09-25-istio-traffic-management-impl-intro/

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.