NLB负载均衡

本文详细介绍了Windowsserver2003中网络负载均衡(NLB)的单播和多播两种操作模式的区别。单播模式下,NLB会为所有节点分配相同的MAC地址,导致网络流量负担增加;而在多播模式下,NLB为每个节点分配一个专用的多播MAC地址,但可能需要手动配置路由器和交换机。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

Windows server 2003中提供了网络负载均衡(NLB)功能。NLB的操作模式有单播和多播两种,它们之间有什么区别呢? 

首先,给大家介绍一下NLB的工作原理:当客户向NLB群集(NLB的虚拟IP地址)发起请求时,其实客户的请求数据包是发送到所有的NLB节点,然后运行在NLB节点上的NLB服务根据同样的NLB算法来确定是否应该由自己进行处理,如果不是则丢弃客户的请求数据包,如果是则进行处理。

如何将请求数据包发送到所有的NLB节点是NLB运行的关键之处,单播和多播这两种操作模式就是用于实现这一需求。NLB不支持单个NLB群集中的单播/多播的混合环境;在每一个NLB群集中,该群集中的所有节点都必须配置为多播或单播,否则,此NLB群集将无法正常工作。

单播和多播的运行方式和不同之处分别为:

单播

在单播模式下,NLB重新对每个NLB节点中启用NLB的网络适配器分配MAC地址(此MAC地址称为群集MAC地址),并且所有的NLB节点均使用相同的MAC地址(均使用群集MAC地址),同时NLB修改所有发送的数据包中的源MAC地址,从而使交换机不能将此群集MAC地址绑定在某个端口上。

工作在单播模式下的NLB可以在所有网络环境下正常运行,但是由于它的工作特性,具有以下两个限制:

由于NLB所使用的群集MAC地址没有绑定在某个具体的交换机端口上,所以所有的NLB通讯均通过在交换机的所有端口上广播进行,而不管此端口是否连接了NLB节点,这造成了额外的网络流量负担;

由于所有的NLB节点具有相同的MAC地址,NLB节点之间不能通过自己原有的专用IP地址进行通讯。

 

多播

在多播模式下,NLB不会修改NLB节点启用NLB的网络适配器的MAC地址,而是为它再分配一个二层多播MAC地址专用于NLB的通讯(此MAC地址称为群集MAC地址),这样NLB节点之间可以通过自己原有的专用IP地址进行通讯。但是在多播模式中,NLB节点发送的针对群集IP地址MAC地址ARP请求的ARP回复会将群集IP地址映射到多播MAC地址,而许多路由器或者交换机(包括CISCO的产品)会拒绝这一行为。当出现这种情况时,你必须在路由器和交换机上手动添加静态映射,将群集IP地址映射到群集的多播MAC地址。

