总结使用 istio 常见的10个异常：

1. Service 端口命名约束

2. 流控规则下发顺序问题

3. 请求中断分析

4. sidecar 和 user container 启动顺序

5. Ingress Gateway 和 Service 端口联动

6. VirtualService 作用域

7. VirtualService 不支持 host fragment

8. 全链路跟踪并非完全透明接入

9. mTLS 导致连接中断

10. 用户服务监听地址限制

## 1. Service 端口命名约束

istio 支持多平台，不过 Istio 和 k8s 的兼容性是最优的，不管是设计理念，核心团队还是社区， 都有一脉相承的意思。但 istio 和 k8s 的适配并非完全没有冲突, 一个典型问题就是 istio 需要 k8s service 按照协议进行端口命名(port naming)。

端口命名不满足约束而导致的流量异常，是使用 mesh 过程中最常见的问题，其现象是协议相关的流控规则不生效，这通常可以通过检查该 port LDS 中 filter 的类型来定位。

### 原因

k8s 的网络对应用层是无感知的，k8s 的主要流量转发逻辑发生在 node 上，由 iptables/ipvs 来实现，这些规则并不关心应用层里是什么协议。

istio 的核心能力是对 7层流量进行管控，但前提条件是 istio 必须知道每个受管控的服务是什么协议，istio 会根据端口协议的不同，下发不同的流控功能（envoy filter），而 k8s 资源定义里并不包括七层协议信息，所以 istio 需要用户显式提供。

