Istio Pilot与Envoy的交互机制解读

在基于Istio+Envoy实现的服务网格中，Istio的角色是控制平面，它是实现了Envoy的发现协议集xDS的管理服务器端。Envoy本身则作为网格的数据平面，和Istio通信，获得各种资源的配置并更新自身的代理规则。

除了实现xDS协议，Istio还负责：

1. Envoy统计数据的收集，从Statd格式转换为Prometheus格式。（注：目前看来Envoy也直接暴露了Prometheus的Exporter）
2. 限速服务、策略服务
3. 和第三方Tracer的对接
4. 数字证书分发

等功能。这些功能都需要Istio和Envoy的协同才能生效。最基础和关键的协同是Istio组件Pilot和Envoy之间基于xDS协议进行的各种Envoy配置信息的推送。

Istio的文档并没有对Istio Pilot和Envoy如何交互进行描述，本文结合Istio、Envoy的源码来探讨这些细节。

Pilot的model包为很多Pilot抽象创建了模型（结构），并定义了它们支持的操作。注意这里建模的是Pilot的抽象，因此名词Service是指Istio的抽象服务，而非K8S的Service或者Envoy的Cluster。

对Istio的配置信息、配置存储进行建模。

代表一个Istio配置单元：

配置的元数据：

定义一组平台无关的，但是底层平台（例如K8S）必须支持的API，通过这些API可以存取Istio配置信息

每个配置信息的键，由type + name + namespace的组合构成，确保每个配置具有唯一的键

写操作是异步执行的，也就是说Update后立即Get可能无法获得最新结果。有资源版本判断资源是否更新

此接口返回的引用，仅支持只读操作，对其修改存在线程安全问题

表示ConfigStore的本地完整复制的缓存，此缓存主动和远程存储保持同步，并且在获取更新时提供提供通知机制。

为了获得通知，事件处理器必须在Run之前注册，缓存需要在Run之后有一个初始的同步延迟。

此接口扩展ConfigStore，增加一些针对Istio资源的操控接口：

此结构为Pilot提供聚合的环境性的API：

此结构建模代理（Envoy代理）的属性，xDS使用此结构对代理进行识别：

用于区分不同代理在网格中的职责。

端点分片，存储单个服务的单个注册表中的单个分片的名称及其端点列表：

存储单个服务的所有分片信息。使用K8S作为注册表时，Shards通常只有一个元素，其键是"Kubernetes"，其值是Shard名为"Kubernetes"的EndpointShard

此结构用于代替NetworkEndpoint和ServiceInstance，做了以下优化：

1. ServicePortName字段代替ServicePort字段。原因是进行了端点回调（endpoint callbacks are made）时端口号、协议可能不可用
2. 合并两个结构，原因是一对一关系
3. 不再持有Service的指针。原因是接收到端点时，服务对象可能不可用
4. 提供缓存的EnvoyEndpoint对象，避免为每次请求/每个客户端重新分配

参考下文。

此结构对Istio服务进行建模，每个服务具有全限定的名称（FQDN），一个或多个监听的端口，一个可选的和服务关联的负载均衡器/虚拟IP地址（FQDN解析到此地址）。

例如，在K8S中，服务kubernetes关联到FQDN kubernetes.default.svc.cluster.local，具有虚拟IP地址10.96.0.1，监听443端口。

用于指示在路由请求之前，如何解析出服务的实例：

服务的特定版本的一个实例，绑定到一个NetworkEndpoint：

建模关联到服务的实例的网络地址：

对服务监听的网络端口进行建模：

通信协议：

流量的方向：

此接口用于发现服务的实例：

Pilot（Pilot Discovery，其对应的客户端组件是Pilot Agent）是Istio最关键的组件，它的职责是将用户提供的、简单的、CRD形式的配置文件，转换为Envoy能理解的格式，并推送给Envoy以更新代理配置。

Pilot的启动逻辑位于bootstrap包中。

我们需要进行单步跟踪，才能了解Pilot在初始化期间做了哪些事情。为了调试的方便，我们在K8S集群外部启动Pilot服务。参考下面的启动参数：

其中meshConfig可以直接从K8S集群中提取，此配置存放在Configmap中，名称为istio-system/istio。内容如下：

Pilot的入口点位于pilot/cmd/pilot-discovery/main.go，它使用包spf13.cobra来管理一组子命令，Pilot核心功能由discovery子命令实现。

入口点的启动过程如下：

