我將分享我在 Kubernetes (1.12) 中使用 CoreDNS (1.2.5) 進行的一些測試結果，為您調整 CoreDNS 以符合叢集需求提供一些參考點。除了測試預設設定的 CoreDNS 之外，我也測試了啟用可選的 autopath 外掛程式的 CoreDNS。autopath 外掛程式是一種最佳化，可協助透明地減輕 Pod 因 Kubernetes 著名的 ndots:5 問題而造成的 DNS 效能損失。這些測試量化了啟用 autopath 時的記憶體/效能權衡。
這篇文章中的指南和公式基於在 GCE 中對叢集進行的一系列測試，您的結果可能會有所不同。這篇部落格文章是完整結果的摘錄，您可以在這裡看到更多詳細資訊。
記憶體和 Pod
在大型 Kubernetes 叢集中，CoreDNS 的記憶體使用量主要受叢集中 Pod 和服務的數量影響。
使用預設 CoreDNS 設定
要估計 CoreDNS 實例所需的記憶體量（使用預設設定），您可以使用以下公式
所需 MB 數 (預設設定) = (Pod 數量 + 服務數量) / 1000 + 54
使用 autopath 外掛程式
autopath 外掛程式是一種可選的最佳化，可提高對叢集外部名稱（例如 infoblox.com）查詢的效能。啟用 autopath 外掛程式需要 CoreDNS 使用顯著更多的記憶體來儲存有關 Pod 的資訊。
啟用 autopath 外掛程式也會對 Kubernetes API 施加額外的負載，因為它必須監控 Pod 的所有變更。
要估計 CoreDNS 實例所需的記憶體量（使用 autopath 外掛程式），您可以使用以下公式
所需 MB 數 (使用 autopath) = (Pod 數量 + 服務數量) / 250 + 56
CPU 和 QPS
透過在使用 CoreDNS 的叢集上使用 kubernetes/perf-tests/dns 工具來測試最大 QPS。使用的兩種查詢類型是內部查詢（例如 kubernetes）和外部查詢（例如 infoblox.com）。
使用預設 CoreDNS 設定
在 GCE n1-standard-2 節點上的 CoreDNS 單一實例（預設設定）
| 查詢類型 | QPS | 平均延遲 (毫秒) |
|---|---|---|
| 外部 | 67331 | 12.021 |
| 內部 | 33669 | 2.608 |
1從伺服器角度來看，它正在以 2.404 毫秒的延遲處理 33667 QPS，但從客戶端角度來看，每個單一名稱查詢實際上包含 5 個連續查詢。
使用 autopath 外掛程式
CoreDNS 中的 autopath 外掛程式是一種可減輕 ClusterFirst 搜尋列表懲罰的選項。啟用後，它可以減少客戶端在查詢外部名稱時發出的 DNS 查詢數量。
在 GCE n1-standard-2 節點上的 CoreDNS 單一實例（啟用 autopath 外掛程式）
| 查詢類型 | QPS | 平均延遲 (毫秒) |
|---|---|---|
| 外部 | 31428 | 2.605 |
| 內部 | 33918 | 2.62 |
請注意，此處外部查詢的數字有所改善。這是由於 autopath 外掛程式的最佳化。
啟用 autopath 後，外部查詢的伺服器角度延遲會稍微增加 (+8%)。
這是因為它在伺服器端執行檢查每個搜尋網域的額外工作。
但是由於它可以在一個往返中而不是五個往返中回答，因此整體客戶端角度效能得到了很大提升。
更多…
有關測試環境以及如何收集資料的更多資訊，請參閱這裡的完整結果。