时间戳

首页 > 解决方案 > 微服务活跃度和就绪超时处理

kubernetes - 微服务活跃度和就绪超时处理

问题描述

我在 kubernetes 集群中部署了 pod，并为一些 HTTPS 请求提供服务。我正在对每秒并发用户数的 api 进行负载测试。

当我在做负载测试时，容器由于活跃度和就绪性失败而被杀死，并且 Pod 被重新部署。因此，我的 API 面临失败。

liveness:
  initialDelaySeconds: 60
  periodSeconds: 20
  timeoutSeconds: 60
  successThreshold: 1
  failureThreshold: 4

readiness:
  initialDelaySeconds: 60
  periodSeconds: 20
  timeoutSeconds: 60
  successThreshold: 1
  failureThreshold: 4

livenessProbe:
   httpGet:
    path: /health
    port: 8000
    scheme: HTTPS
readinessProbe            
   httpGet:
    path: /health
    port: 8000
    scheme: HTTPS

我怎样才能避免这些失败？是因为我的应用程序无法满足活动请求吗？

标签： kuberneteskubernetes-pod

解决方案

您需要更具体地说明您到底在做什么负载测试。您正在使用哪些工具。

请检查pod导致 pod 被重新安排的事件日志的描述，这可以通过kubectl describe pod <pod_name>. 也许您的 pod 的内存或 cpu 不足，因此您可以查看管理容器的计算资源中的请求和限制。

您提到在运行测试时准备就绪和活跃度探测失败，这表明您正在将 http/https 施加到它不再能够服务请求的极限。

为了执行探测，kubelet 向容器中运行并侦听端口 8000 的服务器发送 HTTPS GET 请求。如果服务器 /health 路径的处理程序返回成功代码，则 kubelet 认为容器处于活动状态且健康。如果处理程序返回失败代码，kubelet 将杀死容器并重新启动它。

任何大于或等于 200 且小于 400 的代码都表示成功。任何其他代码都表示失败。

为了减轻这些故障，您可以增加timeoutSecondsand/or failureThreshold，但我认为您应该处理为请求提供服务的流程。

另外，我建议您阅读这篇出色的Kubernetes 最佳实践指南：使用就绪和活跃度探针设置健康检查。

推荐阅读