负载均衡需分层协同与策略对齐：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。
- 统一打标：所有日志和指标加 ingress_id 和 pod_uid 标签
- 关键链路埋点：在 Ingress 注入 X-Request-ID，确保全链路可追溯
- 阈值联动：当 Envoy 的 p99 响应时间突破 300ms，自动触发对应 Pod 的 profiling 抓取