1. 解析命令行参数
2. 创建主服务，服务建模在结构bootstrap.Server中
   1. 调用initKubeClient方法，初始化K8S客户端
   2. 调用initClusterRegistries方法，初始化clusterStore字段
   3. 调用initMesh方法，初始化mesh字段
   4. 调用initMixerSan方法，初始化Mixer服务的SAN
   5. 调用initConfigController方法，初始化configController字段。通过addStartFunc延后调用配置控制器的Run方法
   6. 如果启用了Istio的IngressController功能，则调用configaggregate.MakeCache，包装configController，使其能处理Ingress类型的资源
   7. 调用initServiceControllers方法，此控制器能够从底层服务发现机制中获取Istio抽象服务。通过addStartFunc延后调用服务控制器的Run方法
   8. 调用initDiscoveryService方法，初始化发现服务，发现服务依赖于前面创建的配置控制器、服务控制器，对xDS的支持有发现服务提供
   9. 调用initMonitor方法，初始化Pilot监控服务
   10. 调用initMultiClusterController方法，初始化多集群控制器，目前可以用于跨越多个K8S集群的服务网格
   11. 启动ControlZ监听器
3. 启动主服务，其实就是执行先前注册的延迟启动函数：
   1. 启动配置控制器
   2. 启动Ingress同步器
   3. 启动Service控制器
   4. 启动HTTP服务、gRPC服务、安全gRPC服务
4. 等待停止信号

表示Pilot主服务，它不是一个简单的（侦听单个端口）服务，而是很多服务的集合。包含的字段如下：

仅仅当args.Service.Registries包含Kubernetes，才会创建K8S客户端：

仅当创建了K8S客户端，才会调用此方法。

此方法创建的对象很简单，就是创建一个空的clusterregistry.ClusterStore：

Istio组件Mixer和Pilot需要相互通信，如果mesh.DefaultConfig.ControlPlaneAuthPolicy为mTLS，也就是说Mixer - Pilot通信需要双向TLS认证时，才调用此方法：

此方法转调makeKubeConfigController方法创建配置控制器：

initConfigController方法返回值的真实类型是crd.controller，除了实现ConfigStoreCache 接口的方法以外，它还负责管理Informer。它为每种CR创建一个Informer：

Pilot中的控制器的工作模式基本都是一样的，下文我们详细分析。

如果必要（允许Istio处理Ingress资源的话），initConfigController还会创建IngressController：

包config/aggregate可以将处理不同资源类型的model.ConfigStoreCache组合起来，形成一个更大的model.ConfigStoreCache。接口保持不变，根据资源类型委托给适当的被包装的子对象。

默认的配置下，Pilot会把Config控制器、Ingress控制器组合起来：

Istio网格的入口通常是Gateway，但是它也能够处理K8S原生的Ingress资源，也就是说Istio可以扮演K8S通常意义上的Ingress Controller。实际上入口流量由istio-ingress这个deployment的Pod处理。

哪些Ingress资源会被管理，由主服务的mesh.IngressControllerMode配置决定：

1. MeshConfig_OFF（0）：禁用Istio的IngressController功能
2. MeshConfig_DEFAULT（1）：作为整个K8S集群默认的Ingress控制器
3. MeshConfig_STRICT（2）：仅仅处理包含了注解kubernetes.io/ingress.class，且值等于mesh.IngressClass（默认istio）的Ingress资源

创建IngressController的逻辑位于initConfigController方法中。

此方法首先创建一个聚合控制器：

serviceregistry/aggregate中定义的“聚合控制器”，能够管理多个平台（例如K8S）的服务发现机制（ServiceRegistry）。

然后，它调用createK8sServiceControllers方法创建kube.Controller：

然后，创建ServiceEntry发现服务，并添加到聚合控制器：

最后，注册ServiceController的延迟启动。

kube.Controller能够监控K8S中service、endpoint、node、pod等对象。它实现了model.Controller、model.ServiceDiscovery、model.ServiceAccounts等接口。

该结构包含以下字段：

此方法首先创建一个新的发现服务：

结构envoy.DiscoveryService是真正的发现服务，是Pilot的核心。它负责推送配置给Envoy。

然后，创建一个gRPC服务器、一个HTTP服务器：

创建xDS服务：

注册envoy包的全局函数：

将xDS服务注册到上述gRPC服务器上：

在使用K8S作为后端时，还会配置kube.Controller：

最后，注册httpServer、grpcServer的延迟启动。

proxy/envoy包中定义的这个函数，负责创建一个新的发现服务。它会创建一个RESTful容器并将发现服务注册到此容器：

它还会向serviceregistry/kube.Controller注册Service、Instance的处理器，对于K8S来说，当Serivce、Endpoint发生变更时，会获得通知。

这些处理器的逻辑很简单，就是清空Envoy缓存，但是kube.Controller附加了一些前置逻辑。

不论是K8S内置资源，而是Istio的CR，都由client-go负责List&Watch，并把事件会传递给config/kube/crd/controller.go、config/kube/ingress/controller.go、serviceregistry/kube/controller.go等控制器中的回调函数处理：

