envoy-知识篇

一、envoy basics

1、What is Envoy?

Envoy是一个7层代理和通信总线，专为大型现代面向服务的体系结构设计。

这个项目诞生于这样的信念:
◼网络对应用程序应该是透明的。
◼当网络和应用程序问题确实发生时，应该很容易确定问题的根源。

高水平的特性
⚫流程外的架构
⚫L3/L4过滤器架构
⚫HTTP L7过滤器架构
⚫一流的HTTP/2支持
⚫HTTP/3支持(目前还在alpha版本)
⚫HTTP L7路由
⚫gRPC支持
⚫业务发现和动态配置
⚫健康检查
⚫高级负载均衡
⚫前端/边缘代理支持
⚫最好的类可观察性

2、Envoy is …

⚫服务代理
⚫用c++编写，高度并行，无阻塞
⚫L3/4网络过滤器
⚫开箱即用L7过滤器
⚫HTTP 2，包括gRPC
⚫内置服务发现/健康检查功能
⚫高级负载均衡
⚫统计数据，指标，跟踪
⚫通过xDS动态配置

3、Envoy implements

⚫区域感知，优先级/地域负载均衡
⚫熔断机制
⚫异常值检测
⚫重试，重试策略
⚫超时(包括预算)
⚫流量跟踪
⚫请求速度
⚫速率限制
⚫访问日志、统计数据收集

4、Other key Envoy proxying features

⚫请求对冲
⚫重试预算
⚫负载均衡优先级
⚫位置加权负载均衡
⚫区域路由
⚫endpoint的降级(回退)
⚫聚合集群

5、Envoy Data Path

incoming-requests–>listeners–>fileter-chains–>cluster-definitions–>outgoing-requests

6、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 端点实现（2021年第1季度结束支持）
◼ v3 API：当前支持的版本，支持start_tls、拒绝传入的tcp连接、4096位的tls密钥、SkyWalking和WASM等 
⚫Envoy现已成为现代服务网格和边缘网关的“ 通用数据平面API ”，Istio、Ambassador和Gloo等项目均是为此数据平面代理提供的控制平面；

7、Envoy Terminology

clients–>envoy–>servers
downstream–>envoy–>upstream

8、Envoy基础组件

clients/downstream–>(xDS API)(listeners(–>filters–>routes)–>clusters–>endpoints)–>servers/upstream
xDS API:LDS、RDS、CDS、EDS、SDS、HDS、RLDS(Rate Limit)、VHDS、RTDS等

9、Enovy API常用术语

 主机（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中的区域等；
 子区域：Envoy实例或端点运行的区域内的位置，用于支持区域内的多个负载均衡目标；
 xDS：CDS 、EDS、HDS 、LDS、RLS(Rate Limit)、 RDS 、 SDS、VHDS和RTDS等API的统称；
 Mesh和Envoy Mesh

10、Deployment types

Envoy可用于各种不同的场景，但是最常用于在跨基础设施中作为所有主机的网格部署

Envoy通常用于以容器编排系统为底层环境的服务网格中，并以sidecar的形式与主程序容器运行为单个Pod；
非编排系统环境中测试时，可以将主程序与Envoy运行于同一容器，或手动组织主程序容器与Envoy容器共享同一网络名称空间；
Front Proxy类型的Envoy可独立运行为守护进程或容器；

具体使用时的常见部署类型如下图所示：
front-proxy(envoy)–>ingress-listener + Service-A
front-proxy(envoy)–>ingress-listener + Service-B + egress-listener–>ingress-listener + Service D
front-proxy(envoy)–>ingress-listener + Service-C + egress-listener–>external-Service

service to service
⚫egress listener
◼这是应用程序用来与基础设施中的其他服务进行通信的端口。
◼HTTP和gRPC请求使用HTTP/1.1主机头部或HTTP/2:authority头部来指示请求的目的地是哪个远程集群。
◼Envoy根据配置的细节处理服务发现、负载均衡、速率限制等。
◼服务只需要知道本地Envoy，不需要关心网络拓扑、是在开发中运行还是在生产中运行等等。
app client–>envoy sidecar(egress)(listener-routing->cluster)–>upstream
⚫ingress listener
◼这是远程envoy与本地Envoy通信时所使用的端口
传入的请求被路由到配置端口上的本地服务。
根据应用或负载均衡的需要，可能涉及多个应用端口(例如，如果服务同时需要一个HTTP端口和一个gRPC端口)。
◼本地envoy根据需要进行缓冲、熔断等操作
downstream–>envoy-sidecar(ingress)(listener–routing–>cluster)–>app-server
⚫可选的外部服务的egress listener

⚫front proxy
◼下图显示了用作HTTP L7边缘反向代理的Envoy集群背后的服务到服务配置。
external-clients–>internet–>front-envoy–>cluster
◆终止TLS连接;
◆支持HTTP/1.1和HTTP/2;
◆HTTP L7路由;
◆通过Front-Envoy的Ingress接入请求，并结合发现服务与Service-to-Service的Envoy网格进行通信；
◼front-Envoy主机与任何其他Envoy主机的工作方式相同，但是它们与其他服务不会并列运行。

