在 Azure Kubernetes 服务（AKS）中配置公共标准负载均衡器

可以在创建群集时或通过更新群集来自定义标准公共负载均衡器的不同设置。 通过这些自定义选项，可以创建满足工作负载需求的负载均衡器。 使用标准负载均衡器，你可以执行以下操作：

• 更改入站池类型。
• 设置或缩放托管出站 IP 的数量。
• 提供自己的自定义出站 IP 或出站 IP 前缀。
• 自定义分配给群集上每个节点的已分配出站端口数。
• 为空闲连接配置超时设置。

在您开始之前

• 按照 在 Azure Kubernetes 服务中使用公共标准负载均衡器（AKS）中的 步骤在 AKS 中创建和部署负载均衡器服务。

更改入站池类型

可以通过负载均衡器后端池的 IP 配置（基于 Azure 虚拟机规模集的成员身份）或其 IP 地址来引用 AKS 节点。 更新服务和预配负载均衡器时，基于 IP 地址的后端池成员身份可提供更高的效率，尤其是在高节点计数下。 与 NAT 网关 或 用户定义的路由出口 类型结合使用时，新节点和服务预配的性能更高。

提供了两种不同的池成员身份类型：

• nodeIPConfiguration：基于传统虚拟机规模集 IP 配置的池成员资格类型。
• nodeIP：基于 IP 的成员身份类型。

更改入站池类型的条件

在更改入站池类型之前，请确保满足以下要求：

• AKS 群集的版本必须为 1.23 或更高版本。
• AKS 群集必须使用标准负载均衡器和虚拟机规模集。

缩放受管理出站公共 IP 的数量

Azure 负载均衡器从 VNet 提供出站和入站连接。 使用出站规则可以方便地配置公共标准负载均衡器的出站网络地址转换。

出站规则遵循与负载均衡和入站 NAT 规则相同的语法： 前端 IP + 参数 + 后端池

出站规则为后端池标识的所有虚拟机（VM）配置出站 NAT，以转换为前端。 参数针对出站 NAT 算法提供更大的控制度。

虽然可以将出站规则与单个公共 IP 地址配合使用，但出站规则非常适合缩放出站 NAT，因为它们减轻了配置负担。 可以使用多个 IP 地址规划大规模方案，并可以使用出站规则来缓解容易出现 SNAT 耗尽的模式。 前端提供的每个 IP 地址可提供 64,000 个临时端口，供负载均衡器用作 SNAT 端口。

使用具有（默认创建的）托管出站公共 IP 的标准 SKU 负载均衡器时，可以使用 参数缩放托管出站公共 IP 的数量--load-balancer-managed-outbound-ip-count。

设置托管出站公共 IP 地址的数量

提供自己的出站公共 IP 或前缀

使用标准 SKU 负载均衡器时，默认情况下，AKS 群集会自动在 AKS 管理的基础结构资源组中创建公共 IP 并将其分配给负载均衡器出站池。

AKS 创建的公共 IP 是 AKS 受管理资源，这意味着 AKS 管理该公共 IP 的生命周期，并且不需要用户直接对公共 IP 资源执行操作。 或者，你可以在群集创建时分配自己的自定义公共 IP 或公共 IP 前缀。 还可以在现有群集的负载均衡器属性上更新自定义 IP。

使用自己的出站公共 IP 或前缀的要求

在提供自己的出站公共 IP 或前缀之前，请确保满足以下要求：

• 必须创建并拥有自定义公共 IP 地址。 不能重复使用 AKS 创建的托管公共 IP 地址作为“自带自定义 IP”，因为它可能会导致管理冲突。
• 必须确保 AKS 群集标识具备权限以便根据 所需的公共 IP 权限列表进行访问出站 IP。
• 请确保满足配置出站 IP 或出站 IP 前缀所需的 先决条件和约束 。

提供您自己的出站公共 IP

提供自己的出站公共 IP 前缀

配置分配的出站端口

默认情况下，AKS 在其负载均衡器上将 0 设置为，这会在创建群集时基于后端池大小启用自动出站端口分配。 例如，如果群集有 50 个或更少的节点，则向每个节点分配 1024 个端口。 使用此值，可以缩放到群集最大节点计数，而无需重新配置网络，但随着添加更多节点，可能导致 SNAT 端口耗尽现象更为常见。 随着群集中节点数的增加，每个节点可用的端口将减少。 在图表中跨边界增加节点计数（例如，从 50 个节点增加到 100 个节点或 100 到 101）可能会中断连接，因为分配给现有节点的 SNAT 端口会减少，以允许更多节点。 建议对 AllocatedOutboundPorts 使用显式值。