可以看到，此回调函数的逻辑仅仅是将事件及其处理函数封装为Task并存放到控制器的队列中：

队列的Run循环则取出事件并调用其处理函数：

处理函数就是ChainHandler结构的Apply方法，此结构允许针对一个事件串行的调用多个实际的处理函数：

ChainHandler是在对应控制器的初始化阶段创建的，实际处理函数也在那时注册。

Pilot对很多K8S资源变更的响应，都是简单的清除掉Envoy的配置缓存。它们调用的是envoy包的v1版本的DiscoveryService.clearCache方法：

可以看到，此方法仅仅是简单的请求一次Envoy配置的Full Push。 也就是说Pilot在配置变更的情况下，通常会完整的推送Envoy配置，幸好推送过程具有防抖动支持，而且配置变更不是频繁操作，否则可能出现性能问题。

config/kube/ingress/controller.go注册了多个处理函数，第一个处理函数判断是否informer已经完全同步，如果不是，则中止处理。第二个处理函数则是简单的清除Envoy缓存配置。

第一个处理函数是控制器的notify方法，此函数判断是否informer已经完全同步，如果不是，则中止处理：

第二个处理函数，首先将IstioObject转换为model.Config，然后转调在启动阶段通过s.configController.RegisterEventHandler()为不同资源类型注册的实际处理函数：

MeshPolicy、VirtualService、DestinationRule、Gateway的实际处理函数，都仅仅是清除掉所有Envoy缓存。

此CRD的实际处理函数的逻辑复杂一些。首先将model.Config.Spec转换为具体的Istio结构：

然后，将ServiceEntry转换为Istio内部的“服务”（model.Service）并异步处理 。model.Service具有FQDN、若干端口、可选的负载均衡/虚拟IP：

最后，将ServiceEntry转换为Istio内部的“实例”（model.ServiceInstance）并异步处理。model.ServiceInstance关联到一个网络端点（ip:port），具有一个服务描述和一组描述服务版本的标签：

不管是服务还是实例，go handler ...的逻辑仍然仅仅是清除掉所有Envoy缓存。

在这里可以注意到，ServiceEntry所（通常）表示的外部服务、和一般性的K8S服务，在Istio内部具有相同的表示 —— Service + ServiceInstance。

第一个处理函数是控制器的notify方法，此函数判断是否informer已经完全同步，如果不是，则中止处理。

对于节点资源，默认情况下没有其它处理逻辑。

pilot的serviceregistry包维护了一个最终一致性的Pod缓存：

Pod事件会触发PodCache.event方法的调用，此方法会更新Pod的IP地址和namespace/name形式的Key之间的映射关系，并且为EDS服务更新工作负载：

 

Pilot Discovery和Envoy代理配置的更新（这些配置更新都是由于K8S资源变化而引发）、推送有关的逻辑，主要分布在三个包中：

1. proxy/envoy，主要的逻辑在此，包括xDS的实现
2. model，推送上下文（PushContext）定义在此包中，此结构在每次推送时创建，持有和本次推送相关的所有上下文信息
3. networking，负责生成Envoy的配置文件格式

推送由DiscoveryService.ConfigUpdate()方法触发，转调DiscoveryServer.Push()，后者调用PushContext初始化一系列相关的数据结构，并调用networking包中ConfigGenerator的方法生成Envoy v2的结构，然后向所有连接到Pilot的Envoy代理发起推送。

此结构负责发布服务、集群、路由给所有的代理。

缓存的结构如下，是一种通用的存储：

此方法清除缓存，目前的实现很简陋，就是发起 ds.ConfigUpdate(true)调用，会请求完整的配置推送。

此方法实现ConfigUpdater接口。逻辑如下：

debouncePush方法中包含一些额外的去回弹逻辑：

doPush方法真正触发配置推送：

注意，全局函数BefoerPush实际上是envoyv2.DiscoveryServer.BeforePush方法：

类似的，全局函数Push 也是envoyv2.DiscoveryServer.Push方法。

也就是说，推送的职责在这里转交给DiscoveryServer了。

此结构提供了Envoy v2 xds API的gRPC实现，在启动阶段由initDiscoveryService创建。

此结构支持的方法繁多，定义在proxy/envoy/v2包中的ads.go、cds.go、eds.go、lds.go、rds.go等文件中，对应xDS API的各子集以及ADS。其中一部分方法是通过接口暴露的，例如：

1. AggregatedDiscoveryServiceServer，Envoy提供的gRPC接口。在ads.go中实现
2. XDSUpdater，在push_context.go中定义，在eds.go中实现

此方法的逻辑很简单，将上次变更依赖的服务端点变更增量提取出来返回，并重置此“变更增量”为空：

