istio - Istio 的通信 Sidecar Controle Plane

Question

我目前正在研究 1.6 版的服务网格 Istio。数据平面(Envoy 代理)由控制平面配置。尤其是 Pilot( istiod 的一部分)负责将路由规则和配置传播给特使。我想知道通信是如何工作的？

它是在 sidecar 容器第一次启动时打开的单个 gRPC 流，并在 sidecar 的整个生命周期中保持打开状态。如果网格发生变化，Pilot 会使用此流通过 xDS api 通知 Envoy 有关变化吗？所以更新是基于推送策略的？或者 sidecar 是否在定义的时间间隔内拉取新配置？

侧车容器中的istio代理(fromerpilot和citadel代理)的作用是什么(尤其是前pilot代理，我知道Citadel代理是CSR流程的)？它是否会拉取新的配置，它是否只是引导特使，但为什么它总是在运行，......？

提前致谢!

Answer 1

istio envoy 如何工作的最好解释来自 envoy 文档。它实际上比看起来要复杂得多:

Initialization

How Envoy initializes itself when it starts up is complex. This section explains at a high level how the process works. All of the following happens before any listeners start listening and accepting new connections.

• During startup, the cluster manager goes through a multi-phase initialization where it first initializes static/DNS clusters, then predefined EDS clusters. Then it initializes CDS if applicable, waits for one response (or failure) for a bounded period of time, and does the same primary/secondary initialization of CDS provided clusters.

• If clusters use active health checking, Envoy also does a single active health check round.

• Once cluster manager initialization is done, RDS and LDS initialize (if applicable). The server waits for a bounded period of time for at least one response (or failure) for LDS/RDS requests. After which, it starts accepting connections.

• If LDS itself returns a listener that needs an RDS response, Envoy further waits for a bounded period of time until an RDS response (or failure) is received. Note that this process takes place on every future listener addition via LDS and is known as listener warming.

• After all of the previous steps have taken place, the listeners start accepting new connections. This flow ensures that during hot restart the new process is fully capable of accepting and processing new connections before the draining of the old process begins.

A key design principle of initialization is that an Envoy is always guaranteed to initialize within initial_fetch_timeout, with a best effort made to obtain the complete set of xDS configuration within that subject to the management server availability.

至于更新特使配置:

Runtime configuration

Envoy supports “runtime” configuration (also known as “feature flags” and “decider”). Configuration settings can be altered that will affect operation without needing to restart Envoy or change the primary configuration. The currently supported implementation uses a tree of file system files. Envoy watches for a symbolic link swap in a configured directory and reloads the tree when that happens. This type of system is very commonly deployed in large distributed systems. Other implementations would not be difficult to implement. Supported runtime configuration settings are documented in the relevant sections of the operations guide. Envoy will operate correctly with default runtime values and a “null” provider so it is not required that such a system exists to run Envoy.

Runtime configuration.

有关特使代理如何工作的更多信息，请访问 here .

根据 istio documentation :

The benefit of consolidation: introducing istiod

Having established that many of the common benefits of microservices didn’t apply to the Istio control plane, we decided to unify them into a single binary: istiod (the ’d’ is for daemon).

Let’s look at the benefits of the new packaging:

• Installation becomes easier. Fewer Kubernetes deployments and associated configurations are required, so the set of configuration options and flags for Istio is reduced significantly. In the simplest case, you can start the Istio control plane, with all features enabled, by starting a single Pod.

• Configuration becomes easier. Many of the configuration options that Istio has today are ways to orchestrate the control plane components, and so are no longer needed. You also no longer need to change cluster-wide PodSecurityPolicy to deploy Istio.

• Using VMs becomes easier. To add a workload to a mesh, you now just need to install one agent and the generated certificates. That agent connects back to only a single service.

• Maintenance becomes easier. Installing, upgrading, and removing Istio no longer require a complicated dance of version dependencies and startup orders. For example: To upgrade, you only need to start a new istiod version alongside your existing control plane, canary it, and then move all traffic over to it.

• Scalability becomes easier. There is now only one component to scale.

• Debugging becomes easier. Fewer components means less cross-component environmental debugging.

• Startup time goes down. Components no longer need to wait for each other to start in a defined order.

• Resource usage goes down and responsiveness goes up. Communication between components becomes guaranteed, and not subject to gRPC size limits. Caches can be shared safely, which decreases the resource footprint as a result.

istiod unifies functionality that Pilot, Galley, Citadel and the sidecar injector previously performed, into a single binary.

A separate component, the istio-agent, helps each sidecar connect to the mesh by securely passing configuration and secrets to the Envoy proxies. While the agent, strictly speaking, is still part of the control plane, it runs on a per-pod basis. We’ve further simplified by rolling per-node functionality that used to run as a DaemonSet, into that per-pod agent.

希望能帮助到你。