Envoy基础

envoy 介绍

什么是envoy

  • Envoy 是一个 L7 代理和通信总线,专为大型现代面向服务的架构而设计。该项目的诞生源于以下理念:
    • 网络应该对应用程序透明。
    • 当网络和应用程序出现问题时,应该很容易确定问题的来源。
  • 用C++编写,高度并行,无阻塞。

envoy高级功能

  • Out of process architecture: 进程外的架构 
    • Envoy 适用于任何应用程序语言。单个 Envoy 部署可以在 Java、C++、Go、PHP、Python 等之间形成网格。面向服务的架构使用多种应用程序框架和语言变得越来越普遍。Envoy 透明地弥合了差距。
    • Envoy 可以透明地跨整个基础设施快速部署和升级。
  •  L3/L4 filter architecture:L3/L4 过滤器  TCP proxyUDP proxyHTTP proxyTLS client certificate authenticationRedisMongoDBPostgres, etc.。
  •  HTTP L7 filter architecture:HTTP L7层过滤器 HTTP、HTTPS
  •  First class HTTP/2 support :支持HTTP/2协议
  •  HTTP/3 support (currently in alpha) :支持HTTP/3
  •  HTTP L7 routing :HTTP L7 路由
  •  gRPC support : grpc支持
  •  Service discovery and dynamic configuration : 服务发现和动态配置
  •  Health checking : 健康状态检查
  •  Advanced load balancing :  高级路由
  •  Front/edge proxy support :前端/边缘 代理支持
  •  Best in class observability :可观测性
  •  zone aware, priority/locality load balancing :区域感知路由,基于优先级的路由
  •  circuit breaking :中断
  •  outlier detection :异常探测
  •  retries, retry policies :重试,重试策略
  •  timeout (including budgets) :超时
  •  traffic shadowing :流量镜像
  •  rate limiting:限速
  •  access logging, statistics collection :访问日志
  •  request racing :请求竞速
  •  Request hedging :
  •  Retry Budgets :重试预算
  •  Load balancing priorities :
  •  Locality weighted load balancing :
  •  Zone are routing 
  •  Degraded endpoints (fallback) 
  •  Aggregated clusters 

envoy工作逻辑

envoy有两种工作位置:

  • Front proxy:独立运行
  • sidecar proxy:运行在work load周边

envoy数据路径

envoy接收请求并向后代理的过程;

envoy特性

  • 性能、可扩展性及动态可配置性
    • 性能:除了大量功能外,envoy还提供极高的吞吐量和低尾差异延迟,同时消耗相对较少的CPU和RAM;
    • 可扩展性:envoy在L4和L7上提供了丰富的可插拔过滤器功能,允许用户轻松添加新功能;
    • API可配置性:envoy提供了一组可由控制平面服务实现的管理API,也成为xDS API;
      • 若控制平面实现了这所有的API,则可以使用通用引导配置在整个基础架构中允许envoy;
      • 所有进一步的配置更改都可通过管理服务器无缝地进行动态传递,使得envoy永远不需要从新启动,这使得envoy称为一个通用数据平面,当与足够复杂的控制平面相结合时,可打打降低整体操作复杂性;
  • envoy xDS API存在v1、v2、v3三个版本
    • v1  API仅使用json/REST,本质上是轮询;
    • v2 API是v1的演进,它是v1功能的超集,新的API模式使用proto3指定,并同时以grpc和REST+json/YAML端点实现;
    • v3 API当前支持的版本,支持start_tls、拒绝传入的tcp连接、4096位的tls秘钥、skywalking和wasm等;
  • envoy已成为现代服务网格和边缘网关的通用数据平面API,Istio、Ambassador和Gloo等项目均是为此数据平面代理提供的控制平面;

envoy组件