查看当前分配的出站端口

• 使用命令获取 AKS 群集负载均衡器的 az network lb outbound-rule list 值。

  NODE_RG=$(az aks show --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --query nodeResourceGroup -o tsv)
  az network lb outbound-rule list --resource-group $NODE_RG --lb-name kubernetes -o table
  

  以下示例输出显示为群集启用基于后端池大小的自动出站端口分配：

  AllocatedOutboundPorts    EnableTcpReset    IdleTimeoutInMinutes    Name             Protocol    ProvisioningState    ResourceGroup
  ------------------------  ----------------  ----------------------  ---------------  ----------  -------------------  -------------
  0                         True              30                      aksOutboundRule  All         Succeeded            MC_myResourceGroup_myAKSCluster_chinanorth3
  

计算并验证所需的出站端口和 IP

为出站端口或出站 IP 地址设置特定值或增加现有值之前，必须计算出站端口和 IP 地址的适当数量。 使用以下公式将此计算舍入为最接近的整数：64,000 ports per IP / <outbound ports per node> * <number of outbound IPs> = <maximum number of nodes in the cluster>。

计算出站端口和 IP 的注意事项

计算出站端口和 IP 数并设置值时，请记住以下信息：

• 根据你设置的值，每个节点的出站端口数为固定值。
• 出站端口数的值必须是 8 的倍数。
• 添加更多 IP 不会将更多端口添加到任何节点，但会为群集中的更多节点提供容量。
• 必须考虑可能在升级过程中添加的节点，包括通过maxCount和maxSurge指定的节点数量和值。

计算出站端口和 IP 的示例

以下示例显示了你所设置的值会如何影响出站端口和 IP 地址的数量：

• 如果使用默认值，并且群集有 48 个节点，则每个节点有 1024 个端口可用。
• 如果使用默认值，并且群集的节点从 48 个增加到 52 个，则每个节点都会从 1024 个端口可用更新为 512 个端口可用。
• 如果出站端口数设置为 1,000 并且出站 IP 数设置为 2，则群集最多可以支持 128 个节点：64,000 ports per IP / 1,000 ports per node * 2 IPs = 128 nodes。
• 如果出站端口数设置为 1,000 并且出站 IP 数设置为 7，则群集最多可以支持 448 个节点：64,000 ports per IP / 1,000 ports per node * 7 IPs = 448 nodes。
• 如果出站端口数设置为 4,000 并且出站 IP 数设置为 2，则群集最多可以支持 32 个节点：64,000 ports per IP / 4,000 ports per node * 2 IPs = 32 nodes。
• 如果出站端口数设置为 4,000 并且出站 IP 数设置为 7，则群集最多可以支持 112 个节点：64,000 ports per IP / 4,000 ports per node * 7 IPs = 112 nodes。

设置分配的出站端口和出站 IP

计算并验证这些值后，可以在创建或更新集群时使用 load-balancer-outbound-ports 以及 load-balancer-managed-outbound-ip-count、load-balancer-outbound-ips 或 load-balancer-outbound-ip-prefixes 来应用这些值。

配置负载均衡器的空闲超时

如果 SNAT 端口资源已经耗尽，那么在现有流释放 SNAT 端口之前出站流会失败。 当流关闭时，负载均衡器将回收 SNAT 端口，AKS 配置的负载均衡器将使用 30 分钟空闲超时回收空闲流中的 SNAT 端口。 还可以使用传输（例如 TCP keepalives 或 application-layer keepalives）刷新空闲流，并在必要时重置此空闲超时。

如果你希望具有许多短生存期的连接，而不想有长生存期且可能有长时间空闲的连接（例如使用 kubectl proxy 或 kubectl port-forward），请考虑使用低超时值（如 4 分钟）。 使用 TCP keepalive 时，在连接的一端启用它们就足够了。 例如，若要重置流的空闲计时器，在服务器端启用这些连接就足够了。 没有必要在两端都启动 TCP keepalive。 应用程序层（包括数据库客户端-服务器配置）也存在类似的概念。 检查服务器端对于特定于应用程序的 keepalive 存在哪些选项。

将 IdleTimeoutInMinutes 设置为与默认值 30 分钟不同的值时，请考虑工作负荷需要出站连接的时间。 另请考虑在 AKS 外部使用 的标准 SKU 负载均衡器的默认超时值为 4 分钟。 如果 IdleTimeoutInMinutes 值较准确地反映你的具体 AKS 工作负载，则有助于降低由于绑定不再使用的连接而导致的 SNAT 耗尽。

