时间戳

首页 > 解决方案 > Kubernetes：我应该在为我的就绪探测服务的端点中检查哪些类型的系统方面

kubernetes - Kubernetes：我应该在为我的就绪探测服务的端点中检查哪些类型的系统方面

问题描述

我在 Kubernetes 中部署了一个简单的 SpringBoot 应用程序（实际上是一个基于 REST 的微服务）。

它有一个下游依赖项（另一个基于 REST 的 Web 服务）。我知道，如果我的下游依赖项不可用/不可访问（因为 Kubernetes 重新启动我的微服务 pod 不会修复依赖项！） ，那么对于提供活性探针的 REST 端点，我不应该返回失败。

但是在 REST 端点提供我的就绪探测时，我应该检查下游依赖项吗？我宁愿只做一些基本的事情，但如果我需要检查更多，那么我会的。

@RequestMapping("/health")
public String getHealth() {
    return "OK";
}

标签： kubernetes

解决方案

假设您的 spring-boot 应用程序的活跃性（用户的角度）不需要依赖服务启动，那么您检查 Readiness Probe 状态的想法是正确的做法。

由于依赖的应用程序是 REST 服务，因此您可以公开一个 HTTP/HTTPS 端点以供就绪探针检查。并为liveness probe保留 spring-boot 应用程序的运行状况检查（或类似）端点。

但是，请注意，如果相关服务没有响应，运行第一个微服务（spring-boot 应用程序）的 pod 可能会变得无响应。

因此，提供正确的超时（initialDelays 和 periodDelay）以及成功和失败阈值有助于您缓解这种无响应状态。例如;

readinessProbe:
  httpGet: # make an HTTP request to dependent's health/readiness endpoint
    port: <port>
    path: /health
    scheme: HTTP 
  initialDelaySeconds: 10 # how long to wait before checking
  periodSeconds: 10 # how long to wait between checks
  successThreshold: 1 # how many successes to hit before accepting
  failureThreshold: 3 # how many failures to accept before failing
  timeoutSeconds: 15

官方文档：https ://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/#define-readiness-probes

一篇好文章：https ://itnext.io/kubernetes-readiness-probe-83f8a06d33d3

推荐阅读