ECS 服務發現 DNS 更新的大延遲

Question

我試圖找出為什么 AWS DNS 服務器（10.0.0.2 和 169.254.169.253）需要很長時間才能為我的 ECS 任務返回正確的 IP 地址。

我目前的設置如下：

• dev.private 是 Route53 托管區域
• 使用 TTL 0 和 A 類型 dns 條目的 ECS 服務（在 deepstream.dev.private 下注冊）
• 執行 SSL 終止並將請求轉發到 ECS 服務的 nginx 服務

首次創建 EC2 實例並安裝 nginx 時，一切都與指向 10.0.0.2 的解析器一起工作

但是，在殺死 ECS 任務時：

• 它已從 route53 中刪除（預期）
• 使用新的 IP（預期）將新任務條目輸入到 route53
• 新條目未出現在 nginx 中（它返回（3：找不到主機））
• 使用 dig (dig @10.0.0.2 deepstream.dev.private) 時新條目不顯示

dig @10.0.0.2 deepstream.dev.private

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.amzn2.0.2 <<>> @10.0.0.2 deepstream.dev.private
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 10878
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;deepstream.dev.private.                IN      A

;; Query time: 0 msec
;; SERVER: 10.0.0.2#53(10.0.0.2)
;; WHEN: Tue Apr 14 03:33:39 UTC 2020
;; MSG SIZE  rcvd: 51

這表明沒有答案

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.amzn2.0.2 <<>> @10.0.0.2 deepstream.dev.private
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15576
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;deepstream.dev.private.                IN      A

;; ANSWER SECTION:
deepstream.dev.private. 0       IN      A       10.0.2.214

;; Query time: 1 msec
;; SERVER: 10.0.0.2#53(10.0.0.2)
;; WHEN: Tue Apr 14 03:35:00 UTC 2020
;; MSG SIZE  rcvd: 56

所以總結一下測試場景：

• Dig 返回 IP 一切都很好
• 殺死 ECS 任務后立即刪除 Route53 條目
• 不到 10 秒后（在 ECS 上重新啟動 docker 所需的時間）新的 Route 53 條目添加了 IP
• 5 分鍾后，新條目通過 dig 返回

跑了多次，似乎一直是五分鍾，感覺就像某個地方的緩存。

不能指望在崩潰或部署后需要 5 分鍾才能引用新的 ECS 實例，這將是不可接受的停機時間。

Answer 1

這似乎與 ECS 用於提供服務發現的雲 Map 命名空間中的負 DNS 緩存有關。 在 2020 年 9 月 14 日之前，默認（和固定）負緩存 TTL（換句話說，命名空間的 SOA 記錄的 TTL）對於僅具有 VPC 解析的命名空間為 300 秒（您的 5 分鍾值），對於僅具有 VPC 解析的命名空間為 900 秒具有公共 DNS 分辨率的命名空間。

根據鏈接的 GitHub 問題，新創建的命名空間的默認值現在分別為 15 秒和 60 秒。

我也遇到過這個問題，並且很難追查原因，因為只有當可用任務的數量一直下降到 0 時才會發生這種情況，從而導致緩存的 NXDOMAIN 響應。

至少在撰寫本文時，無法手動修改此值（盡管根據 GitHub 問題正在進行中），因此唯一的解決方案是重新創建命名空間以獲得新的較低默認值。