Typha 在大规模集群中非开箱即用，因其默认无状态代理不感知 Felix 连接数变化、不自动迁移连接或负载均衡，导致 CPU 倾斜、连接超时及节点启动慢；需启用 DNS SRV 发现、禁用静态 endpoint、配置 Felix 使用 headless Service 并调优重连与 TLS 参数。
为什么 Typha 在大规模集群里不是“开箱即用”就有效的
因为默认部署的 typha 实例不自动感知 Felix 连接数变化，也不会主动做连接迁移或负载重平衡。它只是个无状态代理，Felix 连接一旦建立，就长期绑定到某个 Typha 实例上——哪怕那个实例 CPU 已经跑满，其他 Typha 实例还空着。
常见错误现象：Felix 日志频繁出现 Failed to connect to Typha 或连接超时；typha Pod 的 CPU 持续 >90%，但其他副本几乎闲置；calico-node 启动变慢，尤其在节点扩容后。
- 必须显式开启
typha的服务发现能力：通过 Kubernetes Service 的ClusterIP+headlessService 配合 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建议设为5s～10s，避免雪崩式重连 -
FELIX_TYPHATIMEOUTINSEC不宜过短（如2），否则网络抖动就断连；建议5～8 - 启用
FELIX_TYPHARANDOMIZESTARTUPDELAY（v3.23+），让各节点 Felix 启动后随机延迟 0–30 秒再连 Typha，削峰 - 注意：这些参数必须在所有
calico-nodeDaemonSet 的 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-calico、typha-calico.default、typha-calico.default.svc、typha-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 文件——这两个动作不同步，就会进入“连得上但验不过”的静默故障状态。
