kubernetes - Pod到Pod的通信是同一节点上的2个Pod偶尔失败（EKS 1.13）

症状

对应用程序的请求偶尔会给出http 504或较长的等待时间（12s的倍数）。

我们在Pod到Pod的通信中遇到问题，其中2个Pod在kubernetes中的同一节点上。

例如，从nginx入口到同一节点上的应用程序容器从应用程序容器到同一节点上的应用程序容器从应用程序容器到同一节点上的rabbitmq eventbus容器

我们的基础架构

在nginx入口服务上具有经典ELB（内部和外部）（非网络lb）的EKS。负载平衡器服务具有本地的externalnetworkpolicy。节点版本为1.13.8的EKS 1.13（eks优化ami）

TCPDUMP

Folowing是尝试连接到事件总线的应用程序pod有用的tcpdump输出，失败。重试几次后通常会成功（通常在12秒后）：

13：44：46.744764 IP客户报告服务5b4d8c48b-vj4db.35196> eventbus-rabbitmq.kube-system.svc.cluster.local.5672：标志[S]，seq 1434468571，win 26883，选项[ mss 8961，sackOK，TS val 4064032250 ecr 0，nop，wscale 7]，长度0

13：44：46.751000 IP ip-10-0-161-173.eu-west-1.compute.internal> customer-reports-service-5b4d8c48b-vj4db：ICMP时间超出了传输时间，长度为68

有关此tcpdump的信息： 1. applicaton pod向同一节点上的eventbus pod发出请求 2.节点将超出的icmp时间发送到应用程序窗格。该请求可能永远不会到达事件总线。

可能的解决方法

使用pod反关联性确保每个事件总线pod，每个nginx入口pod，每个api网关都在与我们的应用程序服务不同的节点上运行

但是我正在寻找问题的实际解决方案。

其他相关参考

https://kubernetes.io/docs/tasks/debug-application-cluster/debug-service/#a-pod-cannot-reach-itself-via-service-ip 我的EKS设置中的发夹模式为发夹。有以下说明：确保Kubelet有权在节点上的/ sys中运行。但是我不确定如何执行此操作，因为在EKS上不存在cbr0接口，它使用eni接口

Pod到Pod的通信是同一节点上的2个Pod偶尔失败（EKS 1.13）

1 个答案: