架构

Envoy

Pilot

Citadel

Galley

抽象模型

平台适配器

       例如 Pilot 中的 Kubernetes 适配器通过 Kubernetes API 服务器得到 Kubernetes 中 service 和 pod 的相关信息，然后翻译为抽象模型提供给 Pilot 使用

       通过平台适配器模式， Pilot 还可以从 Consul 等平台中获取服务信息，还可以开发适配器将其他提供服务发现的组件集成到 Pilot 中

xDS API

       通过采用该标准 API， Istio 将控制面和数据面进行了解耦，为多种数据平面 sidecar 实现提供了可能性

       例如蚂蚁金服开源的 Golang 版本的 Sidecar MOSN (Modular Observable Smart Network)

用户 API

       通过运用不同的流量规则，可以对网格中微服务进行精细化的流量控制，如按版本分流、断路器、故障注入、灰度发布等

pilot-agent

• 生成 sidecar 配置
  

  Sidecar 的配置主要在 pilot-agent 的 init 方法与 proxy 命令处理流程的前半部分生成：

  • init 方法为 pilot-agent 二进制的命令行配置大量的 flag 与默认值
  • proxy 命令处理流程则负责将这些 flag 组装成为 ProxyConfig 对象以启动 Envoy

  //go 语言，源码摘自 pilot-agent，role 角色定义
  role = &model.Proxy{}
  ...
  
  type Proxy struct {
      // ClusterID 用于指代 proxy 所在集群名称
      ClusterID string
  
      // Type 用于标记 proxy 运行模式
      Type NodeType
  
      IPAddresses []string
      ID string
      DNSDomain string
      ...
  }
  

  role 默认的对象为 proxy，关键参数如下：

  • Type：pilot-agent 的 role 有两种运行模式。根据 role.Type 变量定义，最新版本有2个类型，默认是 sidecar
    • sidecar
    • router
  • IPAddress, ID, DNSDomain：依据注册中心的类型，给予默认值
    • 默认处理方式是 Kubernetes，在 Kubernetes 默认值下
      • IPAddress 默认为 INSTANCE_IP
      • ID 默认为 POD_NAME
      • DNSDomain 默认为 default.svc.cluster.local

  Istio 可以对接的第三方注册中心有 Kubernetes、Consul、MCP、Mock
  

  Envoy 配置文件及命令行参数主要有2个：

  • 启动目录默认为/usr/local/bin/envoy
  • 启动参数相关代码在func (e *envoy) args中

  //go 语言，源码摘自 pilot-agent ，envoy 启动参数
  startupArgs := []string{"-c", fname,
          "--restart-epoch", fmt.Sprint(epoch),
          "--drain-time-s", fmt.Sprint(int(convertDuration(e.Config.DrainDuration) / time.Second)),
          "--parent-shutdown-time-s", fmt.Sprint(int(convertDuration(e.Config.ParentShutdownDuration) / time.Second)),
          "--service-cluster", e.Config.ServiceCluster,
          "--service-node", e.Node,
          "--max-obj-name-len", fmt.Sprint(e.Config.StatNameLength),
          "--local-address-ip-version", proxyLocalAddressType,
          "--log-format", fmt.Sprintf("[Envoy (Epoch %d)] ", epoch) + "[%Y-%m-%d %T.%e][%t][%l][%n] %v",
  }
  

  Envoy 启动参数关键释义：

  • –restart-epoch: epoch 决定了Envoy 热重启的顺序，第一个 Envoy 进程对应的 epoch 为0，后面新建的 Envoy 进程对应 epoch 顺序递增1
  • –drain-time-s: 在 pilot-agent init 函数中指定默认值为2秒，可通过 pilot-agent proxy 命令的 drainDuration flag 指定
  • –parent-shutdown-time-s: 在 pilot-agent init 函数中指定默认值为3秒，可通过 pilot-agent proxy 命令的 parentShutdownDuration flag 指定
  • –service-cluster: 在 pilot-agent init 函数中指定默认值为 istio-proxy ，可通 pilot-agent proxy 命令的 serviceCluster flag 指定
  • –service-node: 将 role 的字符串拼接成 node.Type~ip~ID~DNSDomain 格式
• Sidecar 的启动与监控
  

  //go 语言，源码摘自 pilot-agent ，envoy 启动代理及监听器
  envoyProxy := envoy.NewProxy(envoy.ProxyConfig{
          Config:              proxyConfig,            //Envoy 的配置，如目录等
          Node:                role.ServiceNode(),    //role 的字符串拼接 node.Type~ip~ID~DNSDomain 格式
          NodeIPs:             role.IPAddresses,
          PodName:             podName,
          PodNamespace:        podNamespace,
          PodIP:               podIP,
          ...
          })
  
  // envoy 的代理
  agent := envoy.NewAgent(envoyProxy, features.TerminationDrainDuration())
  
  // envoy 的监控和程序，会监听证书变化和启动 envoy 
  watcher := envoy.NewWatcher(tlsCerts, agent.Restart)
  go watcher.Run(ctx)
  
  // 监听停止信号
  go cmd.WaitSignalFunc(cancel)
  
  // envoy 主循环，阻塞等待停止信号
  return agent.Run(ctx)
  

  • 创建 envoy 对象，结构体包含 proxyConfig, role.serviceNode, loglevel 和 pilotSAN（service account name）等
  • 创建 agent 对象，包含前面创建的 envoy 结构体，一个 epochs 的 map，1个 channel：statusCh
  • 创建 watcher ，包含证书和 agent.Restart 方法并启动协程执行 watcher.Run
    • watcher.Run 首先执行 agent.Restart，启动 Envoy
    • 启动协程调用 watchCerts ，用于监控各种证书，如果证书文件发生变化，则重新生成证书签名并重启 Envoy
  • 创建 context，启动协程调用 cmd.WaitSignalFunc 以等待进程接收到 SIGINT, SIGTERM 信号，接受到信号之后通过 context 通知 agent，agent 接到通知后调用 terminate 来 kill 所有 Envoy 进程，并退出 agent 进程
  • agent.Run 主进程堵塞，监听 statusCh，这里的 status 其实就是 exitStatus，在监听到 exitStatus 后，会删除当前 epochs 中的 channel 资源

pilot-discovery

pilot-discovery 扮演服务注册中心、Istio 控制平面到 sidecar 之间的桥梁作用

