Readiness 和 Liveness 以随机间隔失败

Question

我们正在 GKE 上运行烧瓶微服务。接受所有流量并将其分配给其他服务的主应用程序正在重新启动。

POD 的就绪和活跃度开始随机超时。但是，我们正在运行 5 个特定服务的 pod，它是无状态应用程序。我注意到一件事，记忆也随着时间的推移而不断增加。

是否由于 docker python-slim 图像在某个级别无法处理应用程序以及 pod 中的持续内存增加，是否就像操作系统 python-slim 不释放内存一样？

注意：此行为仅适用于生产而不是暂存（运行单个应用程序 pod）。

这背后的原因是什么云，请帮忙。谢谢

更新 活跃度和就绪度探测配置

readinessProbe:
            httpGet:
              path: /k8/readiness
              port: 9595
            initialDelaySeconds: 25
            periodSeconds: 8
            timeoutSeconds: 10
            successThreshold: 1
            failureThreshold: 30
        livenessProbe:
            httpGet:
              path: /k8/liveness
              port: 9595
            initialDelaySeconds: 30
            periodSeconds: 8
            timeoutSeconds: 10
            successThreshold: 1
            failureThreshold: 30

Answer 1

虽然在不查看集群中的清单、事件或其他跟踪信息的情况下提供答案有点困难，但我经常看到这种情况发生在人们误解/错误配置就绪和活跃度探测器和/或未正确扩展时.

例如，您可能有一个探针：

readinessProbe:
  httpGet:
    path: /healthz
    port: 443
  failureThreshold: 1
  periodSeconds: 10

这意味着，每 10 秒检查一次，如果 http GET 到 /healthz:443 正常，如果失败一次，则停止发送流量（因为它只是一个就绪探测）。

如果不设置timeoutSeconds，默认为1秒。

在负载下经常发生的情况是，如果不添加额外的 pod 并且延迟不断增加，/healthz:443 端点需要越来越长的响应时间。

最终，一旦它徘徊在 1 秒左右，一次超时将导致准备失败 - 这是最好的情况。

如果你的 liveness probe 是这样配置的，你会重启 pod，这会更糟。

这个article 很好地解释了为什么使用活性探针并不总是明智的（除非你有一个非常具体的检查）。

在负载导致这种情况的情况下，您实际上可以设置 1 秒超时（默认值），但如果您的延迟增加，您可能希望使用 HPA 之类的东西来添加额外的 pod。