AZ-104负载均衡器配置全流程（含官方考试评分标准解读）

最新推荐文章于 2025-11-30 14:05:12 发布

原创最新推荐文章于 2025-11-30 14:05:12 发布 · 939 阅读

CC 4.0 BY-SA版权

第一章：MCP AZ-104 负载均衡器设置概述

Azure 负载均衡器是 Microsoft Azure 提供的核心网络服务，用于在多个虚拟机实例之间分配入站和出站流量，以实现高可用性和可伸缩性。它支持公共和内部负载均衡场景，并可在传输层（第 4 层）基于 TCP 或 UDP 协议进行流量分发。

基本架构与组件

Azure 负载均衡器由以下几个关键组件构成：

前端 IP 配置：接收来自客户端的流量，可为公共 IP 或私有 IP。
后端池：包含处理请求的虚拟机实例，通过 NIC 关联到负载均衡器。
负载均衡规则：定义如何将流量从前端端口映射到后端池中的实例。
探测健康状态：定期检查后端实例的可用性，确保只将流量发送至健康的节点。

创建负载均衡器的 CLI 示例

使用 Azure CLI 创建一个基础的公共负载均衡器：


# 创建资源组
az group create --name MyResourceGroup --location eastus

# 创建公共 IP 地址
az network public-ip create --resource-group MyResourceGroup --name MyPublicIP --sku Standard

# 创建负载均衡器并绑定公共 IP
az network lb create \
  --resource-group MyResourceGroup \
  --name MyLoadBalancer \
  --public-ip-address MyPublicIP \
  --frontend-ip-name MyFrontend \
  --backend-pool-name MyBackendPool

上述命令首先创建资源组和标准 SKU 的公共 IP，随后初始化负载均衡器并配置前端与后端池。

常见配置对比

特性	标准负载均衡器	基本负载均衡器
高可用性端口	支持	不支持
区域冗余	支持	不支持
出站规则	可自定义	自动映射

graph LR A[客户端] --> B[公共负载均衡器] B --> C[VM 实例 1] B --> D[VM 实例 2] B --> E[VM 实例 3] C --> F[健康探测响应] D --> F E --> F

第二章：负载均衡器核心概念与架构解析

2.1 Azure负载均衡器类型对比与选型策略

Azure提供两种核心负载均衡器：公共负载均衡器和内部负载均衡器。前者面向公网流量，适用于需要对外暴露服务的场景；后者专用于虚拟网络内部通信，保障后端服务间的安全访问。

关键特性对比

特性	公共负载均衡器	内部负载均衡器
网络位置	公网入口	私有子网
前端IP类型	公共IP	私有IP
典型用途	Web服务器集群	数据库高可用组

配置示例

{
  "frontendIPConfigurations": [
    {
      "name": "LoadBalancerFrontEnd",
      "properties": {
        "publicIPAddress": { "id": "/subscriptions/.../publicIPAddresses/myPublicIP" }
      }
    }
  ]
}

上述JSON片段定义了一个公共前端IP配置，publicIPAddress 引用了已分配的公共IP资源，是公共负载均衡器的核心组件之一。

2.2 公共和内部负载均衡器的工作原理

负载均衡器是现代分布式系统中流量调度的核心组件，根据部署位置和访问范围，可分为公共和内部两类。

公共负载均衡器

面向互联网用户提供服务，通常位于公网入口，接收来自外部客户端的请求。它可基于DNS或IP直接暴露在公网上，常用于Web应用前端。

内部负载均衡器

运行在私有网络内部，用于微服务之间的通信调度，提升后端服务的可用性和响应速度。

类型	访问范围	典型协议
公共	Internet	HTTP/HTTPS, TCP
内部	Private Network	TCP, gRPC

// 示例：Golang中模拟简单负载均衡策略
func NextServer(servers []string) string {
    return servers[atomic.AddUint64(&index, 1)%uint64(len(servers))]
}

该代码实现轮询算法，通过原子操作保证并发安全，适用于内部服务间调用的负载分发。

2.3 前端IP配置与后端池设计原则

在负载均衡架构中，前端IP配置决定了流量入口的可达性与安全性。建议采用静态公网IP绑定前端IP，并结合DNS解析实现高可用访问。

前端IP配置示例

{
  "frontend": {
    "ip": "203.0.113.10",
    "port": 443,
    "protocol": "HTTPS",
    "ssl-cert": "cert-arn:aws:acm:..."
  }
}

该配置指定了HTTPS协议下的前端接入点，IP固定便于防火墙策略管理，SSL证书ARN确保加密传输。

后端池设计原则

按服务类型划分后端组（如API、静态资源）
启用健康检查机制，间隔建议5~10秒
采用加权轮询算法，根据服务器性能分配权重
跨可用区部署以提升容灾能力

合理的设计可显著提升系统可用性与响应效率。