double proxy
external-clients–>internet–>front-envoy–>front-envoy–>private-infra
◼ 双代理的目标是尽可能接近用户地终止 TLS 和客户端连接会更高效

二、配置envoy

1、Envoy配置概述

⚫启动时从Bootstrap配置文件中加载初始配置
⚫支持动态配置
◼ xDS API
从配置文件加载配置
从管理服务器（Management Server）基于xds协议加载配置
◼ runtime
某些关键特性（Feature flags）保存为key/value数据
支持多层配置和覆盖机制
⚫启用全动态配置机制后，仅极少数场景需要重新启动Envoy进程
◼ 支持热重启

2、Envoy的配置方式

⚫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会话票据，以及对证书验证逻辑的配置（受信任的根证书和撤销机制等）；

3、Envoy配置中的重要概念

⚫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”: “…”
}
⚫一般来说，侦听器和集群是最为常用基础配置，无论是以静态或者是动态方式提供；

4、侦听器和集群配置基础

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

5、Listeners

◼Envoy配置支持单个进程中任意数量的侦听器。
◆独立部署时，建议每个主机仅部署单个Envoy实例，并在必要时于此实例上运行一到多个侦听器；
◆Enovy支持TCP和UDP两种类型的侦听器；
◼每个侦听器都独立配置了一些Network (L3/L4) filters。
◆侦听器收到的连接请求将由其过滤器链中的各过滤器进行处理；
◆通用侦听器体系结构用于执行Envoy所用于的绝大多数不同的代理任务
◆速度限制
◆TLS客户端认证
◆HTTP连接管理
◆原始TCP代理
◆等
{
“name”: “…”,
“address”: “{…}”,
“stat_prefix”: “…”,
“filter_chains”: [],
“use_original_dst”: “{…}”,
“default_filter_chain”: “{…}”,
“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”: [],
“tcp_backlog_size”: “{…}”,
“bind_to_port”: “{…}”
}

6、Network (L3/L4) filters

◼网络级别(L3/L4)过滤器形成envoy连接处理的核心
◆过滤器API允许将不同的过滤器集混合、匹配并附加到给定的侦听器上。
◆有三种不同类型的网络过滤器:
read:当Envoy从下游连接接收数据时，读取过滤器被调用。
Write:当Envoy正要将数据发送到下游连接时，会调用写过滤器。
read/write:当Envoy从下游连接接收数据和将要向下游连接发送数据时，会调用读/写过滤器。
◆网络级过滤器的API相对简单，因为最终过滤器只操作原始字节和少量连接事件
◆链中的过滤器可以停止，然后继续迭代到更多的过滤器
◼网络过滤器访问和操作L4连接上的原始数据，即TCP数据包
◆例如，TCP代理过滤器将客户端连接数据路由到上游主机，并生成连接统计信息等

7、Network (L3/L4) filters and HTTP filters

◼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等；
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等；

8、Upstream 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支持纯静态定义方式来指定端点，也允许以动态方式发现各端点，甚至还支持自定义的发现机制
◼支持用户定义多种高级功能，例如，负载均衡策略、主动健康状态检查、被动健康状态检查和断路器等；
{
“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”: “…”
}

9、Envoy线程模型

Envoy使用单进程/多线程的架构模型，一个主线程（Main thread）负责实现各类管理任务，而一些工作线程（Worker threads）则负责执行监听、过滤和转发等代理服务器的核心功能
◼ 主线程：负责Envoy程序的启动和关闭、xDS API调用处理（包括DNS、健康状态检测和集群管理等）、运行时配置、统计数据刷新、
管理接口维护和其它线程管理（信号和热重启等）等，相关的所有事件均以异步非阻塞模式完成；
◼ 工作线程：默认情况下，Envoy根据当前主机CPU核心数来创建等同数量的工作线程，不过，管理员也可以通过程序选项–concurrency具体指定；
每个工作线程运行一个非阻塞型事件循环，负责为每个侦听器监听指定的套接字、接收新请求、为每个连接初始一个过滤器栈并处理此连接整个生命周期中的所有事件；
◼ 文件刷写线程：Envoy写入的每个文件都有一个专用、独立的阻塞型刷写线程，当工作线程需要写入文件时，数据实际上被移入内存缓冲区，最终通过文件刷写线程同步至文件中

10、Envoy连接处理

