读 Envoy 配置的顺序

一句话总结

接收为监听器，通过过滤链，发送至路由选择的群集的端点。Envoy设置都是这五个单词的组合。

概念图: 监听器 · 过滤链 · 路由 · 群集

为什么需要这个？

Envoy设置JSON一看到就让人不知所措。但是结构很简单。进来的和出去的是一对。

概念	对应的东西	做的事情
Listener	nginx 的`server { listen }`	在哪个地址·端口接收？
Filter chain	nginx 的`location` + 模块	如何处理收到的东西
Route	nginx 的`location`匹配	选择要发送到哪个后端
Cluster	nginx 的`upstream`	后端套餐（包括政策）
Endpoint	upstream 的`server`一行	实际地址：港口

怎么行动

一个请求经过的路是这样的。

클라이언트
  → Listener (0.0.0.0:15001)
    → Filter chain (TLS 종료 → HTTP 커넥션 매니저)
      → Route (Host: shop.example.com, path /api/* )
        → Cluster (outbound|8080||shop.default.svc.cluster.local)
          → Endpoint (10.244.1.7:8080)   ← 로드밸런싱으로 하나 고름

核心是集群和端点是分开的。集群包含政策（负载平衡算法、连接池大小、异常检测、断路器），端点是那一刻的实际地址列表。即使出现故障和死亡，集群定义也保持不变，只有端点列表发生了变化。

xDS — 设置流动的通道

Envoy不会重新读取设置文件并重新启动。控制平面将推入gRPC流。每个类型都有名字。

弱者	送什么
LDS	Listener
RDS	Route
CDS	Cluster
EDS	Endpoint
SDS	证书(Secret)

通过Envoy的请求一个顺序。在收音机中接收并通过过滤链处理，如果路由选择后端，就会经过群集的政策到达一个端点。控制平面分别将LDS、RDS、CDS、EDS设置到这五个位置

Istio的istiod所做的事情正是这个。你们写的VirtualService被翻译成RDS，DestinationRule被翻译成CDS，服务的pad列表被翻译成EDS，然后推送到每个side卡。

因此，也确定了调查“修改了Istio设置但无法反映”的方法——查看侧卡实际收到的设置。

istioctl proxy-config route <pod>       # RDS 로 받은 것
istioctl proxy-config cluster <pod>     # CDS
istioctl proxy-config endpoint <pod>    # EDS

重新读VirtualService是没有用的。我们写的东西和代理收到的东西可能不同，差异就是原因。

无法读取设置时实际打开的窗口

邮件发送者的设置dump会输出数万行。如果试图全部读取的话，什么也得不到， 确定问题后，只拿出那个碎片。

curl -s localhost:15000/config_dump | jq '.configs[].dynamic_listeners[]?.name'
curl -s localhost:15000/clusters | grep -E "myapi|health"
curl -s localhost:15000/stats | grep -E "upstream_rq_(5xx|pending|timeout)"
curl -s localhost:15000/server_info | jq '.state'

统计数据首先回答了请求去哪里了。upstream_rq_5xx去的人变多了吗， upstream_cx_connect_fail有这个吗，pending根据堆积的情况，选择的地方会有所不同。接下来是读取设置。

**503的原因有很多种，响应标志可以区分它们。**在访问日志中 %RESPONSE_FLAGS%输入后会以一个字母的代码出现。

旗帜	意思
`UH`	那个群集里没有一个健康的对象。
`UF`	没能连接到上游
`UO`	电路断路器打开了，堵住了。
`NR`	没有正确的路线(route)
`URX`	触及了重新尝试的上限

这个一个字母区分了“设置错误”和“对象死了”。在访问日志中回复如果没有标志，在那个群集中会放一个503，继续猜测。

断路器的基本值一般太低了。max_pending_requests是1024人如果同时请求比那个多的话，上游还好，但发货就会被阻止。UO如果看到旗帜的话这就是这个位置。

如果设置看起来没有变化，请查看xDS。/stats的 *.update_rejected如果数量增加的话，控制平面发送的设置会被发件人拒绝。是。这时，Envoy 最后保持了成功设置，所以从外表上看什么都没有发生。对这个指标设置警报是非常有效的。

常见的误解

“侧车会导致请求延迟” — Envoy本身的延迟通常在毫秒以内。大部分感知延迟来自连接池设置、mTLS握手和重试设置。特别是重试在故障时会将负载增加几倍。

群集名称看起来很随机。outbound|8080||shop.default.svc.cluster.local是规则——방향|포트|서브셋|호스트. 如果subset为空，就表示不使用DestinationRule的subset。知道这个规则后，可以在设置dump中直接找到想要的行。

在实际工作中真正重要的东西

Envoy统计名称也有规则，那是障碍调查的指南。

cluster.<클러스터이름>.upstream_rq_5xx          백엔드가 낸 5xx
cluster.<클러스터이름>.upstream_rq_pending_overflow   커넥션 풀이 넘쳤다
cluster.<클러스터이름>.outlier_detection.ejections_active  쫓겨난 엔드포인트 수
listener.<주소>.downstream_cx_total             들어온 연결 수

upstream_rq_pending_overflow如果流量增加，并不是应用程序变慢，而是连接池太小。这两种情况的应对方法正好相反。