• 初始化及启动
  

  //go 语言，源码摘自 pilot-discovery，pilot-discovery 初始化及启动的关键部分，省去异常处理
  
  // 创建 discoveryServer 对象并启动
  discoveryServer, err := bootstrap.NewServer(serverArgs)
  discoveryServer.Start(stop)
  
  // discoveryServer 对象的具体创建方法
  func NewServer(args *PilotArgs) (*Server, error) {
          //环境变量
          e := &model.Environment{...}
  
          s := &Server{
                  clusterID:      getClusterID(args),                                //集群id
                  environment:    e,                                                //环境变量
                  EnvoyXdsServer: envoyv2.NewDiscoveryServer(e, args.Plugins),     //Pilot 针对 Envoy v2 xds APIs 的 gRPC 实现，用于通知 envoy 配置更新
                  // ...
          }
  
          s.initKubeClient(args)
          s.initMeshConfiguration(args, fileWatcher)        
          s.initConfigController(args)                    
          s.initServiceControllers(args)
          s.initDiscoveryService(args)
          // ...
  }
  // ...
  
  // gRPC服务启动
  func (s *Server) Start(stop <-chan struct{}) error {
          go func() {
                  s.grpcServer.Serve(s.GRPCListener)
          }()
  }
  

  pilot-discovery 的初始化主要在 pilot-discovery 的 init 方法和在 discovery 命令处理流程中调用的 bootstrap.NewServer 完成，关键步骤如下：

  • 创建 Kubernetes apiserver client（initKubeClient），可以在 pilot-discovery 的 discovery 命令的 kubeconfig flag 中提供文件路径，默认为空
  • 读取 mesh 配置（initMeshConfiguration），包含MixerCheckServer、MixerReportServer、ProxyListenPort、RdsRefreshDelay、MixerAddress 等一些列配置，默认 mesh 配置文件"/etc/istio/config/mesh"
  • 初始化与配置存储中心的连接（initConfigController 方法）对 Istio 做出的各种配置，比如 route rule、virtualservice 等，需要保存在配置存储中心（config store）内
  • 配置与服务注册中心（service registry）的连接（initServiceControllers 方法）
  • 初始化 discovery 服务（initDiscoveryService），将 discovery 服务注册为 Config Controller 和 Service Controller 的 Event Handler，监听配置和服务变化消息
  • 启动 gRPC Server 并接收来自 Envoy 端的连接请求
  • 接收 sidecar 端的 xDS 请求，从 Config Controller、Service Controller 中获取配置和服务信息，生成响应消息发送给 sidecar
  • 监听来自 Config Controller 、Service Controller 的变化消息，并将配置、服务变化内容通过 xDS 接口推送到 sidecar
• 配置信息监控与处理
  

  ConfigController 是 Pilot 实现配置信息监控与处理的核心，它关联的几个关键的结构体如下：

  //go 语言，源码摘自 pilot-discovery，pilot-discovery 实现配置监听的关键部分
  
  // 用于存储 route rule、virtualservice 等流量配置信息
  type ConfigStore interface {
          Schemas() collection.Schemas
          Get(typ resource.GroupVersionKind, name, namespace string) *Config
          List(typ resource.GroupVersionKind, namespace string) ([]Config, error)
          Create(config Config) (revision string, err error)
          Update(config Config) (newRevision string, err error)
          Delete(typ resource.GroupVersionKind, name, namespace string) error
          Version() string
          GetResourceAtVersion(version string, key string) (resourceVersion string, err error)
          GetLedger() ledger.Ledger
          SetLedger(ledger.Ledger) error
  }
  
  // 扩展了 ConfigStore 存储，并提供资源处理的注册函数，使用此函数注册后，资源变更会回调 handler 处理
  type ConfigStoreCache interface {
          RegisterEventHandler(kind resource.GroupVersionKind, handler func(Config, Config, Event))
          Run(stop <-chan struct{})
          HasSynced() bool
  }
  
  
  //controller 实现了 ConfigStore 接口和 ConfigStoreCache 接口
  type controller struct {
          client *Client
          queue  queue.Instance
          kinds  map[resource.GroupVersionKind]*cacheHandler
  }
  
  type Task func() error
  
  // controller 的 queue 的类型，包装了 Task 任务
  type Instance interface {
          Push(task Task)
          Run(<-chan struct{})
  }
  
  //initServiceControllers 下的 kubernets 下的 Controller ，由 initKubeRegistry 创建
  func NewController(client kubernetes.Interface, options Options) *Controller {
          c := &Controller{
                  client:                     client,
                  queue:                      queue.NewQueue(1 * time.Second),
                  // ...
          }
  
          // ...
  
          registerHandlers(c.services, c.queue, "Services", c.onServiceEvent)
  

  ConfigController 用于处理 Istio 流控 CRD, 如 VirtualService、DestinationRule 等

  • ConfigStore 对象利用 client-go 库从 Kubernetes 获取 RouteRule、VirtualService 等 CRD 形式存在控制面信息，转换为 model 包下的 Config 对象，对外提供 Get、List、Create、Update、Delete 等 CRUD 服务
  • ConfigStoreCache 则主要扩展了：注册 Config 变更事件处理函数 RegisterEventHandler 、开始处理流程的 Run 方法

  Pilot 中，目前实现了 ConfigStoreCache 的 controller 主要有以下五种：

  • crd/controller/controller.go
  • serviceregistry/mcp/controller.go
  • kube/gateway/controller.go
  • kube/ingress/controller.go
  • memory/controller.go

  //go 语言，源码摘自 pilot-discovery，pilot-discovery 实现配置监听的关键部分，接上一段代码中的 registerHandlers
  
  func registerHandlers(informer cache.SharedIndexInformer, q queue.Instance, otype string,
      handler func(interface{}, model.Event) error) {
  
      informer.AddEventHandler(
          cache.ResourceEventHandlerFuncs{
              AddFunc: func(obj interface{}) {
                      // ...
                  q.Push(...)
                      // ...
              },
              UpdateFunc: func(old, cur interface{}) {
                      // ...
                  q.Push(...)
                      // ...
              },
              DeleteFunc: func(obj interface{}) {
                      // ...
                  q.Push(...)
                      // ...
              },
          })
  }
  
  //queue 的实现，始终等待执行 task
  func (q *queueImpl) Run(stop <-chan struct{}) {
          // ...
      for {
          if len(q.tasks) == 0 {
              return
          }
          task, q.tasks = q.tasks[0], q.tasks[1:]
          task()
      }
  }
  

  其中比较关键的是 crd controller。CRD 是 CustomResourceDefinition 的缩写 ，CRD Controller:

  • 利用 SharedIndexInformer 实现对 CRD 资源的 list/watch
  • 将 Add、Update、Delete 事件涉及到的 CRD 资源对象封装为一个 Task
  • push 到 ConfigController 的 queue 里
  • queue 队列始终处于监听状态，只要队列中有内容，就会回调 task 函数执行

CA 服务器

SDS 服务器

证书密钥控制器

• 证书轮换
  

  	如果没有自动证书轮换功能，当证书过期时，就不得不重启签发，并重启代理
  
  	证书轮换解决了这一问题，提高了服务的可用性
  

  Istio 里通过一个 轮换器 （Rotator）自动检查自签名的根证书，并在证书即将过期时进行更新，它本质上是一个协程（goroutine）在后台轮询实现的：

  • 获取当前证书，解析证书的有效期并获取下一次轮换时间
  • 启动定时器，如果发现证书到达轮换时间，从 CA 获取最新的证书密钥对
  • 更新证书

使用 Sidecar 模式的优势

       在 Kubernetes 的 Pod 中，在原有的应用容器旁边注入一个 Sidecar 容器，两个容器共享存储、网络等资源

       可以广义的将这个包含了 sidecar 容器的 Pod 理解为一台主机，两个容器共享主机资源

Init 容器

       一个 Pod 中可以指定多个 Init 容器，如果指定了多个，那么 Init 容器将会按顺序依次运行

       只有当前面的 Init 容器必须运行成功后，才可以运行下一个 Init 容器

       当所有的 Init 容器运行完成后，Kubernetes 才初始化 Pod 和运行应用容器

在所有的 Init 容器没有成功之前，Pod 将不会变成 Ready 状态，Init 容器的端口将不会在 Service 中进行聚集

正在初始化中的 Pod 处于 Pending 状态，但应该会将 Initializing 状态设置为 true

Init 容器运行完成以后就会自动终止

Init 容器解析

istio-iptables -p 15001 -z 15006 -u 1337 -m REDIRECT -i '*' -x "" -b '*' -d 15090,15020

       注意：在 Istio 1.1 版本时还是使用 isito-iptables.sh 命令行来操作 IPtables

• Init 容器启动入口
  

  Init 容器的启动入口是 istio-iptables 命令行，该命令行工具的用法如下：

  $ istio-iptables [flags]
    -p: 指定重定向所有 TCP 流量的 sidecar 端口（默认为 $ENVOY_PORT = 15001）
    -m: 指定入站连接重定向到 sidecar 的模式，“REDIRECT” 或 “TPROXY”（默认为 $ISTIO_INBOUND_INTERCEPTION_MODE)
    -b: 逗号分隔的入站端口列表，其流量将重定向到 Envoy（可选）。使用通配符 “*” 表示重定向所有端口。为空时表示禁用所有入站重定向（默认为 $ISTIO_INBOUND_PORTS）
    -d: 指定要从重定向到 sidecar 中排除的入站端口列表（可选），以逗号格式分隔。使用通配符“*” 表示重定向所有入站流量（默认为 $ISTIO_LOCAL_EXCLUDE_PORTS）
    -o：逗号分隔的出站端口列表，不包括重定向到 Envoy 的端口。
    -i: 指定重定向到 sidecar 的 IP 地址范围（可选），以逗号分隔的 CIDR 格式列表。使用通配符 “*” 表示重定向所有出站流量 空列表将禁用所有出站重定向（默认为 $ISTIO_SERVICE_CIDR）
    -x: 指定将从重定向中排除的 IP 地址范围，以逗号分隔的 CIDR 格式列表。使用通配符 “*” 表示重定向所有出站流量（默认为 $ISTIO_SERVICE_EXCLUDE_CIDR）
    -k：逗号分隔的虚拟接口列表，其入站流量（来自虚拟机的）将被视为出站流量
    -g：指定不应用重定向的用户的 GID (默认值与 -u param 相同)
    -u：指定不应用重定向的用户的 UID 通常情况下，这是代理容器的 UID（默认值是 1337，即 istio-proxy 的 UID）
    -z: 所有进入 pod/VM 的 TCP 流量应被重定向到的端口（默认 $INBOUND_CAPTURE_PORT = 15006）
  

  该容器存在的意义就是让 sidecar 代理可以拦截所有的进出 pod 的流量，15090 端口（Mixer 使用）和 15092 端口（Ingress Gateway）除外的所有入站（inbound）流量重定向到 15006 端口（sidecar），再拦截应用容器的出站（outbound）流量经过 sidecar 处理（通过 15001 端口监听）后再出站：

  • 将应用容器的所有流量都转发到 sidecar 的 15006 端口
  • 使用 istio-proxy 用户身份运行， UID 为 1337，即 sidecar 所处的用户空间，这也是 istio-proxy 容器默认使用的用户
  • 使用默认的 REDIRECT 模式来重定向流量
  • 将所有出站流量都重定向到 sidecar 代理（通过 15001 端口）
