说明
此插件允许自动重新加载已更改的Corefile。要启用对区域文件更改的自动重新加载，请使用auto插件。
此插件通过读取 Corefile 并计算其 SHA512 校验和来定期检查 Corefile 是否已更改。如果文件已更改，它将使用新的 Corefile 重新加载 CoreDNS。这省去在更改 Corefile 后发送 SIGHUP 或 SIGUSR1 的麻烦。
重新加载是无缝的 - 在重新加载发生时，您不应该看到任何服务丢失。即使新的 Corefile 有错误，CoreDNS 也会继续运行旧配置，并将错误消息输出到日志。但有关故障模式，请参见 Bugs 部分。
在某些环境（例如，Kubernetes）中，可能存在很多在同一时间段内启动并共享一个通用 Corefile 的 CoreDNS 实例。为了防止它们在同一时间全部重新加载，会在重新加载检查时间间隔中添加某些抖动。这是从多个 CoreDNS 实例的角度进行的抖动；每个实例仍会以常规时间间隔进行检查，但这些实例的所有重新加载将分布在整个抖动持续时间中。鉴于重新加载是无缝的，因此这一步骤不是严格必需的，可以通过将抖动设置为0s来禁用它。
在重新加载 Corefile 时会重新计算抖动。
每个服务器块只能使用此插件一次。
语法
reload [INTERVAL] [JITTER]
插件将在INTERVAL的每个范围内（取决于+/-JITTER持续时间）检查更改。
- INTERVAL 和 JITTER 是 Golang durations。默认的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 语句。这意味着如果任何这些导入的文件发生更改，重新加载 插件都不会意识到这个事实。CoreDNS v1.7.0 及更高版本会解析 Corefile 并支持检测导入文件中的更改。
指标
如果启用监控（通过 prometheus 插件），则会导出以下指标
coredns_reload_failed_total{}- 计算失败的重新加载尝试的次数。coredns_reload_version_info{hash, value}- 在重新加载期间记录哈希值。
目前，hash 的类型为“sha512”，value 是返回的哈希值。
另请参阅
请参阅 coredns-import(7) 和 corefile(5)。