Kubernetes下同个请求被2个Pod同时接收处理的问题咨询

是否属于K8s常见问题 #

这属于K8s部署服务时的常见非预期现象，不属于K8s本身的功能缺陷，绝大多数情况和流量转发链路配置、上下游服务策略相关。

可能的产生原因 #

• 负载均衡重试触发：如果你的Service前端对接了Ingress、云厂商负载均衡实例或是七层网关，当第一个处理请求的Pod出现响应超时、TCP连接握手超时、返回5xx类错误时，负载均衡默认会开启重试逻辑，将同一份请求转发给下一个健康Pod，就会出现两个Pod同时处理同个请求的情况。
• 上游服务/请求发起端重试：Google Chats的webhook本身就有超时重试机制，若第一次请求的响应没有在其设定的超时窗口内返回，它会自动发起第二次重试请求，两次请求间隔极短，刚好被K8s的Service负载均衡分发到两个不同的Pod，就会出现你观察到的现象，这种情况和K8s本身无关。
• kube-proxy转发规则异常：如果集群的kube-proxy采用IPVS模式，出现了规则残留、会话保持配置错误、或IPVS内核模块bug时，可能出现同个请求被复制分发到多个后端Pod的情况，可以在节点上执行ipvsadm -Ln查看对应Service的转发规则是否正常。
• 特殊流量策略配置：如果你开启了服务网格的流量镜像、或是给Service配置了多路广播类的自定义路由规则，也会主动将请求复制转发给多个后端Pod。

同类问题情况 #

大量使用K8s部署webhook、回调类接口的开发者都遇到过同类问题，尤其是对接第三方webhook的无状态服务，重复请求的出现概率远高于内部接口场景。

通用规避方案 #

建议优先在接口侧做幂等处理：提取Google Chats请求自带的唯一请求ID作为幂等键，插入数据库前先校验该幂等键是否已经存在，不存在才执行写入操作，从业务侧避免重复数据产生。

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