envoy部分二: envoy的配置組件


一、envoy配置概述

1、envoy啟動時從Bootstrap配置文件中加載初始配置。

2、支持靜態和動態配置。

靜態配置:

純手工指定配置。

動態配置:

1)xDS API

◆從配置文件加載配置

◆從管理服務器(Management Server )基於xds協議加載配置

2) runtime

◆某些關鍵特性(Feature flags )保存為key/value 數據

◆支持多層配置和覆蓋機制

3、啟用全動態配置機制后,僅極少數場景需要重新啟動Envoy進程。

支持熱重啟。

4、Envoy的架構支持非常靈活的配置方式:簡單部署場景可以使用純靜態配置,而更復 雜的部署場景則可以逐步添加需要的動態配置機制。

純靜態配置:用戶自行提供偵聽器、過濾器鏈、集 群及HTTP路由(http代理場景),上游端點的發現僅可通過DNS服務進行,且配置的重新加載必須通過內置的熱重啟(hot restart)完成;

僅使用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配置中的重要概念

1、Bootstrap配置中幾個重要的基礎概念

node:節點標識,以呈現給管理服務器並且例如用於標識目的 ;

static_resources:靜態配置的資源,用於配置靜態的listener、cluster和 secret;

dynamic_resources:動態配置的資源,用於配置基於xDS API獲 取listener、cluster和secret配置的lds_config、cds_config和ads_config;

admin:Envoy內置的管理接口;

tracing:分布式跟蹤;

layered_runtime:層級化的 運行時,支持使用RTDS從 管理服務器動態加載;

hds_config:使用HDS從管理服 務器加載上游主機健康狀態檢測相關的配置;

overload_manager: 過載管理器;

stats_sinks:統計信息接收器;
{
"node": "{...}",
"static_resources": "{...}",
"dynamic_resources": "{...}",
"cluster_manager": "{...}",
"hds_config": "{...}",
"flags_path": "...",
"stats_sinks": [],
"stats_config": "{...}",
"stats_flush_interval": "{...}",
"stats_flush_on_admin": "...",
"watchdog": "{...}",
"watchdogs": "{...}",
"tracing": "{...}",
"layered_runtime": "{...}",
"admin": "{...}",
"overload_manager": "{...}",
"enable_dispatcher_stats": "...",
"header_prefix": "...",
"stats_server_version_override": "{...}",
"use_tcp_for_dns_lookups": "...",
"bootstrap_extensions": [],
"fatal_actions": [],
"default_socket_interface": "..."
}

2、偵聽器和集群是最為常用基礎配置,無論是以靜態或者是 動態方式提供;

三、偵聽器和集群配置基礎

1、偵聽器 listener

偵聽器Listener)就是 Envoy 的監聽地址,可以是端口或 Unix Socket。Envoy 在單個進程中支持任意數量的監聽器。通常建議每台機器只運行一個 Envoy 實例,每個 Envoy 實例的監聽器數量沒有限制,這樣可以簡化操作,統計數據也只有一個來源,比較方便統計。目前 Envoy 支持監聽 TCP 協議和 UDP 協議。

TCP

每個監聽器都可以配置多個過濾器鏈(Filter Chains),監聽器會根據 filter_chain_match 中的匹配條件將流量轉交到對應的過濾器鏈,其中每一個過濾器鏈都由一個或多個網絡過濾器Network filters)組成。這些過濾器用於執行不同的代理任務,如速率限制,TLS 客戶端認證,HTTP 連接管理,MongoDB 嗅探,原始 TCP 代理等。

除了過濾器鏈之外,還有一種過濾器叫監聽器過濾器(Listener filters),它會在過濾器鏈之前執行,用於操縱連接的元數據。這樣做的目的是,無需更改 Envoy 的核心代碼就可以方便地集成更多功能。例如,當監聽的地址協議是 UDP 時,就可以指定 UDP 監聽器過濾器。

UDP

Envoy 的監聽器也支持 UDP 協議,需要在監聽器過濾器中指定一種 UDP 監聽器過濾器(UDP listener filters)。目前有兩種 UDP 監聽器過濾器:UDP 代理(UDP proxy) 和 DNS 過濾器(DNSfilter)。UDP 監聽器過濾器會被每個 worker 線程實例化,且全局生效。實際上,UDP 監聽器(UDP Listener)配置了內核參數 SO_REUSEPORT,這樣內核就會將 UDP 四元組相同的數據散列到同一個 worker 線程上。因此,UDP 監聽器過濾器是允許面向會話(session)的。

每個偵聽器可以包含多個L3/L4的過濾器,並對其進行獨立配置。

1)偵聽器收到的連接請求將由其過濾器鏈中的各過濾器進行處理;
2)Envoy偵聽器構架支持大多數的不同proxy的任務。
如:
rate limiting
TLS client authentication
HTTP connection management
raw TCP proxy
......