Envoy通过侦听器监听套接字并接收客户端请求，而Envoy的所有工作线程会同时共同监听用户配置的所有套接字，对于某次连接请求，
由内核负责将其派发至某个具体的工作线程处理; 随后，相关的工作线程基于特定的处理逻辑分别由相关组件依次完成连接管理;
worker–>listener-filters–>connection–>TCP-fileter-manager–>TCP read filters–>http codec–>http-conn-manager–>HTTP read filters–>
service router–>upstream conn pool–>backend service–>upstream conn pool–>service router–>HTTP write filters–>http-conn-manager–>
http codec–>TCP write filters–>TCP-fileter-manager–>connection–>listener-filters–>worker
stat admin cluster/listener/route/manager Xds-API

三、envoy快速入门

1、Enovy部署类型回顾

见一、10、Deployment types

2、部署和运行Envoy的常用方法

Envoy项目为多种平台（例如amd64和arm64等）维护有相应的Docker Image，我们可按需猎取相应镜像后以容器形式运行Envoy，而且它们存在以下几种变化形式
◼ envoy：基于Ubuntu Bionic制作的Docker Image
◼ envoy-alpine和envoy-alpine-dev：基于alpine制作的Docker Image
◼ envoy-debug和envoy-debug-dev：基于Ubuntu制作的带有debug环境的Docker Image
◼ envoy-windows和envoy-windows-dev：基于Windows 1809制作的Docker Image
Get Envoy项目为多个主流的Linux发行版（例如Ubuntu、CentOS和RHEL等）维护了二进制的发行版，配置相应的仓库后，即可使用系统的包管理器进行安装；
◼ Ubuntu
◆ https://dl.bintray.com/tetrate/getenvoy-deb
◼ CentOS
◆ https://tetrate.bintray.com/getenvoy-rpm/centos/
◼ RHEL
◆ https://tetrate.bintray.com/getenvoy-rpm/rhel/
部署文档（建议使用稳定版）
◼ https://www.envoyproxy.io/docs/envoy/latest/start/install

3、部署并运行Envoy

部署Envoy，以Debian/Ubuntu Linux发行版为例
$ sudo apt update
$ sudo apt install apt-transport-https ca-certificates curl gnupg2 software-properties-common
$ curl -sL ‘https://getenvoy.io/gpg’ | sudo apt-key add -
# 检查密钥
$ apt-key fingerprint 6FF974DB | grep “5270 CEAC”
$ sudo add-apt-repository “deb [arch=amd64] https://dl.bintray.com/tetrate/getenvoy-deb $(lsb_release -cs) stable”
$ sudo apt update
$ sudo apt install getenvoy-envoy
运行Envoy
◼ 检查envoy的版本
◆ envoy --version
◼ 获取帮助
◆ envoy --help
◼ 检查配置文件语法
◆ envoy --mode validate -c /path/to/my-envoy-config.yaml
◼ 运行Envoy，并指定自定义的日志路径
◆ envoy -c envoy-demo.yaml --log-path logs/custom.log
◆ 示例配置文件（提示：被代理的服务是Google，建议修改为其他可用地址）
⚫ https://www.envoyproxy.io/docs/envoy/latest/_downloads/92dcb9714fb6bc288d042029b34c0de4/envoy-demo.yaml

4、启动Envoy

启动Envoy时，需要通过“-c”选项为其指定初始配置文件以提供引导配置（Bootstrap configuration），这也是使用v3 API的必然要求；
◼ $ envoy -c .{json,yaml,pb,pb_text}
◆ 扩展名代表了配置信息的组织格式；
◼ 引导配置是Envoy配置信息的基点，用于承载Envoy的初始配置，它可能包括静态资源和动态资源的定义
◆静态资源（static_resources）于启动直接加载
◆动态资源（dynamic_resources）则需要通过配置的xDS服务获取并生成
◼ 通常，Listener和Cluster是Envoy得以运行的基础，而二者的配置可以全部为静态格式，也可以混合使用动态及静态方式提供，或者全部配置为动态；
◆ 例如，一个yaml格式纯静态的基础配置框架：
static_resources:
listeners:
- name: …
address: {}
filter_chains: []
clusters:
- name: …
type: …
connect_timeout: {}
dns_lookup_family: V4_ONLY
load_assignment: {}

5、静态资源和动态资源

纯静态资源配置方式主是直接在配置文件中通过static_resources配置参数明确定义listeners、clusters和secrets的配置方式，各配置参数的数据类型如下面的配置所示；
◼ 其中，listeners用于配置纯静态类型的侦听器列表，clusters用于定义可用的集群列表及每个集群的端点，而可选的secrets用于定义TLS通信中用到数字证书等配置信息
◼ 具体使用时，admin和static_resources两参数即可提供一个最小化的资源配置，甚至admin也可省略
{
“listeners”: [],
“clusters”: [],
“secrets”: []
}

动态资源，是指由envoy通过xDS协议发现所需要的各项配置的机制，相关的配置信息保存于称之为管理服务器（Management Server）的主机上，经由xDS API向外暴露；下面是一个
◼ 纯动态资源的基础配置框架；
{
“lds_config”: “{…}”,
“cds_config”: “{…}”,
“ads_config”: “{…}”
}

