Azure Load Balancer适配Istio Ingress配置不符问题咨询

当前配置是否符合预期？ #

不符合你的预期。你的目标是让Azure负载均衡器前端9080端口的流量，先转发到某个NodePort，再由该NodePort路由至Istio Ingress ClusterIP的8090端口，但当前配置的流量路径完全不同。

配置差异与工作机制解析 #

1. Kubernetes Service配置逻辑 #

你提供的Kubernetes清单是一个LoadBalancer类型的Service（虽然清单未显式声明type: LoadBalancer，但Azure负载均衡器的存在证明了这一点），核心规则如下：

apiVersion: v1
kind: Service
metadata:
  name: istio-ingressgateway
  #namespace: istio-system
spec:
  selector:
    istio: ingressgateway
  ports:
  - name: http
    port: 9080          # Service对外暴露的集群内端口
    targetPort: 8080    # 流量最终转发到Pod的8080端口

这个Service的作用是：匹配标签为istio: ingressgateway的Pod，将发送到Service 9080端口的流量直接转发到这些Pod的8080端口。

2. Azure负载均衡器自动生成的配置逻辑 #

Azure会根据Kubernetes的LoadBalancer Service自动生成对应负载均衡规则，从你提供的JSON视图可拆解关键逻辑：

• 负载均衡规则：前端端口9080，后端端口9080，协议为TCP。这里的后端端口9080对应Kubernetes Service的端口，实际流量会被转发到集群节点上自动分配的NodePort（即探针中显示的32700）。
• 健康探针：使用TCP协议探测节点的32700端口（该Service对应的NodePort），确保节点能正常接收流量。

3. 当前实际流量路径 #

外部请求 → Azure负载均衡器前端9080端口 → 集群节点的NodePort（32700） → Kubernetes Service → 标签匹配的istio-ingressgateway Pod的8080端口

而你期望的路径是：外部请求 → Azure负载均衡器前端9080 → NodePort → Istio Ingress ClusterIP的8090端口，两者核心差异在于：

• 当前配置直接将流量转发到istio-ingressgateway Pod的8080端口，未经过Istio Ingress ClusterIP的8090端口
• 不存在你所说的“NodePort路由至Istio Ingress ClusterIP”的环节

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