偵聽器Listener)功能:

1) 接收客戶端請求的入口端點,通常由監聽的套接字及調用的過濾器鏈所定義

2)代理類的過濾器負責路由請求,例如tcp_proxy和http_connection_manager等

監聽器的配置結構如下:

{
  "name": "...",
  "address": "{...}",
  "filter_chains": [],
  "per_connection_buffer_limit_bytes": "{...}",
  "metadata": "{...}",
  "drain_type": "...",
  "listener_filters": [],
  "listener_filters_timeout": "{...}",
  "continue_on_listener_filters_timeout": "...",
  "transparent": "{...}",
  "freebind": "{...}",
  "socket_options": [],
  "tcp_fast_open_queue_length": "{...}",
  "traffic_direction": "...",
  "udp_listener_config": "{...}",
  "api_listener": "{...}",
  "connection_balance_config": "{...}",
  "reuse_port": "...",
  "access_log": []
}

name : 監聽器名稱。默認情況下,監聽器名稱的最大長度限制為 60 個字符。可以通過 --max-obj-name-len 命令行參數設置為所需的最大長度限制。
address : 監聽器的監聽地址,支持網絡 Socket 和 Unix Domain Socket(UDS) 兩種類型。
filter_chains : 過濾器鏈的配置。
per_connection_buffer_limit_bytes : 監聽器每個新連接讀取和寫入緩沖區大小的軟限制。默認值是 1MB。
listener_filters : 監聽器過濾器在過濾器鏈之前執行,用於操縱連接的元數據。這樣做的目的是,無需更改 Envoy 的核心代碼就可以方便地集成更多功能。例如,當監聽的地址協議是 UDP 時,就可以指定 UDP 監聽器過濾器。
listener_filters_timeout : 等待所有監聽器過濾器完成操作的超時時間。一旦超時就會關閉 Socket,不會創建連接,除非將參數 continue_on_listener_filters_timeout 設為 true。默認超時時間是 15s,如果設為 0 則表示禁用超時功能。
continue_on_listener_filters_timeout : 布爾值。用來決定監聽器過濾器處理超時后是否創建連接,默認為 false。
freebind : 布爾值。用來決定是否設置 Socket 的 IP_FREEBIND 選項。如果設置為 true,則允許監聽器綁定到本地並不存在的 IP 地址上。默認不設置。
socket_options : 額外的 Socket 選項。
tcp_fast_open_queue_length : 控制 TCP 快速打開(TCP Fast Open,簡稱 TFO)。TFO 是對TCP 連接的一種簡化握手手續的拓展,用於提高兩端點間連接的打開速度。它通過握手開始時的 SYN 包中的 TFO cookie(一個 TCP 選項)來驗證一個之前連接過的客戶端。如果驗證成功,它可以在三次握手最終的 ACK 包收到之前就開始發送數據,這樣便跳過了一個繞路的行為,更在傳輸開始時就降低了延遲。該字段用來限制 TFO cookie 隊列的長度,如果設為 0,則表示關閉 TFO。
traffic_direction : 定義流量的預期流向。有三個選項:UNSPECIFIED、INBOUND 和 OUTBOUND,分別代表未定義、入站流量和出站流量,默認是 UNSPECIFIED。
udp_listener_config : 如果 address 字段的類型是網絡 Socket,且協議是 UDP,則使用該字段來指定 UDP 監聽器。
connection_balance_config : 監聽器連接的負載均衡配置,目前只支持 TCP。
reuse_port : 布爾值。用來決定是否設置 Socket 的 SO_REUSEPORT 選項。如果設置為 true,則會為每一個 worker 線程創建一個 Socket,在有大量連接的情況下,入站連接會均勻分布到各個 worker 線程中。如果設置為 false,所有的 worker 線程共享同一個 Socket。
access_log : 日志相關的配置。

2、集群 cluster service

◼ 一組上游主機的邏輯組合

◼ 每個主機映射為集群中的一個端點

◼ 下游的請求被調度至上游主機

 

3、Upstream clusters

1) Envoy可配置任意數量的上游集群,並使用Cluster Manager進行管理。

(1)由集群管理器負責管理的各集群可以由用戶靜態配置,也可借助於CDS API動態獲取;
(2)集群中的每個成員由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字段中指定使用自定義集群發現機制;

2) 每個Cluster主要由集群名稱,以及集群 中的端點(通常是提供服務的IP地址和 端口)所組成。

3) Envoy Cluster支持純靜態定義方式來指 定端點,也允許以動態方式發現各端點, 甚至還支持自定義的發現機制。

4) 支持用戶定義多種高級功能,例如,負 載均衡策略、主動健康狀態檢查、被動 健康狀態檢查和斷路器等。

 