在未来，Istio对增量更新提供完整支持后，这里需要重构。在将proxy/envoy/discovery合并到v2 discovery之后，此方法不再允许外部访问。

该方法在准备好配置后，使用ADS协议执行推送：

可以看到，startPush仅仅是把事件放入通道，并不直接牵涉到gRPC相关的操作。这实现了数据和传输的解耦。

推送上下文，此结构跟踪推送的状态（指标、错误）。在一次推送完毕后，指标全部置零。

此结构提供了Add、UpdateMetrics方法，和Prometheus统计指标有关：

该方法负责初始化一个新的推送上下文，生成所需的一切数据结构，在执行Envoy配置推送之前你需要（从创建PushContext的协程）调用它。

该方法缓存注册表中的所有服务。

该方法缓存所有VirtualService对象。

该方法初始化所有DestinationRule对象。

列出绑定到指定网关的序列服务。

返回一个服务的DestinationRule。

计算出给定服务的给定子集对应的标签。Istio使用K8S Pod标签区分子集。

此接口负责请求配置更新，在配置推送之前，需要进行去回弹（防止连续触发的频繁推送）。

目前，接口由DiscoveryService实现，而DiscoveryServer也引用前者：

XDSUpdater用于xDS模型的直接更新，以及增量推送。DiscoveryServer实现了此接口。

Pilot使用多个注册表 —— 例如每个K8S集群就是一个注册表。每个注册表负责跟踪关联到网格中服务的端点的变更，并在变更后调用EDSUpdate方法。

注册表可以单个服务的端点分组为更小的子集（例如每个Deployment一个子集），以处理端点数量巨大的服务。由于限制可扩容性，Istio倾向于避免传递大量的对象，例如某个注册表的全部端点，或者某个服务在全部注册表中的端点。

Istio在未来会进行一些优化，例如以标签、网关、或者区域来分组端点。

当服务的信息发生变化后，调用此方法，主要逻辑是更新全局推送上下文中的ServicePort2Name字段。

当工作负载的标签/注解发生变化后，PodCache调用此方法：

kube.Controller在接收到K8S的端点更新后，会调用其自身的updateEDS方法：

此接口位于networking.core包中，负责生成xDS响应。其实现位于v1alpha3子包（Istio CRD的API版本号）中。接口规格如下：

注意BuildYYY函数的返回值均为Envoy v2协议的ProtoBuf消息类型。

该方法的实现如下：

networking包提供了一种插件机制，允许在构造xdsapi.Listener期间，对xdsapi.Listener进行任意的修改。例如启用：

1. AuthenticationPlugin插件，可以在入站监听器、出站集群上设置mTLS认证
2. mixer插件，可以在入站监听器上设置策略检查

插件类型包括：

插件接口规格如下：

具体的插件，只需要按需实现部分方法即可。

一系列传递给插件回调函数（Plugin接口函数）的值，这些值应该被插件只读访问：

传递给On*Listener回调的一系列对象：

传递给On*Cluster回调的Envoy Cluster对象，直接对应ProtoBuffer消息。

传递给On*RouteConfiguration回调的Envoy RouteConfiguration对象，直接对应ProtoBuffer消息。

本章讨论Pilot Agent的启动过程，以及Envoy的Bootstrap配置是如何生成和重新载入的。Pilot Agnet和Pilot Discovery如何通信在下一章分析。

为了方便调试，我们在本地启动Pilot Agent，参考下面的命令行参数：

Pilot Agent的入口点位于pilot/cmd/pilot-agent/main.go，它使用包spf13.cobra来管理一组子命令，Pilot核心功能由proxy子命令实现。

入口点的启动过程如下：

1. 解析命令行参数
2. 初始化model.Proxy对象，在K8S环境下
   1. ID=$POD_NAME.$POD_NAMESPACE
   2. Domain 从命令行--domain参数传入
   3. IPAddress，从环境变量INSTANCE_IP读入
3. 如果控制平面的身份验证策略是mTLS，则初始化Pilot的SAN
4. 调用model.ValidateProxyConfig进行代理配置合法性验证
5. 初始化数字证书位置信息，默认存储在/etc/certs/。如果当前代理的角色不是sidecar而是ingress，还要初始化Ingress数字证书位置信息
6. 如果提供了Envoy配置模板，且CustomConfigFile为空（不使用自定义Envoy配置文件），则根据此模板生成一个Envoy配置文件，并将其路径赋值给CustomConfigFile
7. 如果提供了statusPort，则调用status.NewServer启动一个状态服务。访问状态服务的/healthz/ready可以知晓代理是否准备好
8. 调用envoy.NewProxy，创建一个envoy结构
9. 调用proxy.NewAgent，创建一个agent结构
10. 调用envoy.NewWatcher，创建一个watcher结构
11. 调用watcher.Run启动Watcher
    1. 启动Agent控制循环
    2. 调用Reload立即载入，导致Envoy进程启动
    3. 调用watchCerts监听数字证书的变化

