Kubernetes同集群Pod通信走负载均衡而非内部DNS的问题咨询

这个问题属于应用配置问题，和Kong Ingress Controller的配置无关。

Kong Ingress Controller的核心作用是处理从集群外部经NLB进入的南北向流量的路由转发，完全不会干涉集群内部Pod之间东西向流量的域名解析逻辑。你当前观测到的Operation A调用Statuses时走NLB链路，本质是Operation A的代码/运行配置里写死了用对外暴露的负载均衡域名调用Statuses服务，而非K8s内部服务域名，该逻辑完全由应用侧控制。

出现connection refused报错的常见原因有两个：

• 私有NLB的安全组/网络ACL未放开集群Pod CIDR的入站访问权限，Pod发起的请求被网络策略拦截
• AWS GovCloud VPC存在Hairpin NAT限制，VPC内资源访问同VPC下的NLB地址时路由规则不匹配导致请求被拒绝

根据实际场景可以选择以下三类方案，优先推荐成本最低、性能最优的应用配置修改方案：

方案1：修改应用配置（最优） #

直接修改Operation A服务中配置的Statuses调用地址，改为K8s内部服务域名格式即可：

statuses.A.svc.cluster.local:<Statuses服务的ClusterIP端口>

修改后流量直接走集群内部CNI网络，无需经过Kong和NLB，链路最短、性能最高，也不会出现网络拦截问题。

方案2：CoreDNS域名重写（无需改应用的Workaround） #

如果因镜像固化、业务流程限制等原因无法修改Operation A的配置，可以通过CoreDNS重写规则，将负载均衡域名的内部解析直接指向Statuses的内部服务地址：

1. 编辑CoreDNS配置项：
   kubectl edit configmap coredns -n kube-system
2. 在Corefile配置段添加如下规则，替换为实际的负载均衡域名：

   rewrite name <你的负载均衡DNS域名> statuses.A.svc.cluster.local
   

3. 重启CoreDNS生效：
   kubectl rollout restart deployment coredns -n kube-system
   该方案无需修改应用代码和Kong配置，流量同样走集群内部链路。

方案3：调整网络放行规则（不推荐） #

如果必须保留走NLB+Kong的链路，可以调整网络规则放行请求：

• 修改私有NLB的安全组入站规则，放开集群Pod CIDR段对NLB监听端口的访问权限
• 检查Kong对应Ingress资源的鉴权规则，允许Operation A的请求（比如放行内部来源IP、新增免鉴权配置等）
  该方案会让内部流量额外绕行NLB和Kong，带来不必要的性能损耗，仅作为临时验证方案使用。

不需要修改Kong Ingress Controller或者Ingress资源的任何注解/参数，因为Ingress组件不负责管控集群内部服务的调用链路。

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