Envoy 生命周期管理

Service Mesh 架构思想不是最近才产生，之前很长时间内一直没有引起足够的重视，一个很重要的原因是部署和运维的复杂度太高，如果没有相应的基础设施和工具体系支撑，很难保证 Service Mesh 运维的效率，也很难保障业务 Service Mesh 故障情况下的业务可用性。Istio 在部署运维、生命周期管理方面充分利用 Kubernetes 基础设施的优点，有力地保障了 Service Mesh 的效率和可用性。

一、Envoy 注入

Envoy 注入是通过相应的手段将 Envoy 注入到 Envoy 运行环境中，Istio 利用 Kubernetes 的特点，以优雅的方式实现 Envoy 注入，大大简化 Envoy 运维和管理上的开销。

目前，Envoy 注入分为手工注入和自动注入两种方式。手工注入是指使用 istioctl 工具构建包含 Sidecar 镜像的模板，然后通过 kubectl apply–f xxx.yaml 将包含 Sidecar 镜像的模板文件注入到 Pod 中；自动注入基于 Kubernetes 的 Admision Webhook 机制，在 Pod 资源创建过程中自动触发。手工注入方式整体效率仍然偏低，而自动注入方式充分利用 Kubernetes 平台提供的机制和能力，实现了 Sidecar 透明接入，所以推荐使用自动注入的方式来完成 Envoy 的注入。

二、Envoy 启动管理

Pilot-agent 负责 Envoy 的启动和运行状态监控，Pilot-agent 会根据 Envoy 的类型，拼装相应的启动配置文件和启动参数，进行 Envoy 的启动或重启；同时通过探测和监控 Envoy 当前的运行状态，或者接收外界的配置变更等控制指令，对非正常状态的 Envoy 进行重启或调整。

节点类型是 Envoy 具体的运行模式，当前支持 sidecar、ingress 和 router 3 种运行模式，Sidecar 模式和业务微服务捆绑部署，用于 Istio 集群内部微服务之间流量的透明代理；Ingress 用于 Istio 集群对外的流量代理，负责将集群内部服务暴露出去，供集群外部访问；Router 是独立的 L4/L7 层代理。

Envoy 元数据负责 Envoy 自定义属性信息的维护，主要用于数据平面和控制平面之间的 XDS 交互。元数据信息由控制平面 Pilot-agent 生成，作为 Bootstrap 启动信息的一部分，供 Envoy 服务启动时使用。Envoy 启动后和控制平面交互获取当前节点的 XDS 信息时，会把本节点的 Envoy 元数据信息透传给控制平面，辅助控制平面生成相应的 XDS 配置信息。总之，控制平面生成元数据信息用于 Envoy 启动，Envoy 启动后透传元数据信息给控制平面用于 XDS 配置的生成决策。

Pilot-agent 根据 Envoy 配置模板和当前的启动信息，生成相应的 Envoy 启动文件，用于接下来的 Envoy 启动过程。Envoy 配置模板用于定义 Envoy Bootstrap 启动配置的格式，istio/tools/deb/envoy_bootstrap_v2.json 就是 Envoy 配置模板的一个典型例子。

Envoy 启动后，会记录当前 Envoy 的配置信息，后续启动相关操作前会先比较新配置是否和当前配置相同，如果配置相同不进行任何处理，否则会继续启动流程。Envoy 启动相关准备工作完成后，即可通过 Exec 命令启动 Envoy 进程，启动时将新 Envoy 进程的标准输出 stdout 和标准错误 stderr 进行重定向。启动完成后，通过监控 Envoy 进程的退出码，对 Envoy 的运行状态进行监控。

三、Envoy 配置和运行状态监控

Pilot-agent 通过 watch 对象负责配置文件的监控，比如证书文件发生变化时，watch 对象感知到变化事件后，通知 Pilot-agent 进行处理。配置文件变更感知和处理是通过单独启动一个 Go 协程的方式进行处理，具体处理函数是 watchCerts。watchCerts 通过 fsnotify 的机制来进行变更感知，感知到配置文件变化时，会调用 watchFileEvents 进行处理。