worker节点kernel panic导致pod网络路由长期不释放，本质是节点异常宕机后集群未及时感知清理；需先确认节点notready状态，再通过kubectl drain或delete node强制驱逐并触发terway自动清理eni与路由，最后核对vpc路由表和eni实际状态并手动清除残留。
Worker节点发生Kernel Panic后，其上Pod的网络路由长期不释放，本质是节点异常宕机导致网络状态未被集群及时感知和清理。Kubernetes本身不主动回收已失联节点的网络资源，需结合ACK组件行为与手动干预快速恢复。
确认节点已彻底不可用并标记为NotReady
Kernel Panic通常导致节点完全离线或卡死。先验证节点真实状态：
- 在ACK控制台「节点管理」中查看该节点状态是否为NotReady或长时间无心跳
- 执行
kubectl get node <node-name></node-name>，若显示NotReady且AGE持续增长，说明API Server已失去联系 - 若节点仍显示
Ready但实际无响应，需通过ECS控制台确认实例是否已停止或处于“运行中但无法连接”状态
强制驱逐节点上所有Pod并触发网络清理
Terway插件依赖节点上的terway-eni或terway-eniip DaemonSet来管理ENI和IP路由。节点宕机后，这些组件停止工作，但集群不会自动释放其绑定的IP和路由条目。需人工介入：
Skill Weave Chains — 技能链路由引擎
下载
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
- 执行
kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data --force</node-name>，强制标记Pod为待驱逐（即使节点不可达） - 若
drain失败，直接删除节点对象：kubectl delete node <node-name></node-name>。ACK会自动触发Terway清理该节点注册的ENI、IP及对应路由表项 - 检查
kubectl get eniconfig -n kube-system和kubectl get configmap eni-config -n kube-system -o yaml，确认其中未残留该节点的ENI绑定记录
验证VPC路由表与ENI实际状态
部分路由残留可能源于云平台侧未同步更新。需交叉核对：
- 登录VPC控制台，进入「路由表」→ 找到集群关联的路由表 → 查看是否有指向该故障节点私网IP的自定义路由（尤其是目的地址为Pod CIDR段的条目）
- 进入「弹性网卡（ENI）」列表，筛选该节点ECS实例ID，确认所有ENI状态为已释放或已解绑，无处于
Attaching或Detaching状态的异常ENI - 若发现残留路由或ENI，手动删除；同时检查安全组规则是否仍引用该节点（如基于IP的入方向规则）
预防后续同类问题影响扩散
单点Kernel Panic不应引发全集群网络紊乱，可通过以下配置降低风险：
- 启用
cluster-autoscaler的--skip-nodes-with-system-pods=false参数，确保关键系统Pod（如Terway）不成为缩容障碍 - 为Terway配置健康探针：在DaemonSet YAML中添加
livenessProbe，探测/healthz端点，使崩溃进程能被及时重启而非僵死 - 在节点池设置中开启「自动修复」，当检测到节点连续多次
NotReady时，自动替换ECS实例并重建网络环境
