FI(注入错误故障)--Istio访问日志ResponseFlag重现与解析10

calendar Oct 7, 2023 · 1 min read · KubeCon 访问日志 ResponseFlags FI 演讲  ·
Share on: linkedin copy

KubeCon 2023在上海做的一个关于Istio访问日志的演讲《Detailed Parse and Reproduce Response Flags of Istio Access Log Based on Production Use Case》。解析和重现了在当时解决客户问题时碰到的各种应答日志。

第10个关注的Response Flag是DI，全称是FaultInjected，官方定义表示The request was aborted with a response code specified via fault injection.

含义：

FI 表示故障注入错误。通过VirtualService给目标服务注入了一个特定状态码的故障。在客户端的访问日志中会返回配置的HTTP状态码，并记录FI。

FI服务访问

重现环境：

  • 客户端Pod，注入了Sidecar。
  • 目标服务，一个Cluster类型的Kubernetes服务，多个服务实例。服务端Pod可以注入Siecar，也可以不用注入。

重现步骤：

第一步： 从注入了网格代理的客户端Pod中通过目标名和服务端口访问目标服务，观察代理的访问日志，得到正常的200响应码。从服务端和客户端的访问日志上都可以看到服务在目标服务的多个实例上负载均衡。正常访问参照本系列的环境部分描述。

第二步： 修改VirtualService，在路由上配置了一个HTTP状态码是418的模拟错误。

 1apiVersion: networking.istio.io/v1beta1
 2kind: VirtualService
 3metadata:
 4  name: nginx-80
 5  namespace: accesslog
 6spec:
 7  hosts:
 8  - nginx
 9  http:
10  - fault:
11      abort:
12        httpStatus: 418
13        percentage:
14          value: 100
15    route:
16    - destination:
17        host: nginx.accesslog.svc.cluster.local
18        subset: v1

第三步： 在客户端容器中还是使用原有方式访问目标服务，在客户端输出中会看到返回了418的状态码。原来正常返回200的目标服务未做任何修改，通过上一步VirtualService中注入418的状态码，在客户端就会得到对应的错误。

FI客户端访问

**第四步：**观察客户端访问日志中记录了418 FI，说明进行了故障注入

1[2023-08-20T14:38:38.690Z] "GET / HTTP/1.1" 418 FI fault_filter_abort - "-" 0 18 0 - "-" "curl/7.52.1" "1f085510-06de-439a-8b00-8bc2c1e3dc6a" "nginx.accesslog" "-" outbound|80|v1|nginx.accesslog.svc.cluster.local - 10.246.91.131:80 10.66.0.24:38616 - -

第五步： 不同于DI的场景，FI通过注入模拟了一个错误的应答。直接在客户端返回应答，请求没有发送到服务端，因此服务端没有流量，也没有记录访问日志。通过这种方式，就可以欺骗客户端应用程序，模拟目标服务返回任意的状态码。

应对建议

访问日志中记录了人为注入的故障，无需特殊处理。