Envoy 面试题
14 道题- 分类
- Kubernetes
- 子分类
- services-network
- 题目数
- 14 道
1 Envoy 的整体架构与核心定位是什么?
答案:
Envoy 是 CNCF 毕业的 L4/L7 高性能云原生代理,最初由 Lyft 开源,核心定位是 Service Mesh 数据面 与 Edge Gateway,采用 C++ 编写、**单进程多线程(Single process, Multi-threaded Worker)**架构(不是 Thread-per-core 硬绑——后者是 HAProxy 术语;Envoy 是多线程 worker + 可选 --cpuset-threads 软绑)。
核心架构组件:
| 组件 | 职责 |
|---|---|
| Listener | 监听端口,定义流量入口(L4/L7) |
| Filter Chain | 流量处理管道,按链路依次调用 |
| Network Filter | L4 协议处理(TCP Proxy、Redis Proxy、MongoDB Proxy) |
| HTTP Connection Manager (HCM) | L7 HTTP 处理入口,挂载 HTTP Filter |
| HTTP Filter | L7 协议处理(Router、JWT、Rate Limit、CORS、Lua、Wasm) |
| Route | URL/Header 匹配规则,路由到 Cluster |
| Cluster | 上游服务集合,承载负载均衡与健康检查 |
| Endpoint | Cluster 内的具体实例(IP:Port) |
线程模型:
- Main Thread:xDS 配置管理、服务发现、统计聚合,单线程无锁
- Worker Thread:处理客户端请求,每个线程独立 event loop(基于 libevent),实例化全量 Listener,通过 SO_REUSEPORT 在 Worker 间分摊连接
- File Flush Thread:异步写日志,避免阻塞 Worker
核心特性:
- 动态配置:xDS API 支持运行时热更新,无需重启
- 可观测性内建:详细 stats、access log、分布式追踪
- 多协议支持:HTTP/1.1、HTTP/2、HTTP/3 (QUIC)、gRPC、TCP、Redis、Postgres、Thrift、Dubbo(2024-2025 持续扩展:Kafka、MySQL、DynamoDB 网络 filter)
- 扩展性:原生 C++ Filter、Lua 脚本、Wasm 沙箱
2 xDS 协议的工作原理与各子协议作用是什么?
答案:
xDS(Discovery Service)是 Envoy 与控制面之间的动态配置协议族,基于 gRPC 或 REST 双向流,将控制面策略实时下发至数据面。
xDS 子协议矩阵:
| 协议 | 全称 | 用途 |
|---|---|---|
| LDS | Listener Discovery Service | 动态发现 Listener 配置 |
| RDS | Route Discovery Service | 动态发现 HTTP 路由配置 |
| CDS | Cluster Discovery Service | 动态发现上游集群 |
| EDS | Endpoint Discovery Service | 动态发现 Cluster 内的实例 |
| SDS | Secret Discovery Service | 动态发现 TLS 证书/密钥 |
| ADS | Aggregated Discovery Service | 单流聚合上述所有协议,保证配置顺序 |
| HDS | Health Discovery Service | 健康检查结果上报 |
| VHDS | Virtual Host Discovery Service | 按需加载虚拟主机 |
典型加载顺序(CDS → EDS → LDS → RDS):
1. CDS 下发 Cluster 列表(如 backend-cluster)
2. EDS 下发各 Cluster 的 Endpoint(如 10.0.1.5:8080, 10.0.1.6:8080)
3. LDS 下发 Listener(如 0.0.0.0:80)
4. RDS 下发 Route(如 /api/* 路由到 backend-cluster)
ADS 推荐场景:
xDS 协议存在配置依赖关系,若各协议分别建流,可能出现 Listener 引用尚未下发的 Route 等竞态。ADS 通过单 gRPC 流串行下发,由控制面控制顺序,是生产首选。
SOTW vs Delta xDS:
- SOTW(State of the World):每次推送全量配置,简单但带宽消耗高
- Delta xDS:增量推送(Added/Removed),适合大规模集群(万级 Endpoint)
ADS 配置示例:
dynamic_resources:
ads_config:
api_type: GRPC
transport_api_version: V3
grpc_services:
- envoy_grpc:
cluster_name: xds_cluster
cds_config: { ads: {}, resource_api_version: V3 }
lds_config: { ads: {}, resource_api_version: V3 }
3 Listener / Route / Cluster / Endpoint 的配置模型与关系是什么?
答案:
Envoy 配置采用四层抽象模型,从流量入口到上游实例逐级映射,是理解 Envoy 与所有 xDS 控制面(Istio、Envoy Gateway)的基础。
关系图:
Listener (0.0.0.0:80)
└── Filter Chain (SNI/transport_protocol 匹配)
└── HTTP Connection Manager
└── Route Configuration
└── Virtual Host (host 匹配)
└── Route (path/header 匹配)
└── Cluster (后端服务)
└── Endpoint (具体 IP:Port)
最小静态配置示例:
static_resources:
listeners:
- name: listener_0
address:
socket_address: { address: 0.0.0.0, port_value: 10000 }
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: backend
domains: ["*"]
routes:
- match: { prefix: "/" }
route: { cluster: service_cluster }
http_filters:
- name: envoy.filters.http.router
typed_config:
"@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router
clusters:
- name: service_cluster
connect_timeout: 5s
type: STRICT_DNS
lb_policy: ROUND_ROBIN
load_assignment:
cluster_name: service_cluster
endpoints:
- lb_endpoints:
- endpoint:
address:
socket_address: { address: backend.svc, port_value: 8080 }
关键概念辨析:
| 概念 | 说明 |
|---|---|
| Listener | 监听 socket,可绑定多个 Filter Chain |
| Filter Chain Match | 按 SNI、ALPN、源 IP、传输协议选择 chain |
| Virtual Host | 一组共享路由规则的域名集合 |
| Route | 单条路由规则,含匹配条件和动作(转发/重定向/直接响应) |
| Cluster | 逻辑后端服务(含 LB 策略、健康检查、熔断) |
| Endpoint | 实际后端实例,可静态或通过 EDS 动态发现 |
4 Envoy 的 HTTP L7 路由如何配置?支持哪些高级特性?
答案:
Envoy 通过 RouteConfiguration 提供丰富的 L7 路由能力,支持权重路由、Header/Query 匹配、重试、超时、镜像、重定向、CORS 等。
多维路由匹配示例:
virtual_hosts:
- name: api
domains: ["api.example.com"]
routes:
# 灰度发布(权重路由)
- match: { prefix: "/v1/" }
route:
weighted_clusters:
clusters:
- { name: api_v1_stable, weight: 90 }
- { name: api_v1_canary, weight: 10 }
# Header 匹配(按用户标签路由)
- match:
prefix: "/v2/"
headers:
- name: x-user-tier
string_match: { exact: "premium" }
route: { cluster: api_v2_premium }
# 重试 + 超时
- match: { prefix: "/payment/" }
route:
cluster: payment_cluster
timeout: 3s
retry_policy:
retry_on: "5xx,reset,connect-failure"
num_retries: 3
per_try_timeout: 1s
retry_back_off:
base_interval: 0.1s
max_interval: 1s
# 流量镜像(影子流量)
- match: { prefix: "/order/" }
route:
cluster: order_v1
request_mirror_policies:
- cluster: order_v2_shadow
runtime_fraction:
default_value: { numerator: 50, denominator: HUNDRED }
# 重定向
- match: { prefix: "/old/" }
redirect:
path_redirect: "/new/"
response_code: MOVED_PERMANENTLY
核心 L7 能力清单:
| 能力 | 配置位置 | 典型用途 |
|---|---|---|
| Prefix / Path / Regex 匹配 | match | 路径路由 |
| Header / Query 匹配 | match.headers, match.query_parameters | 灰度、A/B 测试 |
| Weighted Cluster | route.weighted_clusters | 金丝雀发布 |
| Timeout | route.timeout | 请求级超时 |
| Retry Policy | route.retry_policy | 失败重试 |
| Mirror | request_mirror_policies | 影子流量测试 |
| Rewrite | prefix_rewrite, regex_rewrite | URL 改写 |
| Hash Policy | route.hash_policy | 会话保持 |
| Direct Response | direct_response | 健康检查、维护页 |
| Rate Limit | rate_limits(配合 RLS) | 限流 |
5 Envoy Cluster 的服务发现类型与负载均衡策略有哪些?
答案:
Cluster 是上游服务的抽象,Envoy 通过 cluster.type 字段决定服务发现方式,通过 lb_policy 决定负载均衡算法。
服务发现类型:
| 类型 | 适用场景 | 说明 |
|---|---|---|
| STATIC | 测试环境 | Endpoint 写死在配置中 |
| STRICT_DNS | DNS 解析多 IP | 严格按 DNS 返回的 IP 列表,A 记录变化即刷新 |
| LOGICAL_DNS | 简单场景 | 只解析首次连接的 IP,长连接复用 |
| EDS | 生产环境(Istio/Envoy Gateway) | 通过 xDS 动态发现 |
| ORIGINAL_DST | 透明代理(iptables 重定向) | 转发到原始目标 IP |
负载均衡策略:
| 策略 | 说明 | 适用场景 |
|---|---|---|
| ROUND_ROBIN | 轮询 | 默认,均衡分发 |
| LEAST_REQUEST | 最少请求 | 请求耗时差异大 |
| RING_HASH | 一致性哈希 | 会话保持、缓存亲和 |
| MAGLEV | Google Maglev 哈希 | 大规模一致性哈希(更均匀) |
| RANDOM | 随机 | 无状态场景 |
| CLUSTER_PROVIDED | 委托给上游 | gRPC 服务自定义 |
| LOAD_BALANCING_POLICY_CONFIG | 插件化 | 自定义 LB |
配置示例:
clusters:
- name: user_service
connect_timeout: 1s
type: EDS
lb_policy: LEAST_REQUEST
eds_cluster_config:
eds_config:
ads: {}
service_name: user_service
# 健康检查
health_checks:
- timeout: 1s
interval: 5s
unhealthy_threshold: 3
healthy_threshold: 2
http_health_check:
path: "/healthz"
# 熔断
circuit_breakers:
thresholds:
- priority: DEFAULT
max_connections: 1024
max_pending_requests: 1024
max_requests: 1024
max_retries: 3
# 异常点检测(Passive 健康检查)
outlier_detection:
consecutive_5xx: 5
interval: 10s
base_ejection_time: 30s
max_ejection_percent: 50
6 Envoy 与 Nginx 的核心差异是什么?各自适用什么场景?
答案:
Envoy 与 Nginx 都是高性能代理,但设计目标、配置模型、可观测性差异显著。
| 维度 | Envoy | Nginx |
|---|---|---|
| 诞生背景 | 2016 Lyft,云原生设计 | 2004,传统 Web Server |
| 语言 | C++14 | C |
| 配置形式 | YAML/JSON + 动态 xDS | nginx.conf 文本 + reload |
| 动态配置 | 原生 xDS 热更新,零停机 | reload 重启 Worker(连接受影响) |
| HTTP/2/3 | 完整支持(含 gRPC、QUIC) | 商业版 Plus 支持较好 |
| L7 协议 | HTTP, gRPC, Dubbo, Thrift, Postgres, Redis, Kafka | HTTP, Mail |
| 可观测性 | 内置百级 stats、access log、tracing 集成 | 基础日志,stats 需第三方模块 |
| Service Mesh | Istio/Consul Connect 默认数据面 | 不适合 |
| 扩展性 | C++ Filter / Lua / Wasm 沙箱 | C 模块 / Lua (OpenResty) |
| 配置粒度 | 集群级动态推送 | 单实例配置文件 |
| 内存模型 | 单进程多线程 Worker(连接均分) | Master-Worker,fork 模型 |
| 生态定位 | 服务网格、API Gateway、Edge Proxy | Web Server、反向代理 |
适用场景:
| 场景 | 推荐 | 原因 |
|---|---|---|
| Service Mesh sidecar | Envoy | Istio/Linkerd 标配,xDS 动态配置 |
| K8s Ingress / Gateway | Envoy(Envoy Gateway、Istio Gateway) | Gateway API 原生支持 |
| 传统静态 Web 服务 | Nginx | 配置简单,资源占用低 |
| gRPC 代理 | Envoy | 原生 HTTP/2,gRPC-Web 转换 |
| 大规模动态后端(万级) | Envoy | xDS 增量推送 |
| 简单反向代理 + 静态文件 | Nginx | 成熟稳定,运维门槛低 |
**性能层面:**单连接吞吐 Nginx 略优,但 Envoy 在 HTTP/2 多路复用、长连接、动态变更场景下整体优势明显。
7 Envoy 在 Istio 中是如何工作的?xDS 由谁下发?
答案:
在 Istio 架构中,Envoy 以 Sidecar 形式注入业务 Pod,作为数据面承载所有进出 Pod 的流量;控制面 Istiod 负责生成 xDS 配置并下发。
架构示意:
Istiod (Control Plane)
/ | \
/ | \
xDS xDS xDS (gRPC ADS Stream)
/ | \
Pod A Pod B Pod C
[Envoy] [Envoy] [Envoy]
[App ] [App ] [App ]
流量劫持机制:
- Init Container 通过 iptables 规则将 Pod 入站/出站流量重定向到 Envoy 监听端口(15001 outbound,15006 inbound)
- 业务容器无感知,所有流量经 Envoy 处理后再发往真实目标
Istiod 的 xDS 职责:
- 监听 K8s API(Service、Endpoint、Pod、Namespace)
- 监听 Istio CRD(VirtualService、DestinationRule、Gateway、ServiceEntry、PeerAuthentication)
- 转换为 Envoy LDS/RDS/CDS/EDS/SDS 配置
- 通过 ADS gRPC 流推送至各 Sidecar
Istio CRD → Envoy 配置映射:
| Istio CRD | Envoy 配置 |
|---|---|
| Gateway | Listener + TLS Filter Chain |
| VirtualService | Route Configuration |
| DestinationRule | Cluster(LB 策略、熔断、TLS 上游配置) |
| ServiceEntry | Cluster + Endpoint |
| PeerAuthentication | Listener TLS Inspector + SDS |
| AuthorizationPolicy | RBAC HTTP Filter |
| Sidecar | Listener/Cluster 范围裁剪 |
调试命令:
# 查看 Sidecar 收到的配置
istioctl proxy-config listener <pod>
istioctl proxy-config route <pod>
istioctl proxy-config cluster <pod>
istioctl proxy-config endpoint <pod>
istioctl proxy-config secret <pod>
# 实时配置 dump
kubectl exec <pod> -c istio-proxy -- pilot-agent request GET config_dump
8 EnvoyFilter 是什么?它解决了什么问题?
答案:
EnvoyFilter 是 Istio 提供的扩展机制,允许在不修改 Istio 控制面代码的前提下,直接补丁式修改 Envoy 配置,是 Istio 高级定制的最后手段。
适用场景:
- Istio CRD 无法表达的 Envoy 原生能力(如自定义 HTTP Filter)
- 启用 Lua/Wasm Filter
- 添加自定义 Network Filter(如 Dubbo Proxy)
- 修改默认的 Listener/Cluster 参数(如开启 HTTP/3、调整连接池)
- 接入第三方组件(OPA、自研鉴权服务)
配置示例(添加 Lua Filter 改写响应头):
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
name: add-custom-header
namespace: istio-system
spec:
workloadSelector:
labels:
app: gateway
configPatches:
- applyTo: HTTP_FILTER
match:
context: GATEWAY
listener:
filterChain:
filter:
name: envoy.filters.network.http_connection_manager
subFilter:
name: envoy.filters.http.router
patch:
operation: INSERT_BEFORE
value:
name: envoy.filters.http.lua
typed_config:
"@type": type.googleapis.com/envoy.extensions.filters.http.lua.v3.Lua
inline_code: |
function envoy_on_response(response_handle)
response_handle:headers():add("x-custom-header", "from-envoyfilter")
end
核心字段:
| 字段 | 说明 |
|---|---|
| workloadSelector | 作用范围(哪些 Pod 生效) |
| configPatches.applyTo | 修改的 Envoy 配置类型(LISTENER/CLUSTER/ROUTE/HTTP_FILTER 等) |
| configPatches.match | 匹配条件(context: SIDECAR_INBOUND / SIDECAR_OUTBOUND / GATEWAY / ANY) |
| configPatches.patch.operation | 操作(ADD/MERGE/REMOVE/REPLACE/INSERT_BEFORE/INSERT_AFTER) |
使用风险与最佳实践:
- 强耦合 Envoy 版本,升级 Istio 时可能配置失效
- 配置错误会导致整个 Sidecar 崩溃(NACK 拒绝),影响业务流量
- 优先用 Istio 标准 CRD,无法满足时再用 EnvoyFilter
- 上线前必须在 Staging 环境验证,并配合
istioctl proxy-config校验
9 Envoy 的自定义 Filter 扩展方式有哪些?
答案:
Envoy 支持四种扩展方式:原生 C++、Lua、Wasm、外部 gRPC 服务,覆盖从高性能到快速原型的各类需求。
对比矩阵:
| 方式 | 性能 | 开发效率 | 安全性 | 部署 | 典型场景 |
|---|---|---|---|---|---|
| Native C++ Filter | 最高 | 低(需编译 Envoy) | 高(无沙箱) | 替换 Envoy 二进制 | 大型组织自研协议、超高性能场景 |
| Lua Filter | 中 | 高(脚本) | 中(沙箱有限) | 内嵌配置/SDS | 简单请求/响应改写 |
| Wasm Filter | 较高 | 中(C++/Rust 为主推且 production-proven;AssemblyScript/Go-tinygo 有显著限制,如 Go 编译 Wasm 需 syscall/js 假设 JavaScript host) | 高(Wasm 沙箱) | OCI 镜像分发 | 通用业务扩展、跨厂商 |
| External Processor (ExtProc) | 较低(gRPC 出网) | 高(任意语言) | 高(进程隔离) | 独立服务 | 鉴权、复杂业务逻辑 |
| External Auth (ExtAuthz) | 较低 | 高 | 高 | 独立服务 | 鉴权专用 |
Lua Filter 示例:
http_filters:
- name: envoy.filters.http.lua
typed_config:
"@type": type.googleapis.com/envoy.extensions.filters.http.lua.v3.Lua
default_source_code:
inline_string: |
function envoy_on_request(request_handle)
local headers = request_handle:headers()
if headers:get("x-bypass") == "true" then
request_handle:respond(
{ [":status"] = "403" },
"Forbidden by Lua filter"
)
end
headers:add("x-trace-id", os.time())
end
Wasm Filter 示例(加载远端 OCI 镜像):
http_filters:
- name: envoy.filters.http.wasm
typed_config:
"@type": type.googleapis.com/envoy.extensions.filters.http.wasm.v3.Wasm
config:
name: custom_auth
root_id: custom_auth
vm_config:
runtime: envoy.wasm.runtime.v8
code:
remote:
http_uri:
uri: https://registry.example.com/wasm/auth.wasm
cluster: wasm_registry
timeout: 5s
sha256: "abc123..."
External Auth 示例(对接 OPA/自研鉴权):
http_filters:
- name: envoy.filters.http.ext_authz
typed_config:
"@type": type.googleapis.com/envoy.extensions.filters.http.ext_authz.v3.ExtAuthz
grpc_service:
envoy_grpc: { cluster_name: ext_authz_cluster }
timeout: 0.5s
failure_mode_allow: false
选型建议:
- 业务侧扩展(鉴权、限流、灰度):External Auth + Wasm
- 性能敏感(每请求微秒级开销):Native C++
- 临时改写、PoC 验证:Lua
- 追求启动速度与极低开销(2024+):Dynamic Modules(Rust 官方 SDK,envoyproxy/dynamic-modules-examples,比 Wasm 更轻量,无需解释执行)
Dynamic Modules vs Wasm 对比:
| 维度 | Wasm Filter | Dynamic Module |
|---|---|---|
| 启动开销 | 需解释/编译 wasm | 原生 shared library,零开销 |
| 语言支持 | C++/Rust/Go-tinygo/AssemblyScript | Rust 官方,C++/Go 实验性 |
| 沙箱 | 强(wasm 沙箱) | 弱(无沙箱,进程内加载) |
| 适用场景 | 多租户/不可信插件 | 内部高性能扩展 |
| 引入版本 | Envoy 1.16+ | Envoy 1.30+ |
10 Envoy 是如何实现 mTLS 的?SDS 机制的作用是什么?
答案:
Envoy 通过 TLS Transport Socket 在 Listener 和 Cluster 两端实现 mTLS,证书通过 SDS(Secret Discovery Service)动态加载,避免本地存储和重启。
mTLS 双端配置:
下游 mTLS(客户端访问 Envoy):
listeners:
- name: ingress
address:
socket_address: { address: 0.0.0.0, port_value: 443 }
filter_chains:
- transport_socket:
name: envoy.transport_sockets.tls
typed_config:
"@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.DownstreamTlsContext
require_client_certificate: true
common_tls_context:
tls_certificate_sds_secret_configs:
- name: server_cert
sds_config: { ads: {} }
validation_context_sds_secret_config:
name: client_ca
sds_config: { ads: {} }
filters: [...]
上游 mTLS(Envoy 访问后端):
clusters:
- name: backend
transport_socket:
name: envoy.transport_sockets.tls
typed_config:
"@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.UpstreamTlsContext
common_tls_context:
tls_certificate_sds_secret_configs:
- name: client_cert
sds_config: { ads: {} }
validation_context_sds_secret_config:
name: server_ca
sds_config: { ads: {} }
sni: backend.svc
SDS 的核心价值:
| 痛点 | SDS 解决方案 |
|---|---|
| 证书内嵌配置文件,更新需 reload | gRPC 动态推送,零停机更新 |
| 私钥落盘风险 | 内存传递,可对接 SPIFFE/SPIRE 安全分发 |
| 证书轮转难 | 控制面定时签发,热加载 |
| 多 Envoy 同步难 | 集中下发,一致性强 |
Istio 中的 SDS 实现:
- Istiod 作为 CA 为每个 ServiceAccount 签发 SPIFFE 身份证书(
spiffe://cluster.local/ns/<ns>/sa/<sa>) - pilot-agent(Sidecar 进程)通过 UDS 暴露 SDS 接口,向 Istiod 申请证书
- Envoy 通过 UDS 拉取证书,证书每 24h(默认)自动轮转
- 通过 PeerAuthentication 控制 STRICT/PERMISSIVE/DISABLE mTLS 模式
典型故障排查:
# 查看 Sidecar 上的证书有效期、链路
istioctl proxy-config secret <pod> -o json | jq
# 验证 mTLS 连通性
istioctl authn tls-check <pod>.<ns>.svc.cluster.local
11 Envoy Gateway 是什么?它与 Istio Gateway 的差异是什么?
答案:
Envoy Gateway 是 Envoy 官方推出的 Kubernetes Gateway API 实现,目标是降低 Envoy 在 Ingress/Egress 场景的使用门槛,提供开箱即用的 K8s 原生网关。
核心特性:
- 原生实现 Kubernetes Gateway API(GatewayClass / Gateway / HTTPRoute / GRPCRoute / TLSRoute / TCPRoute / UDPRoute)
- 自包含部署:单 Helm Chart 即可,不依赖 Istio 控制面
- 通过 EnvoyProxy CRD 自定义底层 Envoy 行为
- 通过 ClientTrafficPolicy / BackendTrafficPolicy / SecurityPolicy 扩展 Gateway API
架构对比:
| 维度 | Envoy Gateway | Istio Gateway |
|---|---|---|
| 定位 | 专注 Edge / API Gateway | Service Mesh 入口 + 内部流量管理 |
| 依赖 | 独立运行 | 需 Istiod 控制面 |
| 配置模型 | Gateway API(标准) | Istio CRD(Gateway/VirtualService)或 Gateway API |
| 复杂度 | 轻量 | 完整 Mesh 能力 |
| 多协议 | HTTP/gRPC/TLS/TCP/UDP | HTTP/gRPC/TCP(含 Mesh 内服务) |
| mTLS | BackendTLSPolicy | 全自动 mTLS(含 Mesh 内部) |
| 可观测性 | EnvoyProxy 配置 + OTel | Istio 内建(Kiali、Jaeger 集成) |
| 典型场景 | 纯 K8s 入口网关 | 完整服务网格 |
典型配置:
# GatewayClass
apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata: { name: eg }
spec:
controllerName: gateway.envoyproxy.io/gatewayclass
# Gateway
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata: { name: prod-gw }
spec:
gatewayClassName: eg
listeners:
- name: https
protocol: HTTPS
port: 443
tls:
mode: Terminate
certificateRefs:
- { name: tls-secret }
# HTTPRoute
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata: { name: api }
spec:
parentRefs: [{ name: prod-gw }]
hostnames: ["api.example.com"]
rules:
- matches: [{ path: { type: PathPrefix, value: /v1 } }]
backendRefs: [{ name: api-v1-svc, port: 8080 }]
# 自定义 Envoy 参数
apiVersion: gateway.envoyproxy.io/v1alpha1
kind: EnvoyProxy
metadata: { name: custom-proxy }
spec:
provider:
type: Kubernetes
kubernetes:
envoyDeployment:
replicas: 3
resources:
requests: { cpu: 500m, memory: 512Mi }
选型判断:
- 仅需 K8s Ingress / API Gateway:Envoy Gateway
- 已有 Istio 或规划 Mesh:复用 Istio Gateway
- 多集群多 Mesh 治理:Istio Ambient + Gateway API
12 Envoy 的 Access Log 如何配置?支持哪些输出格式?
答案:
Envoy 内建 Access Log 子系统,支持 File、stdout、TCP/UDP、gRPC(ALS)多种 sink,支持文本与 JSON 双格式,覆盖丰富的请求生命周期字段。
File Sink + JSON 格式:
http_filters:
- name: envoy.filters.http.router
typed_config: { "@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router }
access_log:
- name: envoy.access_loggers.file
typed_config:
"@type": type.googleapis.com/envoy.extensions.access_loggers.file.v3.FileAccessLog
path: /dev/stdout
log_format:
json_format:
time: "%START_TIME%"
method: "%REQ(:METHOD)%"
path: "%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%"
protocol: "%PROTOCOL%"
response_code: "%RESPONSE_CODE%"
response_flags: "%RESPONSE_FLAGS%"
bytes_received: "%BYTES_RECEIVED%"
bytes_sent: "%BYTES_SENT%"
duration: "%DURATION%"
upstream_service_time: "%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%"
x_forwarded_for: "%REQ(X-FORWARDED-FOR)%"
user_agent: "%REQ(USER-AGENT)%"
request_id: "%REQ(X-REQUEST-ID)%"
authority: "%REQ(:AUTHORITY)%"
upstream_host: "%UPSTREAM_HOST%"
upstream_cluster: "%UPSTREAM_CLUSTER%"
关键格式化字段:
| 字段 | 含义 |
|---|---|
%START_TIME% | 请求起始时间 |
%DURATION% | 总耗时(毫秒) |
%REQUEST_DURATION% | 接收请求体耗时 |
%RESPONSE_DURATION% | 上游首字节耗时 |
%RESPONSE_TX_DURATION% | 发送响应到下游耗时 |
%RESPONSE_FLAGS% | 响应状态标记(UH/UF/UO/NR/DC/DI 等) |
%UPSTREAM_HOST% | 实际访问的上游 Endpoint |
%UPSTREAM_CLUSTER% | 上游 Cluster 名 |
%REQ(<header>)% | 请求头 |
%RESP(<header>)% | 响应头 |
Response Flags 故障排查速查:
| Flag | 含义 |
|---|---|
UH | 上游 Cluster 无健康主机 |
UF | 上游连接失败 |
UO | 触发上游熔断 |
NR | 无路由匹配 |
URX | 重试次数超限 |
DC | 下游连接中断 |
DPE | 下游协议错误 |
LH | 本地健康检查失败 |
RL | 触发 Rate Limit |
gRPC ALS Sink(集中式日志):
access_log:
- name: envoy.access_loggers.http_grpc
typed_config:
"@type": type.googleapis.com/envoy.extensions.access_loggers.grpc.v3.HttpGrpcAccessLogConfig
common_config:
log_name: ingress
grpc_service:
envoy_grpc: { cluster_name: als_cluster }
transport_api_version: V3
条件日志(仅记录异常):
access_log:
- name: envoy.access_loggers.file
filter:
status_code_filter:
comparison:
op: GE
value: { default_value: 400, runtime_key: access_log.min_status }
typed_config: {...}
13 Envoy 的 Metrics 与分布式 Tracing 如何接入?
答案:
Envoy 提供细粒度统计(数千个指标)和分布式追踪能力,原生支持 Prometheus、StatsD、Datadog、Dog StatsD 等指标 sink,以及 Zipkin、Jaeger、OpenTelemetry、Datadog、AWS X-Ray、SkyWalking 等 Tracer。
Prometheus 指标接入:
admin:
address:
socket_address: { address: 0.0.0.0, port_value: 9901 }
# 直接采集 /stats/prometheus
# curl localhost:9901/stats/prometheus
ServiceMonitor 示例:
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata: { name: envoy }
spec:
selector: { matchLabels: { app: envoy } }
endpoints:
- port: admin
path: /stats/prometheus
interval: 30s
核心指标分类:
| 类别 | 指标前缀 | 关键指标 |
|---|---|---|
| Listener | listener.* | downstream_cx_active, downstream_cx_total |
| HTTP | http.<stat_prefix>.* | downstream_rq_total, downstream_rq_2xx/4xx/5xx, downstream_rq_time |
| Cluster | cluster.<name>.* | upstream_rq_total, upstream_rq_time, upstream_cx_active, ejection_active |
| Server | server.* | memory_allocated, uptime, days_until_first_cert_expiring |
| xDS | cluster_manager.cds.* | update_attempt, update_success, update_failure |
Stats Sink 配置(推送式):
stats_sinks:
- name: envoy.stat_sinks.statsd
typed_config:
"@type": type.googleapis.com/envoy.config.metrics.v3.StatsdSink
address:
socket_address: { address: 127.0.0.1, port_value: 8125 }
Tracing 配置(OpenTelemetry):
tracing:
http:
name: envoy.tracers.opentelemetry
typed_config:
"@type": type.googleapis.com/envoy.config.trace.v3.OpenTelemetryConfig
grpc_service:
envoy_grpc: { cluster_name: otel_collector }
service_name: edge_envoy
http_filters:
- name: envoy.filters.http.router
typed_config:
"@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router
start_child_span: true
HCM 启用 Tracing:
http_connection_manager:
tracing:
random_sampling: { value: 100 } # 100% 采样
client_sampling: { value: 100 }
overall_sampling: { value: 100 }
custom_tags:
- tag: user.id
request_header:
name: x-user-id
- tag: env
literal:
value: production
Tracing 链路传播 Header:
- B3:
x-b3-traceid、x-b3-spanid、x-b3-sampled(Zipkin/Jaeger) - W3C Trace Context:
traceparent、tracestate(OpenTelemetry 标准) - Datadog:
x-datadog-trace-id、x-datadog-parent-id
Admin 接口实用端点:
| 端点 | 用途 |
|---|---|
/stats | 所有指标(文本) |
/stats/prometheus | Prometheus 格式 |
/clusters | Cluster 与 Endpoint 状态 |
/config_dump | 当前生效的全量配置 |
/listeners | Listener 列表 |
/server_info | 版本、运行状态 |
/runtime | 动态运行时参数 |
/hot_restart_version | 热重启版本 |
/healthcheck/fail | 主动摘流 |
/healthcheck/ok | 恢复健康 |
14 Envoy 在生产环境的性能调优有哪些关键点?
答案:
Envoy 生产性能调优需从 线程模型、连接池、缓冲区、xDS 推送、HTTP/2 参数 多维度综合调整。
线程与 CPU 绑定:
# 启动参数
envoy --concurrency 8 --cpuset-threads
--concurrency:Worker 线程数,建议等于 CPU 核数(K8s cgroup v2 中需显式设置而非依赖自动检测)--cpuset-threads:让 Envoy 感知 cpuset(注意:K8s cgroup v2 环境下不会自动适配,仍取 HW 线程数;参考 envoyproxy/envoy#36988,生产中需配合--concurrency显式指定)
连接池调优:
clusters:
- name: backend
connect_timeout: 1s
per_connection_buffer_limit_bytes: 1048576 # 1MiB
upstream_connection_options:
tcp_keepalive:
keepalive_probes: 3
keepalive_time: 30
keepalive_interval: 10
# HTTP/2 连接复用
typed_extension_protocol_options:
envoy.extensions.upstreams.http.v3.HttpProtocolOptions:
"@type": type.googleapis.com/envoy.extensions.upstreams.http.v3.HttpProtocolOptions
explicit_http_config:
http2_protocol_options:
max_concurrent_streams: 100
initial_stream_window_size: 65536
initial_connection_window_size: 1048576
# 熔断与连接上限
circuit_breakers:
thresholds:
- priority: DEFAULT
max_connections: 4096
max_pending_requests: 4096
max_requests: 65536
max_retries: 3
track_remaining: true
Listener 调优:
listeners:
- name: ingress
per_connection_buffer_limit_bytes: 1048576
socket_options:
- level: 1 # SOL_SOCKET
name: 9 # SO_KEEPALIVE
int_value: 1
state: STATE_PREBIND
- level: 6 # IPPROTO_TCP
name: 7 # TCP_DEFER_ACCEPT
int_value: 1
state: STATE_LISTENING
Overload Manager(过载保护):
overload_manager:
refresh_interval: 0.25s
resource_monitors:
- name: envoy.resource_monitors.fixed_heap
typed_config:
"@type": type.googleapis.com/envoy.extensions.resource_monitors.fixed_heap.v3.FixedHeapConfig
max_heap_size_bytes: 4294967296 # 4 GiB
actions:
- name: envoy.overload_actions.shrink_heap
triggers:
- name: envoy.resource_monitors.fixed_heap
threshold: { value: 0.85 }
- name: envoy.overload_actions.stop_accepting_requests
triggers:
- name: envoy.resource_monitors.fixed_heap
threshold: { value: 0.95 }
xDS 推送优化:
- 启用 Delta xDS:减少全量推送的带宽与 CPU
- 控制面侧合并推送(Debounce):Istio 默认 100ms PILOT_DEBOUNCE_AFTER
- Sidecar CRD 收敛配置:仅推送相关 Service,避免万级 Cluster 全推
- 启用 LDS/RDS On-Demand:按需加载
HTTP/2 与 gRPC:
- 后端 gRPC 建议设置
max_concurrent_streams: 100(默认无限可能压垮后端) - 启用 keepalive:避免 LB 长连接被中间设备断开
可观测性常用 SLI 指标:
| 指标 | 含义 | 告警阈值参考 |
|---|---|---|
cluster.<name>.upstream_rq_5xx | 上游 5xx 数 | 5xx 比例 > 1% |
cluster.<name>.upstream_rq_time | 上游耗时分位数 | p99 > SLA |
cluster.<name>.upstream_cx_overflow | 连接池溢出 | > 0 触发熔断告警 |
cluster.<name>.outlier_detection.ejections_active | 当前摘流 Endpoint | 持续 > 0 |
server.memory_allocated | 已分配内存 | > 80% limit |
cluster_manager.cds.update_rejected | CDS NACK 次数 | > 0 立即排查 |
通用最佳实践:
- 镜像版本固定:避免使用
latest,明确 Envoy 版本与 Istio 版本兼容性 - 配置变更灰度:先验证少量 Sidecar,再全量推送
- 启用 hot restart:避免重启导致连接中断
- 资源 request/limit 合理:CPU limit 易导致 throttle,建议仅设 request 或较大 limit
- Admin 接口仅监听 localhost:避免 9901 暴露
前沿:DPDK 集成(Envoy 1.27+ 实验性)
- DPDK(Data Plane Development Kit)用户态网络,绕过内核协议栈,μs 级延迟
- 适用场景:金融交易、低延迟网关、5G UPF 等
- 代价:与 K8s CNI 兼容性弱,非 K8s 部署更合适(裸金属/DPDK-aware 网卡)
- 通过
--base-id+ DPDK driver(如net_af_xdp)启用 - Envoy Gateway/Istio 默认不开 DPDK,高性能场景评估成本/收益后选用