将入站流量限制为特定 IP 范围

以下清单使用 loadBalancerSourceRanges 为外部流量入站指定新的 IP 范围。

apiVersion: v1
kind: Service
metadata:
  name: azure-vote-front
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: azure-vote-front
  loadBalancerSourceRanges:
  - MY_EXTERNAL_IP_RANGE

此示例将规则更新为仅允许 MY_EXTERNAL_IP_RANGE 范围内的入站外部流量。 如果将 MY_EXTERNAL_IP_RANGE 替换为内部子网 IP 地址，则流量将限制为仅群集内部 IP。 如果流量限制为群集内部 IP，则 Kubernetes 群集外部的客户端无法访问负载均衡器。

维护入站连接上的客户端 IP

默认情况下，LoadBalancer 和 AKS 中类型的服务不会在与 Pod 的连接上保留客户端的 IP 地址。 传递到 Pod 的数据包上的源 IP 会成为节点的专用 IP。 若要维护客户端的 IP 地址，必须在服务定义中设置为service.spec.externalTrafficPolicylocal。 以下清单显示了一个示例：

apiVersion: v1
kind: Service
metadata:
  name: azure-vote-front
spec:
  type: LoadBalancer
  externalTrafficPolicy: Local
  ports:
  - port: 80
  selector:
    app: azure-vote-front

通过 Kubernetes 注释进行自定义

类型为 LoadBalancer 的 Kubernetes 服务支持以下批注，这些批注仅适用于 INBOUND 流。

自定义允许的 IP 范围（预览版）

可以使用 azure-allowed-service-tags 和 azure-allowed-ip-ranges 注释在负载均衡器上合并 CIDR 块和 Azure 服务标记。 添加 service.beta.kubernetes.io/azure-allowed-ip-ranges 以逗号分隔的 IP 前缀列表，并添加 service.beta.kubernetes.io/azure-allowed-service-tags 一个或多个 Azure 服务标记。 AKS 云提供商将这两个值合并到单个 NSG 规则中，因此流量在 NSG 中集中筛选，为 IP 地址和服务标记提供一个以 NSG 为中心的控制平面。

对于需要在 NSG 和主机中强制实施基于 CIDR 的限制的情况，可以继续使用 loadBalancerSourceRanges 该属性。 不能将此属性与批注一起使用 azure-allowed-service-tags 。 如果同时指定了两者，则 AKS 在尝试应用负载均衡器服务规范时报告错误。

自定义负载均衡器运行状况探测

支持下列标注来自定义负载均衡器健康探测行为。

默认健康探测行为

当前，健康探测的默认协议会因不同服务的传输协议、应用协议、注释和外部流量策略而有所不同。

• 对于本地服务，将使用 HTTP 和 /healthz。 健康探测将查询 NodeHealthPort 而不是实际的后端服务。
• 对于群集 TCP 服务，将使用 TCP。
• 对于群集 UDP 服务，没有运行状况探测。

健康探测请求路径注释

从 Kubernetes 版本 1.20 开始，引入了服务注释 service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path 来确定运行状况探测行为。

• 对于 <=1.23 的群集，spec.ports.appProtocol 仅在设置 service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path 时用作探测协议。
• 对于 >1.24 的群集，spec.ports.appProtocol 将用作探测协议，/ 将用作默认探测请求路径（service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path 可用于更改为其他请求路径）。

请注意，使用 TCP 或 spec.ports.appProtocol 为空时，将忽略请求路径。 下表汇总了默认运行状况探测行为：

运行状况探测的间隔时间和探测注释数量

从 Kubernetes 版本 1.21 开始，引入了两个服务注释 service.beta.kubernetes.io/azure-load-balancer-health-probe-interval ， load-balancer-health-probe-num-of-probe 用于自定义运行状况探测的配置。 如果未 service.beta.kubernetes.io/azure-load-balancer-health-probe-interval 设置，则应用默认值 5 。 如果未 load-balancer-health-probe-num-of-probe 设置，则应用默认值 2 。

端口的自定义负载均衡器运行状况探测

服务中的不同端口可能需要不同的运行状况探测配置。 这可能是由于服务设计（例如控制多个端口的单个运行状况终结点）或 Kubernetes 功能（如 MixedProtocolLBService）导致的。

下表汇总了特定于端口的注释，这些注释可用于覆盖服务中特定端口的全局健康探测注释：

后续步骤

若要了解有关 Kubernetes 服务的详细信息，请参阅 Kubernetes 服务文档。

若要详细了解如何将内部负载均衡器用于入站流量，请参阅 AKS 内部负载均衡器文档。