自托管K8s集群中AWS NLB从Worker节点访问间歇性超时求助

一、验证请求回环场景 #

• 在Worker节点执行抓包命令：tcpdump host <NLB_IP> and port <NodePort>，同时持续curl业务域名，观察是否存在请求发出后无响应的情况，确认回环流量是否被丢弃
• 检查节点iptables规则：iptables-save | grep -A5 -B5 <NodePort>，查看K8s kube-proxy生成的规则中是否存在针对本地发起的NodePort请求的拦截/丢弃规则
• 核对EC2实例安全组，确认是否允许节点自身IP访问NodePort对应的端口

二、检查NLB与目标组配置 #

• 查看目标组的健康检查状态，确认Worker节点的NodePort端口是否存在间歇性健康检查失败的情况，这种波动会导致流量被临时剔除后重新加入，引发间歇性超时
• 确认NLB的流量分发策略（如轮询、最小连接数），若为轮询模式，请求有50%概率落到发起请求的Worker节点，与间歇性超时现象匹配
• 检查目标组是否开启源IP保留（NLB默认启用），若开启，节点收到来自自身IP的请求时，内核或iptables可能因反向路径过滤（RPFilter）规则拦截流量

三、排查K8s网络组件配置 #

• 确认kube-proxy运行模式（iptables/ipvs）：kubectl get configmap kube-proxy -n kube-system -o yaml | grep mode，若为iptables模式，检查是否存在REJECT规则拦截本地回环流量；若为ipvs模式，查看ipvs规则是否正常转发本地请求
• 检查CNI插件（如Calico、Flannel）的配置，查看是否存在限制本地流量的规则，例如Calico的Felix组件是否启用了相关流量管控策略
• 查看Kong Ingress Controller的日志：kubectl logs -n <kong-namespace> <kong-pod-name>，搜索Worker节点IP相关的请求记录，确认是否有请求被拒绝或处理异常

四、验证本地请求绕过NLB的方案 #

• 在Worker节点直接curl Kong Service的ClusterIP：curl http://<kong-cluster-ip>/<path>，确认业务本身无异常
• 临时修改Worker节点的/etc/hosts，将业务域名映射到Kong的ClusterIP，测试请求是否恢复正常，以此确认问题根源在NLB回环路径
• 长期方案可考虑：配置集群内部DNS规则（如CoreDNS的hosts插件），让Worker节点发起的本地请求直接解析到Kong的ClusterIP，绕过NLB；或者调整目标组配置，排除节点自身作为目标（需结合业务流量需求评估）

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