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

 


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM