1. 每次 backend lookup 都扫 EndpointSlice#

修复前的逻辑大概是这样：

1
c.factoriesKube[...].
2
    Discovery().
3
    V1().
4
    EndpointSlices().
5
    Lister().
6
    EndpointSlices(namespace).
7
    List(serviceSelector)

看起来是“按 Service 查 EndpointSlice”，但实际对 client-go 的 local cache 来说，这仍然是一次 selector list。也就是说，它要在 namespace 的 EndpointSlice 集合里做筛选。

如果一次配置构建里有很多 backend 引用，这个成本会被反复支付。

这类问题最麻烦的地方是，单独看一行代码不吓人，单次 list 也不一定慢。但放进 provider rebuild 的循环里，它会变成：

1
rebuild 次数
2
  * route / ingress path 数量
3
  * backend lookup 次数
4
  * namespace 内 EndpointSlice 数量

这就是控制面 CPU 问题常见的形状：不是某个函数慢到离谱，而是一个本来可以 O(1) 的查询，在热路径里退化成了 O(N)。

2. EndpointSlice 的无关 update 也触发完整 rebuild#

Kubernetes informer 只要收到 update event，provider 就很容易进入“重新构建配置”的路径。

但 EndpointSlice 的 update 不一定都影响 Traefik 的路由结果。比如只改了 resourceVersion、managedFields，或者一些 Traefik 根本不消费的 metadata，重建配置就是浪费。

当然，这里不能粗暴忽略所有 condition-only update。

EndpointSlice 里的这些条件是有语义的：

• Ready
• Serving
• Terminating

HTTP、TCP、UDP、Gateway provider 对这些字段的使用不完全一样。比如 endpoint 是否 ready，直接影响 server 是否应该进入配置。这里如果为了省 CPU 把 condition 变化吞掉，就会变成正确性问题。

所以正确做法不是“少看一点”，而是“只看真正参与配置语义的字段”。

3. Node 心跳把 provider 拖进 rebuild#

还有一条很隐蔽的线是 Node informer。

当 Traefik 需要 cluster-scope 资源时，会 watch Node。Kubelet 会周期性更新 Node status，里面有 conditions、images、capacity、allocatable 等字段。对 Kubernetes 来说，这是正常心跳。

但 Traefik 在这里真正关心的通常只是 Node 地址，尤其是：

• InternalIP
• ExternalIP

如果 Node 的地址没变，只是心跳字段变了，就不应该触发一次完整的动态配置 rebuild。否则你就会得到一个很稳定的“无意义重建节拍”。

EndpointSlice：给 informer cache 建索引#

新增了一个 indexer：

1
const EndpointSliceServiceNameIndex = "endpointSliceServiceName"
2

3
var EndpointSliceServiceNameIndexers = cache.Indexers{
4
    EndpointSliceServiceNameIndex: endpointSliceServiceNameIndexFunc,
5
}
6

7
func EndpointSliceServiceNameIndexKey(namespace, serviceName string) string {
8
    return fmt.Sprintf("%s/%s", namespace, serviceName)
9
}

索引 key 是：

1
namespace/serviceName

然后在各个 Kubernetes provider 的 EndpointSlice informer 上注册：

1
endpointSliceInformer := factoryKube.Discovery().V1().EndpointSlices().Informer()
2
if err = endpointSliceInformer.AddIndexers(k8s.EndpointSliceServiceNameIndexers); err != nil {
3
    return nil, err
4
}

查询时不再 .List(selector)，而是：

1
return k8s.EndpointSlicesByServiceName(
2
    informer.GetIndexer(),
3
    namespace,
4
    serviceName,
5
)

这块我没有只改 Gateway provider，而是一起覆盖了：

• kubernetes/ingress
• kubernetes/crd
• kubernetes/gateway
• kubernetes/ingress-nginx

原因很简单：这几个 provider 共享同一类 EndpointSlice lookup 成本。如果只修一个，问题还会在另一个入口形态里复现。

EndpointSlice event：比较值，不比较噪声#

event_handler.go 里加了 EndpointSlice 的内容级判断。

核心思路是：

• service name label 变了，要 rebuild
• ports 变了，要 rebuild
• endpoint 地址变了，要 rebuild
• endpoint conditions 变了，要 rebuild
• 只有 metadata / resourceVersion / managedFields 这类变化，不 rebuild

这里有一个很小但很重要的细节：指针字段不能直接比指针地址。