此结构位于proxy.envoy包中，封装启动envoy所需的信息：

该结构实现了Proxy接口：

此方法生成Envoy的Bootstrap配置，并启动Envoy进程：

此方法生成Envoy Bootstrap配置。使用的配置模板，按以下逻辑寻找：

1. 如果指定了--customConfigFile，使用此文件。这步逻辑仅仅用于测试，实际无用
2. 如果config.ProxyBootstrapTemplatePath不为空，使用此文件。此字段没有通过命令行暴露
3. 否则，使用常量DefaultCfgDir指定的值，也就是默认配置
4. 如果设置了环境变量ISTIO_BOOTSTRAP，使用此变量指定的配置模板路径

默认配置的路径是/var/lib/istio/envoy/envoy_bootstrap_tmpl.json，内容为Envoy的JSON格式的配置的Go Template。

生成的Envoy配置文件样例：

此结构位于proxy.envoy包中，它是envoy proxy的代理人（Agent） 。它负责管理envoy进程的生命周期和重启。

Agent跟踪所有运行中的代理epochs及其配置。Envoy热重启通过启动具有递增的重启纪元的（strictly incremented restart epoch）代理进程实现。优雅的关闭旧的epochs并且将所有必须的状态传递给最新的epoch是envoy的职责，Agent不会去主动关闭旧的epoch对应的envoy进程。

最初的epoch是0。

这里使用的重启协议（restart protocol ）是和Envoy的重启纪元（restart epochs）语义匹配的：为了成功启动用来替代正在运行的Envoy的新进程，新进程的重启纪元必须正好比所有正在运行的其它Envoy进程中纪元最大的那个高1。

Agent需要调用Proxy的两个函数：

1. Run函数，用于启动代理，且必须一直阻塞直到代理退出
2. Cleanup函数，用于在代理退出后立即进行清理，此函数必须是非阻塞的，因为它在Agent的主控制循环中被调用

这两个函数都以代理的纪元作为入参。

每当Run函数返回了错误，Agent都假设代理启动失败了，并且会重试若干次。后续的重启可能重用之前失败的启动的纪元号。

该结构实现了Agent接口：

此方法重现载入新的代理配置：

此方法调用代理的Run()方法，并且在其崩了后，将错误码写入通道：

此结构位于proxy.envoy包中，负责当代理配置发生变化后，触发Agent的reload。它持有agent，还监控数字证书的变更：

此结构实现了Watcher接口：

促使Agent立即启动Envoy：

Agnet的ScheduleConfigUpdate很简单，就是写通道：

从这里可以看出，导致代理需要重新载入的唯一原因，就是数字证书发生了变更。 

此结构表示当前代理的配置，和命令行选项是对应的：

此结构表示数字证书的存储位置：

代理端的通信行为（主要是xDS）完全由Envoy负责，和Istio无关，后者仅仅提供Bootstrap配置并在必要时Reload。

Envoy的入口点定义在source/exe/main.cc中，仅仅是创建一个Envoy::MainCommon对象并调用其run方法：

Envoy::MainCommon对象的创建过程如下：

1. 创建化负责信号处理、线程池、命令参数解析、定时器的实例变量
2. 创建MainCommonBase base_：
   1. 创建热重启器
   2. 进行日志配置
   3. 创建化监控指标的存储
   4. 创建Envoy服务InstanceImpl —— Envoy服务本体
      1. 初始化热重启器
      2. 通过组件工厂ComponentFactory创建DrainManager
      3. 初始化InstanceImpl：
         1. 加载Bootstrap配置
         2. 配置StoreRoot，该对象是负责监控指标的存储，包括Sink的管理
         3. 从Bootstrap配置创建一个InitialImpl，表示Envoy服务器的最初配置
         4. 利用InitialImpl创建Admin端点，并启动其监听器，开始监听15000端口
         5. 创建过载管理器，用于保护Envoy实例所在节点不资源耗尽
         6. 创建监听器管理器ListenerManager
         7. 通过主线程的Dispatcher，为主线程注册线程本地存储（TLS）
         8. 调用StoreRoot的initializeThreading，启用多线程支持
         9. 创建Runtime::Loader，此对象能够从磁盘读取Envoy的运行时快照
         10. 创建SSL上下文管理器
         11. 创建集群管理器工厂ProdClusterManagerFactory
         12. 传入集群管理器工厂，初始化Envoy服务器的主配置Configuration::MainImpl
             1. 使用密钥管理器添加bootstrap_中配置的静态密钥
             2. 使用集群管理工厂，传入bootstrap配置，创建集群管理器
             3. 创建限速客户端工厂RateLimitClientFactory
             4. 调用监听器管理器，添加所有静态配置的监听器
             5. 调用initializeTracers，为当前Envoy服务器初始化Tracer
             6. 调用initializeStatsSinks，初始化监控信息的Sink
         13. 为HTTP上下文设置Tracer
         14. 如果配置了LDS动态资源，则调用监听器管理器，创建注册gRPC订阅
         15. 将Sinks添加到StoreRoot
         16. 为StoreRoot的Flush设置定时器
         17. 初始化用于死锁检测的GuardDog