Windows Server 2003提供了一个新的特性,称为IGMP 多播,它可以通过使用IGMP协议支持来使交换机只将NLB通讯发送到连接NLB节点的端口,而不是所有交换机端口。但是此特性必须要求交换机支持IGMP侦听,并且要求群集工作在多播模式下。
<think>嗯,用户问的是EKS中NLB负载均衡器的健康检查原理,以及如何查看健康检查的路径端口。这个问题很具体,说明用户可能在搭建或维护Kubernetes服务时遇到了实际配置需求。 用户可能是个DevOps工程师或者云架构师,正在调试EKS上的服务可用性问题。ta特意提到“查看”健康检查路径端口,暗示可能遇到了健康检查失败的状况,需要验证配置。这类问题通常发生在服务部署后无法通过负载均衡器访问的场景。 关于健康检查原理部分,NLB作为四层负载均衡器,其健康检查机制传统负载均衡器不同。需要强调几个关键点:TCP层探测、AWS底层网络直接执行、与kube-proxy的联动。特别要注意说明NodePort的转发机制,这是用户容易混淆的点。 查看路径端口的操作需要分三层展开:首先是Kubernetes的Service配置(用户直接控制的入口),然后是AWS控制台(可视化验证),最后是EC2实例的安全组(容易被忽略的阻塞点)。每个环节都要给出具体命令截图位置提示,因为用户很可能在紧急排障。 注意到用户没有提到Ingress,所以暂时不展开这部分内容。但最后补充的“注意事项”里可以埋个伏笔,提到Ingress健康检查的差异,为后续问题做铺垫。 生成的相关问题要覆盖用户可能遇到的延伸场景:比如如何自定义路径(虽然NLB不支持但用户常会问)、与ALB的对比(用户可能选型错误)、典型排错步骤(实用价值高)。最后一个问题特意设计成诊断工具类,因为能问出这个问题的用户下一步必然要开始排错了。</think>以下是关于EKS中NLB负载均衡器健康检查的工作原理及查看健康检查路径/端口的详细说明: --- ### **一、NLB健康检查工作原理** 1. **工作层级** NLB网络负载均衡器)工作在OSI第4层(传输层),通过TCP协议直接与后端Pod通信。其健康检查机制如下: ```mermaid graph LR A[NLB] -->|TCP探测| B[NodePort] B -->|kube-proxy转发| C[TargetGroup] C -->|路由到| D[Pod IP:Port] ``` - 健康检查请求**绕过Service直接访问Pod**(不同于ALB的7层检查)[^1] - 默认使用**TCP三次握手**验证端口可达性(非HTTP状态码) - 检查频率:默认每30秒,连续失败2次标记为不健康 2. **关键特性** - **路径/协议无关性**:NLB仅检查TCP端口是否开放,**不支持HTTP路径检查**(如`/health`) - **源IP保留**:客户端IP直达Pod,无需`externalTrafficPolicy: Local`(与ALB不同) - **跨可用区检查**:自动在多个AZ部署检查节点 --- ### **二、查看健康检查路径与端口** 由于NLB是4层负载均衡器,其健康检查**仅涉及端口**,不包含路径。查看方法如下: #### **1. 通过Kubernetes Service配置获取** 检查Service的YAML中`healthCheckNodePort`字段(适用于`externalTrafficPolicy: Local`模式): ```yaml apiVersion: v1 kind: Service metadata: name: my-nlb-service annotations: service.beta.kubernetes.io/aws-load-balancer-type: nlb spec: type: LoadBalancer externalTrafficPolicy: Local # 关键配置 ports: - port: 80 targetPort: 8080 healthCheckNodePort: 31080 # 健康检查端口 ``` #### **2. 通过AWS控制台查看** 1. 进入 **EC2控制台 > Target Groups** 2. 选择与EKS Service关联的目标组 3. 在 **Health checks** 标签页查看: - **Protocol**: TCP - **Port**: 显示为`traffic-port`(与Service的`port`一致)或自定义端口 - **Path**: *不存在*(NLB无HTTP路径检查) #### **3. 通过AWS CLI查询** ```bash # 获取目标组ARN TARGET_GROUP_ARN=$(aws elbv2 describe-target-groups \ --query "TargetGroups[?contains(LoadBalancerArns[0],'my-nlb')].TargetGroupArn" \ --output text) # 查看健康检查配置 aws elbv2 describe-target-health \ --target-group-arn $TARGET_GROUP_ARN \ --query "TargetHealthDescriptions[].TargetHealth" \ --output table ``` 输出示例: ``` | Port | Protocol | HealthCheckPort | |-------|----------|-----------------| | 80 | TCP | traffic-port | # 使用服务端口 ``` --- ### **三、注意事项** 1. **端口冲突**:若使用`externalTrafficPolicy: Local`,需确保`healthCheckNodePort`在30000-32767范围内且未被占用 2. **安全组规则**:允许NLB源IP(`172.31.0.0/16`及VPC CIDR)访问健康检查端口 3. **健康检查失败常见原因**: - Pod未监听目标端口 - 节点安全组阻塞请求 - `kube-proxy`规则异常导致流量无法转发 > 注:如需HTTP路径检查,需改用 **ALB Ingress Controller** 配置7层负载均衡[^2]。 --- ### **相关问题** 1. NLB与ALB在EKS中的健康检查机制有何本质区别? 2. 如何为EKS NLB配置自定义健康检查端口(非`traffic-port`)? 3. 当NLB健康检查失败时,如何进行分层故障诊断? 4. 为什么`externalTrafficPolicy: Local`模式下需要单独设置`healthCheckNodePort`? 5. 如何通过Prometheus监控EKS NLB的健康检查状态?
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值