返回列表

Azure 干净 IP 注册号 Azure微软云负载均衡配置

微软云Azure / 2026-04-15 13:25:50

你刚连上跳板机，想远程进那台新部署的Windows Server——鼠标点开远程桌面，输入IP，回车……

黑屏。三秒后弹窗：“连接被拒绝”。

Azure 干净 IP 注册号 你揉了揉眼睛，确认防火墙关了、RDP服务启了、NSG也放行了3389……可它就是不给你开门。

这时候别急着重装系统——大概率，是你漏掉了那个叫Azure Load Balancer的“隐形门卫”。它不声不响站在你VM前面，手里攥着流量钥匙，而你还没给它配一把能开门的钥匙。

别慌。这篇不是PPT式说明书，也不是Azure官网翻译腔合集。咱们就坐你工位边儿上，泡杯浓咖啡，一边敲命令一边聊清楚：Azure负载均衡到底怎么配？公网和内网有啥区别？为什么健康探测老失败？NAT规则和负载均衡规则傻傻分不清？后端池加了VM却一直灰色？……全给你捋直了。

先划重点：Azure LB不是个‘开了就通’的开关，它是个需要你亲手组装的乐高套装——少一块，整个塔就塌。

一、搞清身份：你到底要配哪种LB？

Azure里叫“负载均衡”的东西有仨，但真正在控制台里叫Azure Load Balancer的，特指那个基于四层（TCP/UDP）、纯IP级转发的家伙。别跟Application Gateway（七层HTTP/HTTPS）或Traffic Manager（DNS级全局调度）混了——它们名字带‘均衡’，干的活儿天差地别。

Azure LB分两种：公网型（Public）和内网型（Internal）。选错就像给家门装了个机场安检口——对外暴露的Web服务必须用公网LB；VNet内部微服务互调，比如K8s NodePort后端，就该用内网LB。混着用？轻则连不通，重则安全告警半夜轰炸你邮箱。

二、四件套：LB不是单打独斗，是团队作战

一个能干活的Azure LB，必须凑齐以下四件套，缺一不可：

前端IP配置（Frontend IP Config）：相当于LB的“门牌号”。公网LB绑公网IP（需提前创建Standard SKU），内网LB绑VNet子网里的私有IP（自动分配或手动指定）。
后端地址池（Backend Pool）：即“干活的人名单”。填的是VM的NIC私网IP（不是VM本身ID！），且这些VM必须跟LB在同一个VNet（或通过对等连接可达）。常见错误：填了VM公网IP、填了VM名称、或者VM根本不在同VNet——结果池里显示“0个实例”，还纳闷为啥没流量。
运行状况探测（Health Probe）：LB的“查岗小队长”。它定期（默认15秒）向后端发TCP连接或HTTP GET请求，连续2次失败就踢出池子。注意：探测端口必须是后端服务真实监听的端口（比如IIS用80，就别设成8080），且NSG/防火墙必须放行该探测端口——很多故障根源在此。
负载均衡规则（Load Balancing Rule）：决定“谁进谁出”。它把前端IP+端口，映射到后端池+端口，并关联探测。支持轮询（Round Robin）、源IP亲和性（Source IP Affinity）等分发模式。若只需做端口转发（如公网22→后端VM的22），那就用入站NAT规则（Inbound NAT Rule），它优先级高于LB规则，且每条NAT规则只对应一台后端VM。

三、动手实操：从零配一个公网Web LB（含命令行）

假设：你有两台Ubuntu VM（web-01/web-02），已装好Nginx并监听80端口，位于vnet-prod的subnet-web中。目标：用公网LB将流量均分到它们。

Step 1：创建公网IP（Standard SKU！）
⚠️ 关键！Basic SKU的公网IP不支持LB，会直接报错。

az network public-ip create \
  --resource-group rg-prod \
  --name pip-lb-web \
  --sku Standard \
  --allocation-method Static

Step 2：创建Load Balancer

az network lb create \
  --resource-group rg-prod \
  --name lb-web \
  --sku Standard \
  --public-ip-address pip-lb-web \
  --frontend-ip-name feip-web \
  --backend-pool-name bepool-web

Step 3：配置健康探测
我们用简单的TCP探测（比HTTP更轻量，适合Nginx）：

az network lb probe create \
  --resource-group rg-prod \
  --lb-name lb-web \
  --name probe-http \
  --protocol tcp \
  --port 80 \
  --interval 15 \
  --threshold 2

Step 4：添加后端池成员
找到两台VM的NIC ID（用az vm nic list -g rg-prod --vm-name web-01），然后逐个加：

az network nic ip-config address-pool add \
  --address-pool bepool-web \
  --ip-config-name ipconfig1 \
  --nic-name web-01-nic \
  --resource-group rg-prod \
  --lb-name lb-web

Step 5：建负载均衡规则

az network lb rule create \
  --resource-group rg-prod \
  --lb-name lb-web \
  --name http-rule \
  --protocol tcp \
  --frontend-port 80 \
  --backend-port 80 \
  --frontend-ip-name feip-web \
  --backend-pool-name bepool-web \
  --probe-name probe-http \
  --disable-outbound-snat true

最后一句--disable-outbound-snat true很重要！否则后端VM出向流量会被LB SNAT，导致日志里看到的源IP全是LB的，排查链路时抓瞎。

四、高频翻车现场 & 救命锦囊

“后端池一直灰色/0实例”→ 检查NIC是否已绑定到池（az network nic show看ipConfigurations[].loadBalancerBackendAddressPools）、VM是否运行中、NSG是否放行探测端口。
“能ping通LB IP，但telnet端口超时”→ 八成是LB规则没生效，或后端服务压根没监听（ss -tlnp | grep :80确认）。
“配完还是连不上RDP”→ 别用LB规则！RDP是单用户协议，用Inbound NAT Rule为每台VM单独映射（如LB 50001→VM1的3389，50002→VM2的3389）。
“升级到Standard SKU后原有资源挂了”→ Basic和Standard不兼容！LB、公网IP、可用性集都需重建，没有平滑迁移。

五、最后送你一句真·经验

在Azure里，最贵的不是资源费用，而是你对着控制台发呆的半小时。每次配LB前，拿出一张纸，画四格：前端IP、后端池、探测、规则——每填一项，打个钩；填完再交叉验证：探测端口=后端监听端口？规则端口=应用实际端口？NSG放行了探测和业务端口？NIC真绑上了？

配完，别急着庆祝。立刻执行：curl -v http://[你的LB公网IP]，看返回是不是你预期的页面；再登录任意一台后端VM，sudo tcpdump -i any port 80，确认流量真进来了。

毕竟，在云上，看不见的流量，等于不存在的业务。

好了，现在你可以关掉这篇文章，打开Cloud Shell，去配你那个卡了三天的LB了——这次，它应该会乖乖开门了。