1

我有一个带有 nginx 入口控制器的 AKS 集群。Controller 已经创建了一个类型为 LoadBalancer 的服务，Ports 部分如下所示（来自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 会这样做？

PS我没有连接问题，它可以工作。我只是想了解它在幕后的方式和原因。

4

2 回答 2

2

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

入口信息：

在此处输入图像描述

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

Azure LB 信息：

健康探针：

在此处输入图像描述

磅规则：

在此处输入图像描述

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

希望它可以帮助您了解 AKS 中的入口流量。

更新：

LB规则信息：

在此处输入图像描述

于 2019-07-24T02:08:59.223 回答
2

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

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

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

于 2019-07-25T08:16:48.093 回答