6、Listener的简易静态配置

侦听器主要用于定义Envoy监听的用于接收Downstreams请求的套接字、用于处理请求时调用的过滤器链及相关的其它配置属性；
listeners:
- name:
address:
socket_address: { address: …, port_value: …, protocol: … }
filter_chains: - filters:
- name:
config:
◼ L4过滤器echo主要用于演示网络过滤器API的功能，它会回显接收到的所有数据至下游的请求者；在配置文件中调用时其名称为envoy.echo；
◼ 下面是一个最简单的静态侦听器配置示例
static_resources:
listeners:
name: listener_0
address:
socket_address:
address: 0.0.0.0
port_value: 15001
filter_chains: - filters:
- name: envoy.echo

7、启动第一个自定义的Envoy实例

◼ 基于直接部署二进制程序启动运行envoy实例时，直接指定要使用的配置文件即可：

1. 为envoy创建配置文件专用的存储目录，例如/etc/envoy/
2. 将前面的侦听器示例保存为此目录下的envoy-echo-demo.yaml配置文件
3. 测试配置文件语法

   envoy --mode validate -c /etc/envoy/envoy-echo-demo.yaml

4. 若语法测试不存在问题，即可直接启动Envoy示例

   envoy -c /etc/envoy/envoy-echo-demo.yaml

5. 使用nc命令发起测试，键入的任何内容将会由envoy.echo过滤器直接echo回来

   nc 127.0.0.1 15001

◼ 提示：Envoy的核心功能在于代理请求及负载均衡，因此，定义上游cluster，并设置其代理和路由机制是为常规使用逻辑，本示例仅用于简单演示如何启动envoy进程

8、启动第一个自定义的Envoy容器实例

基于envoy的预制docker镜像启动实例时，需要额外自定义配置文件，而后将其焙进新的镜像中或以存储卷的方式向容器提供以启动容器；下面以二次打包镜像的方式进行测试：

1. 为envoy容器创建专用的工作目录，例如/applications/envoy/
2. 将前面的侦听器示例保存为此目录下的echo-demo/子目录中，文件名为envoy.yaml
   提示：完整的文件路径为/applications/envoy/echo-demo/envoy.yaml；
3. 测试配置文件语法

# cd /applications/envoy/
# docker run --name echo-demo --rm -v $(pwd)/echo-demo/envoy.yaml:/etc/envoy/envoy.yaml envoyproxy/envoy-alpine:v1.18-latest --mode validate -c /etc/envoy/envoy.yaml

4. 若语法测试不存在问题，即可直接启动Envoy示例；下面第一个命令用于了解echo-demo容器的IP地 址

# docker run --name echo-demo --rm -v $(pwd)/echo-demo/envoy.yaml:/etc/envoy/envoy.yaml envoyproxy/envoy-alpine:v1.18- latest -c /etc/envoy/envoy.yaml

5. 使用nc命令发起测试，键入的任何内容将会由envoy.echo过滤器直接echo回来

# containerIP=$(docker container inspect --format="{
  {.NetworkSettings.IPAddress}}" echo-demo)
# nc $containerIP 15001

9、Cluster简易静态配置

通常，集群代表了一组提供相同服务的上游服务器（端点）的组合，它可由用户静态配置，也能够通过CDS动态获取；
集群需要在“预热”环节完成之后方能转为可用状态，这意味着集群管理器通过DNS解析或EDS服务完成端点初始化，以及健康状态检测成功之后才可用；
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: # 端点定义；
socket_adddress: # 端点地址标识；
address: … # 端点地址；
port_value： … # 端点端口；
protocol: … # 协议类型；

10、Cluster配置示例

静态Cluster的各端点可以在配置中直接给出，也可借助DNS服务进行动态发现；
下面的示例直接给出了两个端点地址
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 }

11、L4过滤器tcp_proxy

TCP代理过滤器在下游客户端及上游集群之间执行1:1网络连接代理
◼ 它可以单独用作隧道替换，也可以同其他过滤器（如MongoDB过滤器或速率限制过滤器）结合使用；
◼ TCP代理过滤器严格执行由全局资源管理于为每个上游集群的全局资源管理器设定的连接限制
◆ TCP代理过滤器检查上游集群的资源管理器是否可以在不超过该集群的最大连接数的情况下创建连接；
◼ TCP代理过滤器可直接将请求路由至指定的集群，也能够在多个目标集群间基于权重进行调度转发；
配置语法：
{
“stat_prefix”: “…”, # 用于统计数据中输出时使用的前缀字符；
“cluster”: “…”, # 路由到的目标集群标识；
“weighted_clusters”: “{…}”,
“metadata_match”: “{…}”,
“idle_timeout”: “{…}”, # 上下游连接间的超时时长，即没有发送和接收报文的超时时长；
“access_log”: [], # 访问日志；
“max_connect_attempts”: “{…}” # 最大连接尝试次数；
}

