我目前正在研究1.6版本的服务网格Istio。数据平面(Envoy代理)由控制平面配置。特别是Pilot(istiod的一部分)负责向特使传播路由规则和配置。我想知道沟通是如何进行的？
- 它是在sidecar容器第一次启动时打开的单个gRPC流，并且在sidecars的整个生命周期中保持打开。如果网格发生了更改，Pilot会使用此流通过xDS/api通知特使有关更改的信息？所以更新是基于推送策略的？或者sidecar是否在定义的时间间隔内拉取新的配置
- istio代理(fromer pilot和citadel代理)在sidecar容器中的作用是什么(尤其是前pilot代理，我知道citadel是CSR过程的代理)？它是否需要新的配置，是否只引导特使，但为什么它总是在运行
提前感谢！
- istio特使如何工作的最佳解释来自特使文档。事实上，它比看起来复杂得多：
初始化
Envoy在启动时如何初始化自己很复杂。本节高层次地解释了流程的工作原理。以下所有情况都发生在任何侦听器开始侦听和接受新连接之前。
在启动过程中，集群管理器会经历多阶段初始化，首先初始化静态/DNS集群，然后初始化预定义的EDS集群。然后，如果适用，它初始化CDS，在有限的时间段内等待一个响应(或失败)，并对CDS提供的集群进行相同的初级/次级初始化。
如果集群使用主动健康检查，Envoy还会执行一轮主动健康检查。
完成群集管理器初始化后，RDS和LDS将进行初始化(如果适用)。服务器等待LDS/RDS请求的至少一个响应(或失败)一段有限制的时间。之后，它开始接受连接。
如果LDS本身返回一个需要RDS响应的侦听器，Envoy将进一步等待一段有限制的时间，直到收到RDS响应(或失败)。请注意，此过程发生在通过LDS添加的每个未来侦听器上，称为侦听器预热。
在完成了前面的所有步骤之后，侦听器开始接受新的连接。此流程确保在热重启期间，新进程完全能够在旧进程开始排出之前接受和处理新连接。
初始化的一个关键设计原则是，始终保证Envoy在initial_etch_timeout内初始化，并尽最大努力在该范围内获得完整的xDS配置集，这取决于管理服务器的可用性。
关于更新特使配置：
运行时配置
Envoy支持"运行时"配置(也称为"功能标志"one_answers"决策器")。配置设置可以更改，这将影响操作，而无需重新启动Envoy或更改主配置。当前支持的实现使用文件系统文件树。Envoy监视已配置目录中的符号链接交换，并在发生这种情况时重新加载树。这种类型的系统通常部署在大型分布式系统中。其他实现并不难实现。支持的运行时配置设置记录在操作指南的相关章节中。Envoy将使用默认运行时值和"null"提供程序正确运行，因此不需要存在这样的系统来运行Envoy。
运行时配置。
有关特使代理工作方式的更多信息，请点击此处。
- 根据istio文档：
合并的好处：引入istiod
在确定微服务的许多共同优点不适用于Istio控制平面后，我们决定将它们统一为一个二进制文件：istiod("d"表示守护进程)。
让我们看看新包装的好处：
安装变得更容易需要更少的Kubernetes部署和相关配置，因此Istio的配置选项和标志集显著减少。在最简单的情况下，您可以通过启动一个Pod来启动Istio控制平面，并启用所有功能
配置变得更容易Istio现在拥有的许多配置选项都是编排控制平面组件的方法，因此不再需要。您也不再需要更改集群范围的
PodSecurityPolicy来部署Istio。使用虚拟机变得更容易要将工作负载添加到网格中，您现在只需要安装一个代理和生成的证书。该代理只连接回一个服务。
维护变得更容易安装、升级和删除Istio不再需要复杂的版本依赖关系和启动顺序。例如：要升级，您只需要在现有的控制平面旁边启动一个新的istiod版本，对其进行金丝雀操作，然后将所有流量转移到它上。
可扩展性变得更容易现在只有一个组件需要扩展。
调试变得更容易更少的组件意味着更少的跨组件环境调试。
启动时间下降组件不再需要等待彼此按照定义的顺序启动。
资源使用率下降，响应能力提高组件之间的通信得到保证，并且不受gRPC大小限制。缓存可以安全地共享，从而减少了资源占用。
istiod将Pilot、Galley、Citadel和sidecar注入器之前执行的功能统一为一个二进制文件。
一个单独的组件istio-agent通过将配置和机密安全地传递给Envoy代理，帮助每个sidecar连接到网格。虽然严格来说，特工仍然是控制飞机的一部分，但它是以每个吊舱为基础运行的。我们通过将以前作为DaemonSet运行的每个节点的功能滚动到每个pod代理中来进一步简化
希望它能有所帮助。