envoy常用术语

  •  主机(Host):一个具有网络通信能力的端点,例如服务器、移动智能设备等 
  •  集群(Cluster):集群是Envoy连接到的一组逻辑上相似的端点;在v2中, RDS通过路由指向集群, CDS提供集群配置,而Envoy通过EDS发现集群成员,即端点; 
  •  下游(Downstream):下游主机连接到Envoy,发送请求并接收响应,它们是Envoy的客户端; 
  •  上游(Upstream):上游主机接收来自Envoy的连接和请求并返回响应,它们是Envoy代理的后端服务器; 
  •  端点(Endpoint):端点即上游主机,是一个或多个集群的成员,可通过EDS发现; 
  •  侦听器(Listener):侦听器是能够由下游客户端连接的命名网络位置,例如端口或unix域套接字等; 
  •  位置(Locality):上游端点运行的区域拓扑,包括地域、区域和子区域等; 
  •  管理服务器(Management Server):实现v3 API的服务器,它支持复制和分片,并且能够在不同的物理机器上实现针对不同xDS API的API服务; 
  •  地域(Region):区域所属地理位置; 
  •  区域(Zone): AWS中的可用区(AZ)或GCP中的区域等; 
  •  子区域: Envoy实例或端点运行的区域内的位置,用于支持区域内的多个负载均衡目标; 
  •  xDS: CDS 、 EDS、 HDS 、 LDS、 RLS(Rate Limit)、 RDS 、 SDS、 VHDS和RTDS等API的统称; 

envoy部署类型

front/sidecar模式

  • Front Proxy模式: 在Envoy Mesh中,作为Front Proxy的Envoy通常是独立运行的进程,它将客户端请求代理至Mesh中的各Service,而这些Service中的每个应用实例都会隐藏于一个Sidecar Proxy模式的envoy实例背后;
  • sidecar模式:Envoy通常用于以容器编排系统为底层环境的服务网格中,并以sidecar的形式与主程序容器运行为单个Pod;非编排系统环境中测试时,可以将主程序与Envoy运行于同一容器,或手动组织主程序容器与Envoy容器共享同一网络名称空间; 

Service to service only 

Service to service egress listener 

  • 应用程序用来与其他服务进行通信;
  • HTTP和gRPC请求使用HTTP/1.1主机头或HTTP/2:authority头指示请求的目的地是哪个远程群集;
  • envoy根据配置中的详细信息处理服务发现、负载平衡、速率限制等;
  • 服务只需要了解本地envoy,而不需要关心网络拓扑,不管它们是在开发中还是在生产中运行;

Service to service ingress listener 

  • 远程envoy与本地envoy通信;
    • 接收请求路由到配置端口上的本地服务。
    • 根据应用程序或负载平衡需要,可能涉及多个应用程序端口(例如,如果服务同时需要HTTP端口和gRPC端口)
  • 本地envoy根据需要执行缓冲、断路等操作。

Service to service Plus front proxy 

  • HTTP L7边缘反向代理的envoy集群后面的服务到服务配置;
    •  终止TLS连接; 
    • 支持HTTP/1.1和HTTP/2;
    • HTTP L7路由;
    • 通过Front-Envoy的Ingress接入请求,并结合发现服务与Service-to-Service的Envoy网格进行通信; 
  • 前端envoy主机的工作方式与任何其他envoy主机相同,不同的是它们不会与其他服务并置运行。

Service to service, front proxy, and double proxy 

 双代理的目标是尽可能接近用户地终止 TLS 和客户端连接会更高效 ;

Envoy配置

Envoy配置概述

  • 启动时从Bootstrap配置文件中加载初始配置。
  • 支持动态配置。
    • xDS API
      • 从配置文件加载配置
      • 从管理服务器基于xds协议加载配置。
    • runtime
      • 某些关键特性保存为key/value数据。
      • 支持多层配置和覆盖机制。
  • 启动全动态配置机制后,仅极少数场景需要从新启动Envoy进程(版本更新)。
    • 支持热重启。

Envoy配置方式

Envoy的架构支持非常灵活地配置方式:简单部署场景可以使用纯静态配置,而更复杂的部署场景则可以逐步添加的动态配置机制;

  • 纯静态配置:用户自动提供侦听器、过滤器链、集群及HTTP路由(http代理场景),上游端点的发现仅可通过DNS服务进行,且配置的从新加载必须通过内置的热重启完成;
  • 仅使用EDS:EDS提供的端点发现功能可有效规避DNS的限制(响应中的最大记录数等);
  • 使用EDS和CDS:CDS能够让Envoy以优雅的方式添加、更新和删除上游集群,于是,初始配置时,Envoy无须事先了解所有上游集群;
  • EDS、CDS和RDS:动态发现路由配置;RDS与EDS、CDS一起使用时,为用户提供了构建复杂路由拓扑的能力(流量转移、蓝/绿部署等);
  • EDS、CDS、RDS和LDS:动态发现侦听器配置,包括内嵌的过滤器链;启用此四种发现服务后,除了较罕见的配置变动、证书轮替或更新Envoy程序之外,几乎无须再热重启Envoy;
  • EDS、CDS、RDS、LDS和SDS:动态发现侦听器密钥相关的证书、私钥及TLS会话票据,以及对证书验证逻辑的配置(受信任的根证书和撤销机制等);

