GKE Autopilot搭配Cloud NAT出现接收数据包丢弃问题咨询

你的初步判断不准确，Cloud NAT单个公网IP不存在独立的带宽硬上限，作为GCP分布式托管服务，NAT吞吐量能力和绑定IP数量无直接绑定关系。你新增第二个公网IP后没有流量命中，是因为Cloud NAT默认采用五元组哈希做连接分流，到同一个远端数据库地址的长连接（数据库访问基本都是长连接）会固定映射到同一个NAT IP，不会跨IP分担现有连接流量，因此手动加IP无法解决当前场景的问题。

Cloud NAT出现Dropped received packets错误，在GKE访问远端数据库的场景下，90%以上的诱因不是带宽不足，真实根因按概率从高到低排序：

• NAT端口耗尽：Cloud NAT默认给每个GKE节点分配64个TCP端口，节点上所有Pod共享这部分端口做NAT转换。如果到数据库的连接数过高、或者大量TIME_WAIT状态连接未及时释放，会导致NAT网关没有可用端口匹配数据库返回的入向数据包，直接触发丢包，这是该场景最高发的原因。
• NAT映射超时不匹配：如果Cloud NAT的TCP连接空闲超时和数据库侧的空闲断连阈值不一致，会产生大量无有效映射的孤儿连接占满端口表项，数据库返回的数据包找不到对应的连接映射就会被丢弃。
• 带宽阈值超限：Cloud NAT单网关默认支持10Gbps吞吐量，只有持续流量超过该阈值时才会出现带宽类丢包，这类丢包会同时伴随端口占用率正常、出口带宽打满的监控特征，和你当前新增IP不生效的现象完全不匹配，发生概率极低。

第一步：先做根因确认 #

先到Cloud NAT监控面板核对两个核心指标：

• 查看nat_port_allocation_failed指标值，如果该指标持续上涨，同时open_connections数值接近当前配置的总端口配额上限，即可确认是端口耗尽问题。
• 核对当前NAT端口配置：每个NAT IP默认提供64512个可用端口，按默认单节点64端口计算，单NAT IP最多可支撑1008个GKE节点的端口需求，节点数未超过该值时不需要手动新增IP。

第二步：配置调整 #

• 调高单节点端口配额：将Cloud NAT的「每个虚拟机实例最小端口数」从默认64调整到256或更高，根据实际数据库连接规模设置即可，不要盲目调大避免端口浪费，该配置调整后动态生效，不需要重启GKE集群。
• 开启动态端口分配：在Cloud NAT配置中开启Enable dynamic port allocation开关，当实例默认端口用完时，网关会自动按需分配额外端口，适配数据库访问这类突发连接多的场景。
• 对齐超时配置：将Cloud NAT的TCP已建立连接空闲超时，设置为比数据库侧的空闲连接断开阈值长60s以上，比如数据库侧设置10分钟空闲断连，NAT侧就设置为11分钟，避免孤儿连接长期占用端口表项。
• 校验子网关联配置：如果是私有GKE集群，确认Cloud NAT规则同时关联了节点子网和Pod secondary子网，仅关联节点子网会导致Pod直连流量的NAT规则缺失，触发丢包。

第三步：数据库场景专项优化 #

• 在GKE workload侧配置数据库连接池，限制单实例到数据库的最大连接数，同时开启空闲连接自动回收，避免大量无效长连接占用NAT端口资源。
• 不要手动新增NAT IP，直接开启Cloud NAT的「自动分配NAT IP」功能，当现有IP的端口使用率达到阈值时，GCP会自动新增IP承载新建连接，比手动配置的分流逻辑更可靠。

内容的提问来源于stack exchange，提问作者Ivan Ponomarev