我似乎有一个类似的问题 这个 当我在GCP上使用gitlab runner构建docker镜像时，出现了以下超时的问题
Put https://registry.gitlab.com/v2/[redacted-repo]: dial tcp 35.227.35.254:443: i/o timeout
此刻我的google云NAT给出的日志输出如下。
{
"insertId": "rh7b2jfleq0wx",
"jsonPayload": {
"allocation_status": "DROPPED",
"endpoint": {
"project_id": "gitlab-autoscale-runners",
"vm_name": "runner-5dblbjek-auto-scale-runner-1589446683-0b220f90",
"region": "europe-west4",
"zone": "europe-west4-b"
},
"connection": {
"protocol": 6,
"src_port": 42446,
"src_ip": "some-ip",
"dest_ip": "some-ip",
"dest_port": 443
},
"vpc": {
"vpc_name": "default",
"subnetwork_name": "default",
"project_id": "gitlab-autoscale-runners"
},
"gateway_identifiers": {
"gateway_name": "gitlab-runner-gateway",
"router_name": "gitlab-runner-router",
"region": "europe-west4"
}
},
"resource": {
"type": "nat_gateway",
"labels": {
"region": "europe-west4",
"router_id": "7964886332834186727",
"gateway_name": "gitlab-runner-gateway",
"project_id": "gitlab-autoscale-runners"
}
},
"timestamp": "2020-05-14T10:17:55.195614735Z",
"labels": {
"nat.googleapis.com/nat_ip": "",
"nat.googleapis.com/instance_name": "runner-5dblbjek-auto-scale-runner-1589446683-0b220f90",
"nat.googleapis.com/network_name": "default",
"nat.googleapis.com/subnetwork_name": "default",
"nat.googleapis.com/router_name": "gitlab-runner-router",
"nat.googleapis.com/instance_zone": "europe-west4-b"
},
"logName": "projects/gitlab-autoscale-runners/logs/compute.googleapis.com%2Fnat_flows",
"receiveTimestamp": "2020-05-14T10:18:00.422135520Z"
}
上述问题似乎表明一个问题 与过度利用的NAT端口。我已经通过利用google cloud CLI确认这不是我们的问题，请看下文。
$ gcloud compute routers get-nat-mapping-info gitlab-runner-router
---
instanceName: runner-5dblbjek-auto-scale-runner-1589446683-0b220f90
interfaceNatMappings:
- natIpPortRanges:
- some-id:1024-1055
numTotalDrainNatPorts: 0
numTotalNatPorts: 32
sourceAliasIpRange: ''
sourceVirtualIp: some-ip
- natIpPortRanges:
- some-ip:32768-32799
numTotalDrainNatPorts: 0
numTotalNatPorts: 32
sourceAliasIpRange: ''
sourceVirtualIp: some-ip
我似乎只使用了一些64端口。
google云路由器的广告状态如下。
kind: compute#routerStatusResponse
result:
natStatus:
- autoAllocatedNatIps:
- some-ip
minExtraNatIpsNeeded: 0
name: gitlab-runner-gateway
numVmEndpointsWithNatMappings: 3
network: https://www.googleapis.com/compute/v1/projects/gitlab-autoscale-runners/global/networks/default
同样的docker-images在本地运行或在共享的gitlab运行器中，即不在NAT后面时，也能成功构建。
如何防止在google cloud nat后面构建这个docker image时超时？
从Cloud NAT的输出来看，显示分配掉的状态。建议的操作是将每个虚拟机实例的最小端口增加到足够的范围（4096个端口），并让它运行几天。我建议用这个数字来实现我们将停止收到drop，如果这有助于减少drop，我们可能需要增加更多的2倍，直到没有收到drop。如果你在4k端口没有收到任何DROPPED状态，你可以减少它，直到你找到一个中位数，你不再收到DROPPED状态，也没有大量的NAT端口开放。端口使用率代表了一个虚拟机连接到单一目标的数量（目标IP:端口，协议）。
从您的配置来看，目前每个虚拟机有64个端口分配（如您在描述中提到的）。这意味着，该vpc内的每个虚拟机实例都有64个NAT IP:PORT组合来对外连接。 这意味着，你可以连接到64个唯一的独特的目标（目标IP地址，目标端口和协议）。当你在测试时，看起来你正在达到这个限制。
分配给云计算 NAT 网关的每个 NAT IP 都有 64512 个端口，因此在默认配置为每个虚拟机 64 个端口的情况下，NAT 网关将为 NAT 网关配置中选择的指定子网内的每个虚拟机分配 64 个 NAT IP:PORT。 因此，这意味着在这种配置下，你可以运行1008个虚拟机（64512除以64），但每个虚拟机可以同时连接到64个独特的目的地。现在根据你的应用情况，如果你需要更多的同时连接，你将需要增加每个虚拟机的最小端口。
例如，用1个NAT IP和1024个最小端口，你可以运行63个虚拟机，每个虚拟机可以连接到1024个唯一的目标。 如果你需要运行更多的虚拟机，你需要分配更多的NAT IP。通过增加第二个IP，你可以将NAT容量增加一倍。 由于您选择了自动分配NAT IP，当您在子网中创建更多的虚拟机时，NAT IP将被自动创建和分配。 在这种情况下，您只需要调整每个虚拟机的最小端口配置，以满足您的流量需求。
请注意，一旦连接终止，NAT网关有2分钟的计时器，在此之前，NAT IP:PORT可以被使用。[1]，所以你要保持端口配置比你的流量峰值高一点。
更多关于端口计算的细节在这里[2] 。
[1] https:/cloud.google.comnatdocsoverview#specs-timeouts。
[2] https:/cloud.google.comnatdocsports-and-addresses#ports。