K8s已删除消费者Pod在RabbitMQ残留连接仍消费消息的溯源

前置准备：提取RabbitMQ侧的精确锚点信息 #

• 优先通过RabbitMQ管理控制台或rabbitmqctl list_connections命令，提取目标异常连接的全量元数据：源IP地址、客户端端口、连接建立时间（锚定到你提到的2021-04-02注册时间）、连接用户名、对应的Consumer Tag。
• 重点拆解Consumer Tag的内容：绝大多数基于AMQP协议的客户端（包括Spring AMQP、各类Java/Go语言的RabbitMQ客户端）生成的Consumer Tag都会拼接客户端主机名、进程ID，这部分信息可以直接缩小后续的检索范围，不需要全量扫描集群所有资源。

分步溯源操作 #

1. 检索K8s历史留存的工作负载记录 #

• 全局拉取全集群事件：执行kubectl get events --all-namespaces --sort-by='.lastTimestamp'，将时间范围锚定到2021-04-02当天，筛选与异常IP相关的Created、Started、Killing、Deleted类事件，快速定位当时匹配该IP的Pod所属的命名空间、关联工作负载。
• 检索历史ReplicaSet：针对消费者服务所在命名空间，执行kubectl describe replicasets，翻查2021-04-02时间点前后的所有ReplicaSet条目，每个条目都会记录对应ReplicaSet曾经创建的Pod列表与分配的IP，逐一匹配RabbitMQ侧拿到的异常IP，即可定位旧发布批次对应的Pod信息。
• 查询etcd中的已删除Pod元数据：K8s的核心元数据全部存储在etcd中，已删除的Pod不会被立刻物理删除，会受etcd压缩策略影响留存一段时间（生产集群通常会配置数天的留存周期）。可通过etcdctl工具检索/registry/pods/<对应命名空间>/路径下的历史版本数据，匹配异常IP、对应时间戳，直接拿到旧Pod的完整元信息。

2. 从工作节点本地留存数据匹配 #

• 遍历所有K8s工作节点，使用容器运行时的CLI工具（crictl对应containerd、docker对应Docker引擎）执行crictl ps -a，列出节点上所有曾经运行过的容器（包括已终止、已回收的历史容器），筛选2021-04-02前后启动的消费者服务容器，查看对应容器的网络配置、当时分配的Pod IP，和RabbitMQ的异常IP做比对。
• 检查节点本地网络组件的留存记录：如果集群使用Calico、Flannel等CNI插件，节点本地通常会留存一段时间内的Pod IP分配映射表，可直接通过IP反查当时对应的所属Pod、所在节点。

3. 交叉验证非集群内来源的可能性 #

• 排除公网/NAT出口IP的干扰：如果匹配到的异常IP不在集群Pod网段范围内，大概率是集群外的消费者实例（比如长期运行的测试环境实例、CI流水线临时启动的消费任务）长期保持AMQP长连接，没有被K8s资源管辖区覆盖，才会出现kubectl get pods查不到对应实体的情况。
• 排查Endpoint残留问题：执行kubectl get endpoints -n <消费者服务对应命名空间>，对比当前Endpoint列表与历史记录，确认是否存在旧IP长期未被清理的情况；如果是StatefulSet类工作负载，需检查是否存在旧PVC残留导致Pod重建时复用到了之前的旧IP，出现IP与当前Pod列表不匹配的情况。

临时处置提示：如果溯源流程耗时较长，可直接通过rabbitmqctl close_connection <异常连接的IP:端口> "清理僵尸消费者连接"命令强制断开残留连接，阻断旧代码继续执行消费逻辑的风险。

补充说明：RabbitMQ的连接断开依赖客户端心跳机制，默认3个心跳周期未收到客户端响应才会主动断开连接。如果网络路径上存在TCP长连接拦截设备、客户端未正确实现心跳逻辑，就会出现客户端实体已销毁，但RabbitMQ服务端仍保留连接状态的僵尸问题，这类问题的排查核心永远是先拿到服务端侧的精确连接元数据，再反查客户端实体。

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