• iptables 注入解析
  

  为了查看 iptables 配置，需要登陆到 sidecar 容器中使用 root 用户来查看

  	因为 kubectl 无法使用特权模式来远程操作 docker 容器，所以需要登陆到 productpage pod 所在的主机上使用 docker 命令登陆容器中查看
  
  	如果使用 minikube 部署的 Kubernetes，可以直接登录到 minikube 的虚拟机中并切换为 root 用户。查看 iptables 配置，列出 NAT（网络地址转换）表的所有规则
  
  	在 Init 容器启动的时候选择给 istio-iptables 传递的参数中指定将入站流量重定向到 sidecar 的模式为 REDIRECT，因此在 iptables 中将只有 NAT 表的规格配置
  
  	如果选择 TPROXY 还会有 mangle 表配置
  

  仅查看与 productpage 有关的 iptables 规则如下：

  # 进入 minikube 并切换为 root 用户，minikube 默认用户为 docker
  $ minikube ssh
  $ sudo -i
  
  # 查看 productpage pod 的 istio-proxy 容器中的进程
  $ docker top `docker ps|grep "istio-proxy_productpage"|cut -d " " -f1`
  UID                 PID                 PPID                C                   STIME               TTY                 TIME                CMD
  1337                10576               10517               0                   08:09               ?                   00:00:07            /usr/local/bin/pilot-agent proxy sidecar --domain default.svc.cluster.local --configPath /etc/istio/proxy --binaryPath /usr/local/bin/envoy --serviceCluster productpage.default --drainDuration 45s --parentShutdownDuration 1m0s --discoveryAddress istiod.istio-system.svc:15012 --zipkinAddress zipkin.istio-system:9411 --proxyLogLevel=warning --proxyComponentLogLevel=misc:error --connectTimeout 10s --proxyAdminPort 15000 --concurrency 2 --controlPlaneAuthPolicy NONE --dnsRefreshRate 300s --statusPort 15020 --trust-domain=cluster.local --controlPlaneBootstrap=false
  1337                10660               10576               0                   08:09               ?                   00:00:33            /usr/local/bin/envoy -c /etc/istio/proxy/envoy-rev0.json --restart-epoch 0 --drain-time-s 45 --parent-shutdown-time-s 60 --service-cluster productpage.default --service-node sidecar~172.17.0.16~productpage-v1-7f44c4d57c-ksf9b.default~default.svc.cluster.local --max-obj-name-len 189 --local-address-ip-version v4 --log-format [Envoy (Epoch 0)] [%Y-%m-%d %T.%e][%t][%l][%n] %v -l warning --component-log-level misc:error --concurrency 2
  
  # 进入 nsenter 进入 sidecar 容器的命名空间（以上任何一个都可以）
  $ nsenter -n --target 10660
  

  在该进程的命名空间下查看其 iptables 规则链：

  # 查看 NAT 表中规则配置的详细信息。
  $ iptables -t nat -L -v
  # PREROUTING 链：用于目标地址转换（DNAT），将所有入站 TCP 流量跳转到 ISTIO_INBOUND 链上。
  Chain PREROUTING (policy ACCEPT 2701 packets, 162K bytes)
   pkts bytes target     prot opt in     out     source               destination
   2701  162K ISTIO_INBOUND  tcp  --  any    any     anywhere             anywhere
  
  # INPUT 链：处理输入数据包，非 TCP 流量将继续 OUTPUT 链。
  Chain INPUT (policy ACCEPT 2701 packets, 162K bytes)
   pkts bytes target     prot opt in     out     source               destination
  
  # OUTPUT 链：将所有出站数据包跳转到 ISTIO_OUTPUT 链上。
  Chain OUTPUT (policy ACCEPT 79 packets, 6761 bytes)
   pkts bytes target     prot opt in     out     source               destination
     15   900 ISTIO_OUTPUT  tcp  --  any    any     anywhere             anywhere
  
  # POSTROUTING 链：所有数据包流出网卡时都要先进入POSTROUTING 链，内核根据数据包目的地判断是否需要转发出去，我们看到此处未做任何处理。
  Chain POSTROUTING (policy ACCEPT 79 packets, 6761 bytes)
   pkts bytes target     prot opt in     out     source               destination
  
  # ISTIO_INBOUND 链：将所有入站流量重定向到 ISTIO_IN_REDIRECT 链上，目的地为 15090（mixer 使用）和 15020（Ingress gateway 使用，用于 Pilot 健康检查）端口的流量除外，发送到以上两个端口的流量将返回 iptables 规则链的调用点，即 PREROUTING 链的后继 POSTROUTING。
  Chain ISTIO_INBOUND (1 references)
   pkts bytes target     prot opt in     out     source               destination
      0     0 RETURN     tcp  --  any    any     anywhere             anywhere             tcp dpt:ssh
      2   120 RETURN     tcp  --  any    any     anywhere             anywhere             tcp dpt:15090
   2699  162K RETURN     tcp  --  any    any     anywhere             anywhere             tcp dpt:15020
      0     0 ISTIO_IN_REDIRECT  tcp  --  any    any     anywhere             anywhere
  
  # ISTIO_IN_REDIRECT 链：将所有的入站流量跳转到本地的 15006 端口，至此成功的拦截了流量到 sidecar 中。
  Chain ISTIO_IN_REDIRECT (3 references)
   pkts bytes target     prot opt in     out     source               destination
      0     0 REDIRECT   tcp  --  any    any     anywhere             anywhere             redir ports 15006
  
  # ISTIO_OUTPUT 链：选择需要重定向到 Envoy（即本地） 的出站流量，所有非 localhost 的流量全部转发到 ISTIO_REDIRECT。为了避免流量在该 Pod 中无限循环，所有到 istio-proxy 用户空间的流量都返回到它的调用点中的下一条规则，本例中即 OUTPUT 链，因为跳出 ISTIO_OUTPUT 规则之后就进入下一条链 POSTROUTING。如果目的地非 localhost 就跳转到 ISTIO_REDIRECT；如果流量是来自 istio-proxy 用户空间的，那么就跳出该链，返回它的调用链继续执行下一条规则（OUTPUT 的下一条规则，无需对流量进行处理）；所有的非 istio-proxy 用户空间的目的地是 localhost 的流量就跳转到 ISTIO_REDIRECT。
  Chain ISTIO_OUTPUT (1 references)
   pkts bytes target     prot opt in     out     source               destination
      0     0 RETURN     all  --  any    lo      127.0.0.6            anywhere
      0     0 ISTIO_IN_REDIRECT  all  --  any    lo      anywhere            !localhost            owner UID match 1337
      0     0 RETURN     all  --  any    lo      anywhere             anywhere             ! owner UID match 1337
     15   900 RETURN     all  --  any    any     anywhere             anywhere             owner UID match 1337
      0     0 ISTIO_IN_REDIRECT  all  --  any    lo      anywhere            !localhost            owner GID match 1337
      0     0 RETURN     all  --  any    lo      anywhere             anywhere             ! owner GID match 1337
      0     0 RETURN     all  --  any    any     anywhere             anywhere             owner GID match 1337
      0     0 RETURN     all  --  any    any     anywhere             localhost
      0     0 ISTIO_REDIRECT  all  --  any    any     anywhere             anywhere
  
  # ISTIO_REDIRECT 链：将所有流量重定向到 Sidecar（即本地） 的 15001 端口。
  Chain ISTIO_REDIRECT (1 references)
   pkts bytes target     prot opt in     out     source               destination
      0     0 REDIRECT   tcp  --  any    any     anywhere             anywhere             redir ports 15001
  

  下图展示的是 productpage 服务请求访问 http://reviews.default.svc.cluster.local:9080 当流量进入 reviews 服务内部时，reviews 服务内部的 sidecar proxy 是如何做流量拦截和路由转发的：

  

  第一步开始时，productpage Pod 中的 sidecar 已经通过 EDS 选择出了要请求的 reviews 服务的一个 Pod，知晓了其 IP 地址，发送 TCP 连接请求。

  reviews 服务有三个版本，每个版本有一个实例，三个版本中的 sidecar 工作步骤类似
  

