时间戳

首页 > 解决方案 > Pod 到 Pod 的通信是 2 个 Pod 在同一个节点上偶尔失败 (EKS 1.13)

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

问题描述

症状

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

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

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

我们的基础设施

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

TCPDUMP

以下是来自应用程序 pod 的有用 tcpdump 输出，该 pod 尝试连接到事件总线，但失败了。在大多数情况下（通常在 12 秒后），它会在几次重试后成功：

13:44:46.744764 IP customer-reports-service-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. 应用程序 pod 向同一节点上的 eventbus pod 发出请求 2. 节点向应用程序 pod 发送超过 icmp 时间。可能请求永远不会到达事件总线。

可能的解决方法

使用 pod 反亲和性来确保每个 eventbus pod、每个 nginx 入口 pod、每个 api 网关都运行在不同的节点上，然后我们的应用程序服务

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

其他相关参考

https://kubernetes.io/docs/tasks/debug-application-cluster/debug-service/#a-pod-cannot-reach-itself-via-service-ip 我的 EKS 设置中的发夹模式是 hairpin-veth。有如下指令：确保 Kubelet 有权限在 node 的 /sys 下运行。但我不确定如何做到这一点，因为在 EKS 上 cbr0 接口不存在，它使用 eni 接口

标签： kubernetesamazon-eks

解决方案

好的，在发布问题后，AWS 为我提供了解决问题的方法：

问题： https ://github.com/aws/amazon-vpc-cni-k8s/issues/641

将 VPC CNI 插件降级到 v1.5.3 直到 1.5.5 发布：更新 daemonset 并重启所有节点

推荐阅读