![](https://main.qcloudimg.com/raw/30af78c27ee7aef763b5f3122396929a.png)

### istio 的解决方案：Protocol sniffing

协议嗅探概要：

- 检测 TLS `CLIENT_HELLO` 提取 SNI、ALPN、NPN 等信息
- 基于常见协议的已知典型结构，尝试检测应用层 plaintext 内容 
a. 基于HTTP2 spec: Connection Preface，,判断是否为 HTTP/2 
b. 基于 HTTP  header 结构，判断是否是 HTTP/1.x
- 过程中会设置超时控制和检测包大小限制， 默认按照协议 TCP 处理

### **最佳实践**

Protocol sniffing 减少了新手使用 istio 所需的配置，但是可能会带来不确定的行为。不确定的行为在生产环境中是应该尽量避免的。

一些嗅探失效的例子：

- 客户端和服务端使用着某类非标准的七层协议，客户端和服务端都可以正确解析，但是不能确保 istio 自动嗅探逻辑认可这类非标准协议。比如对于 http 协议，标准的换行分隔是用 CRLF （`0x0d 0x0a`）, 但是大部分 http 类库会使用并认可 LF （`0x0a`）作为分隔。
- 某些自定义私有协议，数据流的起始格式和 http 报文格式类似，但是后续数据流是自定义格式：未开启嗅探时：数据流按照 L4 TCP 进行路由，符合用户期望 如果开启嗅探：数据流最开始会被认定为 L7 http 协议，但是后续数据不符合 http 格式，流量将被中断

建议生产环境不使用协议嗅探, 接入 mesh 的 service 应该按照约定使用协议前缀进行命名。

## **2. 流控规则下发顺序问题**

### **异常描述**

在批量更新流量规则的过程中，偶尔会出现流量异常（503），envoy 日志中 `RESPONSE_FLAGS` 包含「NR」标志(No route configured)，持续时间不长，会自动恢复。

### **原因分析**

当用户使用 `kubectl apply -f multiple-virtualservice-destinationrule.yaml`时，这些对象的传播和生效先后顺序是不保证的，所谓最终一致性，比如 VirtualService 中引用了某一个 DestinationRule 定义的子版本，但是这个 DestinationRule 资源的传播和生效可能在时间上落后于 该 VirtualService 资源。

![](https://main.qcloudimg.com/raw/bc19b9f1c1f7335647c173c0524a09f9.png)

### **最佳实践：make before break**

将更新过程从批量单步拆分为多步骤，确保整个过程中不会引用不存在的 subset：

当新增 DestinationRule subset 时，应该先 apply DestinationRule subset，等待 subset 生效后，再 apply 引用了该 subset 的 VirtualService。

当删除 DestinationRule subset 时，应该先 删除 VirtualService 中对 该 subset 的引用，等待 VirtualService 的修改生效后，在执行删除 DestinationRule subset。

## **3. 请求中断分析**

请求异常，到底是 istio 流控规则导致，还是业务应用的返回，流量断点出现在哪个具体的 pod？

这是使用 mesh 最常见的困境，在微服务中引入 envoy 作为代理后，当流量访问和预期行为不符时，用户很难快速确定问题是出在哪个环节。客户端收到的异常响应，诸如 403、404、503 或者连接中断等，可能是链路中任一 sidecar 执行流量管控的结果， 但也有可能是来自某个服务的合理逻辑响应。

### **envoy 流量模型**

Envoy 接受请求流量叫做 Downstream，Envoy 发出请求流量叫做Upstream。在处理Downstream 和 Upstream 过程中， 分别会涉及2个流量端点，即请求的发起端和接收端：

![](https://main.qcloudimg.com/raw/b94761b6b81f814fac0a0a706e09ab6c.png)

在这个过程中， envoy 会根据用户规则，计算出符合条件的转发目的主机集合，这个集合叫做 UPSTREAM_CLUSTER,  并根据负载均衡规则，从这个集合中选择一个 host 作为流量转发的接收端点，这个 host 就是 UPSTREAM_HOST。

以上就是 envoy 请求处理的 **流量五元组信息**， 这是 envoy 日志里最重要的部分，通过这个五元组我们可以准确的观测流量「从哪里来」和「到哪里去」。

- UPSTREAM_CLUSTER
- DOWNSTREAM_REMOTE_ADDRESS
- DOWNSTREAM_LOCAL_ADDRESS
- UPSTREAM_LOCAL_ADDRESS
- UPSTREAM_HOST

### **日志分析示例**

![](https://main.qcloudimg.com/raw/c1163db649915e36da76b88ecfe0dc69.png)

通过日志重点观测 2 个信息：

- 断点是在哪里 ？
- 原因是什么？

**示例一：一次正常的 client-server 请求**

![](https://main.qcloudimg.com/raw/b03b167d7c4bc7e617006fd288d2e56c.png)

可以看到 2 端日志包含相同的 request ID，因此可以将流量分析串联起来。

**示例二：no healthy upstream, 比如目标 deployment 健康副本数为 0**

![](https://main.qcloudimg.com/raw/973994db17c0df82eeffb1071addbf55.png)

日志中 flag「UH」表示 upstream cluster 中没有健康的 host。

**示例三：No route configured , 比如 DestinationRule 缺乏对应的 subset**

![](https://main.qcloudimg.com/raw/bfd149b67c2849447638a34a73f2a6e4.png)

日志中 flag「NR」表示找不到路由。

**示例四，Upstream connection failure，比如服务未正常监听端口。**

![](https://main.qcloudimg.com/raw/80f744e3c20d16fe279ed428bfaa1e25.png)

日志中 flag「UF」表示 Upstream 连接失败，据此可以判断出流量断点位置。

## **4. sidecar 和 user container 启动顺序**

### **异常描述**

Sidecar 模式在kubernetes 世界很流行，但对目前的 k8s （V1.17）来说，并没有 sidecar 的概念，sidecar 容器的角色是用户主观赋予的。

对 Istio 用户来说，一个常见的困扰是：sidecar 和用户容器的启动顺序：

sidecar（envoy） 和用户容器的启动顺序是不确定的，如果用户容器先启动了，envoy 还未完成启动，这时候用户容器往外发送请求，请求仍然会被拦截，发往未启动的 envoy，请求异常。

在 Pod 终止阶段，也会有类似的异常，根源仍然是 sidecar 和普通容器的生命周期的不确定性。

![](https://main.qcloudimg.com/raw/5ce2e6e634a70f2115b6fc13dffd811d.png)

### 解决方案

目前常规的规避方案主要是有这样几种：

- 业务容器延迟几秒启动,  或者失败重试
- 启动脚本中主动探测 envoy 是否ready，如 `127.0.0.1:15020/ healthz/ready`

无论哪种方案都显得很蹩脚，为了彻底解决上述痛点，从 kubernets 1.18版本开始，k8s 内置的 Sidecar 功能将确保 sidecar 在正常业务流程开始之前就启动并运行，即通过更改pod的启动生命周期，在init容器完成后启动sidecar容器，在sidecar容器就绪后启动业务容器，从启动流程上保证顺序性。而 Pod 终止阶段，只有当所有普通容器都已到达终止状态, 才会向sidecar 容器发送  SIGTERM 信号。

![](https://main.qcloudimg.com/raw/6e63c76a9f99e4886b6ca6a73825f9d3.png)

## 5. Ingress Gateway 和 Service 端口联动

Ingress Gateway 规则不生效的一个常见原因是：Gateway 的监听端口在对应的 k8s Service 上没有开启，首先我们需要理解 Istio Ingress Gateway  和  k8s Service 的关系：

![](https://main.qcloudimg.com/raw/25ece6976e3a4f4a2401ca325a59c960.png)

上图中，虽然 gateway 定义期望管控端口 b 和 c，但是它对应的 service （通过腾讯云CLB）只开启了端口 a 和 b，因此最终从 LB 端口 b 进来的流量才能被 istio gateway 管控。

- Istio Gateway 和 k8s Service 没有直接的关联，二者都是通过 selector 去绑定 pod，实现间接关联
- Istio CRD Gateway 只实现了将用户流控规则下发到网格边缘节点，流量仍需要通过 LB 控制才能进入网格
- 腾讯云 tke mesh 实现了 Gateway-Service 定义中的 Port 动态联动，让用户聚焦在网格内的配置。

## 6. VirtualService 作用域

VirtualService 包含了大部分 outbound 端的流量规则，它既可以应用到网格内部数据面代理中， 也可以应用到网格边缘的代理中。

VirtualService 的属性`gateways`用于指定 VirtualService 的生效范围：

- 如果 `VirtualService.gateways`为空，则 istio 为其赋默认值 `mesh`, 代表生效范围为网格内部
- 如果希望 VirtualService 应用到具体边缘网关上，则需要显示为其赋值：`gateway-name1,gateway-name2...`
- 如果希望 VirtualService 同时应用到网格内部和边缘网关上，则需要显示地把`mesh`值加入`VirtualService.gateways`， 如 `mesh,gateway-name1,gateway-name2...`一个常见的问题是以上的第三种情况，VirtualService 最开始作用于网关内部，后续要将其规则扩展到边缘网关上，用户往往只会添加具体 gateway name，而遗漏 `mesh`:

![](https://main.qcloudimg.com/raw/9b6e51587fc08d1c9f32dc780413bc45.png)

Istio 自动给`VirtualService.gateways`设置默认值， 本意是为了简化用户的配置，但是往往会导致用户应用不当，一个 feature 一不小心会被用成了 bug。

## 7. VirtualService 不支持 host fragment

### 异常案例

对某一 host 新增、修改 VirtualService，发现规则始终无法生效，排查发现存在其他 VirtualService 也对该 host 应用了其他规则，规则内容可能不冲突，但还是可能出现其中一些规则无法生效的情况。

### 背景

- VirtualService 里的规则，按照 host 进行聚合
- 随着业务的增长，VirtualService 的内容会快速增长，一个 host 的流控规则，可能会由不同的团队分布维护。如安全规则和业务规则分开，不同业务按照子 path 分开

目前 istio 对 cross-resource VirtualService 的支持情况：

- 在网格边缘（gateway），同一个 host 的流控规则，支持分布到多个 VirtualService 对象中，istio 自动聚合，但依赖定义顺序以及用户自行避免冲突。
- 在网格内部（for sidecar），同一个 host 的流控规则，不支持分布到多个 VirtualService 对象中，如果同一个 host 存在多个 VirtualService，只有第一个 VirtualService 生效，且没有冲突检测。

VirtualService 不能很好支持 host 规则分片，使得团队的维护职责不能很好的解耦，配置人员需要知悉目标 host 的所有流控规则，才有信心去修改 VirtualService。

### Istio 解决方案：Virtual Service chaining（plan in 1.6）

![](https://main.qcloudimg.com/raw/16a7a2834d1df39c707455fcf5053cea.png)

Istio 计划在 1.6 中支持 Virtual Service 代理链：

- Virtual Service 支持分片定义 + 代理链
- 支持团队对同一 host 的 Virtual Service 进行灵活分片，比如按照 SecOps/Netops/Business 特性分离，各团队维护各种独立的 Virtual Service

## 8. 全链路跟踪并非完全透明接入

### 异常案例

微服务接入后 service mesh 后，链路跟踪数据没有形成串联。

### **原因**

service mesh 遥测系统中，对调用链跟踪的实现，并非完全的零入侵，需要用户业务作出少量的修改才能支持，具体地，在用户发出（http/grpc） RPC 时， 需要主动将上游请求中存在的 `B3 trace headers`写入下游 RPC 请求头中，这些 headers 包括：

![](https://main.qcloudimg.com/raw/982253feb9bdc6217a8883d3252e8abe.png)

有部分用户难以理解：既然 inbound 流量和 outbound 流量已经完全被拦截到 envoy，envoy 可以实现完全的流量管控和修改，为什么还需要应用显示第传递 headers？

![](https://main.qcloudimg.com/raw/cff2624a07e56ae8fcbf1c834c8d4672.png)

对于 envoy 来说，inbound 请求和 outbound 请求完全是独立的，envoy 无法感知请求之间的关联。实际上这些请求到底有无上下级关联，完全由应用自己决定。举一个特殊的业务场景，如果 Pod X 接收到 请求 A，触发的业务逻辑是：每隔 10 秒 发送一个请求到 Pod Y，如 B1，B2，B3，那么这些扇出的请求 Bx（x=1,2,3...），和请求 A 是什么关系？业务可能有不同的决策：认为 A 是 Bx 的父请求，或者认为 Bx 是独立的顶层请求。

![](https://main.qcloudimg.com/raw/5a20680d5fc8a9b5426e49b7abc88a09.png)

## 9. mTLS 导致连接中断

在开启 istio mTLS 的用户场景中，访问出现 `connection termination` 是一个高频的异常：

![](https://main.qcloudimg.com/raw/7e8e74848770e3c23a8a6aced156997a.png)

这个异常的原因和 DestinationRule 中的 mTLS 配置有关，是 istio 中一个不健壮的接口设计。

- 当通过 MeshPolicy 开启全局 mTLS， 如果网格中没有定义其他的 DestinationRule，mTLS 正常运行
- 如果后续网格中新增了 DestinationRule，而 DestinationRule 中可以覆盖子版本的 mTLS 值(默认是不开启！), 用户在使用 DestinationRule 时，往往很少去关注 mTLS 属性（留空）。最终导致增 DestinationRule 后 mTLS 变成了不开启，导致`connection termination`
- 为了修复以上问题，用户不得不在所有 DestinationRule 中增加 mTLS 属性并设置为开启

![](https://main.qcloudimg.com/raw/833e91f3f9a22a8867ab15f65380451a.png)

这种 istio mtls 用户接口极度不友好，虽然 mtls 默认做到了全局透明， 业务感知不到 mtls 的存在， 但是一旦业务定义了 DestinationRule，就必须要知道当前 mtls 是否开启，并作出调整。试想 mtls 配置交由安全团队负责，而业务团队负责各自的 DestinationRule，团队间的耦合会非常严重。

## 10. 用户服务监听地址限制

### 异常描述

如果用户容器中业务进程监听的地址是具体ip (pod ip)，而不是`0.0.0.0`,  该用户容器无法正常接入 istio，流量路由失败。这是又一个挑战 Istio 最大透明化（Maximize Transparency）设计目标 的场景。

### 原因分析

Istio-proxy 中的一段 iptables:

![](https://main.qcloudimg.com/raw/36615a162f82186dab6bfcc22c668f44.png)

其中，ISTIO_IN_REDIRECT 是 virtualInbound, 端口 15006；ISTIO_REDIRECT 是 virtualOutbound，端口 15001。

关键点是规则二：如果 destination 不是127.0.0.1/32,  转给15006 (virtualInbound, envoy监听)，这里导致了对 pod ip 的流量始终会回到 envoy。

对该规则的解释：

> \# Redirect app calls back to itself via Envoy when using the service VIP or endpoint # address, e.g. appN => Envoy (client) => Envoy (server) => appN.

该规则是希望在这里起作用: 假设当前Pod a属于service A, Pod 中用户容器通过服务名访问服务A, envoy中负载均衡逻辑将这次访问转发到了当前的pod ip, istio 希望这种场景服务端仍然有流量管控能力. 如图示:

![](https://main.qcloudimg.com/raw/e23f9264b4a42fc7e8b846e5bcda8312.png)

### 改造建议

建议应用在接入 istio 之前， 调整服务监听地址，使用 `0.0.0.0` 而不是具体 IP。如果业务方认为改造难度大，可以参考之前分享的一个解决方案：服务监听pod ip 在istio中路由异常分析

ITPub博客

istio 常见的 10 个异常

最新文章