Envoy配置概念

  • Bootstrap配置中几个重要的基础概念
    • node:节点标识,以呈现给管理服务器并且例如用于标识目的;
    • static_resources:静态配置的资源,静态资源配置方式主是直接在配置文件中通过static_resources配置参数明确定义listener、cluster和secret的配置方式;
    • dynamic_resources:动态配置的资源,用于配置基于xDS API获取listener、cluster、和secret配置的lds_config、cds_config和ads_config,其相关配置信息保存于称之为管理服务器(ManagementServer)的主机上经由xDS API向外暴露;
    • admin:Envoy内置的管理接口;
    • tracing:分布式跟踪;
    • layered_runtime:层级化的运行时,支持使用RTDS从管理服务器动态加载;
    • hds_config:使用HDS从管理服务器加载上游主机健康状态检测相关的配置;
    • overload_manager:过载管理器;
    • stats_sinks:统计信息管理器;
  • 一般来说,侦听器和集群时最为常用的基础配置,无论是以静态或者是动态方式提供。

侦听器和集群配置基础

  • 侦听器
    • 接收客户端请求的入口端点,通常由监听的套接字及调用的过滤器链所定义;
    • 代理类的过滤器负责路由请求,例如tcp_Proxy和http_connection_manager等。
  • 集群
    • 一组上游主机的逻辑组合;
    • 每个主机映射为集群中的一个端点;
    • 下游的请求被调度至上游主机;

Listener

Listener 配置概念

  • The Envoy configuration supports any number of listeners within a single process.
    • 独立部署时,建议每个主机仅部署单个Envoy实例,并在必要时于此实例上运行一到多个侦听器;
  • Each listener is independently configured with some number of network level (L3/L4) filters.
    • 侦听器收到的连接请求将由其过滤器链中的各过滤器进行处理;
    • The generic listener architecture is used to perform the vast majority of different proxy tasks that Envoy is used for
      • rate limiting
      • TLS client authentication
      • HTTP connection management
      • raw TCP proxy
      • etc
  • 侦听器主要用于定义Envoy监听的用于接收Downstreams请求的套接字、用于处理请求时调用的过滤器链及相关的其它配置属性;
    • L4过滤器echo主要用于演示网络过滤器API的功能,它会回显接收到的所有数据至下游的请求者;在配置文件中调用时其名称为envoy;

Listener 配置格式

listeners:
- name: 
  address:
    socket_address: { address: ..., port_value: ..., protocol: ... }
  filter_chains: 
  - filters:
    - name:
      config:

Listener 配置示例

static_resources:
  listeners:
    name: listener_0
    address:
      socket_address:
        address: 0.0.0.0
        port_value: 15001
     filter_chains: 
     - filters:
       - name: envoy.echo

filter分类

  • 网络过滤器:Network level (L3/L4) filters form the core of Envoy connection handling:
    • The filter API allows for different sets of filters to be mixed and matched and attached to a given listener.
    • There are three different types of network filters:
      • Read: Read filters are invoked when Envoy receives data from a downstream connection.

      • Write: Write filters are invoked when Envoy is about to send data to a downstream connection.

      • Read/Write: Read/Write filters are invoked both when Envoy receives data from a downstream connection and when it is about to send data to a downstream connection.
    • The API for network level filters is relatively simple since ultimately the filters operate on raw bytes and a small number of connection events.
    • Filters in the chain can stop and subsequently continue iteration to further filters.

  • 侦听器过滤器:网络过滤器访问和操作L4连接上的原始数据,即TCP数据包:

    • 例如,TCP代理过滤器将客户端连接数据路由到上游主机,并生成连接统计信息等.

  • 应用层过滤器:Enovy内置了许多L3/L4过滤器,例如:

    • 代理类:TCP Proxy、HTTP connection manager、Thrift Proxy、Mongo proxy、Dubbo Proxy、ZooKeeper proxy、MySql proxy和Redis proxy等;

    • 其它:Client TLS authentication、Rate limit、Role Based Access Control (RBAC) Network Filter和Upstream Cluster from SNI等;