run方法简单的转发给MainCommonBase.run，进而转发给Server::InstanceImpl的run方法。如果运行模式是Serve，则后者的逻辑如下：

1. 初始化RunHelper
2. 调用GuardDog创建针对主线程的WatchDog
3. 启动WatchDog，由主线程的Dispatcher创建定时器，定期touch此WatchDog
4. 阻塞性的运行Dispatcher事件循环
   1. 调用runPostCallbacks，在运行事件循环之前执行所有后置回调。默认情况下没有需要执行的回调
   2. 调用event_base_loop，运行event_base直到1-N个未决/活动事件可用
5. 当Dispatcher.exit被调用（也就是主事件循环退出）后，停止WatchDog
6. 调用Server::InstanceImpl的terminate方法，停止Envoy服务器
7. 重置RunHelper

从第5步开始，主线程会阻塞很长时间。后续的逻辑都主要通过libevent事件驱动 —— 当发生网络事件后执行某种回调。

如果定义了宏ENVOY_HANDLE_SIGNALS，则MainCommon的成员变量负责处理信号：

MainCommon的成员变量 PlatformImpl platform_impl_;定义平台依赖的操作，目前仅仅包含一个线程工厂实现。

MainCommon的成员变量 Envoy::OptionsImpl options_;负责利用TCLAP解析命令行参数，它实现 Envoy::Server::Option接口，通过此接口可获得各种Envoy启动选项。

MainCommon的成员变量 Event::RealTimeSystem real_time_system_;用于墙上时间度量，以及设置定时器、执行回调。

MainCommon持有此类型的一个对象，并且把绝大部分职责委托给此类处理。构造函数逻辑如下：

InstanceImpl类实现接口Instance，代表一个运行中的、由若干紧密协作的组件构成的、独立运行的Envoy服务。

该类的构造函数逻辑如下：

初始化逻辑如下：

此方法的代码如下：

此方法的代码如下：

此运行助手对象的职责包括：

1. 初始化信号处理，主要时关闭Instance
2. 设置集群管理器的初始化后回调
   1. 暂停RDS订阅
   2. 执行初始化管理器的初始化，初始化其上注册的所有目标，最后启动工作线程
   3. 恢复RDS订阅
3. 启动过载管理器

构造函数代码如下：

此方法的代码如下：

到这里可以看到，启动过程的最后，主线程陷入无限循环。

所有后续的逻辑，由Envoy的事件机制来触发。此事件机制的核心是事件分发器接口（Dispatcher），在Envoy启动期间，很多事件回调被注册到Dispatcher，并在以后异步的、可能反复的执行。

Envoy使用libevent2提供的事件机制，但是在其上做了一层封装 —— Dispatcher，事件回调就是通过此Dispatcher注册的。Dispatcher的接口如下：

DispatcherImpl是基于libevent的Dispatcher实现。可以看到，注册回调主要依靠createFileEvent方法。

在Envoy启动阶段，会注册多个事件回调，包括热重启模块的信号回调、DNS解析模块的回调、ADS客户端的定时器回调。

该接口用于执行多个目标的初始化：

单个初始化目标由下面的类型表示：

该实现用于Post集群管理器、Pre监听时的初始化管理。集群管理器并不是单个实例，例如每个Cluster都有自己的初始化管理器。

HotRestartImpl实现热重启功能，在初始化时它为UDS注册一个事件回调：

事件到达后调用onSocketEvent()方法，获取RCP消息，根据消息类型做出各种处理，例如：关闭Admin端点、Drain监听器、返回监控统计信息、停止当前进程。

DnsResolver负责异步的DNS解析。多个组件需要进行DNS解析，例如StrictDnsClusterImpl.startPreInit方法会解析集群的DNS域名。

InstanceImpl在构造函数中创建DnsResolverImpl：

DnsResolverImpl在初始化期间，会将onAresSocketStateChange方法作为回调传递给ares：

当某个ares套接字可读可写时，会调用onAresSocketStateChange：

上面的“ares套接字可读可写”，可以由解析DNS的请求来触发，例如StrictDnsClusterImpl.startPreInit会触发DNS解析：

上面代码的最后一个方法，回调被传递给PendingResolution对象，随即调用其getHostByName方法：