2.4 健康探测机制与流量分发算法详解

健康探测是保障服务高可用的核心机制，通过定期对后端节点发起存活检测，及时剔除异常实例。常见的探测方式包括HTTP、TCP和执行脚本三种类型。

健康检查配置示例

health_check:
  protocol: http
  path: /healthz
  interval: 5s
  timeout: 2s
  unhealthy_threshold: 3

上述配置表示每5秒发送一次HTTP请求至/healthz路径，超时2秒即判定失败，连续3次失败后将节点标记为不健康。

主流负载均衡算法对比

算法	特点	适用场景
轮询（Round Robin）	顺序分发，简单公平	节点性能相近
最小连接数	优先调度至连接最少节点	长连接服务
加权哈希	基于IP哈希并结合权重	会话保持需求

2.5 高可用性与跨区域部署理论基础

高可用性（HA）确保系统在面对硬件故障或网络中断时仍能持续提供服务。实现高可用的关键在于消除单点故障，并通过冗余设计提升系统容错能力。

数据同步机制

在跨区域部署中，数据一致性是核心挑战。常用策略包括异步复制与同步复制：

同步复制：保证强一致性，但增加延迟
异步复制：提升性能，但存在短暂数据不一致窗口

典型架构示例

// 模拟跨区域健康检查路由逻辑
func SelectRegion(regions map[string]HealthStatus) string {
    for region, status := range regions {
        if status.Available && status.Latency < 200 {
            return region // 优先选择低延迟可用区
        }
    }
    return "primary" // 回退到主区域
}

上述代码展示了基于健康状态和延迟的区域选择策略，适用于全局负载均衡决策。参数 Available 表示节点存活状态，Latency 用于优化用户体验。

第三章：实战环境准备与资源部署

3.1 使用Azure门户创建虚拟网络与子网

在Azure门户中创建虚拟网络是构建云基础设施的第一步。通过图形化界面，用户可以直观地配置网络地址空间和子网划分。

创建虚拟网络步骤

登录Azure门户，导航至“虚拟网络”服务
点击“创建”，填写名称、地址空间（如10.1.0.0/16）
在子网配置中指定名称和子网范围（如10.1.0.0/24）
选择资源组与地理位置后完成部署

子网规划建议

子网用途	推荐CIDR块	说明
前端Web层	10.1.0.0/24	面向公网的应用服务器
后端服务	10.1.1.0/24	数据库等内部服务

合理规划地址空间可避免后续网络冲突，确保可扩展性。

3.2 配置NIC与后端虚拟机实例

在构建高可用云网络架构时，正确配置网络接口控制器（NIC）与后端虚拟机实例是实现负载均衡和流量分发的关键步骤。

NIC绑定配置示例

# 绑定辅助网卡至虚拟机实例
ip link set eth1 up
ip addr add 192.168.2.10/24 dev eth1
ip route add default via 192.168.2.1 dev eth1 table secondary

上述命令启用附加NIC并配置独立路由表，确保特定流量通过指定接口转发。eth1作为辅助网卡，提升带宽冗余与故障切换能力。

虚拟机网络参数规划

参数	值	说明
IP地址	192.168.1.100	主网卡私有IP
子网掩码	255.255.255.0	标准/24子网
默认网关	192.168.1.1	接入层路由器IP

3.3 设置NSG规则保障负载均衡通信安全

在Azure环境中，网络安全性组（NSG）是控制虚拟网络流量的关键组件。为确保负载均衡器与后端实例间的通信安全，必须精确配置入站和出站规则。

核心安全规则配置

通过以下规则允许健康探测和前端流量：

{
  "direction": "Inbound",
  "protocol": "Tcp",
  "sourcePortRange": "*",
  "destinationPortRange": "80",
  "sourceAddressPrefix": "Internet",
  "destinationAddressPrefix": "10.0.1.0/24",
  "access": "Allow",
  "priority": 1010,
  "description": "Allow HTTP from Load Balancer"
}

该规则允许来自互联网的HTTP流量进入后端子网，优先级1010确保其在默认拒绝规则前生效。其中，sourceAddressPrefix 可进一步限制为负载均衡器的公共IP，提升安全性。

健康探测通信保障

必须允许负载均衡器探测后端实例健康状态：

开放端口80或自定义探测端口
来源地址设为“AzureLoadBalancer”服务标签
禁止其他源地址访问探测端口

最小化开放端口范围，遵循最小权限原则，可有效降低攻击面。

第四章：负载均衡器配置与验证全流程

4.1 创建公共标准负载均衡器并配置前端

在 Azure 中创建公共标准负载均衡器是构建高可用网络架构的关键步骤。首先需通过 Azure 门户或 CLI 定义负载均衡器类型为“公共”并选择“标准”层级。

资源配置流程