Network(L3/L4) filter

L4过滤器tcp_proxy

  • TCP代理过滤器在下游客户端及上游集群之间执行1:1网络连接代理

    • 它可以单独用作隧道替换,也可以同其他过滤器(如MongoDB过滤器或速率限制过滤器)结合使用;

    • TCP代理过滤器严格执行由全局资源管理于为每个上游集群的全局资源管理器设定的连接限制

      • TCP代理过滤器检查上游集群的资源管理器是否可以在不超过该集群的最大连接数的情况下创建连接;

    • TCP代理过滤器可直接将请求路由至指定的集群,也能够在多个目标集群间基于权重进行调度转发;

L4过滤器tcp_proxy配置语法

{
  "stat_prefix": "...", # 用于统计数据中输出时使用的前缀字符;
  "cluster": "...", # 路由到的目标集群标识;
  "weighted_clusters": "{...}",
  "metadata_match": "{...}",
  "idle_timeout": "{...}", # 上下游连接间的超时时长,即没有发送和接收报文的超时时长;
  "access_log": [], # 访问日志;
  "max_connect_attempts": "{...}" # 最大连接尝试次数;
}

L4过滤器HTTP connection manager

  • HTTP connection manager自身是L3/L4过路器,它能够将原始字节转换为HTTP级别消息和事件(例如,headers和body等);
  • 它还处理所有HTTP连接和请求共有的功能,例如访问日志记录、请求ID生成和跟踪、请求/响应头操作、路由表管理和统计信息等;
  • 与L3/L4过滤器堆栈相似,Envoy还支持在HTTP连接管理器中使用HTTP级过滤器堆栈;
    • HTTP过滤器在L7运行,它们访问和操作HTTP请求和响应;例如,gRPC-JSON Transcoder Filter为gRPC后端公开REST API,并将请求和响应转换为响应的格式;
    • 常用的HTTP过滤器有Router、Rate limit、Health check、Gzip和Fault Injection等;

L4过滤器HTTP connection manager配置格式

listeners:
- name: 
  address:
    socket_address: { address: ..., port_value: ..., protocol: ... }
  filter_chains: 
  - filters:
    - name: envoy.filters.network.http_connection_manager
      typed_config:
        "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
        stat_prefix: ... # 统计信息中使用的易读性的信息前缀;
        route_config: # 静态路由配置;动态配置应该使用rds字段进行指定;
          name: ... # 路由配置的名称;
          virtual_hosts: # 虚拟主机列表,用于构成路由表;
            - name: ... # 虚拟主机的逻辑名称,用于统计信息,与路由无关;
              domains: [] # 当前虚拟主机匹配的域名列表,支持使用“*”通配符;匹配搜索次序为精确匹配、前缀通配、后缀通配及完全通配;
              routes: [] # 指定的域名下的路由列表,执行时按顺序搜索,第一个匹配到路由信息即为使用的路由机制;
        http_filters: # 定义http过滤器链
        - name: envoy.filters.http.router # 调用7层的路由过滤器
  • http_connection_manager通过引入L7过滤器链实现了对http协议的操纵,其中router过滤器用于配置路由转发;
  • 处理请求时,Envoy首先根据下游客户端请求的“host”来搜索虚拟主机列表中各virtual_host中的domains列表中的定义,第一个匹配到的Domain的定义所属的virtual_host即可处理请求的虚拟主机;
  • 而后搜索当前虚拟主机中的routes列表中的路由列表中各路由条目的match的定义,第一个匹配到的match后的路由机制(route、redirect或direct_response)即生效;

