- Pilot is the main control component that distributes all information about what we keep inside the cluster — services, their endpoints and routing rules (for example, the rules of canary deployment or the circuit breaker rules).
- Mixer is an optional control plane component that provides the ability to collect metrics, logs, and any information about network interactions. It also monitors compliance with policy rules and compliance with the rate limits.
- The data plane component is implemented using sidecar proxy containers.By default, a powerful proxy server envoyis used
整体的流程:
- We deploy a new version of the service.
- Depending on the sidecar container injection type, an istio-init container and istio-agent container (envoy) are added during the configuration phase, or they can be manually inserted into the pod description of the kubernetes entity.
- The istio-init container is a script that applies the iptables rules for a pod. There are two ways to configure traffic redirecting to an istio-agent container: using redirect iptables rules or TPROXY. At the writing moment, the default is using redirect rules. In istio-init, it is possible to configure which traffic will be intercepted and sent to istio-agent. For example, in order to intercept all incoming and all outgoing traffic, you need to set the parameters
-i
and-b
to*
. You can specify specific ports to be intercepted. To avoid intercepting a certain subnet, you can specify it using the-x
flag. - After init execution, the containers, including pilot-agent (envoy), are launched. It connects to the deployed Pilot by GRPC and gets information about all existing services and routing policies in the cluster. According to the received data, it configures the cluster and maps these directly to the application endpoints in the k8s cluster. There is an important moment: envoy dynamically configures listeners (IP, port pairs) that start listening. Therefore, when requests enter the pod and are redirected using iptables rules to sidecar, envoy is prepared to handle these connections and understands where to forward the proxy traffic. In this step, the information is sent to the Mixer, which we will be described below.
Mixer has two components: istio-telemetry, istio-policy (up to version 0.8, it used to be a single component istio-mixer). Both are a mixer. Istio telemetry receives GRPC from sidecar containers and reports information about service interactions and parameters. Istio-policy accepts check requests to verify compliance with Policy rules.