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

【问题标题】：Kubernetes Intermittent Delay in response data from REST application来自 REST 应用程序的响应数据中的 Kubernetes 间歇性延迟
【发布时间】：2019-10-29 04:08:48
【问题描述】：

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

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

我在集群上部署了一个 REST API 应用程序，该应用程序具有返回约 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

使用 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

回答 cmets 的其他细节：

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

如有错误请指正：

POD_IP 是 192。（从 pod 描述中找到）
CLUSTER_IP 是 10。（通过服务找到）
INGRESS 是 istio 绑定的 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 为数据提供服务。

【问题讨论】：

嗨，Rob，欢迎来到 SO。您可以通过从集群内的其他地方（最好是未运行 Pod 的节点）针对 Pod 的 IP 发送 curl 来尝试您的实验吗？我也很想知道有多少Endpoints 注册了Service，您可以通过kubectl -n $the_namespace get -o yaml endpoints $the_service_name 获得，因为间歇性 失败闻起来就像有一个活着的Pod 和一个状态不佳，Service 将在它们之间循环（所有条件都相同，但 Istio 可能会变得更棘手）
谢谢马修。该服务是生产环境，但我会在下一个维护窗口中获取一些数据来回答您的问题。（解决方法是将获取数据的天数减少到 14 天。）get endpoints 命令输出中的当前 IP 数量为 2，并且有 2 个 pod.. 我相信这是当我们看到 numdays=30 的问题时也是如此。（如果不是，那就是 1 个吊舱）。
我认为 @mdaniel 就在这里，您是否已经实施了 ReadinessProbe 来解决您的 pod 尚未准备好为流量提供服务的问题？您能否添加kubectl get pods --all-namespaces 的屏幕，以便我们查看您的豆荚的状况？
谢谢，我已经添加了一些额外的细节
@Rob 你知道这个集群上有多少个 istio 入口网关控制器副本吗？检查客户端和数据库之间的连接效率。使用 istio 检查 TCP 连接的指标，检查客户端每秒的字节数。

标签： kubernetes

【解决方案1】：

感谢大家的反馈。

我们将 Isitio 升级到 1.3.3，发现 Sidecar 丢失并重新添加。间歇性似乎得到了解决。

【讨论】：