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

Question

我正在寻找有关如何调试裸机 k8s 集群中似乎是网络问题的一些指导。

除了下面讨论的应用程序之外，该集群还托管多个应用程序。我不是集群中运行的所有东西的所有者，但我知道最近才引入了 istio(以前使用 nginx-ingress)。

我在集群上部署了一个 REST API 应用程序，该应用程序具有返回约 7MB 历史数据(作为 json 结构)的特定路由。 API 应用程序使用 python 模块缓存数据，以避免数据库(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

使用 ingress 或 cluster-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% 数据)

$ 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
 81 6380k   81 5178k    0     0   988k      0  0:00:06  0:00:05  0:00:01 1222k

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

集群信息:

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-system有关)

主机操作系统:RHEL7.5

CNI 和版本:calico/cni:v3.8.0

CRI 和版本:Docker 版本 18.06.1-ce，构建 e68fc7a

回答评论的其他详细信息:

有一个变通方法可以将 30 天的数据量从 ~7MB 减少到 ~3MB。通过将默认值从 30 天更改为 14 天(进一步将数据减少到约 1.5MB)，进行了其他更改以进一步减少数据。这工作了一段时间，直到奇怪的是集群中的其他独立应用程序之一升级了，我们称之为 APP2。我没有 APP2，我知道它是从发行说明升级的，并且可以在 get pods 输出中看到 AGE。

如果我错了，请纠正我:

POD_IP 是 192。(从 pod describe 中找到)

CLUSTER_IP 是 10。(通过服务找到)

INGRESS 是 istio 绑定(bind)的 10.IP。

从集群中的一个节点运行(POD 在一个单独的节点上运行)，CLUSTER_IP 和 POD_IP 都响应一致，但是 INGRESS 遇到了问题。
在集群外部的某个 VM 上运行时，CLUSTER_IP 和 INGRESS 都遇到了问题(POD_IP 无法在外部使用)。

此外，当外部主机上的 CLUSTER_IP 的 curl 卡住时。我可以使用 POD 和 CLUSTER_IP 成功运行内部 curl。

get pods 输出很长。总结:所有与 MYAPP 相关的 pod 都在运行。有一些 istio-telemetry pod 被驱逐。似乎还有一个 APP2 pod 卡在 Terminating 中，重启次数超过 2k。

向服务注册了一个端点(subsets->addresses->ip 下有一个 IP 地址)，并且有 1 个 POD 为数据提供服务。

Answer 1

感谢大家的反馈。
我们将 Istio 升级到 1.3.3，并注意到 sidecar 丢失并重新添加。间歇性似乎得到了解决。