1. 服務網格的部署模式

服務網格部署模式有兩種:

主機共享代理

• 適用于同一主機上存在許多容器的場景,并且還可以利用連接池來提高吞吐量
• 但一個代理進程故障將終止其所在主機上的整個容器隊列,受影響的不僅僅是單個服務
• 實現方式,常見的是運行為kubernetes之上的Daemonset

sidecar容器

• 代理進程注入每個Pod定義以與主容器一同運行
• Sidecar進程應該盡可能輕量且功能完善
• 實現方案: Linkerd,Envoy和Conduit

2. 未來云原生架構趨勢

Lifecycle 生命周期管理: k8s

Networking 網絡: Service Mesh 分布式的高級網絡通信需求

Binding 綁定: Knative 專注于serverless,同時兼顧了服務編排和事件驅動的綁定需求

State 狀態: Dapr 建立在k8s,knative和服務網格的思想之上,并深入應用程序運行時以解決狀態化工作負載,綁定和集成的需求,充當現代分布式中間件.

3. Envoy 基本概念

3.1 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等項目均是為此數據平面代理提供控制平面

3.2 Envoy常見基礎組件

LDS : Listener Discovery Service

CDS: Cluster Discovery Service

RDS: Route Discovery Service

EDS: Endpoint Discovery Service

SDS: Secret Discovery Service(私鑰,證書)

VHDS: Virtual Host Discovery Service

HDS: Health Discovery Service

ADS: Aggregated Discovery Service

ECDS: Extension Config Discovery Service

CSDS: Client Status Discovery Service

RTDS: Runtime Discovery Service

RLS: Rate Limit Service

LRS: Load Reporting Service

ALS: AccessLog Service

3.3 Envoy API xDS常用術語

Host(主機): 一個具有網絡通信能力的端點

Cluster(集群): 集群是Envoy連接到一個邏輯上相似的端點;在v2中,RDS通過路由指向集群,CDS提供集群配置,而Envoy通過EDS發現集群成員,即端點.

Downstream下游: 下游主機連接到Envoy,發送請求并響應,它們是Envoy的客戶端.

Upstream上游: 上游主機接收來自Envoy的連接和請求并返回響應,它們是Envoy代理的后端服務器.

Endpoint端點: 即上游主機,是一個或多個集群的成員,可通過EDS發現

Listener偵聽器: 是能夠由下游客戶端連接的命名網絡位置.如:端口,unix套接字等

Locality位置: 上游端點運行的區域拓撲,包括地域,區域和子區域等

Management Server管理服務器: 實現v2 API的服務器,它支持復制和分片,并且能夠在不同的物理機上實現針對不同xDS API的API服務

Region地域: 區域所屬地理位置

Zone區域: AWS中的可用區AZ或GCP中的區域等

Sub Zone子區域: Envoy實例或端點運行的區域內的位置,用于支持區域內的多個負載均衡目標

xDS: CDS,EDS,HDS,LDS,RLS,RDS,SDS,VHDS,RTDS等API的同城

Mesh和Envoy Mesh

3.4 Deployment type

Front Proxy訪問單個Service: Envoy訪問ServiceA的邊車的Ingress Listener,Sidecar將請求轉發給ServiceA.

訪問調用其他Service的Service: Envoy訪問Ingress,Ingress將請求轉給ServiceA,ServiceA對ServicerB有請求,ServiceA通過Egress Listener將請求正向代理到ServiceB的Ingress Listener,再有Ingress 將求情反向代理給ServiceB

訪問有外部調用的Service: Envoy訪問Ingress,Ingress將請求轉給ServiceA,ServiceA對外部(External Service)有請求,ServiceA通過Egress Listener將請求正向代理到Egress網關,再有Egress網關轉發到外部,并由外部的External Service進行應答響應

4. Envoy配置概述

啟動時從Bootstrap 配置文件中加載初始配置

支持動態配置

• xDS API
  從配置文件加載配置
  從管理服務器基于xds協議加載配置
• runtime
  某些關鍵特性保存為k/v數據
  支持多層配置和覆蓋機制

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

• 支持熱啟動

4.1 Envoy的配置方法

Envoy的架構支持多種配置方法,常見的有:

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

僅使用EDS: EDS提供的端點發現功能可以有效的規避DNS的限制(響應中的最大記錄數等)

使用EDS和CDS: CDS能夠讓Envoy以優雅的方式添加,更新和刪除上游集群,于是,初始配置時,Envoy無需事先了解所有上游集群.

EDS,CDS和RDS: 動態發現路由配置,RDS與EDS,CDS一起使用時,為用戶提供了構建復雜路由拓撲的能力(流量轉移,藍綠發布等)

EDS,CDS,RDS和LDS: 動態發現偵聽器配置,包括內嵌的過濾器鏈,啟用此4種發現服務后,除了罕見的配置變動,證書輪替或更新Envoy程序之外,幾乎無需再熱重啟Envoy

EDS,CDS,RDS,LDS和SDS: 動態發現偵聽器秘鑰相關的證書,私鑰及TLS會話票據,以及對證書驗證邏輯配置(受信任的根證書和撤銷機制等.)

4.2 Envoy配置中的重要概念

4.2.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: 統計信息接收器

一般來說,偵聽器和集群是最為常見的基礎配置,無論是以靜態或者是動態方式提供

4.2.2 Listener

同一個Envoy實例可以配置多個偵聽器

每一個偵聽器可以有多個虛擬主機

偵聽器需要借助過濾器鏈來處理請求,過濾器鏈中使用的過濾器分為:3/4層過濾器,7層過濾器

4.2.3 Cluster如何發現Endpoint

Static 通過靜態配置直接給定IP和Port

給定的是主機名稱和端口,借助于DNS來將主機名稱轉成IP,一個主機名可以對應多個ip,ip與port的組合就是一個Endpoint

• Strict DNS,嚴格DNS: 一個名稱只會解析到有限個數的IP地址上.會把DNS解析結果中的所有ip配置為一個Endpoint
• Logical DNS,邏輯DNS: 解析到不確定個數的地址.僅把DNS解析結果中的第一個IP配置為一個Endpoint

EDS: 通過基于GRPC和REST-JSON API的xDS管理服務器獲取收集群成員的服務發現方式:

Original destination : 當傳入連接通過iptables的REDIRRECT或TPROXY target或使用代理協議重定向到Envoy時,可以使用原始目標集群;

Custom cluster: Envoy還支持在集群配置上的cluster_type字段中指定使用自定義集群發現機制

4.3 Envoy連接處理

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

啟用一個work接收用戶請求,由listener過濾器進行處理,和客戶端建立連接,交給tcp過濾器管理器進行處理.如果Read Fileter則交給TCP Read filters處理,通過Http codec解碼,轉發給Http manager.由Http Chttp_connection_manager Manager轉發給Http 讀過濾器,通過路由交給上游Endpoint.響應報文發送給連接池,經HTTP寫過濾器封裝返回給Http Connation Manager,再有http codec交給TCP寫過濾器做TCP封裝最終返回給客戶端.

5. 常見的Envoy部署方法

使用Docker image進行部署.配置文件默認/etc/envoy/envoy.yaml

二進制,直接下載運行即可

部署文檔

總結

以上是生活随笔為你收集整理的【云原生 | Envoy 系列】--Envoy原理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。