HTTP 路由基础配置

  • route_config.virtual_hosts.routes配置的路由信息用于将下游的客户端请求路由至合适的上游集群中某Server上;
    • 其路由方式是将url匹配match字段的定义;

      • match字段可通过prefix(前缀)、path(路径)或safe_regex(正则表达式)三者之一来表示匹配模式;

      • 可额外根据headers和query_parameters完成报文匹配;

      • 匹配的到报文可有三种路由机制

        • redirect

        • direct_response

        • route

    • 与match相关的请求将由route(路由规则)、redirect(重定向规则)或direct_response(直接响应)三个字段其中之一完成路由;
    • 由route定义的路由目标必须是cluster(上游集群名称)、cluster_header(根据请求标头中的cluster_header的值确定目标集群)或weighted_clusters(路由目标有多个集群,每个集群拥有一定的权重)其中之一;
      • 支持cluster、weighted_clusters和cluster_header三者之一定义目标路由;
      • 转发期间可根据prefix_rewrite和host_rewrite完成URL重写;
      • 可额外配置流量管理机制,例如
        • 韧性相关:timeout、retry_policy
        • 测试相关:request_mirror_policy
        • 流控相关:rate_limits
        • 访问控制相关: cors

路由基础配置

路由配置格式

{
  "name": ...,
  "match": {...},
  "route": {...},
  "redirect": {...},
  "direct_response": {...},
  "metadata": {...},
  "decorator": {...},
  "typed_per_filter_config": {...},
  "request_headers_to_add": [],
  "request_headers_to_remove": [],
  "response_headers_to_add": [],
  "response_headers_to_remove": [],
  "tracing": {...},
  "per_request_buffer_limit_bytes": {...},
  "stat_prefix": ...
}

match

https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/route/v3/route_components.proto#envoy-v3-api-field-config-route-v3-route-match

https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/route/v3/route_components.proto#envoy-v3-api-msg-config-route-v3-routematch

  • 基于prefix、path或safe_regex三者其中任何一个进行URL匹配;

  • 可额外根据headers和query_parameters完成报文匹配;

  • 匹配的到报文可有三种路由机制;

    • redirect

    • direct_response

    • route

match配置格式

{
  "prefix": ...,
  "path": ...,
  "safe_regex": {...},
  "connect_matcher": {...},
  "path_separated_prefix": ...,
  "case_sensitive": {...},
  "runtime_fraction": {...},
  "headers": [],
  "query_parameters": [],
  "grpc": {...},
  "tls_context": {...},
  "dynamic_metadata": []
}

route

  • 支持cluster、weighted_clusters和cluster_header三者之一定义目标路由;
  • 转发期间可根据prefix_rewrite和host_rewrite完成URL重写;
  • 可额外配置流量管理机制,例如timeout、retry_policy、cors、request_mirror_policy和rate_limits等;
查看代码
 {
  "cluster": ...,
  "cluster_header": ...,
  "weighted_clusters": {...},
  "cluster_specifier_plugin": ...,
  "inline_cluster_specifier_plugin": {...},
  "cluster_not_found_response_code": ...,
  "metadata_match": {...},
  "prefix_rewrite": ...,
  "regex_rewrite": {...},
  "host_rewrite_literal": ...,
  "auto_host_rewrite": {...},
  "host_rewrite_header": ...,
  "host_rewrite_path_regex": {...},
  "append_x_forwarded_host": ...,
  "timeout": {...},
  "idle_timeout": {...},
  "early_data_policy": {...},
  "retry_policy": {...},
  "request_mirror_policies": [],
  "priority": ...,
  "rate_limits": [],
  "include_vh_rate_limits": {...},
  "hash_policy": [],
  "cors": {...},
  "max_grpc_timeout": {...},
  "grpc_timeout_offset": {...},
  "upgrade_configs": [],
  "internal_redirect_policy": {...},
  "internal_redirect_action": ...,
  "max_internal_redirects": {...},
  "hedge_policy": {...},
  "max_stream_duration": {...}
}

redirect

{
  "https_redirect": ...,
  "scheme_redirect": ...,
  "host_redirect": ...,
  "port_redirect": ...,
  "path_redirect": ...,
  "prefix_rewrite": ...,
  "regex_rewrite": {...},
  "response_code": ...,
  "strip_query": ...
}

direct_response

{
  "status": ...,
  "body": {...}
}

 

Upstream clusters

