http: TLS handshake error from x.x.x.x:52493: read tcp x.x.x.x:30443->x.x.x.x:52493: read: connection reset by peer
单纯根据报错来看有点像证书问题，以及最后的connection reset by peer 连接被重置，一看就是报错的日志。
深入排查报错原因基于小编多年的排障经验，遇到自己看不懂的报错问题，优先Google 搜索下，看下是否有网上是否有类似文档：
没有Google 解决不了的问题，如果有，那有可能是你搜索姿势不对，换个姿势再试下。
Google 一如既往的给力，找到如下一篇比较符合情况的github 文档：
https://github.com/Tencent/bk-bcs/issues/32
可能有些朋友第一眼看到会有点蒙，这算是什么解答，bcs-api 和 tgw 是什么鬼？
别急，容小编来给你们捋一捋 。
bcs-api ：不知道是什么，那就暂时理解为一个 接口好了。
tgw：是腾讯内网网络架构中的一个重要的网关组件，与之同类型的是 stgw 组件，这两个组件有什么作用呢？网关嘛，肯定是管理内网出入信息的，同时这两个组件还具备一个功能 —— 请求分发 ，腾讯云的 CLB 产品就是依赖这两个组件来实现的，tgw 负责四层的请求分发，stgw 负责七层请求分发。
再回到集群维度来看下，我们知道，开启集群公网访问后，你去解析连接域名，这个时候解析出来的是腾讯云的一个公网地址，那么这个公网地址是用在什么设备上的呢？
没错，这里的公网访问入口，是使用腾讯云的 公网 CLB 来对接的，而且使用的是四层监听器。
理解这些，上面的问题是不是就有点思路了，我们找到的文档中说是tcp 探测产生的这些日志，CLB 也是有健康检查的，那会不会是CLB 健康检查产生的日志呢？
这个就需要咨询下 CLB 后台研发人员了，目前从官网文档介绍来看，我们只知道四层udp 监听器健康检查方式是ping 探测 ，tcp 监听器使用 SYN 包进行探测的方式 ，七层是 HEAD/GET 的健康检查方式。
官网文档：https://cloud.tencent.com/document/product/214/6097
最终结论：tcp 健康检查报文 关闭的时候就是用RST报文关闭的
为了减少TIME-WAIT状态
所以用户后端服务会看到异常关闭的请求
当前云上四层探测1）UDP是用PING探测，源IP是负载均衡的VIP
2）TCP采用CONNECT+RST关闭方式进行探测，源IP是负载均衡的VIP
疑问：根据说明，健康检查的源IP 是负载均衡的VIP ，但是为什么日志中打印出来的源IP 不固定，查看都是master主机内网IP 。
解答：因为apiserver 是部署在pod 内的，pod 运行在master 主机上，所以健康检查到达pod 需要经过master主机这层代理，所以这里看到的源IP 地址是 master 主机的。