Envoy 初始化配置文件

       在 Istio 中，Envoy 的大部分配置都来自于控制平面通过 xDS 接口下发的动态配置，包括网格中服务相关的 service cluster, listener, route 规则等

       但 Envoy 是如何知道 xDS server 的地址呢？

$ kubectl exec productpage-v1-6d8bc58dd7-ts8kw -c istio-proxy cat /etc/istio/proxy/envoy-rev0.json > envoy-rev0.json

{
    "node": {...},
    "stats_config": {...},
    "admin": {...},
    "dynamic_resources": {...},
    "static_resources": {...},
    "tracing": {...}
}

Envoy 完整配置

Envoy 中实际生效的配置是由初始化配置文件中的静态配置和从 Pilot 获取的动态配置一起组成的，因此只对 envoy-rev0.json 进行分析并不能看到网络中流量管理的全貌

那么有没有办法可以看到 Envoy 中实际生效的完整配置呢?

$ kubectl exec -it productpage-v1-6d8bc58dd7-ts8kw -c istio-proxy curl http://127.0.0.1:15000/config_dump > config_dump

{
 "configs": [
  {
   "@type": "type.googleapis.com/envoy.admin.v3.BootstrapConfigDump",
   "bootstrap": {},
   "last_updated": "2020-03-11T08:14:03.630Z"
   },
  {
   "@type": "type.googleapis.com/envoy.admin.v3.ClustersConfigDump",
   "version_info": "2020-03-11T08:14:06Z/23",
   "static_clusters": [...],
   "dynamic_active_clusters": [...]
  },
  {
    "@type": "type.googleapis.com/envoy.admin.v3.ListenersConfigDump",
    "version_info": "2020-03-11T08:13:39Z/22",
    "static_listeners": [...],
    "dynamic_listeners": [...]
  },
  {
   "@type": "type.googleapis.com/envoy.admin.v3.RoutesConfigDump",
   "static_route_configs": [...],
   "dynamic_route_configs": [...],
  },
  {
   "@type": "type.googleapis.com/envoy.admin.v3.SecretsConfigDump",
   "dynamic_active_secrets": [...]
   }
 ]
}