clusters 配置概念

  • Envoy可配置任意数量的上游集群,并使用Cluster Manager进行管理;

    • 由集群管理器负责管理的各集群可以由用户静态配置,也可借助于CDS API动态获取;

    • 集群中的每个成员由endpoint进行标识,它可由用户静态配置,也可通过EDS或DNS服务动态发现;

      • Static:静态配置

      • Strict DNS:严格DNS,Envoy将持续和异步地解析指定的DNS目标,并将DNS结果中的返回的每个IP地址视为上游集群中可用成员;
      • Logical DNS:逻辑DNS,集群仅使用在需要启动新连接时返回的第一个IP地址,而非严格获取DNS查询的结果并假设它们构成整个上游集群;适用于必须通过DNS访问的大规模Web服务集群;
      • Original destination:当传入连接通过iptables的REDIRECT或TPROXY target或使用代理协议重定向到Envoy时,可以使用原始目标集群;
      • Endpoint discovery service (EDS):EDS是一种基于GRPC或REST-JSON API的xDS管理服务器获取集群成员的服务发现方式;
      • Custom cluster:Envoy还支持在集群配置上的cluster_type字段中指定使用自定义集群发现机制;
  • 每个Cluster主要由集群名称,以及集群中的端点(通常是提供服务的IP地址和端口)所组成;
  • Envoy Cluster支持纯静态定义方式来指定端点,也允许以动态方式发现各端点,甚至还支持自定义的发现机制;
  • 支持用户定义多种高级功能,例如,负载均衡策略、主动健康状态检查、被动健康状态检查和断路器等;

clusters 配置格式

查看代码
 {
"transport_socket_matches": [],
"name": "...",
"alt_stat_name": "...",
"type": "...",
"cluster_type": "{...}",
"eds_cluster_config": "{...}",
"connect_timeout": "{...}",
"per_connection_buffer_limit_bytes": "{...}",
"lb_policy": "...",
"load_assignment": "{...}",
"health_checks": [],
"max_requests_per_connection": "{...}",
"circuit_breakers": "{...}",
"upstream_http_protocol_options": "{...}",
"common_http_protocol_options": "{...}",
"http_protocol_options": "{...}",
"http2_protocol_options": "{...}",
"typed_extension_protocol_options": "{...}",
"dns_refresh_rate": "{...}",
"dns_failure_refresh_rate": "{...}",
"respect_dns_ttl": "...",
"dns_lookup_family": "...",
"dns_resolvers": [],
"use_tcp_for_dns_lookups": "...",
"outlier_detection": "{...}",
"cleanup_interval": "{...}",
"upstream_bind_config": "{...}",
"lb_subset_config": "{...}",
"ring_hash_lb_config": "{...}",
"maglev_lb_config": "{...}",
"original_dst_lb_config": "{...}",
"least_request_lb_config": "{...}",
"common_lb_config": "{...}",
"transport_socket": "{...}",
"metadata": "{...}",
"protocol_selection": "...",
"upstream_connection_options": "{...}",
"close_connections_on_host_health_failure": "...",
"ignore_health_on_host_removal": "...",
"filters": [],
"track_timeout_budgets": "...",
"upstream_config": "{...}",
"track_cluster_stats": "{...}",
"preconnect_policy": "{...}",
"connection_pool_per_downstream_connection": "..."
}
查看代码
clusters:
- name: ... # 集群的惟一名称,且未提供alt_stat_name时将会被用于统计信息中;
  alt_state_name: ... # 统计信息中使用的集群代名称;
  type: ... # 用于解析集群(生成集群端点)时使用的服务发现类型,可用值有STATIC、STRICT_DNS、LOGICAL_DNS、ORIGINAL_DST和EDS等;
  lb_policy: # 负载均衡算法,支持ROUND_ROBIN、LEAST_REQUEST、RING_HASH、RANDOM、MAGLEV和CLUSTER_PROVIDED;
  load_assignment: # 为STATIC、STRICT_DNS或LOGICAL_DNS类型的集群指定成员获取方式;EDS类型的集成要使用eds_cluster_config字段配置;
    cluster_name: ... # 集群名称;
    endpoints: # 端点列表;
    - locality: {} # 标识上游主机所处的位置,通常以region、zone等进行标识;
      - lb_endpoints: # 属于指定位置的端点列表;
        - endpoint_name: ... # 端点的名称;
          - endpoint: # 端点定义;
              address: ... # 端点地址;
                socket_adddress: # 端点地址标识;
                  port_value: ... # 端点端口;
                  protocol: ... # 协议类型;

