K8s环境重启客户端节点导致Ignite集群无响应问题排查求助

从日志可以定位到两个核心触发因素：

• 核心错误为SYSTEM_WORKER_BLOCKED，Ignite的TCP通信工作线程tcp-comm-worker在建立socket连接时卡在Net.poll原生调用，心跳超时超过阈值，触发系统工作线程阻塞告警。而你当前配置的StopNodeOrHaltFailureHandler明确忽略了SYSTEM_WORKER_BLOCKED、SYSTEM_CRITICAL_OPERATION_TIMEOUT两类故障，故障发生后节点不会自动退出，会作为僵死节点留在集群中，拖垮整个集群的通信链路。
• K8s环境下的网络波动是直接诱因：重启Tomcat Pod时新的Ignite客户端节点接入，若此时集群内存在旧客户端异常下线残留的半开连接，或者K8s网络策略/端口限制导致通信建联超时，就会卡住通信工作线程，最终导致整个集群无响应。

你看到的同时间PostgreSQL查询的线程转储和该故障完全无关，只是应用主线程执行正常DB查询时刚好被线程转储捕获而已。全量重启集群能解决问题的本质是销毁了所有僵死节点和残留的异常连接，集群重建了正常的通信链路。

临时规避方案（无需全量重启集群） #

• 遍历所有Ignite服务端Pod的日志，定位到打印了SYSTEM_WORKER_BLOCKED错误的僵死节点，单独删除该Pod，K8s会自动拉起新的健康服务节点替换，集群即可恢复正常服务。

永久修复方案 #

• 调整故障处理器配置：修改StopNodeOrHaltFailureHandler参数，移除SYSTEM_WORKER_BLOCKED、SYSTEM_CRITICAL_OPERATION_TIMEOUT的忽略配置，将tryStop设为true、timeout设为30000（30秒），故障发生后节点会自动停止，配合K8s健康检测自动重建Pod，避免僵死节点滞留集群。
• 优化TCP通信SPI配置：将TcpCommunicationSpi的connectTimeout调整为10000（10秒）、socketTimeout调整为30000（30秒），降低K8s网络波动时建联卡住的概率。
• 核对K8s网络规则：确保Ignite服务端节点之间、客户端与服务端之间的通信端口（默认端口范围47100~47200）双向互通，没有网络策略、安全组的拦截限制。
• 配置客户端节点清理规则：开启Ignite客户端节点的超时检测，客户端异常断开后服务端会自动清理对应的连接资源，避免半开连接残留阻塞通信线程。

内容的提问来源于stack exchange，提问作者RichardFeynman