Azure AKS中NGINX Ingress转发9000端口TCP流量跨网VM无法连通问题
流量不通的核心根因与分层排查修复步骤
一、核心配置错误点
- 应用Deployment镜像配置错误:业务Deployment中定义的容器镜像地址
fa.dev/:test1格式不合法,缺失镜像仓库路径下的具体镜像名称,导致Pod无法正常拉取镜像启动,关联的ClusterIP Service无可用后端端点,流量转发无有效目标。 - Service端口映射配置错误:手动补全LoadBalancer服务的9000端口配置时,未通过Helm持久化配置实现规则自动生成,且手动添加的端口规则不在Helm release的管理范畴内,后续控制器reconcile时会被自动重置删除。
- 冗余HTTP规则无效:部署的Ingress资源为HTTP路由规则,仅能处理带Host、Path字段的HTTP流量,对裸TCP的9000端口流量完全无路由作用,不会参与TCP转发链路,该配置对当前场景无任何效果。
二、分层修复操作步骤
- 修正业务应用Deployment配置
修正不合法的镜像地址,确认Pod可正常启动:
部署完成后验证Service的后端端点已正常生成:# 替换为合法的完整镜像地址,格式为<仓库地址>/<镜像名>:<标签> containers: - name: frontarena-ads-aks-test image: fa.dev/frontarena-ads:test1 ports: - containerPort: 9000
输出结果应包含运行中Pod的IP和9000端口,无空值。kubectl get endpoints frontarena-ads-aks-test - 持久化Ingress的TCP端口映射配置
更新内部Ingress的values配置文件,将TCP映射规则永久写入配置,避免临时命令行参数在reconcile时丢失:
执行Helm升级命令,让Chart自动完成LoadBalancer服务端口、ConfigMap映射规则的生成,无需手动编辑Service资源:controller: service: annotations: service.beta.kubernetes.io/azure-load-balancer-internal: "true" tcp: 9000: "default/frontarena-ads-aks-test:9000"
验证Ingress控制器配置已生效:helm upgrade nginx-ingress ingress-nginx/ingress-nginx \ -f internal-ingress.yaml \ --reuse-values- 确认LoadBalancer服务已自动包含9000端口的监听规则:
kubectl get svc nginx-ingress-ingress-nginx-controller - 确认TCP ConfigMap规则与预期一致:
kubectl get configmap nginx-ingress-ingress-nginx-controller -o yaml - 查看Ingress控制器Pod日志,确认9000端口的TCP监听已正常加载:
kubectl logs <Ingress控制器Pod名称> | grep 9000
- 确认LoadBalancer服务已自动包含9000端口的监听规则:
- 跨VPC网络链路放通
完成集群内部配置验证后,排查跨网络的连通性阻断点:- 检查两端VNet的peering配置,确保双向连通路由已生效,无路由规则指向冲突
- 检查AKS节点子网、内部负载均衡关联的网络安全组(NSG),添加入站规则放通9000端口的TCP流量,源地址覆盖外部VM所在VNet的地址段
- 从外部VM执行连通测试,确认到内部LB IP 10.33.27.35:9000的网络层可达:
nc -zv 10.33.27.35 9000
三、常见坑位规避
- 非HTTP的TCP流量转发,完全依赖NGINX Ingress的
tcp类型ConfigMap配置块,不需要也无法通过HTTP类型的Ingress资源实现路由 - 所有对Helm管理资源的修改,必须通过更新values文件后执行Helm upgrade完成,禁止手动通过
kubectl edit修改Service/Deployment等资源,否则配置会在控制器reconcile时被自动重置 - AKS内部负载均衡的承载子网,必须与跨VPC的外部VM网络存在有效路由连通,否则即使集群内部配置完全正确,外部流量也无法到达LB的内部IP
内容的提问来源于stack exchange,提问作者vel
相关产品推荐
相关产品推荐