EndpointSlice 的 port name、port、protocol，以及 endpoint conditions 里有不少 pointer 字段。两个对象的值一样，但指针地址不同，这是正常的。所以我加了一个泛型 helper：

1
func samePtr[T comparable](a, b *T) bool {
2
    if a == nil || b == nil {
3
        return a == b
4
    }
5

6
    return *a == *b
7
}

这个点看起来很细，但在 informer update filter 里很容易踩坑。你以为自己在比较语义，实际上比较的是对象实例。

Node event：只看 Traefik 消费的地址#

Node update 的过滤也类似。

Traefik 这里关心的是 InternalIP / ExternalIP，所以我把 Node 地址抽成 set：

1
func nodeAddressSet(addresses []corev1.NodeAddress) map[corev1.NodeAddress]struct{} {
2
    result := map[corev1.NodeAddress]struct{}{}
3
    for _, address := range addresses {
4
        if address.Type != corev1.NodeInternalIP && address.Type != corev1.NodeExternalIP {
5
            continue
6
        }
7
        result[address] = struct{}{}
8
    }
9

10
    return result
11
}

这样 hostname 变化、capacity 变化、condition 心跳变化，都不会误触发 rebuild。只有真正影响 Traefik 入口地址判断的变化，才会继续往下走。

Gateway listener：不要每条 Route 都扫所有 listener#

Gateway provider 里还有一个额外优化。

以前 HTTPRoute / GRPCRoute / TLSRoute / TCPRoute 匹配 Gateway listener 时，会拿 route 的 parentRefs 和所有 gateway listeners 做匹配。Route 数量一多，这也是典型的重复扫描。

我加了一个很小的 index：

1
type gatewayListenerIndex struct {
2
    byGateway map[ktypes.NamespacedName][]gatewayListener
3
}

构建配置时先把 listeners 按 namespace/name 分组。后面每条 Route 只需要根据 parentRef 找对应 Gateway 的 listeners。

这里不是为了炫技。它只是把数据结构调回正确形态：

1
大量 Route -> 少量 Gateway listener

这种关系本来就应该用索引查，而不是每次全量扫。

1. 先分清楚数据面和控制面#

Traefik 的 CPU 高，不一定是请求转发高。

先看：

• 请求量有没有同步上升
• access log / metrics 里的 RPS 是否对应
• CPU 尖刺是否跟 rollout、scale、Node 事件、EndpointSlice 事件重合
• pprof 里热点是在转发路径，还是 provider rebuild 路径

如果热点在 provider，就不要先去调中间件、TLS、压缩这些数据面选项。

2. 看 informer event 是否真的有语义变化#

很多控制器性能问题，本质是 event 太吵。

我会重点看这些对象：

• EndpointSlice
• Service
• Secret
• Ingress / HTTPRoute / Gateway
• Node

然后问一个问题：这个 update 真的会改变最终配置吗？

如果不会，就应该在 event handler 层过滤掉。靠后面的 hash、deep equal、throttle 都是补救，不是根治。

3. 看 hot path 里有没有 O(N) selector scan#

client-go cache 不是数据库。

如果你在热路径里不断做 .List(selector)，一定要问自己：

• selector 是否可以变成 indexer
• key 是否可以提前构造
• 是否可以在一次 rebuild 内做 per-service dedup
• 是否会随着 namespace 对象数量线性增长

EndpointSlice 这个问题就是很典型的例子。数据结构迁移本来是为了扩展性，但调用方如果还用 scan 的心智，扩展性收益会被吃掉。

4. 看 rebuild 有没有被重复触发#

有些 rebuild 是必要的，比如 Route 变了、Service endpoint 变了、Secret 证书变了。

但有些 rebuild 只是噪声：

• Node heartbeat
• metadata managedFields 更新
• controller annotation tick
• resourceVersion 变化但 payload 不变

这些噪声如果不挡在入口，后面每一层都会付成本。

5. 最后再考虑 throttle#

Traefik provider 本身有 throttle 相关配置，这类配置有用，但我不建议把它当第一优先级。

throttle 能把很多事件合并成更少的 rebuild，但它没有改变两件事：

• 单次 rebuild 本身还是贵
• 无意义事件仍然会进入系统

所以我的顺序会是：

1. 先减少无意义事件
2. 再降低单次 rebuild 成本
3. 最后用 throttle 做工程上的缓冲