此方法调用c-ares库进行主机名解析，回调是PendingResolution的onAresHostCallback方法：

总之，DNS解析是由Dispatcher的回调机制和ares的回调机制协作实现的，达到的效果是异步、高效的DNS解析。

在Envoy主服务InstanceImpl的主配置的初始化过程中，会创建集群管理器ClusterManagerImpl。

集群管理器负责Bootstrap配置中定义的静态集群的初始化，以及CDS/EDS的订阅的启动。这个处理过程比较复杂，分为多个阶段完成

1. 初始化静态/DNS集群
2. 初始化预定义的EDS集群
3. 如果需要，初始化CDS订阅，并等待响应
4. 初始化CDS提供的集群，分为两个阶段
   1. 主（Primary）集群初始化，所有非EDS集群是主集群
   2. 次（Secondary）集群初始化，EDS集群为次集群。每个EDS集群会独自创建一个xDS订阅，这导致EDS集群需要依赖于非EDS集群（xds-grpc，STRICT_DNS集群），因此EDS集群需要在第二阶段初始化
5. 如果集群启用了主动健康检查，此时会触发单轮检查

由集群管理器调用init_helper_.addCluster完成，该方法实现如下：

可以看到，init_helper会调用集群的initialize方法，这是定义在ClusterImplBase中的模板方法：

集群初始化的第一步是预初始化，静态集群对该方法的实现如下：

DNS集群的startPreInit，从DNS解析开始：

DNS解析完成后，异步的执行下面的回调：

EDS集群的startPreInit，从启动EDS订阅开始：

预初始化完成后，此时端点列表已经获得。onPreInitComplete执行下面的回调，进行必要的健康检查：

然后调用finishInitialization方法。

此回调的实现：

per_cluster_init_callback_在集群管理器构造时，通过初始化列表传递给ClusterManagerInitHelper，其实现就是集群管理器的onClusterInit方法：

集群管理器通过此方法进行集群的后初始化处理：

在每个集群的初始化后都会调用， 判断初始化过程是否可以结束：

调用此方法，可以设置在所有集群都初始化之后，调用的回调。

RunHelper会调用此函数，注册的回调会导致InitManager初始化，后者会导致：

1. LdsApiImpl，注册到InitManager的Target，被初始化
2. LdsApiImpl初始化完毕后，工作进程启动

在InstanceImpl初始化阶段，它会创建全局的监听器管理器：

构造函数如下：

在主配置初始化阶段，静态监听器被创建：

MainImpl::initialize将监听器创建工作委托给监听器管理器完成：

如果需要创建新的监听器，则监听器管理器会调用下面的构造函数：

监听器管理器创建新的监听器后，可能需要为其创建监听套接字，这是通过调用ListenerComponentFactory实现的：

监听器管理创建/更新监听器后，会调用此方法：

工作线程对象（WorkerImpl）是由监听器管理器在其构造函数中创建的。 ProdWorkerFactory::createWorker的实现如下：

工作线程的构造函数如下：

需要注意，注册到TLS时，使用的是线程的分发器，而不是线程本身。

工作线程的启动，默认配置下，是由RunHelper注册给集群管理器的setInitializedCb回调触发的。此回调会初始化InitManager，默认配置下，注册到InitManager的唯一Target是LdsApiImpl。而InitManager的总回调就是InstanceImpl::startWorkers方法。

也就是说，当LDS客户端初始化完毕后，工作线程才会启动。

Envoy服务实例提供了启动线程的方法：

监听器管理器的同名方法内容如下：

WorkerImpl::start方法就是启动一个物理线程：

在新线程中，会执行下面的函数：

只要当线程真正启动后，它的事件循环才会运作，  ListenerManagerImpl::addListenerToWorker注册的关联监听器到工作线程的请求才会被执行。

在工作线程启动之前，需要关联到监听器：

在集群管理器初始化一节中，我们了解到，如果Bootstrap配置中包含了ADS配置，则集群管理器会创建GrpcMuxImpl —— ADS API的客户端实现，用于通过gRPC协议，在连接到管理服务器的单个流中管理多个gRPC订阅。GrpcMuxImpl支持ADS订阅的同时，也可用于单种xDS API，例如EDS。

GrpcMuxImpl的start方法包括延迟创建到管理服务器的流的逻辑：

集群管理器在初始化完毕所有静态集群后，会调用上述方法。 

GrpcMuxImpl的构造函数中也包括延迟创建到管理服务器的流的逻辑：

定时器是libevent支持的一种事件触发方式。在定时器到期后，会执行GrpcMuxImpl::establishNewStream方法：

queueDiscoveryRequest会调用sendDiscoveryRequest发送xDS请求：

除了establishNewStream以外，subscribe方法也会调用queueDiscoveryRequest。各种xDS API的客户端实现，例如CdsApiImpl，都会调用subscribe方法，来订阅某种资源：

