Kubernetes 为什么AKS创建的Azure负载平衡器设置为将流量定向到节点上的端口80和443，而不是由服务打开的节点报告？

我有一个带有nginx入口控制器的AKS集群。控制器已创建了一个具有LoadBalancer类型的服务，端口部分如下所示（来自

kubectl get service

）：

80:31141/TCP

如果我理解正确，端口80是一个无法从外部访问的ClusterIp端口，但端口31141是一个节点端口，可以从外部访问。因此，我假设Azure负载平衡器正在向这个31141端口发送流量

我惊讶地发现Azure负载平衡器是按照以下规则设置的：

frontendPort: 80
backendPort: 80
probe (healthCheck): 31141

因此，它实际上使用节点端口，但仅作为健康检查，所有流量都发送到端口80，其功能可能与31141相同

一个奇怪的注意事项是，如果我试图从pod到达端口80处的节点IP，我只会得到“连接被拒绝”，但我想如果流量来自负载平衡器，它会起作用

我在互联网上找不到任何关于这方面的信息，所以问题是这到底是如何工作的，ALB为什么要这样做

---

另外，我在连接方面没有问题，它可以工作。我只是想了解它是如何以及为什么在幕后进行的。

正如我看到的，您对入口端口有一些误解。让我向您展示一些有关AKS入口的详细信息

入口信息：

从屏幕截图中，端口80和443是Azure LB的端口，您可以通过与LB关联的公共IP从Internet访问这些端口，这里的公共IP是40.121.64.51。端口31282和31869是您无法从Internet访问的AKS节点的端口，您只能通过节点专用IP从vnet访问它们

Azure LB信息：

希思探测器：

lb规则：

从屏幕截图中，您可以看到Azure LB的健康探测器和规则。它使用它们将流量从Internet重定向到AKS节点的端口，这些节点是Azure LB的后端

希望它能帮助您了解AKS入口的流量

更新：

LB规则信息：

---

我想我已经弄明白了它是如何工作的（免责声明：我的理解可能不正确，如果错误请纠正我）

发生的情况是，负载平衡流量既不会到达端口80上的节点本身，也不会到达打开的节点端口（在我的例子中是31141）。相反，发送到节点的流量不是由节点本身“处理”，而是在iptables的帮助下进一步路由。因此，如果一些通信量到达目标IP为LB frontendIP和端口80的节点，它将进入服务并进一步进入pod

---

至于健康检查，我认为它不使用相同的端口80，因为请求的目的地不等于外部IP（LB前端IP），而是直接等于节点本身，因此它使用服务节点端口。

谢谢回答，我仍然不完全理解。10.0.151.179是服务的专用IP，而不是节点（如果我理解正确的话）（至少我有一个不同的节点），负载平衡器被设置为向节点发送端口80/443的流量，尽管入口控制器的节点端口是31282/31869。当我尝试访问节点ip:80（从pod）时，连接被拒绝，尽管节点ip:31282按预期工作。所以真正的问题是，为什么负载平衡器不进行从80到31282的映射，以及如果节点拒绝连接，它如何工作。80:31282表示clusterip/nodeip，我想。@IlyaChernomordik端口80和443不是节点的端口，而是LB的端口。因此您无法通过节点ip:80访问。例如，流量将从internet到LB的端口80，然后到LB的后端，这意味着AKS节点，然后到节点的端口31282，最后到服务的ip。@Ilyachermordik ip 10.0.151.179是服务ip，这是我的错误，我已经更新了答案。也许我不明白规则是如何运作的？据我所见，规则设置为将80和443发送到后端池，该后端池将我的群集节点发送到同一端口80和443？你提供的屏幕截图看起来是一样的，而节点端口“仅仅”是健康检查，我最近也在考虑同样的问题！您是否找到了可以证明您当前理论的更多信息（如何从门户、CLI或其他地方获取此iptables配置）？我猜之所以会显示令人困惑的LB端口配置，是因为后端端口没有实际设置，在某种程度上，在这种情况下，有逻辑返回frontendPort，比如：backendPort！="" ? 后端端口：前端端口，最后，这种神奇是如何发生的？由于pod位于节点内部，因此请求必须由节点“处理”，对吗？我没有获得更多信息，但我认为，为了证明我的理论，您可以通过ssh连接到节点本身（您可以通过pod实现，azure docs对此有很好的解释），然后，您可以通过检查iptables或类似内容来分析kubernetes的所有内部事务，看看它到底在做什么