Service Mesh独立面试题：Envoy、xDS、Istio与生产场景
本页只放标准回答、追问点和原理跳转，不用短答案替代完整学习。零基础先看 Service Mesh 主线，内部调用、源码语义、Demo、失败窗口和 Runbook 见 内部原理与生产治理。
一、架构与边界
| 问题 | 标准回答 | 追问与原理 |
|---|---|---|
| Service Mesh 是什么 | Service Mesh 把服务发现、路由、负载均衡、mTLS、重试、资源保护和遥测等通用通信能力下沉到控制面与数据面代理。它治理服务间通信，但不替代业务幂等、事务、用户权限和领域状态机。 | 定位与边界 |
| 为什么要引入 Mesh | 多语言微服务若都在 SDK 中实现治理，版本和行为很难统一；Mesh 可在基础设施层统一身份、路由和观测。代价是多一跳代理、控制面复杂度、配置传播窗口和新的故障域。 | 双链路模型 |
| 控制面与数据面有什么区别 | 控制面监听平台事实与策略，计算每个代理的目标配置并通过 xDS 下发；数据面按本地已接受配置处理真实连接和请求。普通请求通常不经过控制面。 | 控制面与数据面 |
| 控制面挂了业务会立刻中断吗 | 通常不会立刻全部中断，代理可继续使用 Last Known Good 和已有连接；但新端点、路由、策略和证书无法及时更新。随着代理重启、端点变化或证书到期，风险会逐渐扩大。 | ACK/NACK 与 LKG |
| 数据面代理挂了会怎样 | Sidecar 模式下，该 Pod 的入站或出站通常直接受影响；节点共享数据面下故障域可能扩大到节点上的多个工作负载。是否 Fail Open 取决于捕获方式和具体策略，不能一概而论。 | Sidecar 与 Ambient |
| Mesh 能实现 Exactly Once 吗 | 不能。代理在超时或 Reset 时不知道下游数据库是否已经提交；写接口仍需稳定幂等键、事实查询、状态机和补偿。Mesh 最多治理物理 Attempt，不能决定业务提交事实。 | 商业调用职责 |
| Mesh 与 API Gateway 有什么区别 | Gateway 主要处理南北向外部流量、用户认证、API 聚合和外部配额；Mesh 主要治理东西向服务通信、工作负载身份和内部路由。二者可以复用 Envoy，但职责与信任边界不同。 | 职责比较 |
| Mesh 与 Spring Cloud 怎么分工 | Spring Cloud 更接近 Java 应用，可做 Feign 调用、业务降级和客户端扩展；Mesh 适合多语言统一 mTLS、Endpoint 和代理遥测。叠加时必须明确 LB、超时、重试和熔断只由哪一层负责。 | Java 双基线与所有权 |
| Kubernetes Service 已经能负载，为什么还要 Mesh | Service 提供稳定寻址和平台层转发；Mesh 增加七层路由、工作负载 mTLS、细粒度授权、重试、异常实例检测和统一遥测。若系统不需要这些能力，也不必为了技术名词强行上 Mesh。 | Route/Cluster/Endpoint |
| Mesh 的主要成本是什么 | 增加代理 CPU/内存和网络跳点，增加 xDS、证书、连接和策略传播复杂度，还可能与 SDK 重复治理。生产必须建立代理容量、配置收敛、证书和业务事实的观测闭环。 | 观测闭环 |
| JDK 8 与 Java 17+ 会改变 Mesh 原理吗 | 数据面代理原理基本不依赖业务 JDK；差异主要在 Spring Cloud 发行列、Tracing、HTTP 客户端、Jakarta 命名空间和优雅停机接入。两条线都要避免客户端与 Sidecar 重复重试。 | JDK 版本边界 |
| 哪些系统不适合马上引入 Mesh | 服务数量很少、运维能力不足、极端延迟敏感且尚未压测、依赖大量特殊协议或现有治理已经稳定的系统，应先证明收益。Mesh 不是微服务成立的必要条件。 | 常见误区 |
二、Envoy 运行时与一次调用
| 问题 | 标准回答 | 追问与原理 |
|---|---|---|
| Envoy Listener、Filter Chain、Route、Cluster、Endpoint 的关系 | Listener 接受连接，Filter Chain 按 SNI/协议等选择连接处理链，HCM 解析 HTTP 后由 Route 选择逻辑 Cluster，Cluster 的负载均衡器再选真实 Endpoint。它们分别属于连接、HTTP 路由、逻辑上游和实例层。 | 对象分层、Route 分层 |
| Listener Filter 做什么 | Listener Filter 在网络 Filter 前提取连接元数据，例如 TLS Inspector 识别 SNI/ALPN，Original Destination 恢复透明重定向前目标。识别错误会导致选错 Filter Chain 或失去 HTTP 七层能力。 | Listener Filter |
| Filter Chain 匹配和 HTTP Route 匹配有什么区别 | Filter Chain 在连接阶段按地址、端口、SNI、Transport Protocol、ALPN 等匹配；Route 在 HTTP 已解析后按 Host、Path、Method 和 Header 匹配。TLS 成功但 Host 不匹配仍可能得到 NR。 | 匹配层次 |
| HCM 是什么 | HTTP Connection Manager 是 Envoy 的核心 HTTP 网络 Filter，负责协议编解码、路由、HTTP Filter、访问日志、Tracing 和 Stream 生命周期。Router Filter 通常在 HTTP Filter 链末端把请求交给上游。 | HCM 与过滤链 |
| Decoder Filter 与 Encoder Filter 顺序如何 | 请求通常按配置顺序经过 Decoder Filter，响应通常反向经过 Encoder Filter。Filter 可以继续、暂停异步等待、本地回复或 Reset，因此客户端收到错误不代表请求一定到过应用。 | Filter 调用顺序 |
| Envoy 是一个请求一个线程吗 | 不是。Envoy 主要用 Worker 事件循环处理大量连接和 Stream，连接通常在其生命周期内归属一个 Worker。同步阻塞 Filter 会拖慢同一 Worker 上的其他网络事件。 | 线程模型 |
| 为什么阻塞自定义 Filter 很危险 | 它不仅拖慢当前请求，还阻塞 Worker 处理其他 Socket 事件，引发 P99、超时和重试放大。应采用异步暂停/恢复，并设置超时、并发上限和取消逻辑。 | 阻塞后果 |
| Route 为什么不直接保存 Pod IP | Route 表达 HTTP 请求到逻辑服务的映射，Pod IP 由 Endpoint 独立变化。拆成 RDS/CDS/EDS 可让灰度路由和扩缩容分别更新，减小变更范围。 | 为什么分层 |
| Cluster 只是一个服务名吗 | 不是。Cluster 还包含服务发现、Endpoint、上游协议、TLS、连接池、Connect Timeout、LB、健康检查、异常实例检测和资源阈值。一个服务的不同 Subset 常映射成不同 Cluster。 | Cluster 内涵 |
| 一次出站 HTTP 调用完整流程是什么 | 连接被透明捕获后进入 Listener/Filter Chain，HCM 和 Decoder Filter 处理请求，Route 选 Cluster，LB 选 Endpoint，连接池复用或建连，mTLS 后发到服务方代理和应用，响应再反向经过 Filter。重试会生成新的物理 Attempt。 | 完整 17 步调用链 |
| HTTP/1.1 与 HTTP/2 连接池有什么区别 | HTTP/1.1 通常需要更多连接承载并发；HTTP/2 可在一个连接上复用多个 Stream。HTTP/2 降低握手成本，但会造成长连接倾斜，连接 Reset 也可能同时影响多个 Stream。 | 连接池 |
| Pod 从 Endpoint 删除后为什么仍有请求 | 可能是 EDS 尚未收敛、请求已选中该 Endpoint、HTTP/2 Stream 仍在途或旧连接正在 Drain。摘除通常阻止新选择，不等于立即杀掉所有既有连接。 | 旧连接窗口 |
| Envoy Circuit Breaker 是失败率断路器吗 | 通常不是。Envoy Cluster Circuit Breaker 主要限制连接、Pending、活动请求和并发重试等资源；Resilience4j 才常按失败率和慢调用率维护 CLOSED/OPEN/HALF_OPEN 状态。 | 资源熔断 |
| Overload Manager 和 Circuit Breaker 区别 | Circuit Breaker 多按上游 Cluster 限制资源，Overload Manager 根据代理自身内存、事件循环等压力采取全局自保动作。容器 OOMKill 是更晚、更粗暴的边界。 | 过载保护 |
| Envoy Response Flag 怎么用 | Response Flag 是代理访问日志里的失败阶段提示。同样是503，NR偏路由未匹配，UH偏无健康上游，UF偏连接或TLS失败，UO偏上游资源溢出，UT偏上游超时，URX偏重试耗尽。先确定哪个代理产生Flag，再沿Listener、Route、Cluster、Endpoint、TLS、连接池和业务事实排查。 | Response Flag速查、内部Flag原理 |
| Bootstrap 配置解决什么问题 | 它提供代理启动所需的根信息：Node 身份、控制面 Cluster、静态资源、动态资源来源和 Admin 地址。代理必须先知道如何连接 xDS，才能获取其他动态配置。 | Bootstrap |
| Node 身份写错会发生什么 | 控制面可能按错误集群、命名空间、网络或工作负载生成配置，导致服务不可见、路由或身份错误。配置语法可能完全合法，所以必须检查目标 Pod 的实际配置。 | Node 与裁剪 |
三、xDS、配置收敛与 Istiod
| 问题 | 标准回答 | 追问与原理 |
|---|---|---|
| xDS 是什么 | xDS 是 Envoy 动态配置 API 族，常通过 gRPC 双向流传输 Listener、Route、Cluster、Endpoint 和 Secret 等资源。它不是单个注册中心协议。 | xDS 资源 |
| LDS、RDS、CDS、EDS、SDS 分别是什么 | LDS 下发 Listener，RDS 下发 HTTP Route，CDS 下发逻辑 Cluster，EDS 下发 Cluster Endpoint，SDS 下发证书、私钥和信任根等 Secret。资源拆分是因为生命周期和变化频率不同。 | 资源分层 |
| DiscoveryRequest 主要带什么 | 它携带 Node、资源类型、订阅名称、客户端已接受版本、要确认的响应 nonce，以及 NACK 时的 error_detail。具体字段语义要区分 SotW 与 Delta。 | xDS 双向流 |
| DiscoveryResponse 主要带什么 | 它携带资源内容、资源类型、版本标识和本次响应 nonce。客户端校验后通过下一次请求回显 nonce 来 ACK/NACK。 | xDS 双向流 |
| Version 和 Nonce 有什么区别 | Version 表达客户端接受的资源状态，Nonce 关联控制面某一次具体响应。Version 可以是不透明哈希，不保证可按字符串大小比较；Nonce 不能代替资源版本。 | Version/Nonce |
| ACK 能证明配置全网生效吗 | 不能。它只证明一个代理接受某次响应，不证明其他代理、旧连接、真实 Route、Endpoint 健康、TLS 握手或业务事务都成功。 | ACK 边界 |
| NACK 后代理怎么办 | 代理通常携带 error_detail 回应，并继续使用 Last Known Good，避免错误配置立即清空生产流量。结果是代理间可能短暂版本分裂，所以要看版本分布。 | NACK 与 LKG |
| SotW 与 Delta xDS 区别 | SotW 响应通常表达某类资源整体目标集合；Delta 表达资源级新增、更新和删除，并维护每资源版本。二者的断线恢复和订阅状态不同。 | SotW/Delta 对比 |
| ADS 是什么 | ADS 把多种 xDS 资源放在同一有序双向流中，帮助控制面协调跨资源依赖。它不表示所有资源合成一个对象，也不表示网格只有一个全局版本。 | ADS |
| Listener Warming 是什么 | 新 Listener 依赖 RDS、SDS 或扩展配置时先处于 Warming，依赖就绪后才成为 Active；旧 Listener 可继续服务。这避免半初始化配置直接接流量。 | Warming |
| Cluster Warming 是什么 | 依赖 EDS 的 Cluster 通常需要取得初始 Endpoint 等初始化目标后才可用。否则 Route 虽引用 Cluster，却可能立即出现无健康上游。 | Cluster Warming |
| ACK 了为什么还可能 Warming | ACK 表示配置被接受，不一定代表所有初始化依赖已经完成并切为 Active。排障还要看 Active、Warming、Draining 状态和依赖资源。 | Warming 边界 |
| 配置已发布为什么只有部分 Pod 生效 | 可能是 Selector/可见性不同、部分代理断连或 NACK、代理版本不同、Warming 未完成，或旧连接仍在使用旧路径。应按目标代理查看 version、nonce、状态和真实请求。 | 失败窗口 |
| Istiod 怎样生成代理配置 | 它监听 Service、EndpointSlice、Pod 和 Mesh 策略，构建服务/端点/路由/身份模型，再按每个代理的身份、区域、可见范围和角色生成 xDS 资源。 | Istiod 编译链 |
| 为什么不同 Sidecar 的配置不一样 | 控制面会按命名空间、ServiceAccount、Labels、网络、地域、服务可见性、代理角色和版本裁剪配置。另一个 Pod 的 config_dump 不能证明当前 Pod 正确。 | 按代理裁剪 |
| Endpoint 变化一定触发全量 Push 吗 | 不一定。端点变化通常可缩小为 EDS 更新，路由或策略变化可能影响更广；全量/增量判定是具体 Istio 版本实现细节。应观察 Push 范围和控制面负载。 | Push 范围 |
| 控制面重连后如何恢复 | Envoy 重新建立流并声明已知版本/资源状态，控制面据此返回当前目标状态或增量差异。重连成功不代表业务已恢复，还要等待依赖、Warming 和 Endpoint。 | SotW/Delta 恢复 |
四、负载、健康、重试与超时
| 问题 | 标准回答 | 追问与原理 |
|---|---|---|
| Endpoint 选择只是 Round Robin 吗 | 不是。通常先处理 Priority、Locality、健康/降级状态、Panic 与异常剔除，再由具体 LB 算法选 Endpoint，最后进入连接池。 | Endpoint 选择链 |
| Priority 有什么作用 | Priority 表达主用与备用层级，可在高优先级健康容量不足时把流量逐步溢出到低优先级。它不是“P0 只要剩一个实例就永远承担全部流量”。 | Priority |
| Locality 解决什么 | 它按 Region/Zone/Sub-zone 做同区优先、加权和故障转移，降低延迟与跨区成本。全区故障时必须确保备用区有足够容量承接流量阶跃。 | Locality |
| Panic Mode 是什么 | 当健康 Endpoint 比例低于阈值时，Envoy 可能重新把更多 Host 纳入选择，避免候选集为空。常见默认阈值是 50%，但必须以部署版本和配置为准。 | Panic Mode |
| 为什么不健康实例还收到流量 | 可能进入 Panic Mode，也可能 EDS 尚未收敛、旧连接仍在途或该调用方未剔除该实例。应查健康比例、Panic 统计、代理版本与连接。 | Panic 与失败窗口 |
| Outlier Detection 是主动健康检查吗 | 不是，它主要根据真实请求结果做被动健康判断；主动健康检查则周期性探测。两者可以共同影响 Endpoint 可选状态。 | Outlier 原理 |
| Outlier Detection 为什么每个 Sidecar 结果不同 | 各 Sidecar 看到的请求样本不同，剔除是本地快速决策而非共识。全局摘除应改变 Endpoint/Readiness 等平台事实。 | 本地剔除 |
| 成功率剔除为什么需要最小样本 | 样本过小时随机波动很大，容易把正常实例误判。成功率算法通常需要足够 Host 数和每 Host 请求量，再结合统计偏差判断。 | 检测器边界 |
| Endpoint 反复异常时剔除多久 | 剔除时间通常从基础时长开始，连续异常时增长并受最大值限制，恢复后计数逐步衰减。精确公式和字段按 Envoy 版本确认。 | 剔除时间 |
| 重试应对哪些错误 | 只对连接失败、Reset、明确网关错误或协议定义的临时失败等有恢复概率的条件重试。业务校验 4xx 和非幂等写操作不能盲目重试。 | 重试引擎 |
| 重试次数是总次数还是额外次数 | Envoy 和 Istio 字段命名容易误读，通常重试数表示额外尝试，但必须按目标 API 版本确认，并用访问日志 Attempt 验收。容量模型应始终使用实际物理 Attempt。 | 重试计数 |
| Retry Host Predicate 做什么 | 它可避免重试立即选择刚失败的 Host；Retry Priority 可改变重试时的优先级选择。但只有一个 Endpoint 或共享故障时，换 Host 没有收益。 | 重试选 Host |
| Retry Budget 比固定次数好在哪里 | 它把允许的并发重试与当前请求规模关联，避免故障期间固定次数造成无界放大。仍需总 Deadline、退避、抖动和最大边界。 | Retry Budget |
| Hedging 和普通重试区别 | 普通重试通常等前一次失败后再发；Hedging 可在前一次仍在途时并发发第二次，以降低长尾。它会增加并发和重复副作用风险，只适合受严格幂等保护的场景。 | Hedging |
| Per-try Timeout 与总 Timeout 什么关系 | Per-try 约束一个物理 Attempt，总 Timeout 约束整个逻辑请求。所有 Attempt、退避和返回时间之和必须小于总预算。 | 超时预算 |
| Sidecar 超时能取消数据库事务吗 | 不能保证。代理可以 Reset/取消网络流，但应用线程、JDBC 查询或数据库事务可能已经继续并提交。调用方必须通过幂等键和事实查询处理结果未知。 | 取消边界 |
| 为什么多层重试会雪崩 | Gateway、Sidecar、Feign 和业务循环的次数会相乘，单个逻辑请求变成大量物理 Attempt。应集中重试所有权并观察 Attempt/逻辑请求比。 | 重试乘法 |
五、安全、流量捕获与 Ambient
| 问题 | 标准回答 | 追问与原理 |
|---|---|---|
| mTLS 解决什么 | 双方验证证书链和工作负载身份，并协商加密会话，解决服务间传输机密性、完整性和双向身份。它不等于用户级业务授权。 | mTLS |
| 为什么身份不能用 Pod IP | Pod IP 会随重建变化，也可能被复用；稳定身份应绑定信任域、命名空间、ServiceAccount 或工作负载，并放在证书 SAN 中验证。 | SDS 与身份 |
| SDS 做什么 | SDS 动态向代理提供证书、私钥和信任根，使业务代码不必直接管理私钥，并支持短期证书轮换。Secret 仍要经过校验和初始化后生效。 | SDS 轮换 |
| 证书轮换后旧连接会立即换证书吗 | 通常不会。证书在 TLS 握手时使用，新 Secret 主要影响新连接；已有连接可按原会话继续，因此验证轮换要同时检查 Secret 与新建连接。 | 连接与证书 |
| 根证书怎样安全迁移 | 先让双方同时信任旧根与新根，再签发新链证书，等待旧证书和连接有界退出，最后移除旧根。直接替换会形成双方信任不同步窗口。 | 根证书迁移 |
| STRICT 和 PERMISSIVE 区别 | STRICT 只接受符合 Mesh mTLS 的连接；PERMISSIVE 在迁移期兼容明文与 mTLS。STRICT 过早会阻断旧调用方，PERMISSIVE 长期保留会扩大明文窗口。 | 迁移模式 |
| Authentication 与 Authorization 区别 | Authentication 确认调用者身份，Authorization 判断该身份能否访问目标、端口、方法或路径。mTLS 认证成功不代表拥有退款权限。 | 授权分层 |
| 用户 JWT 和工作负载 mTLS 有什么区别 | JWT 通常证明用户或客户端 Claim，mTLS 证明服务工作负载身份，业务授权再判断订单归属和金额等领域条件。三层不能互相替代。 | 身份边界 |
| Sidecar 怎样透明捕获流量 | 常用 Pod 网络命名空间中的 iptables REDIRECT/TPROXY 或 eBPF，把入站和出站连接送到代理，同时排除代理自身和管理端口防止循环。 | 透明拦截 |
| REDIRECT 与 TPROXY 有什么区别 | REDIRECT 通过重定向把连接交给代理；TPROXY 可在特定场景保留原始地址语义，但需要策略路由、权限和内核能力，部署更复杂。 | 拦截模式 |
| 使用 eBPF 后还需要 Envoy 吗 | eBPF 可改变捕获、转发和内核观测，但不自动提供完整 HCM、HTTP Route、mTLS 身份和七层 Filter。是否需要代理取决于目标能力。 | eBPF 边界 |
| Ambient 的 ztunnel 做什么 | ztunnel 是节点级数据面，主要提供工作负载身份、安全隧道、L4 连接与基础遥测，不承担任意完整 HTTP 七层治理。 | Ambient 组件 |
| HBONE 是业务 HTTP 吗 | 不是。HBONE 是 Ambient 中基于 HTTP 的安全覆盖网络承载方式，业务协议可以是 HTTP、TCP 等，不能把覆盖隧道与业务 API 混为一谈。 | HBONE |
| Waypoint 做什么 | Waypoint 为已纳管的服务/命名空间提供 L7 路由、策略和遥测。不是所有 Ambient 流量天然经过 Waypoint，必须检查绑定和真实路径。 | Waypoint |
| Sidecar 与 Ambient 怎么选 | Sidecar L7 能力贴近每个 Pod、故障域较小但资源随 Pod 增长；Ambient 拆分 L4 与可选 L7，降低每 Pod 代理成本但共享故障域和策略路径不同。选型要按功能、成熟度和运维能力验证。 | Ambient 迁移 |
六、生产场景题
6.1 VirtualService 已发布，为什么只有一部分 Pod 生效
我会把链路拆成策略保存、Istiod 重算、xDS 发送、代理校验/Warming、ACK、旧连接 Drain 和真实请求七个阶段。先用
proxy-status找未同步或 NACK 的代理，再对目标 Pod 查 Route/Cluster/Endpoint；同时核对 Selector、服务可见性、代理版本和旧连接。控制面 API 返回成功不能证明全网实际分流完成。
原理：xDS 与 Warming · 失败窗口
6.2 Pod 已经 NotReady，为什么还有流量进入
我会检查 EndpointSlice 是否已移除、Istiod 是否重算、目标 Sidecar 的 EDS 是否更新，以及请求是否早已选中该 Endpoint。HTTP/2 既有 Stream 和 Drain 中连接可以继续完成；强制断开虽然切流更快，却会让在途写请求结果未知。正确做法是 Readiness 摘流、等待传播与 Drain，再有界退出。
原理：连接池与旧连接
6.3 扩容后流量仍集中在旧 Pod
先区分 EDS 是否已有新 Endpoint，以及负载均衡发生在连接级还是请求/Stream 级。大量 HTTP/2 长连接可能继续复用旧 Host，新 Pod 虽 Ready 却没有足够新选择；还要检查 Locality、权重、Slow Start 和一致性哈希。不能仅按 Pod CPU 判断 LB 失效。
原理：Endpoint 选择 · 连接池
6.4 上 Mesh 后下游故障时请求量反而更大
优先计算 Gateway、Sidecar、Feign、Resilience4j 和业务循环的重试乘积，查看 Attempt/逻辑请求比与 Retry Overflow。再检查总 Deadline、Per-try Timeout、退避、Hedging 和写接口幂等。把重试集中在最了解错误语义的一层，其他层关闭或共享预算。
6.5 多数 Endpoint 不健康但仍然收到请求
检查是否低于 Panic Threshold。Envoy 为避免候选集清空，可能重新将更多 Host 纳入选择；同时检查 Outlier 最大剔除比例、主动健康状态和 EDS。Panic 是可用性策略，不是健康检查失效，是否合适要按业务错误风险评估。
原理：Panic Mode
6.6 同一个库存 Pod，有的调用方成功、有的失败
按调用方 Sidecar 拆分实际 EDS、Locality、连接和 Outlier 状态。Outlier Detection 是本地样本驱动，不同代理可对同一 Endpoint 得出不同结论；也可能是节点网络、证书信任或旧连接的局部问题。不要先做全局重启掩盖证据。
原理：Outlier 本地性
6.7 证书轮换当天正常，第二天大量 TLS 失败
这常见于 SDS 轮换失败但旧证书尚未到期，或已有连接一直复用旧会话。应检查双方
/certs、Secret 同步、证书 SAN/信任根/到期时间、系统时间和新建连接握手；若在换根，还要确认双信任重叠窗口。
原理：SDS 与证书轮换
6.8 返回 503 NR 怎么查
先确定哪个代理产生响应，记录 Host/Authority、Path、SNI、端口和协议；再按 Listener → HCM → Virtual Host → Route 检查目标 Pod 的真实配置。重点看 RDS 是否同步、规则顺序、服务可见性和协议识别，不先查 Endpoint，因为 NR 发生在选 Cluster 之前。
原理：Response Flag · NR Runbook
6.9 返回 503 UH 怎么查
先从 Route 确认选中的 Cluster，再查 Cluster 是否 Active、EDS 是否为空、Subset Label 是否匹配、EndpointSlice/Ready、健康检查、Outlier、Priority、Locality 和 Panic。UH 表示没有可选健康上游，和 NR 的路由未匹配不是同一层。
原理：UH Runbook
6.10 返回 UF 或 TLS 握手失败怎么查
从调用方代理所在网络测试实际 Endpoint，检查监听端口、NetworkPolicy、节点网络、MTU 和 Conntrack；随后检查客户端 TLS 模式、服务方 STRICT/PERMISSIVE、证书链、SAN、信任根、到期时间和系统时钟。按 Endpoint/Node/Zone 拆分，定位局部故障。
6.11 Envoy 出现 UO 怎么处理
UO 常表示 Cluster 资源保护溢出。先查最大连接、Pending、活动请求和重试哪个计数触顶，再看下游延迟、连接池、HTTP/2 Stream 和重试风暴。直接提高阈值可能把压力转移给下游，必须结合真实容量和降级策略。
6.12 Sidecar CPU 很高但应用 CPU 正常
查短连接和 TLS 握手、高 Attempt 比、高基数统计、访问日志量、Tracing、自定义/Wasm Filter、Cluster/Endpoint 规模和事件循环延迟。再看 Overload Action。先消除重试风暴和配置膨胀，再调整 Sidecar 资源。
原理：代理过载 Runbook
6.13 灰度配置 5%，实际为什么不是精确 5%
权重表达选择概率或份额，不保证小样本精确；连接复用、一致性哈希、Locality、Header 定向和统计窗口都会造成偏差。应按足够请求样本、版本标签和业务结果验证，不能只看 YAML。
原理：灰度与连接
6.14 流量镜像为什么可能造成事故
镜像响应虽通常被丢弃，请求仍可能真实执行。若目标会扣库存、发短信或写支付，镜像就产生副作用；必须只读、隔离数据或在镜像环境显式禁用副作用，并与生产凭据隔离。
原理：流量镜像
6.15 Ambient 下 mTLS 正常但 Path 授权没生效
先确认目标服务是否真正纳入 Waypoint，以及流量是否经过可执行 L7 Policy 的路径。ztunnel 主要提供 L4 身份和隧道，不能假设它能检查所有 HTTP Path；还要检查策略绑定对象、API 版本和 Waypoint 配置同步。
原理：Ambient 运行链
七、面试中应会写出的排障命令
# 1. 先看控制面收敛
istioctl proxy-status
istioctl analyze -A
# 2. 再按目标Pod逐层检查真实配置
istioctl proxy-config listeners POD -n NAMESPACE
istioctl proxy-config routes POD -n NAMESPACE
istioctl proxy-config clusters POD -n NAMESPACE
istioctl proxy-config endpoints POD -n NAMESPACE
istioctl proxy-config secret POD -n NAMESPACE
# 3. 必要时检查Envoy运行事实
kubectl exec -n NAMESPACE POD -c istio-proxy -- \
curl -s http://127.0.0.1:15000/config_dump
kubectl exec -n NAMESPACE POD -c istio-proxy -- \
curl -s http://127.0.0.1:15000/clusters
kubectl exec -n NAMESPACE POD -c istio-proxy -- \
curl -s http://127.0.0.1:15000/certs不能只背命令。正确顺序是 Listener 是否接住 → Route 是否匹配 → Cluster 是否存在 → Endpoint 是否可选 → Secret 是否正确 → 连接/Attempt 如何变化 → 业务事实是否成功。完整解释见 Admin 与 Istio Runbook。
八、项目回答模板
我们把 Mesh 的职责限定为服务间工作负载身份、mTLS、Endpoint 发现、灰度路由、有界重试和代理遥测，业务幂等与事务仍在应用。Istiod 监听 Service/EndpointSlice 和策略，按每个代理身份生成 LDS/RDS/CDS/EDS/SDS；Envoy 校验并完成 Warming 后 ACK，NACK 时保留 Last Known Good。订单到库存调用先由 Listener/HCM 匹配 Route，再选 Cluster、Priority/Locality 和 Endpoint，通过连接池与 mTLS 发出。我们只在代理层保留一次受总 Deadline 约束的重试，订单号作为幂等键；发布按 proxy-status、真实 config_dump、版本流量、Attempt、P99 和业务流水逐步放量。故障时按 NR/UH/UF/UO/UT、Warming、EDS、证书、连接和业务事实逐层排查。
本章小结
高质量 Service Mesh 面试回答不能停在“Sidecar 拦截流量”。应能从 Istiod 的配置编译和 xDS 收敛，讲到 Envoy 线程、Filter、Route、Cluster、Endpoint、连接池、Panic、Outlier、Retry、SDS 与 Ambient；最后明确网络结果与业务提交事实的边界，并给出可执行取证顺序。