守株阁

一次 HTTP 调用可以经过不止一段连接 orders 请求 inventory 看上去只有一个 URL，实际却可能经过 orders 应用 → 本地出站代理 → 网络 → inventory 入站代理 → 库存应用。Istio 的工作负载 mTLS 验证的是代理之间的连接与身份；应用到同 Pod 代理、代理到本地应用的段仍要分别确认。把“服务之间启用了 mTLS”简写成“每个字节在每一段都加密”会遗漏这两段。第 09 篇的应用自己提供 TLS 的演示也不是此处代理 mTLS 的验收。 服务端 PeerAuthentication 决定入站能接受什么连接：PERMISSIVE 同时接受明文和 mTLS，STRICT 要求 mTLS。客户端代理是否真的发起 mTLS，则要看出站配置、目标是否识别为网格工作负载，以及是否存在显式 DestinationRule；不能只看服务端策略推断客户端行为。自动 mTLS 是在合适的发现和配置条件下帮助客户端选择 mTLS，不代表任意网外目标都自动升级。 先固定连接段，再讨论拒绝 在隔离命名空间中，只给 inventory 设置有明确工作负载 ...

Pod 的名字不是它在网格中的身份 orders → inventory 需要回答的问题不是“库存 Pod 的 IP 是什么”，而是“连接对端以什么身份出现，以及谁担保了这个身份”。Pod IP、Deployment 名称和容器镜像都可能变化；在 Istio 的 Kubernetes 部署中，工作负载通常以命名空间和 ServiceAccount 表示身份。典型的 SPIFFE 形式是 spiffe://<trust-domain>/ns/<namespace>/sa/<service-account>。例如实验信任域为 cluster.local、命名空间为 service-mesh-lab 时，orders 和 inventory 若使用不同 ServiceAccount，就应呈现不同的身份；cluster.local 是示例值，不是所有集群固定使用的值。 身份字符串与证明身份的凭据不是一回事。创建 Pod 时指定 ServiceAccount 是期望身份；实际代理获得并使用的短期 X.509 证书、证书链和对端在握手时的验证结果，才是另一...

100 毫秒后客户端放弃，库存服务是否停止 frontend → orders 调用链（orders 先调用 inventory，成功后再调用 external-stub） 有一个容易混淆的事实：客户端不再等待，不推出每个上游都没有开始、没有完成，更不表示已提交的业务写入被撤销。第 01 篇的合成账本已经显示写入后延迟响应可使客户端超时而账本仍有一条记录。本篇改用同一应用的完整只读调用链，观察取消在哪一跳产生后果。 图中时间轴表示进程实验的既定等待条件，不是 Envoy 各种超时的默认值：inventory 收到请求后 time.Sleep(350ms)，随后尝试写出 HTTP 200；客户端 curl --max-time 0.1 在先前退出。orders 使用入站请求的 context 创建下游请求，因此取消可阻止接下来访问 external-stub；inventory 的演示 handler 没有在睡眠时检查 request.Context().Done()，会在客户端退出后继续运行到日志记录处。日志记录了应用处理步骤，不能保证取消后的响应字节被客户端实际收到。 五个计...

HTTPRoute 没有 Gateway，也能作用于 Service 吗 前提是实现支持 Gateway API 的网格路由能力（GAMMA），不是“集群安装了 HTTPRoute CRD”就自动生效。第 06 篇的五层证据仍适用：提交 HTTPRoute、检查控制器接受与关联状态、查代理当前 route/cluster、观察真实请求经过哪条代理路径、核对库存服务的版本和请求 ID。控制面不处于普通 orders → inventory 请求的转发链上。 与入口流量附着到 Gateway 不同，网格中的 HTTPRoute 通过 parentRefs 指向 Kubernetes Service，例如 inventory 的端口 8080。parentRefs 回答“哪条 Service 流量可受此规则影响”，backendRefs 回答“命中后转发到哪个目标”；前者不是后端 Pod 列表，后者也不表示调用者身份。通过目标应用日志的同一请求 ID 才能核对后端版本，不能只看对象 Accepted=True。 放在哪个命名空间，改变了谁受影响 Gateway API 网格概览将与目...

两个库存 Pod 都健康，为何一个更忙 先区分问的是外部请求数、代理选择次数、上游新连接数，还是库存实际处理次数。第 10 篇的 50/50 权重是路由目标，不能从 10 次样本推断每台必处理 5 次。即使 v1/v2 都在候选列表，长连接、HTTP/2 复用、端点权重、请求耗时、健康状态和 locality 优先级都会改变计数；有重试时一次用户请求可能对应多次后端尝试。 对于请求从 orders 到 inventory 的路径，可能先经过 Kubernetes Service 的连接级目标选择，再经过网格代理的 cluster 选址，具体取决于实际透明接管及协议模式。不能把某一个实现的“轮询”机械地套用到每个 HTTP 请求：先拿到相关 listener/route/cluster 的活跃配置及连接/请求日志，再确定正在讨论哪一层的选址。 选择时刻决定了统计含义 客户端只维持一条被 Service 转发到旧 Pod 的 TCP 连接时，后续复用该连接的请求可能持续命中旧实例；扩容引入新实例主要影响后续新建连接。Envoy 对其上游 cluster 的具体负载均衡与连接池调度另...

