负载均衡接入与云原生流量治理实战演练教程-安全-PHP中文网

负载均衡需分层协同与策略对齐：slb仅做基础转发或https卸载，ingress负责七层路由与灰度，sidecar专注服务发现与细粒度负载；健康检查须端到端统一路径、判定逻辑与超时梯度；算法按业务选型，如ai推理用least_request，冷启动服务启用离群检测；可观测性需打通各层指标并全链路埋点。

负载均衡接入与云原生流量治理实战演练教程

负载均衡接入不是简单加个代理就完事，关键在分层协同和策略对齐。云原生环境里，流量从入口到 Pod 要穿过 SLB、Ingress、Service、Sidecar 多层，每层职责不同，也容易互相干扰。实战中真正卡住的，往往是配置错层、健康检查不一致、或算法没匹配业务特征。

分层接入：明确每层该干什么

外层云厂商 SLB（如阿里云 CLB、AWS ALB）只做基础 TCP/UDP 转发或 HTTPS 卸载，不解析路径或 Header；中间层 Ingress Controller（如 Nginx、Higress、Traefik）负责七层路由、TLS 终结、灰度权重、流量镜像；内层 kube-proxy 或 Service Mesh 的 Sidecar（如 Istio Envoy）专注服务发现、实例健康感知、细粒度负载算法（如 LEAST_REQUEST）。不要让 Ingress 去做熔断，也不该让 kube-proxy 处理 Cookie 会话保持。

SLB 层：开启主动健康检查，探测端口连通性即可，超时设为 3 秒以内
Ingress 层：用 annotation 控制金丝雀（nginx.ingress.kubernetes.io/canary-weight: "10"），避免硬编码版本标签
Mesh 层：通过 DestinationRule 配置 simple: LEAST_REQUEST，适合 AI 推理类高并发低响应场景

健康检查必须端到端对齐

如果 SLB 认为后端健康，但 Istio 把它踢出 Endpoint，请求就会 503。根本原因是各层探针路径、超时、失败阈值不一致。例如 SLB 检查 /healthz，而 Pod 的 readinessProbe 配的是 /ready，且返回码逻辑不同——前者只看 2xx，后者要求 200 且内存低于 80%。

统一探针路径：所有层级使用同一 endpoint，如 /health
统一判定逻辑：返回 JSON {"status":"UP","load":42}，各层按 status 字段判断，而非仅 HTTP 状态码
超时梯度设置：SLB 探针超时 5s > Ingress 3s > Pod readinessProbe 1s，避免上层等待下层卡死

负载算法选型要贴合业务特征

轮询（Round Robin）适合 CPU 均衡、模型同构的推理集群；最少请求（Least Request）更适合批处理与实时混合场景，能自动避开正在处理大请求的 Pod；加权响应时间（Weighted Least Response Time）则适用于 GPU/CPU 混合节点组，需配合 Prometheus 指标动态更新权重。

纯 CPU 推理服务：用 LEAST_REQUEST，Istio VirtualService 中配置即可
含冷启动模型的服务：启用 outlier detection，自动摘除首次响应 >2s 的新 Pod
多区域部署：结合 GTM 的延迟反馈，在 Ingress 层做地理路由（如 host 匹配 + geoip header）

可观测性不能只看“是否通”

传统监控只告警“5xx 上升”，但真实问题常藏在链路毛刺里：某次请求在 Ingress 层耗时 120ms，Envoy 层耗时 800ms，说明是服务内部阻塞，而非网关问题。必须打通各层指标：SLB 的 request_count、Ingress 的 upstream_response_time、Envoy 的 upstream_rq_time_ms、Pod 的 http_server_request_duration_seconds。