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 里面，否則不會生效。

 

參考