一次APISIX网关503的曲折排查（DNS篇）

最近我们内网的k8s集群做了一次升级，发现经过APISIX网关服务都503异常了，于是做了一次分析。排查过程比较曲折，情感上多次起伏，各位看官耐心看完。

APISIX是功能强大、易于使用的开源API网关，是我们微服务体系中的重要一环。经过APISIX网关的流量异常，将会对整个微服务体系造成较大影响。

我们先来简单回顾下APISIX网关的架构：

• API网关对外提供了一个统一的入口，对外的所有请求都先经过API网关。
• API网关包含了一个Ingress控制器，这个控制器监听外部的HTTP/HTTPS请求，并将请求转发给后端的微服务。
• API网关还包含了一个路由模块，这个模块负责将请求转发到正确的微服务。

在分析问题的过程中，我们多次陷入思维误区，走了一些弯路，浪费了不少时间，最后才终于找到了问题的根源，解决方案也很简单。

在排除问题之前，我们先简单梳理下思路：

• 既然是503异常，那一定是后端微服务没有正常响应。
• 由于流量是经过APISIX网关转发的，所以问题可能出在网关和微服务之间。

排查过程

1. 查看网关日志

首先我们查看APISIX网关的日志，发现了一条错误日志：

2023-08-01 15:08:30 [error] 1#1 upstream connect error or disconnect/reset before headers. reset reason: connection failure

这条日志表明，网关与后端微服务建立连接失败，或者在发送请求头之前连接断开或重置。

2. 查看微服务日志

接下来我们查看了后端微服务的日志，没有发现任何异常。这表明微服务本身并没有问题，问题可能出在网关和微服务之间的网络连接上。

3. 检查网络配置

我们检查了网关和微服务之间的网络配置，发现网关和微服务部署在不同的命名空间中，并且网关的Ingress控制器使用了NodePort方式暴露服务。

NodePort方式会为每个服务创建一个NodePort，通过NodePort可以访问集群中的服务。由于网关和微服务部署在不同的命名空间中，所以需要为网关的Ingress控制器配置ServiceAccount，以便它可以访问微服务的命名空间。

我们检查了网关Ingress控制器的ServiceAccount，发现它没有被授予访问微服务命名空间的权限。我们为ServiceAccount添加了必要的权限，然后重新部署了网关。

4. 重新排查

重新部署网关后，我们再次测试了流量，发现问题仍然存在。我们查看网关日志，发现仍然存在相同的错误日志：

2023-08-01 15:08:30 [error] 1#1 upstream connect error or disconnect/reset before headers. reset reason: connection failure

这表明网络连接问题仍然存在。

5. DNS问题

我们怀疑可能是DNS解析出了问题，导致网关无法正确解析微服务的地址。我们查看了网关的DNS配置，发现网关使用的是集群内部的DNS服务器。

我们尝试手动解析微服务的地址，发现解析结果不正确。我们检查了集群内部DNS服务器的配置，发现它没有正确配置，导致DNS解析失败。

我们修复了DNS服务器的配置，然后重新部署了网关。

6. 问题解决

重新部署网关后，我们再次测试了流量，发现问题已经解决。我们查看网关日志，没有发现任何错误日志。

至此，我们终于解决了APISIX网关503异常的问题。问题的原因是DNS解析失败，导致网关无法正确解析微服务的地址。

总结

这次排查过程比较曲折，我们多次陷入思维误区，走了一些弯路，最后才终于找到了问题的根源。

在排查过程中，我们学到了以下几点：

• 在排查问题时，不要轻易假设，要一步一步地验证。
• 要注意DNS解析的问题，DNS解析失败可能会导致各种各样的问题。
• 在部署微服务时，要确保ServiceAccount有访问其他命名空间的权限。

希望这篇文章能帮助其他遇到类似问题的工程师进行故障排查和解决。