UF(上游连接失败)--Istio访问日志ResponseFlag重现与解析03

KubeCon 2023在上海做的一个关于Istio访问日志的演讲。解析和重现了在当时解决客户问题时碰到的各种应答日志。

第三个关注的Response Flag是UF，UF的全称是 UpstreamConnectionFailure ，官方定义表示"Upstream connection failure in addition to 503 response code."

含义：

表示上游连接失败。典型场景如目标服务的服务端口不通。如客户端通过错误的端口访问目标服务时，会导致客户端的服务访问失败，客户端代理的Outbound日志会记录503UF。

目标服务的服务实例端口不通，会导致服务端的服务访问失败，同时目标服务端代理的Inbound日志会记录503UF。我们构建一个服务不通客户端Outbound日志记录UF，服务端inbound 日志的503 U后面的在另外一个URX用例里可以看到，综合起来可以更完整理解UF的含义和出现场景。

重现环境：

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

重现步骤：

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

第二步： 在第一个正常访问的用例基础上修改服务端口为错误的服务端口888。

 1apiVersion: v1
 2kind: Service
 3metadata:
 4  name: nginx
 5  namespace: accesslog
 6spec:
 7  ports:
 8  - name: http
 9    port: 888  # Modify service port 80->888，make service request failed
10    protocol: TCP
11    targetPort: 80
12  selector:
13    app: nginx
14  type: ClusterIP

第三步： 在客户端容器中curl 目标服务端口80，curl命令返回503，错误信息包括：upstream connect error or disconnect/reset before headers. reset reason: connection failure 。

第四步： 观察客户端容器的访问日志出现503 UF。

1[2023-08-19T08:10:17.447Z] "GET / HTTP/1.1" 503 UF upstream_reset_before_response_started{connection_failure} - "-" 0 91 10001 - "-" "curl/7.52.1" "819fb0d7-1ae1-4689-b10a-394a0a53c546" "nginx.accesslog" "10.246.91.131:80" PassthroughCluster - 10.246.91.131:80 10.66.0.24:60926 - allow_any

第五步： 因为客户端代理连接不到目标上游服务，因此请求不会发出去，服务端代理不会有流量，服务端不会记录本次请求的访问日志。

应对建议：

检查服务定义，确保服务（或服务实例的）端口配置正确，客户端通过正确的端口访问目标服务。