Linux calico 的 typha 与高规模集群 Felix 负载分担实践

1次阅读

typha 在大规模集群中非开箱即用,因其默认无状态代理不感知 felix 连接数变化、不自动迁移连接或负载均衡,导致 cpu 倾斜、连接超时及节点启动慢;需启用 dns srv 发现、禁用静态 endpoint、配置 felix 使用 headless service 并调优重连与 tls 参数。

Linux calico 的 typha 与高规模集群 Felix 负载分担实践

为什么 Typha 在大规模集群里不是“开箱即用”就有效的

因为默认部署的 typha 实例不自动感知 Felix 连接数变化,也不会主动做连接迁移或负载重平衡。它只是个无状态代理,Felix 连接一旦建立,就长期绑定到某个 Typha 实例上——哪怕那个实例 CPU 已经跑满,其他 Typha 实例还空着。

常见错误现象:Felix 日志频繁出现 Failed to connect to Typha 或连接超时;typha Pod 的 CPU 持续 >90%,但其他副本几乎闲置;calico-node 启动变慢,尤其在节点扩容后。

  • 必须显式开启 typha 的服务发现能力:通过 kubernetes Service 的 ClusterIP + headless Service 配合 DNS SRV 记录(需 Calico v3.22+)
  • 禁用 typha 的静态 endpoint 配置(如 TYPHA_ENDPOINTS 环境变量),否则 Felix 会绕过 DNS 直连,失去负载分散能力
  • Felix 必须设为使用 DNS 解析:FELIX_TYPHAK8SSERVICENAME 指向 headless Service 名,且 FELIX_TYPHAK8SENABLED 设为 true

如何验证 Felix 是否真的在轮询多个 Typha 实例

不能只看 kubectl get endpoints 有没有多个 IP——那只是 Service 的 endpoint 列表,不代表 Felix 实际连接行为。关键要看 Felix 进程里建立的 TCP 连接目标。

使用场景:集群有 3 个 typha 副本,但 calico-node 日志显示始终连同一个 IP。

  • 进任一 calico-node 容器:nsenter -t 1 -n ss -tnp | grep :5473(Typha 默认端口)
  • 观察输出中 ESTAB 连接的目标 IP 是否分散在多个 Typha Pod IP 上;若全指向一个 IP,说明 DNS 解析失败或 Felix 配置未生效
  • 检查 calico-node 容器内 /etc/resolv.conf 是否能解析 typha-calico.default.svc.cluster.local(假设 Service 名为 typha-calico
  • 确认 CoreDNS 或 kube-dns 返回的是 A 记录(非 CNAME),且记录数量与 Typha 副本数一致

Felix 连接 Typha 超时与重试参数怎么调才不拖慢节点启动

默认 FELIX_TYPHARECONNECTTIMER 是 1s,但在高规模集群里,大量 Felix 同时重连会导致 Typha 瞬时压力暴涨,反而延长连接建立时间。

性能影响:节点启动时,如果 Felix 连不上 Typha,会阻塞路由同步和策略加载,Pod Ready 状态延迟可达分钟级。

  • FELIX_TYPHARECONNECTTIMER 建议设为 5s10s,避免雪崩式重连
  • FELIX_TYPHATIMEOUTINSEC 不宜过短(如 2),否则网络抖动就断连;建议 58
  • 启用 FELIX_TYPHARANDOMIZESTARTUPDELAY(v3.23+),让各节点 Felix 启动后随机延迟 0–30 秒再连 Typha,削峰
  • 注意:这些参数必须在所有 calico-node DaemonSet 的 env 中统一配置,不能只改部分节点

为什么 Typha 的 TLS 配置错一点,Felix 就静默失败

Calico 不会在 Felix 日志里明确报 “TLS handshake failed”,而是表现为反复重连、最终降级为无 Typha 模式(Felix 自行处理策略,CPU 暴涨)。

容易踩的坑:用自签证书但没把 CA 加入 Felix 容器的系统信任库;或 Typha 的 server.crt 里 Subject Alternative Name(SAN)漏了 Service DNS 名。

  • 确认 typha 启动参数含 --tls-cert-file=/calico-secrets/tls.crt--tls-key-file=/calico-secrets/tls.key
  • 证书 SAN 必须包含:typha-calicotypha-calico.defaulttypha-calico.default.svctypha-calico.default.svc.cluster.local
  • Felix 容器内需挂载 CA 证书,并通过 FELIX_TYPHACAFILE 指向它(路径需与挂载路径一致)
  • openssl s_client -connect typha-calico:5473 -CAfile /path/to/ca.crt 手动验证 TLS 握手是否成功

最麻烦的点往往不在配置本身,而在证书更新后忘记滚动重启 Typha,或者忘了同步更新 Felix 的 CA 文件——这两个动作不同步,就会进入“连得上但验不过”的静默故障状态。

text=ZqhQzanResources