描述
此外掛程式允許自動重新載入變更後的 Corefile。若要啟用自動重新載入 zone file 變更，請使用 auto 外掛程式。
此外掛程式會定期檢查 Corefile 是否已變更，方法是讀取該檔案並計算其 SHA512 檢查碼。如果檔案已變更，它會使用新的 Corefile 重新載入 CoreDNS。這省去了在變更 Corefile 後發送 SIGHUP 或 SIGUSR1 的需要。
重新載入是平穩的 - 您在重新載入發生時不應看到任何服務中斷。即使新的 Corefile 有錯誤，CoreDNS 也會繼續執行舊的組態，並且會在記錄中印出錯誤訊息。但請參閱「錯誤」章節以了解失敗模式。
在某些環境中（例如 Kubernetes），可能會有許多 CoreDNS 實例在幾乎相同的時間啟動，且它們都共用一個通用的 Corefile。為了防止它們同時重新載入，會向重新載入檢查間隔新增一些抖動。這是從多個 CoreDNS 實例的角度來看的抖動；每個實例仍然會定期檢查，但所有這些實例的重新載入將分散在整個抖動持續時間內。鑑於重新載入是平穩的，這並非絕對必要，可以透過將抖動設定為 0s 來停用。
每次重新載入 Corefile 時，都會重新計算抖動。
此外掛程式在每個伺服器區塊中只能使用一次。
語法
reload [INTERVAL] [JITTER]
此外掛程式將檢查每隔 INTERVAL 發生的變更，並受到 +/- JITTER 持續時間的影響。
- INTERVAL 和 JITTER 是 Golang 持續時間。預設 INTERVAL 為 30 秒，預設 JITTER 為 15 秒，INTERVAL 的最小值為 2 秒，而 JITTER 的最小值為 1 秒。如果 JITTER 超過 INTERVAL 的一半，它將被設定為 INTERVAL 的一半。
範例
使用預設間隔檢查
. {
reload
erratic
}
每 10 秒檢查一次（在這種情況下，抖動會自動設定為 10 / 2 = 5）
. {
reload 10s
erratic
}
錯誤
重新載入會發生且不會遺失資料（即 DNS 查詢會持續進行），但有一個角落案例會導致重新載入失敗，而您會遺失功能。請考慮以下 Corefile
. {
health :8080
whoami
}
CoreDNS 啟動並從 :8080 提供健康狀態。現在，您將 :8080 變更為 :443，卻不知道已經有程序正在監聽該埠。程序會重新載入並執行以下步驟
- 關閉 8080 上的監聽器
- 重新載入並再次剖析組態
- 無法在 443 上啟動新的監聽器
- 無法載入新的 Corefile，中止並繼續使用舊的程序
在中止重新載入嘗試後，我們保留了正在執行的舊程序，但監聽器已在步驟 1 中關閉；因此健康狀態端點會損壞。同樣的情況也可能發生在 prometheus 外掛程式中。
一般而言，請小心指定新埠，並期望重新載入能完全運作。
在 CoreDNS v1.6.0 和更早版本中，此外掛程式不會發現任何 import 陳述式。這表示如果任何這些匯入的檔案發生變更，reload 外掛程式不會知道該事實。CoreDNS v1.7.0 和更高版本會剖析 Corefile 並支援偵測匯入檔案中的變更。
指標
如果已啟用監控（透過 prometheus 外掛程式），則會匯出以下指標
coredns_reload_failed_total{}- 計算失敗的重新載入嘗試次數。coredns_reload_version_info{hash, value}- 記錄重新載入期間的雜湊值。
目前 hash 的類型為 "sha512"，value 是傳回的雜湊值。
另請參閱
請參閱 coredns-import(7) 和 corefile(5)。