• Bootstrap
  

  从名字可以看出这是 Envoy 的初始化配置，打开该节点，可以看到其中的内容和 envoy-rev0.json 是一致的，这里不再细述

  {
      "@type": "type.googleapis.com/envoy.admin.v3.BootstrapConfigDump",
      "bootstrap": {
          "node": {...},
          "stats_config": {...},
          "admin": {...},
          "dynamic_resources": {...},
          "static_resources": {...},
          "tracing": {...}
      },
      "last_updated": "2020-03-11T08:14:03.630Z"
  },
  

        需要注意的是在 bootstrap 部分配置的一些内容也会被用于其他部分，例如 clusters 部分就包含了 bootstrap 中定义的一些静态 cluster 资源 
  

• Clusters
  

  这部分配置定义了 Envoy 中所有的 cluster，即服务集群，cluster 中包含一个到多个 endpoint，每个 endpoint 都可以提供服务，Envoy 根据负载均衡算法将请求发送到这些 endpoint 中。从配置文件结构中可以看到，在 productpage 的 clusters 配置中包含 static_clusters 和 dynamic_active_clusters 两部分，其中：

  • static_clusters 是来自于 envoy-rev0.json 的初始化配置中的 prometheus_stats、xDS server、zipkin server 信息
  • dynamic_active_clusters 是 Envoy 通过 xDS 接口从 Istio 控制平面获取的服务信息

  其中 dynamic cluster 又分为以下几类

  • Outbound Cluster
    

    这部分的 cluster 占了绝大多数，该类 cluster 对应于 Envoy 所在节点的外部服务

    	 以 reviews 为例，对于 productpage 来说，reviews 是一个外部服务，因此其 cluster 名称中包含 outbound 字样
    

    从 reviews 服务对应的 cluster 配置中可以看到，其类型为 EDS ，即表示该 cluster 的 endpoint 来自于动态发现，动态发现中 eds_config 则指向了ads，最终指向 static resource 中配置的 xds-grpc cluster，即 Pilot 的地址

    {
        "version_info": "2020-03-11T08:13:39Z/22",
        "cluster": {
            "@type": "type.googleapis.com/envoy.api.v2.Cluster",
            "name": "outbound|9080||reviews.default.svc.cluster.local",
            "type": "EDS",
            "eds_cluster_config": {
                "eds_config": {
                    "ads": {}
                },
                "service_name": "outbound|9080||reviews.default.svc.cluster.local"
            },
            "connect_timeout": "1s",
            "circuit_breakers": {},
            "filters": [],
            "transport_socket_matches": []
        },
        "last_updated": "2020-03-11T08:14:04.664Z"
    }
    

    可以通过 Pilot 的调试接口获取该 cluster 的 endpoint：

    $ curl http://10.97.222.108:15014/debug/edsz > pilot_eds_dump
    

    从导出的文件内容可以看到，reviews cluster 配置了3个 endpoint 地址，是 reviews 的 pod ip：

    {
      "clusterName": "outbound|9080||reviews.default.svc.cluster.local",
      "endpoints": [
        {
          "lbEndpoints": [
            {
              "endpoint": {
                "address": {
                  "socketAddress": {
                    "address": "10.40.0.15",
                    "portValue": 9080
                  }
                }
              },
              "metadata": {},
              "loadBalancingWeight": 1
            },
            {
              "endpoint": {
                "address": {
                  "socketAddress": {
                    "address": "10.40.0.16",
                    "portValue": 9080
                  }
                }
              },
              "metadata": {},
              "loadBalancingWeight": 1
            },
            {
              "endpoint": {
                "address": {
                  "socketAddress": {
                    "address": "10.40.0.17",
                    "portValue": 9080
                  }
                }
              },
              "metadata": {},
              "loadBalancingWeight": 1
            }
          ],
          "loadBalancingWeight": 3
        }
      ]
    }
    

  • Inbound Cluster
    

    对于 Envoy 来说，inbound cluster 对应于入向请求的 upstream 集群， 即 Envoy 自身所在节点的服务

    	 对于 productpage Pod 上的 Envoy，其对应的 Inbound cluster 只有一个，即 productpage
    

    该 cluster 对应的 host 为127.0.0.1，即回环地址上 productpage 的监听端口

    {
        "version_info": "2020-03-11T08:13:39Z/22",
        "cluster": {
            "@type": "type.googleapis.com/envoy.api.v2.Cluster",
            "name": "inbound|9080|http|productpage.default.svc.cluster.local",
            "type": "STATIC",
            "connect_timeout": "1s",
            "circuit_breakers": {
                "thresholds": []
            },
            "load_assignment": {
                "cluster_name": "inbound|9080|http|productpage.default.svc.cluster.local",
                "endpoints": [
                    {
                        "lb_endpoints": [
                            {
                                "endpoint": {
                                    "address": {
                                        "socket_address": {
                                            "address": "127.0.0.1",
                                            "port_value": 9080
                                        }
                                    }
                                }
                            }
                        ]
                    }
                ]
            }
        },
        "last_updated": "2020-03-11T08:14:04.684Z"
    }
    

    由于 iptable 规则中排除了127.0.0.1，入站请求通过该 Inbound cluster 处理后将跳过 Envoy，直接发送给 productpage 进程处理

  • BlackHoleCluster
    

    这是一个特殊的 cluster ，其中并没有配置后端处理请求的 host。如其名字所表明的一样，请求进入该 cluster 后如同进入了一个黑洞，将被丢弃掉，而不是发向一个 upstream host

    {
        "version_info": "2020-03-11T08:13:39Z/22",
        "cluster": {
            "@type": "type.googleapis.com/envoy.api.v2.Cluster",
            "name": "BlackHoleCluster",
            "type": "STATIC",
            "connect_timeout": "1s",
            "filters": []
        },
        "last_updated": "2020-03-11T08:14:04.665Z"
    }
    

  • PassthroughCluster
    

    该 cluster 的 type 被设置为 ORIGINAL_DST 类型，表明任何发向该 cluster 的请求都会被直接发送到其请求中的原始目地的，Envoy 不会对请求进行重新路由：

    {
        "version_info": "2020-03-11T08:13:39Z/22",
        "cluster": {
            "@type": "type.googleapis.com/envoy.api.v2.Cluster",
            "name": "PassthroughCluster",
            "type": "ORIGINAL_DST",
            "connect_timeout": "1s",
            "lb_policy": "CLUSTER_PROVIDED",
            "circuit_breakers": {
                "thresholds": []
            },
            "filters": []
        },
        "last_updated": "2020-03-11T08:14:04.666Z"
    }
    

