當將應用程式從傳統架構遷移到微服務架構時，經常會出現一些新的狀況。例如，常見的DNS基礎結構中的間歇性故障，會導致應用程式訪問異常，從而影響用戶的工作效率。
Service discovery是任何微服務架構的基礎。在任何服務到服務通信之前，將調用Service discovery 功能以檢索服務實際IP。這個過程通過利用DNS（包括Kubernetes）來執行，並且每次服務查找都會增加DNS基礎結構上的負載。線上技術論壇中，您會發現很多工程師們討論由於DNS超時而導致的應用失敗。
resolv.conf中可用的某些可調參數不足以解決DNS故障，當Kubernetes服務到服務流量增加時，常常會發生DNS故障。在這裡，Tinder工程博客上的一位元作者描述了DNS超時問題，儘管CoreDNS擴展到了1000個實例，但應用超時沒有得到緩解：“隨著我們為Kubernetes載入越來越多的服務，我們發現現在正在運行DNS服務，服務負載達到了每秒250,000個請求。我們發現應用程式中遇到了間歇性且影響嚴重的DNS查詢超時故障。儘管進行了詳盡的調優工作，並且DNS供應商切換到了CoreDNS部署，該部署達到了峰值使用了120個內核的1,000個Pod，但依舊有相同故障發生。”
由於Overlay網路架構，因此跨Kubernetes節點的兩個Pod之間的任何流量都會導致在conntrack（conntrack是netfilter提供的連接跟蹤機制，允許內核識別出資料包屬於哪個連接）表中插入源和目標NAT規則，以確保將資料包正確地雙向路由到Pod。在Linux conntrack內核模組中存在某些競爭條件的情況下，UDP上的DNS請求可能會丟棄，從而導致應用程式超時或應用程式延遲增加。如何擴展DNS層TTL(Time-To-Live)，就是一條功能變數名稱解析記錄在DNS伺服器中的存留時間。
當各地的DNS伺服器接受到解析請求時，就會向功能變數名稱指定的NS伺服器(權威功能變數名稱伺服器）發出解析請求從而獲得解析記錄；在獲得這個記錄之後，記錄會在DNS伺服器(各地的緩存伺服器，也叫遞迴功能變數名稱伺服器）中保存一段時間，這段時間內如果再接到這個功能變數名稱的解析請求，DNS伺服器將不再向NS伺服器發出請求，而是直接返回剛才獲得的記錄；而這個記錄在DNS伺服器上保留的時間，就是TTL值。在Service discovery 的上下文中，由於DNS記錄本質上是動態的，因此TTL通常保持非常低的值（10秒至一分鐘）。 DNS本質上是分層的，並且DNS緩存通常位於DNS權威伺服器之前。
為什麼選擇 Citrix ADC CPX？
Citrix ADC CPX 是一種以容器形式提供的Citrix ADC 產品。Citrix ADC 在其所有平臺（硬體/虛擬/容器）的代理和權威模式下對 DNS 協定有豐富的支援。以下是將 CPX 用作上述用例的節點緩存的一些好處。Citrix ADC DNS 性能：Citrix ADC 提供大量高性能、高規模的豐富功能，並具有可擴展的 DNS功能，優化記憶體佔用空間。主動 DNS 緩存更新：對於頻繁訪問的 DNS 記錄，Citrix ADC 將在 TTL 過期之前非同步查詢（不在實際用戶端請求的上下文中）更新的 DNS 記錄的後端權威kubeDNS伺服器。因此，DNS 用戶端始終提供最新的 DNS 記錄，而不會出現後端的額外延遲。DNS 請求的內容交換：Pipelined DNS 請求在DNS 中很常見。在緩存未命中的情況下，每個管道 DNS 請求將分別載入到不同的後端 DNS pod。減少 DNS 延遲：隨著 Citrix ADC CPX 作為節點本地 DNS 緩存的引入，我們看到 DNS 延遲的急劇改善。以下是 CPX 第 90、95 和 99 百分位元的性能讀數。
請注意，為了將我們的解決方案與 CoreDNS進行比較，我們使用 DNS 性能工具在 Google Kubernetes 引擎（GKE）進行了性能測試。測試環境的詳細資訊如下：Kubernetes version:1.15.9-gke.2Machine type:n1-standard-1 (1vCPU, 3.75GB memory)Number of Nodes: 3Queries per Second:15kTime duration: 30secs CPX version :13.0-52.24CPX Pod CPU: 25m CPX Pod memory: 25Mi CoreDNS cache version: 1.15.7CoreDNS pod CPU: 25m CoreDNS pod memory:5Mi DNS performance toolversion : 1.1測試方式是通過發送對三個不同功能變數名稱的進行查詢。DNS 性能工具是其中一個節點中的pod。延遲測量由DNS 性能工具提供。在 GCP 中，每次運行的性能數位可能略有不同。為什麼不是Sidecar部署？節點本地的 DNS 緩存有助於增強DNS 訪問並改進緩存使用情況。這可以減少權威伺服器上的負載。Sidecar部署不會有助於強化緩存，因為在 TTL 時間段內，pod 查詢同一域的可能性較小。節點本地緩存部署簡化了維護，而且在更高的規模下，將配置更新推送到每個節點緩存比將其推送到每個 pod 緩存更容易。結論部署節點本地 DNS 緩存有助於減少應用程式延遲並減少由於 DNS 超時而導致的應用程式故障。具有豐富 DNS 功能集和良好性能指標的 Citrix ADC CPX 可作為節點本地緩存來提高Kubernetes 環境中的應用程式性能。您可以在此處瞭解有關 Citrix ADC CPX 作為節點本地緩存和 DNS 功能的詳細資訊。獲取更多有關CPX for service mesh和Ingress Controller for Citrix ADC的詳細資訊。
本文來源：https://www.citrix.com/blogs/2020/04/01/citrix-adc-for-kubernetes-scaling-dns-with-cpx-as-node-local-cache/
發表迴響