1. 为什么需要从NLB迁移到ALB在Kubernetes生产环境中监控服务作为关键基础设施其高可用性和稳定性直接影响运维效率。传统上很多团队选择Network Load BalancerNLB作为入口主要看中其高性能和低延迟特性。但随着业务规模扩大NLB的局限性逐渐显现功能单一NLB仅支持四层TCP/UDP负载均衡无法实现基于路径或主机的路由运维复杂度高需要自行管理SSL证书、维护访问控制策略成本效益低无法实现智能流量分配导致资源利用率不均衡相比之下Application Load BalancerALB作为七层负载均衡器提供了更丰富的功能集高级路由能力支持基于路径/metrics, /api、HTTP头或查询参数的流量路由内置安全特性原生集成AWS Certificate ManagerACM、WAF防护精细化监控提供请求级别指标和访问日志成本优化通过智能算法提升资源利用率2. 迁移前的关键准备工作2.1 环境拓扑梳理首先需要绘制当前监控服务的完整架构图明确以下要素现有NLB的监听器配置端口、协议后端目标组关联的EC2实例或IP地址安全组规则入站/出站流量限制DNS记录指向情况建议使用AWS Resource Groups服务快速获取相关资源清单aws resourcegroupstaggingapi get-resources \ --tag-filters Keykubernetes.io/service-name,Valuesmonitoring-service2.2 配置基线测试建立性能基准指标至关重要使用CloudWatch获取当前NLB的关键指标ActiveFlowCount活跃连接数ProcessedBytes处理流量HealthyHostCount健康后端数量通过k6进行负载测试import http from k6/http; import { check } from k6; export default function() { const res http.get(http://monitoring-service/api/v1/query); check(res, { status is 200: (r) r.status 200, response time 500ms: (r) r.timings.duration 500 }); }2.3 ALB预配置创建新的ALB时需要特别注意选择双AZ部署确保高可用启用跨区域负载均衡Cross-Zone Load Balancing配置访问日志输出到S3resource aws_lb monitoring_alb { enable_cross_zone_load_balancing true access_logs { bucket monitoring-logs-bucket prefix alb enabled true } }3. 零停机迁移实施步骤3.1 双轨运行阶段采用蓝绿部署策略保持新旧系统并行运行在Kubernetes中创建新的Ingress资源指向ALBapiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: monitoring-alb annotations: alb.ingress.kubernetes.io/scheme: internet-facing alb.ingress.kubernetes.io/target-type: ip spec: rules: - host: monitoring.example.com http: paths: - path: /* pathType: Prefix backend: service: name: monitoring-service port: number: 9090通过权重路由逐步切换流量resource aws_route53_record monitoring { zone_id data.aws_route53_zone.main.zone_id name monitoring type CNAME ttl 60 weighted_routing_policy { weight 10 # 初始10%流量到ALB } set_identifier alb records [aws_lb.monitoring_alb.dns_name] }3.2 健康检查优化ALB的健康检查机制与NLB有显著差异调整健康检查路径为/healthz设置合理的超时时间建议5秒配置成功阈值3次成功视为健康alb.ingress.kubernetes.io/healthcheck-path: /healthz alb.ingress.kubernetes.io/healthcheck-interval-seconds: 15 alb.ingress.kubernetes.io/healthcheck-timeout-seconds: 5 alb.ingress.kubernetes.io/success-codes: 200-3993.3 证书与安全配置迁移过程中SSL/TLS处理要点在ACM中申请或导入证书配置ALB监听器HTTPS规则resource aws_lb_listener https { load_balancer_arn aws_lb.monitoring_alb.arn port 443 protocol HTTPS ssl_policy ELBSecurityPolicy-TLS13-1-2-2021-06 certificate_arn aws_acm_certificate.monitoring.arn default_action { type forward target_group_arn aws_lb_target_group.monitoring.arn } }4. 迁移后的验证与优化4.1 功能验证矩阵设计全面的测试用例确保服务完整性测试场景预期结果验证方法指标采集端点访问返回200状态码curl -I https://monitoring.example.com/metrics告警规则评估触发预期告警模拟阈值突破事件历史数据查询返回完整时间序列Grafana面板检查服务发现自动发现新Pod部署测试Pod验证4.2 性能基准对比收集关键指标进行新旧环境对比延迟分布使用CloudWatch的ALB TargetResponseTime指标错误率对比HTTP 5xx错误计数资源利用率监控ALB的ActiveConnectionCount变化aws cloudwatch get-metric-statistics \ --namespace AWS/ApplicationELB \ --metric-name TargetResponseTime \ --dimensions NameLoadBalancer,Value$(aws alb describe-load-balancers --query LoadBalancers[?contains(DNSName,monitoring)].LoadBalancerArn --output text) \ --start-time $(date -v-1d %Y-%m-%dT%H:%M:%SZ) \ --end-time $(date %Y-%m-%dT%H:%M:%SZ) \ --period 300 \ --statistics Average4.3 成本优化建议ALB特有的成本控制策略请求压缩启用ALB的gzip压缩减少数据传输量resource aws_lb monitoring_alb { enable_deletion_protection false enable_http2 true idle_timeout 60 ip_address_type ipv4 load_balancer_type application enable_cross_zone_load_balancing true }智能路由根据URI路径分流到不同规格的实例组alb.ingress.kubernetes.io/actions.weighted-routing: | { type:forward, forwardConfig:{ targetGroups:[ { serviceName:monitoring-heavy, servicePort:9090, weight:20 }, { serviceName:monitoring-light, servicePort:9090, weight:80 } ] } }5. 常见问题与排错指南5.1 502 Bad Gateway问题排查典型原因及解决方案目标组健康检查失败检查后端服务/healthz端点可达性验证安全组允许ALB的私有IP访问ALB使用100.64/10网段证书链不完整使用openssl验证证书链openssl s_client -connect monitoring.example.com:443 -showcerts请求超时调整ALB的idle_timeout默认60秒检查Pod资源限制是否合理5.2 监控数据断点处理迁移过程中可能出现的数据丢失应对配置Prometheus的scrape_interval为15s原30s启用远程写入到S3长期存储remote_write: - url: http://thanos-receive:10908/api/v1/receive queue_config: capacity: 2500 max_shards: 200 min_shards: 1005.3 DNS缓存问题客户端可能缓存旧NLB的DNS记录设置TTL为60秒迁移期间临时调整使用curl测试解析结果for i in {1..10}; do dig short monitoring.example.com | sort | uniq -c; sleep 5; done在完成全面验证后可逐步将Route53权重调整为100%指向ALB并持续观察48小时确保无异常。最后清理NLB相关资源时建议保留配置快照作为回滚预案。