• Listeners
  

  Envoy 采用 listener 来接收并处理 downstream 发过来的请求，listener 采用了插件式的架构，可以通过配置不同的 filter 在 listener 中插入不同的处理逻辑。Listener 可以绑定到 IP Socket 或者 Unix Domain Socket 上，以接收来自客户端的请求；也可以不绑定，而是接收从其他 listener 转发来的数据

  Istio 利用了 Envoy listener 的这一特点，通过 VirtualOutboundListener 在一个端口接收所有出向请求，然后再按照请求的端口分别转发给不同的 listener 分别处理
  

  • VirtualOutbound Listener
    

    Istio 在 Envoy 中配置了一个在 15001 端口监听的虚拟入口监听器
    
    Iptable 规则将 Envoy 所在 pod 的对外请求拦截后发向本地的 15001 端口，该监听器接收后并不进行业务处理，而是根据请求的目的端口分发给其他监听器处理
    
    这就是该监听器取名为 "virtual”（虚拟）监听器的原因，但Envoy 是如何做到按请求的目的端口进行分发的呢？
    

    从下面 VirtualOutbound listener 的配置中可以看到 use_original_dest 属性被设置为 true, 这表示该监听器在接收到来自 downstream 的请求后，会将请求转交给匹配该请求原目的地址的 listener（即名字格式为 0.0.0.0_ 请求目的端口 的 listener）进行处理

    如果在 Enovy 的配置中找不到匹配请求目的端口的 listener，则将会根据 Istio 的 outboundTrafficPolicy 全局配置选项进行处理。存在两种情况：

    • 如果 outboundTrafficPolicy 设置为 ALLOW_ANY：这表明网格允许发向任何外部服务的请求，无论该服务是否在 Pilot 的服务注册表中
      • 在该策略下，Pilot 将会在下发给 Envoy 的 VirtualOutbound listener 加入一个 upstream cluster 为 PassthroughCluster 的 TCP proxy filter
      • 找不到匹配端口 listener 的请求会被该 TCP proxy filter 处理，请求将会被发送到其 IP 头中的原始目的地地址
    • 如果 outboundTrafficPolicy 设置为 REGISTRY_ONLY：只允许发向 Pilot 服务注册表中存在的服务的对外请求
      • 在该策略下，Pilot 将会在下发给 Enovy 的 VirtualOutbound listener 加入一个 upstream cluster 为 BlackHoleCluster 的 TCP proxy filter
      • 找不到匹配端口 listener 的请求会被该 TCP proxy filter 处理，由于 BlackHoleCluster 中没有配置 upstteam host，请求实际上会被丢弃。

    下面是 bookinfo 例子中 productpage 服务中 Enovy Proxy 的 Virutal Outbound Listener 配置：

    {
        "name": "virtualOutbound",
        "active_state": {
            "version_info": "2020-03-11T08:13:39Z/22",
            "listener": {
                "@type": "type.googleapis.com/envoy.api.v2.Listener",
                "name": "virtualOutbound",
                "address": {
                    "socket_address": {
                        "address": "0.0.0.0",
                        "port_value": 15001
                    }
                },
                "filter_chains": [
                    {
                        "filter_chain_match": {
                            "prefix_ranges": [
                                {
                                    "address_prefix": "10.40.0.18",
                                    "prefix_len": 32
                                }
                            ]
                        },
                        "filters": [
                            {
                                "name": "envoy.tcp_proxy",
                                "typed_config": {
                                    "@type": "type.googleapis.com/envoy.config.filter.network.tcp_proxy.v2.TcpProxy",
                                    "stat_prefix": "BlackHoleCluster",
                                    "cluster": "BlackHoleCluster"
                                }
                            }
                        ]
                    },
                    {
                        "filters": [
                            {
                                "name": "envoy.tcp_proxy",
                                "typed_config": {
                                    "@type": "type.googleapis.com/envoy.config.filter.network.tcp_proxy.v2.TcpProxy",
                                    "stat_prefix": "PassthroughCluster",
                                    "cluster": "PassthroughCluster",
                                    "access_log": []
                                }
                            ],
                            "use_original_dst": true,
                            "traffic_direction": "OUTBOUND"
                        },
                        "last_updated": "2020-03-11T08:14:04.929Z"
                    }
                },
            }
        }
    }
    

    由于 outboundTrafficPolicy 的默认配置为 ALLOW_ANY，因此 listener 的 filterchain 中第二个 filter chain 中是一个 upstream cluster 为 PassthroughCluster 的 TCP proxy filter
    
    注意该 filter 没有 filter_chain_match 匹配条件，因此如果进入该 listener 的请求在配置中找不到匹配其目的端口的 listener，就会缺省进入该 filter 进行处理
    
    filterchain 中的第一个 filter chain 中是一个 upstream cluster 为 BlackHoleCluster 的 TCP proxy filter，该 filter 设置了 filter_chain_match 匹配条件，只有发向 10.40.0.18 这个 IP 的出向请求才会进入该 filter 处理
    
    10.40.0.18 是 productpage 服务自身的IP地址，该 filter 的目的是为了防止服务向自己发送请求可能导致的死循环
    

  • Outbound Listener
    

    Envoy 为网格中的外部服务按端口创建多个 Outbound listener，以用于处理出向请求

    bookinfo 示例程序中使用了9080作为微服务的业务端口，因此这里主要分析9080这个业务端口的 listener
    

    和其他所有 Outbound listener 一样，该 listener 配置了"bind_to_port”: false 属性，因此该 listener 没有被绑定到 tcp 端口上，其接收到的所有请求都转发自15001端口的 Virtual listener。该listener 的名称为0.0.0.0_9080,因此会匹配发向任意 IP 的9080端口的请求

    bookinfo 程序中的 productpage,revirews,ratings,details 四个服务都使用了9080端口，那么 Envoy 如何区别处理这四个服务呢？
    

    1. iptables 拦截到 productpage 向外发出的 HTTP 请求，并转发到同一 pod 中的 Envoy sidecar 监听的 15001 virtualOutbound listener 进行处理
    2. Envoy 根据目的端口匹配到 0.0.0.0_9080 这个 Outbound listener，并转交给该 listener
    3. 当 0.0.0.0_9080 接收到出向请求后，并不会直接发送到一个 downstream cluster，而是配置了一个路由规则 9080，在该路由规则中会根据不同的请求目的地对请求进行处理

    {
        "name": "0.0.0.0_9080",
        "active_state": {
            "version_info": "2020-03-11T08:13:39Z/22",
            "listener": {
                "@type": "type.googleapis.com/envoy.api.v2.Listener",
                "name": "0.0.0.0_9080",
                "address": {
                    "socket_address": {
                        "address": "0.0.0.0",
                        "port_value": 9080
                    }
                },
                "filter_chains": [
                    {
                        "filters": [
                            {
                                "name": "envoy.http_connection_manager",
                                "typed_config": {
                                    "@type": "type.googleapis.com/envoy.config.filter.network.http_connection_manager.v2.HttpConnectionManager",
                                    "stat_prefix": "outbound_0.0.0.0_9080",
                                    "rds": {
                                        "config_source": {
                                            "ads": {}
                                        },
                                        "route_config_name": "9080"
                                    },
                                    ...
                                }
                            }
                        ]
                    }
                ],
                "deprecated_v1": {
                    "bind_to_port": false
                },
                "traffic_direction": "OUTBOUND"
            },
            "last_updated": "2020-03-11T08:14:04.927Z"
        }
    }
    

  • VirtualInbound Listener
    

    	 在较早的版本中，Istio 采用同一个 VirtualListener 在端口 15001 上同时处理入向和出向的请求
    
    	 该方案存在一些潜在的问题，例如可能会导致出现死循环
    

    在 1.4 版本之后，Istio 为 Envoy 单独创建了 一个 VirtualInboundListener，在 15006 端口监听入向请求，原来的 15001 端口只用于处理出向请求。另外一个变化是当 VirtualInboundListener 接收到请求后，将直接在 VirtualInboundListener 采用一系列 filterChain 对入向请求进行处理，而不是像 VirtualOutboundListener 一样分发给其它独立的 listener 进行处理　

    	 这样修改后，Envoy 配置中入向和出向的请求处理流程被完全拆分开，请求处理流程更为清晰，可以避免由于配置导致的一些潜在错误
    

    下面是 bookinfo 例子中 reviews 服务中 Envoy Proxy 的 VirtualInbound listener 配置。 在配置中采用注释标注了各个不同作用的 filter chain

    {
        "name": "virtualInbound",
        "active_state": {
            "version_info": "2020-03-11T08:13:14Z/21",
            "listener": {
                "@type": "type.googleapis.com/envoy.api.v2.Listener",
                "name": "virtualInbound",
                "address": {
                    "socket_address": {
                        "address": "0.0.0.0",
                        "port_value": 15006
                    }
                },
                "filter_chains": [
                    {...} //passthrough，启用tls
                    {...} //passthrough,未启用tls
                    {...} //处理发向15020端口的监控检查
                    {...} //9080业务端口，启用tls
                    {...} //9080业务端口，未启用tls
                ],
                "listener_filters": [
                    {
                        "name": "envoy.listener.original_dst"
                    },
                    {
                        "name": "envoy.listener.tls_inspector"
                    }
                ],
                "listener_filters_timeout": "1s",
                "traffic_direction": "INBOUND",
                "continue_on_listener_filters_timeout": true
            },
            "last_updated": "2020-03-11T08:13:39.372Z"
        }
    }
    

    	 如该配置所示，reviews 服务中一共配置了5个 filter chain
    
    	 其中最后两个 filter chain 用于业务处理，一个用于处理 HTTPS 请求；一个用于处理 plain HTTP 请求
    

    除了 TLS 相关的配置以外，这两个业务处理的 filter chain 的处理逻辑是相同的。 打开 HTTPS filter chain，以查看其内部的内容：

    {
        "filter_chain_match": {
            "prefix_ranges": [
                {
                    "address_prefix": "10.40.0.15",
                    "prefix_len": 32
                }
            ],
            "destination_port": 9080,
            "application_protocols": [
                "istio-peer-exchange",
                "istio",
                "istio-http/1.0",
                "istio-http/1.1",
                "istio-h2"
            ]
        },
        "filters": [
            {
                "name": "envoy.filters.network.metadata_exchange",
                "config": {
                    "protocol": "istio-peer-exchange"
                }
            },
            {
                "name": "envoy.http_connection_manager",
                "typed_config": {
                    "@type": "type.googleapis.com/envoy.config.filter.network.http_connection_manager.v2.HttpConnectionManager",
                    "stat_prefix": "inbound_10.40.0.15_9080",
                    "route_config": {
                        "name": "inbound|9080|http|reviews.default.svc.cluster.local",
                        "virtual_hosts": [
                            {
                                "name": "inbound|http|9080",
                                "domains": [
                                    "*"
                                ],
                                "routes": [
                                    {
                                        "match": {
                                            "prefix": "/"
                                        },
                                        "route": {
                                            "cluster": "inbound|9080|http|reviews.default.svc.cluster.local",
                                            "timeout": "0s",
                                            "max_grpc_timeout": "0s"
                                        },
                                        "decorator": {
                                            "operation": "reviews.default.svc.cluster.local:9080/*"
                                        },
                                        "name": "default"
                                    }
                                ]
                            }
                        ],
                        "validate_clusters": false
                    },
                    "http_filters": [
                        {
                            "name": "envoy.filters.http.wasm",
                            ......
                        },
                        {
                            "name": "istio_authn",
                            ......
                        },
                        {
                            "name": "envoy.cors"
                        },
                        {
                            "name": "envoy.fault"
                        },
                        {
                            "name": "envoy.filters.http.wasm",
                            ......
                                {
                                    "name": "envoy.router"
                                }
                        ],
                        "tracing": {
                            ......
                        },
                        "server_name": "istio-envoy",
                        ......
                    }
                }
            ],
        },
        "transport_socket": {
            "name": "envoy.transport_sockets.tls",
            "typed_config": {
                "@type": "type.googleapis.com/envoy.api.v2.auth.DownstreamTlsContext",
                "common_tls_context": {
                    "alpn_protocols": [
                        "istio-peer-exchange",
                        "h2",
                        "http/1.1"
                    ],
                    "tls_certificate_sds_secret_configs": [
                        {
                            "name": "default",
                            "sds_config": {
                                "api_config_source": {
                                    "api_type": "GRPC",
                                    "grpc_services": [
                                        {
                                            "envoy_grpc": {
                                                "cluster_name": "sds-grpc"
                                            }
                                        }
                                    ]
                                }
                            }
                        }
                    ],
                    "combined_validation_context": {
                        "default_validation_context": {},
                        "validation_context_sds_secret_config": {
                            "name": "ROOTCA",
                            "sds_config": {
                                "api_config_source": {
                                    "api_type": "GRPC",
                                    "grpc_services": [
                                        {
                                            "envoy_grpc": {
                                                "cluster_name": "sds-grpc"
                                            }
                                        }
                                    ]
                                }
                            }
                        }
                    }
                },
                "require_client_certificate": true
            }
        }
    }
    

    • 该 filterchain 配置了一个 http_connection_manager filter
      • http_connection_manager 中又配置了 wasm、istio_authn、envoy.router 等 http filter

    Istio 中提供的一些基础能力，例如安全认证、指标收集、请求限流等，就是通过这些 filter 实现的
    

    • 请求经过这些 HTTP filter 处理后，最终被转发给 inbound|9080|http|reviews.default.svc.cluster.local 这个 Inbound cluster
      • 该 Inbound cluster 中配置的 Upstream 为 127.0.0.1:9080，因此该请求将发送到和 sidecar 同一个 pod 上的 reviews 服务的 9080 端口上进行业务处理
    • 在 transport_socket 部分配置的是 TLS 双向认证所需的证书信息
      • 从配置中可以得知，Envoy 将通过 SDS （Secret Discovery Service） 获取自身的服务器证书和验证客户端证书所需的根证书
    • 如果一个入向访问的目的端口不能匹配到业务服务的 filterchain，则会进入到 passthrough 的 filter chain 进行处理
      • 该 filter chain 对应的 cluster 为 InboundPassthroughClusterIpv4，结合 iptables 规则， 该 cluster 将会把请求转发到其本地的原始目的端口处理