“10% 给 v2”是路由意图，还是已发生的调用比例 同一服务链中的 inventory-v1、inventory-v2 返回各自版本标识；第 06 篇已拆开规则声明与代理执行。现在发布 v2：先让带 x-canary: yes 的合成请求稳定到 v2，再测试不带头时按权重选择 v1/v2。Subset 属于后端实例分类，匹配条件属于请求分类，权重属于某条 route 下的目标比例；三者不能写成一项配置。读者应能区分提交的权重、代理选择次数、后端处理次数与最终客户端成功次数。 图的第一步是请求匹配：若顺序靠前的规则匹配 canary 头，就不再按照后续默认权重规则选择；否则才进入默认路由。v1/v2 subset 必须与实际工作负载的版本标签一致，而不是只看 Deployment 名或镜像 tag。 路由规则、端点与观测单位 在 Istio 风格的配置中，DestinationRule 可给 inventory 定义 v1/v2 标签集合，VirtualService 可按 URI/请求头选目标及配置权重。只有当请求的 host、端口、header 落在相应 VirtualSe...

客户端说的是 HTTP，代理看得到路径吗 orders 要把 sku=paper 请求送到库存服务：应用协议、连接的传输加密、代理是否能看见请求路径，是三个独立问题。第 03 篇中的 route 要求 Envoy 能读 HTTP 的 host/path；若所见的只是透传 TLS 密文，代理可以依据连接层可见信息决定去向，但不能凭空读取加密后的 /quote。本篇先用同一个 inventory-v1 实测 TLS 主机名校验和 ALPN，再说明 HTTP/2、gRPC 与 TLS 终止/透传的边界；未声称已运行 sidecar 协议识别。 图中的 SNI 是 TLS 握手给服务器提示的名称，ALPN 是协商应用协议的扩展；它们不等于 HTTP Host、gRPC method 或最终用户 JWT。代理只有在终止相应 TLS 连接并解析上层协议时，才可能按 HTTP 路径或 gRPC 请求元数据作七层治理。TLS 透传和 HTTP 路由适用于不同可见范围。 两条连接不一定采用同一协议 调用方到代理是下游连接，代理到后端是上游连接。客户端至入口网关可以 TLS 终止后以另一条连接转发...

DNS 回答没变，为什么请求的后端变了 第 02 篇区分 Service ClusterIP 与 Pod 端点；第 07 篇又增加了代理配置更新。现在让 inventory-v1 下线并增加 inventory-v2：DNS 仍可能答复同一个 Service 入口，而候选端点和代理路由的上游集合发生变化。若应用保留旧连接，某些请求继续打到旧实例；不能用一次 nslookup 的结果解释全部流量。 图中标了两条控制/发现线和一条业务连接线：应用查询 Service DNS；Kubernetes EndpointSlice 描述当前后端；网格控制面可能将相应服务发现变化下发给代理；实际 TCP 连接建立后又有独立生命周期。Istiod 不是业务请求转发节点。 三种“地址”不要混用 应用地址是 inventory 这个主机名加业务端口。普通 ClusterIP Service 的 DNS 回答通常指向稳定虚拟 IP，而不是此次选中的 Pod。EndpointSlice 存放候选后端地址及条件，节点 Service 数据面依据这些资源选择新连接的目标；网格的 Envoy 也可能拥有经控...

ACK 到了，为什么这条请求仍走旧路由 第 06 篇区分路由声明、Istiod 处理、代理状态和实际请求。现在要观察代理同控制面协商资源的过程：Envoy 对一次 xDS 响应确认（ACK），究竟确认了什么？路由（RDS）可能引用 cluster（CDS），cluster 可能引用端点集合（EDS）；更新不是把一份“最终 YAML”原子广播给所有代理。适合已经认识 listener、route、cluster、endpoint 的读者。 图里的 ACK/NACK 属于特定流和资源类型的控制反馈；图下方的请求沿代理活跃配置执行。两条时间线需要同一代理标识和时间戳连接，不能把 Istiod 画在普通业务请求的中途。 ACK/NACK、资源依赖分别约束什么 控制面可使用聚合发现服务 ADS 在一个 gRPC 流内交换多类发现资源。SotW（state of the world）响应提供相应订阅范围的一组当前资源；Delta xDS 按增量订阅和新增/移除表达变化，两者资源版本的含义和删除方式不能机械套用。具体使用哪种模式须读取实际代理/控制面的协商与日志，不因文档提供两种协议就断言当...

声明“给 v2 一部分流量”以后，谁真正执行 前面已建立 frontend → orders → inventory-v1 / inventory-v2 的服务链，并在 第 03 篇拆开独立代理的 route、cluster 与 endpoint。sidecar 模式下，应用继续用原来的上游地址，配置却需要从 Kubernetes 资源变成 orders 旁的 Envoy 可执行的路由。Istiod 负责观察和生成配置，不是业务请求必经的转发节点。读者需要知道 Service 与 Envoy route 的不同，并能用请求 ID 定位实际库存实例。 这张图中上方为控制路径，下方为请求路径；两个箭头不能合并。“资源已提交”“代理已确认”“配置已存在”“本次请求匹配”是四种不同命题。 五步收集证据 声明：VirtualService 表达匹配/路由意图，DestinationRule 可定义 v1/v2 subset；分别核对资源的 generation、host、port、规则所在作用域、子集标签。API 接受对象，只证明资源提交成功。错误 host 或不匹配的请求头即使语法合...