{
"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": "...",
"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": "..."
}

四、Network (L3/L4) filters

Envoy 進程中運行着一系列 Inbound/Outbound 監聽器(Listener),Inbound 代理入站流量,Outbound 代理出站流量。Listener 的核心就是過濾器鏈(FilterChain),鏈中每個過濾器都能夠控制流量的處理流程。過濾器鏈中的過濾器分為兩個類別:

  • 網絡過濾器(Network Filters): 工作在 L3/L4,是 Envoy 網絡連接處理的核心,處理的是原始字節,分為 ReadWriteRead/Write 三類。

  • HTTP 過濾器(HTTP Filters): 工作在 L7,由特殊的網絡過濾器 HTTP connection manager 管理,專門處理 HTTP1/HTTP2/gRPC 請求。它將原始字節轉換成 HTTP 格式,從而可以對 HTTP 協議進行精確控制。

除了 HTTP connection manager 之外,還有一種特別的網絡過濾器叫 Thrift ProxyThrift 是一套包含序列化功能和支持服務通信的 RPC 框架。Thrift Proxy 管理了兩個 Filter:RouterRate Limit

除了過濾器鏈之外,還有一種過濾器叫監聽器過濾器(Listener Filters),它會在過濾器鏈之前執行,用於操縱連接的元數據。這樣做的目的是,無需更改 Envoy 的核心代碼就可以方便地集成更多功能。例如,當監聽的地址協議是 UDP 時,就可以指定 UDP 監聽器過濾器。

 

1、網絡級(L3/L4)過濾器構成了Envoy連接處理的核心

1)過濾器API允許將不同的過濾器集混合、匹配並附加到給定的偵聽器。  
2)有三種不同類型的網絡過濾器: 
  Read:當Envoy從下游連接接收數據時,讀取過濾器被調用。  
  Write:當Envoy正要將數據發送到下游連接時,會調用Write filter。  
  Read/Write:當Envoy從下游連接接收數據和將要向下游連接發送數據時,會調用讀/寫過濾器。  
3)網絡級過濾器的API相對簡單,因為最終過濾器只操作原始字節和少量連接事件。
4)鏈中的過濾器可能會停止,隨后繼續迭代進一步篩選。  

2、網絡過濾器訪問和操作L4連接上的原始數據,即TCP數據包

例如,TCP代理過濾器將客戶端連接數據路由到上游主機,並生成連接統計信息等

3、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 等;

4、HTTP connection manager

(1)HTTP connection manager自身是L3/L4 過路器,它能夠將原始字節轉換為HTTP級別消息 和事件(例如,headers和body等)
(2)它還處理所有HTTP連接和請求共有的功能,例如訪問日志記錄、請求ID生成和跟蹤、 請求/響應頭操作、路由表管理和統計信息等;
(3)與L3/L4過濾器堆棧相似,Envoy還支持在HTTP連接管理器中使用HTTP級過濾器堆棧; 
  HTTP過濾器在L7運行,它們訪問和操作HTTP請求和響應;例如,gRPC-JSON Transcoder Filter為gRPC后端公開REST API,並將請求和響應轉換為相應的格式;
  常用的HTTP過路器有Router、Rate limit 、Health check 、Gzip和Fault Injection等。

 

五、Envoy線程模型

Envoy使用單進程/多線程的架構模型,一個主線程 (Main thread)負責實現各類管理任務,而一些工作線 程(Worker threads)則負責執行監聽、過濾和轉發等代 理服務器的核心功能。

主線程:負責Envoy程序的啟動和關閉、xDS API調用處 理(包括DNS、健康狀態檢測和集群管理等)、運行時配 置、統計數據刷新、管理接口維護和其它線程管理(信號 和熱重啟等)等,相關的所有事件均以異步非阻塞模式完成.

工作線程:默認情況下,Envoy根據當前主機CPU核心數 來創建等同數量的工作線程,不過,管理員也可以通過程 序選項--concurrency具體指定;每個工作線程運行一個非 阻塞型事件循環,負責為每個偵聽器監聽指定的套接字、接收新請求、為每個連接初始一個過濾器棧並處理此連接 整個生命周期中的所有事件。

文件刷寫線程:Envoy寫入的每個文件都有一個專用、獨 立的阻塞型刷寫線程,當工作線程需要寫入文件時,數據 實際上被移入內存緩沖區,最終通過文件刷寫線程同步至文件中。

 

六、Envoy連接處理

Envoy通過偵聽器監聽套接字並接收客戶端請求,而Envoy的所有工作線程會同時共同監聽用 戶配置的所有套接字,對於某次連接請求,由內核負責將其派發至某個具體的工作線程處理; 隨后,相關的工作線程基於特定的處理邏輯分別由相關組件依次完成連接管理。

 


免責聲明!

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



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