clusters 配置示例

查看代码
 {
"transport_socket_matches": [],
"name": "...",
"alt_stat_name": "...",
"type": "...",
"cluster_type": "{...}",
"eds_cluster_config": "{...}",
"connect_timeout": "{...}",
"per_connection_buffer_limit_bytes": "{...}",
"lb_policy": "...",
"load_assignment": "{...}",
"health_checks": [],
"max_requests_per_connection": "{...}",
"circuit_breakers": "{...}",
"upstream_http_protocol_options": "{...}",
"common_http_protocol_options": "{...}",
"http_protocol_options": "{...}",
"http2_protocol_options": "{...}",
"typed_extension_protocol_options": "{...}",
"dns_refresh_rate": "{...}",
"dns_failure_refresh_rate": "{...}",
"respect_dns_ttl": "...",
"dns_lookup_family": "...",
"dns_resolvers": [],
"use_tcp_for_dns_lookups": "...",
"outlier_detection": "{...}",
"cleanup_interval": "{...}",
"upstream_bind_config": "{...}",
"lb_subset_config": "{...}",
"ring_hash_lb_config": "{...}",
"maglev_lb_config": "{...}",
"original_dst_lb_config": "{...}",
"least_request_lb_config": "{...}",
"common_lb_config": "{...}",
"transport_socket": "{...}",
"metadata": "{...}",
"protocol_selection": "...",
"upstream_connection_options": "{...}",
"close_connections_on_host_health_failure": "...",
"ignore_health_on_host_removal": "...",
"filters": [],
"track_timeout_budgets": "...",
"upstream_config": "{...}",
"track_cluster_stats": "{...}",
"preconnect_policy": "{...}",
"connection_pool_per_downstream_connection": "..."
}
clusters:
- name: test_cluster
  connect_timeout: 0.25s
  type: STATIC
  lb_policy: ROUND_ROBIN
  load_assignment:
    cluster_name: test_cluster
    endpoints:
    - lb_endpoints: 
      - endpoint:
        address:
          socket_address: { address: 172.17.0.3, port_value: 80 }
      - endpoint:
        address:
          socket_address: { address: 172.17.0.4, port_value: 80 }

Envoy线程模型

Envoy使用单进程/多线程的架构模型,一个主线程(Main thread)负责实现各类管理任务,而一些工作线程(Worker threads)则负责执行监听、过滤和转发等代理服务器的核心功能;

  • 主线程:负责Envoy程序的启动和关闭、xDS API调用处理(包括DNS、健康状态检测和集群管理等)、运行时配置、统计数据刷新、管理接口维护和其它线程管理(信号和热重启等)等,相关的所有事件均以异步非阻塞模式完成;
  • 工作线程:默认情况下,Envoy根据当前主机CPU核心数来创建等同数量的工作线程,不过,管理员也可以通过程序选项--concurrency具体指定;每个工作线程运行一个非阻塞型事件循环,负责为每个侦听器监听指定的套接字、接收新请求、为每个连接初始一个过滤器栈并处理此连接整个生命周期中的所有事件;
  • 文件刷写线程:Envoy写入的每个文件都有一个专用、独立的阻塞型刷写线程,当工作线程需要写入文件时,数据实际上被移入内存缓冲区,最终通过文件刷写线程同步至文件中;

Envoy连接处理

Envoy通过侦听器监听套接字并接收客户端请求,而Envoy的所有工作线程会同时共同监听用户配置的所有套接字,对于某次连接请求,由内核负责将其派发至某个具体的工作线程处理; 随后,相关的工作线程基于特定的处理逻辑分别由相关组件依次完成连接管理;

参考文档

官方文档:https://www.envoyproxy.io/docs/envoy/latest/

github地址:https://github.com/envoyproxy/envoy

案例地址: https://github.com/envoyproxy/envoy/tree/main/examples

https://www.envoyproxy.io/docs/envoy/latest/api-v3/http_routes/http_routes

 

posted @ 2022-08-11 16:14  小吉猫  阅读(931)  评论(0编辑  收藏  举报