似乎在启动后会有一段相当长的（一分钟）延迟，直到网络实际到达元数据服务器（169.254.169.254）以外的任何服务器。我使用默认的 debian jessie 映像和我的自定义映像进行了测试。我发现了同样的问题。
也可以通过使用串行控制台连接到计算机来验证这一点。除了上述元数据服务器之外，什么都无法访问，甚至同一 GCE 网络上的其他计算机也无法访问。
还有谁看到这个或者知道它的含义吗？
编辑：
这种情况仅当机器“冷启动”（即从头启动）时才会发生。
我大致看到了以下事件：
- 0s-在控制台中按“启动虚拟机”
- 1s – 实例状态（根据 API）更改为 PRIVISIONING
- 4s – 实例状态变为 STAGING
- 20 秒 – 实例状态变为 RUNNING
- 49s – 实例响应来自同一子网上另一台虚拟机的 ping。
当我按下“启动虚拟机”时开始 ping：
$ ping 10.128.0.5 PING 10.128.0.5 (10.128.0.5) 56（84）字节数据。 来自 10.128.0.5 的 64 字节：icmp_seq=49 ttl=64 时间=1.08 毫秒 来自 10.128.0.5 的 64 字节：icmp_seq=50 ttl=64 时间=0.285 毫秒
因此，假设启动（包括 DHCP）大约需要 5 秒，则网络隔离时间大约为 25 秒，正如我们在重新启动时看到的那样：
将其与重启实例仅在约 7 秒内无法访问（其中包括关闭的几秒钟）
$ ping 10.128.0.5 PING 10.128.0.5 (10.128.0.5) 56（84）字节数据。 来自 10.128.0.5 的 64 字节：icmp_seq=1 ttl=64 时间=1.07 毫秒 来自 10.128.0.5 的 64 字节：icmp_seq=2 ttl=64 时间=0.271 毫秒 来自 10.128.0.5 的 64 字节：icmp_seq=3 ttl=64 时间=0.236 毫秒 来自 10.128.0.5 的 64 字节：icmp_seq=4 ttl=64 时间=0.295 毫秒 来自 10.128.0.5 的 64 字节：icmp_seq=5 ttl=64 时间=0.316 毫秒 来自 10.128.0.5 的 64 字节：icmp_seq=12 ttl=64 时间=0.595 毫秒 来自 10.128.0.5 的 64 字节：icmp_seq=13 ttl=64 时间=0.240 毫秒 来自 10.128.0.5 的 64 字节：icmp_seq=14 ttl=64 时间=0.238 毫秒 来自 10.128.0.5 的 64 字节：icmp_seq=15 ttl=64 时间=0.299 毫秒
答案1
GCP 的一名员工在 Hacker News 上解释了原因https://news.ycombinator.com/item?id=15343888
我们正在努力。这对我们来说是一项重大举措，因为正如您所见，我们在几秒钟内就让该死的东西“启动”，然后互联网的可达性才是关键。Fwiw，我们至少已经到达/离开 *.googleapis.com，所以如果您需要说从 GCS 获取某些东西，那应该会更快一些。
从高层次上讲，这是拥有全球、扁平网络的结果，并且在“编程”所有路由之前不想声明网络“启动”。因此，如果您有 1000 个虚拟机分布在全球，那么您必须确保它们不会“连接”，直到 asia-east1-a 中的新虚拟机可以与网络中的所有其他虚拟机通信（反之亦然）。使用 to/from API 路径，此路由要简单得多，因为您不会获得 N^2 行为。