无法curl访问AKS集群LoadBalancer类型服务公网IP
故障原因
核心问题为端口配置不匹配,导致整条流量链路不通:
- 你使用的官方
nginx:latest镜像默认在容器内监听80端口,但Deployment配置里声明容器暴露8080端口,Service的targetPort也指向8080。 - 该配置会让kube-proxy把访问Service、NodePort的流量全部转发到Pod的8080端口,但该端口没有nginx进程监听,无法响应任何请求。
- AKS配套的Azure LoadBalancer默认会持续探测后端节点的NodePort(你手动指定为31000)健康状态,由于端口转发后无有效响应,LB会判定所有后端节点不健康,不转发实际业务流量。此时客户端能和LB建立部分TCP连接,但没有后端节点返回响应,就会出现curl无报错、一直挂起无返回的现象。
- 次要排查点:如果你曾手动修改AKS节点关联的网络安全组(NSG)规则,需要确认入方向没有拦截8080(LB对外端口)、31000(自定义NodePort)的流量;默认配置下AKS会自动为LoadBalancer类型Service放开对应NSG规则,无需手动配置。
故障验证
通过以下步骤可以直接确认根因:
- 执行命令进入运行中的Pod:
kubectl exec -it pod/myapp-79579b5b68-npb2g -- bash - 在Pod内执行
ss -tulpn查看端口监听状态,会发现nginx进程仅监听80端口,不存在8080端口的监听记录。 - 在Pod内分别执行两个curl命令验证:
curl http://127.0.0.1:80:可以正常返回nginx默认首页curl http://127.0.0.1:8080:直接返回连接拒绝错误
解决方案
两种方案二选一即可,优先选择第一种,配置成本最低。
方案1:修改端口配置匹配nginx默认监听规则
调整YAML中的端口配置,让Service的targetPort指向容器实际监听的80端口即可。如果需要对外保持8080作为访问端口,仅需修改targetPort,无需调整Service的port字段。修正后的参考YAML如下:
apiVersion: apps/v1 kind: Deployment metadata: name: myapp labels: app: myapp spec: selector: matchLabels: app: myapp template: metadata: labels: app: myapp spec: containers: - name: myapp image: nginx:latest resources: limits: memory: "128Mi" cpu: "500m" ports: - containerPort: 80 # 匹配nginx默认监听端口 --- apiVersion: v1 kind: Service metadata: name: myapp-service labels: app: myapp spec: selector: app: myapp type: LoadBalancer ports: - port: 8080 # LoadBalancer对外提供服务的端口,可按需自定义 targetPort: 80 # 指向容器内实际监听的端口 # 建议删除手动配置的nodePort字段,由系统自动分配端口,避免手动指定产生端口冲突
应用修改后的YAML,等待Pod重建完成后,执行curl http://$PUBLIC_IP:8080即可正常访问nginx默认首页。
方案2:自定义nginx配置监听8080端口
如果业务要求容器内必须使用8080端口提供服务,可以通过ConfigMap挂载自定义nginx配置,覆盖容器内默认的/etc/nginx/conf.d/default.conf文件,将nginx监听端口修改为8080后重新部署工作负载即可。
附加排查项(修正端口后仍无法访问时检查)
- 确认本地网络环境没有拦截到AKS LoadBalancer公网IP 8080端口的出向流量
- 执行
kubectl describe service myapp-service查看Events字段,确认LoadBalancer公网IP已正常分配,没有云资源调度失败的报错 - 检查AKS节点关联的NSG规则,确认没有拒绝8080端口、30000-32767 NodePort端口段入站流量的配置
内容的提问来源于stack exchange,提问作者Timothy Pulliam
相关产品推荐
相关产品推荐

