记一次迁移到istio gateway后502问题排查

背景

我们目前架构从ingress-controller迁移到istio-gateway后，出现了两次服务出现502的情况。

• A服务调用B服务，出现502
• 三方服务回调我方域名，出现502

场景说明

• 场景1
  AB服务在同一个k8s集群，架构是nginx+php，A服务配置了proxy_pass到B服务

location /api/ {
    proxy_pass https://api.dgsfor.com/;
    proxy_set_header Host "api.dgsfor.com";
}

• 场景2
  三方服务(可以认为是百度等平台)回调我方C服务，三方服务反映结果502

初步思路

正常502，我们都会优先怀疑到服务端是不是有问题，比如最大进程数、request_timeout、数据库、进程挂了等等。
所以我们优先看日志。

假设我方服务是：https://api.dgsfor.com/v1/callback.

场景1排查

1. 查看B服务nginx 日志，发现异常

2021/12/01 11:19:37 [error] 44#0: *255 peer closed connection in SSL handshake (104: Connection reset by peer) while SSL handshaking to
 upstream, client: 10.18.33.71, server: api.dgsfor.com, request: "GET /api/ HTTP/1.1", upstream: "https://x.x.x.x:443/",
host: "api.dgsfor.com"

2. 可以判断是证书错误，手动curl测试了一下发现正常

curl -vvv "https://api.dgsfor.com/v1/callback"

3. 初步判断是SNI有问题，直接抓包看看

抓包结果发现 HelloClient 没有 SNI Extension，因此 gateway RST 连接，直接导致502

4. 开启sni extension

nginx+php模式，需要配置proxy_ssl_server_name on;，才会SNI 扩展。

5. 开启后正常

场景2排查

有了场景1的思路，我们优先怀疑是不是sni的问题，所以直接把三方回调地址改成http，发现直接可行了，那么没跑了，又是sni的异常。

1. ingress-controller可以，istio-gateway不可以

为什么之前使用ingress没有这个问题，istio-gateway不可以

2. 抓包看看吧，先抓使用ingress时候的包

看Server Hello，发现是有一个默认的sni，是ingress下发的。

3. 抓包看看吧，继续抓使用istio-gateway时候的包

最终结果是没有抓到，在helloClient就rst了。

总结

通过上述可以得到的结论是，

• ingress-controller在客户端没有配置sni的情况下，会下发一个默认的sni，istio-gateway没有默认下发。
  

• 建议调用方都主动配置sni