跳转到内容

Envoy 面试题

14 道题
分类
Kubernetes
子分类
services-network
题目数
14 道
已阅读 0 / 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 FilterL4 协议处理(TCP Proxy、Redis Proxy、MongoDB Proxy)
HTTP Connection Manager (HCM)L7 HTTP 处理入口,挂载 HTTP Filter
HTTP FilterL7 协议处理(Router、JWT、Rate Limit、CORS、Lua、Wasm)
RouteURL/Header 匹配规则,路由到 Cluster
Cluster上游服务集合,承载负载均衡与健康检查
EndpointCluster 内的具体实例(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 子协议矩阵:

协议全称用途
LDSListener Discovery Service动态发现 Listener 配置
RDSRoute Discovery Service动态发现 HTTP 路由配置
CDSCluster Discovery Service动态发现上游集群
EDSEndpoint Discovery Service动态发现 Cluster 内的实例
SDSSecret Discovery Service动态发现 TLS 证书/密钥
ADSAggregated Discovery Service单流聚合上述所有协议,保证配置顺序
HDSHealth Discovery Service健康检查结果上报
VHDSVirtual 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 Clusterroute.weighted_clusters金丝雀发布
Timeoutroute.timeout请求级超时
Retry Policyroute.retry_policy失败重试
Mirrorrequest_mirror_policies影子流量测试
Rewriteprefix_rewrite, regex_rewriteURL 改写
Hash Policyroute.hash_policy会话保持
Direct Responsedirect_response健康检查、维护页
Rate Limitrate_limits(配合 RLS)限流
5 Envoy Cluster 的服务发现类型与负载均衡策略有哪些?

答案:

Cluster 是上游服务的抽象,Envoy 通过 cluster.type 字段决定服务发现方式,通过 lb_policy 决定负载均衡算法。

服务发现类型:

类型适用场景说明
STATIC测试环境Endpoint 写死在配置中
STRICT_DNSDNS 解析多 IP严格按 DNS 返回的 IP 列表,A 记录变化即刷新
LOGICAL_DNS简单场景只解析首次连接的 IP,长连接复用
EDS生产环境(Istio/Envoy Gateway)通过 xDS 动态发现
ORIGINAL_DST透明代理(iptables 重定向)转发到原始目标 IP

负载均衡策略:

策略说明适用场景
ROUND_ROBIN轮询默认,均衡分发
LEAST_REQUEST最少请求请求耗时差异大
RING_HASH一致性哈希会话保持、缓存亲和
MAGLEVGoogle 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 都是高性能代理,但设计目标、配置模型、可观测性差异显著。

维度EnvoyNginx
诞生背景2016 Lyft,云原生设计2004,传统 Web Server
语言C++14C
配置形式YAML/JSON + 动态 xDSnginx.conf 文本 + reload
动态配置原生 xDS 热更新,零停机reload 重启 Worker(连接受影响)
HTTP/2/3完整支持(含 gRPC、QUIC)商业版 Plus 支持较好
L7 协议HTTP, gRPC, Dubbo, Thrift, Postgres, Redis, KafkaHTTP, Mail
可观测性内置百级 stats、access log、tracing 集成基础日志,stats 需第三方模块
Service MeshIstio/Consul Connect 默认数据面不适合
扩展性C++ Filter / Lua / Wasm 沙箱C 模块 / Lua (OpenResty)
配置粒度集群级动态推送单实例配置文件
内存模型单进程多线程 Worker(连接均分)Master-Worker,fork 模型
生态定位服务网格、API Gateway、Edge ProxyWeb Server、反向代理

适用场景:

场景推荐原因
Service Mesh sidecarEnvoyIstio/Linkerd 标配,xDS 动态配置
K8s Ingress / GatewayEnvoy(Envoy Gateway、Istio Gateway)Gateway API 原生支持
传统静态 Web 服务Nginx配置简单,资源占用低
gRPC 代理Envoy原生 HTTP/2,gRPC-Web 转换
大规模动态后端(万级)EnvoyxDS 增量推送
简单反向代理 + 静态文件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 CRDEnvoy 配置
GatewayListener + TLS Filter Chain
VirtualServiceRoute Configuration
DestinationRuleCluster(LB 策略、熔断、TLS 上游配置)
ServiceEntryCluster + Endpoint
PeerAuthenticationListener TLS Inspector + SDS
AuthorizationPolicyRBAC HTTP Filter
SidecarListener/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 FilterDynamic Module
启动开销需解释/编译 wasm原生 shared library,零开销
语言支持C++/Rust/Go-tinygo/AssemblyScriptRust 官方,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 解决方案
证书内嵌配置文件,更新需 reloadgRPC 动态推送,零停机更新
私钥落盘风险内存传递,可对接 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 GatewayIstio Gateway
定位专注 Edge / API GatewayService Mesh 入口 + 内部流量管理
依赖独立运行需 Istiod 控制面
配置模型Gateway API(标准)Istio CRD(Gateway/VirtualService)或 Gateway API
复杂度轻量完整 Mesh 能力
多协议HTTP/gRPC/TLS/TCP/UDPHTTP/gRPC/TCP(含 Mesh 内服务)
mTLSBackendTLSPolicy全自动 mTLS(含 Mesh 内部)
可观测性EnvoyProxy 配置 + OTelIstio 内建(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

核心指标分类:

类别指标前缀关键指标
Listenerlistener.*downstream_cx_active, downstream_cx_total
HTTPhttp.<stat_prefix>.*downstream_rq_total, downstream_rq_2xx/4xx/5xx, downstream_rq_time
Clustercluster.<name>.*upstream_rq_total, upstream_rq_time, upstream_cx_active, ejection_active
Serverserver.*memory_allocated, uptime, days_until_first_cert_expiring
xDScluster_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-traceidx-b3-spanidx-b3-sampled(Zipkin/Jaeger)
  • W3C Trace Context:traceparenttracestate(OpenTelemetry 标准)
  • Datadog:x-datadog-trace-idx-datadog-parent-id

Admin 接口实用端点:

端点用途
/stats所有指标(文本)
/stats/prometheusPrometheus 格式
/clustersCluster 与 Endpoint 状态
/config_dump当前生效的全量配置
/listenersListener 列表
/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_rejectedCDS 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,高性能场景评估成本/收益后选用