【问题标题】:k8s probes for spring boot services, best practices用于 spring boot 服务的 k8s 探测,最佳实践
【发布时间】:2023-02-01 20:14:23
【问题描述】:

我正在为服务于 spring 引导服务的 kubernetes 部署配置启动/活动/就绪探测。从 spring boot 文档开始,最佳做法是使用相应的活动性和就绪性执行器端点,如下所述: https://spring.io/blog/2020/03/25/liveness-and-readiness-probes-with-spring-boot

你用什么做你的启动探针? 您对 failureThreshold、delay、period 和 timeout 值有何建议? 在将 isito sidecars 部署到现有设置时,您是否遇到过问题?

【问题讨论】:

  • 1. Rediness 2. 这非常依赖于应用程序,根据您的启动时间使用试错法 3. 完全没有

标签: spring-boot kubernetes istio


【解决方案1】:

我使用路径 /actuator/health/readiness/actuator/health/liveness

readinessProbe:
  initialDelaySeconds: 120
  periodSeconds: 10
  successThreshold: 1
  timeoutSeconds: 5
  failureThreshold: 3
  httpGet:
    scheme: HTTP
    path: /actuator/health/readiness
    port: 8080

livenessProbe:
  initialDelaySeconds: 120
  periodSeconds: 10
  successThreshold: 1
  timeoutSeconds: 5
  failureThreshold: 3
  httpGet:
    scheme: HTTP
    path: /actuator/health/liveness
    port: 8080

对于建议,实际上取决于您的需求和政策(https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/

没有 istio sidecars 问题 :)

不要忘记激活属性中的端点(cf https://www.baeldung.com/spring-liveness-readiness-probes):

management.endpoint.health.probes.enabled=true
management.health.livenessState.enabled=true
management.health.readinessState.enabled=true

【讨论】:

  • 感谢您的价值观,这实际上非常有帮助。你的初始化延迟非常高,有什么具体原因吗?你没有设置任何启动探测器吗?我正在考虑添加一个 tcpSocket 探测器,但很快就准备好了,所以我想这有什么意义。
  • 哦,是的,它实际上非常高,哈哈,这是因为部署的微服务需要比其他微服务更多的时间来连接所有 Kafka/MQ 东西以启动和运行。要知道你需要多少时间,只需移除探测器,启动你的 pod,检查启动、运行和准备好获取流量/连接所需的时间并使用这段时间(但是你可以添加最短的时间)等待,如果您的 pod 无故退出,则可能是由于此)。我没有为这个项目添加 tcpSocket 探测器,因为这个项目不是为了接收流量而是为了连接到其他东西。
  • 对于在 kuberentes 中运行的应用程序,您不需要 management.endpoint.health.probes.enabled=true。默认情况下启用它们。
  • 你是对的 ! :p
【解决方案2】:

除了@Bguess 答案和部分:

对于建议,这取决于您的需求和政策

我们的一些微服务与需要时间启动的重型/慢速容器通信,因此我们必须使用启动探测器来保护它们。来自https://kubernetes.io/ 的推荐方法是使用 liveness probe,与 spring-boot 执行器端点的连接导致:

readinessProbe:
  httpGet:
    path: /actuator/health/readiness
    port: http
  periodSeconds: 5
livenessProbe:
  httpGet:
    path: /actuator/health/liveness
    port: http
  periodSeconds: 5
startupProbe:
  httpGet:
    path: /actuator/health/liveness
    port: http
  failureThreshold: 25
  periodSeconds: 10

上面的设置确保我们在应用程序完全启动时探测livenessreadiness(有 10 * 25 = 250 秒这样做)。正如文档所说:

如果配置了这样的探测器,它会禁用活动性和就绪性检查,直到它成功,确保这些探测器不会干扰应用程序启动

请注意 management.endpoint.health.probes.enabled=true 在 Kubernetes 中运行的应用程序不需要 (doc)

只有当应用程序在 Kubernetes 环境中运行时,这些健康组才会自动启用。您可以使用 management.endpoint.health.probes.enabled 配置属性在任何环境中启用它们。

因此,如果您想在本地检查探针,则需要它。

【讨论】:

  • 也许是个愚蠢的问题,但有什么好的理由不使用/health作为startupProbe(但继续使用/health/liveness作为livenessProbe
猜你喜欢
  • 1970-01-01
  • 2020-03-08
  • 2020-09-30
  • 1970-01-01
  • 1970-01-01
  • 2020-04-19
  • 1970-01-01
  • 1970-01-01
  • 2019-05-25
相关资源
最近更新 更多