似乎启动后有一个重要的（一分钟）延迟，直到networking实际上达到元数据服务器（169.254.169.254）以外的任何时间。 我testing过使用默认的debian jessie图像，也是我的自定义图像。 我看到了同样的问题。
这也可以通过使用串行控制台连接到机器来validation。 除了所说的元数据服务器之外，什么都不可能，甚至不是同一个GCEnetworking上的其他机器。
任何人看到这个或有任何线索是关于什么？
编辑：
这只发生在机器“冷靴”（即从头开始）时。
大致我看到以下事件：
当我按“启动虚拟机”时开始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.08ms 来自10.128.0.5的64个字节：icmp_seq = 50ttl = 64时间= 0.285ms
因此，假设启动（包括DHCP）需要大约25秒钟的networking隔离时间，大约需要5秒钟，正如我们在重启时看到的那样：
将其与重启实例的情况进行比较，在该实例中，只有7秒钟不可达（并且包括几秒closures）
$ 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.07ms 来自10.128.0.5的64字节：icmp_seq = 2 ttl = 64时间= 0.271ms 来自10.128.0.5的64字节：icmp_seq = 3 ttl = 64时间= 0.236ms 来自10.128.0.5的64字节：icmp_seq = 4 ttl = 64时间= 0.295ms 来自10.128.0.5的64字节：icmp_seq = 5 ttl = 64时间= 0.316ms 来自10.128.0.5的64字节：icmp_seq = 12 ttl = 64时间= 0.595ms 来自10.128.0.5的64字节：icmp_seq = 13 ttl = 64时间= 0.240ms 来自10.128.0.5的64字节：icmp_seq = 14 ttl = 64时间= 0.238ms 来自10.128.0.5的64字节：icmp_seq = 15 ttl = 64时间= 0.299ms
一位GCP员工解释了黑客新闻的原因https://news.ycombinator.com/item?id=15343888
我们正在努力。 这对我们来说是一个主要的举措，因为正如你所看到的，我们可以在几秒钟之内把这个该死的东西“启动”，然后从互联网上进出是一个长长的过程。 Fwiw，我们至less可以从/ .googleapis.com下来，所以如果你需要说从GCS获取一些东西，那应该快一点。
从更高的层面来看，这是拥有全球统一networking的结果，而且在您对所有路线进行“编程”之前，不希望宣布networking“向上”。 因此，如果您有1000台虚拟机分布在全球范围内，那么您必须确保它们没有“连接”，直到asia-east1-a中的新虚拟机可以与networking中的所有其他虚拟机进行通信（反之亦然）。 使用到/从API的path，这个路由就简单得多，因为你没有得到N ^ 2的行为。