指定资源组与区域，确保与后端虚拟机一致
创建公共 IP 地址并关联至负载均衡器前端
配置前端 IP 配置，绑定公共 IP

CLI 创建示例


az network lb create \
  --name myPublicLB \
  --resource-group myRG \
  --sku Standard \
  --public-ip-address myPublicIP \
  --frontend-ip-name myFrontend

上述命令创建标准层级的负载均衡器，并自动关联已有的公共 IP。参数 --sku Standard 确保启用高级路由与可用性集集成，--frontend-ip-name 指定前端配置名称，用于后续规则引用。

4.2 定义后端池与健康探测端点

在负载均衡架构中，后端池（Backend Pool）是承载实际业务服务的服务器集合。通过将多个实例注册到后端池，系统可实现请求的分发与容错。

健康探测配置示例

{
  "healthCheckPath": "/healthz",
  "intervalSeconds": 10,
  "timeoutSeconds": 5,
  "unhealthyThreshold": 3
}

上述配置定义了对后端节点每10秒发起一次HTTP GET请求，路径为/healthz；若5秒内未响应则判定超时，连续3次失败后将节点标记为不健康并从流量调度中剔除。

后端池管理策略

动态注册：新实例启动后自动加入后端池
权重分配：根据CPU、内存等资源指标设置转发权重
地域感知：优先调度至与客户端同区域的节点

4.3 配置负载均衡规则与出站规则

在 Azure 负载均衡器中，负载均衡规则用于定义如何将入站流量分发到后端虚拟机实例。每条规则绑定前端 IP、协议、端口、后端池和健康探测。

负载均衡规则配置示例

{
  "name": "LBRule-HTTP",
  "properties": {
    "protocol": "Tcp",
    "frontendPort": 80,
    "backendPort": 80,
    "frontendIPConfiguration": {
      "id": "/frontendIPs/loadBalancerFrontEnd"
    },
    "backendAddressPool": {
      "id": "/backendAddressPools/backendPool1"
    },
    "probe": {
      "id": "/probes/healthProbe"
    }
  }
}

上述 JSON 定义了一条基于 TCP 的规则，将前端 80 端口的请求转发至后端池中各实例的 80 端口，并依赖指定健康探测决定实例可用性。

出站规则配置要点

出站规则控制后端实例访问外部网络的行为。必须显式配置以确保 SNAT（源网络地址转换）正常工作。

指定前端公网 IP 用于出站流量
关联后端地址池和出站端口数
避免因端口耗尽导致连接失败

4.4 验证流量分发效果与故障排查技巧

监控指标验证分发均衡性

通过 Prometheus 抓取各节点请求量、响应延迟和错误率，可直观判断流量分发是否均匀。关键指标包括：

http_requests_total：按实例统计请求数
http_request_duration_seconds：P99 延迟变化
up：后端实例健康状态

日志与链路追踪定位异常

结合 OpenTelemetry 收集分布式追踪数据，在出现 5xx 错误时快速定位故障节点。典型排查流程如下：

查看网关访问日志中的错误码分布
提取对应请求的 trace_id
在 Jaeger 中分析调用链路耗时瓶颈

location /api/ {
    proxy_pass http://backend;
    proxy_set_header X-Real-IP $remote_addr;
    access_log /var/log/nginx/access.log combined;
}

该 Nginx 配置启用了标准日志格式，便于后续使用 ELK 进行结构化解析。其中 $remote_addr 记录客户端真实 IP，有助于识别异常流量来源。

第五章：考试评分标准深度解读与最佳实践总结

评分维度解析

认证考试通常从代码正确性、架构合理性、安全合规性三个维度进行评分。以 Kubernetes CKA 考试为例，每道题按功能实现是否可达分，即使使用非标准方法，只要通过 kubectl describe 验证状态为 Running 且服务可访问，即可得分。

常见失分点分析

未按题目要求命名资源对象（如 Pod 名称错误）
ConfigMap 挂载路径与题干不符
Service 类型误用（应使用 ClusterIP 却配置为 NodePort）
RBAC 权限配置超出最小权限原则

高分策略实战

在实际操作中，建议采用“先验证后提交”模式。例如，在创建 Deployment 时，先通过 dry-run 生成模板：

kubectl create deployment nginx --image=nginx \
  --dry-run=client -o yaml > deploy.yaml

随后在 YAML 中添加资源限制和就绪探针，确保符合生产级规范。

评分权重分布示例

考核项	分值占比	典型错误扣分
Pod 配置	20%	镜像版本错误（-5分）
网络策略	15%	端口开放范围过大（-3分）
持久化存储	25%	PVC 容量不足（-8分）

时间管理技巧

流程图：审题（2min） → 构建YAML（5min） → 应用并验证（3min） → 标记复查（1min）

建议每题控制在 12 分钟内完成，预留 30 分钟处理复杂场景或重做题目。