Web负载均衡学习笔记之K8S内Ngnix微服务服务超时问题

0x00 概述

本文是从K8S内微服务的角度讨论Nginx超时的问题

0x01 问题

在K8S内部署微服务后，发现部分微服务链接超时，Connection Time Out。

最近碰到了一个 Nginx 做为反向代理设置上的坑。起因是将 Nginx 做为反向代理服务器，来统一处理内网服务的转发。使用了类似如下的配置:

server {listen 80;server_name xxx.xxx.net;location / {proxy_pass http://xxxxx;}
}

刚开始的时候， proxy_pass 里使用的 ip 地址，Nginx 工作正常。近期由于内网服务升级，每个内网服务前面，都新增了一个 AWS internal load balancer，用来作为负载。而 AWS 的 lb 提供的访问方式，是一个内网 DNS 地址，而不直接提供 ip 地址。于是最初我便把 nginx 的 proxy_pass 里的 ip 地址改为了 AWS 提供的负载均衡的内网域名，测试后没有问题。但是在第二天一早到公司后，发现昨天配置的内网服务无法连通了。尝试执行命令 nginx -s reload 后，服务又恢复正常后，便没有过多追究，去忙别的事情了。但是一直感觉到这里的问题应该不简单，在详细查看 log 与文档后，发现了 Nginx 一个设置上的细节。

0x02 解决

在这个文档 Nginx 文档 Using DNS for Service Discovery with NGINX and NGINX Plus 中，解释了发生这个问题的原因。如果在 Nginx 的设置 proxy_pass 里使用域名而不是 IP 地址，Nginx 只会在每次启动和重载设置时，使用 DNS 将域名解析为 IP 地址缓存下来，并在之后一直使用这个 IP，并不会按照 DNS 的 TTL 刷新 IP 地址。如果在这个解析过程中发生错误，则会导致 Nginx 启动失败。由于在 AWS 中负载均衡的内网域名对应的 IP 并不是一直不变的，这才导致了上面的问题。文档中同样指出，使用 Nginx 的 upstream 配置也会有这个问题。

既然知道了问题的原因所在，那么针对这个问题，根据上面文档中给出了一个解决方法，将配置文件修改为如下的形式：

server {listen 80;server_name xxx.xxx.net;resolver 172.31.0.2 valid=30s;set $service_lb xxxxxx;location / {proxy_pass http://$service_lb;}
}

在这个配置中，resolver 是 DNS 服务器地址, valid 设定 DNS 刷新频率。需要特别注意的一点是 set 语句不能写到 location 里面，否则不会生效。

参考

转载于:https://www.cnblogs.com/JetpropelledSnake/p/11104035.html