我有一个安装了 istio 的 GKE 集群。Istio 入口网关会自动创建一个具有 IP 的负载均衡器。
我将此 IP 放入 Cloud DNS 中，如下图所示（带有隐藏 DNS 名称的虚假 IP）。一切正常，我可以使用 URL 访问我的集群。
我知道如果我需要按照文档中所述更改 IP，我可以减少 TTL 时间来尝试减少传播时间。
传播变更
更改分为两个部分进行传播。首先，您通过 API 或命令行工具发送的更改必须推送到 Cloud DNS 的权威 DNS 服务器。其次，DNS 解析器必须在其记录缓存过期时获取此更改。
DNS 解析器的缓存由您为记录设置的生存时间 (TTL) 值控制，该值以秒为单位。例如，如果您将 TTL 值设置为 86400（24 小时内的秒数），则 DNS 解析器会将记录缓存 24 小时。某些 DNS 解析器会忽略 TTL 值或使用自己的值，这可能会延迟记录的完整传播。
如果您计划更改需要较窄窗口的服务，则可能需要在进行更改之前将 TTL 更改为较短的值。此方法可以帮助减少缓存窗口并确保更快地更改新的记录设置。更改后，您可以将值改回其先前的 TTL 值以减少 DNS 解析器的负载。
但正如您所见，此解决方案并不可靠，因为某些 DNS 解析器无法遵循我的 TTL。有没有办法将此传播时间减少到零？我尝试创建负载均衡器和转发规则，但没有成功。
答案1
有什么方法可以将这个传播时间减少到零吗？
通过互联网？不。另请参阅：如何缩短DNS传播效果
权威名称服务器可能具有一些最小 TTL。尽管通常最小值只有几分钟。Google Cloud DNS 可以处理接近其最小 TTL 的查询，因此负载不是问题。
一些解析器已经观察到 TTL 增加。虽然这些人只是少数，但期望 100% 的用户都会按 TTL 迁移是不现实的。
答案2
有什么方法可以将这个传播时间减少到零吗？
不。
假设所有其他 DNS 服务器都会遵守 TTL，因为如果它们不遵守，您既无法控制它，也无法影响它们的行为。将 TTL 设置为您认为合理且可以实现您的目标的任何值。如果某些 DNS 服务器不遵守它，您无论如何也无能为力。