12、TCP代理配置示例（Front Proxy）

下面的示例基于TCP代理将下游用户（本机）请求代理至后端的两个web服务器
static_resources:
listeners:
name: listener_0
address:
socket_address: { address: 0.0.0.0, port_value: 80 }
filter_chains: - filters:
- name: envoy.tcp_proxy
typed_config:
“@type”: type.googleapis.com/envoy.extensions.filters.network.tcp_proxy.v3.TcpProxy
stat_prefix: tcp
cluster: local_cluster
clusters:
- name: local_cluster
connect_timeout: 0.25s
type: STATIC
lb_policy: ROUND_ROBIN
load_assignment:
cluster_name: local_cluster
endpoints:
- lb_endpoints: - endpoint:
address:
socket_address: { address: 172.31.0.11, port_value: 8080 }
- endpoint:
address:
socket_address: { address: 172.31.0.12, port_value: 8080 }

13、L4过滤器http_connection_manager

http_connection_manager通过引入L7过滤器链实现了对http协议的操纵，其中router过滤器用于配置路由转发；
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层的路由过滤器
提示：
◼处理请求时，Envoy首先根据下游客户端请求的“host”来搜索虚拟主机列表中各virtual_host中的domains列表中的定义，第一个匹配到的Domain的定义所属的virtual_host即可处理请求的虚拟主机；
◼而后搜索当前虚拟主机中的routes列表中的路由列表中各路由条目的match的定义，第一个匹配到的match后的路由机制（route、redirect或direct_response）即生效；

14、HTTP L7路由基础配置

route_config.virtual_hosts.routes配置的路由信息用于将下游的客户端请求路由至合适的上游集群中某Server上；
◼ 其路由方式是将url匹配match字段的定义
◆ match字段可通过prefix（前缀）、path（路径）或safe_regex（正则表达式）三者之一来表示匹配模式；
◼ 与match相关的请求将由route（路由规则）、redirect（重定向规则）或direct_response（直接响应）三个字段其中之一完成路由；
◼ 由route定义的路由目标必须是cluster（上游集群名称）、cluster_header（根据请求标头中的cluster_header的值确定目标集群）或weighted_clusters（路由目标有多个集群，每个集群拥有一定的权重）其中之一；
routes:
- name: … # 此路由条目的名称；
match:
prefix: … # 请求的URL的前缀；
route: # 路由条目；
cluster: # 目标下游集群；

15、路由基础配置概览

match
◼ 基于prefix、path或regex三者其中任何一个进行URL匹 配 ✓ 提示：regex将会被safe_regex取代；
◼ 可额外根据headers和query_parameters完成报文匹配
◼ 匹配的到报文可有三种路由机制
◆ redirect
◆ direct_response
◆ route
route
◼ 支持cluster、weighted_clusters和cluster_header三者之一定义目标路由
◼ 转发期间可根据prefix_rewrite和host_rewrite完成URL重写；
◼ 可额外配置流量管理机制，例如timeout、retry_policy、cors、request_mirror_policy和rate_limits等；

16、L7 Front Proxy代理配置示例

