REST应用程序响应数据中的Kubernetes间歇延迟

我正在寻找一些关于如何调试裸机k8s集群中出现的网络问题的指导

除了下面讨论的应用程序之外，集群还承载多个应用程序。我不是集群中运行的所有东西的所有者，但我知道istio是最近引入的（以前使用的是nginx入口）

我在集群上部署了一个RESTAPI应用程序，该应用程序使用一个特定的路由返回大约7MB的历史数据（作为json结构）。API应用程序使用python模块缓存数据，以避免来自DB（helm mysql）查询或数据处理的任何开销。web应用程序（也部署在集群中）从API获取数据以显示，但通过直接使用curl，我将问题缩小到API应用程序或网络。进一步缩小问题范围，我能够在容器中运行curl（docker exec bash和在localhost上执行curl）时一致地成功获取数据

容器中运行curl的示例：

# time curl -o /dev/null localhost/$ROUTE?numDays=30
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 6380k  100 6380k    0     0  2716k      0  0:00:02  0:00:02 --:--:-- 2716k

real    0m2.359s
user    0m0.007s
sys     0m0.012s

使用入口或群集ip访问API应用程序时会出现问题，间歇性地需要2分钟以上才能完成。故障发生的时间超过50%

$ time curl -o /dev/null $CLUSTER_IP/$ROUTE?numDays=30
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 6380k  100 6380k    0     0  51523      0  0:02:06  0:02:06 --:--:--  331k

real    2m6.810s
user    0m0.011s
sys     0m0.038s

在这些需要2分钟响应的示例中，它们最初发送了部分数据。。2分钟后，我们得到100%。（以下输出显示几秒钟后81%的数据）

我正在寻找有关如何继续调试该问题的任何帮助或建议

群集信息： Kubernetes版本：

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.3",    GitCommit:"5e53fd6bc17c0dec8434817e69b04a25d8ae0ff0", GitTreeState:"clean", BuildDate:"2019-06-06T01:44:30Z", GoVersion:"go1.12.5", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.3", GitCommit:"5e53fd6bc17c0dec8434817e69b04a25d8ae0ff0", GitTreeState:"clean", BuildDate:"2019-06-06T01:36:19Z", GoVersion:"go1.12.5", Compiler:"gc", Platform:"linux/amd64"}

• 正在使用的云：裸金属
• 安装方法：未知（可能与metallb系统相关）
• 主机操作系统：RHEL7.5
• CNI和版本：印花布/CNI:v3.8.0
• CRI和版本：Docker版本18.06.1-ce，版本e68fc7a

---

回答评论的其他细节：

已经制定了一个变通办法，将30天的数据量从~7MB减少到~3MB。通过将默认值从30天更改为14天（进一步将数据减少到~1.5MB），进行了其他更改以进一步减少数据。这项工作进行了一段时间，直到奇怪的是集群中的另一个独立应用程序升级，我们称之为APP2。我不拥有APP2，我知道它是从发行说明中升级的，可以在get pods输出中看到它的年龄

如果我错了，请纠正我：

• POD_IP是192。（从pod中找到）
• 集群IP是一个10。（通过服务找到）
• 安格尔是一个10。istio绑定到的IP

从集群内的一个节点运行（POD在一个单独的节点上运行），集群IP和POD IP都会做出一致的响应，但入侵会造成问题。 在集群外部的某个VM上运行时，集群IP和入口都会遇到问题（外部不可能有POD IP）

此外，当外部主机上的群集IP的curl被卡住时。。我可以使用POD和群集IP成功运行内部卷发

get pods输出相当长。总结：与MYAPP相关的所有播客都在运行。有几个istio遥测吊舱被逐出。此外，似乎还有一个APP2 pod卡在终端，重新启动超过2k次

---

有一个端点注册到服务（子集->地址->IP下有一个IP地址），还有一个POD提供数据。

谢谢大家的反馈

---

我们将Isitio升级到1.3.3，并注意到侧车丢失并重新添加。间歇现象似乎已得到解决

谢谢大家的反馈

---

我们将Isitio升级到1.3.3，并注意到侧车丢失并重新添加。间歇现象似乎已得到解决

嗨，罗布，欢迎来到SO。您是否可以通过从集群内的其他位置（最好是未运行Pod的节点）针对Pod的IP发送

curl

来尝试您的实验？我还想知道为

服务注册了多少
端点
，您可以通过
kubectl-n$the_namespace get-o yaml Endpoints$the_Service_name
，因为间歇性故障闻起来像是一个活吊舱和一个状态不好的吊舱，而
服务
将在他们之间进行循环（所有事情都是平等的，但Istio可能会让这更棘手），谢谢Matthew。这项服务是生产性的，但我会在下一个维护窗口中寻找一些数据来回答您的问题。（解决方法是将获取数据的天数减少到14天。）get endpoints命令输出中的当前IP数为2，其中有2个POD。。我相信当我们看到numdays=30的问题时，情况也是如此。（如果不是的话，应该是1个吊舱）。我认为@mdaniel就在这里，您是否已经实施ReadinessProbe来解决您的吊舱无法提供流量服务的问题？您能添加
kubectl get pods的屏幕吗？所有名称空间
，这样我们就可以看到您的pods的状况了。谢谢，我添加了一些额外的功能details@Rob您知道此群集上存在多少istio入口网关控制器副本吗？检查客户端和数据库之间的连接效率。使用istio检查TCP连接的指标，检查每秒发送到客户端的字节数。嗨，Rob，欢迎使用SO。您是否可以通过从集群内的其他位置（最好是未运行Pod的节点）针对Pod的IP发送
curl
来尝试您的实验？我还想知道为
服务注册了多少
端点
，您可以通过
kubectl-n$the_namespace get-o yaml Endpoints$the_Service_name
，因为间歇性故障闻起来像是有一个活吊舱和一个状态不好的吊舱，而
服务
-
$ kubectl version
Client Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.3",    GitCommit:"5e53fd6bc17c0dec8434817e69b04a25d8ae0ff0", GitTreeState:"clean", BuildDate:"2019-06-06T01:44:30Z", GoVersion:"go1.12.5", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.3", GitCommit:"5e53fd6bc17c0dec8434817e69b04a25d8ae0ff0", GitTreeState:"clean", BuildDate:"2019-06-06T01:36:19Z", GoVersion:"go1.12.5", Compiler:"gc", Platform:"linux/amd64"}