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

總結

以上是生活随笔為你收集整理的Web负载均衡学习笔记之K8S内Ngnix微服务服务超时问题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。