下面是一个egress类型的Envoy配置示例，它定义了两个virtual_host，不过，发往第二个virtual_host的请求将被重定向至第一个；
static_resources:
listeners:
- name: listener_0
address:
socket_address: { address: 0.0.0.0, port_value: 80 }
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: ingress_http
codec_type: AUTO
route_config:
name: local_route
virtual_hosts: - name: web_service_1
domains: [".ik8s.io", “ik8s.io”]
routes:
- match: { prefix: “/” }
route: { cluster: local_cluster } - name: web_service_2
domains: [".magedu.com",“magedu.com"]
routes:
- match: { prefix: “/” }
redirect:
host_redirect: “www.ik8s.io”
http_filters: - name: envoy.filters.http.router
前面给出了Listener的配置，Cluster配置我们采用前面tcp-proxy示例中的配置；
而后于主机上使用curl命令即可发起测试
◼ 由下面的命令及结果可知，发往第一个“domain”的请求被调度至后端主机的各端点之上
◼ 发往第二个“domain”的请求被重定向至“http://www.ik8s.io”，而该Location又对应于上面的第一个domain中的主机
~$ curl -H “host: www.ik8s.io” 172.31.0.2
iKubernetes demoapp v1.0 !! ClientIP: 172.31.0.2, ServerName: webserver01, ServerIP: 172.31.0.11!
~$ curl -H “host: www.ik8s.io” 172.31.0.2
iKubernetes demoapp v1.0 !! ClientIP: 172.31.0.2, ServerName: webserver02, ServerIP: 172.31.0.12!
~$ curl -I -H “host: www.magedu.com” 172.31.0.2
HTTP/1.1 301 Moved Permanently
location: http://www.ik8s.io/
date: Tue, 18 May 2021 03:14:37 GMT
server: envoy
transfer-encoding: chunked

17、L7 Ingress Listener代理配置示例

将运行的envoy和demoapp两个应用的容器设定为共享同一个Network Namespace来模拟Ingress代理的场景
◼ envoy容器（Sidecar）：监听于0.0.0.0:80套接字，接收客户端请求，并代理至demoapp容器
◼ demoapp容器：监听于127.0.0.1:8080套接字，接收来自于同一网络名称空间中的envoy代理的请求
右侧是Envoy的配置文件
static_resources:
listeners:
- name: listener_0
address:
socket_address: { address: 0.0.0.0, port_value: 80 }
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: ingress_http
codec_type: AUTO
route_config:
name: local_route
virtual_hosts: - name: web_service_1
domains: ["*"]
routes:
- match: { prefix: “/” }
route: { cluster: local_cluster }
http_filters: - name: envoy.filters.http.router
clusters:
- name: local_cluster
connect_timeout: 0.25s
type: STATIC
lb_policy: ROUND_ROBIN
load_assignment:
cluster_name: local_cluster
endpoints:
- lb_endpoints: - endpoint:
address:
socket_address: { address: 127.0.0.1, port_value: 8080 }

~$ curl 172.31.0.2
iKubernetes demoapp v1.0 !! ClientIP: 127.0.0.1, ServerName: 
d7cc61138f2c, ServerIP: 172.31.0.2!
~$ curl -I 172.31.0.2
HTTP/1.1 200 OK
content-type: text/html; charset=utf-8
content-length: 97
server: envoy
date: Tue, 18 May 2021 03:59:39 GMT
x-envoy-upstream-service-time: 1

18、L7 Egress Listener代理配置示例

将运行的envoy和client两个应用的容器设定为共享同一个Network Namespace来模拟Egress代理的场景
◼ envoy容器（Sidecar）：监听于127.0.0.1:80套接字，接收客户端请求，并代理至demoapp容器
◼ client容器：直接向同一网络名称空间中的envoy代理的127.0.0.1:80套接字发请求
下面，我们测试于client容器的交互式接口中请求Egress Sidecar上的服务
static_resources:
listeners:
- name: listener_0
address:
socket_address: { address: 127.0.0.1, port_value: 80 }
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: ingress_http
route_config:
name: local_route
virtual_hosts: - name: web_service_1
domains: ["*"]
routes:
- match: { prefix: “/” }
route: { cluster: web_cluster }
http_filters: - name: envoy.filters.http.router
clusters:
- name: web_cluster
connect_timeout: 0.25s
type: STATIC
lb_policy: ROUND_ROBIN
load_assignment:
cluster_name: web_cluster
endpoints:
- lb_endpoints: - endpoint:
address:
socket_address: { address: 172.31.4.11, port_value: 80 }
- endpoint:
address:
socket_address: { address: 172.31.4.12, port_value: 80 }
~$ docker exec -it http-egress_client_1 /bin/sh
[root@2e41a86dbac1 /]#
[root@2e41a86dbac1 /]# curl 127.0.0.1/hostname
ServerName: webserver02
[root@2e41a86dbac1 /]# curl 127.0.0.1/hostname
ServerName: webserver01

四、Administration interface和 Layered Runtime 基础

1、管理接口admin

Envoy内建了一个管理服务（administration server），它支持查询和修改操作，甚至有可能暴露私有数据（例如统计数据、集群名称和证书信息等），因此非常有必要精心编排其访问控制机制以避免非授权访问；
admin:
access_log: [] # 访问日志协议的相关配置，通常需要指定日志过滤器及日志配置等；
access_log_path: … # 管理接口的访问日志文件路径，无须记录访问日志时使用/dev/null；
profile_path: … # cpu profiler的输出路径，默认为/var/log/envoy/envoy.prof；
address: # 监听的套接字；
socket_address:
protocol: …
address: …
port_value: …
下面是一个简单的配置示例
admin:
access_log_path: /tmp/admin_access.log
address:
socket_address: { address: 0.0.0.0, port_value: 9901 }
# 提示：此处 仅为出于方便测试的目的，才设定其监听于对外通信的任意IP地址；安全起见，应该使用127.0.0.1；

2、为Envoy添加Admin Interface

以前面一节中配置的“L7 Front Proxy”添加管理接口的方法，仅需要在其用到的envoy.yaml配置文件中添加相关的配置信息即可；
下面给出的简单的测试命令 admin:
access_log_path: /tmp/admin_access.log
address:
socket_address: { address: 0.0.0.0, port_value: 9901 }
static_resources:
listeners:
- name: listener_0
address:
socket_address: { address: 0.0.0.0, port_value: 80 }
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: ingress_http
codec_type: AUTO
……
clusters:
- name: local_cluster
connect_timeout: 0.25s
type: STATIC
……

~$ curl 172.31.5.2:9901/listeners
listener_0::0.0.0.0:80
~$ curl 172.31.5.2:9901/ready
LIVE
~$ curl 172.31.5.2:9901/config_dump
{
"configs": [ {
"@type": 
"type.googleapis.com/envoy.admin.v3.BootstrapConfigDump",
"bootstrap": {
"node": {
"hidden_envoy_deprecated_build_version": 
"98c1c9e9a40804b93b074badad1cdf284b47d58b/1.18.3/Clean/RELEAS
E/BoringSSL",
"user_agent_name": "envoy",
"user_agent_build_version": {
"version": {
"major_number": 1,
"minor_number": 18,
"patch": 3
},
……
}

3、管理接口admin速览

admin接口内置了多个/path，不同的path可能会分别接受不同的GET或POST请求；
admin commands are:
/: Admin home page # GET
/ready：Outputs a string and error code reflecting the state of the server. # GET，返回envoy服务当前的状态；
/certs: print certs on machine # GET，列出已加载的所有TLS证书及相关的信息；
/clusters: upstream cluster status # GET，额外支持使用“GET /clusters?format=json”
/config_dump: dump current Envoy configs # GET，打印Envoy加载的各类配置信息；支持include_eds、master和resource等查询参数；
/contention: dump current Envoy mutex contention stats (if enabled) # GET，互斥跟踪
/cpuprofiler: enable/disable the CPU profiler # POST，启用或禁用cpuprofiler
/healthcheck/fail: cause the server to fail health checks # POST，强制设定HTTP健康状态检查为失败；
/healthcheck/ok: cause the server to pass health checks # POST，强制设定HTTP健康状态检查为成功；
/heapprofiler: enable/disable the heap profiler # POST，启用或禁用heapprofiler；
/help: print out list of admin commands
/hot_restart_version: print the hot restart compatibility version # GET，打印热重启相关的信息；
/listeners: print listener addresses # GET，列出所有侦听器，支持使用“GET /listeners?format=json”
/drain_listeners：Drains all listeners. # POST，驱逐所有的listener，支持使用inboundonly（仅入站侦听器）和graceful（优雅关闭）等查询参数；
/logging: query/change logging levels # POST，启用或禁用不同子组件上的不同日志记录级别
/memory: print current allocation/heap usage # POST，打印当前内在分配信息，以字节为单位；
/quitquitquit: exit the server # POST，干净退出服务器；
/reset_counters: reset all counters to zero # POST，重围所有计数器；
/tap：This endpoint is used for configuring an active tap session. # POST，用于配置活动的带标签的session；
//reopen_logs：Triggers reopen of all access logs. Behavior is similar to SIGUSR1 handling. # POST，重新打开所有的日志，功能类似于SIGUSR1信号；
/runtime: print runtime values # GET，以json格式输出所有运行时相关值；
/runtime_modify: modify runtime values # POST /runtime_modify?key1=value1&key2=value2，添加或修改在查询参数中传递的运行时值
/server_info: print server version/status information # GET，打印当前Envoy Server的相关信息；
/stats: print server stats # 按需输出统计数据，例如GET /stats?filter=regex，另外还支持json和prometheus两种输出格式；
/stats/prometheus: print server stats in prometheus format # 输出prometheus格式的统计信息；

4、管理接口

几个示例输出
◼ GET /clusters：列出所有已配置的集群，包括每个集群中发现的所有上游主机以及每个主机的统计信息；支持输出为json格式；
◆ 集群管理器信息：“version_info string”，无CDS时，则显示为“version_info::static”
◆ 集群相关的信息：断路器、异常点检测和用于表示是否通过CDS添加的标识“add_via_api”
◆ 每个主机的统计信息：包括总连接数、活动连接数、总请求数和主机的健康状态等；不健康的原因通常有以下三种
⚫ failed_active_hc：未通过主动健康状态检测；
⚫ failed_eds_health：被EDS标记为不健康；
⚫ failed_outlier_check：未通过异常检测机制的检查；
◼ GET /listeners：列出所有已配置的侦听器，包括侦听器的名称以及监听的地址；支持输出为json格式；
◼ POST /reset_counters：将所有计数器重围为0；不过，它只会影响Server本地的输出，对于已经发送到外部存储系统的统计数据无效；
◼ GET /config_dump：以json格式打印当前从Envoy的各种组件加载的配置信息；
◼ GET /ready：获取Server就绪与否的状态，LIVE状态为200，否则为503；

5、集群统计信息中主机的状态说明

6、Envoy运行时配置概述

相较于静态资源配置来说，xDS API的动态配置机制使得Envoy的配置系统极具弹性；
◼ 但有时候配置的变动仅需要修改个别的功能特性，若通过xDS接口完成未免有些动静过大，Runtime便是面向这种场景的配置接口；
◼ Runtime就是一个虚拟文件系统树，可通过一至多个本地文件系统目录、静态资源、RTDS动态发现和Admin Interface进行定义和配置；
◆ 每个配置称为一个Layer，因而也称为“Layered Runtime”，这些Layer最终叠加生效；
换句话说，Runtime是与Envoy一起部署的外置实时配置系统，用于支持更改配置设置而无需重启Envoy或更改主配置；
◼ 运行时配置相关的运行时参数也称为“功能标志（feature flags）”或“决策者（decider）”；
◼ 通过运行时参数更改配置将实时生效；
运行时配置的实现也称为运行时配置供应者；
◼ Envoy当前支持的运行时配置的实现是由多个层级组成的虚拟文件系统
◆ Envoy在配置的目录中监视符号链接的交换空间，并在发生交换时重新加载文件树；
◼ 但Envoy会使用默认运行时值和“null”提供给程序以确保其正确运行，因此，运行时配置系统并不必不可少；

7、配置Envoy运行时环境

启用Envoy的运行时配置机制需要在Bootstrap文件中予以启用和配置
◼定义在bootstrap配置文件中的layered_runtime顶级字段之下
◼ 一旦在bootstrap中给出layered_runtime字段，则至少要定义出一个layer；
layered_runtime: # 配置运行配置供应者，未指定时则使用null供应者，即所有参数均加载其默认值；
layers: # 运行时的层级列表，后面的层将覆盖先前层上的配置；
- name: … # 运行时的层级名称，仅用于“GET /runtime”时的输出；
static_layer: {…} # 静态运行时层级，遵循运行时probobuf JSON表示编码格式；不同于静态的xDS资源，静态运行时层一样可被后面的层所覆盖；
# 此项配置，以及后面三个层级类型彼此互斥，因此一个列表项中仅可定义一层；
disk_layer: {…} # 基于本地磁盘的运行时层级；
symlink_root: … # 通过符号链接访问的文件系统树；
subdirectory: … # 指定要在根目录中加载的子目录；
append_service_cluster: … # 是否将服务集群附加至符号链接根目录下的子路径上；
admin_layer: {…} # 管理控制台运行时层级，即通过/runtime管理端点查看，通过/runtime_modify管理端点修改的配置方式；
rtds_layer: {…} # 运行时发现服务（runtime discovery service）层级，即通过xDS API中的RTDS API动态发现相关的层级配置；
name: … # 在rtds_config上为RTDS层订阅的资源；
rtds_config：RTDS的ConfigSource；

8、Envoy运行时配置

运行时配置用于指定包含重新加载配置元素的虚拟文件系统树；
◼ 该虚拟文件可以通过静态引导配置、本地文件系统、管理控制台和RTDS派生的叠加来实现；
◼ 因此，可以将运行时视为由多个层组成的虚拟文件系统；
◆ 在分层运行时的引导配置中指定各层级，后续的各层级中的运行设置会覆盖较早的层级；
◼ 下面是一个典型的配置示例，它定义了四个层级
layers:
- name: static_layer_0
static_layer:
health_check:
min_interval: 5
- name: disk_layer_0
disk_layer: { symlink_root: /srv/runtime/current, subdirectory: envoy }
- name: disk_layer_1
disk_layer: { symlink_root: /srv/runtime/current, subdirectory: envoy_override, append_service_cluster: true }
- name: admin_layer_0
admin_layer: {}
◆静态引导配置层级，直接指定配置的运行时参数及其值；
◆本地磁盘文件系统
◆本地磁盘文件系统，子目录覆盖（override_subdirectory）
◆管理控制台层级

五、Front Proxy and TLS

1、Front Proxy

在Envoy Mesh中，作为Front Proxy的Envoy通常是独立运行的进程，它将客户端请求代理至Mesh中的各Service，而这些Service中的每个应用实例都会隐藏于一个Sidecar Proxy模式的envoy实例背后；
◼ 我们这里仍然以docker-compose为编排工具，以便于将更多的精力集中于Envoy及Mesh之上

2、TLS

Envoy Mesh中的TLS模式大体有如下几种常用场景
◼ Front Proxy面向下游客户端提供https服务，但Front Proxy、Mesh内部的各服务间依然使用http协议
◆ https → http
◼ Front Proxy面向下游客户端提供https服务，而且Front Proxy、Mesh内部的各服务间也使用https协 议◆ https → https
◆ 但是内部各Service间的通信也有如下两种情形
⚫ 仅客户端验证服务端证书
⚫ 客户端与服务端之间互相验证彼此的证书（mTLS） ◆ 注意：对于容器化的动态环境来说，证书预配和管理将成为显著难题
◼ Front Proxy直接以TCP Proxy的代理模式，在下游客户端与上游服务端之间透传tls协议；
◆ https-passthrough
◆ 集群内部的东西向流量同样工作于https协议模型

3、TLS Front Proxy

仅需要配置Listener面向下游客户端提供tls通信，下面是Front Proxy Envoy的配置示例
static_resources:
listeners:
- name: listener_http
address:
socket_address: { address: 0.0.0.0, port_value: 8443 }
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_pref