我是 LEE，老李，一个在 IT 行业摸爬滚打 16 年的技术老兵。
事件背景
马上要开始 618 活动了，公司准备在这时间点开始自己的大促销活动，但是实际我们公司平台中其他 To B 的商户老早开始了预热。traefik 作为 k8s ingress 全局入口，承载了全部业务的之间调用。随着请求量陡然上升以后，我们接到报警系统的预警，出现了部分核心业务 Pod 开始触发能力降级和自保。当时我们也很惊讶，k8s cluster 只用了 70% 左右的资源，为什么核心业务 Pods 就出现了能力降级和自保。
现象获取
经过排查和统计分析，发现出问题的核心业务都是启动 20 - 60 pods 的业务，随着 pods 数量越多，报警数量越频繁。我们紧急登录的 ES 做了一个数据统计分析，发现了一个"奇怪"的现象，当大规模请求进入到后端业务出现数量分配极度不均匀，部分节点请求非常高，而其他节点基本获得不到什么请求。
经过对其他的业务对比分析，总结出现了这样一个结论：pods 数量越少，流量越平衡；pods 数量越多，流量越不平衡。
原理分析
通过对现象的捕获，我们小组的小伙伴一致认为问题一定出现在"均衡算法"上，但是最后我们发现导致不均衡的真正原因并不是"均衡算法"，而是出在了 kubernetesCRD 资源每 2 秒刷新，导致均衡算法的中的 servers 列表每 2 秒刷新一次。而 traefik 在配置 Rule 的时候，假如 Rule 只有一个 service，那么这个 service 内调用是 RR 算法。在 servers 列表每 2 秒刷新这样一个周期内，由于每一个 http request 处理时间不是 100% 相同，导致在一个循环周期内处理的 http 请求总数不同，也就是说在 RR 情况下 servers 列表内容跑圈次数不一样。一但 servers 列表刷新，那么 RR 算法又从 servers 列表 index = 0 开始，这就导致 servers 列表内 Pods IP 越多情况下，servers 列表越靠后的 Pod IP 比前面 Pod IP 执行请求数量少，才出现了那种不均衡的情况。
具体看下面的原理图：
处理方法
既然是因为 kubernetesCRD 资源刷新到导致的，那么就有两个方法可以解决这个问题：
- 延长刷新间隔，从 2 秒变得更长。 这个确实有帮助，但是带来一个更加实际的问题，这样 traefik 对后端的 Pods 业务的扩缩容变化不敏感，容易出现 502。
- 乱序 informer 从 CRD 资源中读取 servers 列表内容的顺序，通过打乱顺序从而实现最后均衡效果
最后我还是采用了方法 2，主要是没有心智压力，同时也遵循默认的 traefik 对 CRD 资源动态同步的原则。
既然知道问题出在哪里，也有解决方案了，就爬了一段时间代码。非常简单，只要在 https://github.com/traefik/traefik/blob/v2.5.7/pkg/server/service/service.go 文件中 upsertServers 方法里添加两行代码就能完美实现效果。
func (m *Manager) upsertServers(ctx context.Context, lb healthcheck.BalancerHandler, servers []dynamic.Server) error {
logger := log.FromContext(ctx)
// 修复流量偏转 bug
if len(servers) > 1 {
rand.Seed(time.Now().UnixNano()) // 设置随机种子
rand.Shuffle(len(servers), func(i, j int) { servers[i], servers[j] = servers[j], servers[i]}) // 乱序 servers 列表
}
for name, srv := range servers {
u, err := url.Parse(srv.URL)
if err != nil {
return fmt.Errorf("error parsing server URL %s: %w", srv.URL, err)
}
logger.WithField(log.ServerName, name).Debugf("Creating server %d %s", name, u)
if err := lb.UpsertServer(u, roundrobin.Weight(1)); err != nil {
return fmt.Errorf("error adding server %s to load balancer: %w", srv.URL, err)
}
// FIXME Handle Metrics
}
return nil
}
最终效果
重编译 traefik 代码后，我们在 QA 环境部署了相同环境，做了 TCP 请求重放，模拟相同的请求。再一次观察业务 Pods 处理请求的情况，结果复合我们预期。所有 Pods 处理负载基本均匀，基本认为是一条横线。
改造后的请求负载图
最大与最小只差了 30 多个请求，基本可以忽略这个偏差了。 多 BB 一句，traefik 都到 2.7 版本了，后端负载不均衡的问题怎么不重视呢？