ADS客户端启动后，Istio Pilot随时可能将动态的集群信息推送过来。

推送信息经过一系列的处理（包括Envoy的过滤器链）后，被onReceiveMessage处理：

可以看到onReceiveMessage会转调各订阅者提供的回调函数，完毕后则会触发下一次发现请求。

CDS客户端是在集群管理器初始化阶段创建的：

构造函数如下：

在每个集群初始化后都会触发的maybeFinishInitialize中，进行CDS客户端初始化：

初始化逻辑很简单，就是启动订阅：

CdsApiImpl.subscription_字段类型为 Config::Subscription<envoy::api::v2::Cluster>，就是上文提到的GrpcMuxImpl，CDS会订阅type.googleapis.com/envoy.api.v2.Cluster这种资源。

GrpcMuxImpl::onReceiveMessage对接收到的推送进行处理后，转交给CdsApiImpl::onConfigUpdate处理：

addOrUpdateCluster负责添加或更新集群：

addOrUpdateCluster可能会调用ClusterManagerInitHelper::addCluster，就是集群管理器初始化，针对静态配置的集群调用的方法。但是这次走针对次集群的分支。

EdsClusterImpl是一种集群实现，它基于EDS协议发现自己的主机（端点，对应Envoy API是ClusterLoadAssignment.endpoints_）。

EdsClusterImpl同时充当了EDS客户端的角色。CDS客户端是单例的，而每个EDS集群都是EDS客户端，它们各自独立向ADS服务器发起订阅。

Eds集群本身可能就是通过CDS订阅获得的，在EdsClusterImpl的构造函数中，它会创建订阅：

在EDS集群的preInit阶段，会启动订阅，只会订阅当前集群的端点：

GrpcMuxImpl::onReceiveMessage对接收到的推送进行处理后，转交给EdsClusterImpl::onConfigUpdate处理： 

LDS客户端是作为InitManager的target之一，进行初始化的。InitManager会先初始化它的所有目标，最后初始化它自己。

InitManager会在集群管理器初始化完毕——所有集群都添加之后被调用。

如果配置了动态LDS资源，则在InstanceImpl的初始化过程中，会创建LDS客户端：

初始化管理器会调用：

导致LDS订阅启动。 

GrpcMuxImpl::onReceiveMessage对接收到的推送进行处理后，转交给LdsApiImpl::onConfigUpdate处理：

该组件一方面实现了完整的xDS协议管理服务器端，一方面对接底层基础设施（K8S），从中获取各种各样的资源。

Discovery关注的K8S资源类型包括：

1. Ingress：需要此资源的原因是，Istio可以作为Ingress Controller
2. Istio CRD，Istio需要：
   1. VirtualService、DestinationRule来构建Envoy的Cluster配置、Listener路由规则
   2. Gateway来为作为网关的Envoy代理（ingressgateway、egressgateway，或者任Pod）提供监听器，并由绑定到网关的VirtualService提供路由表
   3. ServiceEntry来创建一部分Istio服务，进而构建Envoy的Cluster配置、Listener配置
3. Service：Istio需要这种资源创建Istio服务，进而构建Envoy的Cluster配置、Listener配置
4. Pod：Istio需要这种资源为EDS集群更新工作负载

当Discovery发现上述某种资源变更后，会准备好一个推送上下文，并且依据此上下文生成所需的Envoy配置，推送给Envoy代理。

推送服务由DiscoveryService负责，它转调DiscoveryServer。后者提供了Envoy v2 xDS API的gRPC客户端实现，其逻辑在ads.go、cds.go、eds.go、lds.go、rds.go等多个源文件中实现，对应了xDS API的不同部分。

所有连接到Discovery的、发起了订阅请求的代理，都会接收到推送。

该组件包装了Envoy代理，主要实现以下功能：

1. 从模板生成Bootstrap配置
2. 守护Envoy代理，如果宕机重新启动
3. 当Bootstrap配置文件更新后，重现配置Envoy代理
4.  更新数字证书

Proxy有多种运行模式：sidecar、ingress、proxy，分别用作普通Pod的边车、Ingress控制器、入口/出口网关。

该组件实现了完整的xDS协议客户端。和Pilot Discovery的交互主要由GrpcMuxImpl负责，它是基于gRPC的ADS实现。

除了通过Bootstrap配置加载的静态资源，其它资源都需要通过xDS协议，向Pilot Discovery订阅以获取。GrpcMuxImpl获得资源推送后，会调用CDS、EDS、LDS、RDS等API客户端：

1. CDS，动态加载集群，可能创建EDS
2. EDS，为EDS集群更新端点
3. LDS，动态加载监听器，可能触发工作线程的启动