最近我们内网的 k8s 集群做了一次升级,发现经过 APISIX 网关服务都 503 异常了,于是做了一次分析。我们在内网和线上都采用了 APISIX 来做流量网关,对 APISIX 也贡献了 6 个 PR,所以对它的源码还算比较了解。下面排查过程比较曲折,情感上多次起伏,各位看官耐心看完。
现象
经由 APISIX 接管的所有接口请求都 503 了,如下所示。
网络的拓扑结构也非常的简单,就是 APISIX 将流量转发到后端的 java 服务。
APISIX 错误日志如下。
发现是因为域名解析失败,但是非常奇怪的是,在容器内我们通过 curl 请求直接是可以请求成功的
cat /etc/resolv.conf
nameserver 169.254.20.10
search imdach-dev-dev.svc.kubernetes.local svc.kubernetes.local kubernetes.local gz.cvte.cn
域名到底要不要以点号结尾
其实标准的 DNS 域名就是需要以点号结尾的,但是大家在用域名的过程中往往省略了最后的点,.
是根域名,访问所有域名本质都是要从根域名开始解析,比如 care.seewo.com.
理论要先问根域名服务器 .com 在哪。
这里专门有一篇文章讲这个问题,感兴趣的同学可以深入研究
http://www.dns-sd.org/trailingdotsindomainnames.html
小结
因为内网 K8S 的升级,导致 /etc/resolv.conf
中的 search 末尾多了一个点号,导致低版本的 APISIX(APISIX 2.12 版本以下)的域名解析会失败,与 IPV6 返回 NXDOMAIN 无关。
后记
分析问题一定得静下心,仔细去探究问题的根源,不要急于求成。
今天看到一句话,觉得挺好的,分享给大家,「经验用来对待特殊场景,方法论用来处理通用场景,没有经验可能会慢一些,没有方法论可能寸步难行」
如果上面的分析过程能给你带来一些启发,那就很好了。
本篇文章来源于微信公众号:张师傅的博客
本文来自投稿,不代表TakinTalks稳定性技术交流平台立场,如若转载,请联系原作者。