问题描述
概览
我在 App Engine 上有实例，其中包含 Google 提供的自定义域和 SSL 证书，但现在我需要在它前面放置一个 Google Cloud Load Balancer。
我按照此处的说明进行操作（针对 App Engine 而不是 Cloud Run 进行了调整）： https://cloud.google.com/load-balancing/docs/https/setting-up-https-serverless
我先执行了该指南中的步骤，然后在 GoDaddy 中更新了我的 DNS 记录以指向负载均衡器的 IP。
问题
问题是，在我更新我的 GoDaddy DNS 记录以指向负载均衡器的 IP 之后，我花了将近一个小时才能再次访问。尝试通过浏览器或代码访问该网站时，我收到 SSL 错误。
配置 SSL 证书
核心问题似乎是负载均衡器的 SSL 证书状态为 PROVISIONING，而域的状态为 Failed_NOT_VISIBLE，文档说：
网域的 DNS 记录未解析为 Google Cloud 负载平衡器的 IP 地址。要解决此问题，请更新 DNS A/AAAA 记录以指向您的负载平衡器的 IP 地址。
https://cloud.google.com/load-balancing/docs/ssl-certificates/troubleshooting#domain-status
这些文档是关于 PROVISIONING 的：
Google Cloud 正在与证书颁发机构合作颁发 证书。配置 Google 管理的证书可能会占用 到 60 分钟
我可以做些什么来避免/最大限度地减少这一小时的停机时间？
我仍然需要对我的生产项目执行此操作。也许如果我改变步骤的顺序（甚至在创建 SSL 证书之前将 DNS 记录指向 IP）？
如果我能在更新 DNS 记录以指向负载均衡器的 IP 之前获得 SSL 证书，这似乎很好，但更新 DNS 似乎是 SSL 证书甚至启动的先决条件。
这很有趣，因为我已经通过 App Engine 自定义域设置从谷歌获得了这些域的 SSL 证书。我希望这些可以重用于负载平衡器。
解决方法
您是否创建了新的 DNS 资源记录或更改了现有记录？
如果您在创建资源记录之前尝试解析它，DNS 服务器将返回NXDOMAIN，这称为否定响应。否定响应由 DNS 解析器缓存。
如果您更改了现有资源记录，TTL 是多少？
DNS 解析器使用各种策略来决定缓存 DNS 资源记录的时间。一个因素是 TTL。
首先创建/更新 DNS 资源记录
通过首先创建 DNS 资源记录，NXDOMAIN 将不会在验证尝试时返回，这将减少您必须等待否定响应缓存清除的时间。您域的权威 DNS 服务器通常是两到四台服务器。创建新的资源记录时，服务器需要时间来创建 SLAVES 并将其与 MASTER 同步。这个时间通常只有一两分钟。
刷新公共 Google DNS 服务器
如果您的 DNS 资源记录过时（已更改）且 TTL 值过长，请刷新 Google 公共 DNS 服务器。此操作不是即时的，计划等待五分钟以完成操作。
我能做些什么来避免/尽量减少这一小时的停机时间？
您不能直接更改配置时间。如果您遵循以上几点，配置时间将会减少。根据我的经验，SSL 证书配置通常需要 10 分钟。
Google 负载平衡器在进行更改后需要时间来更新。这个时间会有所不同，但五到十分钟是典型的。这一次是对证书供应的补充。您的网站在此期间可能无法访问。
DNS 服务器更改不是即时的。您域的 DNS 服务器需要时间来更新、Internet 上的 DNS 解析器缓存资源记录、客户端系统缓存记录等。在更改 DNS 服务器之前制定计划。更改可能需要 24 到 72 小时才能在全球传播。