• Routers
  

  这部分配置是 Envoy 的 HTTP 路由规则

  	在前面 listener 的分析中，看到 Outbound listener 是以端口为最小粒度来进行处理的
  
  	而不同的服务可能采用了相同的端口，因此需要通过 Route 来进一步对发向同一目的端口的不同服务的请求进行区分和处理
  

  Istio 在下发给 sidecar 的缺省路由规则中为每个端口设置了一个路由规则，然后再根据 host 来对请求进行路由分发

  {
      "version_info": "2020-03-11T08:13:39Z/22",
      "route_config": {
          "@type": "type.googleapis.com/envoy.api.v2.RouteConfiguration",
          "name": "9080",
          "virtual_hosts": [
              {
                  "name": "allow_any",
                  "domains": [
                      "*"
                  ],
                  "routes": [
                      {
                          "match": {
                              "prefix": "/"
                          },
                          "route": {
                              "cluster": "PassthroughCluster",
                              "timeout": "0s"
                          }
                      }
                  ]
              },
              {
                  "name": "details.default.svc.cluster.local:9080",
                  "domains": [
                      "details.default.svc.cluster.local",
                      "details.default.svc.cluster.local:9080",
                      "details",
                      "details:9080",
                      "details.default.svc.cluster",
                      "details.default.svc.cluster:9080",
                      "details.default.svc",
                      "details.default.svc:9080",
                      "details.default",
                      "details.default:9080",
                      "10.96.60.140",
                      "10.96.60.140:9080"
                  ],
                  "routes": [
                      {
                          "match": {
                              "prefix": "/"
                          },
                          "route": {
                              "cluster": "outbound|9080||details.default.svc.cluster.local",
                              "timeout": "0s",
                              "retry_policy": {
                                  "retry_on": "connect-failure,refused-stream,unavailable,cancelled,resource-exhausted,retriable-status-codes",
                                  "num_retries": 2,
                                  "retry_host_predicate": [
                                      {
                                          "name": "envoy.retry_host_predicates.previous_hosts"
                                      }
                                  ],
                                  "host_selection_retry_max_attempts": "5",
                                  "retriable_status_codes": [
                                      503
                                  ]
                              },
                              "max_grpc_timeout": "0s"
                          },
                          "decorator": {
                              "operation": "details.default.svc.cluster.local:9080/*"
                          },
                          "name": "default"
                      }
                  ]
              },
              {
                  "name": "productpage.default.svc.cluster.local:9080",
                  "domains": [
                      "productpage.default.svc.cluster.local",
                      ......
                  ],
                  "routes": [
                      {
                          "match": {
                              "prefix": "/"
                          },
                          "route": {
                              "cluster": "outbound|9080||productpage.default.svc.cluster.local",
                              ......
                          ]
                      },
                      {
                          "name": "ratings.default.svc.cluster.local:9080",
                          "domains": [
                              "ratings.default.svc.cluster.local",
                              ......
                          ],
                          "routes": [
                              {
                                  "match": {
                                      "prefix": "/"
                                  },
                                  "route": {
                                      "cluster": "outbound|9080||ratings.default.svc.cluster.local",
                                      ......
                                  ]
                              },
                              {
                                  "name": "reviews.default.svc.cluster.local:9080",
                                  "domains": [
                                      "reviews.default.svc.cluster.local",
                                      ......
                                  ],
                                  "routes": [
                                      {
                                          "match": {
                                              "prefix": "/"
                                          },
                                          "route": {
                                              "cluster": "outbound|9080||reviews.default.svc.cluster.local",
                                              ......
                                          },
  

  上面是 proudctpage 服务中 9080 的路由配置，从文件中可以看到对应了5个 virtual host，分别是 details、productpage、ratings、reviews 和 allow_any

  • 前三个 virtual host 分别对应到不同服务的 outbound cluster
  • 最后一个对应到 PassthroughCluster，即当入向的请求没有找到对应的服务时，也会让其直接通过

线程模型

     此外，Main 线程也负责整个进程的管理。如处理操作系统信号、Envoy 热重启等

       注意，操作系统会保证一个事件最终只会被一个 Worker 处理

       在绝大多数时候，Worker 线程都只在不断的处理下游的请求和上游的响应，极少数情况下，Main 线程会将配置更新以事件的形式添加到 Worker的事件循环中来

       此外，为了尽可能的减少线程间由于数据共享而引入的争用以及锁操作，Envoy 设计了一套非常巧妙的 Thread Local Store 机制（简称 TLS）

扩展能力

       目前社区已经提供了与 HTTP、Dubbo、Mongo、Kafka、Thrift 等协议对应的多种 L4 筛选器

       而通过扩展 L4 筛选器，也可以轻松的在不侵入 Envoy 主干的前提下，扩展支持新的协议

       协议解析并不是 L4 筛选器的必备功能，同样存在一些非协议解析类型的 L4 筛选器，如工作在 L4 的限流、鉴权等筛选器

       实际上，在 L4 筛选器和 L7 筛选器之间，应该有一层专门的编解码器，不过在常见的实现当中，编解码器都被集成到对应协议的 L4 筛选器中

       一般情况下，只有需要扩展 Envoy 以支持额外的协议之时，才需要扩展开发 L4 筛选器

实际上，路由组件也往往被实现为一个特殊的 L7 筛选器，当然，整个互联网是搭建在 HTTP 协议之上的，所以在 Envoy 中处处可见对 HTTP 协议的特化

在 Envoy 中，L7 筛选器几乎可以等价于 HTTP 筛选器，因为如 Kafka、Redis 等其他协议的 L4 筛选器目前还没有提供良好的 L7 支持

L7 筛选器是大部分开发者最常用也是最需要关注的类型。通过扩展 L7 筛选器，可以扩展支持各种特定的流量控制能力，而且社区本身也提供了大量的可靠、高性能的 L7 筛选器供用户直接使用